Xpra: Ticket #349: some parts of windows can not be clicked after changing resolutions

Here is another bug from Timo (with patch) reported as is from

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710991

Steps to reproduce:

(e.g. in gnome System->Preferences->Monitors)

Expected results: all parts of xpra windows can be accessed with mouse

Actual results: only a 640x480 pixel area in the upper left corner of each window is accessible.

More info: The only workaround I have found so far is to disconnect and reattach xpra.

The xpra server log shows how xpra continues to think that the resolution is 640x480 even after it has been set back to normal:

2013-06-03 21:25:16,371 New connection received: SocketConnection(/home/lindi/.xpra/sauna-7)
2013-06-03 21:25:16,619 Handshake complete; enabling connection
2013-06-03 21:25:16,621 Python/Gtk2 Linux client version 0.9.4 connected from 'sauna'
2013-06-03 21:25:16,621 mmap is enabled using 128MB area in /tmp/xpra.GUArsf.mmap
2013-06-03 21:25:16,621 max client resolution is 1680x1050 (from [[1680, 1050]]), current server resolution is 1024x768
2013-06-03 21:25:16,638 new resolution matching 1680x1050 : screen now set to 1680x1050
2013-06-03 21:25:16,639 setting key repeat rate from client: 500ms delay / 33ms interval
2013-06-03 21:25:16,642 keyboard mapping already configured (skipped)
2013-06-03 21:25:16,712 sending updated screen size to clients: 1680x1050 (max 5120x3200)
2013-06-03 21:25:28,471 new resolution matching 640x480 : screen now set to 640x480
2013-06-03 21:25:28,496 sending updated screen size to clients: 640x480 (max 5120x3200)


Tue, 04 Jun 2013 09:45:40 GMT - Antoine Martin: owner, status, description changed

The patch is probably not correct. There may be more than one screen, and we want to send the full display size, not just the screen that has changed.


Also, from the logs, I see that we correctly set the screen size to 1650x1050 on connection (circa 2013-06-03 21:25:16,***) and then we are notified that the screen resolution has changed (at around 2013-06-03 21:25:28,***) and we correctly update the vfb size to 640x480. But I see no trace in this log sample of the change back to 1650x1050, having the /trimmed/ client debug log would help. I would expect to see "sending updated screen size to server: WxH", twice: one for each resolution change... Unless the log is not from the test case described in the ticket?

If, for whatever reason, the root window size is not updated by the time we get our size changed event, this would help:

--- src/xpra/client/gtk2/client.py	(revision 3560)
+++ src/xpra/client/gtk2/client.py	(working copy)
@@ -176,11 +176,13 @@
                 i += 1
     def _screen_size_changed(self, *args):
-        root_w, root_h = self.get_root_size()
-        log.debug("sending updated screen size to server: %sx%s", root_w, root_h)
-        self.send("desktop_size", root_w, root_h, self.get_screen_sizes())
-        #update the max packet size (may have gone up):
-        self.set_max_packet_size()
+        def update_server():
+            root_w, root_h = self.get_root_size()
+            log.debug("sending updated screen size to server: %sx%s", root_w, root_h)
+            self.send("desktop_size", root_w, root_h, self.get_screen_sizes())
+            #update the max packet size (may have gone up):
+            self.set_max_packet_size()
+        self.idle_add(update_server)
     def get_screen_sizes(self):
         display = gdk.display_get_default()

Wed, 05 Jun 2013 04:03:04 GMT - Antoine Martin: owner, status changed

