Fedora Account System
Red Hat Associate
Red Hat Customer
With mesa 24.2.0 rc3/4 on F41, xvfb-run no longer works while F40 mesa 24.1.5 it works as before. Currently on rawhide (F41) I cannot build any srpm containing test programs running under X. Reproducible: Always Steps to Reproduce: 1. create simple xvfb-run-test.spec and create srpm 2. koji build --scratch f41 xvfb-run-test-0.1.src.rpm 3. koji build --scratch f40 xvfb-run-test-0.1.src.rpm Actual Results: F41: https://koji.fedoraproject.org/koji/taskinfo?taskID=121779976 ``` + xvfb-run -s '-screen 0 640x480x24' glxinfo -B + tee info.log.txt Error: couldn't find RGB GLX visual or fbconfig name of display: :99 ``` Expected Results: F40: https://koji.fedoraproject.org/koji/taskinfo?taskID=121779631 ``` + xvfb-run -s '-screen 0 640x480x24' glxinfo -B + tee info.log.txt name of display: :99 display: :99 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Mesa (0xffffffff) Device: llvmpipe (LLVM 18.1.6, 256 bits) (0xffffffff) Version: 24.1.5 Accelerated: no Video memory: 128790MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 4.5 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 ..... ``` xvfb-run-test.spec: ``` %global debug_package %nil Name: xvfb-run-test Version: 0 Release: 1%{?dist} Summary: xvfb test License: Public Domain URL: https://fedoraproject.org #Source0: BuildRequires: /usr/bin/xvfb-run BuildRequires: /usr/bin/glxinfo BuildRequires: mesa-dri-drivers #Requires: %description %prep %setup -q -c -T %build xvfb-run -s "-screen 0 640x480x24" glxinfo -B 2>&1 | tee info.log.txt grep -q "GLX_MESA" info.log.txt %install %files %changelog * Sun Aug 11 2024 Mamoru TASAKA <mtasaka> - Initial package ```
Hi, I was able to reproduce the issue locally by ssh-ing to a Fedora Rawhide VM and running "xvfb-run glxinfo -B" via when no graphical session has started yet, i.e., while in GDM. The problem doesn't seem to be related to mesa. I tested with the latest mesa (24.3.0) and the version available in Fedora 40 (24.1.5) and in both cases I'm able to reproduce the issue. Meaning that the problem is somewhere else: Latest mesa, with a Wayland session running: ---------------------- $ xvfb-run glxinfo -B name of display: :99 display: :99 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Mesa (0xffffffff) Device: llvmpipe (LLVM 18.1.8, 256 bits) (0xffffffff) Version: 24.3.0 [...] ---------------------- Latest mesa, with NO Wayland session running: ---------------------- $ xvfb-run glxinfo -B name of display: :99 Error: couldn't find RGB GLX visual or fbconfig ---------------------- mesa 24.1.5, with a Wayland session running: ---------------------- $ xvfb-run glxinfo -B name of display: :99 display: :99 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Mesa (0xffffffff) Device: llvmpipe (LLVM 18.1.8, 256 bits) (0xffffffff) Version: 24.1.5 [...] ---------------------- mesa 24.1.5, with NO Wayland session running: ---------------------- $ xvfb-run glxinfo -B name of display: :99 Error: couldn't find RGB GLX visual or fbconfig ---------------------- Maybe @ofourdan knows what could be going on?
Slightly of topic, you might be interested in xwfb-run, the Wayland version of xvfb-run. Here is an example of a package migrated to xwfb-run: https://src.fedoraproject.org/rpms/libepoxy/c/9aa9cf1ace86ee4baf6638177a0d151cc0d5e32c?branch=rawhide
I think this is https://gitlab.freedesktop.org/xorg/xserver/-/issues/1745
Right, so I think this is a an issue with access rights, when the user is not logged in graphically (hence the issue when not connected in GDM). I can reproduce here: ofourdan@fedora:~$ xvfb-run glxinfo -B name of display: :99 Error: couldn't find RGB GLX visual or fbconfig That doesn't tell much indeed. But if we run Xvfb manually, it helps: ofourdan@fedora:~$ Xvfb :12 libEGL warning: failed to open /dev/dri/card0: Permission denied libEGL warning: failed to open /dev/dri/card0: Permission denied libEGL warning: failed to open /dev/dri/card0: Permission denied And of course, we get the same error: ofourdan@fedora:~$ DISPLAY=:12 glxinfo -B name of display: :12 Error: couldn't find RGB GLX visual or fbconfig But now, we have a lead with the -EPERM error, so let's try as root: ofourdan@fedora:~sudo xvfb-run glxinfo -B name of display: :99 error: XDG_RUNTIME_DIR is invalid or not set in the environment. display: :99 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Mesa (0xffffffff) Device: llvmpipe (LLVM 18.1.8, 256 bits) (0xffffffff) Version: 24.2.1 Accelerated: no Video memory: 15985MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 4.5 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 etc. Good, so that confirms the problem is with accessing the device. The device belongs to teh group "video": ofourdan@fedora:~$ ll /dev/dri/card0 crw-rw----+ 1 root video 226, 0 Sep 2 14:08 /dev/dri/card0 Let's add myself to the group "video": ofourdan@fedora:~$ sudo usermod -a -G video ofourdan Log out, log in again, retry: ofourdan@fedora:~$ xvfb-run glxinfo -B name of display: :99 display: :99 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Mesa (0xffffffff) Device: llvmpipe (LLVM 18.1.8, 256 bits) (0xffffffff) Version: 24.2.1 Accelerated: no Video memory: 15985MB Unified memory: yes etc. So it works by adding the user to the group "video".
It's surprising that Mesa would need to access /dev/dri/card0 for llvmpipe though. Could still be a Mesa upstream issue. It would be interesting to bisect the Mesa commit which changed the behaviour.
It's probably an issue in Mesa, I agree. Also, contrary to comment 1, I cannot reproduce with Mesa 24.1 here.
Actually, I cannot even reproduce with Mesa 24.2.1 on Fedora 40, only on rawhide...
Regardless, strace shows that Mesa 24.2.1 opens the device "/dev/dri/card0" whereas Mesa 24.1.7 doesn't.
So a bisection gives: ef88af846761ca9e642f7ed46011db7d3d6b61fd is the first bad commit commit ef88af846761ca9e642f7ed46011db7d3d6b61fd (HEAD) Author: Mike Blumenkrantz <michael.blumenkrantz> Date: Tue Jul 30 12:38:24 2024 -0400 dril: always take the egl init path using EGL_DEFAULT_DISPLAY will cover the swrast case, which fixes generating all the correct configs Fixes: ec7afd2c24c ("dril: rework config creation") Reviewed-by: Eric Engestrom <eric> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30426> src/gallium/targets/dril/dril_target.c | 32 +++++++++++++------------------- 1 file changed, 13 insertions(+), 19 deletions(-) Which, I believe, matches the observation, but I don't think this is a "bug" in the sense that it does what it says on the tin.
I moved the upstream issue to Mesa for awareness, https://gitlab.freedesktop.org/mesa/mesa/-/issues/11830
I have prepared a scratch build of Mesa for rawhide with the fix from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30979 https://koji.fedoraproject.org/koji/taskinfo?taskID=122878505 I tested locally and it solves the issue for me, can you confirm as well? Note: This is a scratch build, for testing purpose, it will automatically removed in a few days, so please make sure to make a copy before it's gone!
Well, "$ xvfb-run glxinfo -B" as mockbuild user seems to work, however when I actually try rebuilding rubygem-opengl.src.rpm (this is the "real" issue I want to resolve), this time I get error like: + xvfb-run -s '-screen 0 640x480x24' ruby -e 'Dir.glob('\''test/test_*.rb'\'').each { |f| require f }' + tee TEST.log freeglut (-e): ERROR: Internal error <FBConfig with necessary capabilities not found> in function fgOpenWindow so it seems still something is wrong (not sure if it is due to mesa side or rubygem-opengl side) https://download.copr.fedorainfracloud.org/results/mtasaka/mesa-xvfb-test/fedora-rawhide-x86_64/07969241-rubygem-opengl/ On the other hand, F-40 scratch build for rubygem-opengl is successful (with F-40 mesa) https://koji.fedoraproject.org/koji/taskinfo?taskID=122883493
I tested it with the steps described in https://bugzilla.redhat.com/show_bug.cgi?id=2303995#c1 and the issue is solved.
(In reply to Mamoru TASAKA from comment #12) > […] > freeglut (-e): ERROR: Internal error <FBConfig with necessary capabilities > not found> in function fgOpenWindow > > so it seems still something is wrong (not sure if it is due to mesa side or > rubygem-opengl side) > […] > > On the other hand, F-40 scratch build for rubygem-opengl is successful (with > F-40 mesa) I suspect this could be because of "dril" which is new in Mesa 24.2, see https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28378
(In reply to Mamoru TASAKA from comment #12) > freeglut (-e): ERROR: Internal error <FBConfig with necessary capabilities > not found> in function fgOpenWindow Quick follow up, that error is coming from freeglut's X11 implementation of `fgPlatformOpenWindow()` so my take is that the dril implementation in the new Mesa 24.2 (which reduces the number of configs exposed, on purpose) somehow breaks freeglut by not exposing a FBconfig that freeglut expects. Still digging the rabbit hole… Looking for a simple reproducer using freeglut.
(In reply to Olivier Fourdan from comment #15) > Still digging the rabbit hole… Looking for a simple reproducer using > freeglut. Well, that wasn't too deep of a rabbit hole, pretty much any freeglut demo program reproduces. ofourdan@rawhide:~/src/freeglut/bin$ xvfb-run ./3dview freeglut (./3dview): ERROR: Internal error <FBConfig with necessary capabilities not found> in function fgOpenWindow
I filed https://gitlab.freedesktop.org/mesa/mesa/-/issues/11836 upstream for that
New scratch build with the fix from https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31013 available here: https://koji.fedoraproject.org/koji/taskinfo?taskID=122935714 Mind giving this new build a try?
I just tried here, it solves the issue with freeglut's demo, but rubygem-opengl test still fails, that's because it looks for a config with accumulation buffer that is not exposed with swrast in Mesa 24.2.
Created attachment 2045405 [details] Remove requirement for accumulation buffers Mesa's swrast with dril does not expose these anymore, so the tests fail trying to find a matching config. See this thread in Mesa upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11836#note_2554888
Adding attachment 2045405 [details] to rubygem-opengl should make the test work with Mesa 24.2.1 from the scratch build https://koji.fedoraproject.org/koji/taskinfo?taskID=122935714 Can you please check on your side as well?
FWIW, looks like test/test_gl_10_11.rb is the only one that uses/tests as accumulation buffer but should bail out nicely if none is available. https://github.com/drbrain/opengl/blob/master/test/test_gl_10_11.rb#L1216
(In reply to Olivier Fourdan from comment #21) > Adding attachment 2045405 [details] to rubygem-opengl should make the test > work with Mesa 24.2.1 from the scratch build > https://koji.fedoraproject.org/koji/taskinfo?taskID=122935714 > > Can you please check on your side as well? Unfortunately even with this mesa, rebuilding rubygem-opengl shows: + xvfb-run -s '-screen 0 640x480x24' ruby -e 'Dir.glob('\''test/test_*.rb'\'').each { |f| require f }' + tee TEST.log freeglut (-e): ERROR: Internal error <FBConfig with necessary capabilities not found> in function fgOpenWindow > FWIW, looks like test/test_gl_10_11.rb is the only one that uses/tests as accumulation buffer Well, all test cases have: > require 'opengl/test_case' and this is: https://github.com/drbrain/opengl/blob/master/lib/opengl/test_case.rb and so the first two lines glutInit / glutInitDisplayMode and setup function is done in any test cases anyway, and my guess is that the above "Internal error" is happening during this stage.
That's why I also posted https://bugzilla.redhat.com/show_bug.cgi?id=2303995#c20 :)
Please see this thread in Mesa upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues/11836#note_2554888 The removal of the accumulation buffers from swrast is expected, and rubygem-opengl requires them, hence the patch I posted to remove the accumulation buffer from the config in attachment 2045405 [details], a patch for rubygem-opengl.
(In reply to Olivier Fourdan from comment #24) > That's why I also posted > https://bugzilla.redhat.com/show_bug.cgi?id=2303995#c20 :) Oh, I overlooked this. Okay, now with your latest mesa scratch rpms and your patch for rubygem-opengl, I've confirmed that rubygem-opengl.src and rubygem-glu (which also uses ruby opengl/test_case) now builds successfully, thank you!
Thanks! I have posted https://src.fedoraproject.org/rpms/mesa/pull-request/53 to add both patches in Mesa downstream, now that both got merged upstream.
FEDORA-2024-bb7298426c (mesa-24.2.2-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-bb7298426c
FEDORA-2024-bb7298426c has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-bb7298426c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-bb7298426c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-bb7298426c (mesa-24.2.2-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.