You are not logged in.
Hello archlinux users!
I don't know how and where to fill in an bug report, so I'm writing here about my problem. With the newest version from testing of xorg-server and xf86-input-evdev I have a problem with my Logitech Media Keyboard 600. Some keys like the arrow keys, the num pad, the home, del etc. keys are not working. Per example the arrow-up key is triggering the Screenshot button.
I've solved my problem with downgrading both packages. If the bug has been already reported, sorry for this thread :)
Greetings,
maschino
Offline
I have the same problem with new xorg, gnome + compiz (up arrow take a screnshot). Fixed for me by selecting compiz option "loose binding".
edit: same problem afert rebooting
Last edited by wain (2008-02-21 15:36:44)
Offline
Hello archlinux users!
I don't know how and where to fill in an bug report, so I'm writing here about my problem. With the newest version from testing of xorg-server and xf86-input-evdev I have a problem with my Logitech Media Keyboard 600. Some keys like the arrow keys, the num pad, the home, del etc. keys are not working. Per example the arrow-up key is triggering the Screenshot button.
I've solved my problem with downgrading both packages. If the bug has been already reported, sorry for this thread
Greetings,
maschino
Same problem here, also with testing versions of xorg-server (1.4.0.90-7) and xf86-input-evdev (1.2.0-1).
Offline
:: ATTENTION!
:: Since xorg-server version 1.4.0.90-7 hal support has
:: been enabled. By default keyboard layouts and variants
:: will now be overridden by hal. Please modfiy
::
:: /etc/hal/fdi/policy/11-xkeyboard.fdi
::
:: to suit your needs and restart X.
changed following line to my layout but after X restart it changes back to default US layout.
<merge key="input.xkb.layout" type="string">us</merge>
thank god xorg devs aint japaneese or chineese
Last edited by con (2008-02-21 17:33:05)
charlie dont surf!
Offline
@maschino & everbody
The devs don't all read the forums, so your problem might not get seen. To file a bug report, go to the arch bugs page (the link is at the top of this page). You pick the correct project (in this case 'Arch Linux') and then search to see if your problem has already been reported (in this case 'xorg-server'). Review the results and either add comments/votes to an existing bug ,if there is one, or report your new bug. You'll need to set up a username and password. It's quite straightforward, and the instructions explain the information they're looking for.
Offline
So it looks like it's evdev that's the culprit. Though I have the testing version of xorg-server (1.4.0-90.7), my keyboard worked fine after I removed xf86-input-evdev. You'll see in /etc/hal/fdi/policy/11-xkeyboard.fdi that if evdev isn't available, xorg-server will fall back to keyboard.
I'm sure you can have your cake and eat it, too. I just don't have time to look into setting up evdev properly, so I'm content with the "fallback".
Offline
@tigrmesh:
thank you for your howto. I've filled in a bug report: http://bugs.archlinux.org/task/9647
I hope this was ok
@dhave:
Yeah, I also think it's the evdev driver. But my skills are not high enough to fix it by myself, so I'll use the older package until the developers take care about this bug.
Offline
Yes, the same problem for me. The solution I found (of course except for downgrading/uninstalling evdev, which is really just a way to avoid the problem) is the following:
Update your xorg.conf!
What I did is that I removed the section with the old keyboard "InputDevice" section:
#Section "InputDevice"
# Identifier "IntegratedKeyboard"
# Driver "kbd" <--- this is the line by which you identify the section (the rest might be different)
# Option "CoreKeyboard"
# Option "XkbModel" "pc105"
# Option "XkbLayout" "us,sk"
# possibilites for us: basic, euro, intl, alt-intl, altgr-intl
# Option "XkbVariant" "altgr-intl,qwerty"
# Option "XkbOptions" "grp:menu_toggle,grp_led:caps"
# Option "XkbRules" "xorg"
#EndSection
Removed the reference to this section from "ServerLayout" section, and added the reference to the new evdev keyboard section:
Section "ServerLayout"
Identifier "Xorg Configured"
Screen 0 "Default Screen" 0 0
# InputDevice "IntegratedKeyboard" "CoreKeyboard" <- note the comment here
InputDevice "evdevkeyboard" "CoreKeyboard" #<- new section (see below)
InputDevice "TrackPoint" "CorePointer"
.... possible some other options here ....
EndSection
And added the new evdev keyboard section:
Section "InputDevice"
Identifier "evdevkeyboard"
Driver "evdev"
Option "Device" "/dev/input/by-path/platform-i8042-serio-0-event-kbd" #<- set this path for your setting!
Option "XkbModel" "evdev"
Option "XkbLayout" "us,sk" #<- it's OK with just "us", but I use two layouts
Option "XkbVariant" "altgr-intl,qwerty" #<- for variants, have a look at e.g. /usr/share/X11/xkb/symbols/us
Option "XkbOptions" "grp:menu_toggle,grp_led:caps" #<- toggling layouts with win-menu key
Option "XkbRules" "xorg"
Option "evBits" "+1"
Option "keyBits" "~1-255 ~352-511"
Option "Pass" "3"
EndSection
Note that some keys will have different keycodes, especially multimedia keys... etc. Check by 'xev' and set your .xmodmaprc.
EDIT: I guess not to get distracted by my extra layouts and way to switch between them, here's a minimal config for evdev section, which should work:
Section "InputDevice"
Identifier "evdevkeyboard"
Driver "evdev"
Option "Device" "/dev/input/by-path/platform-i8042-serio-0-event-kbd" #<- set this path for your setting!
Option "XkbModel" "evdev"
Option "XkbLayout" "us"
Option "evBits" "+1"
Option "keyBits" "~1-255 ~352-511"
Option "Pass" "3"
EndSection
ANOTHER EDIT: the hal backend broke also some of my trackpoint (aka nipple) setting... but I didn't have another couple of hours to investigate that one yet
YET ANOTHER EDIT: With the setup described above, there is one thing which puzzles me, namely that when I run qemu now, inside the qemu the keys seem to be messed up. Most of them are fine, but arrows and such generate wrong keycodes (tested with 'xev' inside qemu).
Last edited by bender02 (2008-02-22 06:33:31)
Offline
Enough edits - new post:
I found a thread on gentoo forums, where some guy (Xake) explains the connections between hal/evdev/xorg, and how the configuration is supposed to be picked up. Interesting read... http://forums.gentoo.org/viewtopic-p-47 … 8e4a19c07a Recommended for anyone with keyboard/mouse xorg config problems.
But some of those people still have a problem with keys in vmware acting weird, and nobody proposed a solution (yet).
Offline
Yes, the same problem for me. The solution I found (of course except for downgrading/uninstalling evdev, which is really just a way to avoid the problem) is the following:
Update your xorg.conf!
Thanks, bender02. I assumed this wasn't a bug but rather a planned change, but I hadn't seen the instructions for exactly how to replace keyboard with evdev. I'll follow your lead this weekend and see how it goes. It's always fun to fix something that isn't broken, I think . At least this, if the fix breaks things, I can unfix the fix and easily go back to keyboard.
Offline
dhave: read around a bit first... apparently there are some other ways to do it as well. I just "wasted" a couple of hours trying to find out how to configure it properly...
If you don't want to waste time, apparently the quickest solution is to add
Section "ServerFlags"
Option "AutoAddDevices" "false"
EndSection
to xorg.conf. That prevents any autodetection, and xorg will use your previous setup from xorg.conf.
Offline
Everything you should do is:
1. comment out all InputSection's in xrog.conf
2. cp /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi /etc/hal/fdi/policy/ (you can also copy other policies for example I'm using 10-ibm-buttons.fdi but I'm not realy sure what does it do )
3. edit /etc/hal/fdi/policy/10-keymap.fdi
4. set proper keymap there instead of "us"
5. restart X
works for me.
Last edited by MAC!EK (2008-02-22 13:06:12)
Offline
dhave: read around a bit first... apparently there are some other ways to do it as well. I just "wasted" a couple of hours trying to find out how to configure it properly...
If you don't want to waste time, apparently the quickest solution is to add
Section "ServerFlags" Option "AutoAddDevices" "false" EndSection
to xorg.conf. That prevents any autodetection, and xorg will use your previous setup from xorg.conf.
Well, I wouldn't say your time is wasted, since (1) you evidently learned something and (2) you kept others -- me, in particular -- from wasting time!
I'm reluctant to turn off autodetection, since I'm reasonably happy with how xorg detects my display (though I admit I didn't like the idea at first). If I use 'Option "AutoAddDevice" "false"', will I lose autodetection of display, too, or just disable hot-plugging of input devices?
One way or the other, thanks for riding the wave on this one and letting the rest of us follow in your wake. Or whatever...
Offline
Everything you should do is:
1. comment out all InputSection's in xrog.conf
2. cp /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi /etc/hal/fdi/policy/ (you can also copy other policies for example I'm using 10-ibm-buttons.fdi but I'm not realy sure what does it do )
3. edit /etc/hal/fdi/policy/10-keymap.fdi
4. set proper keymap there instead of "us"
5. restart Xworks for me.
Looks like it's worth trying, though I'm still concerned about the possibility of problems with VMware (see Gentoo thread cited above).
Offline
2. cp /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi /etc/hal/fdi/policy/ (you can also copy other policies for example I'm using 10-ibm-buttons.fdi but I'm not realy sure what does it do )
Do you have to copy the files to /etc/hal/fdi/policy? Don't they get read by hal if they reside in the default location in /usr/share/hal/fdi/policy? All those .fdi files have a conditions in them, so even if they're read, if your hardware doesn't match the one mentioned in an ..fdi file, hal ignores it.
So, a question for people who understand how hal works better: do you need to copy all those files to /etc/hal/fdi/, or just those that need some editing?
EDIT: /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi (owned by hal) is essentially the same as
/etc/hal/fdi/policy/11-xkeyboard.fdi (owned by xorg-server). Which one to edit? the 11-.. overrides the 10-..., right?
So no copying necessary, just edit 11-...?
Last edited by bender02 (2008-02-22 16:18:13)
Offline
False alarm It's not working
Offline
False alarm It's not working
Offline
I just tried something:
- commented out all the input device sections in xorg.conf
- edited /etc/hal/fdi/policy/11-xkeyboard.fdi to reflect my keyboard settings (2 layouts, etc...)
- restarted hal, restarted xorg
- didn't work. Looking at /var/log/Xorg.0.log, it seemed that xorg/hal detected my kb twice, once as <default keyboard>, with default settings (us, pc105); second time as the stuff I specified in 11-xkeyboard.fdi.
- so I added back the "evdev keyboard" section to my xorg.conf, restarted xorg
- now it worked, in a way that only one correct keyboard was detected by xorg, switching layouts worked, etc...
- except the state of things is the same as I had after my first post: keys inside qemu screwed, some special keys not working (I have a laptop, so there are these combinations like Fn+F4, etc...)
- I concluded that evdev driver still not very well suited for laptop keyboards with special keys, and so I'm back to using the "kbd" driver in xorg.
EDIT forgot to say that I didn't copy any .fdi files around, just edited the 11-xkeyboard.fdi.
Also, when I say "added back the evdev keyboard section back to xorg.conf", I mean only the very minimal part (uhh, I don't remember if I added those 3 commented lines... very bad short memory I'd say... uh... what did I want to say anyway?)
Section "InputDevice"
Identifier "evdevkeyboard"
Driver "evdev"
Option "Device" "/dev/input/by-path/platform-i8042-serio-0-event-kbd"
# Option "evBits" "+1"
# Option "keyBits" "~1-255 ~352-511"
# Option "Pass" "3"
EndSection
Last edited by bender02 (2008-02-22 16:48:13)
Offline
I've done some more testing and here's my upgraded advice
1. comment out all InputSection's in xrog.conf
2. cp /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi /etc/hal/fdi/policy/12-keymap.fdi (note the "12" is important, don't modify /etc/hal/fdi/policy/11-xkeyboard.fdi because it's owned by xorg-server and it will be replaced after upgrade/reinstall of that package )
(you can also copy other policies for example I'm using 10-ibm-buttons.fdi but I'm not realy sure what does it do )
3. edit /etc/hal/fdi/policy/12-keymap.fdi
4. set proper keymap there instead of "us"
5. restart hal and then restart X
this works for me... editing 11-xkeyboard.fdi works also but as I wrote before, it will be probably replaced after upgrade/reinstall.
Last edited by MAC!EK (2008-02-23 13:44:29)
Offline
i Did all this and keep having some keys that dont work, for example:
F16 works but F14 and F15 dont, strange, is this a bug or is some conf that i am missing ?
Offline
Weird thing is when I use autologing in KDM then key up does printscreen, but when I don't use autologon the 'up' is ok.
Offline
i Did all this and keep having some keys that dont work, for example:
F16 works but F14 and F15 dont, strange, is this a bug or is some conf that i am missing ?
Some keys don't work for me as well. The xorg driver which serves your keyboard changed from kbd to evdev, so you can expect that some keys will generate different keycodes. You can use xev to see which keycodes various keys generate, and use xmodmap to map them to what you need.
Offline
I tried MAC!EK's howto but it didn't work for me. My Input Sections were commented out even before this new version because xorg better recognizes my mouse without any section for it.
With the changes I have the old bug with key-up makes a screenshot and so on. I'll stay on 1.4.0.90-6 until the devs get a real solution for this...
Greets,
maschino
Offline
With the changes I have the old bug with key-up makes a screenshot and so on. I'll stay on 1.4.0.90-6 until the devs get a real solution for this...
Most devs apparently want this change to be reverted. You can read the whole thread if you like :
http://archlinux.org/pipermail/arch-dev … 04865.html
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
Thank you for the link, it's nice to see that the devs are taking care about our problem
Offline