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 <anto...@nagafix.co.uk > <mailto:anto...@nagafix.co.uk>> 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 > > <shifter-users@lists.devloop.org.uk > <mailto:shifter-users@lists.devloop.org.uk> > > <mailto:shifter-users@lists.devloop.org.uk > <mailto:shifter-users@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 > > <tmesposit...@gmail.com <mailto:tmesposit...@gmail.com> > <mailto:tmesposit...@gmail.com <mailto:tmesposit...@gmail.com>>> > > > 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@lists.devloop.org.uk > <mailto:shifter-users@lists.devloop.org.uk> > > <mailto:shifter-users@lists.devloop.org.uk > <mailto:shifter-users@lists.devloop.org.uk>> > > > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > > > > _______________________________________________ > > shifter-users mailing list > > shifter-users@lists.devloop.org.uk > <mailto:shifter-users@lists.devloop.org.uk> > > <mailto:shifter-users@lists.devloop.org.uk > <mailto:shifter-users@lists.devloop.org.uk>> > > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > _______________________________________________ shifter-users mailing list shifter-users@lists.devloop.org.uk https://lists.devloop.org.uk/mailman/listinfo/shifter-users