Public bug reported:
This bug applies to Ubuntu 14.04 (Trusty Tahr)
I configured my (GNOME) desktop to make Caps_Lock an additional Control
key.
This results in a perfectly reasonable xkb keymap:
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include
"pc+us+inet(evdev)+capslock(ctrl_modifier)+compose(ralt)" };
xkb_geometry { include "pc(pc105)" };
};
But "xkbcomp" turns this into a slightly broken modifier map:
shift Shift_L (0x32), Shift_R (0x3e)
lock Caps_Lock (0x42)
control Control_L (0x25), Caps_Lock (0x42), Control_R (0x69)
mod1 Alt_L (0x40), Meta_L (0xcd)
mod2 Num_Lock (0x4d)
mod3
mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)
As you can see, Caps_Lock is now assigned to both "lock" and "control".
That's technically not valid, even if it happens to (almost) work with
many X applications.
Unfortunately for me, VMware Workstation is one of the applications that
cannot handle this situation. In fact, when it encounters this type of
modifier map, it proceeds to completely clear the entire map, which is
quite catastrophic:
xmodmap: up to 0 keys per modifier, (keycodes in parentheses):
shift
lock
control
mod1
mod2
mod3
mod4
mod5
That's of course a bug in VMWare -- and I already reported it. But the
root cause of the bug looks as if it is faulty information in the
xkeyboard configuration files.
For the time being, I can work around the problem by issuing "xmodmap -e
'clear lock'" prior to starting VMWare Workstation.
** Affects: xkeyboard-config (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xkeyboard-config in Ubuntu.
https://bugs.launchpad.net/bugs/1296205
Title:
capslock(ctrl_modifier) generates invalid modifier map
Status in “xkeyboard-config” package in Ubuntu:
New
Bug description:
This bug applies to Ubuntu 14.04 (Trusty Tahr)
I configured my (GNOME) desktop to make Caps_Lock an additional
Control key.
This results in a perfectly reasonable xkb keymap:
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include
"pc+us+inet(evdev)+capslock(ctrl_modifier)+compose(ralt)" };
xkb_geometry { include "pc(pc105)" };
};
But "xkbcomp" turns this into a slightly broken modifier map:
shift Shift_L (0x32), Shift_R (0x3e)
lock Caps_Lock (0x42)
control Control_L (0x25), Caps_Lock (0x42), Control_R (0x69)
mod1 Alt_L (0x40), Meta_L (0xcd)
mod2 Num_Lock (0x4d)
mod3
mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)
As you can see, Caps_Lock is now assigned to both "lock" and
"control". That's technically not valid, even if it happens to
(almost) work with many X applications.
Unfortunately for me, VMware Workstation is one of the applications
that cannot handle this situation. In fact, when it encounters this
type of modifier map, it proceeds to completely clear the entire map,
which is quite catastrophic:
xmodmap: up to 0 keys per modifier, (keycodes in parentheses):
shift
lock
control
mod1
mod2
mod3
mod4
mod5
That's of course a bug in VMWare -- and I already reported it. But the
root cause of the bug looks as if it is faulty information in the
xkeyboard configuration files.
For the time being, I can work around the problem by issuing "xmodmap
-e 'clear lock'" prior to starting VMWare Workstation.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/1296205/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
