Image window can unexpectedly move from non-visible desktop to current desktop

[auouymous]

I have multiple virtual desktop areas on each monitor. All xv image windows on all monitors randomly move to the current area on each monitor. It has happened a couple times when opening a new instance of xv, but usually happens when I unlock the computer in the morning. Sometimes it is everyday, but it can also go several days before moving them.

@william8000 The last hunk in 7cecc1d from #23 is causing the issue, and commenting it out eliminates the moving. I don't know why RRScreenChangeNotify would trigger when opening a new instance, nor do I know why it only triggers sometimes when the monitors powerup. An image window in a different area has coordinates that place it outside the current area, with those coordinates always being relative to the current area.

I assume that code is designed to adapt the image window to changes in monitor size. However, if that is its function, it places them half off the side of the screen in this case. Perhaps compare old dispWIDE/HIGH with new dispWIDE/HIGH, and only reposition if they changed? It also doesn't reposition the visual schnauzer window, and maybe other windows, which might also be offscreen on a smaller monitor. So I'm not entirely sure of its function.

@@ -918,11 +926,24 @@ int HandleEvent(event, donep)
     }
     break;
 
-
-
   default: break;      /* ignore unexpected events */
   }  /* switch */
 
+#ifdef HAVE_XRR
+  if (event->type == RRevent_number + RRScreenChangeNotify) {
+    XRRUpdateConfiguration(event);
+    XSync (theDisp, False);
+    xrr_event = (XRRScreenChangeNotifyEvent *)event;
+
+    screen = XRRRootToScreen(theDisp, xrr_event->window);
+
+    dispWIDE = DisplayWidth(theDisp, screen);
+    dispHIGH = DisplayHeight(theDisp, screen);
+    maxWIDE = vrWIDE = dispWIDE;  maxHIGH = vrHIGH = dispHIGH;
+    HandleDispMode();
+  }
+#endif
+
   frominterrupt = 0;
   *donep = done;
   return(retval);

[william8000]

@auouymous I took that hunk in 7cecc1d from a patch set xv-20150913-rainer-m-canavan--xrandr-support from another fork of xv. I have a laptop with only a single display, so I can't test any XRR multi-screen support except to check that it compiles.

I fed that section through chatgpt, and it suggested removing XRRUpdateConfiguration(event); because it could trigger repositioning events. Can you try that?

Otherwise, if commenting the entire sequence works for you, it is fine with me, especially if no one else has a way to test multiple monitors.

What desktop are you using? Maybe the desktop or window manager makes a difference.

[auouymous]

I fed that section through chatgpt, and it suggested removing XRRUpdateConfiguration(event); because it could trigger repositioning events. Can you try that?

Commenting that one function call did not help. It looks like HandleDispMode() might change position, but it is hard for me to comprehend the source right now. I've commented it out and will report back in a couple days.

I have a laptop with only a single display, so I can't test any XRR multi-screen support except to check that it compiles.

I don't think the event or issue is about multi-screen. Rotating the monitor or changing its resolution should also trigger the event. It might be possible to artificially generate the event with xrandr -s and the current resolution.

Just to clarify, my window manager creates a virtual resolution 7x wider and 5x taller than my monitor's actual resolution, and the monitor displays a small area of that. I believe most window managers for linux have always had this feature. If the monitor is showing the center of that virtual space, an xv window offscreen to the left has a negative X coordinate, and an xv window offscreen to the right has an X coordinate greater than the monitor's width.

It would be easy for programs or the window manager to move windows into view when switching to a smaller resolution. But switching back to the larger resolution would leave all of the windows in "squished" positions. Because of that, I would assume no programs or window managers automatically move windows.

I don't use it but I think the resizing feature shouldn't be removed. HandleDispMode() should just be fixed to not change the position.

What desktop are you using? Maybe the desktop or window manager makes a difference.

