[PATCH] hid: ignore all recent SoundGraph iMON devices

[PATCH] hid: ignore all recent SoundGraph iMON devices

[Jarod Wilson]

After some inspection of the Windows iMON driver, several additional
device IDs were added to the lirc_imon driver. At least a few of these
have been seen in the wild, and require manual quirking to keep the
usbhid driver from binding to them. Rather than list out every single
device, ignore the entire device ID range, 0x0034 - 0x0046. Some of
these may not advertise themselves as HID devices, but no harm done to
such devices anyway. Does the right thing in brief testing w/my 0x0045
device.

Signed-off-by: Jarod Wilson <jarod@redhat.com>

---
 drivers/hid/hid-core.c |   10 +++++-----
 drivers/hid/hid-ids.h  |    7 ++-----
 2 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 5eb10c2..18bf803 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1623,11 +1623,6 @@ static const struct hid_device_id hid_ignore_list[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_PANJIT, 0x0003) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_PANJIT, 0x0004) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_POWERCOM, USB_DEVICE_ID_POWERCOM_UPS) },
-	{ HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD) },
-	{ HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD2) },
-	{ HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD3) },
-	{ HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD4) },
-	{ HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD5) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_TENX, USB_DEVICE_ID_TENX_IBUDDY1) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_TENX, USB_DEVICE_ID_TENX_IBUDDY2) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_LABPRO) },
@@ -1694,6 +1689,11 @@ static bool hid_ignore(struct hid_device *hdev)
 				hdev->product <= USB_DEVICE_ID_LOGITECH_HARMONY_LAST)
 			return true;
 		break;