This should be fixed in r3581 but I only have a single monitor to test with (I've tried changing settings with randr), plugging new monitors in may have a different effect... so please confirm that the fix works for you (almost identical to the patch suggested in comment:1) and I will backport to v0.9.x

This is what I see as I switch to 1280x800 then back to 2560x1600:

sending updated screen size to server: 1280x800, screen sizes: [(':1.0', 1280, 800, 321, 201, [('DVI-I-1', 0, 0, 1280, 800, 646, 406)], 0, 0, 2560, 1575)]
sending updated screen size to server: 2560x1600, screen sizes: [(':1.0', 2560, 1600, 643, 402, [('DVI-I-1', 0, 0, 2560, 1600, 646, 406)], 0, 0, 1280, 775)]

Without the patch the screen size details (the long structure) would be correct but the root window size (the total area as WxY) would not as GTK would not have had time to update it yet.


Thu, 06 Jun 2013 07:59:01 GMT - onlyjob:

Reporter tried the proposed fix and confirmed that it solved the problem for him.


Thu, 06 Jun 2013 08:36:48 GMT - Antoine Martin: status changed; resolution set

thanks, now also in v0.9.x branch as of r3590


Sun, 30 Jun 2013 07:42:53 GMT - Antoine Martin: status changed; resolution deleted


Sun, 30 Jun 2013 07:43:57 GMT - Antoine Martin:

Actually, I had missed that the "workarea" parameter (_NET_WORKAREA) is also suffering from the same delay issue, only worse this time: running via idle_add is not sufficient to ensure that you will get the correct value..


Sun, 30 Jun 2013 09:02:37 GMT - Antoine Martin:

_NET_WORKAREA also fixed using a fixed delay timer of one second:


It would be best if we could just get a PropertyNotify (or as gtk calls it property-notify-event) event and fire the screen size change from there, so I am keeping this ticket open.


Tue, 16 Jul 2013 06:19:03 GMT - Antoine Martin: milestone set


Thu, 17 Oct 2013 07:28:14 GMT - Antoine Martin: status changed; resolution set

Done in r4527 - this fixes a bug with the XRootPropWatcher not firing (and there was also another bug there: r4526) but I don't like the fact that this makes all X11 gtk clients use the gtk event filter code (gdk_window_add_filter) as this is a bit heavy handed - so maybe this won't be backported to 0.10.x, or if it is maybe with a way of limiting the impact?


Thu, 30 Oct 2014 21:06:43 GMT - rainwoodman: status, version, milestone changed; resolution deleted

The problem persists on 0.14.9 if the new client has a bigger screen pixel size than the first connection to the server.


Fri, 31 Oct 2014 00:42:43 GMT - Antoine Martin: owner, status changed

Usual questions:

etc...


Sat, 01 Nov 2014 03:57:51 GMT - rainwoodman: attachment set

Server Log


Sat, 01 Nov 2014 03:58:12 GMT - rainwoodman: attachment set

Client log


Sat, 01 Nov 2014 04:04:54 GMT - rainwoodman:

I killed the server before taking xpra info.

The use case is:

  1. set resolution of my client to 800x600
  2. ssh to server, start xpra server with:

xpra start :200 --start-child='/etc/X11/xinit/Xsession gnome-terminal' --no-speaker

  1. on client, run:

xpra attach --encoding=png/P ssh:server:200 --debug=all 2> /tmp/client.log

  1. Control-C on the client
  2. set resolution of my client to 1280x800
  3. on client, run:

xpra attach --encoding=png/P ssh:server:200 --debug=all 2> /tmp/client.log

  1. drag the terminal window to the lower right corner
  2. click the menu bar of the terminal window multiple times; no response from terminal.
  3. Control-C on the client
  4. kill the server.

The Uh-oh, our size doesn't fit window sizing constraints: 735x400 vs 735x383 lines are a bit suspicious. I can rerun the case and make logs for the initial connection on the client if needed.


Sat, 01 Nov 2014 04:14:37 GMT - Antoine Martin:

Looks like the virtual screen size is adjusting as it should:

client root window size is 800x600 with 1 displays:
(..)
server virtual display now set to 800x600
(..)
client root window size is 1280x800 with 1 displays:
(..)
server virtual display now set to 1280x800

The Uh-oh lines are a bit suspicious:

Uh-oh, our size doesn't fit window sizing constraints: 735x454 vs 735x437
Uh-oh, our size doesn't fit window sizing constraints: 638x751 vs 636x742
Uh-oh, our size doesn't fit window sizing constraints: 735x436 vs 735x419
Uh-oh, our size doesn't fit window sizing constraints: 638x751 vs 636x742
Uh-oh, our size doesn't fit window sizing constraints: 735x418 vs 735x401
Uh-oh, our size doesn't fit window sizing constraints: 735x400 vs 735x383

But they normally do not affect the ability to interact with the window, at least not for the place where the menu would be, only potentially at the (usually bottom and right) edges of the window.

Questions:

FYI: for normal operation, you should be able to just start+connect in one command:

xpra start ssh:server:200 --start-child='/etc/X11/xinit/Xsession gnome-terminal' --no-speaker

Sat, 01 Nov 2014 05:52:39 GMT - rainwoodman: attachment set

Server Info at various states


Sat, 01 Nov 2014 05:53:34 GMT - rainwoodman: attachment set

Client logs at various stages


Sat, 01 Nov 2014 05:54:20 GMT - rainwoodman: attachment set

updated server log


Sat, 01 Nov 2014 05:58:59 GMT - rainwoodman:

xpra is installed from the xpra yum repository for Fedora. The distro is F19. This happens with Firefox as well, and likely also with xev (I don't remember much).

xterm is untested. I also did not test server and client on the same machine.

My server and client are from different machines, connected via ssh.

It doesn't matter if the click happens in menubar or text region. The problem is the bottom and right region that is unresponsive is too big (from pixel 800 to 1280 horizontal and from 600 to 800 vertical) I've dragged the window to the bottom right corner to demonstrate the problem better.

Seems like the coordinate of the click is clipped to a server rect that is set at the first connection.


Sat, 01 Nov 2014 15:15:35 GMT - Antoine Martin:

Another thing that would be worth having when the bug occurs is xwininfo -root -tree. Maybe the root window or our WorldWindow are not getting resized properly?


Mon, 03 Nov 2014 16:55:04 GMT - rainwoodman: attachment set

illustration with a screenshot


Mon, 03 Nov 2014 16:55:57 GMT - rainwoodman:

It appears having been resized properly.

output of xwininfo -root -tree.

The client resolution is 1280x800, and the terminal window is maximized.

I've also attached a screenshot.

[yfeng1@waterfall code]$ xwininfo -root -tree
xwininfo: Window id: 0x16d (the root window) (has no name)
  Root window id: 0x16d (the root window) (has no name)
  Parent window id: 0x0 (none)
     19 children:
     0x1400234 "Terminal": ("gnome-terminal-server" "Gnome-terminal")  154x150+236+340  +236+340
        1 child:
        0x1400235 (has no name): ()  1x1+-1+-1  +235+339
     0x400030 "Xpra-SystemTray": ()  1x1+0+0  +0+0
        1 child:
        0x400031 (has no name): ()  1x1+-1+-1  +-1+-1
     0x40002f "Xpra": ()  10x10+-100+-100  +-100+-100
     0x40002e "Xpra": ()  10x10+-100+-100  +-100+-100
     0x40002d "Xpra": ()  10x10+-100+-100  +-100+-100
     0x400026 (has no name): ()  1x1+-1+-1  +-1+-1
     0x40001e "Xpra-WorldWindow": ("Xpra" "Xpra")  1280x800+0+0  +0+0
        2 children:
        0x400022 (has no name): ()  1275x738+0+47  +0+47
           1 child:
           0x1400007 "yfeng1@waterfall:~/edison/qpm_xi/code": ("gnome-terminal-server" "Gnome-terminal")  1275x738+0+0  +0+47
              7 children:
              0x1425b47 (has no name): ()  1262x686+0+52  +0+99
              0x140242d (has no name): ()  1127x542+0+52  +0+99
              0x1402389 (has no name): ()  1127x542+0+52  +0+99
              0x140002f (has no name): ()  1127x542+0+52  +0+99
              0x1400a0b (has no name): ()  1127x560+0+52  +0+99
              0x1433459 (has no name): ()  1127x560+0+52  +0+99
              0x1400008 (has no name): ()  1x1+-1+-1  +-1+46
        0x40001f (has no name): ()  1x1+-1+-1  +-1+-1
     0x40001d "Xpra-EWMH": ()  1x1+0+0  +0+0
     0x400003 "Xpra-ManagerSelection": ()  10x10+-100+-100  +-100+-100
     0x600001 "Xpra": ("Xpra" "Xpra")  10x10+10+10  +10+10
        1 child:
        0x600002 (has no name): ()  1x1+-1+-1  +9+9
     0x400001 "Xpra": ("Xpra" "Xpra")  10x10+10+10  +10+10
        1 child:
        0x400002 (has no name): ()  1x1+-1+-1  +9+9
     0x200001 "Xpra": ("Xpra" "Xpra")  10x10+10+10  +10+10
        1 child:
        0x200002 (has no name): ()  1x1+-1+-1  +9+9
     0x142b369 "Terminal": ("gnome-terminal-server" "Gnome-terminal")  225x128+36+67  +36+67
        1 child:
        0x142b36a (has no name): ()  1x1+-1+-1  +35+66
     0x143cf1b "Terminal": ("gnome-terminal-server" "Gnome-terminal")  455x280+251+48  +251+48
        1 child:
        0x143cf1c (has no name): ()  1x1+-1+-1  +250+47
     0x14000da "Terminal": ("gnome-terminal-server" "Gnome-terminal")  118x44+745+655  +745+655
        1 child:
        0x14000db (has no name): ()  1x1+-1+-1  +744+654
     0x140000d (has no name): ()  1x1+-1+-1  +-1+-1
     0x1400003 "Terminal": ()  10x10+-100+-100  +-100+-100
     0x1400001 "Terminal": ("gnome-terminal-server" "Gnome-terminal-server")  10x10+10+10  +10+10
        1 child:
        0x1400002 (has no name): ()  1x1+-1+-1  +9+9
     0x800001 (has no name): ()  10x10+-20+-20  +-20+-20

Mon, 03 Nov 2014 16:59:35 GMT - rainwoodman:

Output from xev if I click outside of the 800x600 rect, while the xev window overlaps the 800x600 rect. Note that if the xev window is disjoint from the 800x600 rect, it doesn't receive any events at all.

MotionNotify event, serial 32, synthetic NO, window 0xe00001,
    root 0x16d, subw 0x0, time 1031293806, (146,25), root:(799,599),
    state 0x10, is_hint 0, same_screen YES
MotionNotify event, serial 32, synthetic NO, window 0xe00001,
    root 0x16d, subw 0x0, time 1031293821, (146,25), root:(799,599),
    state 0x10, is_hint 0, same_screen YES
MotionNotify event, serial 32, synthetic NO, window 0xe00001,
    root 0x16d, subw 0x0, time 1031293842, (146,25), root:(799,599),
    state 0x10, is_hint 0, same_screen YES
MotionNotify event, serial 32, synthetic NO, window 0xe00001,

Mon, 03 Nov 2014 17:15:56 GMT - rainwoodman:

In addition xrandr shows correct screen sizes (1280x800).

Screen 0: minimum 320 x 175, current 1280 x 800, maximum 8192 x 4096
default connected 1280x800+0+0 0mm x 0mm
   5120x3200     10.00
   3840x2880     10.00
   3840x2560     10.00
   3840x2048     10.00
   2048x2048     10.00
   2560x1600     10.00
   1920x1440     20.00
   1920x1200     10.00
   1920x1080     10.00
   1600x1200     10.00
   1680x1050     10.00
   1600x900      20.00
   1400x1050     75.00    60.00
   1440x900      20.00
   1280x1024     20.00
   1366x768      60.00
   1280x800      20.00*
   1024x768      25.00    20.00    87.00

Mon, 03 Nov 2014 17:21:07 GMT - rainwoodman:

But; if I run

xrandr -s 400x300

I can recover a full screen clip rect with

xrandr -s 3600x1080

But apparently this is the only one that doesn't reset it.

xrandr -s 1280x800

I may have just found a workaround.


Tue, 04 Nov 2014 08:05:18 GMT - Antoine Martin: attachment set

allows me to temporarily test different client screen sizes without actually changing anything


Tue, 04 Nov 2014 08:21:24 GMT - Antoine Martin: owner, priority, status changed

Bug, confirmed. Also noticed a problem with the dimensions reported by randr: #728.

With the patch above I can test more easily. If I set FAKE_SCREEN_SCALE = 2.0/3.0 the client reports:

screen_sizes=[(':0.0', 1706, 1066, 451, 282, [('DVI-I-1', 0, 0, 1706, 1066, 430, 270)], 0, 0, 1706, 1040)]

And the server "correctly" sets the vfb size to:

client root window size is 1706x1066 with 1 displays:
  ':0.0' (451x282 mm - DPI: 96x96) workarea: 1706x1040
    DVI-I-1 (430x270 mm - DPI: 100x100)
server virtual display now set to 1920x1080 (best match for 1706x1066)

The world window matches:

     0x40002b "Xpra-WorldWindow": ("Xpra" "Xpra")  1920x1080+0+0  +0+0

After that, if I reconnect with the correct resolution:

client root window size is 2560x1600 with 1 displays:
  ':0.0' (677x423 mm - DPI: 96x96) workarea: 2560x1560
    DVI-I-1 (646x406 mm - DPI: 100x100)
server virtual display now set to 2560x1600

The world window is OK too:

     0x40002b "Xpra-WorldWindow": ("Xpra" "Xpra")  2560x1600+0+0  +0+0

Yet the bottom and right areas are not usable! How odd!


Tue, 04 Nov 2014 09:32:47 GMT - Antoine Martin:

Tested with versions 0.7 and as far back as 0.3 (first version with xrandr support) and all have the same problem, so this is not a regression. The order doesn't matter either: connecting with the "correct" resolution first doesn't make any difference.

r8052 adds the ability to debug MotionNotify events, and with mouse debugging also turned on using:

XPRA_X11_DEBUG_EVENTS=MotionNotify xpra start -d mouse

I see:

move_pointer(1, (2440, 1146))
MotionNotify event 0x23a4 : <X11:MotionNotify \
    {'delivered_to': '0x40002b', 'send_event': 0, 'subwindow': None, 'x_root': 1919, 'type': 6, 'window': '0x40002b', \
     'is_hint': 0, 'y_root': 1079, 'state': 16, 'time': 56891491L, 'y': 1079, 'x': 1919, 'serial': '0x23a4', \
     'root': '0x44', 'display': ':10', 'same_screen': 1}>
  delivering event to window itself: 0x40002b  (signal=xpra-motion-event)
  no handler registered for window 0x40002b (None), ignoring event

So we correctly call move_pointer with the coordinates found on the client side (larger than 1920x1080), but the coordinates in the event are clipped to 1920x1080...


Tue, 04 Nov 2014 10:22:38 GMT - Antoine Martin:

OK, this looks like a bug in X11, specifically in the dummy driver. Found some links:

Looks like ConstrainCursorHarder is getting it wrong. Or maybe we need to make the dummy driver update some other data structure?

Temporary workarounds: apply one of the patches to your X11 server. (an LD_SO_PRELOAD hack would be another option here). Or use an older version. Better workarounds: maybe find a way to get the dummy driver to turn off this "feature". Best workaround: get some changes upstream..


Tue, 04 Nov 2014 17:47:39 GMT - Antoine Martin:

I have to give up for today, I've tried to modify the dummy driver to find a way to turn off the cursor bounds... There is a pScreen->ConstrainCursor.

Navigating your way around X11 data structures, macros, and header files is like doing a sack race through a minefield, blindfolded.

Here's the code I've added to the dummy driver so far:

    xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "Screen: %ix%i\n", pScrn->pScreen->width, pScrn->pScreen->height);
    int c,d;
    rrScrPrivPtr rrScrPriv = rrGetScrPriv(pScrn->pScreen);
    xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "rrScrPriv: %p\n", rrScrPriv);
    for (c = 0; c < rrScrPriv->numCrtcs; c++) {
        RRCrtcPtr crtc = rrScrPriv->crtcs[c];
        xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "crtc[%i]: %p %i outputs\n", c, &crtc, crtc->numOutputs);
        //xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "crtc[%i]: %p\n", c, &crtc);
        for (d = 0; d < crtc->numOutputs; d++) {
            xf86DrvMsg(pScrn->scrnIndex, X_ERROR, " output[%i] = %s", d, crtc->outputs[d]->name);
        }
        xf86CrtcPtr xfcrtc = crtc->devPrivate;
        xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "CRTC: %i: %p\n", c, xfcrtc);
    }

