Open bolshoytoster opened 1 year ago
I can confirm that I'm experiencing the same issue seemingly at random while using Firefox version 110.0
probably a good idea to include the versions of ffplay
and bspwm
for people trying to reproduce this issue (which i cannot do). also, are you playing the same file before and after running the winit test?
seems curious that you say ffplay should float by default - that is not really the case. you can cause sdl2 to create a fixed size window by starting ffplay with -noborder
. might be useful to include the xprop output of the ffplay windows in both states.
@ortango
probably a good idea to include the versions of ffplay and bspwm for people trying to reproduce this issue
$ ffplay -version
ffplay version 4.4.2-0ubuntu0.22.04.1 Copyright (c) 2003-2021 the FFmpeg developers
built with gcc 11 (Ubuntu 11.2.0-19ubuntu1)
configuration: --prefix=/usr --extra-version=0ubuntu0.22.04.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --enable-pocketsphinx --enable-librsvg --enable-libmfx --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared
libavutil 56. 70.100 / 56. 70.100
libavcodec 58.134.100 / 58.134.100
libavformat 58. 76.100 / 58. 76.100
libavdevice 58. 13.100 / 58. 13.100
libavfilter 7.110.100 / 7.110.100
libswscale 5. 9.100 / 5. 9.100
libswresample 3. 9.100 / 3. 9.100
libpostproc 55. 9.100 / 55. 9.100
$ bspwm -v
0.9.10
also, are you playing the same file before and after running the winit test?
Yes, but this occurs with any file for me.
seems curious that you say ffplay should float by default - that is not really the case.
That might be the issue. After running bspc rule -a ffplay state=floating
, the window spawns floating.
I still think it's odd that it spawns floating on boot but stops after opening certain windows.
might be useful to include the xprop output of the ffplay windows in both states.
Before (floating):
_NET_WM_USER_TIME(CARDINAL) = 481780
_VARIABLE_REFRESH(CARDINAL) = 1
_NET_WM_DESKTOP(CARDINAL) = 0
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
XdndAware(ATOM) = BITMAP
_NET_WM_NAME(UTF8_STRING) = "something - something.mp4"
WM_NAME(STRING) = "something - something.mp4"
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING
_NET_WM_BYPASS_COMPOSITOR(CARDINAL) = 1
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_PID(CARDINAL) = 2593
WM_LOCALE_NAME(STRING) = "C"
WM_CLASS(STRING) = "ffplay", "ffplay"
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
window id # of group leader: 0x243667f1
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 640, 300
WM_CLIENT_MACHINE(STRING) = "0"
WM_TRANSIENT_FOR(WINDOW): window id # 0x79e
After (tiled):
_VARIABLE_REFRESH(CARDINAL) = 1
_NET_WM_DESKTOP(CARDINAL) = 0
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
XdndAware(ATOM) = BITMAP
_NET_WM_NAME(UTF8_STRING) = "something - something.mp4"
WM_NAME(STRING) = "something - something.mp4"
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING
_NET_WM_BYPASS_COMPOSITOR(CARDINAL) = 1
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_PID(CARDINAL) = 3205
WM_LOCALE_NAME(STRING) = "C"
WM_CLASS(STRING) = "ffplay", "ffplay"
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
window id # of group leader: 0x5384f155
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 640, 300
WM_CLIENT_MACHINE(STRING) = "0"
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x1, 0x0, 0x0
Diff:
1d0
< _NET_WM_USER_TIME(CARDINAL) = 481780
13c12
< _NET_WM_PID(CARDINAL) = 2593
---
> _NET_WM_PID(CARDINAL) = 3205
18c17
< window id # of group leader: 0x243667f1
---
> window id # of group leader: 0x5384f155
22c21
< WM_TRANSIENT_FOR(WINDOW): window id # 0x79e
---
> _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x1, 0x0, 0x0
_NET_WM_USER_TIME
i believe that sdl will update that property on button and key events (should be unset until the first event), so maybe that is a red herring - you can double check just to make sure.
peeking at sdl's source some more, it looks like motif hints and transient for are tied together (SetWindowBordered()
). i wonder if transientfor is getting set and then unset by the time you check it with xprop? you can use external_rules_script to check xprop of a window before bspwm maps it - you might catch it there.
apologies for a third edit.
not sure how i missed
WM_TRANSIENT_FOR(WINDOW): window id # 0x79e
that explains it. check the above second edit, the sdl function i refer too, and rule.c's _apply_transient()
function.
refs
I like to have ffplay windows floating, which looks to be the default, and works perfectly fine most of the time.
Unfortunately, I've found that after starting a winit window (or even firefox in some cases), ffplay windows will open tiled instead, andd I'll have to restart bspwm.
You could reproduce this (with an empty
bspwmrc
) if you have cargo installed:I've also been able to reproduce this occasionally by running firefox.