Hi, You laid this out pretty nicely. So a few questions: 1) uvesafb is only a /dev/fb driver right ? I guess it won't help with gnome-shell, but might help with weston? 2) I believe SimpleDRM is a drm version of uvesafb...have you considered it? 3) One thing i'm worried about is races with the real modesetting drivers. can we avoid loading this if theres another driver that advertises support for the pci device? does it already? 4) if you drop vesa and openchrome, maybe you could move fbdev in the server tree like modesetting. If you went with simpledrm instead, maybe you could drop fbdev entirely too? Anyway, your email makes it sound like there are more pluses than cons, so i'm on board. --Ray On Tue, Apr 23, 2019 at 8:47 PM Adam Jackson <ajax@xxxxxxxxxx> wrote: > > I'm considering changing the vesa support code in future Fedora > releases, for a few reasons. I think this will both simplify the > support burden for developers, and increase the number of supported > video configurations in practice. But it's not clear-cut, hence this > email. > > The fallback video path on x86 machines is either efifb if you're > living in the future, or X's vesa driver if you're living in the past. > At this point there are only two X drivers that require userspace setup > support, vesa and openchrome. (The latter I'm also considering nerfing, > because I sincerely doubt there are any Fedora users of it; if this is > you, speak up.) Removing this code would simplify some awkward device > enumeration cases in the X server - cases which have come up in the F30 > blocker list, and I would like not to be on the critical path for that > kind of thing in the future. > > This would also move an 8086 emulator out of the X server to a > dedicated usermode helper. Which is nice, since X still has to run with > elevated privileges in these cases, and X hasn't exactly lacked for > CVEs. > > Having done this, we would also potentially _expand_ the number of > devices we support for graphics, because we would have a vesa-backed > fbdev driver. There exist wayland servers that can display to fbdev, > but I'm not aware of any that can display directly to vesa. > > But there are risks. For one, we've never tried this. uvesafb itself is > not untested - I believe you can coax ubuntu and gentoo into using it - > but we've never built it in Fedora before, so the interactions with > with our initramfs, with plymouth, and so on are only "tested" to the > extent that they're the same thing everyone else is doing. > > In particular, I'm not entirely sure how well the handoff from uvesafb > to drm works in practice. From efifb to drm is fairly well tested, and > also fairly likely to be safe, because efifb does not give you any > ability to _change_ video device state. uvesafb does, and we could end > up putting the GPU in a new funky state that the drm driver doesn't > know how to handle. I suspect this is unlikely, and possible to > mitigate (by blocking uvesafb from initializing in more cases, for > instance), but it's something to be aware of. > > Finally, uvesafb only supports video devices that support VBE 2.0 or > higher. In principle, X's vesa driver supports any VBE implementation > at all. I'm not convinced this is a real issue for us though. VBE 2.0 > dates to 1994, and I have maybe one pre-2.0 video card in my collection > of old weird junk. > > So. Pros: remove some sketchy code from a setuid program everyone has > installed, potentially lower its privilege profile, potentially enable > wayland in more scenarios. Cons: maybe lose some device support, maybe > break gfx fallback on old-firmware systems. > > What do we think? > > - ajax > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
