Many people have existing xorg.conf & XF86config files that specify use of the "keyboard" driver. If they upgrade to the current release on a platform with the deprecated driver disabled, the server refuses to start, instead printing an error message: *** ERROR the legacy keyboard driver "keyboard" is deprecated *** and has not been compiled into this X server. It will be removed *** in the next release of the Xorg server. *** Please consider using the the new "kbd" driver for "Keyboard0". xc/programs/Xserver/hw/xfree86/common/xf86Init.c should be changed so that the message is only a warning, not a fatal error, and the server should simply load kbd instead for the given device.
Created attachment 639 [details] [review] Patch to create compatibility "keyboard" driver This patch adds module structures to kbd.c so the resulting .o can be loaded as an input driver named "keyboard". The changes to the Imakefile creates a new target which is just the new driver, but named "keyboard". Thus two drivers are build: kbd_drv.o and keyboard_drv.o, which is basically the same driver, except the latter will load as "keyboard". I've removed the warning about loading the "keyboard" driver, since I see no problem in just keeping this setup.
build now fails if USE_DEPRECATED_KEYBOARD_DRIVER is set to YES: [...] xf86Configure.c:261:2: #error hat xf86Configure.c: [...] #ifdef USE_DEPRECATED_KEYBOARD_DRIVER #error hat ptr->inp_driver = "keyboard"; #else ptr->inp_driver = "kbd"; #endif [...] Typo?
(In reply to comment #2) ... > #error hat ... > Typo? Heh, very much. This was used for testing the patch, shouldn't bere, of coure.
(In reply to comment #3) > (In reply to comment #2) > ... > > #error hat > ... > > Typo? > > > Heh, very much. This was used for testing the patch, shouldn't bere, of coure. Argh, typo attack... I meant to say that it shouldn't be there.
(In reply to comment #2) Wait, this is actually #1078, and the patch is in the tree. Eww, that's embarrassing... will commit fix.
Patch tested and checked in. Closing and moving to documentation bug 999.
Hmm ... looks like specifying Driver "Keyboard" ^ no longer works. Using Driver "keyboard" ^ instead works. So in this case the config file is case-sensitive now?
(In reply to comment #7) > Hmm ... looks like specifying > > Driver "Keyboard" > ^ > no longer works. Using > > Driver "keyboard" > ^ > instead works. So in this case the config file is case-sensitive now? Not just in this case, it was always case sensitive. For example, Driver "Mouse" doesn't work. It's just that the old code would fall back to the built-in driver if no valid keyboard driver was specified.
You're right. Specifying "Mouse" doesn't work. So this seems to be a misinformation that the config file is not case-sensitive. This needs to be fixed in SuSE's X11 configuration program (SaX2). BTW, where can I find some documentation about the new "kbd" driver? Most likely it makes sense to switch to the new driver anyway.
(In reply to comment #9) > You're right. Specifying "Mouse" doesn't work. So this seems to be a > misinformation that the config file is not case-sensitive. This needs to be > fixed in SuSE's X11 configuration program (SaX2). I think only keywords (Section, EndSection, Option, Device etc) are case insensitive. Strings are not case insensitive, or I guess it depends on the code that uses the strings. > BTW, where can I find some documentation about the new "kbd" driver? There's a man page, man kbd. It supports basically the same options as the old driver. My understanding is that the new driver is mostly based on the old driver, just modularized and broken up into os-specific parts to avoid the #ifdef-hell. > Most likely it makes sense to switch to the new driver anyway. I would very much encourage that. The plan is to get rid of the old driver for the next release, so the more testing we get of the new driver before that happens, the better. I'm afraid we might see some bugs again that have been fixed in the old driver, but we need to take the plunge and move away from the old driver so the core code can be cleaned up.
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.