You are not logged in.
Do you
a) still have problems to use the glx backend
b) still get crashes (w/ either backend)?
Offline
a) still have problems to use the glx backend
yes I'm still getting the same error
$ picom --show-all-xerrors
[ 04/01/2024 18:42:13.325 x_log_error WARN ] X error 170 GLX_BAD_FB_CONFIG request 153 minor 0 serial 220
[ 04/01/2024 18:42:13.325 glx_init ERROR ] Failed to get GLX context.
[ 04/01/2024 18:42:13.327 initialize_backend FATAL ERROR ] Failed to initialize backend, aborting...
[ 04/01/2024 18:42:13.327 draw_callback_impl FATAL ERROR ] Pre-render preparation has failed, exiting...
b) still get crashes (w/ either backend)?
I can't use glx but with xrender it's still freezing. I installed xf86-video-intel and mesa-amber and still got a crash (with picom enabled).
I've been using it without a compositor and there has been no freezes so I guess I'll just compromise and not use a compositor. I assume replacing picom with a different one will make no difference because they're all forks of compton.
Last edited by Kasumin (2024-04-02 00:50:54)
Offline
Can you run glxgears?
Does https://wiki.archlinux.org/title/Intel_ … 915_driver allow you to use the glx backend?
Does https://wiki.archlinux.org/title/Intel_ … ccelMethod stablize xrender?
No problems when using "swrast" as DRI driver, https://wiki.archlinux.org/title/OpenGL#Installation & https://wiki.archlinux.org/title/Intel_ … ecent_GPUs (instead of "iris") - as you can see there, the main mesa offers softpipe & llvmpipe which will likely perform better than swrast - however all of them will render OpenGL on the CPU.
Offline
Can you run glxgears?
yes it runs with no issues at 50fps, in case that matters.
allow you to use the glx backend?
No, It's still giving me same error as before.
stablize xrender?
I tested it and I can't get past the startx login screen, it keeps looping.
using "swrast" as DRI driver
Same as with the accel method, I can't get past the login screen. I also tried llvmpipe and softpipe and both showed the same behavior.
Offline
I tested it and I can't get past the startx login screen, it keeps looping.
Same as with the accel method, I can't get past the login screen. I also tried llvmpipe and softpipe and both showed the same behavior.
Sounds as if X11 fails to start, but "xrender" isn't an xorg config but referred to the picom config and for "llvmpipe" "softpipe" you need mesa while swrast is (only?) available on mesa-amber
=> Do you have an xorg log from such startup failure?
Offline
Sorry I was doing it wrong.
with the drirc configuration file I still can't get the glx backend to work but the error code is a bit different this time:
picom --show-all-xerrors
[ 04/05/2024 00:14:34.217 x_log_error WARN ] X error 170 GLX_BAD_FB_CONFIG request 153 minor 0 serial 220
[ 04/05/2024 00:14:34.217 glx_init ERROR ] Failed to get GLX context.
[ 04/05/2024 00:14:34.217 initialize_backend FATAL ERROR ] Failed to initialize backend, aborting...
[ 04/05/2024 00:14:34.217 draw_callback_impl FATAL ERROR ] Pre-render preparation has failed, exiting...
With accel method uxa I got a freeze a couple minutes after starting xorg, and with swrast setup in both the intel configuration file and as an env variable I got a freeze after almost 30min. Both tests were with picom xrender enabled.
Offline
Ok, undo all of this. Install xf86-video-intel and mesa-amber (for future readers: this is on really old hardware only!) and reset the drirc.
Then post the output of "glxinfo -B" and try to run picom in glx mode, but as
LIBGL_ALWAYS_SOFTWARE=true picom --backend=glx
Offline
I undid everything until now.
This is the output of glxinfo -B before changing the variable
glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) 965GM (CL) (0x2a02)
Version: 21.3.9
Accelerated: yes
Video memory: 384MB
Unified memory: yes
Preferred profile: compat (0x2)
Max core profile version: 0.0
Max compat profile version: 2.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 2.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 965GM (CL)
OpenGL version string: 2.1 Mesa 21.3.9-arch.6 Amber
OpenGL shading language version string: 1.20
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 21.3.9-arch.6 Amber
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
This is the output after changing the variable:
glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) 965GM (CL) (0x2a02)
Version: 21.3.9
Accelerated: yes
Video memory: 384MB
Unified memory: yes
Preferred profile: compat (0x2)
Max core profile version: 0.0
Max compat profile version: 2.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 2.0
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 965GM (CL)
OpenGL version string: 2.1 Mesa 21.3.9-arch.6 Amber
OpenGL shading language version string: 1.20
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 21.3.9-arch.6 Amber
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
I still cannot use glx backend, I'm getting the same error. The variable does show up when I use "printenv".
Offline
env LIBGL_ALWAYS_SOFTWARE=true glxinfo -B
should™ not cause the second output?
env LIBGL_ALWAYS_SOFTWARE=1 glxinfo -B
https://github.com/yshui/picom/issues/165
There's still https://archlinux.org/packages/extra/x86_64/xcompmgr/ …
Offline
This is the output of the first line
env LIBGL_ALWAYS_SOFTWARE=true glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Mesa/X.org (0xffffffff)
Device: softpipe (0xffffffff)
Version: 21.3.9
Accelerated: no
Video memory: 3590MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 3.3
Max compat profile version: 3.3
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: softpipe
OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.3.9-arch.6 Amber
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 3.3 (Compatibility Profile) Mesa 21.3.9-arch.6 Amber
OpenGL shading language version string: 3.30
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 21.3.9-arch.6 Amber
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
the second line shows
env LIBGL_ALWAYS_SOFTWARE=1 glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Mesa/X.org (0xffffffff)
Device: softpipe (0xffffffff)
Version: 21.3.9
Accelerated: no
Video memory: 3590MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 3.3
Max compat profile version: 3.3
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: softpipe
OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.3.9-arch.6 Amber
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 3.3 (Compatibility Profile) Mesa 21.3.9-arch.6 Amber
OpenGL shading language version string: 3.30
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 21.3.9-arch.6 Amber
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
I'm going to try xcomp, hopefully it will be more stable.
Offline
That looks way more like it.
You can try
env LIBGL_ALWAYS_SOFTWARE=1 picom --backend=glx
but of course that'll run opengl picom on the CPU.
Offline
env LIBGL_ALWAYS_SOFTWARE=1 picom --backend=glx
It runs but so incredibly slow it's unusable. I guess the CPU just can't handle it.
I tried with xcomp and got a freeze after ~1h so I maybe I should just go without a compositor at all.
Offline