some parts of windows can not be clicked after changing resolutions

[onlyjob]

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

[Antoine Martin]

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

[Antoine Martin]

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.

[onlyjob]

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

[Antoine Martin]

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

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

[Antoine Martin]

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

• r3746 for trunk
• r3748 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.

[Antoine Martin]

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?

[rainwoodman]

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

[Antoine Martin]

Usual questions:

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

etc...

[rainwoodman]

Server Log

[rainwoodman]

Client log

[rainwoodman]

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.

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

• 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

[rainwoodman]

Server Info at various states

[rainwoodman]

Client logs at various stages

[rainwoodman]

updated server log

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

[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?

[rainwoodman]

illustration with a screenshot

[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

[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,

[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  

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

[Antoine Martin]

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

[Antoine Martin]

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!

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

[Antoine Martin]

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

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

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

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

[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!

[Antoine Martin]

hacked dummy driver with the geometry fix

[Antoine Martin]

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?

[Antoine Martin]

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

[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

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

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

[rainwoodman]

location of popup menus

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

[alas]

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

• Tried with 0.15.0 r7928 with windows 8.1 and 0.15.0 r7514 with windows 7 (both against a fedora 20 server 0.15.0 r7865) ... couldn't reproduce. (0.15.0 r8072 windows client also shows interactable with whole screen no matter how DPI was shifted.)

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?

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

[Antoine Martin]

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

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

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

[Antoine Martin]

This may help: 56#comment:8

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

[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?

[Antoine Martin]

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

[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?

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

• xpra info | grep window
• xprop -root

etc.

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

[Lukas Haase]

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

[Antoine Martin]

converting large inline text to attachment

[Antoine Martin]

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 r8591 and r8592.

[Antoine Martin]

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

[Antoine Martin]

Not heard back, works fine here, closing.

[nathan-renniewaldock]

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.

[nathan-renniewaldock]

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

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

[nathan-renniewaldock]

Yep, that fixed it. Thanks

[migration script]

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