From vsu@altlinux.ru Tue Apr 22 16:39:58 2003
Return-Path: <vsu@altlinux.ru>
Received: from mail.mivlgu.ru (mivlgu.ru [81.18.140.87]) by
	matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h3MEdw615608 for
	<kern@sibbald.com>; Tue, 22 Apr 2003 16:39:58 +0200
Received: by mail.mivlgu.ru (Postfix, from userid 112) id 5667E817DD; Tue,
	22 Apr 2003 18:39:53 +0400 (MSD)
Received: from vcserver.mivlgu.local (vcserver.mivlgu.local
	[192.168.1.251]) by mail.mivlgu.ru (Postfix) with SMTP id 0D7B5817DD; Tue,
	22 Apr 2003 18:39:44 +0400 (MSD)
Date: Tue, 22 Apr 2003 18:39:39 +0400
From: Sergey Vlasov <vsu@altlinux.ru>
To: stewart@wetlogic.net
Cc: stewart@inverse.wetlogic.net, kern@sibbald.com, vojtech@ucw.cz
Subject: Re: [Fwd: [Apcupsd-users] Success - APC BackUPS CS 500 shutdown
	over USB]
Message-Id: <20030422183939.08cd1c13.vsu@altlinux.ru>
In-Reply-To: <E194m2k-0005jB-00@inverse.wetlogic.net>
References: <1050086110.13768.163.camel@rufus>
	 <E194m2k-0005jB-00@inverse.wetlogic.net>
X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i586-alt-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.rPW3CATQ/UTztX"
X-Annoyance-Filter-Junk-Probability: 0.5
X-Annoyance-Filter-Classification: Mail

--=.rPW3CATQ/UTztX
Content-Type: multipart/mixed;
 boundary="Multipart_Tue__22_Apr_2003_18:39:39_+0400_083029a8"


--Multipart_Tue__22_Apr_2003_18:39:39_+0400_083029a8
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Sun, 13 Apr 2003 11:17:30 -0700
Paul Stewart <stewart@inverse.wetlogic.net> wrote:

> I think it is definitely worth putting this in as a quirk.  I know for a
> fact that the MGE UPSes work fine without this patch, but works only after
> a long delay (4 seconds or so) with this patch.  I'm guessing that this
> may be a more substantial problem with other HID devices -- note that
> this function is used with all sorts of devices.
> 
> I agree -- from reading the spec, that the current code is wrong -- there
> is a hard-coded "report->id | 0x200" there that should really be 0x200 for 
> Output and 0x300 for feature reports (now that we realize that Feature 
> reports are settable too).  However, the mode of access in the patch  
> looks nothing at all like the spec, and more like a mirror image of the 
> interrupt transfer.  The prepended report ID byte looks to be a 
> requirement specific to APC UPSes and could easily wreak havoc with other
> devices.  This is why I suggest the patch be re-submitted as a quirk:
> 
>    - Add a new HID_QUIRK_ to hid.h
>    - Add the vendor and device IDs to hid_blacklist, with this new
>      quirk.
>    - Make the changes in the patch conditional on 
> 	(hid->quirks & HID_QUIRK_WEIRD_SETREPORT) != 0
> 
> It would be nice to fix the 0x200 issue while you're in that part of the
> code.  I'd have written the patch myself, but I don't have the vendor/device 
> IDs in question.  This patch should appply cleanly on top of the other 
> changes (I think) I have in the queue WRT HID collections.  Thanks for the
> good work.

(Sorry for the delay - I was busy with other things)

OK, I did this (added a quirk and fixed the report type problem); it
works here, but I have only one USB device - the UPS (APC Back-UPS CS
500).

I have named the device ID USB_DEVICE_ID_APC_UPS_0002, because this
identifier seems to be used for most of the APC USB UPSes (in fact,
all hid-ups report files from apcupsd have this ID). Hope they all
behave the same way (otherwise the code in hid-core.c will need to be
extended to use more fields for matching).

--Multipart_Tue__22_Apr_2003_18:39:39_+0400_083029a8
Content-Type: application/octet-stream;
 name="linux-2.4.20-alt-apc_usb_ups.patch"
Content-Disposition: attachment;
 filename="linux-2.4.20-alt-apc_usb_ups.patch"
Content-Transfer-Encoding: base64

