Disabling/enabling monitor does not call RandRFunc #825
Comments
|
Yes. I'm sure when I last looked into this, using xrandr --off isn't the same thing as yanking an HDMI cable out the back of the monitor... |
|
Ah, ok. I was trying to debug a multimonitor-problem and thought it would be easier to run an xrandr-command than to reach under the table to yank the cable. After actually trying to unplug/replug the cable I should maybe describe the original problem I had: The problem I'm trying to solve is to automatically move FvwmButtons to the currently primary monitor.
I'm using autorandr to reconfigure which monitor is primary, based on if the external monitor is plugged in or not. So in summary the actual issue is that RandRFunc is not called when autorandr reconfigures the screens, including changing the primary screen. So if fvwm can't do this I might have to find another way. Or perhaps functionality to detect randr's changing of primary screen could be implemented in fvwm somehow? |
|
I'll look into it. |
Track which monitors hold the current primary bit, and the monitor which
used to have it.
This is sometimes useful to infer when the primary status of a monitor
has changed, and which monitor it is now, and which monitor it used to
be.
For example:
DestroyFunc RandRFunc
AddToFunc RandRFunc
+ I Echo "Primary is: $[monitor.primary], previous: $[monitor.prev_primary]"
Fixes #825
|
Have a look at the To your earlier observations, I was remembering correctly. If you use |
|
Your patch works fine when executing the xrandr-commands manually. But annoyingly enough not when letting autorandr handle the monitors. I think I traced autorandr's behaviour to the following. At least I get the same end result: (HDMI-1 is my external monitor and DP-1 internal)
End result: RandrFunc is not called when setting primary in the last step. Maybe because the HDMI monitor has been turned off and fvwm cannot keep track of it anymore? These steps works as expected. And will cause RandRFunc to be called when setting primary:
|
Yup. |
|
Ok, but how about ignoring which other monitor was primary, and just check if the monitor in question was not primary. Like this: diff --git a/fvwm/events.c b/fvwm/events.c
index 1ae159fa..10218213 100644
--- a/fvwm/events.c
+++ b/fvwm/events.c
@@ -1855,12 +1855,7 @@ monitor_emit_broadcast(void)
}
if (m->flags & MONITOR_PRIMARY) {
- struct monitor *pm = m, *mnew;
-
- if ((mnew = monitor_by_last_primary()) == NULL)
- break;
-
- if (pm != mnew) {
+ if (m->flags & MONITOR_PRIMARY && !m->was_primary) {
execute_function_override_window(
NULL, NULL, randrfunc, NULL, 0, NULL);
} |
|
Perhaps. This is already an ugly hack as it is. At least my version mirrors other variables where there's a previous state. |
Track which monitors hold the current primary bit, and the monitor which
used to have it.
This is sometimes useful to infer when the primary status of a monitor
has changed, and which monitor it is now, and which monitor it used to
be.
For example:
DestroyFunc RandRFunc
AddToFunc RandRFunc
+ I Echo "Primary is: $[monitor.primary], previous: $[monitor.prev_primary]"
Fixes #825
Upfront Information
Fvwm3 version: fvwm3 1.0.7 (1.0.6a-8-g2327aac1)
Linux distribution or BSD name/version: Debian 11.6 Bullseye
Platform (run:
uname -sp): Linux unknownExpected Behaviour
I expected RandRFunc to trigger when connecting/disconnecting a monitor. Basically on
xrandr --output HDMI-1 --offandxrandr --output HDMI-1 --auto.Actual Behaviour
The RandRFunc is not triggered.
FvwmEvent's
monitor_enabled/monitor_enabledfunctions are also not triggered.RandRFunc is called correctly on resolution and position change (for example
xrandr --output HDMI-1 --right-of DP-1)Steps to Reproduce
I'm using this minimal configuration file:
Then executing
xrandr --output HDMI-1 --autofollowed byxrandr --output HDMI-1 --offgives the following output in the log, but "randrfunc called" is not logged.The text was updated successfully, but these errors were encountered: