remapping of the assistant key is being tracked in issue 784857.  until CrOS has made a choice system-wide, we won't do anything Crostini specific.

similarly, issue 896907 is tracking a more generalized remap solution.  i'm not sure we'll do anything in Crostini until that is sorted out.

As for the assistant key, I don't believe this is the same as _remapping_ the Assistant key to another CrOS function (comparable to the existing remapping dialog). Even if I could remap it to be another Launcher key (which is what currently becomes mod4 in X11), that won't help at all as many key bindings using the Launcher key are already caught by CrOS and won't reach X11 (which is the core issue I want to solve with this).

OTOH, the Assistant key does absolutely nothing on my system, as I've disabled Assistant. Once I do this, shouldn't the Assistant key become visible as _some_ keycode under Crostini - even if not remapped in any way?

As for the Ctrl_L+Ctrl_R+T issue: turns out this issue depends on the key pressed together with both control keys - I can reproduce this only with the keys Tab, T, Y, [, ], A, S, D, F, J, K, L, ; (not sure about the first row keys as they're caught by the OS anyway). So very likely this is a totally separate issue, showing that the HW keyboard of the Pixelbook can't do 3-key rollover. As this is a HW issue ChromeOS can do nothing about, let's ignore the right-shift issue here and make this ticket only about the ability for Crostini to see key presses of the Assistant key that the OS did not handle.

It also seems like there's a separate bug inside Crostini regarding using xmodmap to remap keys - of course, can't tell whether this is a Crostini-specific thing or an XWayland thing. A simple reproducer:

- Use xmodmap to swap Shift_R and Super_R keys:
xmodmap -e 'remove shift = Shift_R'
xmodmap -e 'remove mod4 = Super_R'
xmodmap -e 'keysym Super_R = Shift_R' -e 'keysym Shift_R = Super_R'
xmodmap -e 'add mod4 = Super_R'
xmodmap -e 'add shift = Shift_R'
- Use xev, and press Shift_R+t
- Observe that it's shown with modifiers 0x41 (both shift and mod4), while it should show up as 0x40 (mod4 only).

I suspect that it's mixing the modifiers from Wayland and X11's view of things, but given I don't have any non-Crostini Wayland system, I can't tell where to report this. Sad, because this would otherwise actually be a viable workaround.

Here's though a workaround for people needing a mod4 for the time being that does appear to work sufficiently well - putting this here so people who need it can find it:

xmodmap -e 'add mod4 = XF86AudioPlay'

XF86Back and XF86Reload are also remappable while not causing any modifiers on the Wayland side, so these could be used as modifiers as well - XF86AudioPlay (the key above 8 and 9) seems most convenient for me to use though among the choices.

for everyone's sanity, we're unlikely to do anything with the Assistant key until the OS has sorted out general guidance and control.  we certainly do not want to be in the situation where we tell users "you can use the Assistant key in Linux apps, but only if you go ahead and disable the Assistant feature entirely".  Assistant is a feature that we've been marketing pretty strongly and that would go directly against it.  if you want to discuss Assistant key mapping, please use issue 784857.

there could be some weirdness when Chrome has an OS level shortcut (like Ctrl-T) that we semi-process before passing on.  so let's focus this bug on that.

wrt xmodmap, it's not really supported.  it requires X (which not all apps need), and only works in a single X instance.  we consider XWayland to be a stepping stone for deprecated flows that should be converting to Wayland clients directly.

First of all, regarding stuff like Ctrl+T, there is no bug, but this is working as intended - some keyboard shortcuts are reserved by the system. A bit many on ChromeOS, I'd say, but Ctrl-T isn't one of them, and I also have observed a tendency to slowly move all those shortcuts to use the Launcher key, which is nice.

Although X11 is technically deprecated, it's still very relevant - and in fact, the need to use another modifier key probably coincides >99% with either the use of a sub-X-server like Xephyr and running some X11 window manager inside, or the use of a separate Wayland compositor in a window (e.g. you can run Weston this way).

The former case is 100% solved by xmodmap - either it's an X11 application, then it's managed by the X11 window manager inside that window and remapping will be desirable, or it is a Wayland app running outside the X11 window and is managed by ChromeOS's own compositor.

The latter case - probably not relevant yet, but going to be soon (I bet it will be extremely relevant as soon as sway or a similar compositor enters Debian, and then almost entirely replace the current X11 usage) - also needs a remapping capability to make clear whether you want to control the inner compositor or ChromeOS's.

Now the big question is, whether should the remapping capability be. In X11-world Xephyr is probably the right place, and playing around with Xkb inside the Xephyr session solves that issue (except for the "both modifier bits get applied" issue, which I can't really put a thumb on until I know what exactly causes it). But where should this take place in Wayland-world?

One place could be "in the intermediate compositor", when running such a setup. As Wayland, unlike X11, does not support changing keymaps at runtime, this could be tricky, but of course - if nothing else - one could still solve the issue by editing xkb's files, which Wayland uses as well. Or intermediate compositors could/should have their own remapping capability.

But instead of every intermediate compositor needing to have its own copy of that capability, wouldn't it be nice for sommelier to do this? It already has an option to do "something" with the keyboard mapping, although it IIRC only can ignore keys, not remap them.

So to solve "all the problems", I'd suggest turning adding some kind of generic key-swap functionality to sommelier, which already has some keyboard handling (--accelerators flag). I think that would make most users quite happy, and would apply equally to X11 and Wayland use cases.

Assigning to me as part of keyboard shortcut strategy