lkml.org 
[lkml]   [2008]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectDriver for new hid class (was: Can you use the USB HID interface within a driver?)
>> For 2.6.28, the HID code has been completely refactored, and converted 
>> into a proper bus, making it possible to write driver easily in a way
>> that the driver implements only parts where device deviates from the
>> HID standard, and lets the rest to be handled by generic code. I guess
>> this is what you are looking for?
>
> Yes, that sounds like exactly what I'm after! This device seems to be
> HID with a custom protocol over the top, so presumably I can let the HID
> driver handle all the USB initialisation and just focus on the protocol.

Okay, I've upgraded to 2.6.28-rc2 and started writing a driver for the
new hid class. It didn't take long for me to get stuck though :-(

When I load my module, it calls hid_register_driver() which returns
0/success. However that's as far as it gets. I've defined a probe
function to attach to the device, but this never gets called.

Is there something else I need to do? The USB IDs are right, and I
tried replugging the device with my "driver" loaded but it seems to be
ignored. It seems the device appears as a full HID input
implementation, so it gets an evdev device associated with it.

Does this mean I need to blacklist it to stop the HID input driver from
claiming it? Or should my driver be able to claim it in preference to
the input driver as mine is for a specific device, as opposed to the
whole class?

Thanks,
Adam.


\
 
 \ /
  Last update: 2008-11-02 07:47    [W:0.047 / U:1.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site