No desktop, only using e16 window manager. The event is produced by the X server and sent to the window manager and all windows. So the desktop and window manager should not make any difference.

[auouymous]

The call to HandleDispMode() is repositioning the window, as commenting it out fixed the issue.

[william8000]

@auouymous Thanks for testing that. HandleDispMode() does a lot of things. It resets everything. The main calls seem to happen during initialization, if you make an image into the root background, and on the RRScreenChangeNotify event that is giving you problems. I suspect that it is necessary in some cases. Maybe the event has additional information in a field. I'm not sure if the assignments in the #ifdef HAVE_XRR block would leave xv in an inconsistent state if HandleDispMode() isn't called. I'm not the xv maintainer, so the decision isn't mine to make, but if commenting out HandleDispMode() or the entire #ifdef HAVE_XRR block works for you, I don't have any objection.

[auouymous]

would leave xv in an inconsistent state if HandleDispMode() isn't called.

I was simply testing if that was the cause of the repositioning.

It would probably be better to have the RRScreenChangeNotify code pass a flag to HandleDispMode() and bypass the repositioning. That way the image window will still resize to fit the screen's resolution.

[william8000]

@auouymous HandleDispMode() has the sequence below. Maybe it should call GetWindowPos(&oldXwa); first and then resize and remap only if something has changed, provided that it is in that branch in HandleDispMode().

I just reread your first comment, and you considered doing that earlier inside the #ifdef HAVE_XRR block where it catches the RRScreenChangeNotify event. Maybe that is better than inside HandleDispMode().

Did you find a way to make the problem happen on demand, or is it still something that just happens randomly?

        oldXwa.width = eWIDE;  oldXwa.height = eHIGH;
        SetWindowPos(&oldXwa);
        XResizeWindow(theDisp, mainW, (u_int) eWIDE, (u_int) eHIGH);
        XMapWindow(theDisp, mainW);

[auouymous]

HandleDispMode() has the sequence below. Maybe it should call GetWindowPos(&oldXwa); first and then resize and remap only if something has changed, provided that it is in that branch in HandleDispMode().

I just reread your first comment, and you considered doing that earlier inside the #ifdef HAVE_XRR block where it catches the RRScreenChangeNotify event. Maybe that is better than inside HandleDispMode().

I didn't know how it worked when I posted my first comment, and as I said above, ...

It would be easy for programs or the window manager to move windows into view when switching to a smaller resolution. But switching back to the larger resolution would leave all of the windows in "squished" positions. Because of that, I would assume no programs or window managers automatically move windows.

... it should only resize on RRScreenChangeNotify and never change the position.

Did you find a way to make the problem happen on demand, or is it still something that just happens randomly?

Use xrandr to find supported resolutions, then use xrandr -s WIDTHxHEIGHT to change to another resolution and RRScreenChangeNotify will be generated. It sent the event the first time I ran it with current resolution, but successive runs did not generate the event, so you must alternate between resolutions to get the event more than once. I assume it forgets the resolution every couple days which is why my monitors don't produce the event everytime they wake up.

[william8000]

@auouymous My laptop has a 4k display. When I open xv on one virtual screen, then run xrandr --output eDP-1 --mode 1920x1080 ; sleep 5 ; xrandr --output eDP-1 --auto on a different virtual screen, xv remains on its original virtual screen. I have 20 virtual screens, most of them with xterms that resize when I switch to the lower resolution and don't return to their original size at the higher resolution, so it is a pain for me to test, but xv seems to have behaved reasonably. It is possible that the problem is the window manager that you are using, especially considering that it happens to you randomly. I'm not the maintainer, and I'm not comfortable submitting a patch for an issue that I can't reproduce in code that I don't completely understand. If you can identify the minimal amount of code to comment out that fixes the issue for you, maybe we could add a command line option to disable that section. One of the last xv commits added an XV_OPTIONS environment variable, so you would be able to set the special option in XV_OPTIONS in your login profile and then not worry about it.