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

Bloodsurfer · Posted: Wed Apr 09, 2008 10:09 am Post subject:

WTF?!? I just figured by chance, that my mouse's side buttons are working in Opera - just not in Firefox, where they were working before

How can that be?
_________________
SiberianSniper: my girlfriend's name ends with .c
Clete2: Uber geek! W00t! I'd rather have it end in .cpp... <insert name>.cpp
Dralnu: ...why not <name>.o? Then she's ready for linking...
SiberianSniper: or <name>.ko, so she's ready for insertion?

aPoX · n00b Joined: 28 Jan 2003 Posts: 10

Xake, this is absolutely related to hal.

I don't have GNOME or KDE installed and I'm having the same keyboard issues. Infact, this is not only related to Gentoo, it's also occuring in Debian/Ubuntu/ArchLinux/Fedora.

Xake · Posted: Mon Apr 14, 2008 7:44 pm Post subject:

[quote="aPoX"]Xake, this is absolutely related to hal.[quote]

Short answer:
The only way this is related to hal is that the place where the settings are stored (i.e. as a .fdi instead of in xorg.conf, just as your example said).

Long answer:
These BETAS of Xorg uses hal to find input devices and query hal for the settings. (Nearly) the only real change.
Where things break:
The BETAS of Xorg+hal uses evdev by default and evdev does not behave in the same way as your old xf86-input-{keyboard,mouse} settings.
Problem is:
Dumb applications and DEs thinks it is funny to store these settings themselves too. But when there is a mismatch between their settings and the underlying (i.e. Xorgs) settings things may break.
But this you would all have known if you had tried to configure your system to only use evdev (i.e. ditch xf86-input-{keyboard,mouse}) long way before the hal+Xorg-loveaffair even was in git.

That said:
Some things may break, but it is more like the newest version of evdev does not like Logitech keyboard, but there are patches for that.

That said no2:
I use vmware and have still to see any problem with that and a clean userprofile. Not then. Not now.
But then I am using vmware-console against a vmware-server and that may be the reason.

hoschi · Posted: Tue Apr 29, 2008 10:52 pm Post subject:

*removed everything from xorg.conf

Xake · Posted: Wed May 07, 2008 5:38 pm Post subject:

hoschi · Posted: Wed May 07, 2008 9:21 pm Post subject:

i removed the howl directory - no change

VoidMage · Watchman Joined: 14 Oct 2006 Posts: 6196

Change:
<match key="info.capabilities" contains="input.keymap">
to:
<match key="info.capabilities" contains="input.keys">

cause that's the correct value for hal 0.5.10

hoschi · Posted: Thu May 08, 2008 11:18 pm Post subject:

Xake · Posted: Fri May 09, 2008 7:36 am Post subject:

VoidMage · Watchman Joined: 14 Oct 2006 Posts: 6196

Do something very simple:
run:
hal-find-by-capability --capability input.keys
for every listed device name run:
hal-device <device name>
Post output here.

Naib · Posted: Fri May 09, 2008 8:47 pm Post subject:

I'm also having the UPARROW mapping to printscreen (gnome-2.22 here)

I have done the: cp /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi /etc/hal/fdi/policy/10-keymap.fdi (and edit for my keymap)
as well as gconftool-2 --recursive-unset /desktop/gnome/peripherals

With no luck (UPARROW still does printscreen)

Naib · Posted: Sat May 10, 2008 11:39 am Post subject:

OK interestingly IF I set gdm to be manual-login then my keyboard works as expectedly
BUT when it is set to autologin then the whole UPARROW mapped to printscreen happens

those that are having the issue do you have you login manager set to auto-login?
_________________

VoidMage · Watchman Joined: 14 Oct 2006 Posts: 6196

I think my question would be valid for you, too (as would be input.keys problem).

Naib · Posted: Sat May 10, 2008 5:45 pm Post subject:

VoidMage · Watchman Joined: 14 Oct 2006 Posts: 6196

