Researching An Experimental Touchscreen Driver

Researching An Experimental Touchscreen Driver

[Jeremy Moles]

Hello everyone! I have a piece of hardware here using a vanilla 2.6.34
kernel (though I can easily change kernels if needed) that has attached
to it internally a USB touchscreen device. The relevant DMESG info is
below, and this is printed out whenever the module 'usbhid' is loaded.

--------------------------------------------------------------------

usbcore: registered new interface driver hiddev
input: Fujitsu Component USB Touch Panel
as /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/input/input9
generic-usb 0003:0430:0501.0002: input: USB HID v1.00 Mouse [Fujitsu
Component USB Touch Panel] on usb-0000:00:1a.0-2/input0
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver

--------------------------------------------------------------------

For a long time now, we have been successfully configuring these
machines using the device node created when this driver is loaded, often
something like /dev/input/event5 (with a UDEV rule to make the name more
sensible). In X, we've been using the "evtouch" driver with this device
node, to great effect.

However, I am doing a bit of research and experimentation, and what I
would like to do is write some custom driver code to interface with this
device, instead of letting usbhid manage it. My question is, where is
the best place to start?

- Since usbhid already recognizes and binds to this device, what code
can I begin studying to see exactly how it's detecting this and
formatting input?

- Once usbhid attaches to this device, is the device in some kind of
lock? Is it possible to simply inject additional features or formatting
functions, possibly via quirks? (I don't quite understand how to do
anything with quirks other than blacklist a device).

- If I want to write a full driver for the device, what source file
would be best to start from? I've tried hacking usbtouchscreen.c and
hid-ntrig.c for the last few days to try and get them to bind to the
device, but neither attempt has seen any success. My hid-ntrig change
refuses to successfully call hid_parse(), and my usbtouchscreen change
continually returns some error code in the IRQ callback.

Re: Researching An Experimental Touchscreen Driver

[Jeremy Moles]

On Wed, 2010-11-24 at 11:07 -0500, Jeremy Moles wrote:
> Hello everyone! I have a piece of hardware here using a vanilla 2.6.34
> kernel (though I can easily change kernels if needed) that has attached
> to it internally a USB touchscreen device. The relevant DMESG info is
> below, and this is printed out whenever the module 'usbhid' is loaded.
> 
> --------------------------------------------------------------------
> 
> usbcore: registered new interface driver hiddev
> input: Fujitsu Component USB Touch Panel
> as /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/input/input9
> generic-usb 0003:0430:0501.0002: input: USB HID v1.00 Mouse [Fujitsu
> Component USB Touch Panel] on usb-0000:00:1a.0-2/input0
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> 
> --------------------------------------------------------------------
> 
> For a long time now, we have been successfully configuring these
> machines using the device node created when this driver is loaded, often
> something like /dev/input/event5 (with a UDEV rule to make the name more
> sensible). In X, we've been using the "evtouch" driver with this device
> node, to great effect.
> 
> However, I am doing a bit of research and experimentation, and what I
> would like to do is write some custom driver code to interface with this
> device, instead of letting usbhid manage it. My question is, where is
> the best place to start?
> 
> - Since usbhid already recognizes and binds to this device, what code
> can I begin studying to see exactly how it's detecting this and
> formatting input?
> 
> - Once usbhid attaches to this device, is the device in some kind of
> lock? Is it possible to simply inject additional features or formatting
> functions, possibly via quirks? (I don't quite understand how to do
> anything with quirks other than blacklist a device).
> 
> - If I want to write a full driver for the device, what source file
> would be best to start from? I've tried hacking usbtouchscreen.c and
> hid-ntrig.c for the last few days to try and get them to bind to the
> device, but neither attempt has seen any success. My hid-ntrig change
> refuses to successfully call hid_parse(), and my usbtouchscreen change
> continually returns some error code in the IRQ callback.

I hope this isn't bad etiquette to self-bump my owns posts... I was just
curious if anyone might have any advice. I've continued to hack around,
and I'm certainly gaining more knowledge, but not quite there yet.

