XKB_DEFAULT_LAYOUT=se,ru does not work properly

[tjavdar]

Hi guys,
I'm not sure if this is a sway problem or a Wayland one, reporting still.

Setting (before invoking sway)

XKB_DEFAULT_LAYOUT=se
XKB_DEFAULT_OPTIONS=ctrl:nocaps

works impeccably, whereas

XKB_DEFAULT_LAYOUT=se,ru
XKB_DEFAULT_VARIANT=,phonetic
XKB_DEFAULT_OPTIONS=ctrl:nocaps,grp:shift_toggle,grp_led:caps

pollutes some keys in the Swedish layout with Russian chars, e.g., pressing
S ->'С', '*' -> 'Э', etc.

Interesting enough, the setxkbmap commands below (working in X), but executed from within sway,

setxkbmap -layout se -option ctrl:nocaps

and

setxkbmap -layout se,ru -variant ,phonetic -option ctrl:nocaps grp:shift_toggle grp_led:caps

still work, but repeat the erroneous behavior obtained by setting the XKB-environmental variables.

Using sway 0.12.1-1, wayland 1.13.0-1, on arch,
Linux i5 4.10.8-1-ARCH #1 SMP PREEMPT Fri Mar 31 16:50:19 CEST 2017 x86_64 GNU/Linux

[ghost]

+1, having the same issue - works fine in X but not when using sway. When switching back to the default US layout my | turns into Э and while lowercase letters are US, all upper case letters are in Russian. If I switch to the [phonetic] Russian variant then upper case is US and lower case is Russian. Very odd.

XKB_DEFAULT_MODEL=kinesis
XKB_DEFAULT_LAYOUT=us,us
XKB_DEFAULT_VARIANT=,rus
XKB_DEFAULT_OPTIONS=grp:shifts_toggle,grp_led:scroll,compose:menu,caps:ctrl_modifier

Also on Arch:

Linux yogi 4.11.9-1-ARCH #1 SMP PREEMPT Wed Jul 5 18:23:08 CEST 2017 x86_64 GNU/Linux

[ddevault]

Attempt to reproduce this on other Wayland compositors, please.

[ghost]

way-cooler worked correctly using environment variables picked up from the shell. weston worked with the following configuration in $HOME/.config/weston.ini:

[keyboard]
keymap_layout=us,us
keymap_variant=,rus
keymap_options=grp:toggle,grp:shifts_toggle,grp_led:scroll,compose:menu,caps:ctrl_modifier

For some reason in weston I couldn't toggle variants with only grp:shifts_toggle specified. I had to add grp:toggle and then pressing both shift keys worked as well as right-Alt.

[veox]

To describe the issue in a more generic manner, when having several layouts in XKB_DEFAULT_LAYOUT:

• pressing LShift+<key> will produce a <keysym> from the previous layout;
• pressing RShift+<key> will produce a <keysym> from the next layout.

As can be seen from this gist with a xev snippet, pressing the {L,R}Shift keys sends ISO_{Prev,Next}_Group keysyms, whereas releasing them sends Shift_{L,R} respectively.

---

EDIT:

(Note I also have NumLock on, which shows in state as the second bit being set to 1.)

In other words, the Shift modifier is already propagated into the particular event's state when the event (both KeyPress and KeyRelease) is considered.

So, for example, pressing the LShift key registers the Shift modifier in state (as the first bit being set to 1), and then considers the keycode: it looks like a Shift has been pressed (but not released!) while a Shift is pressed.

When the key is later released, the fact is first registered in state (i.e. the modifier is removed), and then then keycode is considered: a Shift has been released while a Shift is not pressed.

---

I've also checked with xorg-server and awesome via startx, there the behaviour is reversed. That is, when a KeyPress event is considered, the key's effects are not yet propagated into state. They are for KeyRelease, though.

I'm not yet sure which one would be "correct". :/

---

Package versions (using Arch Linux):

sway 0.14.0
wlc 0.0.10
xkeyboard-config 2.21 (EDIT2: 2.22 has just become available)
libinput 1.8.3
libxkbcommon 0.7.2
(any others?)

[veox]

Removing grp:shifts_toggle from XKB_DEFAULT_LAYOUT makes pressing the Shift keys behave as intended (when inspected with xev).

That is, they no longer generate ISO_{Prev,Next}_Group keysyms on a KeyPress event. Instead, they generate the expected Shift_{L,R} keysyms.

[veox]

Dug up the issue having been mentioned in this bug report from 2006 in Freedesktop's xkeyboard-config. A solution might be possible by fiddling with XKB rulesets.

Although the issue seems to come might be coming from somewhere upstream, I'd say keep this open to avoid dupes.

[veox]

Edited comments above with more findings.

---

Also tested with way-cooler v0.6.2. Contrary to what @nharward-hd wrote, I've experienced the same unexpected behaviour as described above for sway.

(Ping @Timidger?..)

[Timidger]

Way Cooler should have same issue as sway, we aren't doing anything fancy and both use wlc obviously.

Can this be reproduced in wlroots?

[veox]

I used rootston from wlroots repo to try it. The issue can be reproduced there, too.

Important detail: all of the above is observed in XWayland programs (tried in urxvt and xev; and firefox a few times).

I'm sure I used to see the same in weston-terminal just a few days ago, but can't reproduce it anymore. :/ It may be that I'm delusional, or that a recent (2017-10-07) system update changed something.

---

In rootston, both urxvt and weston-terminal were tested in the same session (i.e. rootston.ini has xwayland=true), with layout details provided via envvars XKB_DEFAULT_{LAYOUT,OPTIONS} (i.e. like in this bug report).

[Timidger]

Sounds like an upstream bug then, has it been reported yet?

If you can reproduce in Weston then that would certainly mean we aren't doing anything wrong ( @nharward-hd said it worked with Weston, though he also said it worked with Way Cooler... @veox is the issue reproducible in Weston?)

[nharward]

I think since my original comment (as @nharward-hd) other commenters have pointed out a key issue I failed to notice: it does seem to be only an issue in X programs. termite in sway works perfectly fine while Firefox right next to it does not. My suspicion is that I was using a mix of X and native wayland terminals when trying other window managers - my apologies.

I'll try fiddling with different options after reading the very helpful comments from @veox.

[Vintodrimmer]

Good day,

Have you found a persistent solution that allows one to use shifts_toggle?

[nharward]

I left sway/wayland to go back to X (unrelated reason), so I haven't :(

[tjavdar]

My solution (seems to work fine >= 6 months or so): XKB_DEFAULT_LAYOUT=se,ru XKB_DEFAULT_VARIANT=,phonetic XKB_DEFAULT_OPTIONS=ctrl:nocaps,grp:alt_shift_toggle,grp_led:caps Keypad (with num_lock on) does not, though. Tjavdar Ivanov +46 (0) 739-10 16 06 (mobile) +46 (0) 36-10 16 23 (off)

…

On Mon, Mar 26, 2018 at 2:35 AM, NDH ***@***.***> wrote: I left sway/wayland to go back to X (unrelated reason), so I haven't :( — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1161 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJsWctX4gCnbPyKCiNewMpj8kSkF0asSks5tiDflgaJpZM4M38iF> .

[valryne]

I just tried to find a workaround for this problem (sway is working fine while I cannot access the second layer (capital letters) under Xwayland) using the german layout (de) and its neo variant on my system running current Arch and sway(1α from AUR – I updated today, but the problem and my solution attempts were the same under 0.15).

With my layout/variant combination, the solution was using setxkbmap and actually adding the option: grp:shift_toggle (grp:alt_shift_toggle worked as well).

$ setxkbmap -layout de -variant neo -option grp:shift_toggle         

But so far, I don't have a way to preserve settings across boots, except wrapper-scripts for the applications that call setxkbmap before calling the application itself.

After a lot of trial and error, switching back-and-forth between sway and i3 and trying multiple X-applications, I think the problem may be that Xwayland ignores some X-configs.
→ If that is the case, then sway/wlroots may not be able to fix this issue.

What did not work:

• using localectl set-x11-keymap
• modifying /etc/X11/xorg.conf.d/00-keyboard.conf by hand (usually set by localectl)
• adding a setxkbmap line to:
  - ~/.xinit
  - /etc/profile
  - ~/.zprofile (my main shell is zsh and .zprofile also holds the commands to automatically start sway, if I log into tty1)
  - ~/.zshrc
• define the global variable XKB_DEFAULT_OPTIONS in: (@tjavdar how/where did you do that?)
  - ~/.xinit
  - /etc/profile
  - ~/.zprofile
  - ~/.zshrc
  - or even ~/.pam_environment

What worked:

• running setxkbmap in a terminal before running X-applications
• defining an alias for the setxkbmap-call in ~/.zshrc and run that prior to using the first X-application
• when only using very few X-applications:
  - defining an alias for the X-application in ~/.zshrc that includes the call to setxkbmap (dmenu and probably other launchers cannot see this)
  - write a script that has a similar name to the original application-name and runs the setxkbmap command prior to calling the application (if the script is made executable and available in the $PATH, dmenu can see it)

What is strange:
When I use a wrapper-script or an alias for an X-application, the settings only apply to the so started instance of this application, whereas running the setxkbmap-command separately (typed by hand or via alias) has a permanent and application-independent effect.
Not to mention that adding it to ~/.zshrc or ~/.zprofile should work like typing it into a terminal lateron – for ~/.zprofile it is probably because Xwayland is not yet initialized at this point, but the commands in ~/.zshrc must have been run already when I simply start a terminal, no‽

I hope this can be of help for others trying to solve this problem.

If someone finds that solution-attempts I listed (don't) work for them, please say so – I may have made some stupid mistakes.

---

Edit:

For sway 1.0α #1735 @SirCmpwn mentioned that XKB options may now be specified in the sway-config.
Could this solve this issue? – If so, how to properly set this in the config? (I looked through man 5 sway, but it might not be in there yet.)

[ddevault]

I'm closing issues that are resolved by the yet-unreleased sway 1.0.