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
