Bug 45008 - xkb-data 2.5 breaks F10
xkb-data 2.5 breaks F10
Status: RESOLVED FIXED
Product: xkeyboard-config
Classification: Unclassified
Component: General
unspecified
All All
: medium major
Assigned To: xkb
http://bugs.debian.org/cgi-bin/bugrep...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-20 14:24 UTC by Christoph Anton Mitterer
Modified: 2012-09-02 07:58 UTC (History)
2 users (show)

See Also:


Attachments
xkbcomp output with xkb-data 2.3 (57.92 KB, text/plain)
2012-01-21 01:05 UTC, Sven Joachim
Details
xkbcomp output with xkb-data 2.5 (58.97 KB, text/plain)
2012-01-21 01:06 UTC, Sven Joachim
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Anton Mitterer 2012-01-20 14:24:45 UTC
Hi.

This is forwarded from the mentioned Debian bug:

The new version seems to somehow break the F10 key.

When being in GNOME, and havin a gnome-terminal opened, e.g. aptitude running...
pressing F10 should cause aptitude's menu to open.

But now, aptitude's menu opens, as well as the context menu of the terminal itself.

Downgrading fixes the issue.


Cheers,
Chris.
Comment 1 Sergey V. Udaltsov 2012-01-20 14:29:59 UTC
what does xev utility reports when you press f10?
Comment 2 Sven Joachim 2012-01-21 00:11:15 UTC
I'm having the same problem with gnome-terminal, here is the xev output:

KeyPress event, serial 33, synthetic NO, window 0x1400001,
    root 0x2b5, subw 0x0, time 11437053, (31,432), root:(964,458),
    state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x1400001,
    root 0x2b5, subw 0x0, time 11437163, (31,432), root:(964,458),
    state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
Comment 3 Sergey V. Udaltsov 2012-01-21 00:16:40 UTC
But according to what I see - it is all correct, F10 produces F10.

What is xev output with the previous version of xkb-data?

> KeyPress event, serial 33, synthetic NO, window 0x1400001,
>     root 0x2b5, subw 0x0, time 11437053, (31,432), root:(964,458),
>     state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES,
>     XLookupString gives 0 bytes: 
>     XmbLookupString gives 0 bytes: 
>     XFilterEvent returns: False
> 
> KeyRelease event, serial 33, synthetic NO, window 0x1400001,
>     root 0x2b5, subw 0x0, time 11437163, (31,432), root:(964,458),
>     state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES,
>     XLookupString gives 0 bytes: 
>     XFilterEvent returns: False
Comment 4 Sven Joachim 2012-01-21 00:34:57 UTC
With the previous xkb-data version (2.3), it's essentially the same:

KeyPress event, serial 33, synthetic NO, window 0x1600001,
    root 0x2b5, subw 0x0, time 13172000, (-269,319), root:(664,345),
    state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x1600001,
    root 0x2b5, subw 0x0, time 13172097, (-269,319), root:(664,345),
    state 0x0, keycode 76 (keysym 0xffc7, F10), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
Comment 5 Sergey V. Udaltsov 2012-01-21 00:46:12 UTC
Well, in that case God knows why gnome-terminal behaves differently.

Ok, one more thing. Could you please do 'xkbcomp :0 -xkb out.xkb' for both new and old versions? Attach the result here
Comment 6 Sven Joachim 2012-01-21 01:05:27 UTC
Created attachment 55894 [details]
xkbcomp output with xkb-data 2.3
Comment 7 Sven Joachim 2012-01-21 01:06:58 UTC
Created attachment 55895 [details]
xkbcomp output with xkb-data 2.5
Comment 8 Sergey V. Udaltsov 2012-01-21 05:40:52 UTC
The definitions for F10 are different (I expected that, I did that change) - but they should not matter if the XKB events are identical (and they are!).

