fvwm3
fvwm3 copied to clipboard
fvwmorg
FvwmEvent event monitor_focus broken in FVWM3 1.0.4
Thanks for reporting your bug here! The following template will help with giving as much information as possible so that it's easier to diagnose and fix.
Upfront Information
FvwmEvent monitor_focus event does not get triggered when pointer crosses monitors.
- Fvwm3 version (run:
fvwm3 --version)
FVWM3 1.0.4
-
Linux distribution or BSD name/version
-
Platform
Linux x86_64
Expected Behaviour
FvwmEvent emits monitor_focus event when needed. This can be checked with a simple Echo function.
Actual Behaviour
None.
- Does the problem also happen with Fvwm2?
N/A
Does Fvwm3 crash?
No.
Hi @NsCDE
Hmm -- this seems to be working for me...
Here's an example:
DestroyModuleConfig FEn:*
*FEn: monitor_focus Echo $[monitor.current]
Module FvwmEvent FEn
Then in a separate terminal:
echo "set echo" | nc -U $FVWMMFL_SOCKET
Then I start to shift focus between monitors, I see output such as this:
% echo "set echo" | nc -U $FVWMMFL_SOCKET
{"connection_profile":{"version":"1.0.5","version_info":"1.0.4-20-g1d38a7f94"}}
{"echo":{"message":"DisplayPort-2"}}
{"echo":{"message":"DisplayPort-4"}}
{"echo":{"message":"DisplayPort-2"}}
{"echo":{"message":"DisplayPort-4"}}
{"echo":{"message":"DisplayPort-2"}}
{"echo":{"message":"HDMI-A-0"}}
{"echo":{"message":"DisplayPort-4"}}
{"echo":{"message":"DisplayPort-2"}}
{"echo":{"message":"DisplayPort-4"}}
Can you provide more details so I can break it?
Hi @ThomasAdam
Strange. I tried this with nc on $FVWMMFL_SOCKET and it does not work for me. Last time, I was watching in log file opened (Watch Errors in NsCDE). This time I have opened FVWMMFL_SOCKET like this (nc on Linux Fedora 33 VM):
echo "set echo" | nc --no-shutdown -U $FVWMMFL_SOCKET
Put in /opt/NsCDE/config/NsCDE-Event.conf at the end:
*MainLoop: monitor_focus Echo $[monitor.current]
Then shifted focus between monitors and nothing appears on output.
Generally output works. If I make FvwmCommand 'Echo Hello $[monitor.current]' at another terminal, I get the output on nc:
$ echo "set echo" | nc --no-shutdown -U $FVWMMFL_SOCKET {"connection_profile":{"version":"1.0.4","version_info":"released"}} {"echo":{"message":"Hello Virtual-0"}}
To reproduce? Hm ...
You probably have some NsCDE VM around. Try to fetch current master and update ./Installer.ksh -f -n -u and then edit /opt/NsCDE/config/NsCDE-Event.conf, put monitor_focus line, restart FVWM3 and see how it behaves.
For me, it really does not do anything, while ordinary Echo from FvwmCommand, and the rest of events from FvwmEvent (same instance) works.
EDIT: I was in per-monitor mode.
Breaking news (tm):
If I switch monitors by other means (for example Window list and click to window which is on another monitor from $[monitor.current] I get:
{"echo":{"message":"-1"}}
Even if my FvwmEvent line is:
*MainLoop: monitor_focus Echo UNIQUE TEXT BEFORE: $[monitor.current]
I hope this gives some pointer further ...
OK...
Are you able to reproduce this by using a minimal config which isn't using NsCDE? I still can't reproduce this.
Hi @ThomasAdam
This is with default-config copied into ~/.fvwm and edited like this:
--- /usr/share/fvwm/default-config/config 2019-09-05 23:14:43.000000000 +0200
+++ .fvwm/config 2021-09-03 08:33:01.004575657 +0200
@@ -46,6 +46,11 @@
# + M [Action to do on a Mouse Motion]
###########
+DestroyModuleConfig MonProbe:*
+*MonProbe: PassId
+*MonProbe: add_window Echo ADD WINDOW CALLED A B C D E F G H I J K L ...
+*MonProbe: monitor_focus Echo MONITOR FOCUS CALLED FOR $[monitor.current] on $[desk.name0] NOW A B C D E F G H ...
+
# Start Function
#
# The start function is run right after fvwm is done reading
@@ -62,6 +67,8 @@
+ I Test (Init) Module FvwmBanner
+ I Module FvwmButtons RightPanel
+ I Module FvwmEvent EventNewDesk
++ I Module FvwmMFL
++ I Module FvwmEvent MonProbe
# Mouse Bindings Functions
DestroyFunc RaiseMoveX
I had one xterm on Virtual-0 and one on Virtual-1. This is the sequence of commands:
[rjeremy@testbox9 ~]$ /opt/fvwm3/bin/FvwmCommand 'Echo hehe'
[rjeremy@testbox9 ~]$ xterm &
(moving mouse from one to other monitor and back twice)
This is the output on the socket during actions above:
{"echo":{"message":"hehe"}}
{"echo":{"message":"0x80000c"}}
{"echo":{"message":"-1"}}
{"echo":{"message":"-1"}}
{"echo":{"message":"-1"}}
{"echo":{"message":"-1"}}
As you can see, Only the first echo from FvwmCommand actually produced desired effect. Even add_window prints some hex address instead of text, which I didn't observed with NsCDE MainLoop FvwmEvent instance and finally, monitor_focus movement of mouse between monitors produces "-1". Another difference between this modified vanilla config and NsCDE is that monitor_focus in NsCDE often doesn't print event "-1" at all. Here, "-1" is printed every time.
Fedora 33, FVWM3 1.0.4 in KVM
Hi @NsCDE
Is this still a problem? For me, the following works as I would expect:
DestroyModuleConfig FEn:*
*FEn: Cmd echo
*FEn: monitor_focus "MONITOR FOCUS CALLED $[monitor.current] on $[desk.name0] NOW A B C D E F G H ..."
KillModule FvwmEvent FEn
Module FvwmEvent FEn
Hi @ThomasAdam
I have copy/pasted your example and "sourced it".
Most of the time, nothing happens while moving pointer from one to another monitor. Sometimes it prints "-1", and only if I open Workspace Menu (3rd mouse button click on the root window) on Virtual-1 and then go back to Virtual-0, I SOMETIMES get command output. Let's say once in 15-20 attempts. After some time, it starts to work for Virtual-1 (but only if I open menu anc cancel it with 1st mouse button), but never for Virtual-0.
==> /home/rjeremy/.NsCDE/tmp/fvwm.log <==
[1663570036.829507] CMD_Echo: MONITOR FOCUS CALLED Virtual-1 on One NOW A B C D E F G H ... Virtual-2
[1663570036.840141] CMD_Echo: -1
[1663570048.172315] CMD_Echo: MONITOR FOCUS CALLED Virtual-1 on One NOW A B C D E F G H ... Virtual-1
[1663570048.176930] CMD_Echo: -1
[1663570110.750324] CMD_Echo: MONITOR FOCUS CALLED Virtual-1 on One NOW A B C D E F G H ... Virtual-1
[1663570110.755675] CMD_Echo: -1
[1663570212.408560] CMD_Echo: MONITOR FOCUS CALLED Virtual-1 on One NOW A B C D E F G H ... Virtual-1
[1663570218.218504] CMD_Echo: MONITOR FOCUS CALLED Virtual-1 on One NOW A B C D E F G H ... Virtual-1
Hi @NsCDE
That's odd -- I most definitely do not see this in my testing. I wonder what other setting(s) you have which could impact this?
Hi @ThomasAdam
I have tried now with vanilla fvwm config plus FvwmMFL and your neccessary FvwmEvent test.
It behaves differently, but still erroneously.
- Focus is triggered only when some window from the new monitor gets focused
- Popping up 1st or 3rd button root menu on second monitor will discard the event, but this is not the case on 1st monitor
- Always the 1st monitor is in
$[monitor.current]no matter where I move pointer. I tried also$$[monitor.current]and$$$combinations. - What is even more interesting, and I see now this even on my previous paste from NsCDE: correct
$[monitor.current]is printed AFTER this 3 dots and one space at the end of text string!
Hi @NsCDE
Your first point is correct -- as I've mentioned, focus events for monitors can only happen on windows which are focused, not the root window.
I think the example I gave is wrong. Try this:
*FEn: monitor_focus "MONITOR FOCUS CALLED $$$$[monitor.prev] -- $$$$[monitor.current] on $$$$[desk.name0] NOW A B C D E F G H ..."
The reason you're seeing the current monitor at the end of the string, without any expansion placeholder is due to FvwmEvent sending it to the function. I'll remove that.
I do not see any messages with:
{"echo":{"message":"-1"}}
Everything is working for me as it should.
Hi @ThomasAdam
Madness of inconsitencies what I have found ...
First on vanilla fvwm3 session: It works as you described. Then I started to play a bit: I have removed echo from Cmd and put it after monitor_focus to be more similar to my Event config. What I got is only a hardcoded monitor name, but not the string with text and dynamic variables. Moreover, If I add PassID to the "FEn" config, then I get consantly only "-1", not even hardcoded monitor name.
Under NsCDE, situation is similar, except it produces any output in very rare situations: like clicking and moving mouse on monitor 2 to get root menu, then with opened root menu moving mouse to monitor 1 and clicking window (to dissapear opened menu on monitor 2 wil in ~30% cases produce some line of output. Usually with some delay. To be able to get this, I have reconfigured my MainLoop Event config to contain "Cmd Echo" like your FEn example and remove PassID. As you can see, under NsCDE $[monitor.prev] and $[monitor.current] are the same, to add insult to injury, hardcoded indicator after the string is always different from the both!
[1663616289.979581] CMD_Echo: MONITOR FOCUS CALLED Virtual-2 -- Virtual-2 on One NOW A B C D E F G H ... Virtual-1
[1663616382.513973] CMD_Echo: MONITOR FOCUS CALLED Virtual-2 -- Virtual-2 on One NOW A B C D E F G H ... Virtual-1
[1663616393.626420] CMD_Echo: MONITOR FOCUS CALLED Virtual-1 -- Virtual-1 on One NOW A B C D E F G H ... Virtual-2
[1663616448.642472] CMD_Echo: MONITOR FOCUS CALLED Virtual-2 -- Virtual-2 on One NOW A B C D E F G H ... Virtual-1
It looks to me like multiple (2-3) problems, not one. First, Lonely "Cmd" will escape string, second, PassID is the source of "-1", then on the top of all this, under NsCDE previous and current monitor are the same (when it prints anything at all), while hardcoded one after the string is always different from both - previous and current.
I hope you can get some hints and pointers from this mess. :-\
EDIT:
fvwm3 vanilla output when Echo is not in Cmd line, but after monitor_focus:
[1663617545.454689] CMD_Echo: Virtual-2
[1663617546.443375] CMD_Echo: Virtual-1
[1663617547.560705] CMD_Echo: Virtual-2
[1663617548.859618] CMD_Echo: Virtual-1
fvwm3 vanilla output when I add PassID to the FEn instance of FvwmEvent configuration:
[1663617511.351619] CMD_Echo: -1
[1663617512.863807] CMD_Echo: -1
[1663617514.347082] CMD_Echo: -1
[1663617515.628023] CMD_Echo: -1
[1663617517.258846] CMD_Echo: -1
[1663617517.877423] CMD_Echo: -1
Under vanilla fvwm3 at least it is triggered every time while focusing windows on different monitors, which is not the case under NsCDE.
Hey @NsCDE,
I still cannot get -1 -- but I suspect that could be resolved by a few commits found on ta/gh-604, if you could test that, please? Here's the config I've been using:
DestroyModuleConfig FEn:*
*FEn: monitor_focus foo
DestroyFunc foo
AddToFunc foo
+ I Echo hello WIP: "MONITOR FOCUS CALLED PREV ($$[monitor.prev]) -- CURRENT ($$[monitor.current]) on $$[desk.name0] NOW A B C D E F G H ..."
KillModule FvwmEvent FEn
Module FvwmEvent FEn
Hi @ThomasAdam
This works every time and as expected in vanilla fvwm3 even if after testing your example I add Cmd and PassID arguments in module configuration.
However, when I add another event (which knows how to handle PassID) monitor_focus becomes non-functional. Similar as in NsCDE, it will be triggered very rarely and can be forced (sometimes) with open root window menus and moving mouse to another monitor, focusing window there and clicking. New enter_window event will normally work and produce expected output (echo 0x....) Here is the configuration:
DestroyModuleConfig FEn:*
*FEn: PassID
*FEn: Cmd
*FEn: enter_window foo2
*FEn: monitor_focus foo
DestroyFunc foo
AddToFunc foo
+ I Echo hello WIP: "MONITOR FOCUS CALLED PREV ($$[monitor.prev]) -- CURRENT ($$[monitor.current]) on $$[desk.name0] NOW A B C D E F G H ..."
DestroyFunc foo2
AddToFunc foo2
+ I Echo $0
KillModule FvwmEvent FEn
Module FvwmEvent FEn
Hi @NsCDE
With your example, things continue to work exactly as they should -- I do not see any delays or missing events from either enter_window or monitor_focus.
Very strange.
Hi @NsCDE
Can you try ta/gh-604 again, please? I've added a single line to print the event options sent to fvwm to stderr -- so for you to see this, you'd need to ensure you can view fvwm's stderr.
You should see lines starting with EVENT CMD: -- I'm curious what you see with the latest FvwmEvent config we've been testing.
Hi @ThomasAdam
With only monitor_focus, it prints this:
==> .xsession-errors <==
EVENT CMD: << foo -1>>
==> .fvwm/fvwm3-output.log <==
[1663760380.422388] CMD_Echo: hello WIP: "MONITOR FOCUS CALLED PREV () -- CURRENT (Virtual-2) on Main NOW A B C D E F G H ..."
==> .xsession-errors <==
EVENT CMD: << foo -1>>
==> .fvwm/fvwm3-output.log <==
[1663760382.314492] CMD_Echo: hello WIP: "MONITOR FOCUS CALLED PREV (Virtual-2) -- CURRENT (Virtual-1) on Main NOW A B C D E F G H ..."
with enter_window AND monitor_focus, it is this:
==> .xsession-errors <==
EVENT CMD: << foo2 0x53d>>
==> .fvwm/fvwm3-output.log <==
[1663760491.911742] CMD_Echo: 0x53d
==> .xsession-errors <==
EVENT CMD: << foo2 0x800001>>
==> .fvwm/fvwm3-output.log <==
[1663760491.936734] CMD_Echo: 0x800001
==> .xsession-errors <==
EVENT CMD: << foo2 0x53d>>
==> .fvwm/fvwm3-output.log <==
[1663760491.966272] CMD_Echo: 0x53d
As you can see, monitor_focus is totally absent.
Hi @NsCDE
Yes -- you'll see -1 for monitor_* events due to them not having a window-context to operate on.
As for why you don't see any monitor_focus events with enter_focus, it's curious. I see both events just fine:
[1663766500.869797] CMD_Echo: hello WIP: "MONITOR FOCUS CALLED PREV (DP-1-2) -- CURRENT (HDMI-1) on 0 NOW A B C D E F G H ..."
[1663766529.418914] CMD_Echo: 0x100001e
[1663766529.422420] CMD_Echo: hello WIP: "MONITOR FOCUS CALLED PREV (HDMI-1) -- CURRENT (DP-1-2) on 0 NOW A B C D E F G H ..."
[1663766529.466975] CMD_Echo: 0x580001e
[1663766529.589243] CMD_Echo: 0x3e0001e
[1663766529.689037] CMD_Echo: 0x100001e
[1663766541.747723] CMD_Echo: 0x1e00006
[1663766541.754391] CMD_Echo: hello WIP: "MONITOR FOCUS CALLED PREV (DP-1-2) -- CURRENT (HDMI-1) on 0 NOW A B C D E F G H ..."
What focus policy are you using? I'm using sloppyfocus.
I'm using default fvwm config while trying to help with this. Above output was from ~/.xsession-errors and ~/.fvwm/fvwm3-output.log under vanilla fvwm - so as I see in ~/.fvwm/config it is also SloppyFocus.
Sometimes, it spits from functions foo, but very rarely, and as you can see $[monitor.prev] is lost.
==> .xsession-errors <==
EVENT CMD: << foo -1>>
==> .fvwm/fvwm3-output.log <==
[1663766923.592827] CMD_Echo: hello WIP: "MONITOR FOCUS CALLED PREV () -- CURRENT (Virtual-1) on Main NOW A B C D E F G H ..."
Then the second time (after a while trying for a minute or two):
==> .xsession-errors <==
EVENT CMD: << foo -1>>
==> .fvwm/fvwm3-output.log <==
[1663766989.906635] CMD_Echo: hello WIP: "MONITOR FOCUS CALLED PREV (Virtual-1) -- CURRENT (Virtual-2) on Main NOW A B C D E F G H ..."
... but I'm not sure I was passing from xterm on Virtual-1 to another xterm on Virtual-2, somehow it looks like something from the past. I'll try to put some PipeRead to print date.
Hmm... $[monitor.prev] will be blank if you've never focused a window on a different monitor. Just focusing the root window doesn't count, remember.
If I just use the default config, I get the same results as I've been posting -- so the behaviour for me doesn't change.
Nope. date/time is correct whenever output from foo (monitor_focus) appears. Here are both: enter_window and monitor_focus. As you can see, $[monitor.prev] is sometimes empty, altrough it has been referenced before (not a fresh session).
==> .xsession-errors <==
EVENT CMD: << foo2 0x100000e>>
EVENT CMD: << foo -1>>
==> .fvwm/fvwm3-output.log <==
[1663767407.277591] CMD_Echo: 0x100000e
[1663767407.279630] CMD_Echo: hello WIP: "MONITOR FOCUS CALLED PREV () -- CURRENT (Virtual-1) on Main NOW A B C D E F G H ..."
[1663767407.292162] CMD_Echo: Wed 21 Sep 2022 03:36:47 PM CEST
Nop it appeared two times in a row, but then nothing for subsequent 20+ moving mouse from xterm Virtual-1 to xterm Virtual-2.
==> .xsession-errors <==
EVENT CMD: << foo2 0x20000e>>
EVENT CMD: << foo -1>>
==> .fvwm/fvwm3-output.log <==
[1663767562.465409] CMD_Echo: 0x20000e
[1663767562.520678] CMD_Echo: hello WIP: "MONITOR FOCUS CALLED PREV (Virtual-1) -- CURRENT (Virtual-2) on Main NOW A B C D E F G H ..."
[1663767562.535871] CMD_Echo: Wed 21 Sep 2022 03:39:22 PM CEST
==> .xsession-errors <==
EVENT CMD: << foo2 0x53d>>
==> .fvwm/fvwm3-output.log <==
[1663767564.631040] CMD_Echo: 0x53d
==> .xsession-errors <==
EVENT CMD: << foo2 0x800001>>
==> .fvwm/fvwm3-output.log <==
[1663767564.709765] CMD_Echo: 0x800001
==> .xsession-errors <==
EVENT CMD: << foo2 0x100000e>>
EVENT CMD: << foo2 0x100000e>>
EVENT CMD: << foo -1>>
==> .fvwm/fvwm3-output.log <==
[1663767564.811602] CMD_Echo: 0x100000e
[1663767564.811955] CMD_Echo: 0x100000e
[1663767564.812566] CMD_Echo: hello WIP: "MONITOR FOCUS CALLED PREV (Virtual-2) -- CURRENT (Virtual-1) on Main NOW A B C D E F G H ..."
[1663767564.820829] CMD_Echo: Wed 21 Sep 2022 03:39:24 PM CEST
==> .xsession-errors <==
EVENT CMD: << foo2 0x53d>>
==> .fvwm/fvwm3-output.log <==
[1663767566.195137] CMD_Echo: 0x53d
==> .xsession-errors <==
EVENT CMD: << foo2 0x800001>>
==> .fvwm/fvwm3-output.log <==
[1663767566.212504] CMD_Echo: 0x800001
==> .xsession-errors <==
EVENT CMD: << foo2 0x53d>>
==> .fvwm/fvwm3-output.log <==
[1663767566.232246] CMD_Echo: 0x53d
==> .xsession-errors <==
EVENT CMD: << foo2 0x20000e>>
==> .fvwm/fvwm3-output.log <==
[1663767566.437728] CMD_Echo: 0x20000e
==> .xsession-errors <==
EVENT CMD: << foo2 0x53d>>
==> .fvwm/fvwm3-output.log <==
[1663767567.169412] CMD_Echo: 0x53d
==> .xsession-errors <==
EVENT CMD: << foo2 0x800001>>
==> .fvwm/fvwm3-output.log <==
[1663767567.212649] CMD_Echo: 0x800001
==> .xsession-errors <==
EVENT CMD: << foo2 0x53d>>
==> .fvwm/fvwm3-output.log <==
[1663767567.267828] CMD_Echo: 0x53d
==> .xsession-errors <==
EVENT CMD: << foo2 0x100000e>>
==> .fvwm/fvwm3-output.log <==
[1663767567.285886] CMD_Echo: 0x100000e
What fvwm3 version are you using?
For me:
% ./fvwm/fvwm3 --version
fvwm3 1.0.5 (1.0.4-149-g34906f73f)
rjeremy@testbox10:~$ /opt/fvwm3-master/bin/fvwm3 --version fvwm3 1.0.5 (1.0.4-136-gad9356be) with support for: ReadLine, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, XRandR, XRender, XCursor, XFT, NLS
-rwxr-xr-x 1 root root 5076392 Sep 21 13:38 /opt/fvwm3-master/bin/fvwm3
The problem is NeverFocus -- I bet if you put a window on top of the FvwmButtons instance, and used that to focus the cursor between monitors, that things start to work as expected?
Hi @ThomasAdam
Much better
Under vanilla fvwm it works now as expected with "FEn" example configuration.
But under NsCDE which has rich, real life FvwmEvent configuration, it works randomly. String in function is printed ok, but the whole thing sometimes misses to trigger, even if I work slowly. Sometimes it misses from Virtual-2 to Virtual-1, then after that there will be nothing in the next 3-4 moves between windows on different screens, then suddenly starts to work again and prints correctly for 3-4 times etc ... This happens even if I remove all events apart from new_desk and monitor_focus.
Hi @ThomasAdam
Sorry, I'm a lot out of $HOME this days and cannot react frequently.
I have adapted my "MainLoop" FvwmEvent from NsCDE for vanilla FVWM3 with simple f_foo* functions which echoes name of the event.
If you comment out enter_window, leave_window and focus_change, it will work. Adding back focus_change it will work in ~90% cases, adding back enter_window and leave_window will strangle monitor_focus, and it will appear only in 40-55% cases.
DestroyFunc f_foo0
AddToFunc f_foo0
+ I Echo new_desk
DestroyFunc f_foobar123
AddToFunc f_foobar123
+ I Echo hello WIP: "MONITOR FOCUS CALLED PREV ($$[monitor.prev]) -- CURRENT ($$[monitor.current]) on $$[desk.name0] NOW A B C D E F G H ..."
DestroyFunc f_foo1
AddToFunc f_foo1
+ I Echo new_page
DestroyFunc f_foo2
AddToFunc f_foo2
+ I Echo add_window
DestroyFunc f_foo3
AddToFunc f_foo3
+ I Echo destroy_window
DestroyFunc f_foo4
AddToFunc f_foo4
+ I Echo focus_change
DestroyFunc f_foo5
AddToFunc f_foo5
+ I Echo enter_window
DestroyFunc f_foo6
AddToFunc f_foo6
+ I Echo leave_window
DestroyFunc f_foo7
AddToFunc f_foo7
+ I Echo configure_window
DestroyFunc f_foo8
AddToFunc f_foo8
+ I Echo iconify
DestroyFunc f_foo9
AddToFunc f_foo9
+ I Echo deiconify
DestroyFunc f_foo10
AddToFunc f_foo10
+ I Echo res_class
DestroyFunc f_foo11
AddToFunc f_foo11
+ I Echo map
DestroyModuleConfig FEn:*
*FEn: PassID
*FEn: Cmd
*FEn: new_desk f_foo0
*FEn: monitor_focus f_foobar123
*FEn: new_page f_foo1
*FEn: add_window f_foo2
*FEn: destroy_window f_foo3
*FEn: focus_change f_foo4
*FEn: enter_window f_foo5
*FEn: leave_window f_foo6
*FEn: configure_window f_foo7
*FEn: iconify f_foo8
*FEn: deiconify f_foo9
*FEn: res_class f_foo10
*FEn: map f_foo11
KillModule FvwmEvent FEn
Module FvwmEvent FEn
Hi @NsCDE
That's OK -- I appreciate your help.
Despite your example configuration, and playing about with enabling and disabling {enter,leave}_window events, etc., everything works as I expect it to -- I am not seeing any missed events at all.
It's working as it should.
Hi @ThomasAdam
I have tested this on Debian 11.3, kernel 5.10.0 and X.Org X Server 1.20.11.
I will try this on fedora and some other test VMs that I have late on sunday when I'm back from trip. I'm too tired now.