NetBSD Problem Report #19445

Received: (qmail 9476 invoked by uid 605); 18 Dec 2002 21:54:28 -0000
Message-Id: <200212181954.gBIJsqg00430@vash.cel.plethora.net>
Date: Wed, 18 Dec 2002 13:54:52 -0600 (CST)
From: seebs <seebs@vash.cel.plethora.net>
Sender: gnats-bugs-owner@netbsd.org
Reply-To: seebs@vash.cel.plethora.net
To: gnats-bugs@gnats.netbsd.org
Subject: Griffin Powermate is better off on ugen than uhid
X-Send-Pr-Version: 3.95

>Number:         19445
>Category:       kern
>Synopsis:       Griffin Powermate device is less functional as a mouse.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 18 21:55:00 +0000 2002
>Closed-Date:    Wed May 05 17:04:51 +0000 2010
>Last-Modified:  Wed May 05 17:04:51 +0000 2010
>Originator:     seebs
>Release:        NetBSD 1.6K
>Organization:
>Environment:
System: NetBSD vash.cel.plethora.net 1.6K NetBSD 1.6K (VASH) #0: Wed Dec 18 10:42:37 CST 2002 seebs@vash.cel.plethora.net:/usr/src/sys/arch/i386/compile/VASH i386
Architecture: i386
Machine: i386
>Description:
	The Griffin Powermate is a small gizmo which provides a button, knob,
	and tweakable LED light.  There is a published interface for talking
	to these, and a userland program can talk to it through /dev/ugen?.

	However, if our ugen driver doesn't configure it, it will respond
	to the probe for uhid, and become a one-button mouse with only X, not
	Y, movement.  This is useless.

>How-To-Repeat:
	Hook up a Powermate.

>Fix:
	Add this line to GENERIC:
	ugen*   at uhub? vendor 0x077d product 0x0410

	And remove the #if 0 in ugen.c that prevents matches like this from
	working:

