support for Logitech Wave

 	Hi

   I've got a Logitech Wave keyboard, that has a number of extra keys on 
it, and most of them fail to work with evdev. I get no output with xev or 
while trying to cat the input device. I've been told that it's a kernel 
issue if the device shows no events, hence this email.

What should I do to get full support for all the keys on it? It's a nice 
keyboard, so I'd like to get the most of it :)

t

Hi Timo,

On Tue, Jan 15, 2008 at 03:49:14PM +0200, Timo Aaltonen wrote:

	Hi

  I've got a Logitech Wave keyboard, that has a number of extra keys on it, 
and most of them fail to work with evdev. I get no output with xev or while 
trying to cat the input device. I've been told that it's a kernel issue if 
the device shows no events, hence this email.

What should I do to get full support for all the keys on it? It's a nice 
keyboard, so I'd like to get the most of it :)

Please try booting with the latest -rc kernel (currently 2.6.26-rc8) and run
evtest utility. You should see it report MSC_SCAN events when you press keys
on your keyboard. Compose list of keys and corresponding codes and send it to
Jiri Kosina so he can add proper mappings to the HID driver.

Thanks!

-- 
Dmitry

Hi! Chiming in, as I have a similar issue ...

On Wed, Jan 16, 2008 at 11:07:17AM -0500, Dmitry Torokhov wrote:

Hi Timo,

On Tue, Jan 15, 2008 at 03:49:14PM +0200, Timo Aaltonen wrote:

quoted

	Hi

  I've got a Logitech Wave keyboard, that has a number of extra keys on it, 
and most of them fail to work with evdev. I get no output with xev or while 
trying to cat the input device. I've been told that it's a kernel issue if 
the device shows no events, hence this email.

What should I do to get full support for all the keys on it? It's a nice 
keyboard, so I'd like to get the most of it :)

Please try booting with the latest -rc kernel (currently 2.6.26-rc8) and run
evtest utility. You should see it report MSC_SCAN events when you press keys
on your keyboard. Compose list of keys and corresponding codes and send it to
Jiri Kosina so he can add proper mappings to the HID driver.

I tried the same on a Creative Prodikeys keyboard, but can't see any
events for some keys (most notably none of the "piano" keys work).

Is there anything that can be done to make it work?

Cheers,

	Taneli

On Wed, 16 Jan 2008, Taneli Vähäkangas wrote:

I tried the same on a Creative Prodikeys keyboard, but can't see any 
events for some keys (most notably none of the "piano" keys work). Is 
there anything that can be done to make it work?

Hi Taneli,

yes. Could you please grab reasonably recent kernel (2.6.24-rc<anything> 
would be ok), compile it with CONFIG_HID_DEBUG, modprobe the 'hid' module 
with 'debug=1' parameter, and send me the output from the time you connect 
the keyboard and from pressing the non-working keys? It should be trivial 
to fix then.

Thanks,

-- 
Jiri Kosina

On Wed, 16 Jan 2008, Jiri Kosina wrote:

On Wed, 16 Jan 2008, Taneli Vähäkangas wrote:

quoted

I tried the same on a Creative Prodikeys keyboard, but can't see any
events for some keys (most notably none of the "piano" keys work). Is
there anything that can be done to make it work?

Hi Taneli,

yes. Could you please grab reasonably recent kernel (2.6.24-rc<anything>
would be ok), compile it with CONFIG_HID_DEBUG, modprobe the 'hid' module
with 'debug=1' parameter, and send me the output from the time you connect
the keyboard and from pressing the non-working keys? It should be trivial
to fix then.

