Hello everyone,
I'm writing a driver for an USB device that has one configuration with
several interfacies and one of them is a HID interface. So when I check
this interface whether it's claimed (usb_interface_claimed), I find out
that it is, and it's claimed by the HID driver. So here is the
question: how can I ask the HID driver to unclaim this very interface
for me so that I can use it? The HID driver is needed for some other
devices, so I can't just rmmod it.
Thanks in advice.
Regards,
Ivan Ukhov.
On Sat, 20 Jan 2007, Ivan Ukhov wrote:
> I'm writing a driver for an USB device that has one configuration with
> several interfacies and one of them is a HID interface. So when I check
> this interface whether it's claimed (usb_interface_claimed), I find out
> that it is, and it's claimed by the HID driver. So here is the question:
> how can I ask the HID driver to unclaim this very interface for me so
> that I can use it? The HID driver is needed for some other devices, so I
> can't just rmmod it.
Hi Ivan,
if I understand correctly what you need, wouldn't setting the
HID_QUIRK_IGNORE for a given tuple of idVendor and idProduct be enough?
(see hid_blacklist[] in drivers/usb/input/hid-core.c).
--
Jiri Kosina
Jiri Kosina wrote:
> On Sat, 20 Jan 2007, Ivan Ukhov wrote:
>
>
>> I'm writing a driver for an USB device that has one configuration with
>> several interfacies and one of them is a HID interface. So when I check
>> this interface whether it's claimed (usb_interface_claimed), I find out
>> that it is, and it's claimed by the HID driver. So here is the question:
>> how can I ask the HID driver to unclaim this very interface for me so
>> that I can use it? The HID driver is needed for some other devices, so I
>> can't just rmmod it.
>>
>
> Hi Ivan,
>
> if I understand correctly what you need, wouldn't setting the
> HID_QUIRK_IGNORE for a given tuple of idVendor and idProduct be enough?
> (see hid_blacklist[] in drivers/usb/input/hid-core.c).
>
>
No, it won't do. Imagine that I'm not able to modify the kernel with its
drivers. It should work with usual kernel and HID driver. So I want my
driver to ask the HID driver to free the interfaces or don't claim them
at all. Mb there's an example of such a driver?.. obviously there are a
lot of HID devices and mb a vendor one of them doesn't want to use HID
driver for one of its interfaces to provide some additional features or
something, so he should make the kernel use his driver instead of HID...
Does it make any sense?)
On Sun, 21 Jan 2007, Ivan Ukhov wrote:
> No, it won't do. Imagine that I'm not able to modify the kernel with its
> drivers.
Could I ask you what precisely is the driver you are talking about doing?
Why is it not going to be a part of mainline kernel (i.e. being able to be
put on blacklist easily).
> It should work with usual kernel and HID driver. So I want my driver to
> ask the HID driver to free the interfaces or don't claim them at all. Mb
> there's an example of such a driver?.. obviously there are a lot of HID
> devices and mb a vendor one of them doesn't want to use HID driver for
> one of its interfaces to provide some additional features or something,
> so he should make the kernel use his driver instead of HID...
Sure, there are such in-kernel drivers ... for example Wacom driver. This
driver is in-kernel, and it is hooked inside the usb_hid_configure()
function to be ignored by the HID layer completely, and all the driver
specific handling is handled in drivers/usb/input/wacom*.
(When looking at that code, it looks quite ugly by the way. I have no idea
why wacom driver is not using HID_QUIRK_IGNORE, but has a hardcoded hook
in the usb_hid_configure() instead. I will probably fix this.)
Thanks,
--
Jiri Kosina
> Could I ask you what precisely is the driver you are talking about doing?
> Why is it not going to be a part of mainline kernel (i.e. being able to be
> put on blacklist easily).
>
It's a tiny driver and it hardy can be a part of the mainline kernel
because of its useless for everyone but me, beside I don't want to make
someone modify the kernel code. For example, I've written this driver,
than someone who wanna use it takes the code and tries to deal with it
and he finds out that he also needs to have the latest kernel (where the
device is included to that black list) or to fix the kernel himself.
It's rather uncomfortable for a person who just wants to use a simple
device with a simple driver, isn't it? It'll be great if my driver can
manage it himself.
> Sure, there are such in-kernel drivers ... for example Wacom driver. This
> driver is in-kernel, and it is hooked inside the usb_hid_configure()
> function to be ignored by the HID layer completely, and all the driver
> specific handling is handled in drivers/usb/input/wacom*.
>
> (When looking at that code, it looks quite ugly by the way. I have no idea
> why wacom driver is not using HID_QUIRK_IGNORE, but has a hardcoded hook
> in the usb_hid_configure() instead. I will probably fix this.)
>
As far as I remember this driver modifies the HID driver... it's what I
was talking about late.
On Sun, 21 Jan 2007, Ivan Ukhov wrote:
> It's a tiny driver and it hardy can be a part of the mainline kernel
> because of its useless for everyone but me, beside I don't want to make
> someone modify the kernel code.
Then, when this is a non-standard situation anyway, would calling
hid_disconnect() for the usb_interface of your driver be enough?
--
Jiri Kosina
Jiri Kosina wrote:
> Then, when this is a non-standard situation anyway, would calling
> hid_disconnect() for the usb_interface of your driver be enough?
>
I can't even imagine how to call this very function. Could you give me
an example? After all, this function and friends of its aren't
EXPORTED_SYMBOLs. Beside it's going to end up depending on the HID
driver, so the HID driver will have to be loaded all the time even if my
driver is loaded first and manages to claim the interfaces.
Sorry, I've absolutely forgotten to say that I'm talking about 2.4.x and
this function looks like:
static void hid_disconnect(struct usb_device *dev, void *ptr);
ptr is a pointer to the struct hid_device structure, which is created
and initialized in the probe function. Do you offer me to set up this
structure myself????
Thank you.
Ivan Ukhov.
On Sun, 21 Jan 2007, Jiri Kosina wrote:
> > It's a tiny driver and it hardy can be a part of the mainline kernel
> > because of its useless for everyone but me, beside I don't want to
> > make someone modify the kernel code.
> Then, when this is a non-standard situation anyway, would calling
> hid_disconnect() for the usb_interface of your driver be enough?
.. which wouldn't help you either, supposing that you don't want to touch
the kernel sources at all, because this function is unexported and static.
So I think that there is no straightforward way, sorry.
Is this a device that doesn't exist anywhere else than on your table? I
still think that putting the code in kernel (if possible) and blacklisting
the device on the hid_blacklist[] is the simplest way.
The other possibility is writing the driver completely in userspace, using
libhid/hiddev. Would that suit your needs?
--
Jiri Kosina
> .. which wouldn't help you either, supposing that you don't want to touch
> the kernel sources at all, because this function is unexported and static.
>
> So I think that there is no straightforward way, sorry.
>
> Is this a device that doesn't exist anywhere else than on your table? I
> still think that putting the code in kernel (if possible) and blacklisting
> the device on the hid_blacklist[] is the simplest way.
>
> The other possibility is writing the driver completely in userspace, using
> libhid/hiddev. Would that suit your needs?
I'm afraid it wouldn't.
Thank you very much.
--
Regards,
Ivan Ukhov.
Ivan Ukhov wrote:
>> .. which wouldn't help you either, supposing that you don't want to touch
>> the kernel sources at all, because this function is unexported and
>> static.
>>
>> So I think that there is no straightforward way, sorry.
>>
>> Is this a device that doesn't exist anywhere else than on your table? I
>> still think that putting the code in kernel (if possible) and
>> blacklisting the device on the hid_blacklist[] is the simplest way.
>>
>> The other possibility is writing the driver completely in userspace,
>> using libhid/hiddev. Would that suit your needs?
>
> I'm afraid it wouldn't.
>
> Thank you very much.
>
There is another way. Have a look at this article:
http://lwn.net/Articles/143397/
Maybe this is an option for you.
-Rolf
--
Rolf Offermanns <[email protected]>
SYSGO AG Tel.: +49-6136-9948-0
Am Pfaffenstein 14 Fax: +49-6136-9948-10
55270 Klein-Winternheim http://www.sysgo.com