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

Message

Da_G · Post by **Da_G** » Wed Oct 08, 2008 7:25 am

To expand on my previous post re: gdm causing the keyboard to function correctly:

When auto-login is turned on in gdm, the keyboard will not function properly.

When you manually login with gdm, the keyboard will function properly.

I read in another forum that kdm causes similar behavior.

So in the process of gdm/kdm loading, and preparing to accept user input, they must be kicking in some option that 'fixes' the issue.. that should at least provide some direction to discovering the root of this interesting little glitch

gdm is probably changing the keymaps or somesuch, as I notice an entirely different set of events tied to the keycodes being reported by xev when i've logged in with gdm - most of the 'extended' keys on my keyboard will report named events when the up arrow is not working, when the up arrow is working, all extended keys on my keyboard report keycode xxx (keysym 0x0, NoSymbol), where NoSymbol appears instead of a named event like XF86Send, XF86Calculator, etc.

So for me, startx = borked up arrow, properly reporting extended keys
gdm + autologin = borked keyboard, properly reporting extended keys
modifying the HAL policies = no change
gdm + manual login = up arrow works great, but extended keys do not have named events mapped to them

Smart1 · Post by **Smart1** » Wed Oct 08, 2008 10:22 pm

@Xake

With x11-base/xorg-server-1.4.2 I have Keyboard Problems.

I have installed xorg-serve-1.5.1 without "hal" useflags, but have still Problems

Should I do report to https://bugs.freedesktop.org/

Xake · Post by **Xake** » Thu Oct 09, 2008 7:37 am

Smart1 wrote:@Xake

With x11-base/xorg-server-1.4.2 I have Keyboard Problems.

I have installed xorg-serve-1.5.1 without "hal" useflags, but have still Problems

Should I do report to https://bugs.freedesktop.org/

Using hal useflags, did bringing up a clean X with an xterm work?

Removing the files containing xorg-x11 related stuff from /etc/hal/fdi/policy did not help (and remove old left-behind files from that directory if there are any) did not help you bring up a english keyboard that does not hang?
Is there anything logged to dmesg when the keyboard dies?
Anything in the Xorg.0.log when the keyboard hangs?

I think you should start at bugs.gentoo.org with xf86-input-evdev and xorg-server compiled with USE="hal", attach the above mentioned information along with your xorg.conf, emerge --info and the version of xf86-input-evdev, xorg-server, dbus and hal.
After that post a link to the bug here, so we can have a look. It is possible this is something the gentoo-devs does know about or could help with. If not, then they will tell you what to do.

dpetka2001 · Post by **dpetka2001** » Thu Oct 16, 2008 10:18 am

hi there just upgraded to sys-apps/hal-0.5.11-r1,x11-drivers/xf86-input-evdev-2.0.6, x11-drivers/xf86-input-keyboard-1.3.1,x11-drivers/xf86-input-mouse-1.3.0 and x11-base/xorg-server-1.5.2 and i have problems switching layouts between us and greek...the thing is that only the keyboard shortcut doesn't work...if i click with my mouse over the flag icon in tray it switches between the 2 languages...the corresponding section in xorg.conf looks like following

Code: Select all

Section "InputDevice"

    Identifier  "Keyboard1"
    Driver      "evdev"
    Option "CoreKeyboard"
    Option "AutoRepeat"  "500 30"
    Option "XkbRules"    "xorg"
    Option "XkbModel"    "evdev"
    Option "XkbLayout"   "us,gr"
    Option "XkbVariant"  "extended"
    Option "XkbOptions" "grp:alt_shift_toggle,grp_led:scroll"

and 'cat /var/log/Xorg.0.log|grep EE' shows following

Code: Select all

(EE) MX1000: No device specified.
(EE) PreInit returned NULL for "MX1000"
(EE) Keyboard1: No device specified.
(EE) PreInit returned NULL for "Keyboard1"

any help on how to correct the problem and any opinions on how much bothering those errors are? thanks in advance...

Geralt · Post by **Geralt** » Sun Oct 26, 2008 2:25 pm

My fingerprint reader is no longer working as it used to. After swiping my finger I have to wait a bit and then press enter. I've read on page 1 that somebody else has the same issue, but is there a workaround for this?

dmpogo · Post by **dmpogo** » Sun Oct 26, 2008 5:09 pm

Lepaca Kliffoth wrote:
didumos wrote:xf86-input-evdev-1.2.0 apparently needs a different X configuration than previous versions if you don't want to use the HAL backend - what fixed it it for me was adding a "Device" option, like so
Elaborate on "if you don't want to use the HAL backend".

I, for example, run strictly USE='-hal' system, there is no trace of hal on it.

hoputa · Post by **hoputa** » Tue Oct 28, 2008 5:57 pm

