Page MenuHome

When two keymaps are configured on the system and the current isn't the first one Blender use both
Closed, ResolvedPublic

Description

System Information
KDE neon User Edition 5.7 (based on Ubuntu 16.04 xenial) x64

Blender Version
Broken: 2.77a

Short description of error
I have two keymaps configured on my system (x11 keymaps). The first one is bépo (french dvorak) and the second one qwerty. When qwerty is active Blender handles hotkeys for both keymaps. For example pressing the T key opens the tool shelf, but pressing J (which is the T key on bépo) also open the tool shelf. Same behavior is observed for other hotkeys.

Behavior is not observed if bépo is the active keymap. Actually behavior is not observed if the active keymap is the first one in the keymap list.

Exact steps for others to reproduce the error

  • Configure two keymaps on the system (using the control panel provided by your desktop environment, I only tested with KDE).
  • Enable the second keymap.
  • Start Blender.
  • Press T key -> tool shelf opens (expected).
  • Press the key that is T on the first keymap -> tool shelf also open (not expected).

Event Timeline

Bastien Montagne (mont29) lowered the priority of this task from 90 to 30.Jul 21 2016, 5:29 PM

This likely the same issue as T47228, please try the latest build from our buildbot, should be fixed there (hopefully :| ).

This likely the same issue as T47228, please try the latest build from our buildbot, should be fixed there (hopefully :| ).

I tried 2.77-08e1bba. Issue is not fixed.

Bastien Montagne (mont29) raised the priority of this task from 30 to 50.

Yeah… in fact you are right, T47228 was for non-latin keyboards, in that case (since native first layout generates no valid X11 keytype), we can fallback to getting string value of key and convert it to our Blender event type.

But if getting keytype returns a valid value, then we stick to XLookupKeysym value for event type - and that X11 function always uses first defined keyboard layout for some mysterious reasons :(

We can try some other ways around (like, using XLookupString with only exception of main number keys to handle layers switching correctly)… But would wait for after 2.78 now, this is too risky at this stage of release cycle.

OK, have patch ready for this, seems to work nice here… will apply after master is unfreezed - it’s too risky for 2.78 release anyway imho.