On Sunday 03 February 2008 00:39:26 Jiri Kosina wrote: > On Sun, 3 Feb 2008, Michael Buesch wrote: > > > Here's the current userspace implementation of the HAL: > > http://bu3sch.de/gitweb?p=razer.git;a=blob;f=librazer/hw_deathadder.c;h=e76d9347552eb5ea33b524a82e33ba869f3e0b3f;hb=HEAD > > The commands changed slightly in latest firmware version and there's > > also a command to upload firmware. But just so you get an idea... > > I will look at it, thanks. > > > > I have had a plan (*) for quite a long time to make the HID code > > > pluggable, so that it could be possible to write drivers for "slightly > > > non-standard" HID devices easily -- i.e. the specialized driver will > > > have the possibility to hook HID events that he is interested in, and > > > all other events will be handled by the common HID code ... would that > > > by any chance solve your issue? > > Hm, there seems to be some additional bit sent by the device indicating > > a keypress for a small key on the downside of the device. It seems that > > the device sends bit 7 in the IRQ data[0] to indicate the keypress. So > > yes, having hooks there would actually help me. > > Alternatively you can try checking whether hiddev/hidraw (which are > userspace interfaces to HID events in kernel) would be helpful. This > really depends quite a lot on what exactly is sent and how, so it is > difficult to say immediately.
I'm not sure we can actually use some standard kernel API to implement support for the advanced razer features. Especially because razer managed to completely f*ck up the API to their firmware in the latest firmware version (not supported by the current userspace HAL). Basically we are forced to keep some device state information in memory. So that either means we have to do some userspace daemon or do some tiny kernel module with a razer specific userspace API that holds the current state information of the device. I would really prefer the kernel module, as it's much easier to implement and in the end will be a lot less actual code. No IPC and stuff... . And IMO it's overkill to run a daemon just for a mouse. :) So the module will only have two things to do: Provide userspace API and hold device state in memory. However, having a razer specific kernel API seems not too good either. Maybe we can do some generic API? But I have no idea how other mice's features look like... > > Yeah well. I was talking about the drivers/hid/usbhid/usbmouse.c driver. > > Isn't that the driver for standard USB mice? (the device really is a > > standard USB mouse with additional features) > > Actually it is not. This is "just another thing I have on my todo > list"(tm) -- this (and usbkbd) driver really needs renaming. > > In usual conditions (which, I would say, means 99.9% of the world out > there) will never use usbkbd and usbmouse drivers ... everything is > handled by the usbhid driver. usbmouse (and usbkbd) are meant only for > very special situations -- please see the Kconfig help for > CONFIG_USB_MOUSE and CONFIG_USB_KBD. Oh I see. Thanks a lot. That also explains why the driver is so small. :) I'll take a look at the real driver. -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
