Created attachment 1755208 [details]
Xorg.0.log

I am not sure this is Mesa, from attachment 1755208 [details]:

[    32.657] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
[    32.657] (WW) Falling back to old probe method for modesetting
[    32.657] (WW) Falling back to old probe method for fbdev
...
[    32.659] (EE) open /dev/fb0: Permission denied

and then
[    32.661] (EE) Screen(s) found, but none have a usable configuration.
[    32.661] (EE) 
Fatal server error:
[    32.661] (EE) no screens found(EE) 

Switching to the "modesetting" Xorg driver allows Xorg to start.

To try, as root, create `/etc/X11/xorg.conf.d/15-modesetting.conf` to read:

----8<--------8<--------8<--------8<--------8<--------8<----
Section "Device"
	Identifier "Modesetting"
	Driver "modesetting"
	Option "AccelMethod" "glamor"
EndSection
----8<--------8<--------8<--------8<--------8<--------8<----

Then Xorg should work (it does here).

Okay, adding the file helped, but it was not needed before and I doubt every non-Wayland user should add any such, or similar, file to make his/her favourite desktop environment running. I mean, the file was not needed before some semi-recent update in rawhide, thus I consider this a regression.

One change helped in mesa (before than even gdm didn't start, see the referenced thread on the devel list). If this one is elsewhere, then I'm fine if someone knowledgeable moves it to the proper product.

(In reply to Milan Crha from comment #3)
> Okay, adding the file helped, but it was not needed before and I doubt every
> non-Wayland user should add any such, or similar, file to make his/her
> favourite desktop environment running. I mean, the file was not needed
> before some semi-recent update in rawhide, thus I consider this a regression.

Sure, I am not disputing this, I'm just trying to help better understand the issue, and based on what I posted I doubt the issue is in either Mesa or Xorg itself.

> One change helped in mesa (before than even gdm didn't start, see the
> referenced thread on the devel list).

That's how I found about this bug actually.

> If this one is elsewhere, then I'm
> fine if someone knowledgeable moves it to the proper product.

I am seeing the same errors in my Xorg logs.

I might have bungled this, but after noticing this issue in one VM I specifically updated *everything but mesa* (dnf upgrade -x "mesa-*") in a second VM and everything seemed to still work, and after updating mesa there as well, things were broken too. So I'm *pretty sure* the issues were caused by the mesa 21-rc3 update.

Seems like I was wrong about ruling out mesa before.
I tried downgrading my rawhide installs to mesa-20.3.3-7.fc34 (the last mesa build on rawhide before the 21.x series update), and it did not help.

I wanted to try downgrading xorg-x11-server* packages next, but those cannot be downgraded on their own because of a new version restriction in gnome-session-wayland-session (standalone xwayland >= 1.20.99.1, probably because of the new on-demand xwayland).

I wonder if that could be a previous change in Xorg… I'll do some more testing.

So here is the deal, I think…


Forcing the install of F33 packages on my rawhide VM as follow:

  $ dnf download xorg-x11-server-Xorg-1.20.10-1.fc33.x86_64 xorg-x11-server-common-1.20.10-1.fc33.x86_64 xorg-x11-drv-qxl-0.1.5-16.fc33.x86_64
  $ sudo rpm -ivh --replacefiles --replacepkgs --nodeps --oldpackage xorg-x11-server-common-1.20.10-1.fc33.x86_64.rpm xorg-x11-drv-qxl-0.1.5-16.fc33.x86_64.rpm xorg-x11-server-Xorg-1.20.10-1.fc33.x86_64.rpm

solves the problem (but do it at your own risk, all I'm saying is that I tried and it worked for **me**).

The F33 and rawhide packages are similar except for one thing, https://src.fedoraproject.org/rpms/xorg-x11-server/c/38a777ceb5 changed support for int10 and I think that might break xorg-x11-drv-qxl which was rebuilt as part of the mass rebuild.

Reverting the change in xorg is probably not sufficient (I tried), one needs to also rebuild the qxl driver as well with the changes xorg-x11-server build.

@ajax, am I making any sense?

So it looks like I was wrong in comment 8, xorg-x11-server is unrelated, downgrading *only* xorg-x11-drv-qxl fixes the issue

Funny fact is with the older version we also get those errors:

[ 82874.313] (WW) Falling back to old probe method for modesetting
[ 82874.313] (WW) Falling back to old probe method for fbdev
…
[ 82874.314] (EE) open /dev/fb0: Permission denied
[ 82874.314] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support


But the qxl driver works nevertheless so those errors seem also unrelated.

This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

On further investigation, I was right in comment 8, that's actually the removal of DRI1 support in https://src.fedoraproject.org/rpms/xorg-x11-server/c/38a777ceb5 which breaks the qxl driver.

As a test, I re-enabled DRI1 support in xorg-x11-server and rebuilt xorg-11-rv-qxl against that package and the qxl driver now works.

To test, you can try those builds: https://ofourdan.fedorapeople.org/bug1925423/repo/RPMS/x86_64/ (at your own risk)

I filed a PR for xorg-x11-server to re-enable DRI1 here: 
https://src.fedoraproject.org/rpms/xorg-x11-server/pull-request/9

But we also need to rebuild xorg-x11-drv-qxl against that to actually fix this issue.

(An alternative would be to drop xorg-x11-drv-qxl in F34 and rely solely on the modesettings driver)

→ Moving to xorg-x11-server.

Another alternative suggested by Michel Daenzer would be to fix the qxl driver to work without DRI1

Created attachment 1756177 [details]
Xorg logs with QXL in the non-working case

Created attachment 1756178 [details]
Xorg logs with QXL in the working case

For reference and comparison with the non-working package

xorg-x11-drv-qxl-0.1.5-19.fc34 should fix this

Awesome, can confirm that it fixes LightDM, GNOME on Xorg, and Pantheon session.

(In reply to Adam Jackson from comment #17)
> xorg-x11-drv-qxl-0.1.5-19.fc34 should fix this

Thanks, that works for me too. I guess just build it also for the rawhide (f35) and you are done.

*** Bug 1927254 has been marked as a duplicate of this bug. ***

Since FEDORA-2021-07d515076e contains a candidate fix, setting this bug to ON_QA.

Can affected folks please confirm the fix in current F34? -19.fc34 made the most recent compose, so if it works, we can close this.

I have tested the -19.fc34 build on F34 and it works fine.
The package is still missing a build for f35 though.
Looks like it was built during the f34 mass branching and only landed in the f34 tag and not in the f35 tag.

okay I've built the rawhide package, should be possible to close now.

I can confirm an update from
   xorg-x11-drv-qxl-0.1.5-18.fc34
to
   xorg-x11-drv-qxl-0.1.5-19.fc35
allowed me to log in to the "GNOME on Xorg" session.

I wonder if bug 1933637 can be related, seen also with xorg-x11-drv-qxl-0.1.5-19.fc35