And this shows:

CRTC: 0: (nil)

The interesting bits I found:

        (*pScreen->CursorLimits) (pDev, pScreen, pSprite->current,
                                  &pSprite->hotLimits, &pSprite->physLimits);
        pSprite->confined = FALSE;
        (*pScreen->ConstrainCursor) (pDev, pScreen, &pSprite->physLimits);

Now I just need to figure out how to use them.


Tue, 04 Nov 2014 19:10:30 GMT - rainwoodman:

Thanks for looking into this.

Running xrandr after attaching can fix the clipping. I wasn't using a patched x server, so maybe there is a client side workaround in xrandr that's easier to implement? Worst case, we can simply ask the server to spawn

xrandr -s (very large resolution) after a client attaches?

I am using xrandr 1.4.2.


Wed, 05 Nov 2014 08:01:53 GMT - Antoine Martin:

So I thought that the pointer device was getting clamped wrong somehow, but as can be seen in the output using the modified dummy driver from #728, this is not the case:

[127477.517] (II) DUMMY(0): get_constant_dpi_value() found property "dummy-constant-xdpi" with value=96
[127477.517] (II) DUMMY(0): get_constant_dpi_value() found property "dummy-constant-ydpi" with value=96
[127477.517] (EE) DUMMY(0): mm(dpi 96x96)=270x193
[127477.517] (EE) DUMMY(0): Screen: 1024x730
[127477.517] (EE) DUMMY(0): rrScrPriv: 0x7fa80d1bd0f0
[127477.517] (EE) DUMMY(0): crtc[0]: 0x7ffffe626e70 0 outputs
[127477.517] (EE) DUMMY(0): CRTC: 0: (nil)
[127477.517] (EE) DUMMY(0): InputInfo: 0x827ba0
[127477.517] (EE) DUMMY(0): InputInfo.devices: 0x7fa80d2162f0
[127477.517] (EE) DUMMY(0): device=0x7fa80d2162f0
[127477.517] (EE) DUMMY(0):  enabled=1
[127477.517] (EE) DUMMY(0):  coreEvents=1
[127477.517] (EE) DUMMY(0):  spriteInfo=0x7fa80d216648
[127477.517] (EE) DUMMY(0):  pSprite[0]=0x7fa80023d010
[127477.517] (EE) DUMMY(0):  hotLimits=0,0,8192,4096
[127477.517] (EE) DUMMY(0):  physLimits=0,0,8192,4096
[127477.517] (EE) DUMMY(0): device=0x7fa80d216af0
[127477.517] (EE) DUMMY(0):  enabled=1
[127477.517] (EE) DUMMY(0):  coreEvents=1
[127477.517] (EE) DUMMY(0):  spriteInfo=0x7fa80d216e48
[127477.517] (EE) DUMMY(0):  pSprite[1]=0x7fa80023d010
[127477.517] (EE) DUMMY(0):  hotLimits=0,0,8192,4096
[127477.517] (EE) DUMMY(0):  physLimits=0,0,8192,4096
[127477.517] (EE) DUMMY(0): device=0x7fa80023da10
[127477.517] (EE) DUMMY(0):  enabled=1
[127477.517] (EE) DUMMY(0):  coreEvents=1
[127477.517] (EE) DUMMY(0):  spriteInfo=0x7fa80023dd68
[127477.517] (EE) DUMMY(0):  pSprite[2]=0x7fa80023d010
[127477.517] (EE) DUMMY(0):  hotLimits=0,0,8192,4096
[127477.517] (EE) DUMMY(0):  physLimits=0,0,8192,4096
[127477.517] (EE) DUMMY(0): device=0x7fa80023e0a0
[127477.517] (EE) DUMMY(0):  enabled=1
[127477.517] (EE) DUMMY(0):  coreEvents=1
[127477.517] (EE) DUMMY(0):  spriteInfo=0x7fa80023e3f8
[127477.517] (EE) DUMMY(0):  pSprite[3]=0x7fa80023d010
[127477.517] (EE) DUMMY(0):  hotLimits=0,0,8192,4096
[127477.517] (EE) DUMMY(0):  physLimits=0,0,8192,4096
[127477.517] (EE) DUMMY(0): device=0x7fa8002c6680
[127477.517] (EE) DUMMY(0):  enabled=1
[127477.517] (EE) DUMMY(0):  coreEvents=4
[127477.517] (EE) DUMMY(0):  spriteInfo=0x7fa8002c69d8
[127477.517] (EE) DUMMY(0):  pSprite[4]=0x7fa80023d010
[127477.517] (EE) DUMMY(0):  hotLimits=0,0,8192,4096
[127477.517] (EE) DUMMY(0):  physLimits=0,0,8192,4096
[127477.517] (EE) DUMMY(0): device=0x7fa7ffff6350
[127477.517] (EE) DUMMY(0):  enabled=1
[127477.517] (EE) DUMMY(0):  coreEvents=4
[127477.517] (EE) DUMMY(0):  spriteInfo=0x7fa7ffff66a8
[127477.517] (EE) DUMMY(0):  pSprite[5]=0x7fa80023d010
[127477.517] (EE) DUMMY(0):  hotLimits=0,0,8192,4096
[127477.517] (EE) DUMMY(0):  physLimits=0,0,8192,4096

