[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xorg
Subject:    relation between kernel input events and leds
From:       Rafał Mużyło <galtgendo () gmail ! com>
Date:       2011-12-14 18:16:05
Message-ID: 20111214181605.GA2467 () blackspire
[Download RAW message or body]

This might not be 100% on-topic for this list, but it's the closest list
I'm familiar with.

I've got a mouse without a horizontal wheel. I've came across a piece of
code, that was written for for emulating mouse buttons via keyboard.
It grabs input/event* nodes and uses uinput to substitute certain
mouse/keyboard combinations for the desired mouse buttons.
I've modified it to use shift+wheel as hwheel.

It worked, but there's one unfortunate side effect, I just can't fix.
Both in console and in X pressing CapsLock/Numlock toggles its state,
but not the relevant keyboard led.

The original code comes from something called mouseemu, but I've taken
0.15 of it and applied *some* of the Debian patches (then added some of my own chages \
- I'm near the point of a working libudev hotplug monitor), so it differs in a few \
places.

Now, my question is: what is so special about keyboard led events, that
they don't get toggled, even though the states do ?
Is it something about timing/order of events ? Do I need to read and
process a certain number of events in one go ?

_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: freedesktop-xorg@progressive-comp.com


[prev in list] [next in list] [prev in thread] [next in thread]