Bug 14359

Summary:	deferred XKB init breaks use of custom types
Product:	xorg	Reporter:	Matthias B. <haferfrost>
Component:	Server/Input/Core	Assignee:	Xorg Project Team <xorg-team>
Status:	RESOLVED FIXED	QA Contact:	Xorg Project Team <xorg-team>
Severity:	normal
Priority:	medium	CC:	haferfrost
Version:	unspecified
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Matthias B. 2008-02-03 11:12:18 UTC

I tried to set my own custom keymap with xkbcomp in .xinitrc but it doesn't work. More precisely, it works if I insert a little sleep before the call and press a button before xkbcomp is started. If I don't do that, my custom keymap does not become active (or rather, it becomes active but is later reset). 

It seems as if the XKB component does not initialize itself completely until the first keypress and when that comes, it sets the keymap to the values specified in xorg.conf (thereby overwriting my custom keymap). I have confirmed this by putting the following into .xinitrc

xterm -e 'while true; do sleep 1 ; xkbcomp :0 - | grep MSB ; done' &

This starts an xterm that continously runs xkbcomp to check if my keymap is installed (recognizable by the string "MSB"). As long as I don't press a key, it finds the string "MSB". But the instant I press a key, the result is negative.

Comment 1 Julien Cristau 2008-02-03 15:52:33 UTC

(In reply to comment #0)

which server version are you using?  i seem to remember similar reports against 1.4.0, which should be fixed in 1.4.0.90. reassigning anyway, as this isn't an xkbcomp issue.

Comment 2 Matthias B. 2008-02-04 02:37:44 UTC

I'm using 1.4.0.90, so it's not fixed there.

Comment 3 Matthias B. 2008-02-04 06:35:14 UTC

The problem is worse than I thought. The deferred initialization of XKB does not only break using xkbcomp in .xinitrc, it also breaks my custom keymap when I configure it via xorg.conf. I have a custom keymap that redefines the FOUR_LEVEL_* types to prevent auto-capitalization of letters when the Lock modifier is set. Unfortunately, for whatever reasons, the types redefinition (unlike the symbols redefinition) only affects clients started after the keymap has been set. At least that's true for xterms. Because of the deferred initialization, my custom keymap does not work properly with programs started before the first keypress. Unfortunately I start basically all programs I usually work with automatically via .xinitrc.

Is there a workaround? Can I somehow force the initialization of the keymap?

Comment 4 Peter Hutterer 2008-05-20 01:49:48 UTC

(In reply to comment #3)
> The problem is worse than I thought. The deferred initialization of XKB does
> not only break using xkbcomp in .xinitrc, it also breaks my custom keymap when
> I configure it via xorg.conf. I have a custom keymap that redefines the
> FOUR_LEVEL_* types to prevent auto-capitalization of letters when the Lock
> modifier is set. Unfortunately, for whatever reasons, the types redefinition
> (unlike the symbols redefinition) only affects clients started after the keymap
> has been set. At least that's true for xterms. Because of the deferred
> initialization, my custom keymap does not work properly with programs started
> before the first keypress. Unfortunately I start basically all programs I
> usually work with automatically via .xinitrc.

just a stab in the dark:
could it be the following weird race condition?
the input-hotplug code relies on dbus/hal. IIRC, the dbus handler is treated like a socket and added to the standard select loop.
Naturally, some time elapses before all devices have been sent to the server and initialised. These devices are always added with default settings as in /etc/hal/fdi/policy/x11-input.fdi

During this time, clients that are started through xinitrc may start up, connect to the x server, get the current keymap, which is not the one you defined.

To test this, a simple sleep 15 in xinitrc should be enough. After that timeout, all devices should be initialised and you can call xkbcomp and start your applications.

Comment 5 Matthias B. 2008-05-22 02:51:18 UTC

I run neither HAL nor DBUS, so that's not my problem. I've tried sleeps and they haven't helped.

Comment 6 Peter Hutterer 2008-09-18 18:49:15 UTC

Should be fixed with the commits leading up to c06e27b2f6fd9f7b9f827623a48876a225264132.

Please reopen if this is still an issue.

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.