picom icon indicating copy to clipboard operation
picom copied to clipboard

Published 20 hours ago • verified publisher icon yshui

Virtual Box FreeBSD - picom with experimental backends fails

Open oldaccountdeadname opened this issue 4 years ago • 15 comments

Platform

FreeBSD on a VirtualBox VM with 3d acceleration

GPU, drivers, and screen setup

glxinfo -B:

name of display: 0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: VMWare, Inc. (0xffffffff)
    Device: llvmpipe (LLVM 8.0, 128 bits) (0xffffffff)
    Version: 18.3.2
    Video memory: 12800MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 3.3
    Max compat profile version: 3.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL Vendor string: VMWare, Inc.
OpenGL Renderer stirng: llvmpipe (LLVM 8.0, 128 bits)
OpenGL core profile version string: 3.3 (Core Porfile) Mesa 18.3.2
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)

OpenGL version string: 3.1 Mesa 18.3.2
OpenGL shading language version string: 1.40
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.0 Mesa 18.3.2
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00

Environment:

dwm, with gaps and autostart patches.

picom version

v7.5 - latest available in package manager

Version: v7.5

Extensions:

  • Shape: Yes
  • XrandR: Yes
  • Present: Present

Misc:

  • Use Overlay: Yes
  • Config File Used: /home/lincolna/.config/picom/picom.conf

Drivers (inaccurate):

Configuration:

vsync = false

Another github issue said that virtualbox is unable to provide vsync, and picom wouldn't run at all with it.

Steps of reproduction

  1. picom --experimental-backends --backend glx
  2. Attempt to change window focus with Mod+J,K.

Expected behavior

Window switching would work fine.

Current Behavior

Can't switch windows, mod + c closes windows correctly, and control+c stops the process.

Stack trace

Other details

oldaccountdeadname avatar Jul 06 '20 01:07 oldaccountdeadname

elaborate please what is your issue. current description says that you can't change focus with your keybindings and that sounds like a completely wm/hkd issue.

absolutelynothelix avatar Jul 14 '20 16:07 absolutelynothelix

elaborate please what is your issue. current description says that you can't change focus with your keybindings and that sounds like a completely wm/hkd issue.

Oh sorry, the window focus changes perfectly fine when picom isn't running. When it is, everything locks up. I think it's an issue with the VM though, I've never had this issue on normal hardware. Sorry for the lack of detail.

oldaccountdeadname avatar Jul 14 '20 16:07 oldaccountdeadname

have you tried anything other than changing focus? i assume screen just stopped updating for some reason (vsync may be one of them, but you have it disabled) when you started picom.

absolutelynothelix avatar Jul 14 '20 17:07 absolutelynothelix

have you tried anything other than changing focus? i assume screen just stopped updating for some reason (vsync may be one of them, but you have it disabled) when you started picom.

Opening and closing windows works, but focus just doesn't change. Oh, I just noticed it works if I don't use experimental-backends.

oldaccountdeadname avatar Jul 15 '20 15:07 oldaccountdeadname

I am running also VirtualBox and the moment i select glx as backend, everything stops working. When i restart, the windows are NOT updating anymore. I can "refresh" the screen by pressing CTRL + SHIFT + R (reload i3), but this is all i can do.

Any idea? Could be related to this issue

AskMeAgain avatar Sep 05 '20 19:09 AskMeAgain

Is there any error messages in the log?

yshui avatar Sep 06 '20 02:09 yshui

Where can i see the log?

AskMeAgain avatar Sep 06 '20 08:09 AskMeAgain

Log messages are written to stderr by default. You can specify a file to write the logs to with --log-file FILENAME.

tryone144 avatar Sep 07 '20 11:09 tryone144

I get similar behavior with i3 in Xephyr (software glx with mesa, i.e. llvmpipe) where the screen isn't updated. You actually can change focus, it just isn't reflected on the screen. Fading animations are sometimes visible and shadows depending on the focus-state are properly updated - just not the actual window content/border.

I highly suspect this is a problem with the software renderer. The log prints warnings about multiple missing extensions:

  • GLX_SGI_video_sync
  • GLX_SGI_swap_control
  • GLX_OML_sync_control
  • GLX_MESA_swap_control
  • GLX_EXT_swap_control
  • GLX_EXT_buffer_age

