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

Message

mathfeel · Post by **mathfeel** » Fri Jan 11, 2008 1:04 am

I just realized that besides the few (EE) appearing in my Xorg.0.log there is actually nothing much wrong with my keyboard and mouse. Here are my installed hal and evdev:

Code: Select all

 Calculating dependencies... done!
[ebuild   R   ] x11-drivers/xf86-input-evdev-1.2.0  USE="-debug" 0 kB 
[ebuild   R   ] sys-apps/hal-0.5.10  USE="acpi crypt laptop -apm -debug -dell -disk-partition -doc (-selinux)" 0 kB 
[ebuild   R   ] app-misc/hal-info-20071030  0 kB

So, what are people's symptoms? No keyboard or mouse at all? Or some odd behavior??

Gergan Penkov · Post by **Gergan Penkov** » Fri Jan 11, 2008 1:16 am

My mouse was able to move only up and down.
xinput list showed 6 devices and my mouse was recognized as a keyboard as far as I can tel from xinput's output.

devsk · Post by **devsk** » Fri Jan 11, 2008 2:23 am

What are the folks who are not using HALD doing to fix problems with evdev?

EzInKy · Post by **EzInKy** » Fri Jan 11, 2008 3:52 am

mathfeel wrote: So, what are people's symptoms? No keyboard or mouse at all? Or some odd behavior??

I had my logitech expert mouse set to scroll with button eight and the ball because the ring quit working but that was minor compared to what happened to my keyboard. Most of my cymotion linux keys were being interpreted wrong and some even caused actions that were assigned to different combinations.

keenblade · Post by **keenblade** » Fri Jan 11, 2008 6:13 am

devsk wrote:What are the folks who are not using HALD doing to fix problems with evdev?

As didumos stated,
the only way to get the evdev driver working without a HAL-based xserver is stating the device node that the driver should use in xorg.conf. Like this:

Code: Select all

Section "InputDevice"
        Identifier      "Mouse1"
        Driver          "evdev"
        Option          "Device"        "/dev/input/event0"
        Option          "evBits"        "+1-2"
        Option          "keyBits"       "~272-287"
        Option          "relBits"       "~0-2 ~6 ~8"
EndSection

Section "InputDevice"
        Identifier      "Keyboard1"
        Driver          "evdev"
        Option          "Device"        "/dev/input/event1"
        Option          "evBits"        "+1"
        Option          "keyBits"       "~1-255 ~352-511"
        Option          "XkbLayout"     "gb"
EndSection

Also what I understand from didumos is;
The code that scans the devices on the system (i.e. /dev/input/event*) to figure out which one to use within evdev driver is removed, so that the driver could use the new HAL-based input device detection in the 1.4 xserver. And since the upstream did not explain how to configure xorg.conf for the new behavior yet, adding device node is required for me even with using hal.

Edit :
Before I read the following blog entries from hal maintainer of gentoo, I was thinking it is a crazy thing to go without hal. Now I think I can live without it. An open source project must be open source:
HAL 0.5.10 and Things TODO before hitting the tree
No longer maintaining Gentoo’s HAL

LqR · Post by **LqR** » Fri Jan 11, 2008 10:52 am

As far as I've understood the situation, what's happened is that with hal-0.5.10, xf86-input-evdev-1.2.0 and xorg server 1.4 built with the hal USE flag, xorg will ignore your keyboard configuration in the xorg.conf and use HAL to deal with your keyboard in stead (at least commenting/uncommenting my keyboard configuration does nothing). I read about it in a post titled "How to keep your keyboard layout with HAL 0.5.10 / Xorg server 1.4 / evdev input driver" on Planet Gentoo, but it seems to be mysteriously vanished now.

Anyway, what I did (and what that post among other things suggested) was copying /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi to /etc/hal/fdi/policy/10-keymap.fdi and edit it to the following:

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">xorg</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">se</merge>
      <merge key="input.xkb.variant" type="string" />
    </match>
  </device>
</deviceinfo>

Which worked, but some of my keys (home, for example) wouldn't work until i removed xmodmap -e "keycode 115 = F20" from my .xinitrc. It seems everything will become b0rked if you use xmodmap or similar. Note that you'll have to restart hald (and have it started!) or changes won't have any effect.

Of course, everything can be quickly fixed by adding

Code: Select all

>=sys-apps/hal-0.5.10
>=x11-drivers/xf86-input-evdev-1.2.0
>=app-misc/hal-info-20071011

