notifications incomplete or missing in dualhead extended desktop setup

[totaam]

Issue migrated from trac ticket # 1284

component: android | priority: major | resolution: fixed

2016-08-17 23:38:28: jiang.qian created the issue

---

I have recently got a second-hand display to connect to my laptop. The laptop is 1400x1050 and the LCD monitor is 1280x1024 (they're really old! none of those widescreen 16:9 shenanigans). I use them in a dual-head setup as an extended desktop with monitor on the left and laptop on the right.

I use xpra to forward windows from a workstation. I put the forwarded browser window (firefox in this case) on the monitor half of the extended window. The window snap to the maximum extent of that monitor when maximized, which is great.

However, the notifications from firefox are cutoff. For example, I used forecastfox for weather. The pop up tool-tips are sometimes extended to the laptop monitor and sometimes get cut-off from below. Furthermore, gmail notifications that firefox displays when a new mail arrive disappears (or it appears behind the window that I cannot see.) If I run firefox locally, the notification appears, though sometimes in the wrong display.

Is there ways to fix this? This is not the end of the world, but it would be nice if the notifications and pop-up tool-tips appears, and even better if they appear as if each monitor/display is its own desktop.

Because I'm running on a production system, stability is paramount. So both the workstation and the laptop is running ubuntu 14.04.

However, thank to your great work with ffmpeg, I am able to upgrade xpra to the latest beta 1.0 (rev. 13238) on both server and client! They both run 64 bit.

I know I can put the commandline options into xpra configuration file. However, out of habit this is how I run xpra:
on workstation:

XPRA_CLIPBOARD_LIMIT=30 xpra --xvfb='Xorg -noreset -nolisten tcp +extension GLX +extension RANDR +extension RENDER -logfile ${HOME}/.xpra/Xvfb-10.log  -config ${HOME}/.xpra/xorg.conf' start :100 --bind-tcp=0.0.0.0:10000

on client:

XPRA_SET_WORKSPACE=1 xpra --encoding=rgb --packet-encoder=rencode --speaker=off --speaker-code=wav --compressor=lz4 --desktop-scaling=off attach tcp:workstation:10000

I'm on local LAN so I don't need authentication or encryption. I use raw tcp packets so that it is faster.

[totaam]

2016-08-18 04:29:22: antoine changed owner from antoine to jiang.qian

[totaam]

2016-08-18 04:29:22: antoine edited the issue description

[totaam]

2016-08-18 04:29:22: antoine commented

---

However, the notifications from firefox are cutoff.
[[BR]]
You may be able to improve this by adding a new modeline with this exact resolution to the xorg.conf file. ie: 1400x1050 + 1280x1024 gtf 2680 2074 25 added to trunk in r13385.

[[BR]]

Furthermore, gmail notifications that firefox displays when a new mail arrive disappears (or it appears behind the window that I cannot see.)
[[BR]]
Could be related to the problem above, let me know if the new modeline helps.

If it doesn't, please re-assign to me and I'll try to reproduce.
Please include your DE (unity?) and anything else that might be relevant.
Does this bug only happen with the dualhead?

---

XPRA_SET_WORKSPACE=1 and --packet-encoder=rencode --compressor=lz4
are the defaults already, you can drop those.

XPRA_CLIPBOARD_LIMIT=30

Is 20 (the default) not enough? What application causes this sort of heavy clipboard traffic?

[totaam]

2016-08-18 05:03:50: jiang.qian commented

---

Unfortunately adding the extra modeline does not change the behaviors. But I'm very sorry, I provided the wrong information about screen resolution. The monitor is indeed 1280x1028, but the laptop display is 1440x900. I was quoting the number, out of habit, of my even older T43, rather than the slightly younger T61 I'm using.

What should then be the proper modeline?

On the server, it's basically running headless, so no desktop environment is involved. On the client, I am running ubuntu session called gnome-flashback,which basically disables unity and all the fancy 3D acceleration and transparency effect. It's still gtk3, I believe, but no acceleration or graphic effects are used:
https://wiki.gnome.org/Projects/GnomeFlashback

Here are the possibly relevant section in the log:

2016-08-17 23:46:54,296   :0.0 (720x271 mm - DPI: 95x95)[0m
2016-08-17 23:46:54,296     VGA1 1280x1024 (376x301 mm - DPI: 86x86)[0m
2016-08-17 23:46:54,297     LVDS1 1440x900 at 1280x124 (304x190 mm - DPI: 120x120)[0m
2016-08-17 23:46:54,306 server virtual display now set to 3288x1080 (best match for 2720x1024)[0m

[totaam]

2016-08-18 16:57:24: antoine commented

---

Never mind, I had calculated it wrong anyway (no harm done), the one you want is the one shown: 2720x1024, get the new modeline with:

$ gtf 2720 1024 25

  # 2720x1024 @ 25.00 Hz (GTF) hsync: 25.97 kHz; pclk: 86.44 MHz
  Modeline "2720x1024_25.00"  86.44  2720 2760 3024 3328  1024 1025 1028 1039  -HSync +Vsync

Add this to your xorg.conf as per r13388 and the server should now find an exact match.

[totaam]

2016-08-18 22:05:22: jiang.qian commented

---

Thank you for the patch. Adding it to my xorg.conf unfortunately does not change the behaviors of notifications and pop-up tool-tips. They behave exactly as before. The log from the client side when connecting shows:

2016-08-18 16:24:19,302 OpenGL_accelerate module loaded
2016-08-18 16:24:19,320 Warning: OpenGL windows will be clamped to the maximum texture size 4096x4096
2016-08-18 16:24:19,320  for OpenGL 2.1 renderer 'Mesa DRI Intel(R) 965GM'
2016-08-18 16:24:19,320 OpenGL enabled with Mesa DRI Intel(R) 965GM
2016-08-18 16:24:19,545  detected keyboard: rules=evdev, model=pc105, layout=us
2016-08-18 16:24:19,550  desktop size is 2720x1024 with 1 screen:
2016-08-18 16:24:19,550   :0.0 (720x271 mm - DPI: 95x95)
2016-08-18 16:24:19,550     VGA1 1280x1024 (376x301 mm - DPI: 86x86)
2016-08-18 16:24:19,551     LVDS1 1440x900 at 1280x124 (304x190 mm - DPI: 120x120)
2016-08-18 16:24:19,926 Xpra X11 server version 1.0-[r13238](../commit/ab4e514f244cccef4e7e5bbb21c105a94cef549e) 64-bit
2016-08-18 16:24:19,927  running on Linux Ubuntu 14.04 trusty
2016-08-18 16:24:19,927 enabled remote logging

(I'm confused about the line LDVS 1440x900 at 1280x124. What does it mean?)
On the server side, the log shows:

2016-08-18 16:24:19,732   :0.0 (720x271 mm - DPI: 95x95)ESC[0m
2016-08-18 16:24:19,732     VGA1 1280x1024 (376x301 mm - DPI: 86x86)ESC[0m
2016-08-18 16:24:19,732     LVDS1 1440x900 at 1280x124 (304x190 mm - DPI: 120x12
0)ESC[0m
2016-08-18 16:24:19,741 server virtual display now set to 2720x1024ESC[0m
2016-08-18 16:24:19,743 setting key repeat rate from client: 660ms delay / 40ms intervalESC[0m
2016-08-18 16:24:19,745 setting keymap: rules=evdev, model=pc105, layout=usESC[0m
ESC[33m2016-08-18 16:24:19,778 DPI set to 32 x 24 (wanted 96 x 96)ESC[0m
ESC[33m2016-08-18 16:24:19,778  you may experience scaling problems, such as huge or small fonts, etcESC[0m
ESC[33m2016-08-18 16:24:19,778  to fix this issue, try the dpi switch, or use a patched Xorg dummy driverESC[0m

By the way, I experienced a slight lag when typing on a remote window forwarded over xpra. Is the 660ms delay of key repeat rate mentioned in the log responsible for that? If so, is there a parameter with which I can reduce it? The server and client are on a gigabit lan with ping time below 0.3ms.

xpra has been performing excellently after the latest beta to the 1.0 branch, besides the small issues mentioned. Thank you for making the latest version available for Ubuntu 14.04 and all the good work you put into developing xpra!

[totaam]

2016-08-19 04:52:48: antoine commented

---

(I'm confused about the line LDVS 1440x900 at 1280x124. What does it mean?)
[[BR]]
It means the second panel starts at the right of the first one (x=1280) and is aligned to the bottom of the first screen (y=1024-900=124)

---

By the way, I experienced a slight lag when typing on a remote window forwarded over xpra. Is the 660ms delay of key repeat rate mentioned in the log responsible for that?
[[BR]]
No, that's the keyboard repeat rate.
Please file a separate ticket for the lag, and include data from the bug report tool, or at the very least "xpra info" capture when the problem is present.

[totaam]

2016-08-19 05:08:42: jiang.qian uploaded file xpra_info.txt (119.6 KiB)

[totaam]

2016-08-19 05:16:14: jiang.qian commented

---

OK, I'll file a ticket if the input lag becomes really noticeable. For now, I've attached a new file for this bug of notification missing. It is the
xpra info output at the moment when a forwarded Firefox should produce a notification but didn't. Please let me know what I can do to help with this bug. Thank you!

[totaam]

2016-08-19 05:16:50: antoine changed status from new to assigned

[totaam]

2016-08-19 05:16:50: antoine changed owner from jiang.qian to antoine

[totaam]

2016-09-12 10:32:43: antoine changed status from assigned to new

[totaam]

2016-09-12 10:32:43: antoine changed owner from antoine to jiang.qian

[totaam]

2016-09-12 10:32:43: antoine commented

---

The firefox notification window seems to be an OR window:

window.129.class-instance=('Alert', 'Firefox')
window.129.dimensions=(351, 112)
window.129.geometry=(2359, 10, 351, 112)
window.129.role=alert
window.129.supports-transparency=True
window.129.window-type=('UTILITY',)
window.129.override-redirect=True

And your server screen definition is the same as comment:4 (2720x1024).
So the alert window is positioned in the blank space above the monitor on the right hand side...

The problem here is that we have no way to tell applications about the monitor geometry we really want because Xdummy only gives us one virtual screen for all of them.
We set _NET_DESKTOP_GEOMETRY to 2720x1024, and _NET_WORKAREA to the same dimensions minus any desktop menu bars. What we need to be able to implement this is randr: Monitor support in the dummy driver: #56.

This is not a problem for regular windows, we just let the client side window manager do the right thing.
For OR windows, r13669 now detects when a window is being mapped off-screen (we already have the list of monitor sizes client side), and we then add an offset to it. (and substract again when translating mouse events to send back to the server)

@jiang.qian: does that fix things for you? New trusty builds here: [http://xpra.org/beta]
If not, please post the "-d geometry" debug output of the client.

[totaam]

2016-09-12 22:06:55: jiang.qian commented

---

Thank you for the patch! There is a significant change in window behavior. The pop-up toolkits from extension (e.g. the forecastfox weather forecast now appears either in the monitor or the laptop screen, no longer straddling the extended desktop across the two screens.

-However*, the desktop notifications still do not appear. This includes, most significantly, the gmail notificiation (that is a notification) and a variety of others (I use a thing called recollindex firefox extension).

How does xpra handle desktop notification?
https://developer.gnome.org/notification-spec/
Does it forward the notification? If so, perhaps it is the problem with the notification forewarding code, not just the desktop geometry code?

Thanks again for working on this!

[totaam]

2016-09-12 22:07:51: jiang.qian uploaded file xpra-debug.txt (3.8 KiB)

[totaam]

2016-09-13 04:18:27: antoine commented

---

Looks to me like the notification window geometry issue originally reported is fixed, right? If so, please close this ticket and use a separate one for notifications forwarding.

This feature has been supported for 5 years already, see r202 and [/wiki/FAQ#Features-HowdoI] and there should be an menu item for toggling notifications in your xpra system tray menu. It is also found in the man page.

To debug it, start both the client and server with "-d notify,dbus" and include the full log as attachment.
Maybe you don't have all the dependencies installed (python-dbus or python-notify) or maybe you are sharing the same dbus server as another session (we don't steal notifications from other utilities).

[totaam]

2016-09-13 04:22:33: jiang.qian changed status from new to closed

[totaam]

2016-09-13 04:22:33: jiang.qian set resolution to fixed

[totaam]

2016-09-13 04:22:33: jiang.qian commented

---

Follow up is in #1304

[totaam]

2016-09-14 07:52:48: antoine commented

---

Added a simple test application to the source tree in r13719:

./tests/xpra/test_apps/test_windows_at.py 3000 2000 100 100

creates a 100x100 window at position 3000,2000

See also #1339

[totaam]

2019-02-11 14:08:59: antoine commented

---

Turns out that this code looks buggy in some cases, moving the window to the wrong monitor (not the closest one to the original location): better fix in r21631 (see #2141#comment:4).