LS0tIGxpbnV4LTIuNC4yMC9kcml2ZXJzL3VzYi9oaWQtY29yZS5jLmFsdC1hcGNfdXNiX3Vwcwky
MDAzLTA0LTIxIDE5OjM5OjI3ICswNDAwCisrKyBsaW51eC0yLjQuMjAvZHJpdmVycy91c2IvaGlk
LWNvcmUuYwkyMDAzLTA0LTIxIDE5OjU0OjIxICswNDAwCkBAIC0xMDE2LDEwICsxMDE2LDE4IEBA
CiAKIHZvaWQgaGlkX3dyaXRlX3JlcG9ydChzdHJ1Y3QgaGlkX2RldmljZSAqaGlkLCBzdHJ1Y3Qg
aGlkX3JlcG9ydCAqcmVwb3J0KQogewotCWhpZF9vdXRwdXRfcmVwb3J0KHJlcG9ydCwgaGlkLT5v
dXRbaGlkLT5vdXRoZWFkXS5idWZmZXIpOwotCi0JaGlkLT5vdXRbaGlkLT5vdXRoZWFkXS5kci53
VmFsdWUgPSBjcHVfdG9fbGUxNigweDIwMCB8IHJlcG9ydC0+aWQpOwotCWhpZC0+b3V0W2hpZC0+
b3V0aGVhZF0uZHIud0xlbmd0aCA9IGNwdV90b19sZTE2KChyZXBvcnQtPnNpemUgKyA3KSA+PiAz
KTsKKwlpZiAoKGhpZC0+cXVpcmtzICYgSElEX1FVSVJLX1NFVFJFUE9SVF9ORUVEU19JRCkgJiYg
cmVwb3J0LT5pZCkgeworCQloaWQtPm91dFtoaWQtPm91dGhlYWRdLmJ1ZmZlclswXSA9IHJlcG9y
dC0+aWQ7CisJCWhpZF9vdXRwdXRfcmVwb3J0KHJlcG9ydCwgaGlkLT5vdXRbaGlkLT5vdXRoZWFk
XS5idWZmZXIgKyAxKTsKKwkJaGlkLT5vdXRbaGlkLT5vdXRoZWFkXS5kci53TGVuZ3RoID0KKwkJ
CWNwdV90b19sZTE2KCgocmVwb3J0LT5zaXplICsgNykgPj4gMykgKyAxKTsKKwl9IGVsc2Ugewor
CQloaWRfb3V0cHV0X3JlcG9ydChyZXBvcnQsIGhpZC0+b3V0W2hpZC0+b3V0aGVhZF0uYnVmZmVy
KTsKKwkJaGlkLT5vdXRbaGlkLT5vdXRoZWFkXS5kci53TGVuZ3RoID0KKwkJCWNwdV90b19sZTE2
KChyZXBvcnQtPnNpemUgKyA3KSA+PiAzKTsKKwl9CisJaGlkLT5vdXRbaGlkLT5vdXRoZWFkXS5k
ci53VmFsdWUgPQorCQljcHVfdG9fbGUxNigoKHJlcG9ydC0+dHlwZSArIDEpIDw8IDgpIHwgcmVw
b3J0LT5pZCk7CiAKIAloaWQtPm91dGhlYWQgPSAoaGlkLT5vdXRoZWFkICsgMSkgJiAoSElEX0NP
TlRST0xfRklGT19TSVpFIC0gMSk7CiAKQEAgLTEwOTAsNiArMTA5OCw5IEBACiAjZGVmaW5lIFVT
Ql9ERVZJQ0VfSURfUE9XRVJNQVRFCQkweDA0MTAgLyogR3JpZmZpbiBQb3dlck1hdGUgKi8KICNk
ZWZpbmUgVVNCX0RFVklDRV9JRF9TT1VOREtOT0IJCTB4MDRBQSAvKiBHcmlmZmluIFNvdW5kS25v
YiAqLwogCisjZGVmaW5lIFVTQl9WRU5ET1JfSURfQVBDCQkweDA1MWQKKyNkZWZpbmUgVVNCX0RF
VklDRV9JRF9BUENfVVBTXzAwMDIJMHgwMDAyIC8qIEFQQyBVUFMgLSBtYW55IG1vZGVscyAqLwor
CiBzdHJ1Y3QgaGlkX2JsYWNrbGlzdCB7CiAJX191MTYgaWRWZW5kb3I7CiAJX191MTYgaWRQcm9k
dWN0OwpAQCAtMTEyMSw2ICsxMTMyLDcgQEAKIAl7IFVTQl9WRU5ET1JfSURfQVRFTiwgVVNCX0RF
VklDRV9JRF9BVEVOXzRQT1JUS1ZNLCBISURfUVVJUktfTk9HRVQgfSwKIAl7IFVTQl9WRU5ET1Jf
SURfR1JJRkZJTiwgVVNCX0RFVklDRV9JRF9QT1dFUk1BVEUsIEhJRF9RVUlSS19JR05PUkUgfSwK
IAl7IFVTQl9WRU5ET1JfSURfR1JJRkZJTiwgVVNCX0RFVklDRV9JRF9TT1VOREtOT0IsIEhJRF9R
VUlSS19JR05PUkUgfSwKKwl7IFVTQl9WRU5ET1JfSURfQVBDLCBVU0JfREVWSUNFX0lEX0FQQ19V
UFNfMDAwMiwgSElEX1FVSVJLX1NFVFJFUE9SVF9ORUVEU19JRCB9LAogCXsgMCwgMCB9CiB9Owog
Ci0tLSBsaW51eC0yLjQuMjAvZHJpdmVycy91c2IvaGlkLmguYWx0LWFwY191c2JfdXBzCTIwMDIt
MTEtMjkgMDI6NTM6MTQgKzAzMDAKKysrIGxpbnV4LTIuNC4yMC9kcml2ZXJzL3VzYi9oaWQuaAky
MDAzLTA0LTIxIDE5OjQyOjMyICswNDAwCkBAIC0xODYsNiArMTg2LDcgQEAKICNkZWZpbmUgSElE
X1FVSVJLX05PVE9VQ0gJMHgwMgogI2RlZmluZSBISURfUVVJUktfSUdOT1JFCTB4MDQKICNkZWZp
bmUgSElEX1FVSVJLX05PR0VUCQkweDA4CisjZGVmaW5lIEhJRF9RVUlSS19TRVRSRVBPUlRfTkVF
RFNfSUQJMHgxMAogCiAvKgogICogVGhpcyBpcyB0aGUgZ2xvYmFsIGVudmlyb21lbnQgb2YgdGhl
IHBhcnNlci4gVGhpcyBpbmZvcm1hdGlvbiBpcwo=

--Multipart_Tue__22_Apr_2003_18:39:39_+0400_083029a8--

--=.rPW3CATQ/UTztX
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+pVQvW82GfkQfsqIRAsFoAJ4hQtrQVfe97ZioFF8d7HAvp++ZHwCfUztJ
lguft7SZDdYYOrN2tfaDTZE=
=mIxq
-----END PGP SIGNATURE-----

--=.rPW3CATQ/UTztX--
