Bug 3193 - Problem of "ctrl:nocaps" option for the combination with JP106 keyboard
Summary: Problem of "ctrl:nocaps" option for the combination with JP106 keyboard
Status: RESOLVED FIXED
Alias: None
Product: xkeyboard-config
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high minor
Assignee: xkb
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-03 02:34 UTC by Tatsuo Sekine
Modified: 2005-12-29 17:52 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tatsuo Sekine 2005-05-03 02:34:59 UTC
According to the file xkb/symbols/jp, JP K/Bs(jp106/jp109) has 2 meanings
on the Caps Lock key, which are "Eisu_toggle" and "Caps_Lock":
    (snip)
    key <CAPS> { [ Eisu_toggle, Caps_Lock ]     };
    (snip)

If the option "ctrl:nocaps" is set at the same time, following settings
(from xkb/symbols/ctrl) are loaded:
    xkb_symbols "nocaps" {
      key <CAPS>  {  symbols[Group1]= [ Control_L ] };
      modifier_map  Control { <CAPS>, <LCTL> };
    };

So, the use of "ctrl:nocaps" for jp K/Bs result in
    key <CAPS> { [ Control_L, Caps_Lock ]     };

It means that Caps Lock+Shift doesn't work as Ctrl_L+Shift.
Unfortunately, if Caps Lock+Shift is pressed, it results Ctlr+Shift+Caps.

Actual Results(from the result of xev command):
  (snip)
  KeyPress event, serial 30, synthetic NO, window 0x3c00001,
     root 0x48, subw 0x0, time 1262610, (108,-58), root:(112,454),
     state 0x7, keycode 38 (keysym 0x61, a), same_screen YES,
  (snip)

Expected Results:
  (snip)
  KeyPress event, serial 32, synthetic NO, window 0x2400001,
    root 0x48, subw 0x0, time 14782148, (15,96), root:(607,272),
    state 0x5, keycode 38 (keysym 0x41, A), same_screen YES,
  (snip)

The expected results above obtained with modifying it as following:

--- /etc/X11/xkb/symbols/ctrl.orig      2004-09-29 04:20:47.000000000 +1000
+++ /etc/X11/xkb/symbols/ctrl   2005-05-01 20:56:39.824039696 +1000
@@ -3,7 +3,7 @@
 // eliminate the caps lock key completely (replace with control)
 partial modifier_keys
 xkb_symbols "nocaps" {
-    key <CAPS> {  symbols[Group1]= [ Control_L ] };
+    key <CAPS> {  symbols[Group1]= [ Control_L, Control_L ] };
     modifier_map  Control { <CAPS>, <LCTL> };
 };

Though I'm not sure how to fix it in the best way, my quick hack
works fine.
Comment 1 Sergey V. Udaltsov 2005-05-03 04:04:23 UTC
Tatsuo:
1. Could you give a bit more background why in the Japanese layout Caps+Shift is
mapped to Caps - while just Caps is 'Eisu_Toggle'. For example, the other way
around would look more logical (well, for the person who never had any chance to
study Japanese)? Is it standard behaviour? What is the behaviour in MSWin?
2. Just to check - are you talking about standard xorg XKB repository - or did
you use xkeyboard-config data files?
Comment 2 Tatsuo Sekine 2005-05-03 05:47:21 UTC
At first, I'm talking about standard xorg XKB repository.
So, please fix it if my choice of the product was wrong, 

Secondly, normal JP106(/JP109) K/B has
  +---------+
  |Caps Lock|
  |  Eisu   |
  +---------+
print on the key top as well as other key like:
  +-----+
  |  !  |
  |  1  |
  +-----+
Therefore, it is absolutely natural to set those keyboard
mapping in JP106 K/Bs. So, obviously, MSWin has the same settings.

Then, though I don't use "Eisu_Toggle" functionality, someone may
need those mapping on X11 (by default).
Comment 3 Sergey V. Udaltsov 2005-12-30 12:52:52 UTC
OK, for a moment I am adding the second level - and if anyone complains, we'll see


bug/show.html.tmpl processed on Mar 29, 2017 at 22:53:22.
(provided by the Example extension).