+	case USB_VENDOR_ID_SOUNDGRAPH:
+		if (hdev->product >= USB_DEVICE_ID_SOUNDGRAPH_IMON_FIRST &&
+		    hdev->product <= USB_DEVICE_ID_SOUNDGRAPH_IMON_LAST)
+			return true;
+		break;
 	}
 
 	if (hdev->type == HID_TYPE_USBMOUSE &&
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 6301010..989a3ba 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -376,11 +376,8 @@
 #define USB_DEVICE_ID_SONY_PS3_CONTROLLER	0x0268
 
 #define USB_VENDOR_ID_SOUNDGRAPH	0x15c2
-#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD	0x0038
-#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD2	0x0036
-#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD3	0x0034
-#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD4	0x0044
-#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD5	0x0045
+#define USB_DEVICE_ID_SOUNDGRAPH_IMON_FIRST	0x0034
+#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LAST	0x0046
 
 #define USB_VENDOR_ID_SUN		0x0430
 #define USB_DEVICE_ID_RARITAN_KVM_DONGLE	0xcdab

-- 
Jarod Wilson
jarod@redhat.com

Re: [PATCH] hid: ignore all recent SoundGraph iMON devices

[Anssi Hannula]

Jarod Wilson wrote:
> After some inspection of the Windows iMON driver, several additional
> device IDs were added to the lirc_imon driver. At least a few of these
> have been seen in the wild, and require manual quirking to keep the
> usbhid driver from binding to them. Rather than list out every single
> device, ignore the entire device ID range, 0x0034 - 0x0046. Some of
> these may not advertise themselves as HID devices, but no harm done to
> such devices anyway. Does the right thing in brief testing w/my 0x0045
> device.

I'm not sure this is a good idea. I have a 0x0038 device and I'm
developing a proper HID driver for it. If and when I'll submit it for
kernel inclusion, this kind of ID range blacklisting may get ugly.

-- 
Anssi Hannula

Re: [PATCH] hid: ignore all recent SoundGraph iMON devices

[Jarod Wilson]

On Friday 31 July 2009 14:41:38 Anssi Hannula wrote:
> Jarod Wilson wrote:
> > After some inspection of the Windows iMON driver, several additional
> > device IDs were added to the lirc_imon driver. At least a few of these
> > have been seen in the wild, and require manual quirking to keep the
> > usbhid driver from binding to them. Rather than list out every single
> > device, ignore the entire device ID range, 0x0034 - 0x0046. Some of
> > these may not advertise themselves as HID devices, but no harm done to
> > such devices anyway. Does the right thing in brief testing w/my 0x0045
> > device.
> 
> I'm not sure this is a good idea. I have a 0x0038 device and I'm
> developing a proper HID driver for it. If and when I'll submit it for
> kernel inclusion, this kind of ID range blacklisting may get ugly.

Erm, there's already a full driver for it though, and its already in
the ignore list...

-- 
Jarod Wilson
jarod@redhat.com

Re: [PATCH] hid: ignore all recent SoundGraph iMON devices

[Jarod Wilson]

On Friday 31 July 2009 15:00:28 Jarod Wilson wrote:
> On Friday 31 July 2009 14:41:38 Anssi Hannula wrote:
> > Jarod Wilson wrote:
> > > After some inspection of the Windows iMON driver, several additional
> > > device IDs were added to the lirc_imon driver. At least a few of these
> > > have been seen in the wild, and require manual quirking to keep the
> > > usbhid driver from binding to them. Rather than list out every single
> > > device, ignore the entire device ID range, 0x0034 - 0x0046. Some of
> > > these may not advertise themselves as HID devices, but no harm done to
> > > such devices anyway. Does the right thing in brief testing w/my 0x0045
> > > device.
> > 
> > I'm not sure this is a good idea. I have a 0x0038 device and I'm
> > developing a proper HID driver for it. If and when I'll submit it for
> > kernel inclusion, this kind of ID range blacklisting may get ugly.
> 
> Erm, there's already a full driver for it though, and its already in
> the ignore list...

Also, out of curiosity, what does a "proper HID driver for it" look
like and/or do that the latest lirc_imon doesn't? We're already doing
input layer stuff with the mouse mode and mouse buttons, and looking to
further extend that, potentially making the driver pure input layer,
but still usable with the lirc devinput userspace driver.

-- 
Jarod Wilson
jarod@redhat.com

Re: [PATCH] hid: ignore all recent SoundGraph iMON devices

[Anssi Hannula]

Jarod Wilson wrote:
> On Friday 31 July 2009 15:00:28 Jarod Wilson wrote:
>> On Friday 31 July 2009 14:41:38 Anssi Hannula wrote:
>>> Jarod Wilson wrote:
>>>> After some inspection of the Windows iMON driver, several additional
>>>> device IDs were added to the lirc_imon driver. At least a few of these
>>>> have been seen in the wild, and require manual quirking to keep the
>>>> usbhid driver from binding to them. Rather than list out every single
>>>> device, ignore the entire device ID range, 0x0034 - 0x0046. Some of
>>>> these may not advertise themselves as HID devices, but no harm done to
>>>> such devices anyway. Does the right thing in brief testing w/my 0x0045
>>>> device.
>>> I'm not sure this is a good idea. I have a 0x0038 device and I'm
>>> developing a proper HID driver for it. If and when I'll submit it for
>>> kernel inclusion, this kind of ID range blacklisting may get ugly.
>> Erm, there's already a full driver for it though, and its already in
>> the ignore list...
> 
> Also, out of curiosity, what does a "proper HID driver for it" look
> like and/or do that the latest lirc_imon doesn't?

Well, I didn't want to use 3rdparty drivers with my device.

Anyways.. my driver implements a hid_driver (see /drivers/hid/hid-*.c),
and sets a raw_event callback for the non-standard-hid-input events of
the 2nd interface and emits input layer events for those. The device
uses standard HID input protocol in first interface, so my driver
doesn't touch that at all and lets the general hid code handle that
(some remote control buttons are passed by that). LCD write packets are
queued via usbhid_submit_report(). The driver also has code for
registering the LCD as standard framebuffer device and allowing led
subsystem access to the icons, though I'm not sure yet if those should
be there (1-bit framebuffers may not be supported by much userspace
code, haven't checked yet; having the icons registered for led subsystem
allows triggers and handling via /sys, but I'm not sure if that is
useful for these kind of icons).

> We're already doing
> input layer stuff with the mouse mode and mouse buttons, and looking to
> further extend that, potentially making the driver pure input layer,
> but still usable with the lirc devinput userspace driver.

Oh, this sounds to me like active work getting lirc into upstreamable
condition :)  Is it that?

More incentive for me to not submit my driver, then.

-- 
Anssi Hannula

Re: [PATCH] hid: ignore all recent SoundGraph iMON devices

[Jarod Wilson]

