
I acctually do not have a clue. I have yet to hear a good explanation. Could be due to implemention-problems and/or the makers of UDEV not want to have to rewrite stuff from scratch every now and then like it seems the current mantainer of HAL likes to do...golding wrote:Q? Why do we have this HAL?
Wouldn't it have been better/easier to use the full capabilities of UDEV/Dbus?
And as you can see this is a problem everyone experience when they change their configuration for Xorg.conf and still have other configurations left in their DE, I have experienced the exact same problem in GNOME.appofice wrote:Now for the the kde problem. Because my configuration work perfectly for gnome and fluxbox but for kde no. The up arrow key take a screen shot of my desktop "ksnapshot". So i did in the kde control "Regional & Accessibility"->"Keyboard Layouts"
Then select "Evdev-managed keyboard" as your keyboard model..
you can see here is like the mandriva ..
http://archives.mandrivalinux.com/cooke ... g00607.php
good luck
Code: Select all
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.keymap">
<append key="info.callouts.add" type="strlist">hal-setup-keymap</append>
</match>
<match key="info.capabilities" contains="input.keys">
<merge key="input.xkb.rules" type="string">base</merge>
<!-- If we're using Linux, we use evdev by default (falling back to
keyboard otherwise). -->
<merge key="input.xkb.model" type="string">keyboard</merge>
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
string="Linux">
<merge key="input.xkb.model" type="string">evdev</merge>
</match>
<merge key="input.xkb.layout" type="string">us</merge>
<merge key="input.xkb.variant" type="string" />
</match>
</device>
</deviceinfo>
Code: Select all
Section "InputDevice"
Identifier "Default Keyboard"
Driver "evdev"
Option "XkbRules" "xorg"
Option "XkbModel" "evdev"
Option "XkbLayout" "us"
EndSection
You have to reset your keyboardsettings in you DE (GNOME, KDE) as they are currently not in par with the ones Xorg tries to use.clytle374 wrote:So I have the up arrow key is screen shot problem, everything else seems to work after following this thread. If I log out and back in it works fine.
Have you found a solution for that? I'm experiencing exactly the same thing and it's becoming quite frustrating...superbrain666 wrote:I fixed the issue with adding the correct HAL informations.
And telling KDE to use this evdev-mapped-keyboard.
BUT: My VM in VMWARE is still broken. This means my windows has problems with the cursor keys.
Very ugly because i use windows only for playing games... so games without cursors are not possible![]()
I think it has something to do with VMWAREs build-in GTK interface or with the GTK on my Gentoo, which is not ready for evdev.
Is it possible I tell VMWARE to use the correct keymap? Maybe in a config?
I've tried to clean out my .gnomeXX and .gconf folders with no change.

The DE's may have problem due to they let the user set which layout they want (for multiuser systems where one user may want the standard us layout, another one wants the dvorak layout). This is something used by gnome-settings-daemon and the one that KDE uses. And at least the gnome-settings-daemon shows a warning about "X keyboard configurations has changed" with two buttons "use X configuration" and "keep gnome-settings". For me things goes south whatever I press here usually, but it is a strong indication that I need to reset my DE's keyboard settings.Aysen wrote:Have you found a solution for that? I'm experiencing exactly the same thing and it's becoming quite frustrating...superbrain666 wrote:BUT: My VM in VMWARE is still broken. This means my windows has problems with the cursor keys.
Very ugly because i use windows only for playing games... so games without cursors are not possible![]()
I think it has something to do with VMWAREs build-in GTK interface or with the GTK on my Gentoo, which is not ready for evdev.
Is it possible I tell VMWARE to use the correct keymap? Maybe in a config?
I've tried to clean out my .gnomeXX and .gconf folders with no change.
I'm running KDE, so I don't have any GNOME tools installed - could someone tell me how to switch GTK+/GNOME apps to use evdev-managed kayboard without installing all the GNOME stuff I don't need?
In KDE there is no such a warning - when KDE starts, it simply uses settings from X, but you can change them in KControl (but this setting is lost on the next login - X settings are applied again). At least that's what happens here.Xake wrote:The DE's may have problem due to they let the user set which layout they want (for multiuser systems where one user may want the standard us layout, another one wants the dvorak layout). This is something used by gnome-settings-daemon and the one that KDE uses. And at least the gnome-settings-daemon shows a warning about "X keyboard configurations has changed" with two buttons "use X configuration" and "keep gnome-settings". For me things goes south whatever I press here usually, but it is a strong indication that I need to reset my DE's keyboard settings.
True, the toolkit does not. The DE does, but only as much that you can change the layout for the current session (at least in KDE).Xake wrote:This means the toolkit got NOTHING to do with the layout.
True. I didn't say anything about porting anything, only about changing my settings for GTK+/GNOME apps. I used to have GNOME installed a few years ago, so I guess it's possible that some settings (eg. keyboard layout I chose back then) got preserved and now they are conflicting with new X/evdev. That's why I asked how to change those settings. However, this is just a wild guess and quite possibly wrong, as VMware is the only app that's giving me troubles, so it might be something specific to VMware configuration. I'm going to dig into this tomorrow, probably. I'll keep you posted.Xake wrote:No porting of any app/toolkit/DE/whatever should be needed to use evdev.
If something does not work it is a strong indication that your settings are wrong.
I'll try that as soon as I get to my machine again.Xake wrote:Have you tried start VMWare from a "failsafe terminal" (nothing from the DE loaded, just the basic stuff to run X-progs)?
For me VMWare works as used to.

