Due to the context and actual bugs, and what we see during the argues, the main idea about "work correctly" is that you should be able to launch a working desktop where typical use of some tools and specialy the installer process can be launched and executed with success.
Yeah, with caveats, a suboptimal performance, maybe with difficulties to use certain i18n options, but should be able to open a wiki and install the box.
Nowadays you just got a blank screen on a lot of hardware and we had a 100% freeze success rate on qa team wih nomodeset activated some weeks ago.
We don't have to problem to put a line on "what the hell is work correctly" now, it just doesn't work at all on a lot of typical hardware
Adam Jackson ajax@redhat.com igorleak hau idatzi zuen (2019 mar. 26, ar. 21:03):
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.
- (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
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@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/test@lists.fedoraproject.org