#349 closed defect (fixed)
some parts of windows can not be clicked after changing resolutions
Reported by: | onlyjob | Owned by: | Lukas Haase |
---|---|---|---|
Priority: | critical | Milestone: | 0.15 |
Component: | client | Version: | 0.14.x |
Keywords: | Cc: | lukashaase@…, nathan.renniewaldock@… |
Description (last modified by )
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):
Attachments (12)
Change History (66)
comment:1 Changed 9 years ago by
Description: | modified (diff) |
---|---|
Owner: | changed from Antoine Martin to Antoine Martin |
Status: | new → assigned |
comment:2 Changed 9 years ago by
Owner: | changed from Antoine Martin to onlyjob |
---|---|
Status: | assigned → new |
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.
comment:3 Changed 9 years ago by
Reporter tried the proposed fix and confirmed that it solved the problem for him.
comment:4 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
thanks, now also in v0.9.x branch as of r3590
comment:5 Changed 9 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:6 Changed 9 years ago by
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..
comment:7 Changed 9 years ago by
_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.
comment:8 Changed 9 years ago by
Milestone: | → 0.11 |
---|
comment:9 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
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?
comment:10 Changed 8 years ago by
Milestone: | 0.11 → 0.15 |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
Version: | 0.9.x → 0.14.x |
The problem persists on 0.14.9 if the new client has a bigger screen pixel size than the first connection to the server.
comment:11 Changed 8 years ago by
Owner: | changed from onlyjob to rainwoodman |
---|---|
Status: | reopened → new |
Usual questions:
- log output of client
- application exhibiting this problem
- xpra info from server
- log output from server as the new client connects
etc...
comment:12 Changed 8 years ago by
I killed the server before taking xpra info.
The use case is:
- set resolution of my client to 800x600
- ssh to server, start xpra server with:
xpra start :200 --start-child='/etc/X11/xinit/Xsession gnome-terminal' --no-speaker
- on client, run:
xpra attach --encoding=png/P ssh:server:200 --debug=all 2> /tmp/client.log
- Control-C on the client
- set resolution of my client to 1280x800
- on client, run:
xpra attach --encoding=png/P ssh:server:200 --debug=all 2> /tmp/client.log
- drag the terminal window to the lower right corner
- click the menu bar of the terminal window multiple times; no response from terminal.
- Control-C on the client
- 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.
comment:13 Changed 8 years ago by
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
comment:14 Changed 8 years ago by
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.
comment:15 Changed 8 years ago by
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?
Changed 8 years ago by
Attachment: | Screenshot from 2014-11-03 08:49:47.png added |
---|
illustration with a screenshot
comment:16 Changed 8 years ago by
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
comment:17 Changed 8 years ago by
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,
comment:18 Changed 8 years ago by
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
comment:19 Changed 8 years ago by
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.
Changed 8 years ago by
Attachment: | fake-scaled-screen-size.patch added |
---|
allows me to temporarily test different client screen sizes without actually changing anything
comment:20 Changed 8 years ago by
Owner: | changed from rainwoodman to Antoine Martin |
---|---|
Priority: | major → critical |
Status: | new → assigned |
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!
comment:21 Changed 8 years ago by
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...
comment:22 Changed 8 years ago by
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..
comment:23 Changed 8 years ago by
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.
comment:24 Changed 8 years ago by
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.
comment:25 Changed 8 years ago by
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.
comment:26 Changed 8 years ago by
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!
comment:27 Changed 8 years ago by
Owner: | changed from Antoine Martin to rainwoodman |
---|---|
Status: | assigned → new |
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?
comment:28 Changed 8 years ago by
Owner: | changed from rainwoodman to alas |
---|
@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.
comment:29 Changed 8 years ago by
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
comment:30 Changed 8 years ago by
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.
comment:31 Changed 8 years ago by
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)
comment:32 Changed 8 years ago by
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).
comment:33 Changed 8 years ago by
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?
comment:34 Changed 8 years ago by
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.
comment:35 Changed 8 years ago by
@afarr: like rainwoodman said, the bug fix is in the dummy driver. You must have the correct one installed to test.
comment:36 Changed 8 years ago by
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.
comment:37 Changed 8 years ago by
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)
comment:38 Changed 8 years ago by
Cc: | lukashaase@… added |
---|
comment:39 Changed 8 years ago by
Owner: | changed from alas to Antoine Martin |
---|---|
Status: | new → assigned |
This may help: 56#comment:8
comment:40 Changed 8 years ago by
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...
comment:41 Changed 8 years ago by
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?
Changed 8 years ago by
Attachment: | xorg-x11-drv-dummy-0.3.6-15.xpra4.el6.x86_64-bug.png added |
---|
comment:42 Changed 7 years ago by
Owner: | changed from Antoine Martin to Lukas Haase |
---|---|
Status: | assigned → new |
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
comment:43 Changed 7 years ago by
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?
comment:44 Changed 7 years ago by
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.
comment:45 Changed 7 years ago by
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 ...
comment:46 Changed 7 years ago by
Some more comment: It seems that disconnecting and reconnecting with solves the problem then.
Changed 7 years ago by
Attachment: | xpra-info-window.txt added |
---|
converting large inline text to attachment
comment:47 Changed 7 years ago by
Owner: | changed from Lukas Haase to Antoine Martin |
---|---|
Status: | new → assigned |
comment:48 Changed 7 years ago by
Owner: | changed from Antoine Martin to Lukas Haase |
---|---|
Status: | assigned → new |
lukashaase: if that works for you, please close this ticket.
comment:49 Changed 7 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Not heard back, works fine here, closing.
comment:50 Changed 7 years ago by
Cc: | nathan.renniewaldock@… added |
---|---|
Resolution: | worksforme |
Status: | closed → reopened |
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.
Changed 7 years ago by
Attachment: | xpra-info.txt added |
---|
comment:51 Changed 7 years ago by
Yes, this also happens on Linux. Fresh session, attached on 1024x600, then 1280x1024, can't use scrollbar. Happens regardless of fakeXinerama
comment:52 Changed 7 years ago by
@nathan.renniewaldock: if you're using wiki/Xdummy you may need the patch from r8060, if you're using xvfb... I don't know.
comment:53 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Yep, that fixed it. Thanks
comment:54 Changed 17 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/349
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 (circa2013-06-03 21:25:16,***
) and then we are notified that the screen resolution has changed (at around2013-06-03 21:25:28,***
) and we correctly update the vfb size to640x480
.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: