x11-drivers/xf86-input-evdev-1.2.0 keyboard problem

[golding]

Q? Why do we have this HAL?

Wouldn't it have been better/easier to use the full capabilities of UDEV/Dbus?

[appofice]

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

[Xake]

Q? Why do we have this HAL?

Wouldn't it have been better/easier to use the full capabilities of UDEV/Dbus?

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...

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

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.

Maybe it is time to make a wiki-entry with a "HOWTO Configure HOTPLUG" and a "Common keyboard problems"?
I suck at makeing wiki-pages but if someone else make one I can help review.

[clytle374]

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.

I have in /etc/hal/fdi/policy/10-keymap.fdi

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>

In /etc/X11/xorg.conf

Code: Select all

Section "InputDevice"
  Identifier  "Default Keyboard"
  Driver      "evdev"
  Option      "XkbRules" "xorg"
  Option            "XkbModel" "evdev"
  Option            "XkbLayout" "us"
EndSection

Again it is only mis configured the first login.
Ideas?

[Xake]

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.

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.

And as said before this is NOT a HAL/DBUS fault. I had it long time before hotplugging when I tried to migrate from kbd/mouse to evdev.

[Aysen]

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.

Have you found a solution for that? I'm experiencing exactly the same thing and it's becoming quite frustrating...

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?

Oh, and for the record - if you use hal+evdev, setup an fdi file with an appropriate keymap and let xorg do the hotplugging, you can get rid of all Input sections in xorg.conf completely and remove all those devices from ServerLayout. As Xake said, they are deprecated in such a situation and could only cause problems (for me they introduced some weird keymapping problems; as it turned out from the log file, xorg was seeing each device twice - once it read settings from xorg.conf and the second time it got settings from hal; the effect was a rather unusable keyboard - e.g. CTRL key randomly stopped working).

[Xake]

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.

Have you found a solution for that? I'm experiencing exactly the same thing and it's becoming quite frustrating...

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?

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.

This means the toolkit got NOTHING to do with the layout.
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.
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.

[Aysen]

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.

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.

This means the toolkit got NOTHING to do with the layout.

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).

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.

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.

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.

I'll try that as soon as I get to my machine again.

[renrutal]

My earlier post is old news, like the Guru said please don't mask stuff, use

Option "AutoAddDevices" "false"

in ServerLayout in your xorg.cong.

[mooninite]

Hi all,

Fedora user here. (*dodges rocks*)

I switched from "kbd" to "evdev" for my keyboard so I would be ready for the next release, and I, too, ran into VMWare keyboard issues.

Hal 0.5.10
X.org 7.2
XFCE 4.4.2
VMWare Player 2.0.2

I setup a Samba server as a Domain Controller and use a Windows 2000 VM on it as a Domain Workstation. This causes Windows to force the "CTRL+ALT+DEL" requirement to login. After switching to evdev, VMWare wouldn't read my DELETE key. To put it lightly, I was upset that I couldn't login to my VM. I ending up finding that it was mapped to the PRINT SCREEN key. Go figure. Oh, and yes the cursor keys are all messed up. The down arrow is the SUPER key.

Why is VMWare reading the keyboard mapping differently than every other application?

Is this a VMWare bug or something I can take up with Red Hat?

P.S. That Gentoo maintainers blog doesn't make me feel good about HAL.

P.P.S. The xorg.conf settings do nothing for mapping. The defaults are already "evdev" and "xorg" so there's nothing to set.

[kknm_fixxxer]

HAI GUIZE

Ok, so I managed to get the keyboard working, and it actually wasn't that hard. Plus, I must be the lucky one, because there were like a hundred methods to get it working as far as the keymap was concerned (evdev, hal, no hal, partly hal, partly xorg.conf, you name it).

However, I still have one problem that I don't really know how to tackle.

I decided to go the pure HAL route, ie get rid of all the keyboard- and mouse-related settings from my xorg.conf and set everything up with HAL's .fdi file. It's all fine and dandy, but after I suspend-to-RAM and go out of suspend, I loose my "swap ctrl and capslock" setting.

Does anyone has an idea what might be causing this? The keymap survives suspending, just not this additional setting. I'm using GNOME, btw.

Here's my .fdi file:

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>

[ranger719]

I experienced another problem with hal. After upgrading from 0.5.9.1-r3 to 0-5.10 I had to change my keyboard settings, too (in the kdecontrol-panel, commenting all keyboard/mouse devices in my xorg.conf and changing my default-keyboard-layout in the .fdi-file). This worked fine, but after switching to vtX via alt+ctrl+fX from KDE and switching back to X , X crashes, consuming 100% cpu-time. No graphic is "updated/redrawn", the screen is completely frozen. I am still able to move my mouse, but keyboard-input only works for about 1-2secs after switching back to X. Amarok still plays my music, but only until the track ends. Then it stops, instead of playing the next song. The system is unusabel from local controls. I cannot click anything, change to vtX, move a window and so on. SSHing into it still works, and I can restart XDM. Restarting XDM fixes all the problems, until I change to the console and switch back again. My xorg-log is appended. Any ideas? Reverting hal back to 0.5.9.1-r3 fixes this issue. I know this might not fit in this thread, but its still somehow related

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.

[Ibn al-Hazardous]