Code: Select all
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.keymap">
<append key="info.callouts.add" type="strlist">hal-setup-keymap</append>
</match>
<match key="info.capabilities" contains="input.keys">
<merge key="input.xkb.rules" type="string">base</merge>
<!-- If we're using Linux, we use evdev by default (falling back to
keyboard otherwise). -->
<merge key="input.xkb.model" type="string">keyboard</merge>
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
string="Linux">
<merge key="input.xkb.model" type="string">evdev</merge>
</match>
<merge key="input.xkb.layout" type="string">pl</merge>
<merge key="input.xkb.leftalt" type="string">Meta</merge>
<merge key="input.xkb.options" type="string">ctrl:swapcaps</merge>
<merge key="input.xkb.variant" type="string" />
</match>
</device>
</deviceinfo>
Code: Select all
[...]
(WW) intel(0): fbc already enabled on plane a, not enabling on plane a
(II) HID 05ac:1000: On
(II) HID 05ac:1000: On
(II) Microsoft Microsoft 5-Button Mouse with IntelliEye(TM): On
(II) HID 04d9:1504: On
(II) <default pointer>: ps2EnableDataReporting: succeeded
evdev: leds are 0x0 for device 7
evdev: leds are 0x0 for device 4
evdev: leds are 0x0 for device 7
evdev: leds are 0x0 for device 4
evdev: leds are 0x0 for device 7
evdev: leds are 0x0 for device 4
evdev: leds are 0x1000 for device 7
evdev: leds are 0x1000 for device 4
evdev: leds are 0x1000 for device 7
evdev: leds are 0x1000 for device 4
(II) HID 05ac:1000: Off
(II) HID 05ac:1000: Off
(II) Microsoft Microsoft 5-Button Mouse with IntelliEye(TM): Off
(II) HID 04d9:1504: Off
(II) AIGLX: Suspending AIGLX clients for VT switch
(II) intel(0): fbc disabled on plane a
(II) intel(0): xf86UnbindGARTMemory: unbind key 0
(II) intel(0): xf86UnbindGARTMemory: unbind key 1
(II) intel(0): xf86UnbindGARTMemory: unbind key 2
(II) intel(0): xf86UnbindGARTMemory: unbind key 3
(II) intel(0): xf86UnbindGARTMemory: unbind key 4
(II) Open ACPI successful (/var/run/acpid.socket)
(II) AIGLX: Resuming AIGLX clients after VT switch
(II) intel(0): xf86BindGARTMemory: bind key 0 at 0x01000000 (pgoffset 4096)
(II) intel(0): xf86BindGARTMemory: bind key 1 at 0x02000000 (pgoffset 8192)
(II) intel(0): xf86BindGARTMemory: bind key 2 at 0x05000000 (pgoffset 20480)
(II) intel(0): xf86BindGARTMemory: bind key 3 at 0x06000000 (pgoffset 24576)
(II) intel(0): xf86BindGARTMemory: bind key 4 at 0x07000000 (pgoffset 28672)
(II) intel(0): Fixed memory allocation layout:
(II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB)
(II) intel(0): 0x00020000-0x0061ffff: compressed frame buffer (6144 kB, 0x000000007f020000 physical
)
(II) intel(0): 0x00620000-0x00620fff: compressed ll buffer (4 kB, 0x000000007f620000 physical
)
(II) intel(0): 0x00621000-0x0062afff: HW cursors (40 kB, 0x000000007f621000 physical
)
(II) intel(0): 0x0062b000-0x00632fff: logical 3D context (32 kB)
(II) intel(0): 0x00633000-0x00633fff: overlay registers (4 kB, 0x000000007f633000 physical
)
(II) intel(0): 0x00fbf000: end of stolen memory
(II) intel(0): 0x01000000-0x01ffffff: front buffer (13440 kB) X tiled
(II) intel(0): 0x02000000-0x0475ffff: exa offscreen (40320 kB)
(II) intel(0): 0x05000000-0x05ffffff: back buffer (13440 kB) X tiled
(II) intel(0): 0x06000000-0x06ffffff: depth buffer (13440 kB) X tiled
(II) intel(0): 0x07000000-0x08ffffff: classic textures (32768 kB)
(II) intel(0): 0x10000000: end of aperture
(WW) intel(0): ESR is 0x00000010, page table error
(WW) intel(0): PGTBL_ER is 0x00000010, display A pte
(WW) intel(0): Existing errors found in hardware state.
(II) intel(0): fbc disabled on plane a
(II) intel(0): fbc disabled on plane a
(II) intel(0): fbc disabled on plane a
(II) intel(0): fbc enabled on plane a
(WW) intel(0): fbc already enabled on plane a, not enabling on plane a
(II) intel(0): Output configuration:
(II) intel(0): Pipe A is on
(II) intel(0): Display plane A is now enabled and connected to pipe A.
(II) intel(0): Pipe B is off
(II) intel(0): Display plane B is now disabled and connected to pipe B.
(II) intel(0): Output VGA is connected to pipe none
(II) intel(0): Output TMDS-1 is connected to pipe A
(II) intel(0): Output TV is connected to pipe none
(II) intel(0): [drm] dma control initialized, using IRQ 17
(WW) intel(0): fbc already enabled on plane a, not enabling on plane a
(II) HID 05ac:1000: On
(II) HID 05ac:1000: On
(II) Microsoft Microsoft 5-Button Mouse with IntelliEye(TM): On
(II) HID 04d9:1504: On
(II) <default pointer>: ps2EnableDataReporting: succeeded
tossed event which came in late
tossed event which came in late
tossed event which came in late
tossed event which came in late
MANY OF THE LAST 3 LINES! About 70.
Code: Select all
Backtrace:
0: /usr/bin/X(xf86SigHandler+0x9b) [0x47f99b]
1: /lib/libc.so.6 [0x7fe9fc99f960]
2: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7fe9e3691e63]
3: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7fe9e3692a7a]
4: /usr/lib64/xorg/modules/input//evdev_drv.so(evdevNewDriver+0x38) [0x7fe9e3692b4f]
5: /usr/lib64/xorg/modules/input//evdev_drv.so [0x7fe9e3691a80]
6: /usr/bin/X(NewInputDeviceRequest+0x1ec) [0x470fce]
7: /usr/bin/X [0x45f3a2]
8: /usr/bin/X [0x45f555]
9: /usr/bin/X [0x45e66b]
10: /usr/bin/X [0x52ce74]
11: /usr/bin/X(WaitForSomething+0x524) [0x52d422]
12: /usr/bin/X(Dispatch+0x7e) [0x44aaca]
13: /usr/bin/X(main+0x559) [0x4372d2]
14: /lib/libc.so.6(__libc_start_main+0xf4) [0x7fe9fc98bb74]
15: /usr/bin/X(FontFileCompleteXLFD+0x271) [0x436629]
Fatal server error:
Caught signal 11. Server abortingCode: Select all
Option "RightAlt" "RApple"Code: Select all
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
I have the exact same chipset. The thing is that we get entirely different errors in the log, so I'm not sure it's the same problem. Anyway, I'll make another try in a couple of days (it won't do to break my work computer too oftenranger719 wrote:My machine is an Intel Apple Mac Mini, with this chipset:Maybe it is hardware-related? My X-Server also crashes, see 2 posts above.Code: Select all
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