On Monday 03 August 2009 09:05:28 Anssi Hannula wrote:
> Jarod Wilson wrote:
> > On Friday 31 July 2009 15:00:28 Jarod Wilson wrote:
> >> On Friday 31 July 2009 14:41:38 Anssi Hannula wrote:
> >>> Jarod Wilson wrote:
> >>>> After some inspection of the Windows iMON driver, several additional
> >>>> device IDs were added to the lirc_imon driver. At least a few of these
> >>>> have been seen in the wild, and require manual quirking to keep the
> >>>> usbhid driver from binding to them. Rather than list out every single
> >>>> device, ignore the entire device ID range, 0x0034 - 0x0046. Some of
> >>>> these may not advertise themselves as HID devices, but no harm done to
> >>>> such devices anyway. Does the right thing in brief testing w/my 0x0045
> >>>> device.
> >>> I'm not sure this is a good idea. I have a 0x0038 device and I'm
> >>> developing a proper HID driver for it. If and when I'll submit it for
> >>> kernel inclusion, this kind of ID range blacklisting may get ugly.
> >> Erm, there's already a full driver for it though, and its already in
> >> the ignore list...
> > 
> > Also, out of curiosity, what does a "proper HID driver for it" look
> > like and/or do that the latest lirc_imon doesn't?
> 
> Well, I didn't want to use 3rdparty drivers with my device.
> 
> Anyways.. my driver implements a hid_driver (see /drivers/hid/hid-*.c),
> and sets a raw_event callback for the non-standard-hid-input events of
> the 2nd interface and emits input layer events for those. The device
> uses standard HID input protocol in first interface, so my driver
> doesn't touch that at all and lets the general hid code handle that
> (some remote control buttons are passed by that).

Yeah, a lot of this sounds like what Rene Harder and I have discussed
doing over on the lirc list. We're both a bit tied up with other things
right now though, so its not really progressed in a few weeks, since
we merged a bunch of touchscreen and mouse input device support a bit
ago.

> LCD write packets are
> queued via usbhid_submit_report(). The driver also has code for
> registering the LCD as standard framebuffer device and allowing led
> subsystem access to the icons, though I'm not sure yet if those should
> be there (1-bit framebuffers may not be supported by much userspace
> code, haven't checked yet; having the icons registered for led subsystem
> allows triggers and handling via /sys, but I'm not sure if that is
> useful for these kind of icons).

So is the LCD usable with, say, lcdproc? I hadn't ever really thought
about using mine any other way (I have an 0045 device myself, its an
Antec Veris Premiere, which is a rebranded iMON UltraBay).

> > We're already doing
> > input layer stuff with the mouse mode and mouse buttons, and looking to
> > further extend that, potentially making the driver pure input layer,
> > but still usable with the lirc devinput userspace driver.
> 
> Oh, this sounds to me like active work getting lirc into upstreamable
> condition :)  Is it that?

It is. I'm hoping to send another submission for upstream review Real
Soon Now. lirc_imon, lirc_mceusb, lirc_serial and lirc_i2c are all in
pretty good shape now, will probably limit the submission to those
four this time around...

> More incentive for me to not submit my driver, then.

More than anything, I'd love to see any worthwhile additions in your
work merged into the lirc_imon driver.

-- 
Jarod Wilson
jarod@redhat.com

Re: [PATCH] hid: ignore all recent SoundGraph iMON devices

[Anssi Hannula]

Jarod Wilson wrote:
> On Monday 03 August 2009 09:05:28 Anssi Hannula wrote:
>> Jarod Wilson wrote:
>>> Also, out of curiosity, what does a "proper HID driver for it" look
>>> like and/or do that the latest lirc_imon doesn't?
>> Well, I didn't want to use 3rdparty drivers with my device.
>>
>> Anyways.. my driver implements a hid_driver (see /drivers/hid/hid-*.c),
>> and sets a raw_event callback for the non-standard-hid-input events of
>> the 2nd interface and emits input layer events for those. The device
>> uses standard HID input protocol in first interface, so my driver
>> doesn't touch that at all and lets the general hid code handle that
>> (some remote control buttons are passed by that).
> 
> Yeah, a lot of this sounds like what Rene Harder and I have discussed
> doing over on the lirc list. We're both a bit tied up with other things
> right now though, so its not really progressed in a few weeks, since
> we merged a bunch of touchscreen and mouse input device support a bit
> ago.
> 
>> LCD write packets are
>> queued via usbhid_submit_report(). The driver also has code for
>> registering the LCD as standard framebuffer device and allowing led
>> subsystem access to the icons, though I'm not sure yet if those should
>> be there (1-bit framebuffers may not be supported by much userspace
>> code, haven't checked yet; having the icons registered for led subsystem
>> allows triggers and handling via /sys, but I'm not sure if that is
>> useful for these kind of icons).
> 
> So is the LCD usable with, say, lcdproc? I hadn't ever really thought
> about using mine any other way (I have an 0045 device myself, its an
> Antec Veris Premiere, which is a rebranded iMON UltraBay).

Well, these can be additional to /dev/lcd*, not necessarily replacing it.

