[winswitch] capslock acting like shiftlock?

[Antoine Martin]

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 <antoine at nagafix.co.uk
> <mailto:antoine at 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 at lists.devloop.org.uk
>     <mailto:shifter-users at lists.devloop.org.uk>
>     > <mailto:shifter-users at lists.devloop.org.uk
>     <mailto: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
>     >     <tmesposito00 at gmail.com <mailto:tmesposito00 at gmail.com>
>     <mailto:tmesposito00 at gmail.com <mailto:tmesposito00 at 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 at lists.devloop.org.uk
>     <mailto:shifter-users at lists.devloop.org.uk>
>     >     <mailto:shifter-users at lists.devloop.org.uk
>     <mailto: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
>     <mailto:shifter-users at lists.devloop.org.uk>
>     >     <mailto:shifter-users at lists.devloop.org.uk
>     <mailto:shifter-users at lists.devloop.org.uk>>
>     >     https://lists.devloop.org.uk/mailman/listinfo/shifter-users
>     >
>