Bug 3912 - XKB support for evdev
Summary: XKB support for evdev
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/evdev (show other bugs)
Version: 6.8.99.16
Hardware: All All
: high normal
Assignee: Zephaniah E. Hull
QA Contact:
URL:
Whiteboard:
Keywords:
: 5501 (view as bug list)
Depends on:
Blocks: 968
  Show dependency treegraph
 
Reported: 2005-07-30 03:57 UTC by Adam Jackson
Modified: 2006-04-01 16:56 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
evdev-xkb-2.patch (28.16 KB, patch)
2005-08-25 19:28 UTC, Adam Jackson
no flags Details | Splinter Review
evdev-keycodes-new (6.96 KB, text/plain)
2005-11-17 10:32 UTC, Adam Jackson
no flags Details
original evdev-xkb-2.patch with fixed compile errors and redefined LWin, Rwin, Menu keycodes. (27.64 KB, patch)
2006-01-24 08:53 UTC, Mikhail Kshevetskiy
no flags Details | Splinter Review
patch to add evdev keyboard model. (1.13 KB, patch)
2006-01-26 23:03 UTC, Islam Amer
no flags Details | Splinter Review

Description Adam Jackson 2005-07-30 03:57:52 UTC
the evdev input driver is totally ignorant of XKB, it should be remappable like
any other keyboard.
Comment 1 Adam Jackson 2005-08-25 19:28:02 UTC
Created attachment 3039 [details] [review]
evdev-xkb-2.patch

this might do the trick.
Comment 2 Peter Hofmann 2005-09-20 15:12:50 UTC
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.
Comment 3 Adam Jackson 2005-11-17 10:32:39 UTC
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.
Comment 4 Robert Lundmark 2005-12-06 00:23:56 UTC
(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.
Comment 5 Ander Conselvan de Oliveira 2005-12-17 00:18:19 UTC
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.
Comment 6 Adam Jackson 2006-01-06 08:58:04 UTC
*** Bug 5501 has been marked as a duplicate of this bug. ***
Comment 7 Eric Kunze 2006-01-11 10:42:44 UTC
The windows key entries are incorrect, based on the two keyboards that I tried.

Should be:
<LWIN> = 133;
<RWIN> = 134;
<MENU> = 135;
Comment 8 Peter Hjalmarsson 2006-01-18 19:58:16 UTC
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

Comment 9 Islam Amer 2006-01-23 22:56:30 UTC
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.
Comment 10 Mikhail Kshevetskiy 2006-01-24 08:53:17 UTC
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.
Comment 11 Islam Amer 2006-01-24 09:47:58 UTC
Okay will try this one in a few hours, hope it fixes things :P
Comment 12 Islam Amer 2006-01-25 23:31:43 UTC
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.
Comment 13 Islam Amer 2006-01-26 00:30:20 UTC
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 ?
Comment 14 Islam Amer 2006-01-26 19:35:11 UTC
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.
Comment 15 Islam Amer 2006-01-26 23:02:09 UTC
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.
Comment 16 Islam Amer 2006-01-26 23:03:52 UTC
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.
Comment 17 Islam Amer 2006-01-28 15:27:12 UTC
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?
Comment 18 Zephaniah E. Hull 2006-02-16 11:02:40 UTC
Reassign to the new evdev maintainer.
Comment 19 Daniel Stone 2006-03-05 08:08:22 UTC
fixed in head, no?
Comment 20 Peter Hjalmarsson 2006-03-16 01:33:00 UTC
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.
Comment 21 Daniel Stone 2006-04-02 10:56:52 UTC
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.