to your package.mask or possibly by not using the hal USE flag when building xorg.

Genetic · Post by **Genetic** » Fri Jan 11, 2008 11:55 pm

Hi,

I'm also experiencing problems with a German notebook keyboard. Using

Code: Select all

Driver "evdev"
Option "Device" "/dev/input/event4"
Option "XkbLayout" "de"

makes X use a German keymap, but it does not recognize all buttons. In my old config, I had activated the "pc105" model, how do I do this with evdev?

//Genetic

devsk · Post by **devsk** » Sat Jan 12, 2008 12:08 am

Code: Select all

>=sys-apps/hal-0.5.10
>=x11-drivers/xf86-input-evdev-1.2.0
>=app-misc/hal-info-20071011

Is what I had to do to get my mouse working properly again. HAL is not an option for me because I think it is just cr*@. You run it and many things like suspend/resume will just break.

keenblade · Post by **keenblade** » Sat Jan 12, 2008 2:06 am

Genetic wrote:Hi,

I'm also experiencing problems with a German notebook keyboard. Using
Code: Select all
Driver "evdev"
Option "Device" "/dev/input/event4"
Option "XkbLayout" "de"
makes X use a German keymap, but it does not recognize all buttons. In my old config, I had activated the "pc105" model, how do I do this with evdev?

//Genetic

Does it work:

Code: Select all

setxkbmap -model evdev -layout de -verbose

Did you try to configure keyboard and layout within your DE?

Also try like this:

Code: Select all

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "evdev"
	Option "Device" "/dev/input/event4"
	Option      "CoreKeyboard"
	Option "XkbRules" "xorg"
	Option "XkbModel" "evdev"
	Option "XkbLayout" "de"
EndSection

jespera · Post by **jespera** » Sat Jan 12, 2008 6:54 am

LqR wrote: Anyway, what I did (and what that post among other things suggested) was copying /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi to /etc/hal/fdi/policy/10-keymap.fdi and edit it to the following:

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">xorg</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">se</merge>
      <merge key="input.xkb.variant" type="string" />
    </match>
  </device>
</deviceinfo>

I would just like to take the time to say a very big thank you here. The above solved all my problems with my keyboard worries using hal-0.5.10.

Genetic · Post by **Genetic** » Sat Jan 12, 2008 10:52 am

keenblade wrote: Does it work:
Code: Select all
setxkbmap -model evdev -layout de -verbose
Did you try to configure keyboard and layout within your DE?

I do not have that command, which ebuild installs it?

keenblade wrote:

Code: Select all

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "evdev"
	Option "Device" "/dev/input/event4"
	Option      "CoreKeyboard"
	Option "XkbRules" "xorg"
	Option "XkbModel" "evdev"
	Option "XkbLayout" "de"
EndSection

This is exactly, what the keyboard section in my xorg.conf looks like. It seems that all I need is the new equivalent to

Code: Select all

  Option "XkbModel" "pc105"

(this line does not work).

BTW: I use gnome, maybe gnome overrides some settings? How can I find out whether it's gnome or X that gets the wrong settings?

//Genetic

keenblade · Post by **keenblade** » Sat Jan 12, 2008 1:24 pm

Genetic wrote:
Code: Select all
setxkbmap -model evdev -layout de -verbose
I do not have that command, which ebuild installs it?

x11-apps/setxkbmap is the package. It is from xorg.
I use kde, but I think you can safely use it for your gnome, since it is not a kde program.
If it does not work try what LqR suggests about 10-keymap.fdi file.

Genetic · Post by **Genetic** » Sat Jan 12, 2008 1:47 pm

Code: Select all

> setxkbmap -model evdev -layout de -verbose

Warning! Multiple definitions of keyboard model
         Using command line, ignoring X server
Warning! Multiple definitions of keyboard layout
         Using command line, ignoring X server
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwertz)
types:      complete
compat:     complete
symbols:    pc+de+inet(evdev)+level3(ralt_switch_for_alts_toggle)+group(alts_toggle)
geometry:   pc(pc104)

This is almost correct, but there still are some errors: The up-arrow button takes a screenshot (I do not know how this button is called in English, but it is a special button whose only purpose is to take a screenshot) and f2-f12 print the letters (Q, R, S, s, S, s, ...).

This is my /usr/share/hal/fdi/policy/10osvendor/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>

