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