Can you confirm you get the same behavior?

tryone144 avatar Sep 07 '20 11:09 tryone144

I'm using kvm/qemu/virt-manager, but can confirm the behavior you mention @tryone144 . Here's a clip from my log file. I tabbed back and forth between desktops which I'm guessing is the win_bind_pixmap calls to Firefox alnd nostromo - main (my tmux session) here.

[ 03/04/2021 15:50:29.548 redirect_start DEBUG ] Redirecting the screen.
[ 03/04/2021 15:50:29.621 glx_has_extension INFO ] Missing GLX extension GLX_SGI_video_sync.
[ 03/04/2021 15:50:29.621 glx_has_extension INFO ] Missing GLX extension GLX_SGI_swap_control.
[ 03/04/2021 15:50:29.621 glx_has_extension INFO ] Missing GLX extension GLX_OML_sync_control.
[ 03/04/2021 15:50:29.621 glx_has_extension INFO ] Missing GLX extension GLX_MESA_swap_control.
[ 03/04/2021 15:50:29.621 glx_has_extension INFO ] Missing GLX extension GLX_EXT_swap_control.
[ 03/04/2021 15:50:29.621 glx_has_extension INFO ] Found GLX extension GLX_EXT_texture_from_pixmap.
[ 03/04/2021 15:50:29.621 glx_has_extension INFO ] Found GLX extension GLX_ARB_create_context.
[ 03/04/2021 15:50:29.621 glx_has_extension INFO ] Missing GLX extension GLX_EXT_buffer_age.
[ 03/04/2021 15:50:29.652 gl_has_extension INFO ] Missing GL extension GL_GREMEDY_string_marker.
[ 03/04/2021 15:50:29.652 gl_init DEBUG ] GL_VENDOR = Mesa/X.org
[ 03/04/2021 15:50:29.652 initialize_backend DEBUG ] Marking window 0x01600222 (Firefox) for update after redirection
[ 03/04/2021 15:50:29.652 initialize_backend DEBUG ] Marking window 0x03000006 (Polybar tray window) for update after redirection
[ 03/04/2021 15:50:29.652 initialize_backend DEBUG ] Marking window 0x03000000 ((null)) for update after redirection
[ 03/04/2021 15:50:29.652 initialize_backend DEBUG ] Marking window 0x00400017 (nostromo - main) for update after redirection
[ 03/04/2021 15:50:29.652 initialize_backend DEBUG ] Marking window 0x004002b8 (polybar-top_Virtual-1) for update after redirection
[ 03/04/2021 15:50:29.652 atom_getter DEBUG ] Atom _XROOTPMAP_ID is 363
[ 03/04/2021 15:50:29.653 glx_find_fbconfig DEBUG ] Looking for FBConfig for RGBA8880, depth 24
[ 03/04/2021 15:50:29.655 glx_bind_pixmap DEBUG ] depth 24, rgba 0
[ 03/04/2021 15:50:29.664 redirect_start DEBUG ] Screen redirected.
[ 03/04/2021 15:50:29.664 _draw_callback DEBUG ] Re-run _draw_callback
[ 03/04/2021 15:50:29.664 handle_pending_updates DEBUG ] Delayed handling of events, entering critical section
[ 03/04/2021 15:50:29.664 ev_handle DEBUG ] event  MapNotify serial 0x0000015c window 0x0000005c "(Overlay)"
[ 03/04/2021 15:50:29.664 ev_handle DEBUG ] event     Expose serial 0x0000015c window 0x0000005c "(Overlay)"
[ 03/04/2021 15:50:29.664 win_bind_pixmap DEBUG ] New named pixmap for 0x01600222 (Firefox) : 0x02600038
[ 03/04/2021 15:50:29.664 glx_find_fbconfig DEBUG ] Looking for FBConfig for RGBA8880, depth 24
[ 03/04/2021 15:50:29.667 glx_bind_pixmap DEBUG ] depth 24, rgba 0
[ 03/04/2021 15:50:29.667 win_clear_flags DEBUG ] Clear flags 2 from window 0x01600222 (Firefox)
[ 03/04/2021 15:50:29.667 win_clear_flags DEBUG ] Clear flags 9 from window 0x01600222 (Firefox)
[ 03/04/2021 15:50:29.667 win_bind_pixmap DEBUG ] New named pixmap for 0x03000006 (Polybar tray window) : 0x0260003c
[ 03/04/2021 15:50:29.667 glx_find_fbconfig DEBUG ] Looking for FBConfig for RGBA8880, depth 24
[ 03/04/2021 15:50:29.670 glx_bind_pixmap DEBUG ] depth 24, rgba 0
[ 03/04/2021 15:50:29.670 win_clear_flags DEBUG ] Clear flags 2 from window 0x03000006 (Polybar tray window)
[ 03/04/2021 15:50:29.670 win_clear_flags DEBUG ] Clear flags 9 from window 0x03000006 (Polybar tray window)
[ 03/04/2021 15:50:29.670 win_bind_pixmap DEBUG ] New named pixmap for 0x03000000 ((null)) : 0x02600040
[ 03/04/2021 15:50:29.670 glx_find_fbconfig DEBUG ] Looking for FBConfig for RGBA8880, depth 24
[ 03/04/2021 15:50:29.673 glx_bind_pixmap DEBUG ] depth 24, rgba 0
[ 03/04/2021 15:50:29.673 win_clear_flags DEBUG ] Clear flags 2 from window 0x03000000 ((null))
[ 03/04/2021 15:50:29.673 win_clear_flags DEBUG ] Clear flags 9 from window 0x03000000 ((null))
[ 03/04/2021 15:50:29.673 win_bind_pixmap DEBUG ] New named pixmap for 0x00400017 (nostromo - main) : 0x02600044
[ 03/04/2021 15:50:29.673 glx_find_fbconfig DEBUG ] Looking for FBConfig for RGBA8888, depth 32
[ 03/04/2021 15:50:29.675 glx_bind_pixmap DEBUG ] depth 32, rgba 1
[ 03/04/2021 15:50:29.685 win_clear_flags DEBUG ] Clear flags 2 from window 0x00400017 (nostromo - main)
[ 03/04/2021 15:50:29.685 win_clear_flags DEBUG ] Clear flags 9 from window 0x00400017 (nostromo - main)

