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.

> 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
_______________________________________________
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