From ajs1 at cam.ac.uk Thu Apr 1 17:18:13 2021 From: ajs1 at cam.ac.uk (Anthony Stone) Date: Thu, 1 Apr 2021 17:18:13 +0100 Subject: [winswitch] Key repeat bug Message-ID: Hello, I'm experiencing odd behaviour while using xpra. Quite often, when I press a key, however briefly, the character seems to be transmitted many times -- as many as 20 times or more. This happens both when working in emacs on the remote machine, and also, less often, on the command line of the remote. It happens to many different characters, including return and backspace (delete), so I don't think it can be a sticky keyboard. Can it be a bug in xpra? It happens often enough in emacs to be a real nuisance. Anthony From antoine at nagafix.co.uk Thu Apr 1 18:00:11 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 2 Apr 2021 00:00:11 +0700 Subject: [winswitch] Key repeat bug In-Reply-To: References: Message-ID: <3e2b31ea-0633-183d-00e8-396863454448@nagafix.co.uk> On 01/04/2021 23:18, Anthony Stone via shifter-users wrote: > Hello, > > I'm experiencing odd behaviour while using xpra. Quite often, when I > press a key, however briefly, the character seems to be transmitted many > times -- as many as 20 times or more. This happens both when working in > emacs on the remote machine, and also, less often, on the command line > of the remote. It happens to many different characters, including return > and backspace? (delete), so I don't think it can be a sticky keyboard. > Can it be a bug in xpra? It happens often enough in emacs to be a real > nuisance. What version and OS are you using on client and server? Have you tried turning keyboard-sync off? What is the latency of your connection? Cheers, Antoine > > Anthony > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users From totaam at xpra.org Fri Apr 2 06:14:15 2021 From: totaam at xpra.org (Antoine Martin) Date: Fri, 2 Apr 2021 12:14:15 +0700 Subject: [winswitch] [ANNOUNCE] xpra-html5 4.1.2 Message-ID: <6b7b5d2c-4149-5cea-14a7-b83f59f14d17@xpra.org> Hi, There were some build and packaging issues with the xpra-html5 4.1.1 release, 4.1.2 should fix all of those. Also, if your Debian repositories are not updating due to an "Origin changed" issue, please see: https://github.com/Xpra-org/xpra/commit/5dd47a01a3fa3a7f9374319a431a4a5d0f0aac37 TLDR, use: apt-get update --allow-releaseinfo-change The source snapshot is at the usual location: https://xpra.org/src/ And also on github: https://github.com/Xpra-org/xpra-html5/releases Cheers Antoine From ajs1 at cam.ac.uk Fri Apr 2 16:23:41 2021 From: ajs1 at cam.ac.uk (Anthony Stone) Date: Fri, 2 Apr 2021 16:23:41 +0100 Subject: [winswitch] Key repeat bug In-Reply-To: <3e2b31ea-0633-183d-00e8-396863454448@nagafix.co.uk> References: <3e2b31ea-0633-183d-00e8-396863454448@nagafix.co.uk> Message-ID: <5ceb3289-1ec6-82b5-a189-c5b4e08f1344@cam.ac.uk> Sorry, I forgot to say: Ubuntu 18.04 and xpra 4.1.1 on client and server. I have tried turning keyboard sync off, and so far have had no more trouble, but that hasn't been very long. Is it reasonable to leave it off indefinitely? It's a fast broadband connection, approaching 100 mb/s. The ping time to the server is around 24 ms. Regards, Anthony On 01/04/2021 18:00, Antoine Martin via shifter-users wrote: > On 01/04/2021 23:18, Anthony Stone via shifter-users wrote: >> Hello, >> >> I'm experiencing odd behaviour while using xpra. Quite often, when I >> press a key, however briefly, the character seems to be transmitted many >> times -- as many as 20 times or more. This happens both when working in >> emacs on the remote machine, and also, less often, on the command line >> of the remote. It happens to many different characters, including return >> and backspace? (delete), so I don't think it can be a sticky keyboard. >> Can it be a bug in xpra? It happens often enough in emacs to be a real >> nuisance. > What version and OS are you using on client and server? > > Have you tried turning keyboard-sync off? > What is the latency of your connection? > > Cheers, > Antoine > >> >> Anthony >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> https://lists.devloop.org.uk/mailman/listinfo/shifter-users > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Fri Apr 2 16:33:18 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 2 Apr 2021 22:33:18 +0700 Subject: [winswitch] Key repeat bug In-Reply-To: <5ceb3289-1ec6-82b5-a189-c5b4e08f1344@cam.ac.uk> References: <3e2b31ea-0633-183d-00e8-396863454448@nagafix.co.uk> <5ceb3289-1ec6-82b5-a189-c5b4e08f1344@cam.ac.uk> Message-ID: <5737d0a6-4217-184f-f981-027d7b4586d0@nagafix.co.uk> On 02/04/2021 22:23, Anthony Stone via shifter-users wrote: > Sorry, I forgot to say: Ubuntu 18.04 and xpra 4.1.1 on client and server. > > I have tried turning keyboard sync off, and so far have had no more > trouble, but that hasn't been very long. Is it reasonable to leave it > off indefinitely? With keyboard-sync turned off, the xpra client will send a pair of key-press + key-release for each key event. It does so even when the key is held down, in which case it will send those event pairs repeatedly. This prevents problems when variations in the latency cause the key-release event to arrive too late (be it CPU overload or actual line latency jitter) but this can also cause some applications to misbehave if they're monitoring the keyboard state rather than just processing key events. This does not affect modifiers which are handled separately. Cheers, Antoine > > It's a fast broadband connection, approaching 100 mb/s. The ping time to > the server is around 24 ms. > > Regards, > Anthony > > On 01/04/2021 18:00, Antoine Martin via shifter-users wrote: >> On 01/04/2021 23:18, Anthony Stone via shifter-users wrote: >>> Hello, >>> >>> I'm experiencing odd behaviour while using xpra. Quite often, when I >>> press a key, however briefly, the character seems to be transmitted many >>> times -- as many as 20 times or more. This happens both when working in >>> emacs on the remote machine, and also, less often, on the command line >>> of the remote. It happens to many different characters, including return >>> and backspace? (delete), so I don't think it can be a sticky keyboard. >>> Can it be a bug in xpra? It happens often enough in emacs to be a real >>> nuisance. >> What version and OS are you using on client and server? >> >> Have you tried turning keyboard-sync off? >> What is the latency of your connection? >> >> Cheers, >> Antoine >> >>> >>> Anthony >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk >>> https://lists.devloop.org.uk/mailman/listinfo/shifter-users >> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> https://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users From vini.ipsmaker at gmail.com Tue Apr 6 12:31:20 2021 From: vini.ipsmaker at gmail.com (=?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?=) Date: Tue, 6 Apr 2021 08:31:20 -0300 Subject: [winswitch] XKB layout Message-ID: How do I use XKB layouts other than US? I'm failing to set this one up. Do I need to set this property on server or client? Do I need to enable an input method (server-side or client-side?)? What env vars (should the default XKB_ vars do?)? Do I need to have some package on server-side to recognize layouts other than US (which one?)? I'm really missing a starting point here. -- Vin?cius dos Santos Oliveira https://vinipsmaker.github.io/ From antoine at nagafix.co.uk Tue Apr 6 12:57:51 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 6 Apr 2021 18:57:51 +0700 Subject: [winswitch] XKB layout In-Reply-To: References: Message-ID: On 06/04/2021 18:31, Vin?cius dos Santos Oliveira via shifter-users wrote: > How do I use XKB layouts other than US? I assume you are referring to the "X11 keyboard" rather than the "xkb" API specifically here. > I'm failing to set this one up. Do > I need to set this property on server or client? Theoretically, you just connect and the server will configure its virtual keyboard to match the one you have on the client. How this is achieved depends on the OS and the server subcommand used. The keyboard layout detected by the client is printed out when you run from the command line, and it is also found in the server log. It should also be possible to change the layout at runtime from xpra's system tray. > Do I need to enable an > input method (server-side or client-side?)? Input-methods are usually transparent to xpra. Xpra will receive keyboard events from the operating system and just forward them. > What env vars (should the > default XKB_ vars do?)? I don't understand this bit. > Do I need to have some package on server-side to > recognize layouts other than US (which one?)? No. > I'm really missing a starting point here. Or, it's possible that you've hit a bug. Please always specify your OS and xpra version at both ends, desktop environment, etc.. as well as the command lines used. The "-d keyboard" debugging switch is probably too verbose, but may help diagnose things. Cheers, Antoine From vini.ipsmaker at gmail.com Tue Apr 6 13:43:15 2021 From: vini.ipsmaker at gmail.com (=?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?=) Date: Tue, 6 Apr 2021 09:43:15 -0300 Subject: [winswitch] XKB layout In-Reply-To: References: Message-ID: Em ter., 6 de abr. de 2021 ?s 08:58, Antoine Martin via shifter-users escreveu: > I assume you are referring to the "X11 keyboard" rather than the "xkb" > API specifically here. That's correct. > Theoretically, you just connect and the server will configure its > virtual keyboard to match the one you have on the client. > How this is achieved depends on the OS and the server subcommand used. > > The keyboard layout detected by the client is printed out when you run > from the command line, and it is also found in the server log. > It should also be possible to change the layout at runtime from xpra's > system tray. The client printed: keyboard settings: rules=evdev, model=pc105, layout=us My layout is layout=us variant=colemak. I can't tell whether it's ignoring the variant. The server printed: 2021-04-06 11:39:17,196 setting keymap: 2021-04-06 11:39:17,197 Error: cannot find rules file 'evdev' 2021-04-06 11:39:17,197 setting keyboard layout to 'us' 2021-04-06 11:39:17,198 Error: cannot find rules file 'evdev' Maybe that's also relevant (on server): 2021-04-06 11:39:18,205 client 1 @07.692 server does not support xi input devices 2021-04-06 11:39:18,211 client 1 @07.700 server uses: xtest So AltGr + e should print ?, but all AltGr combinations are failing. I can't find an option on the systray to set the layout. I also tried to call setxkbmap from a terminal emulator running on server, but it didn't work either. > Input-methods are usually transparent to xpra. > Xpra will receive keyboard events from the operating system and just > forward them. Okay. > > What env vars (should the > > default XKB_ vars do?)? > I don't understand this bit. I meant env vars such as XKB_DEFAULT_LAYOUT, XKB_DEFAULT_VARIANT, XKB_DEFAULT_OPTIONS and XKB_DEFAULT_MODEL > > Do I need to have some package on server-side to > > recognize layouts other than US (which one?)? > No. Okay. So it should be working I guess. > > I'm really missing a starting point here. > Or, it's possible that you've hit a bug. > Please always specify your OS and xpra version at both ends, desktop > environment, etc.. as well as the command lines used. Client is a standard ArchLinux box. The cmd is just xpra attach --socket-dirs=... I'm running X11+awesomewm on client. Server is: guix environment \ --container \ --no-cwd \ --share="$HOME/.var/app/telegram/profile-1=$HOME" \ --network \ --ad-hoc xpra telegram-desktop -- \ xpra \ start \ --daemon=no \ --mdns=no \ --dbus-proxy=no \ --dbus-launch=no \ --socket-permissions=666 \ --bind=auto \ --speaker=off \ --use-display=no \ --xsettings=no \ --forward-xdg-open=no \ --terminate-children=yes \ --exit-with-children=yes \ --start-child=telegram-desktop > The "-d keyboard" debugging switch is probably too verbose, but may help > diagnose things. I'll try that and report any extra information that I find. -- Vin?cius dos Santos Oliveira https://vinipsmaker.github.io/ From totaam at xpra.org Tue Apr 6 14:52:59 2021 From: totaam at xpra.org (Antoine Martin) Date: Tue, 6 Apr 2021 20:52:59 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 4.1.2 Message-ID: Hi, There are no critical fixes in this update but the screen update rate fixes do improve responsiveness. This also fixes compatibility with MacOS Big Sur and nested paramiko ssh tunnels should be working again. The more detailed release notes can be found here: https://github.com/Xpra-org/xpra/blob/v4.1.x/docs/CHANGELOG.md The source snapshots are available on github, pypi as well as: https://xpra.org/src/ Downloads: https://github.com/Xpra-org/xpra/wiki/Download Cheers Antoine From vini.ipsmaker at gmail.com Tue Apr 6 17:35:42 2021 From: vini.ipsmaker at gmail.com (=?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?=) Date: Tue, 6 Apr 2021 13:35:42 -0300 Subject: [winswitch] XKB layout In-Reply-To: References: Message-ID: Em ter., 6 de abr. de 2021 ?s 08:58, Antoine Martin via shifter-users escreveu: > The "-d keyboard" debugging switch is probably too verbose, but may help > diagnose things. Indeed it's very verbose. However I got this: 2021-04-06 16:27:18,986 make_keymask_match: ignored as keynames_for_mod not assigned yet 2021-04-06 16:27:18,987 set_keymap(None, {}, False, False) keyboard_config=KeyboardConfig(us / / None) 2021-04-06 16:27:18,990 current keyboard id=None, new keyboard id=us//None/ab7bde654447bf3655ef60eac19ec0048d52e808 2021-04-06 16:27:18,991 set_keymap(False) layout=us, variant=, options=None, print=, query=rules: evdev\nmodel: pc105\nlayout: us\noptions: caps:capslock\n 2021-04-06 16:27:18,991 setting XKB layout group 0 2021-04-06 16:27:18,992 do_set_keymap using xkbmap_query struct={b'rules': b'evdev', b'model': b'pc105', b'layout': b'us', b'options': b'caps:capslock'} 2021-04-06 16:27:18,993 setting keymap: 2021-04-06 16:27:18,993 setxkbmap(b'evdev', b'pc105', b'us', None, b'caps:capslock') 2021-04-06 16:27:18,993 setxkbmap: using locale=C 2021-04-06 16:27:18,994 setxkbmap: using {'rules': 'evdev', 'model': 'pc105', 'layout': 'us', 'variant': 'NULL', 'options': 'caps:capslock'} 2021-04-06 16:27:18,994 setxkbmap: trying to load rules file b'./rules/evdev'... 2021-04-06 16:27:18,994 setxkbmap: trying to load rules file b'/usr/share/X11/xkb/rules/evdev'... 2021-04-06 16:27:18,995 Error: cannot find rules file 'evdev' 2021-04-06 16:27:18,995 setting keyboard layout to 'us' 2021-04-06 16:27:18,995 setxkbmap(evdev, pc105, us, , None) 2021-04-06 16:27:18,995 setxkbmap: using locale=C 2021-04-06 16:27:18,996 setxkbmap: using {'rules': 'evdev', 'model': 'pc105', 'layout': 'us', 'variant': 'NULL', 'options': 'NULL'} 2021-04-06 16:27:18,996 setxkbmap: trying to load rules file b'./rules/evdev'... 2021-04-06 16:27:18,996 setxkbmap: trying to load rules file b'/usr/share/X11/xkb/rules/evdev'... 2021-04-06 16:27:18,997 Error: cannot find rules file 'evdev' It seems to be ignoring XKB_DEFAULT_VARIANT=colemak. It's only getting the XKB_DEFAULT_LAYOUT=us. colemak is a variant from the /usr/share/X11/xkb/symbols/us layout (totally different tho). Did I hit a bug then? -- Vin?cius dos Santos Oliveira https://vinipsmaker.github.io/ From antoine at nagafix.co.uk Tue Apr 6 18:06:48 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 7 Apr 2021 00:06:48 +0700 Subject: [winswitch] XKB layout In-Reply-To: References: Message-ID: <877bd308-7f38-5fd6-3c57-c5559ca5ac95@nagafix.co.uk> > 2021-04-06 16:27:18,991 set_keymap(False) layout=us, variant=, The variant is missing here. > 2021-04-06 16:27:18,994 setxkbmap: using {'rules': 'evdev', 'model': > 'pc105', 'layout': 'us', 'variant': 'NULL', 'options': > 'caps:capslock'} And here. So the first problem is that the client isn't detecting the variant properly. You should be able to override this faulty detection with: --keyboard-variant=colemak > 2021-04-06 16:27:18,994 setxkbmap: trying to load rules file > b'/usr/share/X11/xkb/rules/evdev'... > 2021-04-06 16:27:18,995 Error: cannot find rules file 'evdev' That's a different problem, which may impede xpra's ability to set the correct keymap once the variant is correctly detected or specified. The evdev rules file should exist at the path specified. > It seems to be ignoring XKB_DEFAULT_VARIANT=colemak. It's only getting > the XKB_DEFAULT_LAYOUT=us. > > colemak is a variant from the /usr/share/X11/xkb/symbols/us layout > (totally different tho). Did I hit a bug then? Possibly. Can you please create a github issue here: https://github.com/Xpra-org/xpra/issues/new/choose with more details as per: https://github.com/Xpra-org/xpra/wiki/Reporting-Bugs So that I can try to reproduce the problem on my test systems. Cheers, Antoine From vini.ipsmaker at gmail.com Tue Apr 6 19:17:29 2021 From: vini.ipsmaker at gmail.com (=?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?=) Date: Tue, 6 Apr 2021 15:17:29 -0300 Subject: [winswitch] XKB layout In-Reply-To: <877bd308-7f38-5fd6-3c57-c5559ca5ac95@nagafix.co.uk> References: <877bd308-7f38-5fd6-3c57-c5559ca5ac95@nagafix.co.uk> Message-ID: Em ter., 6 de abr. de 2021 ?s 14:06, Antoine Martin escreveu: > So the first problem is that the client isn't detecting the variant > properly. You should be able to override this faulty detection with: > --keyboard-variant=colemak Doing this alone won't fix the problem. > > 2021-04-06 16:27:18,994 setxkbmap: trying to load rules file > > b'/usr/share/X11/xkb/rules/evdev'... > > 2021-04-06 16:27:18,995 Error: cannot find rules file 'evdev' > That's a different problem, which may impede xpra's ability to set the > correct keymap once the variant is correctly detected or specified. > The evdev rules file should exist at the path specified. Nor exposing this directory by itself will fix the problem neither. However doing both (forcing --keyboard-variant=colemak and invoking guix with --expose=/usr/share/X11/xkb/rules) does fix the problem. > Possibly. Can you please create a github issue here: > https://github.com/Xpra-org/xpra/issues/new/choose Do you still want a bug report given the above fixed it? -- Vin?cius dos Santos Oliveira https://vinipsmaker.github.io/ From vini.ipsmaker at gmail.com Tue Apr 6 19:47:49 2021 From: vini.ipsmaker at gmail.com (=?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?=) Date: Tue, 6 Apr 2021 15:47:49 -0300 Subject: [winswitch] Where is the mmap file created? Message-ID: I'm running a xpra server in a container where only whitelisted files are shared between guest and host. I'd like to use the mmap mode as both are really running in the same computer, but I'm failing to use --mmap=yes. I'm failing to find where the server creates mmap files. Setting the XPRA_MMAP_DIR env seems to have no effect. I don't find any created files in the directory I point it to. Any hints on how to make this setup work? -- Vin?cius dos Santos Oliveira https://vinipsmaker.github.io/ From antoine at nagafix.co.uk Wed Apr 7 08:16:50 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 7 Apr 2021 14:16:50 +0700 Subject: [winswitch] XKB layout In-Reply-To: References: <877bd308-7f38-5fd6-3c57-c5559ca5ac95@nagafix.co.uk> Message-ID: <6dc79088-b265-2d76-1922-dea7c2d31082@nagafix.co.uk> On 07/04/2021 01:17, Vin?cius dos Santos Oliveira wrote: > Em ter., 6 de abr. de 2021 ?s 14:06, Antoine Martin > escreveu: >> So the first problem is that the client isn't detecting the variant >> properly. You should be able to override this faulty detection with: >> --keyboard-variant=colemak > > Doing this alone won't fix the problem. Yes. There are two problems. >>> 2021-04-06 16:27:18,994 setxkbmap: trying to load rules file >>> b'/usr/share/X11/xkb/rules/evdev'... >>> 2021-04-06 16:27:18,995 Error: cannot find rules file 'evdev' >> That's a different problem, which may impede xpra's ability to set the >> correct keymap once the variant is correctly detected or specified. >> The evdev rules file should exist at the path specified. > > Nor exposing this directory by itself will fix the problem neither. > > However doing both (forcing --keyboard-variant=colemak and invoking > guix with --expose=/usr/share/X11/xkb/rules) does fix the problem. So this isn't a standard installation at all, is it? If you are intentionally hiding system directories then you should be expecting problems and look there first. >> Possibly. Can you please create a github issue here: >> https://github.com/Xpra-org/xpra/issues/new/choose > > Do you still want a bug report given the above fixed it? The keyboard layout and variant should be detected correctly. You can run: xpra/platform/keyboard.py To see what comes out. This may not work properly under wayland, which does not have an API for querying those settings. Cheers, Antoine From antoine at nagafix.co.uk Wed Apr 7 08:29:59 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 7 Apr 2021 14:29:59 +0700 Subject: [winswitch] Where is the mmap file created? In-Reply-To: References: Message-ID: On 07/04/2021 01:47, Vin?cius dos Santos Oliveira via shifter-users wrote: > I'm running a xpra server in a container where only whitelisted files > are shared between guest and host. I'd like to use the mmap mode as > both are really running in the same computer, but I'm failing to use > --mmap=yes. > > I'm failing to find where the server creates mmap files. Setting the > XPRA_MMAP_DIR env seems to have no effect. I don't find any created > files in the directory I point it to. > > Any hints on how to make this setup work? $ xpra -h | grep mmap= --mmap=yes|no|mmap-filename So you can use: xpra start --mmap=/the/server/path xpra attach --mmap=/the/client/path And make sure that both paths resolve to the shared area where mmap files can be created. This may well require changes to the IPC settings in your container tool to allow mmapped files. YMMV. The difference in performance is huge, so it is worth doing. Cheers, Antoine > -- > Vin?cius dos Santos Oliveira > https://vinipsmaker.github.io/ From vini.ipsmaker at gmail.com Wed Apr 7 11:09:37 2021 From: vini.ipsmaker at gmail.com (=?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?=) Date: Wed, 7 Apr 2021 07:09:37 -0300 Subject: [winswitch] XKB layout In-Reply-To: <6dc79088-b265-2d76-1922-dea7c2d31082@nagafix.co.uk> References: <877bd308-7f38-5fd6-3c57-c5559ca5ac95@nagafix.co.uk> <6dc79088-b265-2d76-1922-dea7c2d31082@nagafix.co.uk> Message-ID: Em qua., 7 de abr. de 2021 ?s 04:16, Antoine Martin escreveu: > > However doing both (forcing --keyboard-variant=colemak and invoking > > guix with --expose=/usr/share/X11/xkb/rules) does fix the problem. > So this isn't a standard installation at all, is it? guix installs stuff into /gnu/store. > If you are intentionally hiding system directories then you should be > expecting problems and look there first. X11 files are there in the guest, but under a different directory (/gnu/store). guix doesn't use /usr. If xpra uses some env var to check where X11 files should be, I can open an issue in guix and they'll make sure this env is set when xpra is run. What I did by passing --expose was to share files from my ArchLinux box. I'll be using this hack since it worked. Anyway, I did expect problems, but I didn't know how to debug. Therefore I came here. > The keyboard layout and variant should be detected correctly. > You can run: > xpra/platform/keyboard.py > To see what comes out. Okay, I filled an issue in the tracker: https://github.com/Xpra-org/xpra/issues/3075 > This may not work properly under wayland, which does not have an API for > querying those settings. I'm using X11. Wayland, never again. -- Vin?cius dos Santos Oliveira https://vinipsmaker.github.io/ From antoine at nagafix.co.uk Wed Apr 7 13:18:43 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 7 Apr 2021 19:18:43 +0700 Subject: [winswitch] XKB layout In-Reply-To: References: <877bd308-7f38-5fd6-3c57-c5559ca5ac95@nagafix.co.uk> <6dc79088-b265-2d76-1922-dea7c2d31082@nagafix.co.uk> Message-ID: On 07/04/2021 17:09, Vin?cius dos Santos Oliveira wrote: > Em qua., 7 de abr. de 2021 ?s 04:16, Antoine Martin > escreveu: >>> However doing both (forcing --keyboard-variant=colemak and invoking >>> guix with --expose=/usr/share/X11/xkb/rules) does fix the problem. >> So this isn't a standard installation at all, is it? > > guix installs stuff into /gnu/store. > >> If you are intentionally hiding system directories then you should be >> expecting problems and look there first. > > X11 files are there in the guest, but under a different directory > (/gnu/store). guix doesn't use /usr. If xpra uses some env var to > check where X11 files should be, I can open an issue in guix and > they'll make sure this env is set when xpra is run. No, there is nothing you could possibly do in xpra. This file location is set at build-time in the X11 server. (IIRC, it belongs in libxkbfile) Your OS and / or guix should configure X11 correctly. > What I did by passing --expose was to share files from my ArchLinux > box. I'll be using this hack since it worked. > > Anyway, I did expect problems, but I didn't know how to debug. > Therefore I came here. > >> The keyboard layout and variant should be detected correctly. >> You can run: >> xpra/platform/keyboard.py >> To see what comes out. > > Okay, I filled an issue in the tracker: > https://github.com/Xpra-org/xpra/issues/3075 Thanks! Antoine > >> This may not work properly under wayland, which does not have an API for >> querying those settings. > > I'm using X11. > > Wayland, never again. > > From vini.ipsmaker at gmail.com Wed Apr 7 14:04:53 2021 From: vini.ipsmaker at gmail.com (=?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?=) Date: Wed, 7 Apr 2021 10:04:53 -0300 Subject: [winswitch] Where is the mmap file created? In-Reply-To: References: Message-ID: Em qua., 7 de abr. de 2021 ?s 04:30, Antoine Martin via shifter-users escreveu: > $ xpra -h | grep mmap= > --mmap=yes|no|mmap-filename I saw the manpage. > So you can use: > xpra start --mmap=/the/server/path > xpra attach --mmap=/the/client/path And I tried that. The path should be a directory path right? > And make sure that both paths resolve to the shared area where mmap > files can be created. I'll assume it didn't work due to this error (file creation error). > This may well require changes to the IPC settings in your container tool > to allow mmapped files. YMMV. How does xpra create mmap files? I'm skimming over xpra/net/mmap_pipe.py, but I'm failing to detect any special operation that isn't allowed in the container. -- Vin?cius dos Santos Oliveira https://vinipsmaker.github.io/ From antoine at nagafix.co.uk Wed Apr 7 14:32:24 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 7 Apr 2021 20:32:24 +0700 Subject: [winswitch] Where is the mmap file created? In-Reply-To: References: Message-ID: <21d0aa10-7075-0654-cc06-96a7c6136580@nagafix.co.uk> On 07/04/2021 20:04, Vin?cius dos Santos Oliveira wrote: > Em qua., 7 de abr. de 2021 ?s 04:30, Antoine Martin via shifter-users > escreveu: >> $ xpra -h | grep mmap= >> --mmap=yes|no|mmap-filename > > I saw the manpage. > >> So you can use: >> xpra start --mmap=/the/server/path >> xpra attach --mmap=/the/client/path > > And I tried that. The path should be a directory path right? No, it should be the exact filename you want to use. >> And make sure that both paths resolve to the shared area where mmap >> files can be created. > > I'll assume it didn't work due to this error (file creation error). Please always include the full command lines used and exact error messages shown. You can extra verbose debug logging by adding "-d mmap" to your command line. >> This may well require changes to the IPC settings in your container tool >> to allow mmapped files. YMMV. > > How does xpra create mmap files? I'm skimming over > xpra/net/mmap_pipe.py, but I'm failing to detect any special operation > that isn't allowed in the container. There is nothing special. The magic happens in: https://docs.python.org/3/library/mmap.html#mmap.mmap Cheers, Antoine > > > -- > Vin?cius dos Santos Oliveira > https://vinipsmaker.github.io/ > From vini.ipsmaker at gmail.com Wed Apr 7 14:42:23 2021 From: vini.ipsmaker at gmail.com (=?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?=) Date: Wed, 7 Apr 2021 10:42:23 -0300 Subject: [winswitch] Where is the mmap file created? In-Reply-To: <21d0aa10-7075-0654-cc06-96a7c6136580@nagafix.co.uk> References: <21d0aa10-7075-0654-cc06-96a7c6136580@nagafix.co.uk> Message-ID: Em qua., 7 de abr. de 2021 ?s 10:32, Antoine Martin escreveu: > > And I tried that. The path should be a directory path right? > No, it should be the exact filename you want to use. Okay, it worked this time. How does this work? Can I connect multiple clients to the same server? Won't there be a problem using the same file for mmaped transfers? -- Vin?cius dos Santos Oliveira https://vinipsmaker.github.io/ From antoine at nagafix.co.uk Wed Apr 7 16:20:08 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 7 Apr 2021 22:20:08 +0700 Subject: [winswitch] Where is the mmap file created? In-Reply-To: References: <21d0aa10-7075-0654-cc06-96a7c6136580@nagafix.co.uk> Message-ID: <2e146de5-12ca-2d5d-1a7e-3e18de20d913@nagafix.co.uk> On 07/04/2021 20:42, Vin?cius dos Santos Oliveira wrote: > Em qua., 7 de abr. de 2021 ?s 10:32, Antoine Martin > escreveu: >>> And I tried that. The path should be a directory path right? >> No, it should be the exact filename you want to use. > > Okay, it worked this time. How does this work? Can I connect multiple > clients to the same server? Won't there be a problem using the same > file for mmaped transfers? I had never thought there would be much point in having multiple users connected to a local session with mmap. But since it was trivial to add, you can now do that: https://github.com/Xpra-org/xpra/commit/ef936f461996915547141e8d02c15a57516d5ff0 Just run: xpra start --mmap=/path/to/mmap-dir/ And attach as before, using a separate mmap file for each client. Cheers, Antoine From antoine at nagafix.co.uk Wed Apr 7 17:05:12 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 7 Apr 2021 23:05:12 +0700 Subject: [winswitch] XKB layout In-Reply-To: References: <877bd308-7f38-5fd6-3c57-c5559ca5ac95@nagafix.co.uk> <6dc79088-b265-2d76-1922-dea7c2d31082@nagafix.co.uk> Message-ID: <928ea6b6-ec22-4f2a-a240-c2ecaa07c794@nagafix.co.uk> >> X11 files are there in the guest, but under a different directory >> (/gnu/store). guix doesn't use /usr. If xpra uses some env var to >> check where X11 files should be, I can open an issue in guix and >> they'll make sure this env is set when xpra is run. > No, there is nothing you could possibly do in xpra. Scratch that - sorry for the misinformation: https://github.com/Xpra-org/xpra/commit/d4816b7971172e90055feb45834aee688626c359 You can now override the path with: XPRA_XKB_CONFIG_ROOT=/gnu/store/wherever xpra start .. >> What I did by passing --expose was to share files from my ArchLinux >> box. I'll be using this hack since it worked. >> >> Anyway, I did expect problems, but I didn't know how to debug. >> Therefore I came here. >> >>> The keyboard layout and variant should be detected correctly. >>> You can run: >>> xpra/platform/keyboard.py >>> To see what comes out. >> >> Okay, I filled an issue in the tracker: >> https://github.com/Xpra-org/xpra/issues/3075 Fixed! Cheers, Antoine > Thanks! > > Antoine > >> >>> This may not work properly under wayland, which does not have an API for >>> querying those settings. >> >> I'm using X11. >> >> Wayland, never again. >> >> > From vini.ipsmaker at gmail.com Wed Apr 7 17:44:34 2021 From: vini.ipsmaker at gmail.com (=?UTF-8?Q?Vin=C3=ADcius_dos_Santos_Oliveira?=) Date: Wed, 7 Apr 2021 13:44:34 -0300 Subject: [winswitch] XKB layout In-Reply-To: <928ea6b6-ec22-4f2a-a240-c2ecaa07c794@nagafix.co.uk> References: <877bd308-7f38-5fd6-3c57-c5559ca5ac95@nagafix.co.uk> <6dc79088-b265-2d76-1922-dea7c2d31082@nagafix.co.uk> <928ea6b6-ec22-4f2a-a240-c2ecaa07c794@nagafix.co.uk> Message-ID: Em qua., 7 de abr. de 2021 ?s 13:05, Antoine Martin escreveu: > https://github.com/Xpra-org/xpra/commit/d4816b7971172e90055feb45834aee688626c359 > > You can now override the path with: > XPRA_XKB_CONFIG_ROOT=/gnu/store/wherever xpra start .. Thanks. I'll submit an issue to the guix tracker once a new xpra release is out. -- Vin?cius dos Santos Oliveira https://vinipsmaker.github.io/ From eric.lemings at gmail.com Thu Apr 15 14:49:39 2021 From: eric.lemings at gmail.com (Eric Lemings) Date: Thu, 15 Apr 2021 07:49:39 -0600 Subject: [winswitch] Pulseaudio in Xpra 3 on RHEL 7 Message-ID: Greetings all, Was hoping someone could shed some light on this. I'm using Xpra 3.0.9 on RHEL 7 systems. When I launch an `xpra start` command even with the --pulseaudio=no option, the xpra process still launches pactl and pulseaudio child processes. In my environment, there seem to be DBus/SELinux issues that cause these child processes to hang so the Xpra session takes about 5 minutes to (timeout I assume and) go from UNKNOWN to LIVE. Is there some other way to avoid the pulseaudio checks in an Xpra start command? Thanks, Eric. From antoine at nagafix.co.uk Thu Apr 15 15:48:10 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 15 Apr 2021 21:48:10 +0700 Subject: [winswitch] Pulseaudio in Xpra 3 on RHEL 7 In-Reply-To: References: Message-ID: On 15/04/2021 20:49, Eric Lemings via shifter-users wrote: > Greetings all, > > Was hoping someone could shed some light on this. I'm using Xpra 3.0.9 on > RHEL 7 systems. Let's start here: the current version for RHEL7 is 3.0.13 > When I launch an `xpra start` command even with the --pulseaudio=no option, > the xpra process still launches pactl and pulseaudio child processes. In > my environment, there seem to be DBus/SELinux issues that cause these child > processes to hang so the Xpra session takes about 5 minutes to (timeout I > assume and) go from UNKNOWN to LIVE. > > Is there some other way to avoid the pulseaudio checks in an Xpra start > command? What happens is that xpra runs "pactl" (ie: "pactl info") to figure out the system's audio configuration - even if pulseaudio was not started by xpra. Any calls to "pactl" seem to have the side effect of starting an instance of pulseaudio if one isn't running yet... On my test systems, this takes mere milliseconds to run. If your system takes minutes, perhaps you should figure out what it's getting stuck on and fix that. You can ensure that this audio probing does not happen by adding: "--speaker=no --microphone=no" to your command line. This will completely skip the loading of all the audio modules. An easier way might be to just completely remove the audio components from your installation: yum remove python2-xpra-audio Cheers, Antoine > > Thanks, > Eric. > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From totaam at xpra.org Wed Apr 21 11:27:59 2021 From: totaam at xpra.org (Antoine Martin) Date: Wed, 21 Apr 2021 17:27:59 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 4.1.3 Message-ID: <6b14114b-a262-8491-4077-d80e7dc7af5c@xpra.org> Hi, Most of the fixes in this release are fairly minor. There is no urgency to update if you were not affected by these bugs. The more detailed release notes can be found here: https://github.com/Xpra-org/xpra/releases/tag/v4.1.3 Downloads: https://github.com/Xpra-org/xpra/wiki/Download Cheers Antoine From yonatan.zaken at gmail.com Wed Apr 21 14:43:09 2021 From: yonatan.zaken at gmail.com (yonatan zaken) Date: Wed, 21 Apr 2021 16:43:09 +0300 Subject: [winswitch] xpra core files generated Message-ID: Hi All, My platform: Linux Kubuntu 14 xpra version: xpra v1.0.12-r19800 When using the xpra utility I am receiving core files regularly. I tried to run the core files through the gdb gnu debugger via the following command: gdb /usr/bin/xpra core.xpra.23367 The output is as follows: ================================================ user at hostname:~> gdb /usr/bin/xpra core.xpra.23367 GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... "/usr/bin/xpra": not in executable format: File format not recognized [New LWP 23367] [New LWP 23664] [New LWP 23669] [New LWP 23934] [New LWP 23660] [New LWP 23663] [New LWP 23665] [New LWP 23670] Core was generated by `/usr/bin/python /usr/bin/xpra _sound_play - - vorbis+mka 1.0'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00000000005ac13d in ?? () ================================================ Using this information, does anyone have an idea how to prevent the generation of these core files? I checked multiple core files they all generate the same output from the debugger *Cheers,* *Yonatan* From antoine at nagafix.co.uk Wed Apr 21 15:13:21 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 21 Apr 2021 21:13:21 +0700 Subject: [winswitch] xpra core files generated In-Reply-To: References: Message-ID: <21ae3374-3242-8e05-5e71-17a58d596815@nagafix.co.uk> On 21/04/2021 20:43, yonatan zaken via shifter-users wrote: > Hi All, > > My platform: Linux Kubuntu 14 > xpra version: xpra v1.0.12-r19800 > > When using the xpra utility I am receiving core files regularly. > I tried to run the core files through the gdb gnu debugger via the > following command: > > gdb /usr/bin/xpra core.xpra.23367 (..) > Core was generated by `/usr/bin/python /usr/bin/xpra _sound_play - - > vorbis+mka 1.0'. > > Program terminated with signal SIGSEGV, Segmentation fault. You can try running it by hand with full debug enabled to see why / where it is crashing: XPRA_ALL_DEBUG=1 xpra _sound_play vorbis+mka 1.0 > Using this information, does anyone have an idea how to prevent the > generation of these core files? Yes. Disable all audio playback: --speaker=no > I checked multiple core files they all generate the same output from the > debugger You're using an EOL OS... it's quite possible that your gstreamer installation is in a bad state. Cheers, Antoine > > *Cheers,* > *Yonatan* > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From luca.manganelli at comune.trento.it Tue Apr 27 08:42:54 2021 From: luca.manganelli at comune.trento.it (Luca Manganelli) Date: Tue, 27 Apr 2021 09:42:54 +0200 Subject: [winswitch] Problems with recent version of xpra Message-ID: Hello, with xpra I could connect via ssh from Windows to my Fedora 33 (either using 4.1.1 version). Now it doesn't work anymore: the windows client states "could not connect", but I can ssh to Fedora with the normal putty. From antoine at nagafix.co.uk Tue Apr 27 08:54:58 2021 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 27 Apr 2021 14:54:58 +0700 Subject: [winswitch] Problems with recent version of xpra In-Reply-To: References: Message-ID: <5bb090e8-0c1b-2447-1f1e-ac0b15896e30@nagafix.co.uk> On 27/04/2021 14:42, Luca Manganelli via shifter-users wrote: > Hello, > > with xpra I could connect via ssh from Windows to my Fedora 33 (either > using 4.1.1 version). The current version is 4.1.3, what version are you using now? > Now it doesn't work anymore: the windows client states "could not connect", > but I can ssh to Fedora with the normal putty. Please try to connect via the command line and post the output: Xpra_cmd attach ssh://username at host/ --debug ssh Cheers, Antoine