No idea why it is getting clamped!

Found an excellent overview of X Events.

@rainwoodman: using xrandr like that is a bad idea. Menus and things will appear in areas where they shouldn't, etc. The whole point of this code is to make sure the virtual screen is the same size as the client screen.


Wed, 05 Nov 2014 08:59:13 GMT - Antoine Martin:

Ah, but wait. That's just the first time around, the second time around I do see:

(..)
[129352.831] (EE) DUMMY(0): device=0x7fdd1861c680
[129352.831] (EE) DUMMY(0):  enabled=1
[129352.831] (EE) DUMMY(0):  coreEvents=4
[129352.832] (EE) DUMMY(0):  spriteInfo=0x7fdd1861c9d8
[129352.832] (EE) DUMMY(0):  confined=0
[129352.832] (EE) DUMMY(0):  pSprite[5]=0x7fdd18863360
[129352.832] (EE) DUMMY(0):  hotLimits=0,0,1024,730
[129352.832] (EE) DUMMY(0):  physLimits=0,0,1024,730
[129352.832] (EE) DUMMY(0):  confineWin=(nil)

Working hacked dummy driver attached, will make new release of the dummy driver patch once cleaned up!


Wed, 05 Nov 2014 09:30:46 GMT - Antoine Martin: attachment set

