From shanew at shanew.net Mon Dec 3 17:29:52 2018 From: shanew at shanew.net (Shane Williams) Date: Mon, 3 Dec 2018 11:29:52 -0600 (CST) Subject: [winswitch] Scaling on Newer Retina displays Message-ID: I have a user who is running xpra (probably 2.3) on a new MacBook Pro with Retina, connecting to an Ubuntu system running xpra 2.4.2. Various programs (notably xemacs or various terminals) display as very small on his Mac (to the point where it's basically impossible to read the text). We've used the scaling setting to make these windows larger, but by the time text would be large enough to read, it's gotten so fuzzy/noisy that you can't really read it that way either. I've read the xpra web page about DPI and followed most of the links, but it's still not clear to me whether there's a solution other than scaling. Is anyone using a high-DPI Retina display with xpra that might have suggestions on how to improve the readability/usability in this situation? P.S. I don't have regular access to the laptop, so I can't easily provide diagnostic information about it. -- Public key #7BBC68D9 at | Shane Williams http://pgp.mit.edu/ | System Admin - UT CompSci =----------------------------------+------------------------------- All syllogisms contain three lines | shanew at shanew.net Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew From mh+shifter-users at zugschlus.de Sat Dec 8 19:39:58 2018 From: mh+shifter-users at zugschlus.de (Marc Haber) Date: Sat, 8 Dec 2018 20:39:58 +0100 Subject: [winswitch] xpra session to other account on localhost Message-ID: <20181208193958.GJ3480@torres.zugschlus.de> Hi, I would like to do an xpra connection to an xpra server running under a different account on the same host. I am running Debian unstable and have xpra 2.4.2. The box is a strong Six-Core machine with plenty of free RAM and a fast SSD. Running a Firefox browser over this connection is quite slow. I have to wait multiple hundreds of milliseconds before the reaction to a click can be seen. Scrolling a window takes like ten seconds until the picture is completely re-drawn at full resolution. Is that the expected behavior on a local host with no network involved, plenty of CPU and plenty of RAM? I notice that the server complains twice on startup: 2018-12-08 20:19:08,741 cannot use uinput for virtual devices: 2018-12-08 20:19:08,741 [Errno 13] Failed to open the uinput device: Permission denied WARNING: no 'numpy' module, HyBi protocol will be slower python-numpy 1.15.4-2 is installed, and the /dev/uinput device is root:root 600, so it is not accessible by a regular user. Should I make /dev/uinput root:uinput 660 and put myself into the uinput group? Or is that a security disk? What is the recommended way to handle uinput? I don't even know what that is... Here is what the server logs: marc at fan:~$ xpra start --daemon=no --speaker=off --webcam=no --mdns=no --pulseaudio=no --start=konsole :100 2018-12-08 20:20:27,121 cannot use uinput for virtual devices: 2018-12-08 20:20:27,121 [Errno 13] Failed to open the uinput device: Permission denied X.Org X Server 1.20.3 X Protocol Version 11, Revision 0 Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian Current Operating System: Linux fan 4.18.0-3-amd64 #1 SMP Debian 4.18.20-2 (2018-11-23) x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-4.18.0-3-amd64 root=/dev/mapper/root ro splash console=ttyS0,57600n8 quiet Build Date: 25 October 2018 06:15:23PM xorg-server 2:1.20.3-1 (https://www.debian.org/support) Current version of pixman: 0.34.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (++) Log file: "/run/user/1002/xpra/Xorg.:100.log", Time: Sat Dec 8 20:20:27 2018 (++) Using config file: "/etc/xpra/xorg.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" 2018-12-08 20:20:28,913 created unix domain socket: /run/user/1002/xpra/fan-100 2018-12-08 20:20:28,913 created unix domain socket: /run/xpra/fan-100 2018-12-08 20:20:29,096 pointer device emulation using XTest 2018-12-08 20:20:31,107 OpenGL is supported on this display WARNING: no 'numpy' module, HyBi protocol will be slower 2018-12-08 20:20:31,186 serving html content from: /usr/share/xpra/www 2018-12-08 20:20:31,516 D-Bus notification forwarding is available 2018-12-08 20:20:31,691 xpra X11 version 2.4.2-r21077M 64-bit 2018-12-08 20:20:31,691 uid=1002 (marc), gid=1002 (marc) 2018-12-08 20:20:31,691 running with pid 4804 on Linux Debian unstable sid 2018-12-08 20:20:31,692 connected to X11 display :100 with 24 bit colors 2018-12-08 20:20:31,896 xpra is ready. 2018-12-08 20:20:39,158 printer forwarding enabled using postscript and pdf 2018-12-08 20:20:39,189 15.7GB of system memory (after client connection): 2018-12-08 20:23:56,917 New unix-domain connection received on /run/user/1002/xpra/fan-100 2018-12-08 20:23:56,924 Handshake complete; enabling connection 2018-12-08 20:23:56,934 automatic picture encoding enabled, also available: 2018-12-08 20:23:56,934 h264, vp9, vp8, png, png/P, png/L, webp, rgb24, rgb32, jpeg, h265, mpeg1, mpeg2 2018-12-08 20:23:56,935 Python/Gtk2 Linux Debian unstable sid x11 client version 2.4.2-r21077 64-bit 2018-12-08 20:23:56,935 connected from 'fan' as 'marc' - 'Marc Haber' 2018-12-08 20:23:57,109 setting key repeat rate from client: 600ms delay / 40ms interval 2018-12-08 20:23:57,111 setting keymap: rules=evdev, model=pc101, layout=de 2018-12-08 20:23:57,161 setting keyboard layout to 'de' 2018-12-08 20:23:57,226 client root window size is 4352x1728 with 1 display: 2018-12-08 20:23:57,226 :0.0 (1439x571 mm - DPI: 76x76) workarea: 4352x1690 2018-12-08 20:23:57,226 monitor 1 3072x1728 (941x529 mm - DPI: 82x82) 2018-12-08 20:23:57,227 monitor 2 1280x960 at 3072x0 (408x306 mm - DPI: 79x79) 2018-12-08 20:23:57,313 server virtual display now set to 4352x2048 (best match for 4352x1728) 2018-12-08 20:23:57,355 client @09.168 Xpra X11 server version 2.4.2-r21077 64-bit 2018-12-08 20:23:57,356 client @09.169 running on Linux Debian unstable sid 2018-12-08 20:23:57,360 DPI set to 51 x 48 (wanted 54 x 77) 2018-12-08 20:23:57,361 you may experience scaling problems, such as huge or small fonts, etc 2018-12-08 20:23:57,361 to fix this issue, try the dpi switch, or use a patched Xorg dummy driver 2018-12-08 20:23:57,417 client @09.176 Attached to localhost:22 via ssh 2018-12-08 20:23:57,417 client @09.177 (press Control-C to detach) 2018-12-08 20:23:57,510 client @09.284 server does not support xi input devices 2018-12-08 20:23:57,513 client @09.284 server uses: xtest 2018-12-08 20:23:57,706 New unix-domain connection received on /run/user/1002/xpra/fan-100 2018-12-08 20:23:57,708 New unix-domain connection received on /run/xpra/fan-100 2018-12-08 20:24:06,527 Warning: limited clipboard support for CLIPBOARD 2018-12-08 20:24:06,528 virtual method Gtk.Widget.selection_get not implemented And here is what the client logs: [19/5150]mh at fan:~ $ xpra attach ssh:marc at localhost:100 2018-12-08 20:23:48,174 Xpra gtk2 client version 2.4.2-r21077M 64-bit 2018-12-08 20:23:48,175 running on Linux Debian unstable sid 2018-12-08 20:23:48,176 window manager is 'KWin' 2018-12-08 20:23:51,994 GStreamer version 1.14.4 for Python 2.7.15 64-bit 2018-12-08 20:23:52,191 No OpenGL_accelerate module loaded: No module named OpenGL_accelerate 2018-12-08 20:23:52,554 OpenGL enabled with Radeon RX 580 Series (POLARIS10, DRM 3.26.0, 4.18.0-3-amd64, LLVM 7.0.1) 2018-12-08 20:23:52,671 Connected (version 2.0, client OpenSSH_7.9p1) 2018-12-08 20:23:54,937 Authentication (publickey) successful! 2018-12-08 20:23:55,045 keyboard settings: rules=evdev, model=pc101, layout=de 2018-12-08 20:23:55,067 desktop size is 5440x2160 with 1 screen: 2018-12-08 20:23:55,067 :0.0 (1439x571 mm - DPI: 96x96) workarea: 5440x2112 2018-12-08 20:23:55,067 monitor 1 3840x2160 (941x529 mm - DPI: 103x103) 2018-12-08 20:23:55,067 monitor 2 1600x1200 at 3840x0 (408x306 mm - DPI: 99x99) 2018-12-08 20:23:55,067 upscaled by 125%, virtual screen size: 4352x1728 2018-12-08 20:23:55,068 :0.0 (1439x571 mm - DPI: 76x76) workarea: 4352x1690 2018-12-08 20:23:55,068 monitor 1 3072x1728 (941x529 mm - DPI: 82x82) 2018-12-08 20:23:55,068 monitor 2 1280x960 at 3072x0 (408x306 mm - DPI: 79x79) 2018-12-08 20:23:57,343 enabled remote logging 2018-12-08 20:23:57,343 Xpra X11 server version 2.4.2-r21077 64-bit 2018-12-08 20:23:57,344 running on Linux Debian unstable sid 2018-12-08 20:23:57,351 Attached to localhost:22 via ssh 2018-12-08 20:23:57,352 (press Control-C to detach) 2018-12-08 20:23:57,459 server does not support xi input devices 2018-12-08 20:23:57,460 server uses: xtest In the panel applet, I have set Picture => Fixed speed to "Lowest latency". The session information claims that I have 60 ms frame total latency, but it feels like a multiple of that. Any networked RDP session to a Windows machine feels much faster. This is not fun at all. What am I doing wrong? Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 From antoine at nagafix.co.uk Tue Dec 11 04:08:43 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 10 Dec 2018 20:08:43 -0800 Subject: [winswitch] Scaling on Newer Retina displays In-Reply-To: References: Message-ID: <399afeb7-f35a-98c7-ac90-de6fdead2155@nagafix.co.uk> On 03/12/2018 09:29, Shane Williams via shifter-users wrote: > I have a user who is running xpra (probably 2.3) on a new > MacBook Pro with Retina, connecting to an Ubuntu system running xpra > 2.4.2.? Various programs (notably xemacs or various terminals) display > as very small on his Mac (to the point where it's basically impossible > to read the text). Are you using the patched dummy driver from the repository? > We've used the scaling setting to make these > windows larger, Which scaling setting? From the system tray menu? > but by the time text would be large enough to read, > it's gotten so fuzzy/noisy that you can't really read it that way > either. Desktop scaling does dumb upscaling, without any anti-aliasing. > I've read the xpra web page about DPI and followed most of the links, > but it's still not clear to me whether there's a solution other than > scaling. Have you tried playing with the --dpi= switch *before* starting your applications? > Is anyone using a high-DPI Retina display with xpra that > might have suggestions on how to improve the readability/usability in > this situation? I believe what you are looking for is recorded in this ticket: http://xpra.org/trac/ticket/1933 Feel free to subscribe to it and / or add any details if you have any. Cheers, Antoine > > > P.S. I don't have regular access to the laptop, so I can't easily > provide diagnostic information about it. From antoine at nagafix.co.uk Tue Dec 11 04:25:55 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 10 Dec 2018 20:25:55 -0800 Subject: [winswitch] xpra session to other account on localhost In-Reply-To: <20181208193958.GJ3480@torres.zugschlus.de> References: <20181208193958.GJ3480@torres.zugschlus.de> Message-ID: <258992e5-897f-b767-efc1-fab862b7dc88@nagafix.co.uk> On 08/12/2018 11:39, Marc Haber via shifter-users wrote: > Hi, > > I would like to do an xpra connection to an xpra server running under a > different account on the same host. I am running Debian unstable and > have xpra 2.4.2. The box is a strong Six-Core machine with plenty of > free RAM and a fast SSD. > > Running a Firefox browser over this connection is quite slow. I have to > wait multiple hundreds of milliseconds before the reaction to a click > can be seen. Scrolling a window takes like ten seconds until the picture > is completely re-drawn at full resolution. Is that the expected behavior > on a local host with no network involved, plenty of CPU and plenty of > RAM? No. It should be almost indistinguishable from native for all but the most extreme use cases. The most important thing for local connections is to enable mmap. (see mmap command line options and use "-d mmap" to enable debug logging) > I notice that the server complains twice on startup: > 2018-12-08 20:19:08,741 cannot use uinput for virtual devices: > 2018-12-08 20:19:08,741 [Errno 13] Failed to open the uinput device: Permission denied Harmless and completely safe to ignore. > WARNING: no 'numpy' module, HyBi protocol will be slower This one is bogus. Both have been added to the FAQ: https://xpra.org/trac/wiki/FAQ > python-numpy 1.15.4-2 is installed, and the /dev/uinput device is > root:root 600, so it is not accessible by a regular user. Should I make > /dev/uinput root:uinput 660 and put myself into the uinput group? Or is > that a security disk? What is the recommended way to handle uinput? I > don't even know what that is... Don't bother with it. It is only really useful for simulating special input devices. (and I have found some bugs in this code just today) > Here is what the server logs: > marc at fan:~$ xpra start --daemon=no --speaker=off --webcam=no --mdns=no --pulseaudio=no --start=konsole :100 > 2018-12-08 20:20:27,121 cannot use uinput for virtual devices: > 2018-12-08 20:20:27,121 [Errno 13] Failed to open the uinput device: Permission denied (..)> 2018-12-08 20:23:57,360 DPI set to 51 x 48 (wanted 54 x 77) > 2018-12-08 20:23:57,361 you may experience scaling problems, such as huge or small fonts, etc > 2018-12-08 20:23:57,361 to fix this issue, try the dpi switch, or use a patched Xorg dummy driver That's odd. Make sure to use the patched dummy driver from the repository. > 2018-12-08 20:23:57,417 client @09.176 Attached to localhost:22 via ssh > 2018-12-08 20:23:57,417 client @09.177 (press Control-C to detach) > 2018-12-08 20:23:57,510 client @09.284 server does not support xi input devices > 2018-12-08 20:23:57,513 client @09.284 server uses: xtest > 2018-12-08 20:23:57,706 New unix-domain connection received on /run/user/1002/xpra/fan-100 > 2018-12-08 20:23:57,708 New unix-domain connection received on /run/xpra/fan-100 > 2018-12-08 20:24:06,527 Warning: limited clipboard support for CLIPBOARD > 2018-12-08 20:24:06,528 virtual method Gtk.Widget.selection_get not implemented > (..)> In the panel applet, I have set Picture => Fixed speed to "Lowest > latency". The session information claims that I have 60 ms frame total > latency, but it feels like a multiple of that. Any networked RDP session > to a Windows machine feels much faster. Even remote connections should be as fast as RDP, let alone local ones. > > This is not fun at all. What am I doing wrong? Enable mmap and you should be fine. Feel free to create a ticket to fix the non-mmap case. Cheers, Antoine > Greetings > Marc > From mh+shifter-users at zugschlus.de Tue Dec 11 17:44:19 2018 From: mh+shifter-users at zugschlus.de (Marc Haber) Date: Tue, 11 Dec 2018 18:44:19 +0100 Subject: [winswitch] xpra session to other account on localhost In-Reply-To: <258992e5-897f-b767-efc1-fab862b7dc88@nagafix.co.uk> References: <20181208193958.GJ3480@torres.zugschlus.de> <258992e5-897f-b767-efc1-fab862b7dc88@nagafix.co.uk> Message-ID: <20181211174419.GG3480@torres.zugschlus.de> Hi Antoine, On Mon, Dec 10, 2018 at 08:25:55PM -0800, Antoine Martin via shifter-users wrote: > On 08/12/2018 11:39, Marc Haber via shifter-users wrote: > > I would like to do an xpra connection to an xpra server running under a > > different account on the same host. I am running Debian unstable and > > have xpra 2.4.2. The box is a strong Six-Core machine with plenty of > > free RAM and a fast SSD. > > > > Running a Firefox browser over this connection is quite slow. I have to > > wait multiple hundreds of milliseconds before the reaction to a click > > can be seen. Scrolling a window takes like ten seconds until the picture > > is completely re-drawn at full resolution. Is that the expected behavior > > on a local host with no network involved, plenty of CPU and plenty of > > RAM? > No. It should be almost indistinguishable from native for all but the > most extreme use cases. My installation is wide apart from that. > The most important thing for local connections is to enable mmap. (see > mmap command line options and use "-d mmap" to enable debug logging) My system explicitly says mmap disabled, shouldn't that be detected automatically? Both accounts are member of the xpra group. I start the server with ssh marc at localhost xpra start --mmap=/var/tmp/mh-mmap -d mmap --mmap-group --socket-dir=/var/tmp --speaker=off --encoding=png/P --daemon=no --dpi=96 --webcam=no --mdns=no --pulseaudio=no --start=konsole :100 which makes the socket show up in /var/tmp with marc:xpra 660. When I then start the client as xpra attach ssh:marc at localhost:100 --mmap=/var/tmp/mh-mmap --socket-dir=/var/tmp --mmap-group --dpi=96 --desktop-scaling=off -d mmap I see /var/tmp/mh-mmap appear for a short time as mh:mh 775, then I see the server complaining: 2018-12-11 18:36:48,410 client supplied mmap_file=/var/tmp/mh-mmap 2018-12-11 18:36:48,410 mmap supported=True, token=242228041280381797676313904508936308232 2018-12-11 18:36:48,410 using global server specified mmap file path: '/var/tmp/mh-mmap' 2018-12-11 18:36:48,411 Error: cannot access mmap file '/var/tmp/mh-mmap': 2018-12-11 18:36:48,411 [Errno 13] Permission denied: '/var/tmp/mh-mmap' 2018-12-11 18:36:48,411 see mmap-group option? 2018-12-11 18:36:48,411 found client mmap area: None, 0 bytes - min mmap size=67108864 and then the mmap file disappears again. What am I doing wrong? > > I notice that the server complains twice on startup: > > 2018-12-08 20:19:08,741 cannot use uinput for virtual devices: > > 2018-12-08 20:19:08,741 [Errno 13] Failed to open the uinput device: Permission denied > Harmless and completely safe to ignore. > > WARNING: no 'numpy' module, HyBi protocol will be slower > This one is bogus. > > Both have been added to the FAQ: > https://xpra.org/trac/wiki/FAQ Did I miss that or was it added just recently? > > Here is what the server logs: > > marc at fan:~$ xpra start --daemon=no --speaker=off --webcam=no --mdns=no --pulseaudio=no --start=konsole :100 > > 2018-12-08 20:20:27,121 cannot use uinput for virtual devices: > > 2018-12-08 20:20:27,121 [Errno 13] Failed to open the uinput device: Permission denied > (..)> 2018-12-08 20:23:57,360 DPI set to 51 x 48 (wanted 54 x 77) > > 2018-12-08 20:23:57,361 you may experience scaling problems, such as huge or small fonts, etc > > 2018-12-08 20:23:57,361 to fix this issue, try the dpi switch, or use a patched Xorg dummy driver > That's odd. Make sure to use the patched dummy driver from the repository. I'd rather refrain from having to patch my xorg, I can live with giving hard-coded dpi values (which I usually do, but didn't do when creating these mails to make things simpler). > (..)> In the panel applet, I have set Picture => Fixed speed to "Lowest > > latency". The session information claims that I have 60 ms frame total > > latency, but it feels like a multiple of that. Any networked RDP session > > to a Windows machine feels much faster. > Even remote connections should be as fast as RDP, let alone local ones. They're not. > Feel free to create a ticket to fix the non-mmap case. Like "xrdp very slow" and giving the same information like in the thread starting message? Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 From antoine at nagafix.co.uk Tue Dec 11 18:36:00 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 11 Dec 2018 10:36:00 -0800 Subject: [winswitch] xpra session to other account on localhost In-Reply-To: <20181211174419.GG3480@torres.zugschlus.de> References: <20181208193958.GJ3480@torres.zugschlus.de> <258992e5-897f-b767-efc1-fab862b7dc88@nagafix.co.uk> <20181211174419.GG3480@torres.zugschlus.de> Message-ID: (..) >> The most important thing for local connections is to enable mmap. (see >> mmap command line options and use "-d mmap" to enable debug logging) > > My system explicitly says mmap disabled, shouldn't that be detected > automatically? > > Both accounts are member of the xpra group. I start the server with > ssh marc at localhost xpra start --mmap=/var/tmp/mh-mmap -d mmap > --mmap-group --socket-dir=/var/tmp Why change the socket-dir? The defaults should include /run/xpra which should be writable by members of the xpra group. > --speaker=off --encoding=png/P Don't change the encoding unless you really know what you are doing. Especially not for png/P which is very rarely a good option. > --daemon=no --dpi=96 --webcam=no --mdns=no --pulseaudio=no > --start=konsole :100 > which makes the socket show up in /var/tmp with marc:xpra 660. When I > then start the client as > xpra attach ssh:marc at localhost:100 --mmap=/var/tmp/mh-mmap > --socket-dir=/var/tmp --mmap-group --dpi=96 --desktop-scaling=off -d > mmap > I see /var/tmp/mh-mmap appear for a short time as mh:mh 775, then I see > the server complaining: > 2018-12-11 18:36:48,410 client supplied mmap_file=/var/tmp/mh-mmap > 2018-12-11 18:36:48,410 mmap supported=True, token=242228041280381797676313904508936308232 > 2018-12-11 18:36:48,410 using global server specified mmap file path: '/var/tmp/mh-mmap' > 2018-12-11 18:36:48,411 Error: cannot access mmap file '/var/tmp/mh-mmap': > 2018-12-11 18:36:48,411 [Errno 13] Permission denied: '/var/tmp/mh-mmap' > 2018-12-11 18:36:48,411 see mmap-group option? > 2018-12-11 18:36:48,411 found client mmap area: None, 0 bytes - min mmap size=67108864 > and then the mmap file disappears again. I think you need to make the 'xpra' group the primary group of the user. > What am I doing wrong? Not much, cross-user shared memory requires some tweaking. (the feature has not really been updated much for the last 6 years..) To make it easier, we should enhance the mmap-group option so users can specify the group they want to use directly: https://xpra.org/trac/ticket/2075 ie: --mmap-group=xpra >>> I notice that the server complains twice on startup: >>> 2018-12-08 20:19:08,741 cannot use uinput for virtual devices: >>> 2018-12-08 20:19:08,741 [Errno 13] Failed to open the uinput device: Permission denied >> Harmless and completely safe to ignore. >>> WARNING: no 'numpy' module, HyBi protocol will be slower >> This one is bogus. >> >> Both have been added to the FAQ: >> https://xpra.org/trac/wiki/FAQ > > Did I miss that or was it added just recently? Both were added yesterday, but they were available elsewhere on the wiki before that. >>> Here is what the server logs: >>> marc at fan:~$ xpra start --daemon=no --speaker=off --webcam=no --mdns=no --pulseaudio=no --start=konsole :100 >>> 2018-12-08 20:20:27,121 cannot use uinput for virtual devices: >>> 2018-12-08 20:20:27,121 [Errno 13] Failed to open the uinput device: Permission denied >> (..)> 2018-12-08 20:23:57,360 DPI set to 51 x 48 (wanted 54 x 77) >>> 2018-12-08 20:23:57,361 you may experience scaling problems, such as huge or small fonts, etc >>> 2018-12-08 20:23:57,361 to fix this issue, try the dpi switch, or use a patched Xorg dummy driver >> That's odd. Make sure to use the patched dummy driver from the repository. > > I'd rather refrain from having to patch my xorg, You're not patching xorg, just the dummy driver. > I can live with giving > hard-coded dpi values (which I usually do, but didn't do when creating > these mails to make things simpler). OK. Note that there is at least one more non-DPI bug you may encounter with the unpatched driver. >> (..)> In the panel applet, I have set Picture => Fixed speed to "Lowest >>> latency". The session information claims that I have 60 ms frame total >>> latency, but it feels like a multiple of that. Any networked RDP session >>> to a Windows machine feels much faster. >> Even remote connections should be as fast as RDP, let alone local ones. > > They're not. > >> Feel free to create a ticket to fix the non-mmap case. > > Like "xrdp very slow" and giving the same information like in the thread > starting message? That's a good start, more guidelines can be found here: https://xpra.org/trac/wiki/ReportingBugs Based on recent similar reports, you may want to attach the server's debug log with "-d bandwidth,stats" added to the command line. Cheers, Antoine > > Greetings > Marc > From mh+shifter-users at zugschlus.de Sat Dec 15 14:42:45 2018 From: mh+shifter-users at zugschlus.de (Marc Haber) Date: Sat, 15 Dec 2018 15:42:45 +0100 Subject: [winswitch] xpra session to other account on localhost In-Reply-To: References: <20181208193958.GJ3480@torres.zugschlus.de> <258992e5-897f-b767-efc1-fab862b7dc88@nagafix.co.uk> <20181211174419.GG3480@torres.zugschlus.de> Message-ID: <20181215144245.GT3480@torres.zugschlus.de> Hi Antoine, thanks for helping. On Tue, Dec 11, 2018 at 10:36:00AM -0800, Antoine Martin via shifter-users wrote: > > Both accounts are member of the xpra group. I start the server with > > ssh marc at localhost xpra start --mmap=/var/tmp/mh-mmap -d mmap > > --mmap-group --socket-dir=/var/tmp > Why change the socket-dir? Leftover from my experiments to get mmap to work. The mmap file cannot be in /run/xpra though. > The defaults should include /run/xpra which should be writable by > members of the xpra group. > > --speaker=off --encoding=png/P > Don't change the encoding unless you really know what you are doing. > Especially not for png/P which is very rarely a good option. Removed. That made things a bit better, but still miles apart from native X, especially when scrolling. Is Firefox an especially badly behaving application? > > 2018-12-11 18:36:48,411 found client mmap area: None, 0 bytes - min mmap size=67108864 > > and then the mmap file disappears again. > I think you need to make the 'xpra' group the primary group of the user. I am tempted to say that this is an unreasonable suggestion. Traditionally, the primary groups of users have always been the local admin's domain; they're frequently used to control access of other users to one user's home directory. Having arbitrary software demand that the user's primary group is set to a software-specific group is not only an intrusion into that domain it also doesn't scale beyond one single piece of software making that demand. Do you need a bug report for this? > > What am I doing wrong? > Not much, cross-user shared memory requires some tweaking. > (the feature has not really been updated much for the last 6 years..) > > To make it easier, we should enhance the mmap-group option so users can > specify the group they want to use directly: > https://xpra.org/trac/ticket/2075 > ie: --mmap-group=xpra Thanks, that would greatly ease things. > > I'd rather refrain from having to patch my xorg, > You're not patching xorg, just the dummy driver. If you mean /usr/lib/xorg/modules/drivers/dummy_drv.so, that one is, on Debian, from the package xserver-xorg-video-dummy. I could patch that, but I'd prefer to look for a cleaner solution first. > > I can live with giving > > hard-coded dpi values (which I usually do, but didn't do when creating > > these mails to make things simpler). > OK. > Note that there is at least one more non-DPI bug you may encounter with > the unpatched driver. For example? Will the patch be part of a future xorg release? > >> (..)> In the panel applet, I have set Picture => Fixed speed to "Lowest > >>> latency". The session information claims that I have 60 ms frame total > >>> latency, but it feels like a multiple of that. Any networked RDP session > >>> to a Windows machine feels much faster. > >> Even remote connections should be as fast as RDP, let alone local ones. > > > > They're not. > > > >> Feel free to create a ticket to fix the non-mmap case. > > > > Like "xrdp very slow" and giving the same information like in the thread > > starting message? > That's a good start, more guidelines can be found here: > https://xpra.org/trac/wiki/ReportingBugs > Based on recent similar reports, you may want to attach the server's > debug log with "-d bandwidth,stats" added to the command line. Will do in due time. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 From antoine at nagafix.co.uk Sun Dec 16 05:26:40 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 15 Dec 2018 21:26:40 -0800 Subject: [winswitch] xpra session to other account on localhost In-Reply-To: <20181215144245.GT3480@torres.zugschlus.de> References: <20181208193958.GJ3480@torres.zugschlus.de> <258992e5-897f-b767-efc1-fab862b7dc88@nagafix.co.uk> <20181211174419.GG3480@torres.zugschlus.de> <20181215144245.GT3480@torres.zugschlus.de> Message-ID: <2529be75-589c-560e-a195-46c011188d54@nagafix.co.uk> (..) >> The defaults should include /run/xpra which should be writable by >> members of the xpra group. >>> --speaker=off --encoding=png/P >> Don't change the encoding unless you really know what you are doing. >> Especially not for png/P which is very rarely a good option. > > Removed. If making mmap work is not an option, you can try: --encodings=rgb --speed=100 > That made things a bit better, but still miles apart from > native X, especially when scrolling. Is Firefox an especially badly > behaving application? Browsers in general are difficult to handle. Scrolling is also more challenging than most people imagine. >>> 2018-12-11 18:36:48,411 found client mmap area: None, 0 bytes - min mmap size=67108864 >>> and then the mmap file disappears again. >> I think you need to make the 'xpra' group the primary group of the user. > > I am tempted to say that this is an unreasonable suggestion. > Traditionally, the primary groups of users have always been the local > admin's domain; they're frequently used to control access of other users > to one user's home directory. Having arbitrary software demand that the > user's primary group is set to a software-specific group is not only an > intrusion into that domain it also doesn't scale beyond one single piece > of software making that demand. > > Do you need a bug report for this? If you feel strongly about this, you can: * subscribe to that ticket and help in testing the changes * submit patches or add to the ticket etc (..) >>> I'd rather refrain from having to patch my xorg, >> You're not patching xorg, just the dummy driver. > > If you mean /usr/lib/xorg/modules/drivers/dummy_drv.so, that one is, on > Debian, from the package xserver-xorg-video-dummy. I could patch that, > but I'd prefer to look for a cleaner solution first. Using Xvfb instead of Xdummy may work for you, it just doesn't support runtime DPI adjustements. >>> I can live with giving >>> hard-coded dpi values (which I usually do, but didn't do when creating >>> these mails to make things simpler). >> OK. >> Note that there is at least one more non-DPI bug you may encounter with >> the unpatched driver. > > For example? Will the patch be part of a future xorg release? Possibly. But even if I worked on merging this upstream, distributions very rarely apply those patches to their current branch. So the fix would take years to land on user's systems. Cheers, Antoine >>>> (..)> In the panel applet, I have set Picture => Fixed speed to "Lowest >>>>> latency". The session information claims that I have 60 ms frame total >>>>> latency, but it feels like a multiple of that. Any networked RDP session >>>>> to a Windows machine feels much faster. >>>> Even remote connections should be as fast as RDP, let alone local ones. >>> >>> They're not. >>> >>>> Feel free to create a ticket to fix the non-mmap case. >>> >>> Like "xrdp very slow" and giving the same information like in the thread >>> starting message? >> That's a good start, more guidelines can be found here: >> https://xpra.org/trac/wiki/ReportingBugs >> Based on recent similar reports, you may want to attach the server's >> debug log with "-d bandwidth,stats" added to the command line. > > Will do in due time. > > Greetings > Marc > From jimy at gis.de Sun Dec 16 12:33:56 2018 From: jimy at gis.de (jimy) Date: Sun, 16 Dec 2018 13:33:56 +0100 Subject: [winswitch] ubuntu package availability Message-ID: <99963eba-6da2-af52-2e68-f4ef5b128665@gis.de> Hello, for me it seems that the winswitch package for the ubuntu cosmic distribution is not available in the repository. Just to be sure: is this true or is it a misconfiguration on my side? Cheers j From antoine at nagafix.co.uk Thu Dec 20 00:19:53 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 19 Dec 2018 16:19:53 -0800 Subject: [winswitch] ubuntu package availability In-Reply-To: <99963eba-6da2-af52-2e68-f4ef5b128665@gis.de> References: <99963eba-6da2-af52-2e68-f4ef5b128665@gis.de> Message-ID: <76fae5f9-91e4-8ac0-9727-e65a4ae19b42@nagafix.co.uk> On 16/12/2018 04:33, jimy via shifter-users wrote: > > Hello, > > for me it seems that the winswitch package for the ubuntu cosmic > distribution is not available in the repository. > > Just to be sure: is this true or is it a misconfiguration on my side? That was true, this has now been rectified. Thanks for pointing that out. Note that those packages are untested and may or may not work well. I don't have enough time to maintain winswitch properly at the moment. Cheers, Antoine > > Cheers > j