Logitech MX5000 extra keys

Logitech MX5000 extra keys

[Bastien Nocera]

Heya,

I own another keyboard, the Logitech MX5000[1], which is a
keyboard/mouse combo, with a USB dongle (which can switch between HID
and HCI/Bluetooth modes).

Some keys aren't reported at all through the input layer, but there is
code in the mx5000-tools[2] to make those keys work through hiddev.

See eventin():
http://svn.gna.org/viewcvs/mx5000tools/trunk/mx5000d/input_translate.c?rev=15&view=auto

There's a bit more scary code to enable the keys in the library part of
the module.

I was wondering what the best course of action would be to make this
code work out-of-the-box. Would it be better to write a HAL addon, and
do all this work in user-space, or would it be more useful to have
directly in the kernel?

Obviously, if the latter, I'd appreciate a bit of guidance on where I
should add the code.

Cheers


[1]: http://www.amazon.com/Logitech-Cordless-Desktop-Laser-967558-0403/dp/B000AY5ZIS
[2]: http://home.gna.org/mx5000tools/

Re: Logitech MX5000 extra keys

[Jiri Kosina]

On Fri, 6 Feb 2009, Bastien Nocera wrote:

> Some keys aren't reported at all through the input layer, but there is 
> code in the mx5000-tools[2] to make those keys work through hiddev.
[ ... ]
> I was wondering what the best course of action would be to make this
> code work out-of-the-box. Would it be better to write a HAL addon, and
> do all this work in user-space, or would it be more useful to have
> directly in the kernel?
> Obviously, if the latter, I'd appreciate a bit of guidance on where I
> should add the code.

Hi Bastien,

the HAL people are trying to put as much possible of the mappings into the 
userspace HAL code, see [1].

If you prefer doing the mappings correctly already in-kernel for this 
particular keyboard, please see Logitech-specific HID driver in 
drivers/hid/hid-lg.c; we already handle various kinds of Logitech devices 
there, and adding a new one is pretty straightforward (maybe the code can 
even be shared with a different model).

[1] http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html

-- 
Jiri Kosina
SUSE Labs

Re: Logitech MX5000 extra keys

[Bastien Nocera]

On Sat, 2009-02-07 at 02:12 +0100, Jiri Kosina wrote:
> On Fri, 6 Feb 2009, Bastien Nocera wrote:
> 
> > Some keys aren't reported at all through the input layer, but there is 
> > code in the mx5000-tools[2] to make those keys work through hiddev.
> [ ... ]
> > I was wondering what the best course of action would be to make this
> > code work out-of-the-box. Would it be better to write a HAL addon, and
> > do all this work in user-space, or would it be more useful to have
> > directly in the kernel?
> > Obviously, if the latter, I'd appreciate a bit of guidance on where I
> > should add the code.
> 
> Hi Bastien,
> 
> the HAL people are trying to put as much possible of the mappings into the 
> userspace HAL code, see [1].

Problem is that it's not just a mapping problem, as the keys don't get
out of the kernel at all. The code in hid-lg.c looks more like what's
required. Not sure whether the magic is the same to enable the extra
keys on this keyboard.

> If you prefer doing the mappings correctly already in-kernel for this 
> particular keyboard, please see Logitech-specific HID driver in 
> drivers/hid/hid-lg.c; we already handle various kinds of Logitech devices 
> there, and adding a new one is pretty straightforward (maybe the code can 
> even be shared with a different model).

I'll have to get my kernel groove back on and test this.

Cheers

Re: Logitech MX5000 extra keys

[Jiri Kosina]

On Mon, 9 Feb 2009, Bastien Nocera wrote:

> Problem is that it's not just a mapping problem, as the keys don't get 
> out of the kernel at all. The code in hid-lg.c looks more like what's 
> required. Not sure whether the magic is the same to enable the extra 
> keys on this keyboard.

It's possible (and, in fact, quite probable), that quirk similar (or even 
the very same) to what is implemented in lg_report_fixup() would be 
neeeded.

You can verify by adding the VID/PID of your device to struct 
hid_device_id lg_devices[] with LG_RDESC flag.

-- 
Jiri Kosina
SUSE Labs

Re: Logitech MX5000 extra keys

[Bastien Nocera]

On Tue, 2009-02-10 at 11:31 +0100, Jiri Kosina wrote:
> On Mon, 9 Feb 2009, Bastien Nocera wrote:
> 
> > Problem is that it's not just a mapping problem, as the keys don't get 
> > out of the kernel at all. The code in hid-lg.c looks more like what's 
> > required. Not sure whether the magic is the same to enable the extra 
> > keys on this keyboard.
> 
> It's possible (and, in fact, quite probable), that quirk similar (or even 
> the very same) to what is implemented in lg_report_fixup() would be 
> neeeded.
> 
> You can verify by adding the VID/PID of your device to struct 
> hid_device_id lg_devices[] with LG_RDESC flag.

I did, but without success (I didn't see the line "fixing up Logitech
keyboard report descriptor" in the kernel logs). In user-space, the
device needs to be poked to get the device to do something when the
extra keys are pressed. I guess something similar is needed here.

I'll leave work on this for a while until I get more time to experiment.

Cheers

Re: Logitech MX5000 extra keys

[Jiri Kosina]

On Tue, 10 Feb 2009, Bastien Nocera wrote:

> > You can verify by adding the VID/PID of your device to struct 
> > hid_device_id lg_devices[] with LG_RDESC flag.
> I did, but without success (I didn't see the line "fixing up Logitech 
> keyboard report descriptor" in the kernel logs). In user-space, the 
> device needs to be poked to get the device to do something when the 
> extra keys are pressed. I guess something similar is needed here.

Please compile the kernel with CONFIG_HID_DEBUG, modprobe the hid module 
with 'debug=2' and send me the report descriptor of the device (that 
appears in the dmesg output when the device is connected) as well as the 
output that appears when you press the non-working keys.

-- 
Jiri Kosina
SUSE Labs