but many other keys are still mapped wrong.xkeymap.keycode.116 = 0x050
xkeymap.keycode.113 = 0x04b
xkeymap.keycode.114 = 0x04d
xkeymap.keycode.111 = 0x048
Code: Select all
xkeymap.nokeycodeMap = trueCode: Select all
PCTRAVAIL ~ # eix -A sys-apps/hal
[I] sys-apps/hal
Available versions: 0.5.7.1-r5 0.5.9-r1 ~0.5.9.1-r1 ~0.5.9.1-r2 0.5.9.1-r3 ~0.5.10 {acpi apm crypt debug dell disk-partition dmi doc kernel_FreeBSD kernel_linux laptop pcmcia selinux}
Installed versions: 0.5.9.1-r3(20:32:38 25.02.2008)(acpi crypt doc kernel_linux -debug -dell -disk-partition -kernel_FreeBSD -pcmcia -selinux)
Description: Hardware Abstraction Layer
PCTRAVAIL ~ # eix -A x11-drivers/xf86-input-evdev
[I] x11-drivers/xf86-input-evdev
Available versions: 1.1.5-r1 ~1.1.5-r2 ~1.2.0 {debug}
Installed versions: 1.1.5-r1(02:31:29 27.02.2008)(-debug)
Homepage: http://xorg.freedesktop.org/
Description: Generic Linux input driver
PCTRAVAIL ~ # eix -A app-misc/hal-info
[I] app-misc/hal-info
Available versions: 20070425 ~20070516 20070618 ~20071011 ~20071030
Installed versions: 20070618(08:16:08 19.02.2008)
Homepage: http://hal.freedesktop.org/
Description: The fdi scripts that HAL uses
That works for me, too. Thanks!Rion wrote:VMWARE
UPDATE:
seems putting to this fileinstead of lines above works good. (almost all keys for me)Code: Select all
xkeymap.nokeycodeMap = true
but vmware team doesn't recommend it. (see documentation for more info)
Could you place a link to the info that you found that says why this isn't recommended.Rion wrote:seems putting to this fileinstead of lines above works good. (almost all keys for me)Code: Select all
xkeymap.nokeycodeMap = true
but vmware team doesn't recommend it. (see documentation for more info)