I spent the weekend trying to get the pure HAL way going, but X keeps crashing. The backtrace seems to point at evdev (if I interpret it correctly):

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 aborting

I tried hal-0.5.10-r1 from gentopia (which made a nice fdi for my weird keyboard settings), and I tried downgrading dbus - but no go. Is this the kind of bug that should be filed (I failed to find something that looked like this one in bugzilla), or should I fight on with the configuration?

Oh, the hardware is a Macbook from last may, intel945 graphics and a synaptics touchpad.

/Ibn

PS In my old xorg.conf I had the line:

Code: Select all

	Option		"RightAlt"		"RApple"

Is there a way to get this effect in an fdi-file? Swedish keyboards without right alt is a bit painful.

[ranger719]

My machine is an Intel Apple Mac Mini, with this chipset:

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)

Maybe it is hardware-related? My X-Server also crashes, see 2 posts above.

[Ibn al-Hazardous]

My machine is an Intel Apple Mac Mini, with this chipset:

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)

Maybe it is hardware-related? My X-Server also crashes, see 2 posts above.

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 often ).

[doublehp]

What a stupid debate for nothing; read all bugs listed in http://bugs.gentoo.org/show_bug.cgi?id=210710 . There are bugs, so, apply proposed fixes, or downgrade to X-1.3 .

[roginovicci]

This thread is much of interest. Many thanks to all participants. It is looks like hal is really works and some utils helps to write your own configs in /etc/hal/... I have one question left. Well I was running Xorg 7.1 till now since I was afraid evdev changes a mach, and this is the case Actually I am using multy seat configuration - double set of mice keyboard videocards and monitors. Thus I have two working place with one computer. evdev helped me to split keyboards and mice. Thus I could run two X servers at the time with separate set of input devices. Now I cant figure out how to perfome that split. What option should I use to the X server use only one set of input devices and wouldn't react on actions with other set of input devices. Any help are welcome.

[Rion]

VMWARE

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.

so i think its entirely vmware bug or maybe some settings needed

UPDATE:
i've fixed cursor problem by making ~/.vmware/config with content

xkeymap.keycode.116 = 0x050
xkeymap.keycode.113 = 0x04b
xkeymap.keycode.114 = 0x04d
xkeymap.keycode.111 = 0x048

but many other keys are still mapped wrong.
i'll investigate it a bit more..

UPDATE:
seems putting to this file

Code: Select all

xkeymap.nokeycodeMap = true

instead of lines above works good. (almost all keys for me)
but vmware team doesn't recommend it. (see documentation for more info)

[lalebarde]

doublehp : it is not that simple. I am under x11-base/xorg-server 1.3.0.0-r5 and have big problems - cf http://forums.gentoo.org/viewtopic-p-49 ... ml#4908137.
From what I have read in this thread, every people don't have the same problem. For my concern, I am on arch, and not on tild-arch.

Code: 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

EDIT 29/02/2008 : Solved for me by reemerging xf86-input-mouse xorg-server (cf the other thread I point to for details).

[mooninite]

VMWARE

UPDATE:
seems putting to this file

Code: Select all

xkeymap.nokeycodeMap = true

instead of lines above works good. (almost all keys for me)
but vmware team doesn't recommend it. (see documentation for more info)

That works for me, too. Thanks!

For VMWare Player, the file is in ~/.vmware/preferences instead of ~/.vmware/config.

[VinnieNZ]

seems putting to this file

Code: Select all

xkeymap.nokeycodeMap = true

instead of lines above works good. (almost all keys for me)
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.

The only info I can find from VMWare is in the Manuals where it mentions it, but doesn't really explain why its not recommended.

Thanks

[kwisatz_haderais]

Now, the only question that remains is:
Is it really easier to edit your /etc/hal/fdi/policy/xyz xml file than configuring xorg.conf, as it used to be?

[Aysen]

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.

For me this bug is present even if I launch VMware from pure clean X session, so it has to be a VMware bug.

seems putting to this file

Code: Select all

xkeymap.nokeycodeMap = true

instead of lines above works good. (almost all keys for me)
but vmware team doesn't recommend it. (see documentation for more info)

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.

[simoo]

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.

Thank you SO much! my arrow keys stopped working and I was completely stumped until I read this

[irasnyd]

Has anyone gotten multiple keyboard layouts working at the same time?

Here is what I had in xorg.conf before I upgraded hal / xorg / evdev to ~x86 latest:

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

This made the X server start up with the dvorak layout, but switch to qwerty when I pressed the menu key. Also, it used the right windows key to give me things like accents and umlauts.

I upgraded hal / xorg / and evdev a while back. I removed all keyboard related config from /etc/X11/xorg.conf. I reset everything to their defaults in GNOME, then tried to switch to dvorak. No luck, it stays qwerty, and I get the nasty gnome-screenshot with the up arrow. I DID set the keyboard to "evdev managed".

I was able to get dvorak by running "setxkbmap -layout dvorak -model evdev -verbose". I can't get the nice toggle between qwerty working, though.

I tried putting all of the above in the /etc/hal/fdi/policy/10-keymap.fdi file, by editing the one from /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi and adding <merge key=input.xkb.layout" type="string">dvorak,us</merge>. Maybe I did it wrong, but I could not get it to work.

Does anyone have any ideas how to get a setup like this working?

Thanks.