Hi folks!
So at last week's Fedora 30 Beta Go/No-Go meeting, it was decided that the Basic release criterion:
"Boot menu contents
The boot menu for all supported installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer or desktop and attempting to use the generic driver."
should no longer apply to Beta - i.e. that it should no longer be a Basic or Beta criterion.
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.
For context, it is worth noting that the *feature* predates the introduction of both kernel modesetting *and* Wayland to Fedora. What the feature initially did was tell anaconda to write an X config file specifying the 'vesa' driver (instead of working out the correct 'native' driver for the adapter and writing a config file specifying that). After KMS was introduced in Fedora 10, the mechanism was tweaked to also pass the 'nomodeset' kernel parameter to disable KMS. Around 2012 (https://bugzilla.redhat.com/show_bug.cgi?id=858270) we noticed that the X config file mechanism was a bit superfluous as 'nomodeset' alone could basically be relied on to force some sort of 'fallback mechanism', and so the feature was simplified to *only* specify the 'nomodeset' kernel parameter (this is all it does now).
The *criterion* dates to 2010, in the Fedora 15 release cycle: it appears in the Fedora 15 Alpha criteria but not the Fedora 14 Alpha criteria. It was added on 2010-08-16: https://fedoraproject.org/w/index.php?title=Fedora_15_Alpha_Release_Criteria...
The group at the meeting did not, however, make any further decisions, so this leaves us with some open questions:
0) Do we generally agree with the decision made at the meeting? If anyone (especially a subject matter expert) strongly believes the decision was wrong and this should still be a Basic/Beta requirement, please say so.
1) Should the criterion be modified somehow, but some requirement in relation to some kind of fallback graphical mode be kept at Basic or Beta?
2) Should the criterion be moved to Final, unchanged or changed somehow?
3) Should the requirement just basically be dropped entirely as no longer useful?
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?
I realize this is quite a big and fuzzy topic, but I'm hoping the responses to this mail will clarify our path :) So if you have any kind of useful information or strong opinions on the general area here, please do contribute them, and hopefully a clearer way forward will emerge.
Thanks everyone!
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.
A note here: there is one specific case where 'basic graphics mode' may still be regularly needed: new NVIDIA hardware.
The device matching for Intel (i915) and AMD (amdgpu, radeon) graphics adapters is done in a very device-specific way: if you look at 'modinfo amdgpu | grep alias' you will see a ton of entries. Each of these is basically specific to a particular card - they include a PCI vendor ID and a device ID (the string 'pci:v00008086d00003E94sv*sd*bc03sc*i*', for example, means 'load this module if you see a device with vendor ID 8086, device ID 3E94, any subvendor ID, any subdevice ID, 'base class' 3 (which basically means 'graphics device'), any subclass, and any programming interface.
If you look at 'modinfo nouveau | grep alias', though, you see two lines:
alias: pci:v000012D2d*sv*sd*bc03sc*i* alias: pci:v000010DEd*sv*sd*bc03sc*i*
these basically mean 'any time you see any device with PCI vendor ID 12D2 or 10DE, load this module'.
Effectively there is a manufacturer wildcard: the nouveau module gets loaded for *any* NVIDIA graphics card at all.
This means that when a *new* graphics card comes out, one that the nouveau driver doesn't actually work with right away, when you try and boot any Linux on a system with that card, nouveau will still get loaded and *try* to work. This may not end well (though I don't have direct experience with this case, so I don't know whether there are other fallback paths or anything involved that may cope with it sometimes; ajax and airlied may be able to advise there). This is not the case for Intel or AMD cards, because they *are* matched one device at a time - when a completely new adapter comes out, it will have a new device ID, and so the module just won't load, and the system will likely automatically wind up doing more or less the same thing as happens when you boot with 'nomodeset' on a system whose adapter *is* supported.
Typically, though, the advice given to people who get stuck in this state is to use 'nomodeset' - i.e. our 'basic graphics mode'. If you poke around the usual places on the internet (Fedora forums, Q&A sites) you'll find 'try basic graphics mode if your NVIDIA card doesn't work' is quite a standard meme.
Adam Williamson composed on 2019-03-26 11:38 (UTC-0700):
To be clear, this is about DDX drivers, not kernel drivers, right? Seeing "driver" used willy nilly in discussing video issues and configuration is confusing.
...when a *new* graphics card comes out, one that the nouveau driver doesn't actually work with right away, when you try and boot any Linux on a system with that card, nouveau will still get loaded and *try* to work. This may not end well (though I don't have direct experience with this case, so I don't know whether there are other fallback paths...
Wasn't this part of the instigation for the creation of the /other/ DDX driver, the generic one that works with all the big three/four GPUs, AMD/ATI, Intel and NVidia, and maybe the minor players too, the now upstream default, the one that isn't a separate DDX package, instead included in the Xorg server package (where does it come from when running Wayland?):
modesetting?
Except for brief tests, and for hardware too old for its support, I keep /none/ of the optional DDX packages installed, relying on the modesetting DDX. Except for the bugs in downstream reports eventually leading to https://gitlab.freedesktop.org/xorg/xserver/issues/542 the modesetting DDX has been bulletproof for me.
On Tue, 2019-03-26 at 15:33 -0400, Felix Miata wrote:
Adam Williamson composed on 2019-03-26 11:38 (UTC-0700):
To be clear, this is about DDX drivers, not kernel drivers, right? Seeing "driver" used willy nilly in discussing video issues and configuration is confusing.
The mail you're replying to? No. It's about kernel drivers.
...when a *new* graphics card comes out, one that the nouveau driver doesn't actually work with right away, when you try and boot any Linux on a system with that card, nouveau will still get loaded and *try* to work. This may not end well (though I don't have direct experience with this case, so I don't know whether there are other fallback paths...
Wasn't this part of the instigation for the creation of the /other/ DDX driver, the generic one that works with all the big three/four GPUs, AMD/ATI, Intel and NVidia, and maybe the minor players too, the now upstream default, the one that isn't a separate DDX package, instead included in the Xorg server package (where does it come from when running Wayland?):
modesetting?
The clue is in the name: it only works if kernel modesetting is available. If no kernel driver is successfully providing kernel mode setting, that X driver isn't going to do anything.
On UEFI systems, there is actually a sort of generic fallback driver that provides kernel modesetting if no native kernel driver is available to do it. However, I think if nouveau loads but doesn't work, that driver gets precluded so you still don't get KMS. (I haven't checked this for sure, though).
On BIOS, on Fedora, nothing provides kernel modesetting if no 'native' kernel driver works for the hardware, AIUI. The non-native driver fallback path on BIOS is simply X.org with the 'vesa' X driver.
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
On Tue, 2019-03-26 at 16:02 -0400, Adam Jackson wrote:
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.
Well, practically speaking it is: right now we know of two bugs that affect this exact mechanism :)
https://bugzilla.redhat.com/show_bug.cgi?id=1683197 https://bugzilla.redhat.com/show_bug.cgi?id=1691909
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
My two cents:
If there's a fallback option, and if the user selects it, they shouldn't end up in an unambiguous state. Right now we're seeing systems hanging. I'd rather see a crash than a hang where the user can't get to a shell, and sees no useful information on the screen that tells them why they're hung up; or even generically that "by now you should see a login screen and if you don't we've faceplanted somewhere, sorry".
Maybe split the criterion:
Basic criterion: installation media must have a basic video boot entry that uses the accepted fallback boot parameter(s), e.g. nomodeset. The criterion just means the media must have the menu entry, and that it passes something intentional for this purpose as a boot parameter.
Final criterion: installation media's basic video boot entry should either work (we get a successful graphical boot), or it should faceplant in some unambiguous way.
If it's not possible to ensure basic video either works as intended or faceplants unambiguously; then I suggest dropping any beta or final criterion. And also I wonder if it's at all useful to include some kind of heads up description for the basic video boot entry? Like, "this may not work at all" or "wait 5 minutes for graphical boot, after 10 minutes assume it failed". Haha - I have no idea. Just something so they aren't waiting around going WTF? Now what?
-- Chris Murphy
On Tue, Mar 26, 2019 at 9:31 PM Chris Murphy lists@colorremedies.com wrote:
My two cents:
If there's a fallback option, and if the user selects it, they shouldn't end up in an unambiguous state. Right now we're seeing systems hanging. I'd rather see a crash than a hang where the user can't get to a shell, and sees no useful information on the screen that tells them why they're hung up; or even generically that "by now you should see a login screen and if you don't we've faceplanted somewhere, sorry".
Maybe split the criterion:
Basic criterion: installation media must have a basic video boot entry that uses the accepted fallback boot parameter(s), e.g. nomodeset. The criterion just means the media must have the menu entry, and that it passes something intentional for this purpose as a boot parameter.
Sounds good.
Final criterion: installation media's basic video boot entry should either work (we get a successful graphical boot), or it should faceplant in some unambiguous way.
I'd rather require it to just work. Based on Ajax's response that the code path is here to stay and they still need to support it because of VMs and fresh new graphics cards.
On Tue, 2019-03-26 at 14:30 -0600, Chris Murphy wrote:
My two cents:
If there's a fallback option, and if the user selects it, they shouldn't end up in an unambiguous state. Right now we're seeing systems hanging. I'd rather see a crash than a hang where the user can't get to a shell, and sees no useful information on the screen that tells them why they're hung up; or even generically that "by now you should see a login screen and if you don't we've faceplanted somewhere, sorry".
Maybe split the criterion:
Basic criterion: installation media must have a basic video boot entry that uses the accepted fallback boot parameter(s), e.g. nomodeset. The criterion just means the media must have the menu entry, and that it passes something intentional for this purpose as a boot parameter.
Final criterion: installation media's basic video boot entry should either work (we get a successful graphical boot), or it should faceplant in some unambiguous way.
If it's not possible to ensure basic video either works as intended or faceplants unambiguously; then I suggest dropping any beta or final criterion. And also I wonder if it's at all useful to include some kind of heads up description for the basic video boot entry? Like, "this may not work at all" or "wait 5 minutes for graphical boot, after 10 minutes assume it failed". Haha - I have no idea. Just something so they aren't waiting around going WTF? Now what?
So kinda aggregating all the response to this discussion, I propose we go with a modified version of Chris' proposal.
1. We retain the 'entry must exist' part of the criterion at Basic (but at that point it does not have to *work* - the idea is to ensure it's testable so we catch bugs in it at that point)
2. We move the rest of the criterion to Final and tweak it a bit to specify that it must be at least somewhat capable of reaching the installer or desktop. We do not adopt Chris' "or faceplant unambiguously" proposal, people seemed to prefer just requiring it to work.
So, here's the specific text I propose. At Basic we would change this requirement:
"The boot menu for all supported installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa'). This mechanism should work correctly, launching the installer or desktop and attempting to use the generic driver."
To read only:
"The boot menu for all release-blocking installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa')."
i.e. remove the second sentence (and change 'supported' to 'release- blocking' - that is a better form of words that should have been used all along).
At Final we would add this requirement:
"The generic video driver option ('basic graphics mode') on all release-blocking installer and live images must function as intended (launching the installer or desktop and attempting to use a generic driver), and there must be no bugs that clearly prevent the installer or desktop from being reached in this configuration on all systems or on wide classes of hardware."
How does that sound to everyone? Thanks!
On Mon, Apr 1, 2019 at 3:04 PM Adam Williamson adamwill@fedoraproject.org wrote:
So, here's the specific text I propose. At Basic we would change this requirement:
<DELETIA>
To read only:
"The boot menu for all release-blocking installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa')."
This seems reasonable to me. +1
At Final we would add this requirement:
"The generic video driver option ('basic graphics mode') on all release-blocking installer and live images must function as intended (launching the installer or desktop and attempting to use a generic driver), and there must be no bugs that clearly prevent the installer or desktop from being reached in this configuration on all systems or on wide classes of hardware."
Am I correct in my interpretation that this failing on a narrow set of hardware or configurations would NOT be considered a blocker?
On Mon, Apr 1, 2019 at 9:04 PM Adam Williamson adamwill@fedoraproject.org wrote:
"The boot menu for all release-blocking installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa')."
Maybe change "causes" to "attempts", so that it's clear it has to do something (e.g. add a kernel cmdline option), but the thing doesn't have to succeed ("causes" sounds to me like a successful attempt). But perhaps that's just me not being a native speaker, though.
i.e. remove the second sentence (and change 'supported' to 'release- blocking' - that is a better form of words that should have been used all along).
At Final we would add this requirement:
"The generic video driver option ('basic graphics mode') on all release-blocking installer and live images must function as intended (launching the installer or desktop and attempting to use a generic driver), and there must be no bugs that clearly prevent the installer or desktop from being reached in this configuration on all systems or on wide classes of hardware."
Here I'd probably remove "attempting" in favor of a stricter "using a generic driver". But even your version sounds ok.
On Tue, Apr 2, 2019 at 4:19 AM Kamil Paral kparal@redhat.com wrote:
On Mon, Apr 1, 2019 at 9:04 PM Adam Williamson adamwill@fedoraproject.org wrote:
"The boot menu for all release-blocking installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa')."
Maybe change "causes" to "attempts", so that it's clear it has to do something (e.g. add a kernel cmdline option), but the thing doesn't have to succeed ("causes" sounds to me like a successful attempt).
Agree.
At Final we would add this requirement:
"The generic video driver option ('basic graphics mode') on all release-blocking installer and live images must function as intended (launching the installer or desktop and attempting to use a generic driver), and there must be no bugs that clearly prevent the installer or desktop from being reached in this configuration on all systems or on wide classes of hardware."
Here I'd probably remove "attempting" in favor of a stricter "using a generic driver". But even your version sounds ok.
I agree.
On Tue, 2019-04-02 at 12:07 -0600, Chris Murphy wrote:
On Tue, Apr 2, 2019 at 4:19 AM Kamil Paral kparal@redhat.com wrote:
On Mon, Apr 1, 2019 at 9:04 PM Adam Williamson adamwill@fedoraproject.org wrote:
"The boot menu for all release-blocking installer and live images should include an entry which causes both installation and the installed system to use a generic, highly compatible video driver (such as 'vesa')."
Maybe change "causes" to "attempts", so that it's clear it has to do something (e.g. add a kernel cmdline option), but the thing doesn't have to succeed ("causes" sounds to me like a successful attempt).
Agree.
At Final we would add this requirement:
"The generic video driver option ('basic graphics mode') on all release-blocking installer and live images must function as intended (launching the installer or desktop and attempting to use a generic driver), and there must be no bugs that clearly prevent the installer or desktop from being reached in this configuration on all systems or on wide classes of hardware."
Here I'd probably remove "attempting" in favor of a stricter "using a generic driver". But even your version sounds ok.
I agree.
OK, I'm gonna go ahead and push this change out with both of Kamil's proposed changes. Thanks folks!
-
Adam Jackson -
Adam Williamson -
Adam Williamson -
Ben Cotton -
Chris Murphy -
Felix Miata -
Julen Landa Alustiza -
Kamil Paral