Da_G wrote:To expand on my previous post re: gdm causing the keyboard to function correctly:

When auto-login is turned on in gdm, the keyboard will not function properly.

When you manually login with gdm, the keyboard will function properly.

I read in another forum that kdm causes similar behavior.

So in the process of gdm/kdm loading, and preparing to accept user input, they must be kicking in some option that 'fixes' the issue.. that should at least provide some direction to discovering the root of this interesting little glitch

gdm is probably changing the keymaps or somesuch, as I notice an entirely different set of events tied to the keycodes being reported by xev when i've logged in with gdm - most of the 'extended' keys on my keyboard will report named events when the up arrow is not working, when the up arrow is working, all extended keys on my keyboard report keycode xxx (keysym 0x0, NoSymbol), where NoSymbol appears instead of a named event like XF86Send, XF86Calculator, etc.

So for me, startx = borked up arrow, properly reporting extended keys
gdm + autologin = borked keyboard, properly reporting extended keys
modifying the HAL policies = no change
gdm + manual login = up arrow works great, but extended keys do not have named events mapped to them

I'm having this exact issue. It may have something to do with this:
https://bugs.freedesktop.org/show_bug.cgi?id=16364

EDIT: I confirm that the patch on xorg-server suggested in comment 12 of the bug report fixes the issue for me.

dmpogo · Post by **dmpogo** » Tue Oct 28, 2008 7:35 pm

hoputa wrote:
Da_G wrote:To expand on my previous post re: gdm causing the keyboard to function correctly:

When auto-login is turned on in gdm, the keyboard will not function properly.

When you manually login with gdm, the keyboard will function properly.

I read in another forum that kdm causes similar behavior.

So in the process of gdm/kdm loading, and preparing to accept user input, they must be kicking in some option that 'fixes' the issue.. that should at least provide some direction to discovering the root of this interesting little glitch

gdm is probably changing the keymaps or somesuch, as I notice an entirely different set of events tied to the keycodes being reported by xev when i've logged in with gdm - most of the 'extended' keys on my keyboard will report named events when the up arrow is not working, when the up arrow is working, all extended keys on my keyboard report keycode xxx (keysym 0x0, NoSymbol), where NoSymbol appears instead of a named event like XF86Send, XF86Calculator, etc.

So for me, startx = borked up arrow, properly reporting extended keys
gdm + autologin = borked keyboard, properly reporting extended keys
modifying the HAL policies = no change
gdm + manual login = up arrow works great, but extended keys do not have named events mapped to them
I'm having this exact issue. It may have something to do with this:
https://bugs.freedesktop.org/show_bug.cgi?id=16364

well, kde and gnome has their own keyboard model/layout setups which overwrite the default (i.e xorg.conf or hal) if enabled.

Xake · Post by **Xake** » Wed Oct 29, 2008 7:33 am

dmpogo wrote:well, kde and gnome has their own keyboard model/layout setups which overwrite the default (i.e xorg.conf or hal) if enabled.

Or if you are unlucky fights against each other leaving you with a dead keyboard...

dmpogo · Post by **dmpogo** » Wed Oct 29, 2008 12:51 pm

Xake wrote:
dmpogo wrote:well, kde and gnome has their own keyboard model/layout setups which overwrite the default (i.e xorg.conf or hal) if enabled.
Or if you are unlucky fights against each other leaving you with a dead keyboard...

I was never able to make kde switch layouts with key combinations. Used to work > 2 years ago, but not since.
Whether they are set up in xorg.conf and xkb options are disabled in kde, or kde "xkb options" are enabled,
or even I ran manually setxkbmap under KDE - as long as layouts are enabled in KDE, switching works only through their icon.

At the end I just set it all up in xorg.conf, disabled KDE layouts and am happy every since

guitoo · Post by **guitoo** » Fri Oct 31, 2008 3:06 pm

Finally evdev working fine here.
Replacing the model in gnome keyboard settings by generic / evdev-managed keyboard did the trick.
This evdev driver gave me headache, but now my g15 works flawlessly. i delete every xmodmap file i ever created and remove the usual ZAxisMapping and ButtonMapping lines in xorg.conf that was required to make use of the mouse wheel with the older driver.

So my xorg.conf looks like this

Code: Select all

Section "InputDevice"
    Identifier     "Mouse0"
    Driver         "evdev"
    Option         "Protocol" "auto"
EndSection

Section "InputDevice"
    Identifier      "Keyboard0"
    Option          "Device" "/dev/input/by-id/usb-Logitech_Logitech_Gaming_Keyboard-event-kbd"
    Driver	       "evdev"
    Option          "XkbModel"              "evdev"
    Option          "XkbLayout"             "fr"
EndSection