Bug 11822 - want more complex type for F-keys to support multiple symbols
Summary: want more complex type for F-keys to support multiple symbols
Status: RESOLVED FIXED
Alias: None
Product: xkeyboard-config
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: xkb
QA Contact:
URL: http://bugs.debian.org/cgi-bin/bugrep...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-02 14:30 UTC by Brice Goglin
Modified: 2011-06-15 13:42 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Brice Goglin 2007-08-02 14:30:02 UTC
Bug reported by Vincent Lefevre on the Debian BTS about a month ago. Applies to xf86-input-keyboard 1.2.1.

Vincent had
   Option "XkbDisable" "true"
and xmodmap set to
   keycode 67 = eacute Eacute
so that when he hits the F1 key, he gets the character 'é', while Shift-F1 gives 'É'.

Since xf86-input-keyboard 1.2.1 entered Debian, lots of people had to switch from the old "keyboard" driver to the new "kbd". But now Shift-F1 gives 'é' instead of 'É'.

So it looks like kbd and keyboard do not handle this config the same way. And according to Vincent, "kbd" already behaved (wrongly?) like this for a long time (for instance in 1.1.0).

Brice
Comment 1 Vincent Lefevre 2007-11-02 02:26:27 UTC
Any news? Or is there any workaround?
Comment 2 Jesse Adkins 2010-11-30 18:28:25 UTC
Confirming this with the latest from Ubuntu 10.10. Using xev says that Ctrl+Alt+F1 results in the character the reporter is looking for. I can't find any other app that sees Ctrl+Alt+F1 as Eacute instead of eacute.

I tried variations of Eacute, in case the capitalization was wrong. It's not.
Comment 3 Vincent Lefevre 2010-11-30 19:14:13 UTC
Here Shift-F1 gives 'é', but Alt-Shift-F1 gives 'É'.
Comment 4 Vincent Lefevre 2011-05-31 05:16:57 UTC
A workaround is to use xkb only (instead of xmodmap): one can change the type of the function keys to e.g.

    type "CUSTFNKEY" {
        modifiers = Shift+Lock+Control+Alt;
        map[Shift] = Level2;
        map[Lock] = Level2;
        map[Control] = Level3;
        map[Control+Alt] = Level4;
        level_name[Level1] = "Base";
        level_name[Level2] = "Caps";
        level_name[Level3] = "Level3";
        level_name[Level4] = "Ctrl+Alt";
    };

I can see two solutions if xmodmap is not declared as deprecated:

1. xmodmap should change the type of the key when necessary.

2. The default xkb settings for the function keys could be similar to the above one, i.e. allowing Shift as a modifier, in addition to Ctrl+Alt. It should probably even be more complex to allow ISO_Level3_Shift (a.k.a. Mode_switch). So, this would still allow one to use xmodmap a usual:

   keycode NUMBER = KEYSYMNAME ...
       The list of keysyms is assigned to the indicated keycode (which
       may be specified in decimal, hex or octal and can be determined
       by  running  the  xev  program).   Up  to  eight keysyms may be
       attached to a key, however the last four are not  used  in  any
       major  X  server implementation.  The first keysym is used when
       no modifier key is pressed in conjunction with  this  key,  the
       second  with  Shift, the third when the Mode_switch key is used
       with this key and the fourth  when  both  the  Mode_switch  and
       Shift keys are used.

(from the xmodmap(1) man page), and Ctrl+Alt would still work.
Comment 5 Daniel Stone 2011-05-31 09:48:13 UTC
Hi,

On Tue, May 31, 2011 at 05:16:57AM -0700, bugzilla-daemon@freedesktop.org wrote:
> A workaround is to use xkb only (instead of xmodmap): one can change the type
> of the function keys to e.g.
> 
>     type "CUSTFNKEY" {
>         modifiers = Shift+Lock+Control+Alt;
>         map[Shift] = Level2;
>         map[Lock] = Level2;
>         map[Control] = Level3;
>         map[Control+Alt] = Level4;
>         level_name[Level1] = "Base";
>         level_name[Level2] = "Caps";
>         level_name[Level3] = "Level3";
>         level_name[Level4] = "Ctrl+Alt";
>     };

This is true, but would be an xkeyboard-config change.

> I can see two solutions if xmodmap is not declared as deprecated:

It's not deprecated per se, but isn't half as expressive as XKB.  In
addition, we're somewhat limited by the spec; section 12 describes the
interaction between core and XKB requests.  Re-reading it now, I think
we might have just enough wiggle room to do this sort of thing, but that
might require the keys to be configured with explicit groups.