Index: ugen.c
===================================================================
RCS file: /cvsroot/syssrc/sys/dev/usb/ugen.c,v
retrieving revision 1.63
diff -c -r1.63 ugen.c
*** ugen.c	2002/11/26 18:49:48	1.63
--- ugen.c	2002/12/18 21:53:46
***************
*** 189,198 ****
  {
  	USB_MATCH_START(ugen, uaa);

- #if 0
  	if (uaa->matchlvl)
  		return (uaa->matchlvl);
- #endif
  	if (uaa->usegeneric)
  		return (UMATCH_GENERIC);
  	else
--- 189,196 ----

	Note that this latter change is almost certainly a good idea whether
	or not we add the line for the powermate to GENERIC; someone who
	doesn't know it's there has no way of knowing why his attempt to
	probe a device with ugen is failing.

>Release-Note:
>Audit-Trail:

From: Dave Sainty <dave@dtsp.co.nz>
To: seebs@plethora.net (Peter Seebach)
Cc: gnats-bugs@gnats.netbsd.org, augustss@netbsd.org, dave@dtsp.co.nz
Subject: Re: kern/19445: Griffin Powermate is better off on ugen than uhid 
Date: Thu, 26 Dec 2002 22:29:38 +1300

 Peter Seebach writes:

 > In message <200212260630.gBQ6Twk24766@guild.plethora.net>, Dave Sainty writes:
 > >If it's a HID device, it's correct for it to attach as a uhid device.
 > 
 > It's not, though.  It's a device which *can* probe as a HID, but which
 > doesn't support its full functionality in that mode.  (Silly, I know.)

 That seems strange...  What is this thing actually for?

 > >What is treating it as a mouse though?  Is it attaching as a ums(4)
 > >device?  Perhaps something should be done to prevent that?
 > 
 > That's the thing; if you don't attach to it with ugen, we ask it if maybe
 > it's a mouse, and it assumes we have no driver, and goes into dumb mouse
 > mode.

 Hmmm, I think that means the device has two interfaces, a HID and a
 specialist interface.  The device probably supports both interfaces
 simultaneously (rather than switching to a different mode).  But the
 ugen driver will only attach if no interface was supported by any
 driver.

 If I'm reading the code right, you can't even explicitly attach ugen
 and another driver to a single device.  Presumably the rationale is
 that ugen is designed to be all-or-nothing, so ugen as it stands could
 walk all over then other device driver if two has access to the same
 device.

 So, the only way to attach both uhid and something else is to write a
 device driver that knows all about the "Griffin Powermate".  Might be
 worthwhile if this is a widely used device.  Is it?

 Otherwise doing what you did (explicit device binding by
 product/vendor) seems exactly right...

 But I think enabling the matchlvl code will potentially cause a
 problem.  The code where it sits will allow ugen to attach to a device
 (by explicit rule) even if another driver is attached.  Meaning 'ugen'
 could trample over another drivers interface.  I guess maybe that's
 why it's disabled.

 Is that right Lennart?

 Cheers,

 Dave

From: seebs@plethora.net (Peter Seebach)
To: Dave Sainty <dave@dtsp.co.nz>
Cc: gnats-bugs@gnats.netbsd.org, augustss@netbsd.org
Subject: Re: kern/19445: Griffin Powermate is better off on ugen than uhid 
Date: Thu, 26 Dec 2002 03:38:53 -0600

 In message <200212260930.gBQ9UT713070@herd.plethora.net>, Dave Sainty writes:
 >Peter Seebach writes:
 >> It's not, though.  It's a device which *can* probe as a HID, but which
 >> doesn't support its full functionality in that mode.  (Silly, I know.)

 >That seems strange...  What is this thing actually for?

 Er.  It's a gizmo!

 It's sold as a volume knob.  Basically, it's a knob that recognizes "clicks"
 and also supports an LED which can be set to a given brightness or to pulse.

 >Hmmm, I think that means the device has two interfaces, a HID and a
 >specialist interface.  The device probably supports both interfaces
 >simultaneously (rather than switching to a different mode).  But the
 >ugen driver will only attach if no interface was supported by any
 >driver.

 I think that may be right.

 >So, the only way to attach both uhid and something else is to write a
 >device driver that knows all about the "Griffin Powermate".  Might be
 >worthwhile if this is a widely used device.  Is it?

 I don't think it's all that widely used, but mostly, I can't see any advantage
 to the driver; everything it would do can be done by a userland program
 attached to ugen.

 -s

From: Dave Sainty <dave@dtsp.co.nz>
To: seebs@plethora.net (Peter Seebach)
Cc: gnats-bugs@gnats.netbsd.org, augustss@netbsd.org, dave@dtsp.co.nz
Subject: Re: kern/19445: Griffin Powermate is better off on ugen than uhid 
Date: Thu, 26 Dec 2002 23:06:47 +1300

 Peter Seebach writes:

 > >That seems strange...  What is this thing actually for?
 > 
 > Er.  It's a gizmo!
 > 
 > It's sold as a volume knob.  Basically, it's a knob that recognizes "clicks"
 > and also supports an LED which can be set to a given brightness or to pulse.

 Heh :)  Doesn't sound much like a mouse to me...  But it does sounds
 very much like a human interface...  I wonder why they decided to come
 up with their own non-HID protocol...

 > >So, the only way to attach both uhid and something else is to write a
 > >device driver that knows all about the "Griffin Powermate".  Might be
 > >worthwhile if this is a widely used device.  Is it?
 > 
 > I don't think it's all that widely used, but mostly, I can't see any
 > advantage to the driver; everything it would do can be done by a
 > userland program attached to ugen.

 The only advantages would be through having a secondary HID interface
 to the device too, so standard tools and programs could also talk to
 the device without having to know how to talk its other proprietary
 protocol.

 Generally speaking, that's a good thing.  But perhaps in this case it
 wouldn't be awfully useful :)  I do agree that a new device driver for
 it would be fairly overkill...

 Cheers,

 Dave

From: seebs@plethora.net (Peter Seebach)
To: Dave Sainty <dave@dtsp.co.nz>
Cc: gnats-bugs@gnats.netbsd.org, augustss@netbsd.org
Subject: Re: kern/19445: Griffin Powermate is better off on ugen than uhid 
Date: Thu, 26 Dec 2002 12:44:04 -0600

 In message <200212261007.gBQA71713157@herd.plethora.net>, Dave Sainty writes:
 >Heh :)  Doesn't sound much like a mouse to me...  But it does sounds
 >very much like a human interface...  I wonder why they decided to come
 >up with their own non-HID protocol...

 Dunno; you'd have to ask them.  I think it may have been a desire to have it
 do *something* on a system with no drivers for it.

 -s