What I suspect is that some app (gnome-terminal?) somehow checks the key definition. Why? I have no idea. Something was hardcoded - some workaround, perhaps - there was an issue with functional keys in 2.4. But xev output proves there is nothing to fix in xk-c
Comment 9 Christoph Anton Mitterer 2012-01-21 16:09:22 UTC
It's a bit strange simply closing this... and btw: it's not only gnome-terminal that is affected...
Comment 10 Christoph Anton Mitterer 2012-01-21 16:10:37 UTC
(Especially as it's clearly triggered by the new xkb-data version).
Comment 11 Sergey V. Udaltsov 2012-01-21 17:00:10 UTC
Actually I am ready to reopen if you explain me what exactly would you like me to fix. The x11 (xev) events are absolutely identical - that is the limit of xk-c responsibility, for properly written SW. Is that ok with everybody?

If that's the case, the software is using some other information from XKB config - which is should not, I guess

Returning to the previous version of F10 definition is not an option because it had clearly broken semantics of things like Shift-F10.

So, what would you propose to do?
Comment 12 Christoph Anton Mitterer 2012-01-21 17:06:08 UTC
Well has anyone some idea on whose door we should knock now?

I mean it's probably some GNOME/GTK wide keyboard library or so?
Comment 13 Sergey V. Udaltsov 2012-01-21 17:15:11 UTC
I would start with gnome-terminal perhaps.

I am really sorry I cannot be of much help. When you open the bug in gnome bugzilla, could you please provide the link here in comments - so that I could participate in the discussion.

Thank you and sorry again.
Comment 14 Sergey V. Udaltsov 2012-01-21 17:39:50 UTC
I just tried on my debian, F10 opens g-t menu, aptitide seems not getting it at all. Which is reasonable to some extent...
Comment 15 Sven Joachim 2012-01-21 23:01:56 UTC
To reproduce the problem, you need to configure gnome-terminal to pass F10 to the application. Under "Edit → Keyboard Shortcuts", uncheck "Enable the menu shortcut key (F10 by default)".
Comment 16 Sergey V. Udaltsov 2012-01-22 03:57:10 UTC
Yes I can reproduce it. That just convinces me that g-t would be a good starting point - I do not know how g-t implements that feature...
Comment 17 Andreas Wettstein 2012-01-22 07:17:32 UTC
> The definitions for F10 are different (I expected that, I did that change) ->
> but they should not matter if the XKB events are identical (and they are!).

This is not completely true. The new definition of CTRL+ALT consumes Shift,
the old one does not.  With the new definition, in a pedantic interpretation
of section 7.2.1 of the protocol specification of the X Keyboard Extension,
applications must not distinguish Shift-F10 and F10 anymore.

To see wether this is related to problem at hand, one could replace the 
definition of CTRL+ALT (file in types/pc) with the following one:

   type "CTRL+ALT" {
	modifiers = Control+Alt+Shift+LevelThree;
        map[None] = Level1;
        map[Shift] = Level2;
        map[LevelThree] = Level3;
        map[Shift+LevelThree] = Level4;
	map[Control+Alt] = Level5;
	preserve[Shift] = Shift;
	preserve[Shift+LevelThree] = Shift;
	preserve[Shift+LevelThree+Alt] = Shift;
	preserve[Shift+LevelThree+Control] = Shift;
	preserve[Shift+LevelThree+Alt+Control] = Shift;
	preserve[Shift+Alt] = Shift;
	preserve[Shift+Alt+Control] = Shift;
	preserve[Shift+Control] = Shift;
        level_name[Level1] = "Base";
        level_name[Level2] = "Shift";
        level_name[Level3] = "Alt Base";
        level_name[Level4] = "Shift Alt";
	level_name[Level5] = "Ctrl+Alt";
    };

I do not have gnome on my machine, so I cannot test myself.  Note that
the above definition is still not nice, but should be ok to check wether
consumed Shift is to blame.

> Returning to the previous version of F10 definition is not an option because it
> had clearly broken semantics of things like Shift-F10.

Do you have a pointer where the problems with the old definition are
described?
Comment 18 Sergey V. Udaltsov 2012-01-22 07:22:39 UTC
> This is not completely true. The new definition of CTRL+ALT consumes Shift,
> the old one does not.  
How does it affect the behavior of the F10 when shift is not pressed? As you can see, the events are exactly same.

> Do you have a pointer where the problems with the old definition are
> described?
https://bugs.freedesktop.org/show_bug.cgi?id=11822
Comment 19 Andreas Wettstein 2012-01-22 08:06:43 UTC
> How does it affect the behavior of the F10 when shift is not pressed? As you
> can see, the events are exactly same.

Basically, as Shift is consumed, one should not distinguish F10 and
Shift-F10.  This means that pressing Shift-F10 should be handled like
pressing F10; or that pressing F10 should be handled like pressing
Shift-F10.  So it is imaginable that consuming Shift assigns two functions
to pressing F10: the usual one for F10, plus the one for Shift-F10.

That is the idea.  Whether it happens like this, I do not know.  One has to
try or read the relevant source code.  In any event, the original report
speaks about two actions triggered by F10...
Comment 20 Christoph Anton Mitterer 2012-01-26 06:48:18 UTC
I've reassigned (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656685#19) the Debian bug to the GNOME guys... hope they can point us to the right place.
Comment 21 Sven Joachim 2012-01-26 08:14:29 UTC
For the record, this has already been reported in GNOME's bugzilla at https://bugzilla.gnome.org/show_bug.cgi?id=661973.
Comment 22 Yevgen Muntyan 2012-08-05 18:26:56 UTC
Could someone take a look at gdk_x11_keymap_translate_keyboard_state () in http://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkkeys-x11.c, and see if they are supposed to be broken? This bug is sitting for six month in the gnome bugzilla now, and it doesn't look like someone knows a definite answer as to what exactly is broken.
Comment 23 Matthias Clasen 2012-09-02 00:58:20 UTC
I'm reopening this.
My own investigation confirms the finding in comment 17.
The xkeyboard-config changes in 2.4.1 make XKB translate Shift-F10 into F10 with level one, while telling my that the Shift modifier got consumed.
Comment 24 Matthias Clasen 2012-09-02 01:02:55 UTC
Also note that xev output being identical is pretty irrelevant here, since xev only reports the core key events, not xkb data. that can be extracted from the combination of key events + xkb maps.
Comment 25 Matthias Clasen 2012-09-02 02:23:03 UTC
    type "CTRL+ALT" {
        modifiers = Control+Alt+Shift+LevelThree;
        map[None] = Level1;
        map[Shift] = Level2;
        map[LevelThree] = Level3;
        map[Shift+LevelThree] = Level4;
        map[Control+Alt] = Level5;
        preserve[Shift] = Shift;
        preserve[Shift+LevelThree] = Shift;
        level_name[Level1] = "Base";
        level_name[Level2] = "Shift";
        level_name[Level3] = "Alt Base";
        level_name[Level4] = "Shift Alt";
        level_name[Level5] = "Ctrl+Alt";
    };

Here is a modified type for CTRL+ALT that works in my testing.
It is similar to the one in comment 17, but avoids blowing up the map with lots of new entries.

With this map, XkbTranslateKeyCode still translates Shift-F10 into F10 at level1, but the Shift modifier is now preserved, so GTK+ uses it when matching  accelerators, and thus F10 and Shift-F10 can once again have different bindings.
Comment 26 Sergey V. Udaltsov 2012-09-02 07:58:34 UTC
Thanks, that idea with preserve looks nice! Pushed.