Is there a good primer anywhere, or does have any skeleton code they
use, for writing input drivers in Linux? The code is already there in
usbhid.ko for this particular device, so I know it's just a matter of
piecing it together, adding my modifications, and making them play
nice. :)

Re: Researching An Experimental Touchscreen Driver

[Dmitry Torokhov]

On Wed, Nov 24, 2010 at 11:07:00AM -0500, Jeremy Moles wrote:
> Hello everyone! I have a piece of hardware here using a vanilla 2.6.34
> kernel (though I can easily change kernels if needed) that has attached
> to it internally a USB touchscreen device. The relevant DMESG info is
> below, and this is printed out whenever the module 'usbhid' is loaded.
> 
> --------------------------------------------------------------------
> 
> usbcore: registered new interface driver hiddev
> input: Fujitsu Component USB Touch Panel
> as /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/input/input9
> generic-usb 0003:0430:0501.0002: input: USB HID v1.00 Mouse [Fujitsu
> Component USB Touch Panel] on usb-0000:00:1a.0-2/input0
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> 
> --------------------------------------------------------------------
> 
> For a long time now, we have been successfully configuring these
> machines using the device node created when this driver is loaded, often
> something like /dev/input/event5 (with a UDEV rule to make the name more
> sensible). In X, we've been using the "evtouch" driver with this device
> node, to great effect.
> 
> However, I am doing a bit of research and experimentation, and what I
> would like to do is write some custom driver code to interface with this
> device, instead of letting usbhid manage it. My question is, where is
> the best place to start?

I guess you need to enumerate what deficiencies usbhid has and what
issues you want to solve. That would clear a lot. I think that
completely abandoning HID driver for device that is mostly HID compliant
is not the best idea and you probably want to wire a HID sub-driver that
works in tandem with usbhid.

> 
> - Since usbhid already recognizes and binds to this device, what code
> can I begin studying to see exactly how it's detecting this and
> formatting input?

I guess drivers/hid/hid-input.c is the most interesting one.

> 
> - Once usbhid attaches to this device, is the device in some kind of
> lock? Is it possible to simply inject additional features or formatting
> functions, possibly via quirks? (I don't quite understand how to do
> anything with quirks other than blacklist a device).

Only one driver can manage a device so once HID claimed it your
standalone driver will not be able to control it. However there is
notion of HID bus drivers (you looked at hid-ntrig - it's one of them)
that allow you to override and/or augment processing done by the default
HID driver.

> 
> - If I want to write a full driver for the device, what source file
> would be best to start from? I've tried hacking usbtouchscreen.c and
> hid-ntrig.c for the last few days to try and get them to bind to the
> device, but neither attempt has seen any success. My hid-ntrig change
> refuses to successfully call hid_parse(), and my usbtouchscreen change
> continually returns some error code in the IRQ callback.

Did you add the VID/PID of your device to the blacklist in
drivers/hid/hid-core.c?

-- 
Dmitry

Re: Researching An Experimental Touchscreen Driver

[Jeremy Moles]

On Sat, 2010-11-27 at 15:51 -0800, Dmitry Torokhov wrote:
> On Wed, Nov 24, 2010 at 11:07:00AM -0500, Jeremy Moles wrote:
> > Hello everyone! I have a piece of hardware here using a vanilla 2.6.34
> > kernel (though I can easily change kernels if needed) that has attached
> > to it internally a USB touchscreen device. The relevant DMESG info is
> > below, and this is printed out whenever the module 'usbhid' is loaded.
> > 
> > --------------------------------------------------------------------
> > 
> > usbcore: registered new interface driver hiddev
> > input: Fujitsu Component USB Touch Panel
> > as /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/input/input9
> > generic-usb 0003:0430:0501.0002: input: USB HID v1.00 Mouse [Fujitsu
> > Component USB Touch Panel] on usb-0000:00:1a.0-2/input0
> > usbcore: registered new interface driver usbhid
> > usbhid: USB HID core driver
> > 
> > --------------------------------------------------------------------
> > 
> > For a long time now, we have been successfully configuring these
> > machines using the device node created when this driver is loaded, often
> > something like /dev/input/event5 (with a UDEV rule to make the name more
> > sensible). In X, we've been using the "evtouch" driver with this device
> > node, to great effect.
> > 
> > However, I am doing a bit of research and experimentation, and what I
> > would like to do is write some custom driver code to interface with this
> > device, instead of letting usbhid manage it. My question is, where is
> > the best place to start?
> 
> I guess you need to enumerate what deficiencies usbhid has and what
> issues you want to solve. That would clear a lot. I think that
> completely abandoning HID driver for device that is mostly HID compliant
> is not the best idea and you probably want to wire a HID sub-driver that
> works in tandem with usbhid.

I think you're absolutely right about a sub-driver of sorts.

Essentially it comes down to this: the touchscreen is being used in
hardware running Android, and the Android userspace code expects an
input event device to support the BTN_TOUCH ioctl. However, seeing as
usbhid binds to this device in a very generic way, it doesn't add the
BTN_TOUCH bits, and rightly so. In regular X, the evtouch driver does
not require this particular feature, so the device works fine.

HOWEVER, if I remove this check from the Android userspace library tslib
(the ioctl query for BTN_TOUCH), it does at least act as a pointer
inside Android's display manager, although there is no notion of
pressure--it's either 255 or 0 in tslib terms. I'm not entirely sure the
device even supports pressure, but that is why I'm researching this
project. :)