> 1. xmodmap should change the type of the key when necessary.

That still wouldn't help people using XChangeKeyboardMapping, and .

> 2. The default xkb settings for the function keys could be similar to the above
> one, i.e. allowing Shift as a modifier, in addition to Ctrl+Alt. It should
> probably even be more complex to allow ISO_Level3_Shift (a.k.a. Mode_switch).
> So, this would still allow one to use xmodmap a usual:
> 
>    keycode NUMBER = KEYSYMNAME ...
>        The list of keysyms is assigned to the indicated keycode (which
>        may be specified in decimal, hex or octal and can be determined
>        by  running  the  xev  program).   Up  to  eight keysyms may be
>        attached to a key, however the last four are not  used  in  any
>        major  X  server implementation.  The first keysym is used when
>        no modifier key is pressed in conjunction with  this  key,  the
>        second  with  Shift, the third when the Mode_switch key is used
>        with this key and the fourth  when  both  the  Mode_switch  and
>        Shift keys are used.
> 
> (from the xmodmap(1) man page), and Ctrl+Alt would still work.

Right - you'd have to file a bug on xkeyboard-config for this.
Comment 6 Daniel Stone 2011-05-31 10:13:44 UTC
I'm reassigning this one to xkeyboard-config as a request for the Fn keys to have a more complex type that supports multiple symbols, rather than one symbol and an action with Ctrl+Alt.
Comment 7 Sergey V. Udaltsov 2011-05-31 11:58:16 UTC
I see no problem adding that new type. But it should be used somehow. Would we provide xkb option or smth?
Comment 8 Daniel Stone 2011-05-31 12:12:40 UTC
On Tue, May 31, 2011 at 11:58:16AM -0700, bugzilla-daemon@freedesktop.org wrote:
> I see no problem adding that new type. But it should be used somehow. Would we
> provide xkb option or smth?

You tell me. :) I guess, to make it as unintrusive WRT current
configurations as possible, you could have shift map to level 3, level 3
to level 4, and level 3 + shift map to level 5? It's not exactly
intuitive though ...
Comment 9 Sergey V. Udaltsov 2011-05-31 13:28:06 UTC
> You tell me. :) I guess, to make it as unintrusive WRT current
> configurations as possible, you could have shift map to level 3, level 3
> to level 4, and level 3 + shift map to level 5? It's not exactly
> intuitive though ...
What if we add xkb option, that makes functional keys "alphabetic"? That would use new section of symbols mappings, something like

key <FK01> {
  type="FOUR_LEVEL",
  symbols[Group1] = [ F1, VoidSymbol, XF86_Switch_VT_1 ]
};

etc
Comment 10 Daniel Stone 2011-05-31 15:02:17 UTC
On Tue, May 31, 2011 at 01:28:06PM -0700, Sergey V. Udaltsov wrote:
> What if we add xkb option, that makes functional keys "alphabetic"? That would
> use new section of symbols mappings, something like
> 
> key <FK01> {
>   type="FOUR_LEVEL",
>   symbols[Group1] = [ F1, VoidSymbol, XF86_Switch_VT_1 ]
> };
> 
> etc

Or make the CTRL+ALT type basically be FOUR_LEVEL but with Ctrl+Alt
mapping to level five, so you'd have:
    [ F1, VoidSymbol, VoidSymbol, VoidSymbol, VoidSymbol, XF86_Switch_VT_1 ]
?
Comment 11 Daniel Stone 2011-05-31 15:06:58 UTC
(In reply to comment #10)
> Or make the CTRL+ALT type basically be FOUR_LEVEL but with Ctrl+Alt
> mapping to level five, so you'd have:
>     [ F1, VoidSymbol, VoidSymbol, VoidSymbol, VoidSymbol, XF86_Switch_VT_1 ]
> ?

23:05 < svu> daniels, I guess you put extra VoidSymbol in that bug about F-keys, right?
23:05 < daniels> svu: ha, yes
23:06 < svu> :)
23:06  * svu always knew X.org developers could not count to 4

(It's true.)
Comment 12 Sergey V. Udaltsov 2011-06-15 13:42:57 UTC
It is committed. Please check in git.

But I could not add new type - I had to amend the existing one. The bug https://bugs.freedesktop.org/show_bug.cgi?id=27988 still kills my X when I try to add one more type.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.