tvjg avatar Mar 05 '21 03:03 tvjg

@tvjg did use enable use-damage in your config file?

yshui avatar Mar 05 '21 10:03 yshui

Happy to test a particular set of options and dump log if that would help @yshui . I think I did picom --config /dev/null --experimental-backends --backend glx for that run. I tried a number of different config combos around glx including use-damage and glx-no-rebind-pixmap (because it mentioned llvmpipe), but I got similar behavior everytime. No immediate corruption, but not updating either and often resulting in blank window foreground after moving focus around.

tvjg avatar Mar 05 '21 12:03 tvjg

Hmm, OK. I don't think any of the missing extensions could be causing this problem...

yshui avatar Mar 05 '21 12:03 yshui

Experiencing the same issue, running FreeBSD 13-release-p4 on a T430, with bspwm.

Picom version is vgit-ee7d9; revision hash is ee7d96101d17f3160fcb80b7aa767b75f06662ec.

glxinfo -B output

name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Mesa/X.org (0xffffffff)
    Device: llvmpipe (LLVM 10.0.1, 256 bits) (0xffffffff)
    Version: 20.2.3
    Accelerated: no
    Video memory: 8192MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 3.1
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 10.0.1, 256 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 20.2.3
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 3.1 Mesa 20.2.3
OpenGL shading language version string: 1.40
OpenGL context flags: (none)

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.2.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Steps to reproduce are the same as OP's, just running with --experimental-backends and --backend glx is enough.

I've also tried each combination of use-damage and the mark-*-focused options with no difference.

And since OP mentioned it, vsync = true also causes a crash on hardware as well as virtualbox with the following output:

[ 09/10/21 09:21:04.353 vsync_opengl_swc_init ERROR ] Failed to load a swap control extension.
[ 09/10/21 09:21:04.353 session_init FATAL ERROR ] Failed to initialize the backend

sioonhho avatar Sep 10 '21 14:09 sioonhho

I think the software renderer is not coping well with picom. Are you stuck with the software renderer?

yshui avatar Nov 16 '21 10:11 yshui