[OE-core] [PATCH 05/10] weston-init: use the drm backend rather than fbdev one

[Alexander Kanavin]

Will that take precedence over qemuall though? Sounds brittle. Another
option is to make the fbdev configuration specific to mips and arm, as
using kms does not need a configuration at all.

Alex

On Wed 19. Feb 2020 at 18.21, Khem Raj <raj.khem at gmail.com> wrote:

> On Wed, Feb 19, 2020 at 1:45 AM Alexander Kanavin
> <alex.kanavin at gmail.com> wrote:
> >
> > On Tue, 18 Feb 2020 at 02:56, Khem Raj <raj.khem at gmail.com> wrote:
> >>
> >>
> >>> but I'll get to it, or you are welcome to try and report.
> >>> Mips can be either fixed like suggested, or be a specific exception.
> >>>
> >>> For the rest of the targets, I see that you have extended the fbdev
> fallback to qemuall only on Jan 9 this year. So it's very unlikely anyone
> is using them to run weston (not to mention how painfully slow that would
> be), and so it would just be wasteful to test or fix them.
> >>
> >>
> >> We should be only applying tested part debugging these breakages is
> very hard so when we know it will break we should be careful as with this
> patch
> >
> >
> > I have tested these things now:
> >
> > 1. Switching mips from cirrus to std vga works fine, as long as
> xorg.conf is also deleted (it's written specifically for cirrus and isn't
> working or needed with std vga). Both weston and sato boot and look right.
> I'll send a patch for it.
> >
> > 2. Switching weston to kms backend degrades performance to unusable
> level, as neither kvm nor virtio/virgl are available for non-x86 qemu, and
> kms backend is using software renderer in mesa. So fbdev is the only
> realistic option there. But for x86 qemu kms is still viable. I'm not sure
> how to best configure it though.
>
> copy qemuall/weston.ini new folders qemux86 and qemux86-64 and point
> to backend it should be using.
>
> >
> > Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20200219/da0b8d5b/attachment-0001.html>