Bug 93701

Summary: xcb_xkb_get_names reply always returns "us" layout until XCB_XKB_NEW_KEYBOARD_NOTIFY detects first keypress
Product: xorg Reporter: Florian Hubold <doktor5000>
Component: Server/GeneralAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED MOVED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: geert, rdieter
Version: 7.7 (2012.06)   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Print group names none

Description Florian Hubold 2016-01-13 20:18:37 UTC
It was suggested via https://github.com/sddm/sddm/issues/202 to report this here as it seems to be an XCB bug. To reproduce, start e.g. sddm with a non-english keyboard layout (selected via localectl) and it will always show "us" layout until the first key has been pressed, then the correct layout will be shown and also used.

More detailed description via davispuh: https://github.com/sddm/sddm/issues/202#issuecomment-133628462

> This is Xcb bug (even with latest libxcb from git master branch), because in XcbKeyboardBackend::initLayouts
> 
>         cookie = xcb_xkb_get_names(m_conn,
>                 XCB_XKB_ID_USE_CORE_KBD,
>                 XCB_XKB_NAME_DETAIL_GROUP_NAMES | XCB_XKB_NAME_DETAIL_SYMBOLS);
>         reply = xcb_xkb_get_names_reply(m_conn, cookie, nullptr);
> it always returns "us" layout on startup, but as soon as any key is pressed then > XCB_XKB_NEW_KEYBOARD_NOTIFY event will be issued and then it will return correct > layout.
Comment 1 Ran Benita 2016-01-13 23:19:19 UTC
Created attachment 121010 [details]
Print group names

The linked code in `XcbKeyboardBackend::initLayouts` seems OK to me (other than wrong error handling for `xcb_xkb_get_names`).

Please run the attached (abbreviated) program and see if it prints the expected group names (it does for me).
Comment 2 Florian Hubold 2016-01-14 20:37:31 UTC
Thanks (In reply to Ran Benita from comment #1)
> Please run the attached (abbreviated) program and see if it prints the
> expected group names (it does for me).

Thanks for the testcase, works fine here after compiling with -std=c11 added, it returns: "German (eliminate dead keys)".

But from what I understood, this is not the actual issue.
I'll try to run it directly after X / DM starts, before the first keypress (that is before XCB_XKB_NEW_KEYBOARD_NOTIFY is run the first time).
Comment 3 Florian Hubold 2016-02-07 10:12:37 UTC
(In reply to Ran Benita from comment #1)
> Created attachment 121010 [details]
> Print group names
> Please run the attached (abbreviated) program and see if it prints the
> expected group names (it does for me).

Tried that, and it's exactly as described in the sddm bugreport. Before any keypress, that program returns "English (US)" and after the first keypress or in the regular session it returns "German (eliminate dead keys)" as expected in my case.

Although that doesn't really help in finding out what's wrong, or does it?
Comment 4 Ran Benita 2016-02-07 12:10:18 UTC
From what you describe, it is likely a server bug (or not a bug). My guess is that for some reason you initially get the default RMLVO (XKB configuration) for the core keyboard device. The default is US (unless it is changed in the xserver build ./configure). You can try to trace back the callers of this function: http://cgit.freedesktop.org/xorg/xserver/tree/xkb/xkbInit.c?id=e6b106715f24112d1dc7a84c6e37df4b5debb2d0#n112

You say that you set the XKB config through localctl, which IIRC writes an xserver config file with the RMLVO. This means you should be getting the correct keymap right from the start. But there might be some lazy initialization or race condition or maybe it's intentional.

I don't have time to investigate myself, but maybe that helps. In any case I suggest you move the bug to the server component.
Comment 5 Florian Hubold 2016-02-07 20:44:10 UTC
(In reply to Ran Benita from comment #4)
> You say that you set the XKB config through localctl, which IIRC writes an
> xserver config file with the RMLVO. This means you should be getting the
> correct keymap right from the start. But there might be some lazy
> initialization or race condition or maybe it's intentional.

Yep, sounds about right. After one keypress the correct keymap is, like reloaded or whatever.
 
> In any case I suggest you move the bug to the server component.

Ok, will do, and thanks for the hints, appreciated :)

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.