keyboard, evdev and bug 7800
cyrusthevirus
Under X11R6.9, with this configuration:
Section "InputDevice"
Identifier "KeyboardPs2"
Driver "evdev"
Option "Device" "/dev/input/event0"
Option "AutoRepeat" "500 30"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "it"
EndSection
my keyboard uses the default "us" layout, while with this trivial one:
Section "InputDevice"
Identifier "Keyboard"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "it"
EndSection
the layout is the right one, but the keyboard don't work in the
multiseat configuration.
I've found some references to this in google, like
https://bugs.freedesktop.org/show_bug.cgi?id=7800
It seem there could be workarounds, however.
Has someone experience of this?
TIA
Cyrus (the /perplexed/ virus)
--
I love to be mailed just by smart people:
perl -we 'print "\12\142\145\162\156\141\155\141\100\151".
"\164\167\145\142\56\151\164\12\12";'
CptDondo
Interesting. I've run into the same behaviour in my multi-seat config
using a Japanese keyobard. Basically, many of the keys don't work, even
with the correct (i.e. working in a single-seat setup) xorg.conf entry.
So I can confirm the behavior, but I can't offer a solution. It has me
stumped.
> athena:~# X -version
>
> X Window System Version 7.1.1
> Release Date: 12 May 2006
> X Protocol Version 11, Revision 0, Release 7.1.1
> Build Operating System: UNKNOWN
> Current Operating System: Linux athena 2.6.18ys #1 Sun Oct 29 15:58:57 PST 2006 i686
> Build Date: 07 July 2006
> Before reporting problems, check http://wiki.x.org
> to make sure that you have the latest version.
> Module Loader present
--Yan
cyrusthevirus
> Interesting. I've run into the same behaviour in my multi-seat config
> using a Japanese keyobard. Basically, many of the keys don't work, even
> with the correct (i.e. working in a single-seat setup) xorg.conf entry.
>
> So I can confirm the behavior, but I can't offer a solution. It has me
> stumped.
Multiseaters of the world, unite! You have nothing to lose but your
layouts! :-D
Yan,
thanks for your informations: at least now I know this behavior is not
due to my stale version of X Window.
what happens if you remove the Device line from xorg.conf?
And which driver are you using? evdev or kbd?
Cyrus (the /co-stumped/ virus)
Captain Dondo
> Il 15/01/2007 18:20, CptDondo dixit:
>
>> Interesting. I've run into the same behaviour in my multi-seat config
>> using a Japanese keyobard. Basically, many of the keys don't work, even
>> with the correct (i.e. working in a single-seat setup) xorg.conf entry.
>>
>> So I can confirm the behavior, but I can't offer a solution. It has me
>> stumped.
>
> Multiseaters of the world, unite! You have nothing to lose but your
> layouts! :-D
>
> Yan,
> thanks for your informations: at least now I know this behavior is not
> due to my stale version of X Window.
> what happens if you remove the Device line from xorg.conf?
> And which driver are you using? evdev or kbd?
Well, I don't know if you ran into this, but after I upgraded to 2.6.19,
all my /dev/input devices started moving around. Every time I rebooted,
the devices would get a different number assigned.
So... It turns out that the evdev driver is very braindamaged when it
comes to device names. It will only accept device names of the form
'/dev/input/event*', but also the event numbers must not have a leading
0.... And symlinks don't count.
The only way I was able to get reliable device addressing was to use the
physical address, which kind of defeats the purpose of hot-plugging.
The entries in by-user aren't used by X; they're just a mnemonic to the
poor admin (me) so he/I can remember how this bloody machine is set up.
Here's my udev rules for the multiuser sessions:
# SYSFS{product}=="Microsoft 5-Button Mouse with IntelliEye_TM_"
# SYSFS{manufacturer}=="Microsoft"
SYSFS{phys}=="usb-0000:00:10.0-1/input0", NAME="input/mouse10", SYMLINK+="input/by-user/MouseJason", OPTIONS+="last_rule"
# SYSFS{product}=="RF USB Receiver"
# SYSFS{manufacturer}=="A4Tech"
SYSFS{phys}=="usb-0000:00:10.0-2.1/input1", NAME="input/mouse11", SYMLINK+="input/by-user/MouseAkari", OPTIONS+="last_rule"
SYSFS{phys}=="isa0060/serio1/input0", NAME="input/mouse12", SYMLINK+="input/by-user/MouseMyth", OPTIONS+="last_rule"
# the MS keyboard isn't identified ????
SYSFS{phys}=="usb-0000:00:10.2-2/input0", NAME="input/event10", SYMLINK+="input/by-user/KbdJason", OPTIONS+="last_rule"
# SYSFS{product}=="RF USB Receiver"
# SYSFS{manufacturer}=="A4Tech"
SYSFS{phys}=="usb-0000:00:10.0-2.1/input0", NAME="input/event11", SYMLINK+="input/by-user/KbdAkari", OPTIONS+="last_rule"
SYSFS{phys}=="isa0060/serio0/input0", NAME="input/event12", SYMLINK+="input/by-user/KbdMyth", OPTIONS+="last_rule"
cyrusthevirus
> Well, I don't know if you ran into this, but after I upgraded to 2.6.19,
> all my /dev/input devices started moving around. Every time I rebooted,
> the devices would get a different number assigned.
I don't know. I've not yet rebooted since I had an almost working
configuration...
> So... It turns out that the evdev driver is very braindamaged when it
> comes to device names.
Even with the keyboard layout, it seems.
Or perhaps the missing layouts are due to a wrong device addressing
(could be a clue).
> The only way I was able to get reliable device addressing was to use the
> physical address, which kind of defeats the purpose of hot-plugging.
What happens if you scramble the cables before booting?
> Here's my udev rules for the multiuser sessions:
Interesting!
My udev configuration was planned just after a working keyboard, but
I'll see if using your method will give me a quick fix.
--
I love to be mailed just by smart people:
perl -we 'print "\12\142\145\162\156\141\155\141\100\151".
"\164\167\145\142\56\151\164\12\12";'
Spammers scratch here with a diamond to find my address:
|||||||||||||||||||||||||||||||||||||||||||||||
CptDondo
> Il 23/01/2007 16:25, Captain Dondo dixit:
>
>> Well, I don't know if you ran into this, but after I upgraded to 2.6.19,
>> all my /dev/input devices started moving around. Every time I rebooted,
>> the devices would get a different number assigned.
>
> I don't know. I've not yet rebooted since I had an almost working
> configuration...
>
>> So... It turns out that the evdev driver is very braindamaged when it
>> comes to device names.
>
> Even with the keyboard layout, it seems.
> Or perhaps the missing layouts are due to a wrong device addressing
> (could be a clue).
>
>> The only way I was able to get reliable device addressing was to use the
>> physical address, which kind of defeats the purpose of hot-plugging.
>
> What happens if you scramble the cables before booting?
I'm screwed.... But now that I've figured out the /dev/input/event*
naming scheme, I think I can go back and twiddle one keyboard at a time
and see if I can ID them by USB ID.
The problem is the wireless keyboard and mouse; they share the same USB
ID but have different interfaces. That information shows up in
different sections and so cannot be used by udev - at least not until
how I figure out how to chain udev rules.
>
>
>> Here's my udev rules for the multiuser sessions:
>
> Interesting!
> My udev configuration was planned just after a working keyboard, but
> I'll see if using your method will give me a quick fix.
>
I haven't had the guts to try the Japanese keyboard layout yet. That's
for the other multi-seat machine....
(I'm on a radical computer reduction program at the house; I am setting
up 2 shared computers to replace 5 individual boxes.)
--Yan
cyrusthevirus
> cyrusthevirus wrote:
>> What happens if you scramble the cables before booting?
>
> I'm screwed....
So it would be better to screw the plugs, I guess.
> I haven't had the guts to try the Japanese keyboard layout yet. That's
> for the other multi-seat machine....
Hint: I'm using this script to test different layouts (from
/etc/X11/xkb/symbols).
----------- %< ---------------- %< -----------------
#!/bin/bash
# reset _XKB_RULES_NAMES property to xorg - 8s is the string length
xprop -root -f _XKB_RULES_NAMES 8s -set _XKB_RULES_NAMES "xorg"
echo -e "\n-----------------------------------\nxprop done\n\n";
# set xkb parameters:
setxkbmap -v 10 -rules "xorg" -keycodes "xfree86" -types "default" \
-compat "default" -symbols "en_US(pc102)+it" -geometry "pc(pc102)"
echo -e "\n-----------------------------------\nsetxbmap done\n\n";
# show or save xkb parameters:
xmodmap -pm -pk > /tmp/charlist.tmp
----------- %< ---------------- %< -----------------
Now I'm rewriting my own layout, to add supplemental characters to the
default Italian keyboard, but I'm still lacking something.
This link could be quite useful: http://pascal.tsu.ru/en/xkb/
> (I'm on a radical computer reduction program at the house; I am setting
> up 2 shared computers to replace 5 individual boxes.)
Good idea: it saves a lot of power.