Hi! I managed to get the event codes with evtest. Here's the output, 
followed by mappings to what the buttons really are. The ones that are 
mapped below 255 are working on X:

Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0x46d product 0xc317 version 0x110
Input device name: "Logitech USB Multimedia Keyboard"
Supported events:
   Event type 0 (Reset)
     Event code 0 (Reset)
     Event code 1 (Key)
     Event code 4 (?)
   Event type 1 (Key)
     Event code 113 (Mute)
     Event code 114 (VolumeDown)
     Event code 115 (VolumeUp)
     Event code 140 (Calc)
     Event code 142 (Sleep)
     Event code 155 (Mail)
     Event code 163 (NextSong)
     Event code 164 (PlayPause)
     Event code 165 (PreviousSong)
     Event code 166 (StopCD)
     Event code 171 (Config)
     Event code 172 (HomePage)
     Event code 256 (Btn0)
     Event code 257 (Btn1)
     Event code 258 (Btn2)
     Event code 259 (Btn3)
     Event code 260 (Btn4)
     Event code 261 (Btn5)
     Event code 262 (Btn6)
     Event code 263 (Btn7)
     Event code 264 (Btn8)
     Event code 266 (?)
     Event code 267 (?)
     Event code 268 (?)
     Event code 269 (?)
     Event code 270 (?)
     Event code 271 (?)
     Event code 272 (LeftBtn)
     Event code 273 (RightBtn)


Mappings:

