On Tue, 2019-03-12 at 14:11 -0400, Adam Jackson wrote: > On Wed, 2019-03-06 at 12:46 -0800, Adam Williamson wrote: > > Hi folks! > > > > So there's a current Beta blocker bug: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1683197 > > > > it is currently accepted as a blocker on the understanding that trying > > to boot to Workstation in 'basic graphics mode' (i.e. with 'nomodeset' > > on the cmdline) *always* fails, on all hardware (or at least on most > > hardware). However, we don't yet have enough testing to be sure of > > this. > > I looked into this today, and while it's a truly gross issue at root, I > think I've got a reasonable solution (see patch in comment #11). > > The issue seems to be: > > a) gdm is expecting a 'master-of-seat' property for the graphics device > attached to a given seat before it will deign to touch the seat > > b) systemd is now setting that property only for a subset of devices - > specifically, drm devices but not fbdev devices. > > c) you don't want to set master-of-seat unconditionally for fbdev > devices, because it introduces a race: efifb will have bound to the > device first, and drm driver load is asynchronous, so there's no > guarantee i915 (or whatever) will have loaded by the time gdm starts, > and if gdm wins the race the session at best comes up unaccelerated and > RANDRless with fbdev and llvmpipe, and at worst crashes when the > framebuffer handoff to i915 triggers. > > So. The workaround is to add a udev rule: > > # allow efifb / uvesafb to be a master if KMS is disabled > SUBSYSTEM=="graphics", KERNEL=="fb[0-9]", PROGRAM="/usr/bin/grep -qw nomodeset /proc/cmdline", TAG+="master-of-seat" > > This says, if you asked for nomodeset, whatever fbdev device is present > is good enough to be a seat master. This doesn't handle all possible > cases. It doesn't catch the case of a user saying (for example) > i915.modeset=0, which would also disable modesetting, but that's never > what our tools write to our grub configs. It wouldn't catch the case of > using vgafb or vesafb (or any other fbdev driver) _without_ explicitly > saying nomodeset; but we ship very few such drivers, and our tools will > not give you any of the generic ones like vga or vesa by default. > > So I think this handles 90%+ of the cases we care about, certainly > enough to unblock the release. If anyone wants to polish it further, > feel free. Let me know if there's any additional insight I can provide. Wow, that sounds icky. Thanks a lot for the investigation! I agree that your workaround should be sufficient to at least fix the release-blocking case we care about (our 'nomodeset'-based "basic graphics mode" feature). It would be nice if this could be made to work for other cases where we wind up with a non-modesetting driver, as you point out, but I agree we don't need to block releases on that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-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/desktop@xxxxxxxxxxxxxxxxxxxxxxx
