From it.dishantrawat at gmail.com Sun Oct 4 09:02:29 2020 From: it.dishantrawat at gmail.com (Dishant Rawat) Date: Sun, 4 Oct 2020 01:02:29 -0700 Subject: [winswitch] Starting with XPRA Message-ID: Hey Guys, I am new to XPRA, I read some docs and watched videos but I still don't know from where to start . Till now what I did : Installed client on Mac which is working but cannot start any session as its not supported on mac. Question : How to start a server on Mac ? The brew installation doesn't work for me so I could start the server through terminal. Is there any doc for mac , step wise which can be followed? Thanks in advance. From antoine at nagafix.co.uk Sun Oct 4 09:45:34 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 4 Oct 2020 15:45:34 +0700 Subject: [winswitch] Starting with XPRA In-Reply-To: References: Message-ID: <819c4159-6dc7-52a2-a054-c861f0bf43ff@nagafix.co.uk> On 04/10/2020 15:02, Dishant Rawat via shifter-users wrote: > Hey Guys, > > I am new to XPRA, I read some docs and watched videos but I still > don't know from where to start . Till now what I did : > Installed client on Mac which is working but cannot start any session as > its not supported on mac. > > Question : How to start a server on Mac ? You cannot start seamless ("xpra start") or desktop ("xpra start-desktop") sessions on a mac. You can only start a shadow session of your existing desktop: Xpra shadow > The brew installation doesn't > work for me so I could start the server through terminal. This not a supported installation method. Try the binaries from xpra.org instead. > Is there any doc for mac , step wise which can be followed? There is nothing really specific to macs, apart from the fact that you can't start seamless or desktop sessions. (and this is also true for MS Windows) Cheers, Antoine > Thanks in > advance. > _______________________________________________ > 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 Oct 7 10:38:05 2020 From: totaam at xpra.org (Antoine Martin) Date: Wed, 7 Oct 2020 16:38:05 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 3.0.12 LTS: many fixes, one critical Message-ID: Hi, This update fixes quite a few bugs, mostly the same ones that were included in the 4.0.4 release with just a couple of extra fixes for the HTML5 client and in the python client with nested openssh connections. The key fixes are the same: * a server-side memory leak * an auto-refresh bug causing some windows to remain blurry * errors with some 64-bit MS Windows client configurations * file-transfer fixes For those on the 3.x LTS branch, updating is strongly recommended. Note: just like v4.0.4, to prevent some X11 desktop crashes seen only with Debian and Ubuntu, the packaging for those two distributions has been changed to use Xvfb instead of Xdummy. This may result in less accurate DPI and font sizes. You can switch back to Xdummy by modifying /etc/xpra/conf.d/55_server_x11.conf (this is not a bug in xpra but the fact that xpra can trigger it makes it our problem) Full release notes: * fix memory leak with 'scroll' encoding * fix proxy control socket becoming unresponsive after errors * fix proxy shutdown * fix shadow server dbus call causing all further "xpra info" requests to fail * fix error in dbus debug logging * fix client using an invalid list of encodings * fix NVENC encoder (profile errors, cleanup race condition) * fix unmanaged X11 message call which could cause GTK to crash when it fails * fix missing auto-refresh leaving a blurry image * fix missing pixels on the edge of video areas in 'auto' encoding mode * fix connection errors with notifications disabled on the server * fix 'sync-xvfb' option: setup error, non-standard bit depth support * fix incomplete repaints when window contents have padding * fix missing system tray on Ubuntu 18.04 * fix workspace spurious warnings on 64-bit X11 systems * fix event handler with 64-bit MS Windows builds * fix named-pipe server clash * fix error handing in MS Windows printer query API * fix keyboard overflow error on MS Windows * fix ssl server hostname verification errors * fix ssl certificate verification error detection with python2 builds * fix missing 'openssl' dependency in DEB packages * fix syntax errors when using connections using nested ssh tunnels * fix syntax error in HTML5 client maximize toggle * fix HTML5 client keyboard layout detection with Internet Explorer * fix HTML5 audio forwarding compatibility with Safari * fix HTML5 (un)fullscreen * fix window re-initialization errors * fix keysym mapping with Xkb and some specific configurations * fix right click on systray using the gtk StatusIcon implementation * fix small file transfers not showing as completed * fix file-transfer identifiers getting lost * fix int overflow errors on some 64-bit mswindows installations * fix hard to trigger mmap memory leak * add support for sm86 architecture with CUDA 11.1 * allow 'pager' source indication value to activate window server-side * fix websocket compatibility with some client / middleware * switch to Xvfb on Debian and Ubuntu * workaround corruption on some windows when maximized * workaround more pyxdg bugs * MacOS and MS Windows: fix security issue in brotli decompression * bundle mimetypes module (MacOS and MS Windows) * ignore plink packaging errors with 32-bit MS Windows builds * disable swscale on 32-bit MS Windows builds (prevent crashes) * tabs mixed with spaces (potential for bug) * add missing DEB dependency The source: https://xpra.org/src/ Downloads: https://xpra.org/trac/wiki/Download Cheers Antoine From blacksburgturkey at gmail.com Fri Oct 16 19:03:40 2020 From: blacksburgturkey at gmail.com (Richard Powell) Date: Fri, 16 Oct 2020 14:03:40 -0400 Subject: [winswitch] XPRA Windows client Message-ID: Hello, I am testing the xpra windows client version 4.0.4 Python 3.8 64bit. The program has the ability to Save connection details. Currently, this action saves connection details, password included, in a plain text .xpra file. Is there a way to have the xpra client save this connection information in encrypted text to prevent exposing password? If not, is there a way to configure the Windows client to disable saving the password of a connection, or disable saving connections completely? From antoine at nagafix.co.uk Sat Oct 17 17:45:42 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 17 Oct 2020 23:45:42 +0700 Subject: [winswitch] XPRA Windows client In-Reply-To: References: Message-ID: <859f0f8f-8cd8-c4ac-f725-216fee26b111@nagafix.co.uk> On 17/10/2020 01:03, Richard Powell via shifter-users wrote: > Hello, I am testing the xpra windows client version 4.0.4 Python 3.8 > 64bit. The program has the ability to Save connection details. Currently, > this action saves connection details, password included, in a plain text > .xpra file. Is there a way to have the xpra client save this connection > information in encrypted text to prevent exposing password? Since this encryption would need to be reversible for the password to be used for authentication, it would be more akin to obfuscation and of limited practical effectiveness in preventing the password from being exposed. > If not, is > there a way to configure the Windows client to disable saving the password > of a connection, or disable saving connections completely? It could be done reasonably easily but I fail to see how that helps. The password field must have been populated by the user or by a connection file, which means that the password is already known to the user. Is it not? Perhaps another authentication module would be preferable for what you are trying to achieve? (gss / kerberos or even u2f?) Support for one-time passwords should be trivial to add: https://xpra.org/trac/ticket/2906 Cheers, Antoine From mike at cchtml.com Thu Oct 22 21:39:13 2020 From: mike at cchtml.com (Michael Cronenworth) Date: Thu, 22 Oct 2020 15:39:13 -0500 Subject: [winswitch] Disable TCP on systemd socket activation Message-ID: <78d29d9d-3bdb-40f2-3cb3-012992616619@cchtml.com> Hi, I'm using the Xpra 4.x packages from the official Xpra repo on RHEL 8. I'm also using the provided systemd socket and service. This enables the listening socket at port 14500 to respond to plain TCP and SSL requests. I would like to disable support for plain TCP, but I do not see a combination of config options that works with socket activation. Am I right or wrong? Thanks, Michael From tmesposito00 at gmail.com Fri Oct 23 05:08:35 2020 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Fri, 23 Oct 2020 00:08:35 -0400 Subject: [winswitch] capslock acting like shiftlock? Message-ID: We finally upgraded from Centos 6.6 to 7.6 at work (it will be YEARS before we see 8.x) and I took the opportunity to upgrade xpra to 3.x. So far, everything seems to be working well, except for some strange keyboard behavior. My capslock key is acting as shiftlock (i.e. effects ALL keys, not just letters). I DON'T get this behavior in a VNC session on the same machine. I have compared xmodmap and setxkbmap settings between my vnc and xpra sessions and haven't found any differences that seem like they could explain this behavior. Any ideas? From tmesposito00 at gmail.com Fri Oct 23 05:44:42 2020 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Fri, 23 Oct 2020 00:44:42 -0400 Subject: [winswitch] capslock acting like shiftlock? In-Reply-To: References: Message-ID: If I had to guess, I'd say the the xpra client is translating the capslock to a shift before it ever gets to the server. Is that possible? If so, how can I verify that this is happening and how would I fix it? On Fri, Oct 23, 2020, 12:08 AM Thomas Esposito wrote: > We finally upgraded from Centos 6.6 to 7.6 at work (it will be YEARS > before we see 8.x) and I took the opportunity to upgrade xpra to 3.x. > > So far, everything seems to be working well, except for some strange > keyboard behavior. My capslock key is acting as shiftlock (i.e. effects ALL > keys, not just letters). I DON'T get this behavior in a VNC session on the > same machine. I have compared xmodmap and setxkbmap settings between my vnc > and xpra sessions and haven't found any differences that seem like they > could explain this behavior. > > Any ideas? > From zhuojia.dai at gmail.com Fri Oct 23 05:52:37 2020 From: zhuojia.dai at gmail.com (Zhuo Jia Dai) Date: Fri, 23 Oct 2020 15:52:37 +1100 Subject: [winswitch] Unsubscribe In-Reply-To: References: Message-ID: Un On Fri, 23 Oct 2020, 15:45 Thomas Esposito via shifter-users, < shifter-users at lists.devloop.org.uk> wrote: > If I had to guess, I'd say the the xpra client is translating the capslock > to a shift before it ever gets to the server. Is that possible? If so, how > can I verify that this is happening and how would I fix it? > > On Fri, Oct 23, 2020, 12:08 AM Thomas Esposito > wrote: > > > We finally upgraded from Centos 6.6 to 7.6 at work (it will be YEARS > > before we see 8.x) and I took the opportunity to upgrade xpra to 3.x. > > > > So far, everything seems to be working well, except for some strange > > keyboard behavior. My capslock key is acting as shiftlock (i.e. effects > ALL > > keys, not just letters). I DON'T get this behavior in a VNC session on > the > > same machine. I have compared xmodmap and setxkbmap settings between my > vnc > > and xpra sessions and haven't found any differences that seem like they > > could explain this behavior. > > > > Any ideas? > > > _______________________________________________ > 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 Oct 23 10:05:48 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 23 Oct 2020 16:05:48 +0700 Subject: [winswitch] Disable TCP on systemd socket activation In-Reply-To: <78d29d9d-3bdb-40f2-3cb3-012992616619@cchtml.com> References: <78d29d9d-3bdb-40f2-3cb3-012992616619@cchtml.com> Message-ID: <4a30b36a-f006-2f68-1e98-4f1e48c92d91@nagafix.co.uk> On 23/10/2020 03:39, Michael Cronenworth via shifter-users wrote: > Hi, > > I'm using the Xpra 4.x packages from the official Xpra repo on RHEL 8. > I'm also using the provided systemd socket and service. This enables the > listening socket at port 14500 to respond to plain TCP and SSL requests. > I would like to disable support for plain TCP, but I do not see a > combination of config options that works with socket activation. Am I > right or wrong? Right. Based on your request, I have just added a simple way to make this work: https://www.xpra.org/trac/ticket/2914 You can grab the latest centos8 beta builds which have this change already included. Cheers, Antoine > > Thanks, > Michael > _______________________________________________ > 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 Oct 23 10:08:38 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 23 Oct 2020 16:08:38 +0700 Subject: [winswitch] capslock acting like shiftlock? In-Reply-To: References: Message-ID: <15c0a696-c094-c70a-4fda-f7ebc5c7667f@nagafix.co.uk> On 23/10/2020 11:44, Thomas Esposito via shifter-users wrote: > If I had to guess, I'd say the the xpra client is translating the capslock > to a shift before it ever gets to the server. Is that possible? No, the client tries hard not not modify key events before sending them to the server. > If so, how > can I verify that this is happening and how would I fix it? Run the server and client with "-d keyboard" to get details on events and how they are processed. (just be aware that this is hard to interpret as it is very verbose) "Shift" and "Caps_Lock" are treated interchangeably by the key mapping code for non-native keymaps. (non-X11 clients for seamless servers) To fix it, please file a ticket as per: https://xpra.org/trac/wiki/Keyboard#ReportingBugs Cheers, Antoine > > On Fri, Oct 23, 2020, 12:08 AM Thomas Esposito > wrote: > >> We finally upgraded from Centos 6.6 to 7.6 at work (it will be YEARS >> before we see 8.x) and I took the opportunity to upgrade xpra to 3.x. >> >> So far, everything seems to be working well, except for some strange >> keyboard behavior. My capslock key is acting as shiftlock (i.e. effects ALL >> keys, not just letters). I DON'T get this behavior in a VNC session on the >> same machine. I have compared xmodmap and setxkbmap settings between my vnc >> and xpra sessions and haven't found any differences that seem like they >> could explain this behavior. >> >> Any ideas? >> > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From tmesposito00 at gmail.com Fri Oct 23 12:33:05 2020 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Fri, 23 Oct 2020 07:33:05 -0400 Subject: [winswitch] capslock acting like shiftlock? In-Reply-To: <15c0a696-c094-c70a-4fda-f7ebc5c7667f@nagafix.co.uk> References: <15c0a696-c094-c70a-4fda-f7ebc5c7667f@nagafix.co.uk> Message-ID: > "Shift" and "Caps_Lock" are treated interchangeably by the key mapping code for non-native keymaps. (non-X11 clients for seamless servers) I'm not sure what you mean by "non-native keymaps" in this context. FWIW, my xpra client is running on Windows 10 and I'm using the same xpra client version (3.0) that I was using when the xpra server version was 1.x running on Centos 6.6. I didn't have this problem before. Also not sure what you mean when you say that "Shift" and "Caps_Lock" are treated interchangeably. Are you talking about the xpra client? It sounds like this explains my problem but that can't be because I haven't changed the client, only the server OS version and the xpra version running on it. On Fri, Oct 23, 2020, 5:08 AM Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > On 23/10/2020 11:44, Thomas Esposito via shifter-users wrote: > > If I had to guess, I'd say the the xpra client is translating the > capslock > > to a shift before it ever gets to the server. Is that possible? > No, the client tries hard not not modify key events before sending them > to the server. > > > If so, how > > can I verify that this is happening and how would I fix it? > Run the server and client with "-d keyboard" to get details on events > and how they are processed. > (just be aware that this is hard to interpret as it is very verbose) > > "Shift" and "Caps_Lock" are treated interchangeably by the key mapping > code for non-native keymaps. (non-X11 clients for seamless servers) > > To fix it, please file a ticket as per: > https://xpra.org/trac/wiki/Keyboard#ReportingBugs > > Cheers, > Antoine > > > > > > > On Fri, Oct 23, 2020, 12:08 AM Thomas Esposito > > wrote: > > > >> We finally upgraded from Centos 6.6 to 7.6 at work (it will be YEARS > >> before we see 8.x) and I took the opportunity to upgrade xpra to 3.x. > >> > >> So far, everything seems to be working well, except for some strange > >> keyboard behavior. My capslock key is acting as shiftlock (i.e. effects > ALL > >> keys, not just letters). I DON'T get this behavior in a VNC session on > the > >> same machine. I have compared xmodmap and setxkbmap settings between my > vnc > >> and xpra sessions and haven't found any differences that seem like they > >> could explain this behavior. > >> > >> Any ideas? > >> > > _______________________________________________ > > 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 Oct 23 12:44:22 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 23 Oct 2020 18:44:22 +0700 Subject: [winswitch] capslock acting like shiftlock? In-Reply-To: References: <15c0a696-c094-c70a-4fda-f7ebc5c7667f@nagafix.co.uk> Message-ID: On 23/10/2020 18:33, Thomas Esposito wrote: >> "Shift" and "Caps_Lock" are treated interchangeably by the key mapping > code for non-native keymaps. (non-X11 clients for seamless servers) > > I'm not sure what you mean by "non-native keymaps" in this context. Non-x11 clients, like MS Windows or MacOS. For X11 clients connecting to seamless servers, things are easier to map since the software is the same (X11) at both ends. > FWIW, my xpra client is running on Windows 10 and I'm using the same > xpra client version (3.0) that I was using when the xpra server version > was 1.x running on Centos 6.6. I didn't have this problem before. So this sounds like a regression, can you please file a ticket? (with all the details for the keymap and keys pressed, etc) > Also not sure what you mean when you say that "Shift" and "Caps_Lock" > are treated interchangeably. If either is pressed but not both, then the key is shifted and we use the symbol found at level 1 of the keymap. (often the uppercase version of the same keysym) > Are you talking about the xpra client? No, like I said: the client tries hard not to modify key events. > It > sounds like this explains my problem but that can't be because I haven't > changed the client, only the server OS version and the xpra version > running on it. Yes, the key mapping happens all server side. Cheers, Antoine > > > On Fri, Oct 23, 2020, 5:08 AM Antoine Martin via shifter-users > > wrote: > > On 23/10/2020 11:44, Thomas Esposito via shifter-users wrote: > > If I had to guess, I'd say the the xpra client is translating the > capslock > > to a shift before it ever gets to the server. Is that possible? > No, the client tries hard not not modify key events before sending them > to the server. > > > If so, how > > can I verify that this is happening and how would I fix it? > Run the server and client with "-d keyboard" to get details on events > and how they are processed. > (just be aware that this is hard to interpret as it is very verbose) > > "Shift" and "Caps_Lock" are treated interchangeably by the key mapping > code for non-native keymaps. (non-X11 clients for seamless servers) > > To fix it, please file a ticket as per: > https://xpra.org/trac/wiki/Keyboard#ReportingBugs > > Cheers, > Antoine > > > > > > > On Fri, Oct 23, 2020, 12:08 AM Thomas Esposito > > > > wrote: > > > >> We finally upgraded from Centos 6.6 to 7.6 at work (it will be YEARS > >> before we see 8.x) and I took the opportunity to upgrade xpra to 3.x. > >> > >> So far, everything seems to be working well, except for some strange > >> keyboard behavior. My capslock key is acting as shiftlock (i.e. > effects ALL > >> keys, not just letters). I DON'T get this behavior in a VNC > session on the > >> same machine. I have compared xmodmap and setxkbmap settings > between my vnc > >> and xpra sessions and haven't found any differences that seem > like they > >> could explain this behavior. > >> > >> Any ideas? > >> > > _______________________________________________ > > 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 tmesposito00 at gmail.com Fri Oct 23 13:12:16 2020 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Fri, 23 Oct 2020 08:12:16 -0400 Subject: [winswitch] capslock acting like shiftlock? In-Reply-To: References: <15c0a696-c094-c70a-4fda-f7ebc5c7667f@nagafix.co.uk> Message-ID: "Shift" and "Caps_Lock" aren't exactly the same because the 1st needs to be held down and the 2nd only needs to be toggled to have the same effect. Regardless, it sounds like this explains my issue though, because I have a non-X11 client. Do you know what changed between 1.x and 3.x to cause this? On Fri, Oct 23, 2020 at 7:44 AM Antoine Martin wrote: > On 23/10/2020 18:33, Thomas Esposito wrote: > >> "Shift" and "Caps_Lock" are treated interchangeably by the key mapping > > code for non-native keymaps. (non-X11 clients for seamless servers) > > > > I'm not sure what you mean by "non-native keymaps" in this context. > Non-x11 clients, like MS Windows or MacOS. > For X11 clients connecting to seamless servers, things are easier to map > since the software is the same (X11) at both ends. > > > FWIW, my xpra client is running on Windows 10 and I'm using the same > > xpra client version (3.0) that I was using when the xpra server version > > was 1.x running on Centos 6.6. I didn't have this problem before. > So this sounds like a regression, can you please file a ticket? > (with all the details for the keymap and keys pressed, etc) > > > Also not sure what you mean when you say that "Shift" and "Caps_Lock" > > are treated interchangeably. > If either is pressed but not both, then the key is shifted and we use > the symbol found at level 1 of the keymap. (often the uppercase version > of the same keysym) > > > Are you talking about the xpra client? > No, like I said: the client tries hard not to modify key events. > > > It > > sounds like this explains my problem but that can't be because I haven't > > changed the client, only the server OS version and the xpra version > > running on it. > Yes, the key mapping happens all server side. > > Cheers, > Antoine > > > > > > > On Fri, Oct 23, 2020, 5:08 AM Antoine Martin via shifter-users > > > > wrote: > > > > On 23/10/2020 11:44, Thomas Esposito via shifter-users wrote: > > > If I had to guess, I'd say the the xpra client is translating the > > capslock > > > to a shift before it ever gets to the server. Is that possible? > > No, the client tries hard not not modify key events before sending > them > > to the server. > > > > > If so, how > > > can I verify that this is happening and how would I fix it? > > Run the server and client with "-d keyboard" to get details on events > > and how they are processed. > > (just be aware that this is hard to interpret as it is very verbose) > > > > "Shift" and "Caps_Lock" are treated interchangeably by the key > mapping > > code for non-native keymaps. (non-X11 clients for seamless servers) > > > > To fix it, please file a ticket as per: > > https://xpra.org/trac/wiki/Keyboard#ReportingBugs > > > > Cheers, > > Antoine > > > > > > > > > > > > On Fri, Oct 23, 2020, 12:08 AM Thomas Esposito > > > > > > wrote: > > > > > >> We finally upgraded from Centos 6.6 to 7.6 at work (it will be > YEARS > > >> before we see 8.x) and I took the opportunity to upgrade xpra to > 3.x. > > >> > > >> So far, everything seems to be working well, except for some > strange > > >> keyboard behavior. My capslock key is acting as shiftlock (i.e. > > effects ALL > > >> keys, not just letters). I DON'T get this behavior in a VNC > > session on the > > >> same machine. I have compared xmodmap and setxkbmap settings > > between my vnc > > >> and xpra sessions and haven't found any differences that seem > > like they > > >> could explain this behavior. > > >> > > >> Any ideas? > > >> > > > _______________________________________________ > > > 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 Oct 23 13:46:27 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 23 Oct 2020 19:46:27 +0700 Subject: [winswitch] capslock acting like shiftlock? In-Reply-To: References: <15c0a696-c094-c70a-4fda-f7ebc5c7667f@nagafix.co.uk> Message-ID: On 23/10/2020 19:12, Thomas Esposito wrote: > "Shift" and "Caps_Lock" aren't exactly the same because the 1st needs to > be held down and the 2nd only needs to be toggled to have the same > effect. That's one of the things usually handled by the client OS: it tells us the state of the modifier keys and we don't have to worry about the ones that latch and the ones that have to be held down. > Regardless, it sounds like this explains my issue though, > because I have a non-X11 client. Do you know what changed between 1.x > and 3.x to cause this? 4 years worth of changes, so no, not OTOH. Cheers, Antoine > > On Fri, Oct 23, 2020 at 7:44 AM Antoine Martin > wrote: > > On 23/10/2020 18:33, Thomas Esposito wrote: > >> "Shift" and "Caps_Lock" are treated interchangeably by the key > mapping > > code for non-native keymaps. (non-X11 clients for seamless servers) > > > > I'm not sure what you mean by "non-native keymaps" in this context. > Non-x11 clients, like MS Windows or MacOS. > For X11 clients connecting to seamless servers, things are easier to map > since the software is the same (X11) at both ends. > > > FWIW, my xpra client is running on Windows 10 and I'm using the same > > xpra client version (3.0) that I was using when the xpra server > version > > was 1.x running on Centos 6.6. I didn't have this problem before. > So this sounds like a regression, can you please file a ticket? > (with all the details for the keymap and keys pressed, etc) > > > Also not sure what you mean when you say that "Shift" and "Caps_Lock" > > are treated interchangeably. > If either is pressed but not both, then the key is shifted and we use > the symbol found at level 1 of the keymap. (often the uppercase version > of the same keysym) > > > Are you talking about the xpra client? > No, like I said: the client tries hard not to modify key events. > > > It > > sounds like this explains my problem but that can't be because I > haven't > > changed the client, only the server OS version and the xpra version > > running on it. > Yes, the key mapping happens all server side. > > Cheers, > Antoine > > > > > > > On Fri, Oct 23, 2020, 5:08 AM Antoine Martin via shifter-users > > > > >> wrote: > > > >? ? ?On 23/10/2020 11:44, Thomas Esposito via shifter-users wrote: > >? ? ?> If I had to guess, I'd say the the xpra client is > translating the > >? ? ?capslock > >? ? ?> to a shift before it ever gets to the server. Is that possible? > >? ? ?No, the client tries hard not not modify key events before > sending them > >? ? ?to the server. > > > >? ? ?> If so, how > >? ? ?> can I verify that this is happening and how would I fix it? > >? ? ?Run the server and client with "-d keyboard" to get details on > events > >? ? ?and how they are processed. > >? ? ?(just be aware that this is hard to interpret as it is very > verbose) > > > >? ? ?"Shift" and "Caps_Lock" are treated interchangeably by the key > mapping > >? ? ?code for non-native keymaps. (non-X11 clients for seamless > servers) > > > >? ? ?To fix it, please file a ticket as per: > >? ? ?https://xpra.org/trac/wiki/Keyboard#ReportingBugs > > > >? ? ?Cheers, > >? ? ?Antoine > > > > > > > >? ? ?> > >? ? ?> On Fri, Oct 23, 2020, 12:08 AM Thomas Esposito > >? ? ? > >> > >? ? ?> wrote: > >? ? ?> > >? ? ?>> We finally upgraded from Centos 6.6 to 7.6 at work (it will > be YEARS > >? ? ?>> before we see 8.x) and I took the opportunity to upgrade > xpra to 3.x. > >? ? ?>> > >? ? ?>> So far, everything seems to be working well, except for > some strange > >? ? ?>> keyboard behavior. My capslock key is acting as shiftlock (i.e. > >? ? ?effects ALL > >? ? ?>> keys, not just letters). I DON'T get this behavior in a VNC > >? ? ?session on the > >? ? ?>> same machine. I have compared xmodmap and setxkbmap settings > >? ? ?between my vnc > >? ? ?>> and xpra sessions and haven't found any differences that seem > >? ? ?like they > >? ? ?>> could explain this behavior. > >? ? ?>> > >? ? ?>> Any ideas? > >? ? ?>> > >? ? ?> _______________________________________________ > >? ? ?> 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 mike at cchtml.com Fri Oct 23 16:50:08 2020 From: mike at cchtml.com (Michael Cronenworth) Date: Fri, 23 Oct 2020 10:50:08 -0500 Subject: [winswitch] Disable TCP on systemd socket activation In-Reply-To: <4a30b36a-f006-2f68-1e98-4f1e48c92d91@nagafix.co.uk> References: <78d29d9d-3bdb-40f2-3cb3-012992616619@cchtml.com> <4a30b36a-f006-2f68-1e98-4f1e48c92d91@nagafix.co.uk> Message-ID: On 10/23/20 4:05 AM, Antoine Martin via shifter-users wrote: > Right. > Based on your request, I have just added a simple way to make this work: > https://www.xpra.org/trac/ticket/2914 > > You can grab the latest centos8 beta builds which have this change > already included. Great! Thank you!