some parts of windows can not be clicked after changing resolutions

[totaam]

Issue migrated from trac ticket # 349

component: client | priority: critical | resolution: fixed

2013-06-04 02:38:22: onlyjob created the issue

---

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:

• xpra attach ssh:server.example.com:7
• change resolution of the client machine to 640x480 temporarily
  (e.g. in gnome System->Preferences->Monitors)
• change the resolution back to normal

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)

• It seems that when I change the resolution from R1 to R2 xpra sets the screen size to R1 and not R2! Here is a patch that fixes the problem for me:

--- /usr/share/pyshared/xpra/client.py    2013-05-27 07:21:53.000000000 +0300
+++ client.py                             2013-06-04 00:50:28.197672381 +0300
@@ -1106,8 +1106,9 @@
         self.encoding = encoding
         self.send("encoding", encoding)
 
-    def _screen_size_changed(self, *args):
-        root_w, root_h = get_root_size()
+    def _screen_size_changed(self, screen):
+        root_w = screen.get_width()
+        root_h = screen.get_height()
         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):

[totaam]

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()

[totaam]

2013-06-05 05:03:05: totaam commented

---

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.

[totaam]

2013-06-06 08:59:02: onlyjob commented

---

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

[totaam]

2013-06-06 09:36:49: totaam commented

---

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

[totaam]

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..

[totaam]

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

• r3746 for trunk
• 3748 for v0.9.x

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.

[totaam]

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?

[totaam]

2014-10-30 21:06:43: rainwoodman commented

---

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

[totaam]

Usual questions:

• log output of client
• application exhibiting this problem
• xpra info from server
• log output from server as the new client connects
  etc...

[totaam]

2014-11-01 03:57:52: rainwoodman uploaded file :200.log (9.3 KiB)

Server Log

[totaam]

2014-11-01 03:58:12: rainwoodman uploaded file client.log (619.3 KiB)

Client log

[totaam]

2014-11-01 04:04:55: rainwoodman commented

---

I killed the server before taking xpra info.

The use case is:
0. set resolution of my client to 800x600

1. ssh to server, start xpra server with:
   xpra start :200 --start-child='/etc/X11/xinit/Xsession gnome-terminal' --no-speaker
2. on client, run:
   xpra attach --encoding=png/P ssh:server:200 --debug=all 2> /tmp/client.log
3. Control-C on the client
4. set resolution of my client to 1280x800
5. on client, run:
   xpra attach --encoding=png/P ssh:server:200 --debug=all 2> /tmp/client.log
6. drag the terminal window to the lower right corner
7. click the menu bar of the terminal window multiple times; no response from terminal.
8. Control-C on the client
9. 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.

[totaam]

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:

• which distro are you running? (both client and server)
• can you provide xpra info captured when the window is having problems with clicks?
• does this happen only with gnome terminal? or can you reproduce with an xterm?

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

[totaam]

2014-11-01 05:52:39: rainwoodman uploaded file info.tar.gz (77.4 KiB)

Server Info at various states

[totaam]

2014-11-01 05:53:35: rainwoodman uploaded file client-log.tar.gz (252.0 KiB)

Client logs at various stages

[totaam]

2014-11-01 05:54:21: rainwoodman uploaded file :200.2.log (8.9 KiB)

updated server log

[totaam]

2014-11-01 05:59:00: rainwoodman commented

---

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.

[totaam]

2014-11-01 15:15:35: totaam commented

---

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?

[totaam]

2014-11-03 16:55:04: rainwoodman uploaded file Screenshot from 2014-11-03 08:49:47.png (51.3 KiB)

illustration with a screenshot

[totaam]

2014-11-03 16:55:58: rainwoodman commented

---

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

[totaam]

2014-11-03 16:59:35: rainwoodman commented

---

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,

[totaam]

2014-11-03 17:15:57: rainwoodman commented

---

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  

[totaam]

2014-11-03 17:21:08: rainwoodman commented

---

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.

[totaam]

2014-11-04 08:05:18: totaam uploaded file fake-scaled-screen-size.patch (3.2 KiB)

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

[totaam]

2014-11-04 08:21:24: totaam commented

---

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!

[totaam]

2014-11-04 09:32:48: totaam commented

---

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...

[totaam]

2014-11-04 10:22:39: totaam commented

---

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

• RandR scaling doesn't work
• Xrandr panning/scaling jails the mouse
• xrandr --scale restricts area in which mouse moves

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..

[totaam]

2014-11-04 17:47:40: totaam commented

---

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.

[totaam]

2014-11-04 19:10:30: rainwoodman commented

---

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.

[totaam]

2014-11-05 08:01:54: totaam commented

---

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.

[totaam]

2014-11-21 17:51:33: antoine commented

---

This may help: [#56#comment:8]

[totaam]

2014-11-30 06:08:36: lukashaase commented

---

I have been redirected to here from

https://xpra.org/list/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...

[totaam]

2014-11-30 19:22:40: lukashaase commented

---

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):

[[Image(xorg-x11-drv-dummy-0.3.6-15.xpra4.el6.x86_64-bug.png)]]

Can the patch explain a behavior like this?

[totaam]

2014-11-30 19:23:01: lukashaase uploaded file xorg-x11-drv-dummy-0.3.6-15.xpra4.el6.x86_64-bug.png (580.8 KiB)

[totaam]

2015-01-26 09:02:45: totaam commented

---

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 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: #56#comment:9

[totaam]

2015-01-28 00:34:28: lukashaase commented

---

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?

[totaam]

2015-01-28 04:06:30: totaam commented

---

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:

• xpra info | grep window
• xprop -root
  etc.

[totaam]

2015-01-29 22:18:29: lukashaase commented

---

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 ...

[totaam]

2015-01-29 22:59:31: lukashaase commented

---

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

[totaam]

2015-01-30 03:42:01: antoine uploaded file xpra-info-window.txt (16.7 KiB)

converting large inline text to attachment

[totaam]

2015-01-30 06:11:26: antoine commented

---

Got it!

2 big bugs squashed:

• first, a stupid typo (client side), see r8588 for details
• second, a GTK bug by the looks of things (server side), fixed in r8590

Backport for 0.14.19 in 8591 and 8592.

[totaam]

2015-02-02 09:49:51: totaam commented

---

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

[totaam]

2015-02-13 04:51:57: totaam commented

---

Not heard back, works fine here, closing.

[totaam]

2015-10-11 21:59:49: nathan-renniewaldock commented

---

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.

[totaam]

2015-10-11 22:00:22: nathan-renniewaldock uploaded file xpra-info.txt (102.8 KiB)

[totaam]

2015-10-12 00:02:28: nathan-renniewaldock commented

---

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

[totaam]

2015-10-12 04:58:02: antoine commented

---

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

[totaam]

2015-10-12 15:12:15: nathan-renniewaldock commented

---

Yep, that fixed it. Thanks