hacked dummy driver with the geometry fix


Wed, 05 Nov 2014 13:53:27 GMT - Antoine Martin: owner, status changed

It was far from easy, but it is finally fixed! r8060 adds a patch to our build of xorg-x11-drv-xdummy, which I will submit upstream after a bit more testing - feedback welcome.

There are new RPM packages with this fix in the beta area. @rainwoodman: does that fix things for you?


Thu, 06 Nov 2014 07:06:11 GMT - Antoine Martin: owner changed

@afarr: you should be able to reproduce by connecting a low-res client, then bumping up the resolution on the client. With the unpatched dummy driver, parts of the windows in the newly expanded area (bottom and right) will not respond to clicks. With the patched dummy, everything should work as expected.


Fri, 07 Nov 2014 20:12:51 GMT - rainwoodman:

I think I am still seeing this with the beta RPM on the server.

I'll dig a bit and post another update later. I didn't update the client -- is it relavant?

rpm -q xpra
xpra-0.15.0-1.fc20.x86_64
rpm -a -q|grep dummy
xorg-x11-drv-dummy-0.3.6-13.fc20.x86_64

Sat, 08 Nov 2014 02:45:43 GMT - Antoine Martin:

I didn't update the client -- is it relavant?


No, the client version doesn't matter.

xorg-x11-drv-dummy-0.3.6-13.fc20.x86_64


Ah, the release number in the beta area is lower than the one in the regular repo (for whatever reason), sorry. So you will have to "downgrade" by hand to install the patched one (xorg-x11-drv-dummy-0.3.6-11.xpra3.fc20.x86_64.rpm)

Edit: I've bumped the packages again, so the new beta builds should now "upgrade" the regular one.


Mon, 10 Nov 2014 04:35:38 GMT - rainwoodman:

