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 <[email protected]> wrote: > On Wed, Feb 19, 2020 at 1:45 AM Alexander Kanavin > <[email protected]> wrote: > > > > On Tue, 18 Feb 2020 at 02:56, Khem Raj <[email protected]> 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 >
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
