On 2/19/20 10:06 AM, Alexander Kanavin wrote:
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.


I think it will. arch specific overrides should come before generic ones.

Alex

On Wed 19. Feb 2020 at 18.21, Khem Raj <[email protected] <mailto:[email protected]>> wrote:

    On Wed, Feb 19, 2020 at 1:45 AM Alexander Kanavin
    <[email protected] <mailto:[email protected]>> wrote:
     >
     > On Tue, 18 Feb 2020 at 02:56, Khem Raj <[email protected]
    <mailto:[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

Reply via email to