Well, I can click any where on the screen now! But here is one more issue. The popup menu created is still clipped to the original 800x600 rect! (i'll attach an image)


Mon, 10 Nov 2014 04:38:20 GMT - rainwoodman: attachment set

location of popup menus


Mon, 10 Nov 2014 04:41:36 GMT - rainwoodman:

I know that GtkMenu will query Gdk to find the size of the current screen before placing the menu, to make sure it is always at a visible location.

Thus somehow the change in screen size up on reconnection is not properly propagated to GdkScreen. I know GDK is defintely aware of dynamically changing the monitor size. So this is really getting somewhat puzzling.

I can dig a bit what event Gdk is waiting for (some time next week).

EDIT: GDK just calls WidthOfScreen and HeightOfScreen to get the screen sizes! (in gdkx11screen.c).


Mon, 10 Nov 2014 21:35:17 GMT - alas:

Odd... testing with windows clients (windows 7 or 8.1) I can't seem to reproduce this at all.

With osx, however, I was able to reproduce with 0.15.0 r7865 against that same fedora 20 0.15.0 r7865 server.

Unfortunately, I'm still able to reproduce it with 0.15.0 r 8096 clients against a fedora 20 0.15.0 r8072 server (switching DPI on retina laptop from 1024x640 up to 1280x800 ... with the adjusting DPI clearly captured in client-side output).

OpenGL vs. no OpenGL (unsurprisingly) has no impact. I tested using youtube (lots of clickables) with a variety of browsers... adjusting DPI upward invariably made the whole bottom of the window non-interactable (left bottom corner as well as right bottom corner) - despite the fact that the changing DPI seemed to be scaled in order to display apparently the same content before and after DPI adjustment. (I have screenshots if that would be of any use).

I wasn't able to repro anything with the popup menus, since the bottom portion of the window was apparently so non-responsive that right clicking didn't produce any popup menu at all (using the two-finger trac pad... in fact, while the cursor was over the non-responsive portions of the window, the pad wouldn't allow scrolling, left-clicking, right-clicking, or any other interaction).

Let me know if there's any debugging flag that might be of use, perhaps to compare the windows vs. osx?


Mon, 10 Nov 2014 22:11:33 GMT - rainwoodman:

Hi affar, This seems to be really an issue with the X server on the server. Did you install the patched Xdummy server:

xorg-x11-drv-dummy-0.3.6-11.xpra3.fc20.x86_64.rpm ?

I believe I made the popup menu screen shot with that version of x dummy.


Tue, 11 Nov 2014 04:37:09 GMT - Antoine Martin:

@afarr: like rainwoodman said, the bug fix is in the dummy driver. You must have the correct one installed to test.


Tue, 11 Nov 2014 14:31:23 GMT - Antoine Martin:

Gdk wants the "size-changed" signal. Which should have fired when we resize.

I can reproduce the problem with just gedit, which is nice.

I've tried changing the order of the randr notify calls and place them right at the end of the dummy driver's DUMMYSwitchMode function:

    RRScreenSizeNotify(pScrn->pScreen);
    RRTellChanged(pScrn->pScreen);

No change.


Tue, 11 Nov 2014 17:09:01 GMT - rainwoodman:

Is the function at

http://cgit.freedesktop.org/xorg/app/xrandr/tree/xrandr.c#n1662

any useful?

EDIT: and http://cgit.freedesktop.org/xorg/app/xrandr/tree/xrandr.c#n1573

Feels like a if branch is missing some operations when screens size / fb size equals to the monitor size. (I am not sure about the terminology)


Tue, 18 Nov 2014 19:03:32 GMT - Lukas Haase: cc set


Fri, 21 Nov 2014 17:51:32 GMT - Antoine Martin: owner, status changed

This may help: 56#comment:8


Sun, 30 Nov 2014 06:08:35 GMT - Lukas Haase:

I have been redirected to here from

http://lists.devloop.org.uk/pipermail/shifter-users/2014-November/001063.html

Indeed, what I described in the email above seems to be the same problem.

I just manually installed http://xpra.org/beta/CentOS/6.6/x86_64/xorg-x11-drv-dummy-0.3.6-15.xpra4.el6.x86_64.rpm on my server and it seems applications work after a reconnect with 2 monitors :) :)

Looking forward to find this fix in the 0.14 stable soon...


Sun, 30 Nov 2014 19:22:39 GMT - Lukas Haase:

Unfortunately I face a different problem with the patched xorg driver now: In some applications, when I click a menu from a windows on the primary monitor (no matter where the window is on the primary monitor), the menus always appears at the intersection between the primary and the secondary monitor.

When the window is on the secondary monitor, it works as expected.

Hard to describe, therefore a screenshot of this (the taskbar is included, so you can see where the intersection between the two monitors is):

Can the patch explain a behavior like this?


Sun, 30 Nov 2014 19:23:00 GMT - Lukas Haase: attachment set


Mon, 26 Jan 2015 09:02:45 GMT - Antoine Martin: owner, status changed

Sorry it's taken so long to get back to this ticket. Is this still a problem? Was this not a problem before with the non-patched dummy driver? Do you have wiki/FakeXinerama installed and configured properly? (and if so, does removing it help?)

From the screenshot, it looks like your primary monitor (the one with the system task bar) is the one on the right. I guess that the application is trying to open the menu on the correct monitor and getting it wrong. Can you find any applications that does this beyond this commercial application that I cannot run?

Finally, there is some progress on randr 1.2 for dummy (just nothing ready for immediate consumption), see: ticket:56#comment:9


Wed, 28 Jan 2015 00:34:28 GMT - Lukas Haase:

Thanks for getting back on this. Yes, this is still a problem. However, at this point it is hard to say because I struggle again with this bug #751 which I just re-opened.

FakeXinerama is installed and I think configured properly. Unfortunately this proprietary application is the one where it appeared but my set of applications is very small. I e.g. tried xterm, Firefox, they work. Is it possible to extract some debugging info (e.g. window properties) that could help?


Wed, 28 Jan 2015 04:06:29 GMT - Antoine Martin:

Based on the data from #751, please try with 0.14.x - it may well be the same trunk bug that's causing the "workspace" to have the wrong dimensions with win32 clients, and the application then decides to constrain the window position to those invalid dimensions. If that does not solve it, please post:

etc.


Thu, 29 Jan 2015 22:18:28 GMT - Lukas Haase:

Unfortunately the bug still appears with 0.14 stable :(

$ xprop -root
dummy-constant-ydpi(CARDINAL) = 96
dummy-constant-xdpi(CARDINAL) = 96
RESOURCE_MANAGER(STRING) = "gnome.Xft/DPI:\t98304\nXft.dpi:\t96\n"
_MOTIF_DEFAULT_BINDINGS(STRING) = "osfCancel:<Key>Escape,<Key>Cancel\nosfLeft:<Key>Left\nosfUp:<Key>Up\nosfRight:<Key>Right\nosfDown:<Key>Down\nosfEndLine:<Key>End\nosfBeginLine:<Key>Home,<Key>Begin\nosfPageUp:<Key>Prior\nosfPageDown:<Key>Next\nosfBackSpace:<Key>BackSpace\nosfDelete:<Key>Delete\nosfInsert:<Key>Insert\nosfAddMode:Shift<Key>F8\nosfHelp:<Key>F1,<Key>Help\nosfMenu:Shift<Key>F10,<Key>Menu\nosfMenuBar:<Key>F10,Shift<Key>Menu\nosfSelect:<Key>Select\nosfActivate:<Key>KP_Enter,<Key>Execute\nosfClear:<Key>Clear\nosfUndo:<Key>Undo\nosfSwitchDirection:Alt<Key>Return,Alt<Key>KP_Enter"
_NET_CLIENT_LIST_STACKING(WINDOW): window id # 0xc00059, 0x1000026
_NET_CLIENT_LIST(WINDOW): window id # 0xc00059, 0x1000026
_NET_ACTIVE_WINDOW(CARDINAL) = 0
_NET_DESKTOP_VIEWPORT(CARDINAL) = 0, 0
_NET_DESKTOP_GEOMETRY(CARDINAL) = 3200, 1200
_NET_WORKAREA(CARDINAL) = 0, 0, 1366, 768
_NET_SUPPORTED(ATOM) = _NET_SUPPORTED, _NET_SUPPORTING_WM_CHECK, _NET_WM_FULL_PLACEMENT, _NET_WM_HANDLED_ICONS, _NET_CLIENT_LIST, _NET_CLIENT_LIST_STACKING, _NET_DESKTOP_VIEWPORT, _NET_DESKTOP_GEOMETRY, _NET_NUMBER_OF_DESKTOPS, _NET_DESKTOP_NAMES, _NET_WORKAREA, _NET_ACTIVE_WINDOW, _NET_CURRENT_DESKTOP, WM_NAME, _NET_WM_NAME, WM_ICON_NAME, _NET_WM_ICON_NAME, WM_CLASS, WM_PROTOCOLS, _NET_WM_PID, WM_CLIENT_MACHINE, WM_STATE, _NET_WM_ALLOWED_ACTIONS, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_USER_TIME, _NET_WM_USER_TIME_WINDOW, WM_HINTS, WM_NORMAL_HINTS, WM_TRANSIENT_FOR, _NET_WM_STRUT, _NET_WM_STRUT_PARTIAL_NET_WM_ICON, _NET_FRAME_EXTENTS, _NET_WM_WINDOW_TYPE, _NET_WM_WINDOW_TYPE_NORMAL, _NET_WM_WINDOW_TYPE_TOOLBAR, _NET_WM_WINDOW_TYPE_MENU, _NET_WM_WINDOW_TYPE_UTILITY, _NET_WM_WINDOW_TYPE_SPLASH, _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_DROPDOWN_MENU, _NET_WM_WINDOW_TYPE_POPUP_MENU, _NET_WM_WINDOW_TYPE_TOOLTIP, _NET_WM_WINDOW_TYPE_COMBO, _NET_WM_STATE, _NET_WM_STATE_DEMANDS_ATTENTION, _NET_WM_STATE_MODAL, _NET_WM_STATE_MAXIMIZED_VERT,  _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_HIDDEN, _NET_WM_STATE_FULLSCREEN, _MOTIF_WM_HINTS, _MOTIF_WM_INFO, _NET_WM_MOVERESIZE
_NET_CURRENT_DESKTOP(CARDINAL) = 0
_NET_DESKTOP_NAMES(UTF8_STRING) = "Main"
_NET_NUMBER_OF_DESKTOPS(CARDINAL) = 1
_NET_WM_NAME(UTF8_STRING) = "Xpra"
_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x40001e
XPRA_SERVER(STRING) = "0.14.18"
_XPRA_SERVER_UUID(STRING) = "5b3972303d6940ccb9bd6d38937a08b6"
_XPRA_SERVER_PID(CARDINAL) = 11997
_XKB_RULES_NAMES(STRING) = "base", "pc105", "us", "", ""
VFB_IDENT(STRING) = "TRUE"

Edit: converted large xpra info window to an attachment.

I hope this can help a bit ...


Thu, 29 Jan 2015 22:59:30 GMT - Lukas Haase:

Some more comment: It seems that disconnecting and reconnecting with solves the problem then.


Fri, 30 Jan 2015 03:42:01 GMT - Antoine Martin: attachment set

converting large inline text to attachment


Fri, 30 Jan 2015 06:11:26 GMT - Antoine Martin: owner, status changed

Got it!

2 big bugs squashed:

Backport for 0.14.19 in r8591 and r8592.


Mon, 02 Feb 2015 09:49:50 GMT - Antoine Martin: owner, status changed

lukashaase: if that works for you, please close this ticket.


Fri, 13 Feb 2015 04:51:56 GMT - Antoine Martin: status changed; resolution set

Not heard back, works fine here, closing.


Sun, 11 Oct 2015 20:59:48 GMT - nathan-renniewaldock: cc, status changed; resolution deleted

I'm having what appears to be the same issue. Server: Ubuntu 12.04, xpra v0.15.4 Client: Windows 10, xpra v0.16.0-r10076

The log reports that the screen size changed, but parts of the window outside the original area can't be interacted with.

2015-10-11 21:25:54,143 _screen_size_changed(<gtk.gdk.ScreenX11 object at 0x316f9b0 (GdkScreenX11 at 0x3127890)>)
2015-10-11 21:25:54,144 new screen dimensions: (1440, 900)
2015-10-11 21:25:54,144 calculate_workarea(1440, 900)
2015-10-11 21:25:54,144 calculate_workarea() screen_sizes(ServerSource(Protocol(SocketConnection(/home/administrator/.xpra/rebecca.home-9876))))=[['1\\WinSta0\\Default', 1440, 900, 381, 238, [['\\\\.\\DISPLAY6', 0, 0, 1440, 900, 408, 255, 0, 0, 1440, 839]], 0, 0, 1440, 839]]
2015-10-11 21:25:54,144 calculate_workarea() found gtk.gdk.Rectangle(0, 0, 1440, 839) for display 1\WinSta0\Default
2015-10-11 21:25:54,144 _NET_WORKAREA=[0, 0, 1440, 839]

For example, in Thunderbird I can't click the menu button (right of search box) unless I either shrink the window or drag it left. The window's max size seems to be stuck at the size it was when it was first attached. If I attach it first on 1440x900, the right side behaves correctly, but of course I can't interact with the bottom.

Mouse debug info shows correct positions:

2015-10-11 21:32:58,097 move_pointer(1, (1422, 102))
2015-10-11 21:32:58,097 xtest_fake_button(1, False) at (1422, 102)
xprop -root:
dummy-constant-ydpi(CARDINAL) = 96
dummy-constant-xdpi(CARDINAL) = 96
RESOURCE_MANAGER(STRING) = "gnome.Xft/DPI:\t98304\nXft.hinting:\t1\nXft.antialias:\t1\nXft.dpi:\t96\nXft.rgba:\trgb\nXft.hintstyle:\thintmedium\n"
_NET_CLIENT_LIST_STACKING(WINDOW): window id # 0xa00004
_NET_CLIENT_LIST(WINDOW): window id # 0xa00004
_NET_ACTIVE_WINDOW(CARDINAL) = 10485764
_NET_DESKTOP_VIEWPORT(CARDINAL) = 0, 0
_NET_DESKTOP_GEOMETRY(CARDINAL) = 1440, 900
_NET_WORKAREA(CARDINAL) = 0, 0, 1440, 839
_NET_SUPPORTED(ATOM) = _NET_SUPPORTED, _NET_SUPPORTING_WM_CHECK, _NET_WM_FULL_PLACEMENT, _NET_WM_HANDLED_ICONS, _NET_CLIENT_LIST, _NET_CLIENT_LIST_STACKING, _NET_DESKTOP_VIEWPORT, _NET_DESKTOP_GEOMETRY, _NET_NUMBER_OF_DESKTOPS, _NET_DESKTOP_NAMES, _NET_WORKAREA, _NET_ACTIVE_WINDOW, _NET_CURRENT_DESKTOP, WM_NAME, _NET_WM_NAME, WM_ICON_NAME, _NET_WM_ICON_NAME, WM_CLASS, WM_PROTOCOLS, _NET_WM_PID, WM_CLIENT_MACHINE, WM_STATE, _NET_WM_FULLSCREEN_MONITORS, _NET_WM_ALLOWED_ACTIONS, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_USER_TIME, _NET_WM_USER_TIME_WINDOW, WM_HINTS, WM_NORMAL_HINTS, WM_TRANSIENT_FOR, _NET_WM_STRUT, _NET_WM_STRUT_PARTIAL_NET_WM_ICON, _NET_CLOSE_WINDOW, _NET_FRAME_EXTENTS, _NET_WM_WINDOW_TYPE, _NET_WM_WINDOW_TYPE_NORMAL, _NET_WM_WINDOW_TYPE_TOOLBAR, _NET_WM_WINDOW_TYPE_MENU, _NET_WM_WINDOW_TYPE_UTILITY, _NET_WM_WINDOW_TYPE_SPLASH, _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_DROPDOWN_MENU, _NET_WM_WINDOW_TYPE_POPUP_MENU, _NET_WM_WINDOW_TYPE_TOOLTIP, _NET_WM_WINDOW_TYPE_COMBO, _NET_WM_STATE, _NET_WM_STATE_DEMANDS_ATTENTION, _NET_WM_STATE_MODAL, _NET_WM_STATE_STICKY, _NET_WM_STATE_MAXIMIZED_VERT, _NET_WM_STATE_MAXIMIZED_HORZ, _NET_WM_STATE_SHADED, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER, _NET_WM_STATE_HIDDEN, _NET_WM_STATE_FULLSCREEN, _NET_WM_STATE_ABOVE, _NET_WM_STATE_BELOW, _NET_WM_MOVERESIZE, _NET_MOVERESIZE_WINDOW, _MOTIF_WM_HINTS, _MOTIF_WM_INFO
_NET_CURRENT_DESKTOP(CARDINAL) = 0
_NET_DESKTOP_NAMES(UTF8_STRING) = "Main"
_NET_NUMBER_OF_DESKTOPS(CARDINAL) = 1
_NET_WM_NAME(UTF8_STRING) = "Xpra"
_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x400025
XPRA_SERVER(STRING) = "0.15.4"
_XPRA_SERVER_UUID(STRING) = "b0ee3b247f83459eb2f25f636023ddfd"
_XPRA_SERVER_PID(CARDINAL) = 25581
_XKB_RULES_NAMES(STRING) = "evdev", "pc105", "gb", "", ""
VFB_IDENT(STRING) = "TRUE"

I'll give this a try on Linux too and see if it's Win32 specific or not.


Sun, 11 Oct 2015 21:00:21 GMT - nathan-renniewaldock: attachment set


Sun, 11 Oct 2015 23:02:27 GMT - nathan-renniewaldock:

Yes, this also happens on Linux. Fresh session, attached on 1024x600, then 1280x1024, can't use scrollbar. Happens regardless of fakeXinerama


Mon, 12 Oct 2015 03:58:02 GMT - Antoine Martin:

@nathan.renniewaldock: if you're using wiki/Xdummy you may need the patch from r8060, if you're using xvfb... I don't know.


Mon, 12 Oct 2015 14:12:14 GMT - nathan-renniewaldock: status changed; resolution set

Yep, that fixed it. Thanks


Sat, 23 Jan 2021 04:52:25 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/349