Summary: | XKB support for evdev | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Adam Jackson <ajax> | ||||||||||
Component: | Input/evdev | Assignee: | Zephaniah E. Hull <warp-spam+fdo> | ||||||||||
Status: | RESOLVED FIXED | QA Contact: | |||||||||||
Severity: | normal | ||||||||||||
Priority: | high | CC: | conselvan2, ekunze, freedesktop-bugs, sherif, xake | ||||||||||
Version: | 6.8.99.16 | ||||||||||||
Hardware: | All | ||||||||||||
OS: | All | ||||||||||||
Whiteboard: | |||||||||||||
i915 platform: | i915 features: | ||||||||||||
Bug Depends on: | |||||||||||||
Bug Blocks: | 968 | ||||||||||||
Attachments: |
|
Description
Adam Jackson
2005-07-30 03:57:52 UTC
Created attachment 3039 [details] [review] evdev-xkb-2.patch this might do the trick. With my German layout Logitech diNovo Media Desktop keyboard and also with a no-name German layout USB keyboard some of the keycodes are wrong. I have to use the following xmodmap: keycode 113 = Left keycode 114 = Right keycode 111 = Up keycode 116 = Down keycode 108 = ISO_Level3_Shift keycode 119 = Delete keycode 118 = Insert keycode 110 = Home keycode 115 = End keycode 112 = Prior keycode 117 = Next keycode 127 = Pause keycode 107 = Print (This is probably not exhaustive, I have not tested the separate MediaPad.) This is my xorg.conf entry for the keyboard: Section "InputDevice" Identifier "Keyboard0" Driver "evdev" Option "XkbLayout" "de" Option "XkbVariant" "nodeadkeys" Option "XkbModel" "logidmd" Option "Dev Name" "Generic USB Keyboard" Option "Dev Phys" "00:07:61:1F:DD:4A" Option "Device" "/dev/input/event5" EndSection I use this with Fedora Core 3 and the stock xorg 6.8.2 coming with the distribution patched with evdev and multi-seat support. Created attachment 3821 [details]
evdev-keycodes-new
the keycodes attached to the original patch were bogus, these should be better.
as far as i know this is totally working with these keycodes. please test so i
can commit this.
(In reply to comment #3) > Created an attachment (id=3821) [edit] > evdev-keycodes-new > > the keycodes attached to the original patch were bogus, these should be better. > > > as far as i know this is totally working with these keycodes. please test so i > can commit this. Please update the patch with the updated keycodes, then I'll try it. This does not work with Brazillian ABNT2 keyboard. For this keyboard, the BKSL key have an alternate keycode (94), the key 51 (BKSL) is used for bracketright. I guess that it should have a new session, like in the xorg keycodes: xkb_keycode "abnt2" { include "evdev" alternate <BKSL> = 94; <AC12> = 51; <KPPT> = 129; <AB11> = 97; } But to use this, the xkb map must set with: XkbKeycode "evdev(abnt2)" XkbLayout "br" instead of something base in rules, model and layout. I'm not sure if this is correct. *** Bug 5501 has been marked as a duplicate of this bug. *** The windows key entries are incorrect, based on the two keyboards that I tried. Should be: <LWIN> = 133; <RWIN> = 134; <MENU> = 135; How does this proceed? I've tried the patch agains modular xorg and xbkdata did go well (after adjustments for imake -> make). The patching of evdev.c did go well (with an offset of 15 lines for hunk #3-7) however it will not compile. xf86-input-evdev-1.0.0.5 gcc-4.0.2 i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -march=pentium4 -pipe -O2 -fomit-frame-pointer -DXFree86Server -DIN_MODULE -DXFree86Module -DXFree86LOADER -I/usr/include/xorg -I../src -MT evdev.lo -MD -MP -MF .deps/evdev.Tpo -c evdev.c -fPIC -DPIC -o .libs/evdev.o evdev.c:104: error: conflicting types for 'EvdevRec' evdev.c:90: error: previous declaration of 'EvdevRec' was here evdev.c:104: error: conflicting types for 'EvdevPtr' evdev.c:90: error: previous declaration of 'EvdevPtr' was here evdev.c: In function 'EvdevProc': evdev.c:636: error: 'struct <anonymous>' has no member named 'kernel24' evdev.c:644: error: 'struct <anonymous>' has no member named 'kernel24' evdev.c: In function 'EvdevProbe': evdev.c:682: error: 'struct <anonymous>' has no member named 'kernel24' evdev.c:731: error: 'struct <anonymous>' has no member named 'kernel24' make[2]: *** [evdev.lo] Error 1 Hello everyone! I am trying to get evdev to work with my USB keyboard and Mouse, but facing multiple problems. I am using modular X.org server along with xkeyboard-config for keyboard data. Using the normal drivers ( kbd and mouse ) everything works fine, including layout switching. I tried patching the evdev input driver, and the xkeyboard-config package , but to no avail. The patches I used are from here and the blocking bug ( against cvs head ). I login into gnome and the session crashes at once. Logging into a plain openbox desktop, is ok until I start gnome-settings-daemon, then it tries to set the keyboard map and crashes. I seem to have narrowed it down to this test case with gnome-settings-daemon: " The program 'gnome-settings-daemon' received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 461 error_code 2 request_code 149 minor_code 29) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) [1138022065,000,xklavier.c:XklStartListen/] The backend does not require manual layout management - but it is provided by the application " It seems that the evdev driver is still no exporting xkb capibilities. I am ready to test any newer patches, thanks for your cooperation. Created attachment 4445 [details] [review] original evdev-xkb-2.patch with fixed compile errors and redefined LWin, Rwin, Menu keycodes. this patch join both previous patches and fix corresponding compile errors. It also redefine the keycodes for LWin, Rwin, Menu buttons as was sujjested by Eric Kunze. Okay will try this one in a few hours, hope it fixes things :P Tried the new patch on the monolithic Xorg-6.9 provided in mandriva-2006 and evdev driver. Works almost perfectly. KDE and Gnome can now set keyboard layouts properly, and the user can switch them. However the mapping for the arrow keys is missing .. I will try to modify the keymap for this. Thanks a lot guys for your help. actually I can see the buttons defined correctly in the patch, matching with what xev says. But then I noticed xorg is not using the proper evdev rules. I think gnome/kde set the layout using the compat names which doesn't pickup the evdev rules; does that make any sense? I tried using setxkbmap with various options.. but in the end I couldn't get it to load a correct map. Any pointers to how to fix this please ? Ok somewhat found the problem.. I removed the old configuration from kde and gnome and started with a fresh one. Then I set my keyboard in xorg.conf like this : Section "InputDevice" Identifier "keyboard0" Driver "evdev" Option "Device" "/dev/input/event0" Option "XkbModel" "evdev" Option "XkbLayout" "us,ara(digits)" Option "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll,compose:rwin" EndSection This worked perfectly in GNOME since it doesn't force any keyboard model when I use it's tool to set the layouts. It just shows "unkown" for keyboard layout and keeps it that way. KDE however thinks it's smarter and forces a pc104 model, which of course messes up the keyboard again. I will try to find a way to stop it from doing this. Thanks guys for all your wonderful work. Fixed it by adding an "evdev" keyboard model to the model list. Is this the right thing to do? I dunno, but it works like a charm. GNOME now will display "evdev based keyboard" instead of "unknown" and KDE will show it and work fine. I will attatch the minor patch here. Created attachment 4482 [details] [review] patch to add evdev keyboard model. Here it is.. I don't know about the translations in xorg.xml , can someone have a look. Thinking about this again, I don't understand why an evdev keyboard model fixed things.. It doesn't make sense; the keyboard model is a physical thing, has nothing to do with the keycodes generated. Any ideas? Reassign to the new evdev maintainer. fixed in head, no? I have no problems with current head and the rewritten driver, just some keys not giving output despite reactions in xev. But it is localized alright. this is fixed in cvs head evdev |
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.