--geometry offsets are relative to active mouse-active monitor, not entire display

[woodruffw]

This is on feh 2.14, so feel free to close it if it's been fixed since then.

I've been trying to pin a feh process on my vertical monitor using an absolute geometry:

feh --geometry 300x300+729+1504

However, this seems to cause feh to display the image on whatever monitor currently has the mouse. I've confirmed that this is the correct absolute geometry using xwininfo:

  Absolute upper-left X:  727
  Absolute upper-left Y:  1539
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 300
  Height: 300
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x20 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +727+1539  -3653+1539  -3653-81  +727-81
  -geometry 300x300+727-81

I've also tried "-geometry" at the very bottom of that output, which results in the image being loaded in the upper left corner of the active monitor.

Let me know if you need any more information; I'm happy to provide screenshots and/or recordings of the behavior.

[woodruffw]

Just realized that this is what --xinerama-index is probably for. Is there no to use just the absolute geometry?

Edit 1:

I ask because I use a single virtual screen across all of my monitors, causing --xinerama-index to have no effect.

Edit 2:

For reference, xdotool windowmove <wid> <x> <y> works correctly. I can look into how they do it and add it to feh, if desired.

Edit 3:

Their relevant code involves an XConfigureWindow call:

int xdo_move_window(const xdo_t *xdo, Window wid, int x, int y) {
  XWindowChanges wc;
  int ret = 0;
  wc.x = x;
  wc.y = y;

  ret = XConfigureWindow(xdo->xdpy, wid, CWX | CWY, &wc);
  return _is_success("XConfigureWindow", ret == 0, xdo);
}

[woodruffw]

I "fixed" a similar problem in mpv by moving the eventual moving logic below the window mapping call (XMapWindow). It seems like X11 isn't required to honor move/resize requests until after the window has been mapped, but I'm not certain about this.

In feh's case, that means taking the geometry logic out of winwidget_create_window and moving it into winwidget_show (below the XMapWindow call).