For me this bug is present even if I launch VMware from pure clean X session, so it has to be a VMware bug.Rion wrote:just removed all keyboard things from xorg.conf, cleared gconf settings and setted up fdi file as described above.
rebooted and started fluxbox instead of gnome.
after this started vmware.
bug with cursor keys still present (up as print screen, left as alt and so on) and with fluxbox and with gnome.
Thanks! This works pretty well - cursor keys are working again. However, I still can't enter Polish characters (right_alt+{a,z,x,c,e,s,o,l,n}) - but it's a minor annoyance compared to the cursor keys problem.Rion wrote:seems putting to this fileinstead of lines above works good. (almost all keys for me)Code: Select all
xkeymap.nokeycodeMap = true
but vmware team doesn't recommend it. (see documentation for more info)
Thank you SO much! my arrow keys stopped working and I was completely stumped until I read thistrashman wrote:All I had to do to resolve this problem was go to K-Menu > Control Center > Regional & Accessibility > Keyboard Layout. Then, change Keyboard model to Evdev-managed keyboard. After that, my keyboard was immediately restored, without any modification of xorg.conf or x/kde restart.
Code: Select all
Section "InputDevice"
Identifier "Keyboard1"
Driver "kbd"
Option "XkbModel" "microsoftpro"
Option "XkbLayout" "dvorak,us"
Option "XkbOptions" "compose:rwin,grp:menu_toggle,grp_led:scroll"
EndSection