Important questions:
your hal/hal-info/xf86-input-evdev version ?
Did you do something strange with your hal, cause I don't think it should add kyboard properties to the keyboard ?
And it's not adding info.callouts.add, so you need that
<match key="info.capabilities" contains="input.keys">
line in the correct place.

Also I think correct place would be /usr/share/hal/fdi/policy/20thirdparty/ (don't know if that's correct, but it works for me, though if
/etc/hal actually work, is OK after all).

Naib · Posted: Sat May 10, 2008 8:02 pm Post subject:

VoidMage · Watchman Joined: 14 Oct 2006 Posts: 6196

First of all, I'll repeat:
CHANGE
<match key="info.capabilities" contains="input.keymap">
TO
<match key="info.capabilities" contains="input.keys">
RESTART HAL
if afterwards it's still not applied, put the file in /usr/share/hal/fdi/policy/20thirdparty/
RESTART HAL
You'll know it worked when
info.callouts.add = { 'hal-setup-keymap' } (string list)
appears in the hal-device output

And what other files you have in /etc/hal/ ?
With app-misc/hal-info-20071030 I don't have any fdi files there (though perhaps that is the correct place after all)
but my mouse looks like this:

Naib · Posted: Sat May 10, 2008 10:49 pm Post subject:

my mistake I didn't notice all the info.capabilities

changed that to input.keys still didn't work (with a /etc/init.d/xdm stop && /etc/init.d/hald restart && /etc/init.d/xdm start inbetween)

copied the file to: /usr/share/hal/fdi/policy/20thirdparty/ and still didn't work (with a /etc/init.d/xdm stop && /etc/init.d/hald restart && /etc/init.d/xdm start inbetween)

did a gconftool-2 --recursive-unset /desktop/gnome/peripherals and then a reboot and still doesn't work

I'm going back to the kbd driver, hal is just to broken.
_________________

VoidMage · Watchman Joined: 14 Oct 2006 Posts: 6196

Well, my fdi file looks like this

Naib · Posted: Sun May 11, 2008 10:46 am Post subject:

Well got it working (tnx for help)

Seems it was definitely a GNOME issue
even when I set my system back to using kbd driver GNOME insisted it was going to use evdev (and as such no mouse or keyboard).
moving both the fdi files out of the hal policy folder/s and restarting X got the same up-arrow BUT this time gnome-keyboard insisted my layout was USA

moving those files back and re-starting X the upkey issue was fixed BUT they keymap was USA still. manually setting it to UK from the GNOME-gui sorted that
strange that the gconftool-2 --recursive-unset /desktop/gnome/peripherals didn't reset that

its not good that there is basically 3 places that
1) layout
2) keyboard driver
is set (xorg.conf,hal fdi, gnome setting) AND the order is key. I thought that evdev is/was suppose to simplify things
_________________

VoidMage · Watchman Joined: 14 Oct 2006 Posts: 6196

You're looking at this the wrong way.
Originally you setup the keyboard in xorg.conf (or whatever this file was called before xorg)
Gnome/KDE keyb. controls were overriding those settings.
Now xorg is trying to move to hal, but those desktop controls still try to override it.
That may sometimes lead to conflicts.

rodrigoaraujorge · n00b Joined: 12 May 2008 Posts: 2

OK guys. We already know how to solve the layout problem of keyboards. However, I'm also having FN key problems since I upgraded HAL.
There is a topic with 6 posts about that but it is dead: https://forums.gentoo.org/viewtopic-t-661319-highlight-.html?sid=af8b729fa8e29832f615acc866fdaeee

I posting here because FN is a keyboard problem and it is related to HAL. Does anyone know what can I replace, unset or do to solve it ? I do not want to downgrade my HAL version.

Thank you all for this big topic (spent almost 30 minutes reading it entirely). Cheers.

wizard69 · Apprentice Joined: 22 Sep 2003 Posts: 178 Location: Berlin

if you want to continue using the kbd driver and a xorg config file add this to the section server layout in your xorg.conf

hoschi · Posted: Mon May 12, 2008 8:27 pm Post subject:

Xake · Posted: Tue May 13, 2008 10:55 am Post subject: