Great. Thank you very much.
On Tue, Mar 12, 2019 at 8:05 PM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
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
--
Lukáš Růžička
FEDORA QE, RHCE
Purkyňova 115
612 45 Brno - Královo Pole
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-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/test@xxxxxxxxxxxxxxxxxxxxxxx
