On Sunday 03 February 2008 01:09:44 Michael Buesch wrote:
> 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...
Ok, well. I thought more about the approach to create a generic
"advanced" mouse API. And I must say... I really like it. :)
Let's see which features the razer mouse has.
LEDs -> These should conveniently be accessed in a standard way
through the LED triggers. So you could map some crazy functions
to the LEDs. Like your HDD LED, or your mail notification.
I really like that. :)
Scan resolution -> The mouse lets you change the resolution (in DPI)
at which it scans the underground. I think this actually
is not a razer specific feature. Every mouse can easily
implement this. So I think we should have a generic interface
for this. I'd say a sysfs file and a standardized API in the
kernel would be best. So if the mouse does not have this
feature,
the sysfs file is simply missing. That's OK and userspace can
easily test that.
Scan frequency -> The mouse lets you change the frequency (in Hz)
at which it scans the underground. This also is not a razer
specific feature. So a generic sysfs file would be good, too.
Firmware upload -> Not sure. Do we already have some generic device firmware
update API/subsystem?
Does that sound reasonable?
I think we should probably make this all independent of USB and HID.
So also mice on other buses can use it.
So we would create a new subsystem called "mouseconfig" or whatever which
lets you configure advanced mouse features through a standardized userspace
API. The busdriver (HID in this case) would then register to this subsystem,
tell it which features the mouse supports and provide callbacks to the hardware.
It should probably also provide information on the initial state of the
hardware.
Suggestions are welcome.
--
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