From: Lennart Augustsson <lennart@augustsson.net>
To: Dave Sainty <dave@dtsp.co.nz>
Cc: seebs@plethora.net (Peter Seebach), gnats-bugs@gnats.netbsd.org,
  augustss@netbsd.org
Subject: Re: kern/19445: Griffin Powermate is better off on ugen than uhid 
Date: Fri, 27 Dec 2002 13:17:50 +0100

 On Thursday, Dec 26, 2002, at 10:29 Europe/Stockholm, Dave Sainty wrote:
 >
 > But I think enabling the matchlvl code will potentially cause a
 > problem.  The code where it sits will allow ugen to attach to a device
 > (by explicit rule) even if another driver is attached.  Meaning 'ugen'
 > could trample over another drivers interface.  I guess maybe that's
 > why it's disabled.
 >
 > Is that right Lennart?

 Well, I didn't enable it because I was a bit of a coward.  I think it 
 can be
 enabled without any ill effects.

 	-- Lennart


From: Lennart Augustsson <lennart@augustsson.net>
To: seebs@plethora.net (Peter Seebach)
Cc: Dave Sainty <dave@dtsp.co.nz>, gnats-bugs@gnats.netbsd.org,
  augustss@netbsd.org
Subject: Re: kern/19445: Griffin Powermate is better off on ugen than uhid 
Date: Fri, 27 Dec 2002 13:22:31 +0100

 As far as I can tell the device is perfect for just being a HID device.
 They way they did it looks like pure laziness to me.

 	-- Lennart

 On Thursday, Dec 26, 2002, at 19:44 Europe/Stockholm, Peter Seebach 
 wrote:

 > In message <200212261007.gBQA71713157@herd.plethora.net>, Dave Sainty 
 > writes:
 >> Heh :)  Doesn't sound much like a mouse to me...  But it does sounds
 >> very much like a human interface...  I wonder why they decided to come
 >> up with their own non-HID protocol...
 >
 > Dunno; you'd have to ask them.  I think it may have been a desire to 
 > have it
 > do *something* on a system with no drivers for it.
 >
 > -s
 >


From: seebs@plethora.net (Peter Seebach)
To: Lennart Augustsson <lennart@augustsson.net>
Cc: Dave Sainty <dave@dtsp.co.nz>, gnats-bugs@gnats.netbsd.org,
  augustss@netbsd.org
Subject: Re: kern/19445: Griffin Powermate is better off on ugen than uhid 
Date: Fri, 27 Dec 2002 11:51:29 -0600

 In message <DEF1DBF1-1995-11D7-847E-0003936B1CA4@augustsson.net>, Lennart Augus
 tsson writes:
 >As far as I can tell the device is perfect for just being a HID device.
 >They way they did it looks like pure laziness to me.

 It probably is - unfortunately, they did it this way, so we can't easily
 outsmart them.  :(

 -s
From: "Jonathan A. Kollasch" <jakllsch@kollasch.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: PR/19445
Date: Sun, 27 Dec 2009 15:52:09 +0000

 It seems to me like the easiest thing to do would be to not allow this
 device to attach as a ums(4) and instead treat it as a uhid(4).  This
 may be sub-optimal, but it would at least allow the device to be used
 in a not-unexpected way without the trouble of extending wscons and
 writing a device-specific driver.

From: "Jonathan A. Kollasch" <jakllsch@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/19445 CVS commit: src/sys/dev/usb
Date: Tue, 12 Jan 2010 16:18:59 +0000

 Module Name:	src
 Committed By:	jakllsch
 Date:		Tue Jan 12 16:18:59 UTC 2010

 Modified Files:
 	src/sys/dev/usb: ums.c

 Log Message:
 Avoid treating the Griffin PowerMate knob as a ums(4).
 Should fix PR/19445.


 To generate a diff of this commit:
 cvs rdiff -u -r1.78 -r1.79 src/sys/dev/usb/ums.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->feedback
State-Changed-By: jakllsch@NetBSD.org
State-Changed-When: Wed, 05 May 2010 17:02:15 +0000
State-Changed-Why:
This may be fixed now.


State-Changed-From-To: feedback->closed
State-Changed-By: jakllsch@NetBSD.org
State-Changed-When: Wed, 05 May 2010 17:04:51 +0000
State-Changed-Why:
feedback bounced, believed fixed.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.