After upgrading to sys-apps/hal-0.5.10 arrow key and page_up page_down key dont work properly anymore Reproducible: Always Steps to Reproduce: 1. upgrade to sys-apps/hal-0.5.10 2. restart 3. try to use described keys Portage 2.1.4_rc1 (default-linux/x86/2007.0/desktop, gcc-4.2.2, glibc-2.7-r0, 2.6.23-gentoo-r2 i686) ================================================================= System uname: 2.6.23-gentoo-r2 i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz Timestamp of tree: Fri, 23 Nov 2007 08:00:01 +0000 app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.2-r1 dev-lang/python: 2.5.1-r4 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r2 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.UTF-8" LINGUAS="en de ru" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="7zip X a52 aac acl acpi alsa audacious berkdb bitmap-fonts bluetooth bzip2 cairo cdda cddb cdr cli cracklib crypt css cups curl dbus dga divx djvu dts dvd dvdr dvdread eds emboss encode evo exif fam fbcon ffmpeg firefox flac fortran ftp gdbm gif glut gpm gps gstreamer gtk gtk2 hal hddtemp iconv icq ieee1394 imlib irmc java javascript jpeg jpeg2k kde kdeenablefinal kdehiddenvisibility lesstif lzo mad md5sum midi mikmod mmx mmxext mng motif mp3 mpeg mplayer msn mudflap ncurses nls nptl nptlonly nsplugin ogg openal opengl openmp pam pcre pdf perl png pppd python qt-static qt3 qt3support quicktime rar readline real realmedia recode reflection reiserfs samba sdl seamonkey session slang sox spell spl sse sse-filters sse2 ssl ssse3 svg tcpd theora threads tiff truetype truetype-fonts unicode usb userlocales v4l v4l2 vcd vorbis wifi win32codecs wma wmf wxwindows x264 x86 xanim xcomposite xml xorg xpm xscreensaver xv xvid xvmc zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en de ru" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I have installed new hal-0.5.10 too, and my PgUp/PgDn keys still work. As well as arrows. I have a problem with layout switching in a new hal, but as I can't reproduce your problem, I presume that mine is a separate bug (posted it as bug #200061).
If xorg-server is going to rely on keyboard configuration to be stored in HAL and require that people write the files themselves, xorg-server should be like every other package out there (example, libgphoto2) and provide documentation on how to write configuration files since xorg.conf is not the place to configure your keyboard. Or provide some sample files.
Reading through xorg mailing list I discovered the following things: [quote] [...] there are three ways to configure [a keyboard]: a. with old kbd driver & legacy model: stuff like arrows will work, but multimedia keys will return garbage b. with evdev protocol and legacy model: arrows will break but multimedia keys will work c. with evdev protocol and evdev model: everything just works Most of the people complaining of evdev tried b. because evdev is underdocumented, it's a natural mistake to make and it's f* stupid to have made it a valid config in the first place. [/quote] Then I tried a couple of different combinations in xorg.conf and found that the following configuration works fine for me: *) set "evdev" as the driver to use both for keyboard and mouse (but keep "synaptics" for synaptics touchpad); *) set "XkbModel" to "evdev" in the keyboard section; *) keep the appropriate "XkbLayout" option for you keyboard; *) you _have_ to set Option "Device" also for keyboards (/dev/input/event4 on my laptop but YMMV). With the above configuration it is no longer necessary to set the keyboard mappings through KDE Control Center as suggested in bug #200061.
Created attachment 140543 [details] xorg.conf The relevant sections of my working xorg.conf.
(In reply to comment #3) Can we get these hints added to the einfo and maybe even turn it into a warning? Also might be worth noting that people have to select "evdev-managed keyboard" in kde and not "Generic 10X keyboard"
*** Bug 206523 has been marked as a duplicate of this bug. ***
I followed te suggestions for evdev in comment #3, but still have a broken keyboard. I followed the links in /dev/input/by-id and found my keyboard was event3. Te only thing close to an error I find in Xorg.0.log is [QUOTE](II) Unicomp Endura Keyboard: Unable to grab pEvdev (Device or resource busy). Cowardly refusing to check use as keyboard. (EE) Unicomp Endura Keyboard: Don't know how to use pEvdev. (II) UnloadModule: "evdev" (EE) PreInit returned NULL for "Unicomp Endura Keyboard"[/QUOTE] Yet the keyboard works well enough for Alt-F1 to bring up a menu which requires mouse navigation to select Exit FVWM.
I struggled a bit with this one but found out what was going on : Like said before in your xorg.conf be sure to have : Driver "evdev" Option "XkbModel" "evdev" Then, don't forget if you use KDE with Kxkb (the keyboard layout tool in KDE) : Switch your keyboard model to : "Evdev-managed keyboard"
There's one more thing to add. Something I found (and verified) today on the forums. Current (hal-0.5.10) /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi has: <match key="info.capabilities" contains="input.keymap"> <append key="info.callouts.add" type="strlist">hal-setup-keymap</append> </match> But keyboard is created with info.capabilities = { 'input', 'input.keyboard', 'input.keypad', 'input.keys', 'button' } So one more block has to be added to your custom fdi file: <match key="info.capabilities" contains="input.keys"> <append key="info.callouts.add" type="strlist">hal-setup-keymap</append> </match> (at least I think that 'input.keys' is the correct capability to match, it can be one of the others) This is needed if you are NOT using Gnome/KDE/whatever to manage your keyboard, cause otherwise you have to call `setxkbmap` every time you startx even if you've got correct fdi file with your keyboard layout (I'm using ROX-Session and Openbox, but ROX-Session is not setup to override system keyboard settings).
Just in case setting this alone doesn't help (like for me), check if CONFIG_PROTECT=/usr/share/X11/xkb etc-update finds lots of file (>100 for me). Seems that at one point an xkb update was CONFIG_PROTECTed, and another upgrade in the same block removed the protection.
*** Bug 209329 has been marked as a duplicate of this bug. ***
This may help: try to add Option "AutoAddDevices" "False" to your ServerLayout. It fixed my layout, but not my mouse. See http://bugs.gentoo.org/show_bug.cgi?id=200061#c22 Also have a look at bug 204128 and bug 210710
Hi there, I've been fiddling with hal 0.5.10 from time to time now and I want to share this here. Using hal+evdev is not making problems regarding the layout. But my Fn+Fx keys seem to act strangely. First Fn+Fx doesn't pass any event to X (at least nothing is shown in xev). My Fn+Arrows are multimedia keys and they seem to work just fine. Even the Fn+{End/Pos1} (german keyboard) let me adjust the brightness automagically (I always thought the nvidia driver would prevent that). Brightness control doesn't show up in xev either though. So my thought is that acpi events are "swallowed" by hal. Is there any hal guru around here that can give me any hints why ie Fn+F4(suspend) doesn't suspend but does show up in /var/log/messages as unhandled acpi event? Can I somehow monitor hal's actions? I know about lshal -m but it just sits there returning nothing no matter what Fn keycombo I try. I have been googling for hours now and the only things I can find are similar reports resulting in a suggestion to downgrade hal... but I'd like to help fix that and just don't know where else to look. Note: I have a thinkpad t61 / xorg+gnome configured to use evdev / with <hal-0.5.10 I can suspend using Fn+F4 and lock the screen using Fn+F2 etc
I came here from bug: 209329 Normally in X I don't have issues. The issues occur when running vmware-workstation or vmware-server-console. There the arrow keys don't work (arrow down actually pops up the start menu in windows guests) as well as several others like delete. In the original bug the reporter is using evdev. The reply is you can't configure your keyboard like that and then it's duplicated to this bug. This bug tells me to use evdev. That actually gave me several issues in several setups. Including my X which never had issues. In the end I deleted my xorg.conf and ran X --configure. Got more or less the same config back (video setup differs probably because of newer intel drivers). Keyboard works fine again in X. Still has same issues in vmware.
Created attachment 146475 [details] emerge.info
Created attachment 146476 [details] xorg.conf
So, for those who care. evdev uses a slightly different key mapping than regular xf86 does, for whatever reasons. Here are some: in /usr/share/X11/xkb/keycodes/evdev (output cut from xev): state 0x0, keycode 110 (keysym 0xff50, Home), same_screen YES, state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES, state 0x0, keycode 112 (keysym 0xff55, Prior), same_screen YES, state 0x0, keycode 113 (keysym 0xff51, Left), same_screen YES, state 0x0, keycode 114 (keysym 0xff53, Right), same_screen YES, state 0x0, keycode 115 (keysym 0xff57, End), same_screen YES, state 0x0, keycode 116 (keysym 0xff54, Down), same_screen YES, state 0x0, keycode 117 (keysym 0xff56, Next), same_screen YES, state 0x0, keycode 118 (keysym 0xff63, Insert), same_screen YES, state 0x0, keycode 119 (keysym 0xffff, Delete), same_screen YES, in /usr/share/X11/xkb/keycodes/xfree86: state 0x0, keycode 97 (keysym 0xff50, Home), same_screen YES, state 0x0, keycode 98 (keysym 0xff52, Up), same_screen YES, state 0x0, keycode 99 (keysym 0xff55, Prior), same_screen YES, state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES, state 0x0, keycode 102 (keysym 0xff53, Right), same_screen YES, state 0x0, keycode 103 (keysym 0xff57, End), same_screen YES, state 0x0, keycode 104 (keysym 0xff54, Down), same_screen YES, state 0x0, keycode 105 (keysym 0xff56, Next), same_screen YES, state 0x0, keycode 106 (keysym 0xff63, Insert), same_screen YES, state 0x0, keycode 107 (keysym 0xffff, Delete), same_screen YES, Looks to me like vmware doesn't like that, and has the xfree86 keycodes (rather than keysyms) hardcoded. I don't know where all the translations happen, that's just where I am stuck in my migration.
(In reply to comment #17) > Looks to me like vmware doesn't like that, and has the xfree86 keycodes (rather > than keysyms) hardcoded. I don't know where all the translations happen, that's > just where I am stuck in my migration. > VMWare keyboard issues could be manually solved by remapping the problem keys in /etc/vmware/config. xkeymap.usekeycodeMap=true xkeymap.keycode.111=0x148 xkeymap.keycode.113=0x14b xkeymap.keycode.114=0x14d xkeymap.keycode.116=0x150 xkeymap.keycode.133=0x15b
(In reply to comment #18) link to the article i've used http://www.vmware.com/support/ws55/doc/ws_devices_keymap_linux_longer.html
(In reply to comment #19) > (In reply to comment #18) > link to the article i've used > http://www.vmware.com/support/ws55/doc/ws_devices_keymap_linux_longer.html > I had to use the following to get most of my keys (like Del, PageUp/Down etc.) working. xkeymap.usekeycodeMap=true xkeymap.keycode.112=0x149 xkeymap.keycode.117=0x151 xkeymap.keycode.118=0x152 xkeymap.keycode.119=0x153 xkeymap.keycode.111=0x148 xkeymap.keycode.113=0x14b xkeymap.keycode.114=0x14d xkeymap.keycode.116=0x150 xkeymap.keycode.133=0x15b
*** Bug 228645 has been marked as a duplicate of this bug. ***
Ok, since a real solution doesn't seem to have been proposed here so far, I ask at least for what I tried to describe in a different bug report (#228645): Add an einfo message about the changed keycodes to the repsective ebuilds. For a list of all the differences, look at the changes with: diff -yw /usr/share/X11/xkb/keycodes/evdev /usr/share/X11/xkb/keycodes/xfree86 | less
None of the proposed solutions work here. It appears very fickle, as between one boot and the next, I lost my Up and Page-Down keys (and only those) when they were working before. I did not modify any configuration files or upgrade any packages in that time. my xkb model is evdev, I am using evdev as a driver, and I don't even have a keyboard device in xorg.conf, to allow it to configure itself. It worked perfectly fine. My xkb map is us, as it should be.
This particular list works for me: xkeymap.keycode.108 = 0x138 # Alt_R xkeymap.keycode.106 = 0x135 # KP_Divide xkeymap.keycode.104 = 0x11c # KP_Enter xkeymap.keycode.111 = 0x148 # Up xkeymap.keycode.116 = 0x150 # Down xkeymap.keycode.113 = 0x14b # Left xkeymap.keycode.114 = 0x14d # Right xkeymap.keycode.105 = 0x11d # Control_R xkeymap.keycode.118 = 0x152 # Insert xkeymap.keycode.119 = 0x153 # Delete xkeymap.keycode.110 = 0x147 # Home xkeymap.keycode.115 = 0x14f # End xkeymap.keycode.112 = 0x149 # Prior xkeymap.keycode.117 = 0x151 # Next xkeymap.keycode.78 = 0x46 # Scroll_Lock xkeymap.keycode.127 = 0x100 # Pause xkeymap.keycode.133 = 0x15b # Meta_L xkeymap.keycode.134 = 0x15c # Meta_R xkeymap.keycode.135 = 0x15d # Menu
(In reply to comment #23) > None of the proposed solutions work here. It appears very fickle, as between > one boot and the next, I lost my Up and Page-Down keys (and only those) when > they were working before. I did not modify any configuration files or upgrade > any packages in that time. > my xkb model is evdev, I am using evdev as a driver, and I don't even have a > keyboard device in xorg.conf, to allow it to configure itself. It worked > perfectly fine. > My xkb map is us, as it should be. > Hi! I did have a similar problem. My keyboard is a spanish kb. Using setxkbmap I could set the right layout using evdev. But I did lost my '<' and '>' keys. With 'xev' I found that the keycode for '<' and '>' key is "94". Then I add to my .xinitrc file 2 lines: setxkbmap -rules xorg -model evdev -layout latam xmodmap -e 'keycode 94 = less greater' Now my keyboard works fine. I hope this help you. Sorry by my english :-)
this bug hasn't been updated in a few months, please provide an update so we know if people are still experiencing these issues with hal-0.5.13 and evdev-2.2.2/xorg-server-1.6
(In reply to comment #26) > this bug hasn't been updated in a few months, please provide an update so we > know if people are still experiencing these issues with hal-0.5.13 and > evdev-2.2.2/xorg-server-1.6 > seems to be fixed now. just closing it ...