256 (Btn0)	"Word"
257 (Btn1)	"Spreadsheet"
258 (Btn2)	"Calendar"
259 (Btn3)	"custom key a"
260 (Btn4)	"Photos"
261 (Btn5)	"custom key b"
262 (Btn6)	"custom key c"
263 (Btn7)	"Media center"
264 (Btn8)	"Messenger"
266 (?)		"local search"
267 (?)		"Vista Flip 3D" (go through windows, "alt-tab")
268 (?)		"Vista Gadget" (
269 (?)		"internet search"
270 (?)		"zoom -"
271 (?)		"zoom +"
272 (LeftBtn)	"eject"
273 (RightBtn)	"Function key, used for most of the above"

Hope this helps!

t
-
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, 17 Jan 2008, Timo Aaltonen wrote:

268 (?)		"Vista Gadget" (

hmm, this was not complete.. that key is apparently used for launching the 
vista gadget library.. never seen one but that's the name of the key on 
the "manual".

btw, the kernel was 2.6.24-rc7 from Ubuntu Hardy.

t

On Wed, Jan 16, 2008 at 11:00:48PM +0100, Jiri Kosina wrote:

On Wed, 16 Jan 2008, Taneli Vähäkangas wrote:

quoted

I tried the same on a Creative Prodikeys keyboard, but can't see any 
events for some keys (most notably none of the "piano" keys work). Is 
there anything that can be done to make it work?

Hi Taneli,

yes. Could you please grab reasonably recent kernel (2.6.24-rc<anything> 
would be ok), compile it with CONFIG_HID_DEBUG, modprobe the 'hid' module 
with 'debug=1' parameter, and send me the output from the time you connect 
the keyboard and from pressing the non-working keys? It should be trivial 
to fix then.

Thanks for prompt reply Jiri. Now I get some information for extra
function keys at the top row, but still nothing for the "piano" keys.
Here's the output for two previously non-functioning keys:


Jan 17 00:27:13 newer kernel: drivers/hid/hid-core.c: report (size 4)
(numbered)
Jan 17 00:27:13 newer kernel: drivers/hid/hid-core.c: report 4 (size 3) =  02 00 00
Jan 17 00:27:13 newer kernel: hid-debug: input ff00.0001 = 0
Jan 17 00:27:13 newer kernel: hid-debug: input ff00.0001 = 1
Jan 17 00:27:13 newer kernel: hid-debug: input ff00.0001 = 0
Jan 17 00:27:13 newer last message repeated 13 times
Jan 17 00:27:13 newer kernel: drivers/hid/hid-core.c: report (size 4) (numbered)
Jan 17 00:27:13 newer kernel: drivers/hid/hid-core.c: report 4 (size 3) =  00 00 00
Jan 17 00:27:13 newer kernel: hid-debug: input ff00.0001 = 0
Jan 17 00:27:13 newer last message repeated 15 times


Is this the information you asked? I can make you the full mapping of
non-working keys to log messages. However, I don't think that's very
useful if the "piano" keys don't work, as they're the main reason for
having such a keyboard in the first place.

There was a great deal of log messages at the time of plugging in the
keyboard. I didn't feel comfortable spamming the list with it, so it is
available at:
http://www.cs.helsinki.fi/u/vahakang/hid-dbg.txt

(I think all the log entries after 00:23:59 are key presses, but
couldn't tell for sure.)

BTW, here's a picture of the keyboard in question ... just in case my
descriptions don't seem to make sense:
http://images.tw.creative.com/images/corporate/artwork/hires_prodikeyspcmidiusb.jpg

Cheers,

	Taneli
-
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, 17 Jan 2008, Taneli Vähäkangas wrote:

Thanks for prompt reply Jiri. Now I get some information for extra 
function keys at the top row, but still nothing for the "piano" keys. 

That's strange. Could you please try to snoop the traffic on USB, to see 
if the keys that don't produce any HID debugging output at all at least 
produce some USB traffic?

See Documentation/usb/usbmon.txt for details.

Here's the output for two previously non-functioning keys:
Jan 17 00:27:13 newer kernel: drivers/hid/hid-core.c: report (size 4)
(numbered)
Jan 17 00:27:13 newer kernel: drivers/hid/hid-core.c: report 4 (size 3) =  02 00 00
Jan 17 00:27:13 newer kernel: hid-debug: input ff00.0001 = 0
Jan 17 00:27:13 newer kernel: hid-debug: input ff00.0001 = 1
Jan 17 00:27:13 newer kernel: hid-debug: input ff00.0001 = 0
Jan 17 00:27:13 newer last message repeated 13 times
Jan 17 00:27:13 newer kernel: drivers/hid/hid-core.c: report (size 4) (numbered)
Jan 17 00:27:13 newer kernel: drivers/hid/hid-core.c: report 4 (size 3) =  00 00 00
Jan 17 00:27:13 newer kernel: hid-debug: input ff00.0001 = 0
Jan 17 00:27:13 newer last message repeated 15 times

Hmm, this looks only like output for on key, is it really for two?

Is this the information you asked? I can make you the full mapping of
non-working keys to log messages. However, I don't think that's very
useful if the "piano" keys don't work, as they're the main reason for
having such a keyboard in the first place.

Yes, we'll need to figure out where the data from these keys are getting 
lost.

(I think all the log entries after 00:23:59 are key presses, but
couldn't tell for sure.)

Yes, they are.

BTW, here's a picture of the keyboard in question ... just in case my
descriptions don't seem to make sense:
http://images.tw.creative.com/images/corporate/artwork/hires_prodikeyspcmidiusb.jpg

Could it be that the keyboard is a totally separate device? Does alsa 
report anything, when you connect it, for example?

-- 
Jiri Kosina

Hello!

On Thu, Jan 17, 2008 at 02:07:03PM +0100, Jiri Kosina wrote:

On Thu, 17 Jan 2008, Taneli Vähäkangas wrote:

quoted

Thanks for prompt reply Jiri. Now I get some information for extra 
function keys at the top row, but still nothing for the "piano" keys. 

That's strange. Could you please try to snoop the traffic on USB, to see 
if the keys that don't produce any HID debugging output at all at least 
produce some USB traffic?

See Documentation/usb/usbmon.txt for details.

I did that and there are no usbmon messages at all for the "piano" keys,
so this is most likely not linux-input or HID issue.

quoted

Here's the output for two previously non-functioning keys:
Jan 17 00:27:13 newer kernel: drivers/hid/hid-core.c: report (size 4)
(numbered)
Jan 17 00:27:13 newer kernel: drivers/hid/hid-core.c: report 4 (size 3) =  02 00 00
Jan 17 00:27:13 newer kernel: hid-debug: input ff00.0001 = 0
Jan 17 00:27:13 newer kernel: hid-debug: input ff00.0001 = 1
Jan 17 00:27:13 newer kernel: hid-debug: input ff00.0001 = 0
Jan 17 00:27:13 newer last message repeated 13 times
Jan 17 00:27:13 newer kernel: drivers/hid/hid-core.c: report (size 4) (numbered)
Jan 17 00:27:13 newer kernel: drivers/hid/hid-core.c: report 4 (size 3) =  00 00 00
Jan 17 00:27:13 newer kernel: hid-debug: input ff00.0001 = 0
Jan 17 00:27:13 newer last message repeated 15 times

Hmm, this looks only like output for on key, is it really for two?

I'll check again later, I was quite confident last night that it was two
keypresses, but I was also quite tired ...

quoted

BTW, here's a picture of the keyboard in question ... just in case my
descriptions don't seem to make sense:
http://images.tw.creative.com/images/corporate/artwork/hires_prodikeyspcmidiusb.jpg

Could it be that the keyboard is a totally separate device? Does alsa 
report anything, when you connect it, for example?

Unfortunately alsa notices nothing (that was also my first guess, so I
tried that even before reporting the problem here).

Could it be that hid steals the device and that's why alsa doesn't see
it?

Maybe the keyboard expects some kind of trigger from the host side to
enable the missing functionality. It apparently requires a separate
driver in windows and doesn't work in Mac OS X (that's why my sister
borrowed the keyboard to me, it didn't work with a Mac ...)

Thanks a lot for your time and responses Jiri.

Cheers,

	Taneli

-
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, 17 Jan 2008, Timo Aaltonen wrote:

On Wed, 16 Jan 2008, Jiri Kosina wrote:

quoted

On Wed, 16 Jan 2008, Taneli Vähäkangas wrote:

quoted

I tried the same on a Creative Prodikeys keyboard, but can't see any
events for some keys (most notably none of the "piano" keys work). Is
there anything that can be done to make it work?

Hi Taneli,

yes. Could you please grab reasonably recent kernel (2.6.24-rc<anything>
would be ok), compile it with CONFIG_HID_DEBUG, modprobe the 'hid' module
with 'debug=1' parameter, and send me the output from the time you connect
the keyboard and from pressing the non-working keys? It should be trivial
to fix then.

Hi! I managed to get the event codes with evtest. Here's the output, followed 
by mappings to what the buttons really are. The ones that are mapped below 
255 are working on X:

Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0x46d product 0xc317 version 0x110
Input device name: "Logitech USB Multimedia Keyboard"
Supported events:
 Event type 0 (Reset)
   Event code 0 (Reset)
   Event code 1 (Key)
   Event code 4 (?)
 Event type 1 (Key)
   Event code 113 (Mute)
   Event code 114 (VolumeDown)
   Event code 115 (VolumeUp)
   Event code 140 (Calc)
   Event code 142 (Sleep)
   Event code 155 (Mail)
   Event code 163 (NextSong)
   Event code 164 (PlayPause)
   Event code 165 (PreviousSong)
   Event code 166 (StopCD)
   Event code 171 (Config)
   Event code 172 (HomePage)
   Event code 256 (Btn0)
   Event code 257 (Btn1)
   Event code 258 (Btn2)
   Event code 259 (Btn3)
   Event code 260 (Btn4)
   Event code 261 (Btn5)
   Event code 262 (Btn6)
   Event code 263 (Btn7)
   Event code 264 (Btn8)
   Event code 266 (?)
   Event code 267 (?)
   Event code 268 (?)
   Event code 269 (?)
   Event code 270 (?)
   Event code 271 (?)
   Event code 272 (LeftBtn)
   Event code 273 (RightBtn)


Mappings:

256 (Btn0)	"Word"
257 (Btn1)	"Spreadsheet"
258 (Btn2)	"Calendar"
259 (Btn3)	"custom key a"
260 (Btn4)	"Photos"
261 (Btn5)	"custom key b"
262 (Btn6)	"custom key c"
263 (Btn7)	"Media center"
264 (Btn8)	"Messenger"
266 (?)		"local search"
267 (?)		"Vista Flip 3D" (go through windows, "alt-tab")
268 (?)		"Vista Gadget" (Vista "desktop applets"?)
269 (?)		"internet search"
270 (?)		"zoom -"
271 (?)		"zoom +"
272 (LeftBtn)	"eject"
273 (RightBtn)	"Function key, used for most of the above"

Hope this helps!

Jiri, did you notice this post? Is there enough information for you to 
patch the driver?

thanks,

t
-
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, 12 Feb 2008, Timo Aaltonen wrote:

quoted

quoted

yes. Could you please grab reasonably recent kernel 
(2.6.24-rc<anything> would be ok), compile it with CONFIG_HID_DEBUG, 
modprobe the 'hid' module with 'debug=1' parameter, and send me the 
output from the time you connect the keyboard and from pressing the 
non-working keys? It should be trivial to fix then.

Hi! I managed to get the event codes with evtest. Here's the output, 
followed by mappings to what the buttons really are. The ones that are 
mapped below 255 are working on X:

Jiri, did you notice this post? Is there enough information for you to patch
the driver?

No, sorry, I missed it, please don't drop me from To:/Cc:, otherwise I am 
likely to miss posts :)

If all the events are seen by evtest, then everything is fine on the 
kernel side and you should just tweak your X configuration.

-- 
Jiri Kosina

On Tue, 12 Feb 2008, Jiri Kosina wrote:

On Tue, 12 Feb 2008, Timo Aaltonen wrote:

quoted

quoted

quoted

yes. Could you please grab reasonably recent kernel
(2.6.24-rc<anything> would be ok), compile it with CONFIG_HID_DEBUG,
modprobe the 'hid' module with 'debug=1' parameter, and send me the
output from the time you connect the keyboard and from pressing the
non-working keys? It should be trivial to fix then.

Hi! I managed to get the event codes with evtest. Here's the output,
followed by mappings to what the buttons really are. The ones that are
mapped below 255 are working on X:

Jiri, did you notice this post? Is there enough information for you to patch
the driver?

No, sorry, I missed it, please don't drop me from To:/Cc:, otherwise I am
likely to miss posts :)

Ah ok, sorry about that :)

If all the events are seen by evtest, then everything is fine on the
kernel side and you should just tweak your X configuration.

hmm, but X doesn't allow key-id's >255, so I can only wait until they 
support more? (maybe in X.org R7.5..)

t

On Tue, 12 Feb 2008, Timo Aaltonen wrote:

quoted

If all the events are seen by evtest, then everything is fine on the
kernel side and you should just tweak your X configuration.

hmm, but X doesn't allow key-id's >255, so I can only wait until they support
more? (maybe in X.org R7.5..)

You need to specify "evdev" as the keyboard driver in the xorg.conf input 
device section and the correct input device for your keyboard. Then you 
should be able to get all the keys working correctly in xorg.

-- 
Jiri Kosina

On Tue, 12 Feb 2008, Jiri Kosina wrote:

On Tue, 12 Feb 2008, Timo Aaltonen wrote:

quoted

quoted

If all the events are seen by evtest, then everything is fine on the
kernel side and you should just tweak your X configuration.

hmm, but X doesn't allow key-id's >255, so I can only wait until they support
more? (maybe in X.org R7.5..)

You need to specify "evdev" as the keyboard driver in the xorg.conf input
device section and the correct input device for your keyboard. Then you
should be able to get all the keys working correctly in xorg.

Yes, evdev is what I'm using, but I still don't get any events with xev. 
I'll ask the Xorg dev's again about it. IIRC it was a limitation of XKB..

t