I also see that currently the LCD handling code is somewhat duplicated
at least with lcdproc and VDR imon
(http://projects.vdr-developer.org/wiki/plg-imonlcd), haven't searched
if there are other projects doin the same. Maybe an userspace library
would be better suited for this, though.

>>> We're already doing
>>> input layer stuff with the mouse mode and mouse buttons, and looking to
>>> further extend that, potentially making the driver pure input layer,
>>> but still usable with the lirc devinput userspace driver.
>> Oh, this sounds to me like active work getting lirc into upstreamable
>> condition :)  Is it that?
> 
> It is. I'm hoping to send another submission for upstream review Real
> Soon Now. lirc_imon, lirc_mceusb, lirc_serial and lirc_i2c are all in
> pretty good shape now, will probably limit the submission to those
> four this time around...

Great :)

>> More incentive for me to not submit my driver, then.
> 
> More than anything, I'd love to see any worthwhile additions in your
> work merged into the lirc_imon driver.

I'll see. I have so much other work to do currently, that it may not
happen soon, though.

-- 
Anssi Hannula

Re: [PATCH] hid: ignore all recent SoundGraph iMON devices

[Jiri Kosina]

On Fri, 31 Jul 2009, Jarod Wilson wrote:

> After some inspection of the Windows iMON driver, several additional
> device IDs were added to the lirc_imon driver. At least a few of these
> have been seen in the wild, and require manual quirking to keep the
> usbhid driver from binding to them. Rather than list out every single
> device, ignore the entire device ID range, 0x0034 - 0x0046. Some of
> these may not advertise themselves as HID devices, but no harm done to
> such devices anyway. Does the right thing in brief testing w/my 0x0045
> device.
> 
> Signed-off-by: Jarod Wilson <jarod@redhat.com>
> 
> ---
>  drivers/hid/hid-core.c |   10 +++++-----
>  drivers/hid/hid-ids.h  |    7 ++-----
>  2 files changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 5eb10c2..18bf803 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1623,11 +1623,6 @@ static const struct hid_device_id hid_ignore_list[] = {
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_PANJIT, 0x0003) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_PANJIT, 0x0004) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_POWERCOM, USB_DEVICE_ID_POWERCOM_UPS) },
> -	{ HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD) },
> -	{ HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD2) },
> -	{ HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD3) },
> -	{ HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD4) },
> -	{ HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD5) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_TENX, USB_DEVICE_ID_TENX_IBUDDY1) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_TENX, USB_DEVICE_ID_TENX_IBUDDY2) },
>  	{ HID_USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_LABPRO) },
> @@ -1694,6 +1689,11 @@ static bool hid_ignore(struct hid_device *hdev)
>  				hdev->product <= USB_DEVICE_ID_LOGITECH_HARMONY_LAST)
>  			return true;
>  		break;
> +	case USB_VENDOR_ID_SOUNDGRAPH:
> +		if (hdev->product >= USB_DEVICE_ID_SOUNDGRAPH_IMON_FIRST &&
> +		    hdev->product <= USB_DEVICE_ID_SOUNDGRAPH_IMON_LAST)
> +			return true;
> +		break;
>  	}
>  
>  	if (hdev->type == HID_TYPE_USBMOUSE &&
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 6301010..989a3ba 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -376,11 +376,8 @@
>  #define USB_DEVICE_ID_SONY_PS3_CONTROLLER	0x0268
>  
>  #define USB_VENDOR_ID_SOUNDGRAPH	0x15c2
> -#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD	0x0038
> -#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD2	0x0036
> -#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD3	0x0034
> -#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD4	0x0044
> -#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD5	0x0045
> +#define USB_DEVICE_ID_SOUNDGRAPH_IMON_FIRST	0x0034
> +#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LAST	0x0046
>  
>  #define USB_VENDOR_ID_SUN		0x0430
>  #define USB_DEVICE_ID_RARITAN_KVM_DONGLE	0xcdab

[ sorry for late reply, have been away for quite some time ]

So after reading the thread, I understand that Anssi will rather submit 
his changes through lirc project, and has therefore no objections to 
applying Jarod's patch, right?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] hid: ignore all recent SoundGraph iMON devices

[Anssi Hannula]

Jiri Kosina wrote:
> On Fri, 31 Jul 2009, Jarod Wilson wrote:
> 
>> After some inspection of the Windows iMON driver, several additional
>> device IDs were added to the lirc_imon driver. At least a few of these
>> have been seen in the wild, and require manual quirking to keep the
>> usbhid driver from binding to them. Rather than list out every single
>> device, ignore the entire device ID range, 0x0034 - 0x0046. Some of
>> these may not advertise themselves as HID devices, but no harm done to
>> such devices anyway. Does the right thing in brief testing w/my 0x0045
>> device.
>>
>> Signed-off-by: Jarod Wilson <jarod@redhat.com>
>>
>> ---
>>  drivers/hid/hid-core.c |   10 +++++-----
>>  drivers/hid/hid-ids.h  |    7 ++-----
>>  2 files changed, 7 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
>> index 5eb10c2..18bf803 100644
>> --- a/drivers/hid/hid-core.c
>> +++ b/drivers/hid/hid-core.c
>> @@ -1623,11 +1623,6 @@ static const struct hid_device_id hid_ignore_list[] = {
>>  	{ HID_USB_DEVICE(USB_VENDOR_ID_PANJIT, 0x0003) },
>>  	{ HID_USB_DEVICE(USB_VENDOR_ID_PANJIT, 0x0004) },
>>  	{ HID_USB_DEVICE(USB_VENDOR_ID_POWERCOM, USB_DEVICE_ID_POWERCOM_UPS) },
>> -	{ HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD) },
>> -	{ HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD2) },
>> -	{ HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD3) },
>> -	{ HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD4) },
>> -	{ HID_USB_DEVICE(USB_VENDOR_ID_SOUNDGRAPH, USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD5) },
>>  	{ HID_USB_DEVICE(USB_VENDOR_ID_TENX, USB_DEVICE_ID_TENX_IBUDDY1) },
>>  	{ HID_USB_DEVICE(USB_VENDOR_ID_TENX, USB_DEVICE_ID_TENX_IBUDDY2) },
>>  	{ HID_USB_DEVICE(USB_VENDOR_ID_VERNIER, USB_DEVICE_ID_VERNIER_LABPRO) },
>> @@ -1694,6 +1689,11 @@ static bool hid_ignore(struct hid_device *hdev)
>>  				hdev->product <= USB_DEVICE_ID_LOGITECH_HARMONY_LAST)
>>  			return true;
>>  		break;
>> +	case USB_VENDOR_ID_SOUNDGRAPH:
>> +		if (hdev->product >= USB_DEVICE_ID_SOUNDGRAPH_IMON_FIRST &&
>> +		    hdev->product <= USB_DEVICE_ID_SOUNDGRAPH_IMON_LAST)
>> +			return true;
>> +		break;
>>  	}
>>  
>>  	if (hdev->type == HID_TYPE_USBMOUSE &&
>> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
>> index 6301010..989a3ba 100644
>> --- a/drivers/hid/hid-ids.h
>> +++ b/drivers/hid/hid-ids.h
>> @@ -376,11 +376,8 @@
>>  #define USB_DEVICE_ID_SONY_PS3_CONTROLLER	0x0268
>>  
>>  #define USB_VENDOR_ID_SOUNDGRAPH	0x15c2
>> -#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD	0x0038
>> -#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD2	0x0036
>> -#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD3	0x0034
>> -#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD4	0x0044
>> -#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LCD5	0x0045
>> +#define USB_DEVICE_ID_SOUNDGRAPH_IMON_FIRST	0x0034
>> +#define USB_DEVICE_ID_SOUNDGRAPH_IMON_LAST	0x0046
>>  
>>  #define USB_VENDOR_ID_SUN		0x0430
>>  #define USB_DEVICE_ID_RARITAN_KVM_DONGLE	0xcdab
> 
> [ sorry for late reply, have been away for quite some time ]
> 
> So after reading the thread, I understand that Anssi will rather submit 
> his changes through lirc project, and has therefore no objections to 
> applying Jarod's patch, right?

Yes.

-- 
Anssi Hannula

Re: [PATCH] hid: ignore all recent SoundGraph iMON devices

[Jarod Wilson]

On 8/3/09 9:42 AM, Anssi Hannula wrote:
>>>> We're already doing
>>>> >>>  input layer stuff with the mouse mode and mouse buttons, and looking to
>>>> >>>  further extend that, potentially making the driver pure input layer,
>>>> >>>  but still usable with the lirc devinput userspace driver.
>>> >>  Oh, this sounds to me like active work getting lirc into upstreamable
>>> >>  condition:)   Is it that?
>> >
>> >  It is. I'm hoping to send another submission for upstream review Real
>> >  Soon Now. lirc_imon, lirc_mceusb, lirc_serial and lirc_i2c are all in
>> >  pretty good shape now, will probably limit the submission to those
>> >  four this time around...
> Great:)

With luck, this submission will finally go out tonight or tomorrow. I've 
got a 99% functional pure input layer imon driver implementation 
together now that'll be included -- it'll be the default mode for imon 
devices that do onboard decoding, with a modparam that can be used to 
fall back to "classic" lirc mode. Just need to do a bit of final testing 
and code cleanup.

-- 
Jarod Wilson
jarod@redhat.com