> > 
> > - Since usbhid already recognizes and binds to this device, what code
> > can I begin studying to see exactly how it's detecting this and
> > formatting input?
> 
> I guess drivers/hid/hid-input.c is the most interesting one.
> 
> > 
> > - Once usbhid attaches to this device, is the device in some kind of
> > lock? Is it possible to simply inject additional features or formatting
> > functions, possibly via quirks? (I don't quite understand how to do
> > anything with quirks other than blacklist a device).
> 
> Only one driver can manage a device so once HID claimed it your
> standalone driver will not be able to control it. However there is
> notion of HID bus drivers (you looked at hid-ntrig - it's one of them)
> that allow you to override and/or augment processing done by the default
> HID driver.

This is definitely what I'm interested in. I stripped its code down to
basically just the probe function. It recognizes my USB PCIID but fails
to call hid_parse() with the error -19. I've not been able to lock down
where the ll_driver->hid_parse() function is to see exactly what this
error might be.

> > 
> > - If I want to write a full driver for the device, what source file
> > would be best to start from? I've tried hacking usbtouchscreen.c and
> > hid-ntrig.c for the last few days to try and get them to bind to the
> > device, but neither attempt has seen any success. My hid-ntrig change
> > refuses to successfully call hid_parse(), and my usbtouchscreen change
> > continually returns some error code in the IRQ callback.
> 
> Did you add the VID/PID of your device to the blacklist in
> drivers/hid/hid-core.c?

Yes, and this does prevent usbhid from picking it up. I can also add a
quirk to modprobe.conf dynamically adding the HID_QUIRK_IGNORE quirk to
achieve the same effect. In fact, this is necessary for my "hacked"
hid-testdriver.c module to even TRY and call the probe function.

BTW, thanks a ton for you response. I hope I've given you more
information, and I'll keep hacking on this!

Re: Researching An Experimental Touchscreen Driver

[Dmitry Torokhov]

On Sat, Nov 27, 2010 at 09:23:30PM -0500, Jeremy Moles wrote:
> On Sat, 2010-11-27 at 15:51 -0800, Dmitry Torokhov wrote:
> > On Wed, Nov 24, 2010 at 11:07:00AM -0500, Jeremy Moles wrote:
> > > Hello everyone! I have a piece of hardware here using a vanilla 2.6.34
> > > kernel (though I can easily change kernels if needed) that has attached
> > > to it internally a USB touchscreen device. The relevant DMESG info is
> > > below, and this is printed out whenever the module 'usbhid' is loaded.
> > > 
> > > --------------------------------------------------------------------
> > > 
> > > usbcore: registered new interface driver hiddev
> > > input: Fujitsu Component USB Touch Panel
> > > as /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/input/input9
> > > generic-usb 0003:0430:0501.0002: input: USB HID v1.00 Mouse [Fujitsu
> > > Component USB Touch Panel] on usb-0000:00:1a.0-2/input0
> > > usbcore: registered new interface driver usbhid
> > > usbhid: USB HID core driver
> > > 
> > > --------------------------------------------------------------------
> > > 
> > > For a long time now, we have been successfully configuring these
> > > machines using the device node created when this driver is loaded, often
> > > something like /dev/input/event5 (with a UDEV rule to make the name more
> > > sensible). In X, we've been using the "evtouch" driver with this device
> > > node, to great effect.
> > > 
> > > However, I am doing a bit of research and experimentation, and what I
> > > would like to do is write some custom driver code to interface with this
> > > device, instead of letting usbhid manage it. My question is, where is
> > > the best place to start?
> > 
> > I guess you need to enumerate what deficiencies usbhid has and what
> > issues you want to solve. That would clear a lot. I think that
> > completely abandoning HID driver for device that is mostly HID compliant
> > is not the best idea and you probably want to wire a HID sub-driver that
> > works in tandem with usbhid.
> 
> I think you're absolutely right about a sub-driver of sorts.
> 
> Essentially it comes down to this: the touchscreen is being used in
> hardware running Android, and the Android userspace code expects an
> input event device to support the BTN_TOUCH ioctl. However, seeing as
> usbhid binds to this device in a very generic way, it doesn't add the
> BTN_TOUCH bits, and rightly so. In regular X, the evtouch driver does
> not require this particular feature, so the device works fine.
> 
> HOWEVER, if I remove this check from the Android userspace library tslib
> (the ioctl query for BTN_TOUCH), it does at least act as a pointer
> inside Android's display manager, although there is no notion of
> pressure--it's either 255 or 0 in tslib terms. I'm not entirely sure the
> device even supports pressure, but that is why I'm researching this
> project. :)
> 
> > > 
> > > - Since usbhid already recognizes and binds to this device, what code
> > > can I begin studying to see exactly how it's detecting this and
> > > formatting input?
> > 
> > I guess drivers/hid/hid-input.c is the most interesting one.
> > 
> > > 
> > > - Once usbhid attaches to this device, is the device in some kind of
> > > lock? Is it possible to simply inject additional features or formatting
> > > functions, possibly via quirks? (I don't quite understand how to do
> > > anything with quirks other than blacklist a device).
> > 
> > Only one driver can manage a device so once HID claimed it your
> > standalone driver will not be able to control it. However there is
> > notion of HID bus drivers (you looked at hid-ntrig - it's one of them)
> > that allow you to override and/or augment processing done by the default
> > HID driver.
> 
> This is definitely what I'm interested in. I stripped its code down to
> basically just the probe function. It recognizes my USB PCIID but fails
> to call hid_parse() with the error -19. I've not been able to lock down
> where the ll_driver->hid_parse() function is to see exactly what this
> error might be.
> 
> > > 
> > > - If I want to write a full driver for the device, what source file
> > > would be best to start from? I've tried hacking usbtouchscreen.c and
> > > hid-ntrig.c for the last few days to try and get them to bind to the
> > > device, but neither attempt has seen any success. My hid-ntrig change
> > > refuses to successfully call hid_parse(), and my usbtouchscreen change
> > > continually returns some error code in the IRQ callback.
> > 
> > Did you add the VID/PID of your device to the blacklist in
> > drivers/hid/hid-core.c?
> 
> Yes, and this does prevent usbhid from picking it up. I can also add a
> quirk to modprobe.conf dynamically adding the HID_QUIRK_IGNORE quirk to
> achieve the same effect. In fact, this is necessary for my "hacked"
> hid-testdriver.c module to even TRY and call the probe function.

Well, if you add HID_QUIRK_IGNORE then in usbhid_parse:


        quirks = usbhid_lookup_quirk(le16_to_cpu(dev->descriptor.idVendor),
                        le16_to_cpu(dev->descriptor.idProduct));

        if (quirks & HID_QUIRK_IGNORE)
                return -ENODEV;

and -ENODEV is -19 so it is no surprise you are getting -19 from
hid_parse().

You need to make sure you are adding entry to

drivers/hid/hid-core.c:static const struct hid_device_id hid_blacklist[]

and not to

drivers/hid/usbhid/hid-quirks.c:static const struct hid_blacklist

Hmm, I wonder if we should rename the first one to something different,
like hid_has_custom_driver. Jiri?

-- 
Dmitry

Re: Researching An Experimental Touchscreen Driver

[Jeremy Moles]

On Sat, 2010-11-27 at 19:07 -0800, Dmitry Torokhov wrote:
> On Sat, Nov 27, 2010 at 09:23:30PM -0500, Jeremy Moles wrote:
> > On Sat, 2010-11-27 at 15:51 -0800, Dmitry Torokhov wrote:
> > > On Wed, Nov 24, 2010 at 11:07:00AM -0500, Jeremy Moles wrote:
> > > > Hello everyone! I have a piece of hardware here using a vanilla 2.6.34
> > > > kernel (though I can easily change kernels if needed) that has attached
> > > > to it internally a USB touchscreen device. The relevant DMESG info is
> > > > below, and this is printed out whenever the module 'usbhid' is loaded.
> > > > 
> > > > --------------------------------------------------------------------
> > > > 
> > > > usbcore: registered new interface driver hiddev
> > > > input: Fujitsu Component USB Touch Panel
> > > > as /devices/pci0000:00/0000:00:1a.0/usb3/3-2/3-2:1.0/input/input9
> > > > generic-usb 0003:0430:0501.0002: input: USB HID v1.00 Mouse [Fujitsu
> > > > Component USB Touch Panel] on usb-0000:00:1a.0-2/input0
> > > > usbcore: registered new interface driver usbhid
> > > > usbhid: USB HID core driver
> > > > 
> > > > --------------------------------------------------------------------
> > > > 
> > > > For a long time now, we have been successfully configuring these
> > > > machines using the device node created when this driver is loaded, often
> > > > something like /dev/input/event5 (with a UDEV rule to make the name more
> > > > sensible). In X, we've been using the "evtouch" driver with this device
> > > > node, to great effect.
> > > > 
> > > > However, I am doing a bit of research and experimentation, and what I
> > > > would like to do is write some custom driver code to interface with this
> > > > device, instead of letting usbhid manage it. My question is, where is
> > > > the best place to start?
> > > 
> > > I guess you need to enumerate what deficiencies usbhid has and what
> > > issues you want to solve. That would clear a lot. I think that
> > > completely abandoning HID driver for device that is mostly HID compliant
> > > is not the best idea and you probably want to wire a HID sub-driver that
> > > works in tandem with usbhid.
> > 
> > I think you're absolutely right about a sub-driver of sorts.
> > 
> > Essentially it comes down to this: the touchscreen is being used in
> > hardware running Android, and the Android userspace code expects an
> > input event device to support the BTN_TOUCH ioctl. However, seeing as
> > usbhid binds to this device in a very generic way, it doesn't add the
> > BTN_TOUCH bits, and rightly so. In regular X, the evtouch driver does
> > not require this particular feature, so the device works fine.
> > 
> > HOWEVER, if I remove this check from the Android userspace library tslib
> > (the ioctl query for BTN_TOUCH), it does at least act as a pointer
> > inside Android's display manager, although there is no notion of
> > pressure--it's either 255 or 0 in tslib terms. I'm not entirely sure the
> > device even supports pressure, but that is why I'm researching this
> > project. :)
> > 
> > > > 
> > > > - Since usbhid already recognizes and binds to this device, what code
> > > > can I begin studying to see exactly how it's detecting this and
> > > > formatting input?
> > > 
> > > I guess drivers/hid/hid-input.c is the most interesting one.
> > > 
> > > > 
> > > > - Once usbhid attaches to this device, is the device in some kind of
> > > > lock? Is it possible to simply inject additional features or formatting
> > > > functions, possibly via quirks? (I don't quite understand how to do
> > > > anything with quirks other than blacklist a device).
> > > 
> > > Only one driver can manage a device so once HID claimed it your
> > > standalone driver will not be able to control it. However there is
> > > notion of HID bus drivers (you looked at hid-ntrig - it's one of them)
> > > that allow you to override and/or augment processing done by the default
> > > HID driver.
> > 
> > This is definitely what I'm interested in. I stripped its code down to
> > basically just the probe function. It recognizes my USB PCIID but fails
> > to call hid_parse() with the error -19. I've not been able to lock down
> > where the ll_driver->hid_parse() function is to see exactly what this
> > error might be.
> > 
> > > > 
> > > > - If I want to write a full driver for the device, what source file
> > > > would be best to start from? I've tried hacking usbtouchscreen.c and
> > > > hid-ntrig.c for the last few days to try and get them to bind to the
> > > > device, but neither attempt has seen any success. My hid-ntrig change
> > > > refuses to successfully call hid_parse(), and my usbtouchscreen change
> > > > continually returns some error code in the IRQ callback.
> > > 
> > > Did you add the VID/PID of your device to the blacklist in
> > > drivers/hid/hid-core.c?
> > 
> > Yes, and this does prevent usbhid from picking it up. I can also add a
> > quirk to modprobe.conf dynamically adding the HID_QUIRK_IGNORE quirk to
> > achieve the same effect. In fact, this is necessary for my "hacked"
> > hid-testdriver.c module to even TRY and call the probe function.
> 
> Well, if you add HID_QUIRK_IGNORE then in usbhid_parse:
> 
> 
>         quirks = usbhid_lookup_quirk(le16_to_cpu(dev->descriptor.idVendor),
>                         le16_to_cpu(dev->descriptor.idProduct));
> 
>         if (quirks & HID_QUIRK_IGNORE)
>                 return -ENODEV;
> 
> and -ENODEV is -19 so it is no surprise you are getting -19 from
> hid_parse().
> 
> You need to make sure you are adding entry to
> 
> drivers/hid/hid-core.c:static const struct hid_device_id hid_blacklist[]
> 
> and not to
> 
> drivers/hid/usbhid/hid-quirks.c:static const struct hid_blacklist
> 
> Hmm, I wonder if we should rename the first one to something different,
> like hid_has_custom_driver. Jiri?

WHOA! Now we're cooking! My probe succeeds and now my
event/input_mapping/input_mapped functions all get called!

When driver developers are writing HID glue drivers like this, how is it
you generally determine the contents of your drv_data structure? Via
hardware specs or is there some way to poke at the device via USB and
have it tell you? Perhaps this question is a bit TOO out of line, as I'm
sure that information is available in the standard USB HID
information...

Re: Researching An Experimental Touchscreen Driver

[Dmitry Torokhov]

On Sat, Nov 27, 2010 at 11:12:51PM -0500, Jeremy Moles wrote:
> 
> WHOA! Now we're cooking! My probe succeeds and now my
> event/input_mapping/input_mapped functions all get called!
> 
> When driver developers are writing HID glue drivers like this, how is it
> you generally determine the contents of your drv_data structure? Via
> hardware specs or is there some way to poke at the device via USB and
> have it tell you? Perhaps this question is a bit TOO out of line, as I'm
> sure that information is available in the standard USB HID
> information...
> 

If you are talking about data structures that are accessed via
hig_get_drvdata() and hid_set_drvdata() then it is entirely up to driver
writer to define them. Basically whatever state you need to be able to
handle the device.

-- 
Dmitry

Re: Researching An Experimental Touchscreen Driver

[Dmitry Torokhov]

On Sat, Nov 27, 2010 at 07:07:29PM -0800, Dmitry Torokhov wrote:
> 
> You need to make sure you are adding entry to
> 
> drivers/hid/hid-core.c:static const struct hid_device_id hid_blacklist[]
> 
> and not to
> 
> drivers/hid/usbhid/hid-quirks.c:static const struct hid_blacklist
> 
> Hmm, I wonder if we should rename the first one to something different,
> like hid_has_custom_driver. Jiri?
> 

Something like this one I guess...

-- 
Dmitry


HID: hid-core - rename hid_blacklist to hid_have_special_driver

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

To avoid confusion with hid_blacklist describing various quirks in
usbhid code, let's rename this one.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

 drivers/hid/hid-core.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)


diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index b133d47..8b421e6 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1230,7 +1230,7 @@ void hid_disconnect(struct hid_device *hdev)
 EXPORT_SYMBOL_GPL(hid_disconnect);
 
 /* a list of devices for which there is a specialized driver on HID bus */
-static const struct hid_device_id hid_blacklist[] = {
+static const struct hid_device_id hid_have_special_driver[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_3M, USB_DEVICE_ID_3M1968) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_3M, USB_DEVICE_ID_3M2256) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_WCP32PU) },
@@ -1493,9 +1493,9 @@ static int hid_bus_match(struct device *dev, struct device_driver *drv)
 	if (!hid_match_device(hdev, hdrv))
 		return 0;
 
-	/* generic wants all non-blacklisted */
+	/* generic wants all that don't have specialized driver */
 	if (!strncmp(hdrv->name, "generic-", 8))
-		return !hid_match_id(hdev, hid_blacklist);
+		return !hid_match_id(hdev, hid_have_special_driver);
 
 	return 1;
 }

Re: Researching An Experimental Touchscreen Driver

[Jiri Kosina]

On Sat, 27 Nov 2010, Dmitry Torokhov wrote:

> On Sat, Nov 27, 2010 at 07:07:29PM -0800, Dmitry Torokhov wrote:
> > 
> > You need to make sure you are adding entry to
> > 
> > drivers/hid/hid-core.c:static const struct hid_device_id hid_blacklist[]
> > 
> > and not to
> > 
> > drivers/hid/usbhid/hid-quirks.c:static const struct hid_blacklist
> > 
> > Hmm, I wonder if we should rename the first one to something different,
> > like hid_has_custom_driver. Jiri?
> > 
> 
> Something like this one I guess...
> 
> -- 
> Dmitry
> 
> 
> HID: hid-core - rename hid_blacklist to hid_have_special_driver
> 
> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> 
> To avoid confusion with hid_blacklist describing various quirks in
> usbhid code, let's rename this one.
> 
> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> ---
> 
>  drivers/hid/hid-core.c |    6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> 
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index b133d47..8b421e6 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1230,7 +1230,7 @@ void hid_disconnect(struct hid_device *hdev)
>  EXPORT_SYMBOL_GPL(hid_disconnect);
>  
>  /* a list of devices for which there is a specialized driver on HID bus */
> -static const struct hid_device_id hid_blacklist[] = {
> +static const struct hid_device_id hid_have_special_driver[] = {
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_3M, USB_DEVICE_ID_3M1968) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_3M, USB_DEVICE_ID_3M2256) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_WCP32PU) },
> @@ -1493,9 +1493,9 @@ static int hid_bus_match(struct device *dev, struct device_driver *drv)
>  	if (!hid_match_device(hdev, hdrv))
>  		return 0;
>  
> -	/* generic wants all non-blacklisted */
> +	/* generic wants all that don't have specialized driver */
>  	if (!strncmp(hdrv->name, "generic-", 8))
> -		return !hid_match_id(hdev, hid_blacklist);
> +		return !hid_match_id(hdev, hid_have_special_driver);
>  
>  	return 1;

Hi Dmitry,

yes, this thing definitely needed renaming for quite a some time already.

'hid_have_special_driver' sounds more like a boolean type variable to me, 
but I wasn't able to come up with anything better after thinking about it 
for a few seconds :) so I have applied your version.

Thanks,

-- 
Jiri Kosina
SUSE Labs, Novell Inc.