[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <490D4C0B.603@shikadi.net>
Date: Sun, 02 Nov 2008 16:43:23 +1000
From: Adam Nielsen <a.nielsen@...kadi.net>
To: Jiri Kosina <jkosina@...e.cz>
CC: LKML Mailinglist <linux-kernel@...r.kernel.org>
Subject: Driver 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists