Bug#574590: xserver-xorg: Regression: no graceful treatment of broken keyboard config
reassign 574590 xserver-xorg-core
fixed 574590 2:1.9.99.902-1
kthxbye
On Sat, Feb 26, 2011 at 12:49:21 +0100, Cyril Brulebois wrote:
> Hi,
>
> Shai Berger <shai@platonix.com> (19/03/2010):
> > Please restore the behavior where a broken config means a
> > partially-broken keyboard rather than a disabled one. A warning of
> > some sort may be warranted as a means to letting a user know
> > something's wrong, if that's suddenly become a priority after years
> > of leniency, but killing the keyboard is, well, overkill.
> >
> > Also, if the keyboard is disabled, over a broken config, it warrants
> > a log (EE) message IMHO. I have seen no such (relevant) messages in
> > the logs, neither on my machine nor on the referenced bugs.
>
> I think it's still the case with current versions, but I think some
> fallback is being considered. Hopefully that's going to be resolved
> “soon”.
>
Should be fixed with:
commit d3499556d8d83396fa2585bd00371a81e086be36
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date: Thu Feb 10 15:12:14 2011 +1000
xkb: if the keymap failed to compile, load the default keymap instead.
We really need symbols, compat, keynames, vmods and types for a sensible keymap.
Try this in your xorg.conf.d snippets for all keyboards:
Option "XkbLayout" "us"
Option "XkbVariant" "nodeadkeys"
us(nodeadkeys) doesn't exist so xkbcomp provides everything but the symbols
map. We say we want everything but don't _need_ anything, the server happily
gives us a keymap with every key mapped to NoSymbol. This in turn isn't what
we want after all.
So instead, require symbols, compat, keynames, vmods and types from the
keymap and if that fails, load the default keymap instead. If that fails
too, all bets are off.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Cheers,
Julien
Reply to: