On Tue, 2019-03-26 at 11:14 -0700, Adam Williamson wrote: > The justification for this is, I hope I am correctly representing all > views here (please say so if not), that this mechanism is both less > necessary (due to a general reduction in the amount of 'weird' graphics > hardware out there, and general improvement in the reliability and > coverage of the major drivers for the major graphics hardware > manufacturers) and inherently less likely to work (due to the general > trend of work on kernel modesetting and Wayland) than it used to be.
At least in a Gnome context, the issue is that 'nomodeset' will likely leave you with efifb, and that mutter does not support (both being a wayland server and) rendering to fbdev devices, only drm devices. (This will probably soon be true for weston too; no idea what KDE does these days.) So in that scenario gdm will instead launch Xorg. Now, Xorg's not about to delete fbdev support, but this means you're exercising quite a few different paths relative to the normal Wayland session. Input devices are driven from Xorg so xinput(1) will show more interesting results, xrandr(1) will behave differently, control-center will be using a different backend, you probably won't get hidpi support working the same way, you'd expect HDR not to work once that's a thing we support at all, etc etc etc. So with the above caveat understood that "work correctly" has a bunch of asterisks next to it and you will probably be able to tell that you're using a fallback path, I don't think it's intrinsically less likely that graphics fallback would work. I might prefer that we call it "desperation" or "emergency" graphics instead of "basic", I suppose. But the support path itself is something we already want/need to keep working for the case of hardware released after the OS. I might want to see the code implementing that fallback path made cleaner, and I might wish the path weren't necessary, but. > 4) (This one mainly for ajax and airlied) to what extent does the > concept of a 'fallback option' for our supported desktop environments > and graphical servers still actually make sense? Could a different > implementation of the same basic idea be envisaged, and would it be > useful? If so, should we do that, and what would be the consequences > for the criteria? The components necessary to support fallback graphics are components we already have to support graphics in a dumb vm. I don't see that requirement going away, so I don't see much point in disabling that support for physical machines. From an implementation perspective I would certainly like to see the fallback path look more like the supported path, in that I'd like drm devices to be the only graphics abstraction, and eventually would like to stop caring about Xorg - meaning, the X server also being the display server and input server. But saying 'nomodeset' is a perfectly unambiguous way of asking for the fallback path, I don't think there's much point in requiring you to say something different on kcmdline. - ajax _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
