Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 200060 - After upgrading to sys-apps/hal-0.5.10 some keys don't work anymore properly
Summary: After upgrading to sys-apps/hal-0.5.10 some keys don't work anymore properly
Status: VERIFIED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: High normal with 1 vote (vote)
Assignee: Freedesktop bugs
URL:
Whiteboard:
Keywords:
: 206523 209329 228645 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-11-23 09:27 UTC by michel
Modified: 2009-12-31 15:44 UTC (History)
24 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
xorg.conf (xorg.conf,3.53 KB, text/plain)
2008-01-09 12:40 UTC, Davide Pesavento
Details
emerge.info (freaky-emerge.info,3.45 KB, text/plain)
2008-03-18 12:55 UTC, Ferry
Details
xorg.conf (freaky-xorg.conf,2.49 KB, text/plain)
2008-03-18 12:55 UTC, Ferry
Details

Note You need to log in before you can comment on or make changes to this bug.
Description michel 2007-11-23 09:27:30 UTC
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
Comment 1 Andrey Melentyev 2007-11-23 10:10:18 UTC
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).
Comment 2 Doug Goldstein (RETIRED) gentoo-dev 2007-11-28 01:01:11 UTC
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.
Comment 3 Davide Pesavento gentoo-dev 2008-01-09 12:27:56 UTC
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.
Comment 4 Davide Pesavento gentoo-dev 2008-01-09 12:40:48 UTC
Created attachment 140543 [details]
xorg.conf

The relevant sections of my working xorg.conf.
Comment 5 Markus Ullmann (RETIRED) gentoo-dev 2008-01-11 13:43:07 UTC
(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"
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2008-01-18 14:35:16 UTC
*** Bug 206523 has been marked as a duplicate of this bug. ***
Comment 7 Felix Finch 2008-01-18 19:50:50 UTC
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.
Comment 8 Guillaume BINET 2008-01-21 09:30:25 UTC
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"

Comment 9 Rafał Mużyło 2008-01-25 12:09:23 UTC
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).
Comment 10 Christian Schmidt 2008-01-28 17:45:27 UTC
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.
Comment 11 Jakub Moc (RETIRED) gentoo-dev 2008-02-08 15:08:44 UTC
*** Bug 209329 has been marked as a duplicate of this bug. ***
Comment 12 DEMAINE Benoît-Pierre, aka DoubleHP 2008-02-20 18:10:17 UTC
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
Comment 13 Martin Schanzenbach 2008-02-28 13:39:08 UTC
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
Comment 14 Ferry 2008-03-18 12:54:33 UTC
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.

Comment 15 Ferry 2008-03-18 12:55:09 UTC
Created attachment 146475 [details]
emerge.info
Comment 16 Ferry 2008-03-18 12:55:38 UTC
Created attachment 146476 [details]
xorg.conf
Comment 17 Christian Schmidt 2008-03-18 14:42:52 UTC
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.
Comment 18 A Sotirov 2008-03-27 14:27:28 UTC
(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

Comment 19 A Sotirov 2008-03-27 14:29:30 UTC
(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
Comment 20 devsk 2008-06-04 04:00:10 UTC
(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
Comment 21 Carsten Lohrke (RETIRED) gentoo-dev 2008-06-20 23:50:42 UTC
*** Bug 228645 has been marked as a duplicate of this bug. ***
Comment 22 quazgar 2008-06-21 13:58:34 UTC
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

Comment 23 Dustin Howett 2008-07-12 01:48:36 UTC
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.
Comment 24 Lubos Dolezel 2009-01-27 15:18:14 UTC
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
Comment 25 Ignacio 2009-02-05 21:51:57 UTC
(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 :-)
Comment 26 Gilles Dartiguelongue gentoo-dev 2009-07-28 22:54:26 UTC
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
Comment 27 michel 2009-07-28 23:01:22 UTC
(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 ...