Thanks, Nia, for the suggestions. Unfortunately, they didn't help much.
On Sun, 29 Sep 2024 06:40:19 +0000
nia <n...@netbsd.org> wrote:
> Hi, there are several common errors that could lead to libGL not
> working.
>
> First, check the permissions on /dev/dri. RW by your user should
> be possible.
set$ ll -a /dev/dri
total 46
drwxr-xr-x 2 root wheel 512 Feb 13 2024 ./
drwxr-xr-x 10 root wheel 46080 Sep 14 10:30 ../
crw-rw---- 1 root wheel 180, 0 Mar 18 2020 card0
crw-rw---- 1 root wheel 180, 1 Mar 18 2020 card1
crw-rw---- 1 root wheel 180, 2 Mar 18 2020 card2
crw-rw---- 1 root wheel 180, 3 Mar 18 2020 card3
crw-rw---- 1 root wheel 180, 128 Feb 13 2024 renderD128
crw-rw---- 1 root wheel 180, 129 Feb 13 2024 renderD129
crw-rw---- 1 root wheel 180, 130 Feb 13 2024 renderD130
crw-rw---- 1 root wheel 180, 131 Feb 13 2024 renderD131
I'm in the wheel group, but I don't have write permission on the
directory.
> Try running the application with LIBGL_DEBUG=verbose in the environment.
> This will show some spurious warnings about .drirc (that's a red
> herring).
set$ LIBGL_DEBUG=verbose kicad
libGL: Can't open configuration file /home/tsprad/.drirc: No such file
or directory.
libGL: Can't open configuration file /home/tsprad/.drirc:
No such file or directory.
libGL: Can't open configuration
file /home/tsprad/.drirc: No such file or directory.
^C
^C
^C
^Z[1] + Stopped LIBGL_DEBUG=verbose kicad
set$ kill %1
set$
> Check the output of "glxinfo". "vendor string" should contain Intel.
set$ glxinfo | grep -i vendor
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
Vendor: Intel Open Source Technology Center (0x8086)
OpenGL vendor string: Intel Open Source Technology Center
I tried changing the permissions on the /dev/dri directory but the
behavior didn't change.
I'm going to try Tobias' suggestion to use fallback graphics.
--
Ted Spradley <tsp...@talent-free-studios.com>