keenblade · Post by **keenblade** » Sat Jan 12, 2008 2:09 pm

Genetic wrote:... This is my /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi:
Code: Select all
     <merge key="input.xkb.layout" type="string">us</merge>

I think you have to change this line for your locale (de):

Code: Select all

     <merge key="input.xkb.layout" type="string">de</merge>

keenblade · Post by **keenblade** » Sat Jan 12, 2008 2:21 pm

I think the proper way to do it is using your own fdi file. The procedure goes like this (taken from here)

Code: Select all

cp /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi /etc/hal/fdi/policy/
emacs /etc/hal/fdi/policy/10-keymap.fdi

and within emacs or an other editor, change the input.xkb.layout to your favourite layout (de). Restart HAL (your edited copy will take precedence on the default one)

Code: Select all

rm /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi

and restart HAL: this will disable keyboard handling by evdev (until the next HAL update).

slim.one · Post by **slim.one** » Sat Jan 12, 2008 2:24 pm

quake3-mouseinput is fucked up with evdev. according to ttimo this is dga-related, so there is no other solution except from switching back to mouse/kbd drivers (which sucks... for the first time all my keyboard-buttons worked)

keenblade · Post by **keenblade** » Sat Jan 12, 2008 2:32 pm

slim.one wrote:quake3-mouseinput is fucked up with evdev. according to ttimo this is dga-related, so there is no other solution except from switching back to mouse/kbd drivers (which sucks... for the first time all my keyboard-buttons worked)

I don't think kbd driver works right or better than evdev driver at the moment unless you downgrade hal, kbd or evdev driver.

Genetic · Post by **Genetic** » Sat Jan 12, 2008 4:09 pm

Hi keenblade,

still the same problem: some keys are just wrong and I do not know how to pursuade evdev to use the pc105 keyboard type

//Genetic

Genetic · Post by **Genetic** » Sat Jan 12, 2008 7:12 pm

I just "solved" the problem: removing the evdev flag from the INPUT_DEVICES list made evdev superfluous; obviously evdev is not needed by any input device I'm using.

Nevertheless: Thanks for your patience and help, keenblade!

//Genetic

keenblade · Post by **keenblade** » Sat Jan 12, 2008 7:19 pm

Genetic wrote:I just "solved" the problem: removing the evdev flag from the INPUT_DEVICES list made evdev superfluous; obviously evdev is not needed by any input device I'm using.

Nevertheless: Thanks for your patience and help, keenblade!

//Genetic

Glad to hear that you get your keyboard again. Also thanks for your help, too.

slim.one · Post by **slim.one** » Mon Jan 14, 2008 4:10 pm

keenblade wrote:
slim.one wrote:quake3-mouseinput is fucked up with evdev. according to ttimo this is dga-related, so there is no other solution except from switching back to mouse/kbd drivers (which sucks... for the first time all my keyboard-buttons worked)
I don't think kbd driver works right or better than evdev driver at the moment unless you downgrade hal, kbd or evdev driver.

you may think so, no problem

the problem isn't the keyboard but the mouse. it's unusable. the view goes all the way down, which results in you being able only to look to the bottom (not many enemies there)
only solution for me is to unmerge evdev, since i can't force X to use the mousedriver instead of evdev. hal 0.5.10 states no problem.

keenblade · Post by **keenblade** » Mon Jan 14, 2008 5:05 pm

slim.one wrote: ... you may think so, no problem
the problem isn't the keyboard but the mouse. it's unusable. the view goes all the way down, which results in you being able only to look to the bottom (not many enemies there) ...

If you say so, then it is so; since you are experiencing that. I don't have quake-3 at the moment to try. I was just referring that both evdev and kbd drivers have the keyboard layout problem. Because you said that for the first time all your keyboard-buttons worked.
Is your mouse working fine outside quake-3?

trashman · Post by **trashman** » Mon Jan 14, 2008 11:02 pm

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.

ffyring · Post by **ffyring** » Tue Jan 15, 2008 7:22 pm

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

Thanks Trashman! I was going crazy with my keyboard and have tried all permutations of the tips in the thread. After changing to evdev-managed keyboard everything works!

VValdo · Post by **VValdo** » Wed Jan 16, 2008 4:05 am

FWIW-- I don't have a mouse when X11/Gnome starts up.

I unplug/replug and suddenly the arrow moves... haven't yet restarted to see if this is reproducible but definitely was the case the 1st time..

W