Re: usb/140477: [umass] [patch] allow boot-time attachment of daX devices to GEOM_ELI
The following reply was made to PR usb/140477; it has been noted by GNATS.
From: Eygene Ryabinkin rea-f...@codelabs.ru
To: Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net
Cc: bug-follo...@freebsd.org
Subject: Re: usb/140477: [umass] [patch] allow boot-time attachment of daX
devices to GEOM_ELI
Date: Thu, 12 Nov 2009 12:11:17 +0300
Bjoern, good day.
Thu, Nov 12, 2009 at 07:28:03AM +, Bjoern A. Zeeb wrote:
has this changed recently, that it no longer works? I seem to
remember that it had perfectly worked before this year.
Yes, it used to work with up to 7.anything. But it seems that with
the new USB stack we have asynchronous discovery and attachment, so
other subsystems are started when this process isn't yet fully
completed, so root mount is getting closer and, for my case, root
mount typically waits only for the completion of USB tasks.
My gut feeling is that the device discovery prior to the USBv2 was
done synchronously, but with USBv2 kernel use async callbacks. Though,
I may be wrong in this judgement.
You can try it yourself -- plugged USB stick with geli volume that is
marked as attach-on-boot should show the current behaviour.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/140477: [umass] [patch] allow boot-time attachment of daX devices to GEOM_ELI
The following reply was made to PR usb/140477; it has been noted by GNATS.
From: Eygene Ryabinkin rea-f...@codelabs.ru
To: Bjoern A. Zeeb bzeeb-li...@lists.zabbadoz.net
Cc: bug-follo...@freebsd.org
Subject: Re: usb/140477: [umass] [patch] allow boot-time attachment of daX
devices to GEOM_ELI
Date: Thu, 12 Nov 2009 16:29:54 +0300
Thu, Nov 12, 2009 at 10:43:56AM +, Bjoern A. Zeeb wrote:
I am doing that regularly, on HEAD (last updated in October). But I
see I lacked coffee this morning, wanted to say earlier this year.
Then it will be interesting to see on which point your kernel is
attaching the daX devices. Could you, please, show your dmesg?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/137189: [usb][patch] create and use sysctl nodes for HID report descriptors
Hans Petter, good day.
Tue, Jul 28, 2009 at 07:40:27PM +0400, Eygene Ryabinkin wrote:
HPS wrote:
Why do you dislike the sysctl approach? It is simple and reliable.
It's duplicating access to data. There is not that much wrong about
it, except it will not work if the device is of another kind. I.E. you
would have to patch the HID sysctl node into every driver accessing
HID descriptors?
Just now -- yes, I'll need it. But probably I can move this
functionality into the USB bus level -- it will automatically create
this sysctl node for all HID children and will dispose it on the detach.
usb_probe_and_attach() is a candidate for such functionality. Will it
be bad?
OK, attached is the reworked version of the sysctl patch: it now creates
the needed nodes automatically (though they still can be created by
explicit call from the driver, as in uhid(4)). As a bonus, kernel got the
ability to install per-USB class post-attach and pre-detach handlers, so
we can do some class-specific things for every driver. What do you think
of it?
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/137189: [usb][patch] create and use sysctl nodes for HID report descriptors
The following reply was made to PR usb/137189; it has been noted by GNATS.
From: Eygene Ryabinkin rea-f...@codelabs.ru
To: bug-follo...@freebsd.org, freebsd-usb@FreeBSD.org
Cc: hsela...@c2i.net
Subject: Re: usb/137189: [usb][patch] create and use sysctl nodes for HID
report descriptors
Date: Fri, 31 Jul 2009 00:38:12 +0400
--tThc/1wpZn/ma/RB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hans Petter, good day.
Tue, Jul 28, 2009 at 07:40:27PM +0400, Eygene Ryabinkin wrote:
HPS wrote:
Why do you dislike the sysctl approach? It is simple and reliable.
It's duplicating access to data. There is not that much wrong about
it, except it will not work if the device is of another kind. I.E. you
would have to patch the HID sysctl node into every driver accessing
HID descriptors?
Just now -- yes, I'll need it. But probably I can move this
functionality into the USB bus level -- it will automatically create
this sysctl node for all HID children and will dispose it on the detach.
usb_probe_and_attach() is a candidate for such functionality. Will it
be bad?
OK, attached is the reworked version of the sysctl patch: it now creates
the needed nodes automatically (though they still can be created by
explicit call from the driver, as in uhid(4)). As a bonus, kernel got the
ability to install per-USB class post-attach and pre-detach handlers, so
we can do some class-specific things for every driver. What do you think
of it?
Thanks!
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
--tThc/1wpZn/ma/RB
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename=0001-USB-implement-new-sysctl-node-hiddesc-for-HID-device.patch
Content-Transfer-Encoding: quoted-printable
=46rom 4f8fd6e07cc388e96ab567ef29c6d592231ffb8a Mon Sep 17 00:00:00 2001
=46rom: Eygene Ryabinkin rea-f...@codelabs.ru
Date: Mon, 27 Jul 2009 08:36:07 +0400
Subject: [PATCH 1/3] USB: implement new sysctl node, hiddesc for HID devi=
ces
=2E..and also implement per-class attach/detach hooks -- now USB classes
can register theis handlers that will be called just after attachment
of device from their class and just before detachment of such device.
This functionality provides the foundation to implement the needed
sysctl in a generic manner where all HID-type devices will automatically
gain this sysctl.
The sysctl node will give out HID descriptor for the given device. It
should be useful both for debugging and for the usbhidctl(1) utility --
it will be able to get (and dump) report descriptors from the devices
that are children of the uhid(4): ukbd(4), ums(4) and others.
We can't export this data via the ioctl, because ums(4) and ukbd(4)
devices are typically used (by moused, Xorg, etc), so we just can't
open them to pass the file descriptor to the ioctl call.
Any driver can override the automated sysctl creation (that will read
the report descriptor from the device-supplied data): this is handy for
uhid(4) -- it sometimes uses hand-crafted report descriptors and we want
to export the descriptor that driver really uses.
Signed-off-by: Eygene Ryabinkin rea-f...@codelabs.ru
---
sys/dev/usb/input/uhid.c |5 +
sys/dev/usb/usb_device.c | 68 ---
sys/dev/usb/usb_hid.c| 214 ++=
sys/dev/usb/usb_hooks.h | 48 ++
sys/dev/usb/usbhid.h |1 +
5 files changed, 325 insertions(+), 11 deletions(-)
create mode 100644 sys/dev/usb/usb_hooks.h
diff --git a/sys/dev/usb/input/uhid.c b/sys/dev/usb/input/uhid.c
index 411aeb6..2432491 100644
--- a/sys/dev/usb/input/uhid.c
+++ b/sys/dev/usb/input/uhid.c
@@ -756,6 +756,11 @@ uhid_attach(device_t dev)
if (error) {
goto detach;
}
+
+ /* Sysctl stuff */
+ hid_install_hiddesc_sysctl_handler(dev,
+ sc-sc_repdesc_ptr, sc-sc_repdesc_size);
+
return (0); /* success */
=20
detach:
diff --git a/sys/dev/usb/usb_device.c b/sys/dev/usb/usb_device.c
index 6617297..df2d531 100644
--- a/sys/dev/usb/usb_device.c
+++ b/sys/dev/usb/usb_device.c
@@ -50,6 +50,7 @@
#include dev/usb/usbdi.h
#include dev/usb/usbdi_util.h
#include dev/usb/usb_ioctl.h
+#include dev/usb/usb_hooks.h
#include usbdevs.h
=20
#define USB_DEBUG_VAR usb_debug
@@ -81,8 +82,8 @@ static void usb_init_endpoint(struct usb_device *, uint8_=
t,
struct usb_endpoint_descriptor *, struct usb_endpoint *);
static void usb_unconfigure(struct usb_device *, uint8_t
Re: usb/137189: [usb][patch] create and use sysctl nodes for HID report descriptors
Hans Petter, good day.
HPS wrote:
Can you change your patch, so that usbhidctl uses libusb to get the
HID descriptor, instead of sysctl?
I can, but how to relate the device name under devfs to the descriptor
to be retrieved? I can enumerate all HID descriptors via libusb, but I
can't currently say which device uses them. And I don't want to torture
users with the crawl over the list of all vendor/device pairs for the
discovered HID descriptors and ask to choose one -- that's not
productive.
Why do you dislike the sysctl approach? It is simple and reliable.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/137189: [usb][patch] create and use sysctl nodes for HID report descriptors
The following reply was made to PR usb/137189; it has been noted by GNATS.
From: Eygene Ryabinkin rea-f...@codelabs.ru
To: bug-follo...@freebsd.org, freebsd-usb@FreeBSD.org
Cc: hsela...@c2i.net
Subject: Re: usb/137189: [usb][patch] create and use sysctl nodes for HID
report descriptors
Date: Tue, 28 Jul 2009 15:51:43 +0400
Hans Petter, good day.
HPS wrote:
Can you change your patch, so that usbhidctl uses libusb to get the
HID descriptor, instead of sysctl?
I can, but how to relate the device name under devfs to the descriptor
to be retrieved? I can enumerate all HID descriptors via libusb, but I
can't currently say which device uses them. And I don't want to torture
users with the crawl over the list of all vendor/device pairs for the
discovered HID descriptors and ask to choose one -- that's not
productive.
Why do you dislike the sysctl approach? It is simple and reliable.
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/137189: [usb][patch] create and use sysctl nodes for HID report descriptors
HPS wrote:
I can, but how to relate the device name under devfs to the descriptor
to be retrieved?
By unit number and device address, like usbconfig.
Yes, but these numbers are the ugen ones; on my system, for example,
ums0 maps to ugen5.3.0.
I can enumerate all HID descriptors via libusb, but I
can't currently say which device uses them.
Try:
usbconfig show_ifdrv
Yes, that's better. But can I rely that the first item in the output of
the libusb20_dev_get_iface_desc() will be the device name? And still,
to get the report descriptor from one device, I should walk the entire
USB tree until I'll find the device I am interested in. May be there
are some other ways? I understand that enumeration is the principle of
the USB bus, but may be there are another ways to directly grab 'struct
libusb20_device *' or alike for the devfs node I am interested in?
Why do you dislike the sysctl approach? It is simple and reliable.
It's duplicating access to data. There is not that much wrong about
it, except it will not work if the device is of another kind. I.E. you
would have to patch the HID sysctl node into every driver accessing
HID descriptors?
Just now -- yes, I'll need it. But probably I can move this
functionality into the USB bus level -- it will automatically create
this sysctl node for all HID children and will dispose it on the detach.
usb_probe_and_attach() is a candidate for such functionality. Will it
be bad?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: usb/137189: [usb][patch] create and use sysctl nodes for HID report descriptors
The following reply was made to PR usb/137189; it has been noted by GNATS.
From: Eygene Ryabinkin rea-f...@codelabs.ru
To: bug-follo...@freebsd.org, freebsd-usb@FreeBSD.org
Cc: hsela...@c2i.net
Subject: Re: usb/137189: [usb][patch] create and use sysctl nodes for HID
report descriptors
Date: Tue, 28 Jul 2009 19:40:27 +0400
HPS wrote:
I can, but how to relate the device name under devfs to the descriptor
to be retrieved?
By unit number and device address, like usbconfig.
Yes, but these numbers are the ugen ones; on my system, for example,
ums0 maps to ugen5.3.0.
I can enumerate all HID descriptors via libusb, but I
can't currently say which device uses them.
Try:
usbconfig show_ifdrv
Yes, that's better. But can I rely that the first item in the output of
the libusb20_dev_get_iface_desc() will be the device name? And still,
to get the report descriptor from one device, I should walk the entire
USB tree until I'll find the device I am interested in. May be there
are some other ways? I understand that enumeration is the principle of
the USB bus, but may be there are another ways to directly grab 'struct
libusb20_device *' or alike for the devfs node I am interested in?
Why do you dislike the sysctl approach? It is simple and reliable.
It's duplicating access to data. There is not that much wrong about
it, except it will not work if the device is of another kind. I.E. you
would have to patch the HID sysctl node into every driver accessing
HID descriptors?
Just now -- yes, I'll need it. But probably I can move this
functionality into the USB bus level -- it will automatically create
this sysctl node for all HID children and will dispose it on the detach.
usb_probe_and_attach() is a candidate for such functionality. Will it
be bad?
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
usb/137188: [usb][patch] correctly handle USB report descriptors with interleaved report IDs
Number: 137188
Category: usb
Synopsis: [usb][patch] correctly handle USB report descriptors with
interleaved report IDs
Confidential: no
Severity: serious
Priority: medium
Responsible:freebsd-usb
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Mon Jul 27 19:40:01 UTC 2009
Closed-Date:
Last-Modified:
Originator: Eygene Ryabinkin
Release:FreeBSD 8.0-BETA2 amd64
Organization:
Code Labs
Environment:
System: FreeBSD 8.0-BETA2 amd64
Description:
Some devices can have interleaved report IDs. For example, when vendor
groups some items inside logical collections and these items come from
various report IDs, they will be interleaved. Current code sets item
position to zero everytime when new report ID is encountered. Such
behaviour isn't enforced by the HID specification (at least I hadn't
found such place in the HID spec v 1.11), so I take that interleaved IDs
are OK and the code should be changed to handle these devices.
How-To-Repeat:
One can reproduce this with, for example, Microsoft Wireless Laser Mouse
5000: it has Z-axis and tilt axis output items grouped with their feature
items that control sensitivity. HID descriptor for this mouse can be
found in the supplied patch.
For me, without the below patch Z-axis is reported to be at offset 0, so
button clicks produce extra wheel movements that are translated to
scrolls under Xorg. And that's very funny when click produces scrolls --
it reminds me old game with the hiding mouse pointer under WFWG 3.11.
Fix:
The following patch adds the ability to save current item positions
when new report ID is encountered. It fixes both kernel parser and
libusbhid one. Patches are generally the same, modulo differences
between kernel- and user-side needs.
--- correctly-handle-interleaved-report-IDs.patch begins here ---
begin 644 0001-HID-correctly-handle-interleaved-report-IDs-inside-t.patch
M1G)O;2`W-#=C-3U93DV,SEB.69F,F0Q,#...@r,S$Y-#4R968R8S$R-(u...@p
M($UO;B!397`@,3@,#`Z,#`Z,#`@,C`P,0IF]M.B!%6=E;f...@4gea8fen
M:VEN(#QR96$M9F)S9$!C;V1E;%BRYR=3X*1%t...@4w5n+`R-B!*=6P@
M,C`P.2`P.#HT,#HP.`K,#0P,`I3=6)J96-T.B!;4$%40T@@,2\W72!(240Z
M(-OG)E8W1L2!H86YD;4@:6YT97)L96%V960@F5P;W)T($E$R!I;G-I
M94...@=]P+6QE=F5L(-O;QE8W1I;VX*e=h...@82!t;W`M;5v...@8v]l
M;5C=EO;B!H87,@;75L=EP;4@F5P;W)T($E$R!I;G-I94L('1H92!C
M=7)R96YTF-O94@F5S971S(ET96T@]S:71I;v...@96%c:!T:6UE('=H
M96X@:7...@96yc;W5N=5RR`G4F5P;W)T($E$)R!F:65L9`II;B!T:4...@2$e$
M(1EV-R:7!T;W(N(!4:%T)W,@;F]T(=O;v...@9f]r(1EV-R:7!T;W)S
M('=H97)E(')E]R=!)1',*87)E(EN=5R;5a=f5d...@1f]r(5X86UP
M;4L('1H92!B96QO=R!D97-CFEP=]R('=O;B=T()E('!AG-E9`IC;W)R
M96-T;'DZ(ET(AAR!L;V=I8V%L(=R;W5P:6YG(]F('9AFEO=7,@F5P
M;W)T($E$(ET96US(ENVED90IT:4@;]G:6-A;!C;VQL96-T:6]NRX@
M(%1H92!D97-CFEP=]R(ES('1A:V5N(9R;v...@=AE($UI8W)OV]F=`I7
M:7)E;5SR!,87-EB!-;W5S92`U,#...@hm+2tm+0i-:6-R;w-o...@5ver
M96QEW,@3%S97(@36]Uv...@-3`p,`H*6W)E]R=!D97-C('-IF4],CT
M70I54T%'12!004=%($-O;G-U;65r*#!x8rd*55-!...@0v]nW5M97(@0V]N
M=')O;@P#$I6T-O;G-U;65R*#!X8RE=D-/3$Q%0U1)3...@07!p;EC871I
M;VXH,2D*(!54T%'12!004=%($=E;F5R:6,@15S:W1O@P#$Ib...@55-!
m...@36]uV4H,'@R*5M'96YEFEC($1EVMT;W`H,'@Q*5T*(!#3TQ,14-4
M24].($QO9VEC86PH,BD*(`@(%)%4$]25!)1`Q.0H@(`...@55-!1t4@4$%'
M12!#;VYS=6UEb...@p,IB`@(!54T%'12!!0R!086XH,'@R,s...@i6t-o;G-U
M;65R*#!X8RE=B`@(!215!/4...@0t]53e0@,0H@(`...@4d503u)4(%-)6D4@
M.`H@(`...@3$]'24-!3!-24Y)355-(TQ,C*(`@($Q/1te#...@34%824u5
M32`Q,C*(`@($E.4%54(@@1%T82!687)I86)L92!296QA=EV92`I(@V
M*0H@(`...@4d503u)4($E$(#(PB`@(!54T%'12!004=%($UI8W)OV]F=@P
M9F,#`IB`@(!54T%'12!5;FMN;W=N(%5S86=E*#!X9F4P,2E;36ECF]S
M;V9T*#!X9F8P,E=B`@(!215!/4...@4te:12`RB`@(!,3T=)0T%,($U)
M3DE-54T@,`H@(`...@3$]'24-!3!-05A)355-(#,*(`@($E.4%54(@@1%T
M82!687)I86)L92!!8G-O;'5T92`I(@R*0H@(`...@55-!1t4@56YK;F]W;B!5
Mv%...@p9E,#(I6TUI8W)OV]F=@P9F,#`I70H@(`...@55-!1t4@56YK
M;F]W;B!5v%...@p9E,#`I6TUI8W)OV]F=@P9F,#`I70H@(`...@4d50
M3U)4($-/54Y4(#(*(`@(%)%4$]25!325I%(#$*(`@($Q/1te#...@34%8
M24U532`QB`@(!)3E!55`H($1A=$...@5f%r:6%B;4...@06)S;VQU=4...@*2`h
M,BD*(`@(%5304=%(%5N:vyo...@57-a9v4h,'AF9C`S*5M-:6-R;W-O9G0H
M,'AF9C`P*5T*(`@(%)%4$]25!#3U5.5`QB`@(!215!/4...@4te:12`R
MB`@(!,3T=)0T%,($U!6$E-54T@,PH@(`...@24y0550@*!$871A(%9AFEA
M8FQE($%BV]L=71E(d...@*#(IB`@(!)3E!55`H($-O;G-T($%RF%Y($%B
MV]L=71E(d...@*#$iB`@(!215!/4...@240@,C$*(`@(%)%4$]25!325I%
M(#$*(`@($Q/1te#...@34%824u532`qB`@(!54T%'12!5;FMN;W=N(%5S
M86=E*#!X9F8P8BE;36ECF]S;V9T*#!X9F8P,E=B`@(!)3E!55`H($1A
M=$...@5f%r:6%B;4...@06)S;VQU=4...@*2`h,BD*(`@(%)%4$]25!325I%(#*
M(`@($E.4%54(@@0V]Nw...@07)r...@06)S;VQU=4...@*2`h,2D*(`@(%53
M04=%(%5N:vyo...@57-a9v4h,'AF9C!D*5M-:6-R;W-O9G0H,'AF9C`P*5T*
M(`@(%)%4$]25!325I%(#$VB`@(!,3T=)0T%,($u!6$e-...@-c4u,S4*
M(`@($E.4%54(@@1%T82!687)I86)L92!!8G-O;'5T92`I(@R*0H@(`@
M4D503U)4($E$(#(SB`@(!54T%'12!5;FMN;W=N(%5S86=E*#!X9F8P-BE;
M36ECF]S;V9T*#!X9F8P,E=B`@(!54T%'12!5;FMN;W=N(%5S86=E*#!X
M9F8P9BE;36ECF]S;V9T*#!X9F8P,E=B`@(!,3T=)0T%,($U!6$E-54T@
M,0H@(`...@4$a94te#04p@34E
usb/137189: [usb][patch] create and use sysctl nodes for HID report descriptors
Number: 137189
Category: usb
Synopsis: [usb][patch] create and use sysctl nodes for HID report
descriptors
Confidential: no
Severity: non-critical
Priority: medium
Responsible:freebsd-usb
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Mon Jul 27 19:50:03 UTC 2009
Closed-Date:
Last-Modified:
Originator: Eygene Ryabinkin
Release:FreeBSD 8.0-BETA2 amd64
Organization:
Code Labs
Environment:
System: FreeBSD 8.0-BETA2 amd64
Description:
usbhidctl in 8.x can dump report descriptors only from the uhid(4)
devices. When, for example, ums(4) or ukbd(4) grab HID devices,
there is no way to dump and decode their descriptors via usbhidctl.
How-To-Repeat:
Run 'usbhidctl -f /dev/ums0 -d' and see how it will fail.
Fix:
The following patch makes kernel-side changes: it introduces general
framework to create opaque sysctl nodes 'dev.name.unit.hiddesc'
that are exporting HID descriptor to the userspace.
--- 0003-UHID-implement-new-sysctl-node-hiddesc.patch begins here ---
begin 644 0003-UHID-implement-new-sysctl-node-hiddesc.patch
M1G)O;2`S-3,R931F-3EC,#P8C%A-C(V-#%C,S8X.6(R.8U.3%E,C9C,3...@u
M($UO;B!397`@,3@,#`Z,#`Z,#`@,C`P,0IF]M.B!%6=E;f...@4gea8fen
M:VEN(#QR96$M9F)S9$!C;V1E;%BRYR=3X*1%t...@36]n+`R-R!*=6P@
M,C`P.2`P.#HS-CHP-R`K,#0P,`I3=6)J96-T.B!;4$%40T@@,R\W72!52$E$
M.B!I;7!L96UE;G0@;F5W('-YV-T;!N;V1E+`B:ED95S8R(*E1H:7,@
M;F]D92!W:6QL(=I=F4@;W5T($A)1!D97-CFEP=]R(9OB!T:4...@9vev
m...@95V:6-e...@270@VAO=6QDF)E('5S969U;!B;W1H(9OB!D96)U
M9V=I;F@86YD(9OB!T:4...@=7-b:ED8W1L*#$I('5T:6QI='d...@+2t@:70@
M=VEL;`IB92!A8FQE('1O(=E=`H86YD(1U;7`I(')E]R=!D97-CFEP
M=]RR!FF]M('1H92!D979I8V5S('1h...@87)EF-H:6QDF5N(]F('1H
M92!U:ED*#0I.B!U:V)D*#0I+!U;7,H-d...@86yd(]T:5RRX*E=E(-A
M;B=T(5X]R=!T:ES(1A=$...@=fea('1H92!I;V-T;p...@8f5c875s92!u
M;7,H-d...@86yd('5K8F0H-D*95V:6-ER!Af...@='EP:6-A;QY('5S960@
M*)Y(UO=7-E9p...@6]r...@971c*2p@v...@=v4@:G5S=!C86XG=`IO5N
M('1h...@=\@%SR!T:4...@9fel92!d97-cFEP=]R('1O('1H92!I;V-T
M;!c86...@h*1f]r('1H92!U;FEF;W)M:71Y+!T:4...@=6ai9@T*2!I='-E
M;8...@86qs;r!g86en...@=AIR!S7-C=PN@I3:6=N960M;V9F+6)Y.B!%
M6=E;f...@4gea8fen:VEN(#QR96$M9F)S9$!C;V1E;%BRYR=3X*+2TMB!S
M7,O95V+W5S8B]I;G!U=]U:ED+F,@?`@(`U(LK*RLKB!S7,O95V
M+W5S8B]I;G!U=]U:V)D+F,@?`@(#,T(LK*RLK*RLK*RLK*RLK*RLK*RLK
M*RLK*RTM+2TM+2TM+2T*('-YR]D978O=7-B+VEN'5T+W5MRYC(!\(`@
M,S(@*RLK*RLK*RLK*RLK*RLK*RLK*RLK+2TM+2TM+2TM+2T*('-YR]D978O
M=7-B+W5S8E]H:60N8R`@(!\(`@,s...@*rlk*rlk*rlk*rlk*rlk*rlk*rlk
M*RLK*RLK*RLK*RLK*RL*('-YR]D978O=7-B+W5S8FAI9YH(`@(!\(`@
M(#...@*ph@-2!F:6QER!C:%N9V5D+`X-B!I;G-EG1I;VYS*LI+`R,2!D
M96QE=EO;G,H+2D*f1i...@+2ug:7...@82]s7,O95V+W5S8B]I;G!U=]U
M:ED+F,@8B]S7,O95V+W5S8B]I;G!U=]U:ED+F,*:6YD97@@-#$Q865B
M-BXN,C0S,C0Y,2`Q,#`V-#0*+2TM($OWES+V1E=B]UV(O:6YP=70O=6AI
M9YCBLK*R!B+W-YR]D978O=7-B+VEN'5T+W5H:60N8PI`0`M-S4V+#8@
M*SU-BPQ,2!`0!U:ED7V%T=%C:AD979I8V5?=!D978IB`):6...@*5R
MF]R*2![B`)6=O=\...@95T86-H.PH@7T**PHK2\J(%-YV-T;!S='5F
M9B`J+PHK6AI9%]I;G-T86QL7VAI91EV-?WES8W1L7VAA;F1L97(H95V
M+`HK2`@(!S8RT^V-?F5P95S8U]P='(L('-C+3YS8U]R97!D97-C7W-I
MF4I.PHKB`)F5T=7)N(@P*3L)0DO*B!S=6-C97-S(HOB`*(1E=%C
M:#H*9EF9B`M+6=I=!A+W-YR]D978O=7-B+VEN'5T+W5K8F0N8R!B+W-Y
MR]D978O=7-B+VEN'5T+W5K8F0N8PII;F1E`R.34T-F$U+BYC,F,Y9F%C
M(#$P,#8t-`hm...@82]s7,O95V+W5S8B]I;G!U=]U:V)D+F,**RLK((O
MWES+V1E=B]UV(O:6YP=70O=6MB9YCD!`(TQ-SDL-B`K,3y...@0$`@
MW1R=6-T('5K8F1?V]F=,@PH@75I;G0X7W0)V-?:69A8V5?;F\[B`)
M=6EN=#A?=!S8U]K8F1?:60[B`)=6EN=#A?=!S8U]L961?:60[BL**PEV
M;VED(IH:61?F1EV,[BL)=6EN=#$V7W0@:ED7W)S:7ie...@?3l*(`H@
M(V1E9FEN90E+15E?15)23U()(`P#`QD!`(TW,C8L,3...@*sR.2PQ,2!`
M0!U:V)D7V%T=%C:AD979I8V5?=!D978IB`)W1R=6-T('5S8E]A='1A
M8VA?87)G(IU86$@/2!D979I8V5?9V5T7VEV87)S*1E=BD[B`):6YT,S)?
M=!U;FET(#...@95V:6-E7V=E=%]U;FET*1E=BD[B`):V5Y8F]AF1?=`J
M:V)D(#T@)G-C+3YS8U]K8F0[BT)=F]I9`J:ED7W!TB`]($Y53$P[B`)
M=7-B7V5Rf]r...@97)R.PH@75I;G0S,E]T(9L86=S.PH@75I;G0Q-E]T
M(X[BT)=6EN=#$V7W0@:ED7VQE;CL**PHK7-C+3YH:61?F1EV,@/2!.
M54Q,.PH@B`);71X7V%SV5R=@F1VEA;G0L($U!7T]73D5$*3L*(`I`0`M
M-SX+#(P(LW.#$L,c...@0$`@=6MB9%]A='1...@h95V:6-e...@95V*0H@
M4M1%]04D]15]$3TY%*MB9D[B`*(`DO*B!F:6=UF4@;W5T(EF('1H
M97)E(ES(%N($E$()Y=4@:6...@=AE(1A=$...@*b\*+0eeG(@/2!UV)D
M7W)E5]G971?:ED7V1EV,H=6%A+3YD979I8V4L($Y53$PL(9H:61?'1R
M+`HM2`@(`F:ED7VQE;b...@35]414u0+!U86$M/FEN9F\N8DEF86-E26YD
m...@i.phk65RB`]('5S8F1?F5Q7V=E=%]H:61?95S8RAU86$M/F1E=FEC
m...@3e5,3P@)G-C+3YH:61?F1EV,LBL)(`@(9S8RT^:ED7W)S:7IE
M+!-7u530d1%...@=6%a+3yi;F9O+F))9F%C94EN95X*3L*(`EI9B`H97)R
M(#T](#`I('L*(`D)=6EN=#A?=!T96UP7VED.PH@B`)2\J(EN=F5S=EG
M871E(EF('1H:7,@:7,@8...@07!p;4...@2v5y8f]af...@*b\*+0d):6...@*AI
M9%]L;V-A=4H:ED7W!TBP@:ED7VQE;BP**PD):6...@*AI9%]L;V-A=4H
MV,M/FAI9%]R95S8RP@V,M/FAI9%]RVEZ92P*(`D)(`@($A)1%]54T%'
M13(H2%507T-/3E-53452+!(54=?05!03$5?14I%0U0I+`H@0D@(`@:ED
M7VEN'5T+`P+`FV,M/G-C7VQO8U]A'!L95]E:F5C=P@)F9L86=S+`H@
M0D@(`@)G-C+3YS8U]K8F1?:60I*2![B`)0EI9B`H9FQA9W,@)B!(24]?
M5D%224%3$4IB`)0D)V,M/G-C7V9L86=S('P](%5+0D1?1DQ!1U]!4%!,
M15]%2D5#5!\(`H@0D)2`@(!52T)$7T9,04=?05!03$5?4U
usb/137190: [usb][patch] inhibit spurious button releases for some complex mices
Number: 137190
Category: usb
Synopsis: [usb][patch] inhibit spurious button releases for some complex
mices
Confidential: no
Severity: serious
Priority: medium
Responsible:freebsd-usb
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Mon Jul 27 20:00:10 UTC 2009
Closed-Date:
Last-Modified:
Originator: Eygene Ryabinkin
Release:FreeBSD 8.0-BETA2 amd64
Organization:
Code Labs
Environment:
System: FreeBSD 8.0-BETA2 amd64
Description:
My Microsoft Wireless Laser Mouse 5000 shows weird behaviour when I do
press some button and trying to select the text inside the terminal
moving the pointer: looks like extra button press/release events are
generated. Running 'xev' I see such events in the utility's output.
How-To-Repeat:
Get the mentioned mice and try to select some text in the terminal:
you'll likely won't be able to select everything you want.
Fix:
The problem is that this mice is complex: it has other output descriptors
whose output also goes to the ums(4) driver. It produces no data that will
be consumed by the driver, but due to the logics of the callback function,
variable 'buttons' will be different from the initial softc's button state
of some button was physically pressed when this foreign data comes.
The following patch makes ums(4) to be resistant to such callback input.
--- 0007-ums-avoid-spurious-button-releases-for-complex-mices.patch begins here
---
begin 644 0007-ums-avoid-spurious-button-releases-for-complex-mices.patch
M1G)O;2`U,#8S9F1F-F,Y-4P8C0Q-#4W8V8Y-C!C-F8S86)a9#$...@s.30x
M($UO;B!397`@,3@,#`Z,#`Z,#`@,C`P,0IF]M.B!%6=E;f...@4gea8fen
M:VEN(#QR96$M9F)S9$!C;V1E;%BRYR=3X*1%t...@36]n+`R-R!*=6P@
M,C`P.2`Q-CHU.#HU.`K,#0P,`I3=6)J96-T.B!;4$%40T@@-R\W72!U;7,Z
M(%V;VED('-P=7)I;W5S()U='1O;B!R96QE87-ER!F;W(@8V]MQE!M
M:6-EPH*4V]M92!M:6-ER`H36ECF]S;V9T(%=IF5L97-S($QAV5R($UO
M=7-E(#4P,#`@:7,@;VYE(]F('1H96TI(')E]R=`II;G!U=!I=5M('9I
M82!M=6QT:7!L92!R97!Og...@95S8W)I'1OG,@86YD(YO=!A;p...@9%T
M82!IPIR96-O9VYIF5D()Y('5Mr...@t*2!dFEV97(N(!7:5N('-U8V@@
M(F9Of5i...@9%T82(@8V]M97,@:6...@86yd('-O;64*;6]Uv...@8g5t=]N
M('=AR!A;')E861Y('!R97-S960L('1H:7,@=VEL;!E9F9E8W1I=F5L2!Z
M97)O(]U=!B=71T;VX*W1A=4Z(=B=71T;VYS)R!AF4@:6YI=EA;EZ
m...@=\@F5R;R!A=!T:4...@8f5g:6YN:6YG(]F('1H92!H86YD;5RF%N
M9!S;V9T8R!D871A(ES(UO9EF:65D(EF('1H92!B=71T;VX@W1A=4@
M:6X@V]F=,@:7-N)w...@=AE('-A;64*87,@=AE()U='1O;B!D871A(9R
M;VT@)V)U='1O;G,g...@h*06yy('-U8G-E75E;G0@;6]UV4@;6]V97,@=VET
M:!B=71T;VX@AYVEC86QL2!H96QD('=I;P@')O9'5C90IE'1R82!M
M;W5S92!PF5SV5S(AA9V%I;b...@=AE('-P=7)I;W5S(]N97,I.B!M;W9E
M(UA:V5S(ui...@=\@V5N9`IT:4@%C:V5T('=I=@@=AE(1A=$@
M=AA=!W:6QL()E(')E8V]G;fez...@8gd@=AE(1R:79Ec...@86qlB)R
M96QE87-E9(@8G5T=]NR!W:6QL()E+!O9B!C;W5RV4L()PF5SV5D
M(%G86EN(B!W:5N('1H:7,@9%T80IW:6QL()E('!R;V-EW-E9X*D%N
M;W1H97(@=F%R:6%B;4...@=v%s(EN=')O9'5c...@=\...@9fqa9r!i9b!w92!h
M860@V5E;B!A;g...@9%T82!I=5MPIT:%T()E;]N9R!T;R!UR!A;F0@
MV]F=,@W1A=4@:7,@8VAA;F=E9!O;FQY(EF('1H92!F;%G(ESFYO
M;BUZ97)o...@h*4veg;F5D+6]F9BUB3...@17eg96ye(%)Y86)I;FMI;B`\F5A
M+69BV1`8V]D96QA8G,NG4^BTM+0H@WES+V1E=B]UV(O:6YP=70O=6US
M+F,@?`@(#,V(LK*RLK*RLK*RLK*RLK*RLK*RLK*RLK*RLK*RLK+2TM+2TM
M+0H@,2!F:6QER!C:%N9V5D+`R.2!I;G-EG1I;VYS*LI+`W(1E;5T
M:6]Nr...@m*0h*9EF9B`M+6=I=!A+W-YR]D978O=7-B+VEN'5T+W5MRYC
M((OWES+V1E=B]UV(O:6YP=70O=6US+F,*:6YD97@@,C!B8V0S,RXN.#EE
M,3...@u,B`Q,#`V-#0*+2TM($OWES+V1E=B]UV(O:6YP=70O=6US+F,**RLK
M((OWES+V1E=B]UV(O:6YP=70O=6US+F,*...@+3(P,BPV(LR,#(L-R!`
M0!U;7-?:6YTE]C86QL8F%C:RAS=')u...@=7-b7waf97(@*GAF97(L('5S
M8E]EG)OE]T(5RF]R*0H@75I;G0X7W0@:3L*(`EU:6YT.%]T(ED.PH@
M6EN=!L96X[BL)=6YS:6=N960@:6YT(=O=%]M:6YE7V1A=$@/2`P.PH@
MB`)=7-B9%]X9F5R7W-T871URAX9F5R+`F;5N+!.54Q,+!.54Q,+!.
M54Q,*3L*(`I`0`M,C0R+#$X(LR-#,L,s...@0$`@=6US7VEN=')?8V%L;)A
M8VLHW1R=6-T('5S8E]X9F5R(IX9F5R+!UV)?97)R;W)?=!EG)OBD*
M(`D)7T*(`D)?0H@BL)+rh*...@*b`g9v]t7vui;F5?9%T82@:7,@=7-E
M9!AR!T:4...@9fqa9r!t:%T('=E(AA9!C;VYS=6UE9`HK2`J(%T(QE
M87-T(]N92!I=5M('1h...@8f5l;VYGR!T;R!URX@(%1H:7,@9W5AF1S
M('5Mr...@t*0hk2`J(9R;v...@=AE(EN'5T(1A=$...@=vet:!T:4@)V9O
MF5I9VXG(')E]R=!)1',Z('=H96X@W5C:`HK2`J(1A=$...@8v]m97,L
M(ET('=I;p...@8f4@')O8V5SV5D()Y('1H:7,@:%N9QEBX@($YO(ET
M96USBL)(h...@=vel;!B92!M;V1I9FEE9p...@8g5t('-I;F-E('1H92!B=71T
M;VX@W1A=4@:7,@:6YI=EA;ez960*...@*b!t;R!Z97)O(%T('1H92!B
M96=I;FYI;F@;v...@=AE(AA;F1L97(L('1H:7,@9F]R96EG;B!D871ABL)
M(h...@=vel;!L96%D('1O('1H92!B=71T;VX@W1A=4...@8vaa;F=E(EF('-O
M;6...@8g5t=]N(ESBL)(h...@8w5rF5N=QY('!R97-S960N(!4:ES('=I
M;P@')O9'5C92!S'5R:6]UR!C;EC:W,*...@*b!a;f...@=v4@;75S=!A
M=F]I9!T:5...@hk2`J+PH@7)E5A=#H*(`D):6...@*AI;F9O+3YS8U]F
M;%GR`F(%5-4U]3$%'7U=?05A)4RD@)B8*+0D)(`@(AI9`]/2!I;F9O
M+3YS8U]I:61?=RDIBL)2`@(`H:60@/3T@:6YF;RT^V-?:6ED7WI*2![
MB`)0ED=R`K/2!H:61?9V5T7V1A=$H8G5F+!L96XL(9I;F9O+3YS8U]L
M;V-?=RD[BL)0EG;W1?;6EN95]D871A*RL[BL)7T*(`HM0EI9B`H*EN
M9F\M/G-C7V9L86=S(8...@54u37t9,04=?6%]!6$E3*2`F)B`*+0D)(`@(AI
M9`]/2!I;F9O+3YS8U]I:61?DIBL)6EF(@H:6YF;RT^V-?9FQA9W,@
M)B!535-?1DQ!1U]87T%825,I(8FBL
Re: usb/137189: [usb][patch] create and use sysctl nodes for HID report descriptors
The following reply was made to PR usb/137189; it has been noted by GNATS.
From: Eygene Ryabinkin rea-f...@codelabs.ru
To: freebsd-gnats-sub...@freebsd.org, freebsd-usb@FreeBSD.org
Cc:
Subject: Re: usb/137189: [usb][patch] create and use sysctl nodes for HID
report descriptors
Date: Tue, 28 Jul 2009 00:01:28 +0400
I forgot to add another patch that enabled usbhidctl to parse
all report IDs and not just report ID zero.
--- 0005-usbhidctl-dump-report-descriptor-for-all-IDs.patch begins here ---
begin 600 0005-usbhidctl-dump-report-descriptor-for-all-IDs.patch
M1G)O;2!E9C`U-,Y-65B8C1B-0W86%F8SW.9C,V9C-68R,V0X-9F,3`X
M($UO;B!397`@,3@,#`Z,#`Z,#`@,C`P,0IF]M.B!%6=E;f...@4gea8fen
M:VEN(#QR96$M9F)S9$!C;V1E;%BRYR=3X*1%t...@36]n+`R-R!*=6P@
M,C`P.2`Q-#HU,CHS-`K,#0P,`I3=6)J96-T.B!;4$%40T@@-2\W72!UV)H
M:61C=PZ(1U;7`@F5P;W)T(1EV-R:7!T;W(@9F]R(%L;!)1',*E!R
M979I;W5S;'d...@9%T82!W87,@9'5M5D(]N;'d...@9f]r('1H92!R97!OG0@
M240@/2`P+!B96-A=7-E('1H90IV87)I86)L92`GF5P;W)T:60G(ES('-T
M871I8RX@(%1H870GR!N;w...@9v]o9`M+2!N;w...@979eg...@95V:6-E(AA
MPIR97!Og...@240@,!A;f...@9v5n97)A;QY('=E('=A;g...@=\@V5E('1H
M92!W:]L92!R97!Og...@95S8W)I'1OBX*E-IF5S(%R92!A;'-O(-A
M;-U;%t...@9f]r(%L;!R97!Og...@241s(AT:5Y(%R92!S=6UM960@
m=7...@h*4veg;F5D+6]F9BUB3...@17eg96ye(%)Y86)I;FMI;B`\F5A+69B
MV1`8V]D96QA8G,NG4^btm...@=7-r+f)I;B]UV)H:61C=PO=7-B:ED
M+F,@?`@(`Y(LK*RLK+2TM+0H@,2!F:6QER!C:%N9V5D+`U(ENV5R
M=EO;G,H*RDL(#...@95L971I;VYS*TI@ID:69F(TM9VET($O=7-R+F)I
M;B]UV)H:61C=PO=7-B:ED+F,@8B]UW(N8FEN+W5S8FAI9-T;]UV)H
M:60N8PII;F1E`U93`T,34U+BXX-,V.30P(#$P,#8t-`hm...@82]uW(N
M8FEN+W5S8FAI9-T;]UV)H:60n8phk...@8b]uW(N8FEN+W5S8FAI9-T
M;]UV)H:60N8PI`0`M-3,L-R`K-3,L.!`0!I;g...@=f5r8f]s92`](#`[
MB!I;g...@86ql(#T@,#L*(EN=!N;VYA;64@/2`P.PH@:6YT(AE1U;7`@
M/2`P.PHMW1A=EC(EN=!R97!OG1I9#L**R\J(%=E)W)E(EN=5R97-T
M960@:6...@86ql(')E]R=!)1',@=VAI;4...@9'5MEN9R!T:4@W1U9F8N
M(HOBMS=%T:6,@:6YT(')E]R=ED(#...@+3$[B`*(-H87(@*BIN86UE
MSL*(EN=!N;F%M97,[D!`(TQ-3(L,3,@*S$U,RPQ,R!`0!D=6UP:71E
M;7,HF5P;W)T7V1EV-?=!R*0H@0E]B`)?0H@6AI9%]E;F1?%RV4H
M9D[BT)VEZ92`](AI9%]R97!OG1?VEZ92AR+!H:61?:6YP=70L(#`I
M.PHK7-IF4@/2!H:61?F5P;W)T7W-IF4HBP@:ED7VEN'5T+!R97!O
MG1I9D[B`)')I;G1F*)4;W1A;`@(EN'5T('-IF4@)6...@8get97-
M;B(L('-IF4I.PH@BT)VEZ92`](AI9%]R97!OG1?VEZ92AR+!H:61?
M;W5T'5T+`P*3L**PES:7IE(#T@:ED7W)E]R=%]S:7IE*'(L(AI9%]O
M=71P=70L(')E]R=ED*3L*(`EPFEN=8H(E1O=%L(!O=71P=70@VEZ
M92`E9!B71EUQN(BP@VEZ92D[B`*+0ES:7IE(#T@:ED7W)E]R=%]S
M:7IE*'(L(AI9%]F96%T=7)E+`P*3L**PES:7IE(#T@:ED7W)E]R=%]S
M:7IE*'(L(AI9%]F96%T=7)E+!R97!OG1I9D[B`)')I;G1F*)4;W1A
M;!F96%T=7)E('-IF4@)6...@8get97-;B(L('-If4i...@?0h@BTM(`HQ
(+C8N,RXQ@H`
`
end
--- 0005-usbhidctl-dump-report-descriptor-for-all-IDs.patch ends here ---
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
usb/137191: [usb][patch] export ums(4) output report parser data to the userspace
Number: 137191
Category: usb
Synopsis: [usb][patch] export ums(4) output report parser data to the
userspace
Confidential: no
Severity: non-critical
Priority: medium
Responsible:freebsd-usb
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Mon Jul 27 20:10:03 UTC 2009
Closed-Date:
Last-Modified:
Originator: Eygene Ryabinkin
Release:FreeBSD 8.0-BETA2 amd64
Organization:
Code Labs
Environment:
System: FreeBSD 8.0-BETA2 amd64
Description:
It is sometimes useful to see how various mouse functions are recognized
by the ums(4) driver. One can recompile the kernel with USB_DEBUG, but
that's not always viable. Another way to proceed is to create sysctl
node that will show parser's data.
How-To-Repeat:
Try to understand how bits in the output report descriptors are mapped
to the buttons and mouse movements by the ums(4) driver with the stock
FreeBSD kernel.
Fix:
The following patch adds sysctl named 'dev.ums.unit.parseinfo' that
dumps parser internal state in the human-readable form.
--- 0006-ums-4-add-sysctl-node-to-give-away-mouse-report-pars.patch begins here
---
begin 644 0006-ums-4-add-sysctl-node-to-give-away-mouse-report-pars.patch
M1G)O;2`T.#`V9CX.30X-68U8F1D8V)A9(S.3-D.#0R8V-C96(U-S1A-6$R
M($UO;B!397`@,3@,#`Z,#`Z,#`@,C`P,0IF]M.B!%6=E;f...@4gea8fen
M:VEN(#QR96$M9F)S9$!C;V1E;%BRYR=3X*1%t...@36]n+`R-R!*=6P@
M,C`P.2`Q-3HT,SHR,B`K,#0P,`I3=6)J96-T.B!;4$%40T@@-B\W72!U;7,H
M-DZ(%D9!S7-C=P@;F]D92!T;R!G:79E(%W87D@;6]UV4@F5P;W)T
M('!AG-I;F@9%T80H*36]S=QY(1E8G5G9VEN9R!S='5F9CH@:70@:7,@
MV]M971I;65S(1EVER86)L92!T;R!U;F1EG-T86YD(AO=R!T:4*9%T
M82!T:%T(-O;65S('9I82!T:4...@55-(')E]R=',@:7,@%RV5D+B`@
m...@8v%n(')E8F]O=!T:4@:V5R;F5LG=I=@@=AE('9EF)Ov...@8f]o
M=!F;%G+!B=70@V]M971I;65S(ET(ES(YO=!V:6%B;4Z(9OB!E
M%MQE+`IW:5N('5S97(@F5P;W)TR!S;VUE('=E:7)D()E:%V:6]U
MB!O9B!H:7,@;6]UV4L()U=!IVXG=!G;VEN9R!T;PID;R!T:4...@9g5l
M;!D96)U9R!A;F0@F5B;V]T(AIR!H;w...@h*06yd+!T;R!T96QL('1H
M92!TG5T:P@:70@:7,@VEMQI97(@=\...@='EP92`GWES8W1L(UBF1E
M=BYU;7,N,YP87)S96EN9F\G('1h...@=\...@8w)A=VP@;W9EB!T:4...@9UE
MV@;W5T'5...@h*4veg;F5D+6]F9BUB3...@17eg96ye(%)Y86)I;FMI;B`\
MF5A+69BV1`8V]D96QA8G,NG4^BTM+0H@WES+V1E=B]UV(O:6YP=70O
M=6US+F,@?`@(#Q(LK*RLK*RLK*RLK*RLK*RLK*RLK*RLK*RLK*RLK*RLK
M*RLK*RLK*RLK*RLK*RLKB`Q(9I;5S(-H86YG960L(#Q(ENV5R=EO
M;G,H*RDL(#...@95L971I;VYS*TI@ID:69F(TM9VET($OWES+V1E=B]U
MV(O:6YP=70O=6US+F,@8B]S7,O95V+W5S8B]I;G!U=]U;7,N8PII;F1E
M!F-C,W86,Q+BXR,)C9#,S(#$P,#8t-`hm...@82]s7,O95V+W5S8B]I
M;G!U=]U;7,n8phk...@8b]s7,O95V+W5S8B]I;G!U=]U;7,N8PI`0`M
M-C,L-B`K-C,L-R!`0!?7T94T1)1@B)$9R9654T0D(BD[B`C:6YC;'5D
M92`\WES+W!R:78N:#X*(-I;F-L=61E(#QS7,O8V]N9BYH/@H@(VEN8VQU
M94@/'-YR]F8VYT;YH/@HK(VEN8VQU94@/'-Yr]s8g5...@^B`*(-I
M;F-L=61E(#QD978O=7-B+W5S8BYH/@H@(VEN8VQU94@/1E=B]UV(O=7-B
M9DN:#x*...@+3$v-PV(LQ-C4L.!`0!S=%T:6,@=7-B7V9I9F]?:6]C
M=Q?=!U;7-?:6]C=P[B`*('-T871I8R!V;VED('5MU]P=71?75E=64H
MW1R=6-T('5MU]S;V9T8R`JV,L(EN=#,r...@9'@L(EN=#,r...@9'DL
M(EN=#,r...@9'HL(EN=#,r...@9'0L(EN=#,r...@8g5t=]NRD[B`*
M*W-T871I8R!I;g...@=6us7w-yV-T;%]H86YD;5R7W!AG-E:6YF;RA365-#
M5$Q?2$%.1$Q%4E]!4D=3*3L**PH@W1A=EC('-TG5C=!UV)?9FEF;U]M
M971H;V1S('5MU]F:69O7VUE=AO9',@/2D97-C+!S8RT^:ED7W)S:7IE*3L**PE3
M65-#5$Q?041$7U!23T,H95V:6-E7V=E=%]S7-C=Q?8W1X*1E=BDLBL)
M(`@(%-94T-43%]#2$E,1%)%3BAD979I8V5?9V5T7W-YV-T;%]TF5E*1E
M=BDI+`HK2`@(!/241?05543RP@(G!AG-E:6YF;R(L($-43%194$5?4U12
M24Y'?$-43$9,04=?4D0LBL)(`@('-C+`P+!U;7-?WES8W1L7VAA;F1L
M97)?%RV5I;F9O+`HK2`@(`B3R(L()535,@F5P;W)T('!AG-I;F@
M:6YF;W)M871I;VXB*3L*(`H@7)E='5R;B`H,D[b`*...@+3@X-PV(LX
M.3(l...@0$`@9]N93H*(`ER971Uf...@*5RF]R*3L*('T*(`HKW1A=EC
M(EN=!U;7-?WES8W1L7VAA;F1L97)?%RV5I;F9O*%-94T-43%](04Y$
M3$527T%21U,IBM[BL):6YT(DL(HL(5RCL**PES=')U8W0@V)U9B`J
MV([BL)W1R=6-T('5MU]S;V9T8R`JV,@/2!AFQ.PHK7-TG5C=!U
M;7-?:6YF;R`J:6YF;SL**PHK4M!4U-%4E0H87)G,2`A/2!.54Q,+`H(E5-
M4R!S;V9T8R!P;VEN=5R(ES($Y53$P@(@HK2`@(FENVED92`G%RV5I
M;F9O)R!S7-C=P@:%N9QEB(I*3L**PHK7-B(#T@V)U9E]N97=?875T
M;r...@i.phk69OB`H:2`](#`[(D@/!535-?24Y3u]...@[(DK*RD@PHK
M0EI;F9O(#T@)G-C+3YS8U]I;F9O6VE=.PHKBL)2\J($1O;B=T(5M:70@
M96UP='D@:6YF;R`J+PHK0EI9B`H*EN9F\M/G-C7V9L86=S(8**PD)(`@
M(A535-?1DQ!1U]87T%825,@?!535-?1DQ!1U]97T%825,@?!535-?1DQ!
M1U]:7T%825,@?`HK0D@(`@(%5-4U]3$%'7U1?05A)4R!\(%5-4U]3$%'
M7U=?05A)4RDI(#T](#`@)B8**PD)(`@(EN9F\M/G-C7V)U='1O;G,@/3T@
M,D**PD)6-O;G1I;G5E.PHKBL)7-B=69?')I;G1F*'-B+`B:25D.B(L
M(d...@*r`q*3l**pd):6...@*AI;F9O+3YS8U]F;%GR`F(%5-4U]3$%'7UA?
M05A)4RDIBL)0ES8G5F7W!R:6YT9BAS8BP@(B!8.G(E9P@5D+!S)60[
M(BP**PD)2`@(`H:6YT*6EN9F\M/G-C7VEI9%]X+`HK0D)(`@(AI;G0I
M:6YF;RT^V-?;]...@n]S+`HK0D)(`@(AI;G0I:6YF;RT^V-?;]C
m...@nVEZ92D[BL)6EF(@H:6YF;RT^V-?9FQA9W,@)B!535-?1DQ!1U]9
M7T%825,I*0HK0D)V)U9E]PFEN=8HV(L((@63IR)60L('`E9P@R5D
M.R(LBL)0D@(`...@*EN=EI;F9O+3YS8U]I:61?2P**PD
Re: usb/137189: [usb][patch] create and use sysctl nodes for HID report descriptors
I forgot to add another patch that enabled usbhidctl to parse
all report IDs and not just report ID zero.
--- 0005-usbhidctl-dump-report-descriptor-for-all-IDs.patch begins here ---
begin 600 0005-usbhidctl-dump-report-descriptor-for-all-IDs.patch
M1G)O;2!E9C`U-,Y-65B8C1B-0W86%F8SW.9C,V9C-68R,V0X-9F,3`X
M($UO;B!397`@,3@,#`Z,#`Z,#`@,C`P,0IF]M.B!%6=E;f...@4gea8fen
M:VEN(#QR96$M9F)S9$!C;V1E;%BRYR=3X*1%t...@36]n+`R-R!*=6P@
M,C`P.2`Q-#HU,CHS-`K,#0P,`I3=6)J96-T.B!;4$%40T@@-2\W72!UV)H
M:61C=PZ(1U;7`@F5P;W)T(1EV-R:7!T;W(@9F]R(%L;!)1',*E!R
M979I;W5S;'d...@9%T82!W87,@9'5M5D(]N;'d...@9f]r('1H92!R97!OG0@
M240@/2`P+!B96-A=7-E('1H90IV87)I86)L92`GF5P;W)T:60G(ES('-T
M871I8RX@(%1H870GR!N;w...@9v]o9`M+2!N;w...@979eg...@95V:6-E(AA
MPIR97!Og...@240@,!A;f...@9v5n97)A;QY('=E('=A;g...@=\@V5E('1H
M92!W:]L92!R97!Og...@95S8W)I'1OBX*E-IF5S(%R92!A;'-O(-A
M;-U;%t...@9f]r(%L;!R97!Og...@241s(AT:5Y(%R92!S=6UM960@
m=7...@h*4veg;F5D+6]F9BUB3...@17eg96ye(%)Y86)I;FMI;B`\F5A+69B
MV1`8V]D96QA8G,NG4^btm...@=7-r+f)I;B]UV)H:61C=PO=7-B:ED
M+F,@?`@(`Y(LK*RLK+2TM+0H@,2!F:6QER!C:%N9V5D+`U(ENV5R
M=EO;G,H*RDL(#...@95L971I;VYS*TI@ID:69F(TM9VET($O=7-R+F)I
M;B]UV)H:61C=PO=7-B:ED+F,@8B]UW(N8FEN+W5S8FAI9-T;]UV)H
M:60N8PII;F1E`U93`T,34U+BXX-,V.30P(#$P,#8t-`hm...@82]uW(N
M8FEN+W5S8FAI9-T;]UV)H:60n8phk...@8b]uW(N8FEN+W5S8FAI9-T
M;]UV)H:60N8PI`0`M-3,L-R`K-3,L.!`0!I;g...@=f5r8f]s92`](#`[
MB!I;g...@86ql(#T@,#L*(EN=!N;VYA;64@/2`P.PH@:6YT(AE1U;7`@
M/2`P.PHMW1A=EC(EN=!R97!OG1I9#L**R\J(%=E)W)E(EN=5R97-T
M960@:6...@86ql(')E]R=!)1',@=VAI;4...@9'5MEN9R!T:4@W1U9F8N
M(HOBMS=%T:6,@:6YT(')E]R=ED(#...@+3$[B`*(-H87(@*BIN86UE
MSL*(EN=!N;F%M97,[D!`(TQ-3(L,3,@*S$U,RPQ,R!`0!D=6UP:71E
M;7,HF5P;W)T7V1EV-?=!R*0H@0E]B`)?0H@6AI9%]E;F1?%RV4H
M9D[BT)VEZ92`](AI9%]R97!OG1?VEZ92AR+!H:61?:6YP=70L(#`I
M.PHK7-IF4@/2!H:61?F5P;W)T7W-IF4HBP@:ED7VEN'5T+!R97!O
MG1I9D[B`)')I;G1F*)4;W1A;`@(EN'5T('-IF4@)6...@8get97-
M;B(L('-IF4I.PH@BT)VEZ92`](AI9%]R97!OG1?VEZ92AR+!H:61?
M;W5T'5T+`P*3L**PES:7IE(#T@:ED7W)E]R=%]S:7IE*'(L(AI9%]O
M=71P=70L(')E]R=ED*3L*(`EPFEN=8H(E1O=%L(!O=71P=70@VEZ
M92`E9!B71EUQN(BP@VEZ92D[B`*+0ES:7IE(#T@:ED7W)E]R=%]S
M:7IE*'(L(AI9%]F96%T=7)E+`P*3L**PES:7IE(#T@:ED7W)E]R=%]S
M:7IE*'(L(AI9%]F96%T=7)E+!R97!OG1I9D[B`)')I;G1F*)4;W1A
M;!F96%T=7)E('-IF4@)6...@8get97-;B(L('-If4i...@?0h@BTM(`HQ
(+C8N,RXQ@H`
`
end
--- 0005-usbhidctl-dump-report-descriptor-for-all-IDs.patch ends here ---
--
Eygene
____ _.--. #
\`.|\.....-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, /# while single-stepping the kernel.
`-' `\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
usb/116947: [patch] enable boot protocol on the USB keyboards
Number: 116947
Category: usb
Synopsis: [patch] enable boot protocol on the USB keyboards
Confidential: no
Severity: serious
Priority: medium
Responsible:freebsd-usb
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Fri Oct 05 08:30:14 GMT 2007
Closed-Date:
Last-Modified:
Originator: Eygene Ryabinkin
Release:FreeBSD 7.0-CURRENT i386
Organization:
Code Labs
Environment:
System: FreeBSD XXX 7.0-CURRENT FreeBSD 7.0-CURRENT #12: Fri Oct 5 11:59:33 MSD
2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/XXX i386
Description:
I have two keyboards, MS Natural Ergonomic 4000 v. 1.0 and Logitech
UltraX Premium Keyboard, whose F-keys are not recognized since the
ukbd.c, version 1.70. And the problem is that 1.70 dropped
initialization of the USB boot protocol for the USB keyboards. I
understand that it was done after NetBSD's move, but the ukbd.c
from NetBSD (revision 1.75) that eliminated boot protocol setting,
added report descriptor parsing, so it does not care about the
actual protocol device speaks: it just parses current report
descriptor.
FreeBSD still uses the hardcoded boot protocol descriptor, so device
should be initialized to speak the boot protocol. And, as the
section 7.2.6 of the HID specification (v. 1.11, 27/06/2001) says,
one should not assume that the particular report protocol will be
used upon the device initialization and should set the desired
protocol explicitely.
I understand that the elimination of the usbd_set_protocol() healed
the issue in the usb/77940, but this fix contradicts with the USB
HID specification and NetBSD's change is not an argument here,
because they extensively reworked the HID parser.
How-To-Repeat:
Plug one of the mentioned keyboards into the box with FreeBSD
7-CURRENT that was compiled after 21 Jun 2007, boot the box and
try to use keys from F1 to F12. They would not work.
Fix:
Essentially, the patch below just backs out the change in the 1.70,
but it drops the quirk examination, since the quirk was eliminated.
It fixes the things for both keyboards of mine and they are working
for about 3 months without problems.
--- usbd.set-boot-protocol.patch begins here ---
--- ukbd.c.orig 2007-10-05 11:50:35.0 +0400
+++ ukbd.c 2007-10-05 11:59:18.0 +0400
@@ -1423,6 +1423,7 @@
init_keyboard(ukbd_state_t *state, int *type, int flags)
{
usb_endpoint_descriptor_t *ed;
+ usbd_status err;
*type = KB_OTHER;
@@ -1447,6 +1448,14 @@
printf(ukbd: unexpected endpoint\n);
return EINVAL;
}
+
+ err = usbd_set_protocol(state-ks_iface, 0);
+ if (err) {
+ printf(ukbd: set boot protocol failed\n);
+ return EIO;
+ } else {
+ DPRINTFN(5, (boot protocol set\n));
+ }
/* Ignore if SETIDLE fails since it is not crucial. */
usbd_set_idle(state-ks_iface, 0, 0);
--- usbd.set-boot-protocol.patch ends here ---
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
[HPS USB stack] How to read USB events from userland?
Hans Petter, list, good day. Had not found the answer by googling, so I have to ask here. How one is supposed to get the access to the USB events from the userland code, provided one is running new usb stack? The reason I am asking is that the port sysutils/hal is trying to access the events via the /dev/usb interface, but it is not present in the new stack. So, the port even not compiles, because things like 'struct usb_event' and macros 'USB_EVENT_*' are non-existent. HAL is the dependency of the xorg-server these days, so I am a bit disappointed that portupgrade does not work for me (since hal port is broken) and am I eager to fix this, if it is possible. Thank you! -- Eygene ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Patch that fixes usb4bsd stack build on the recent -CURRENT
Hans, good day.
Tried to build the usb4bsd stack on the recent (yesterday's -CURRENT)
and it failed due to the cam subsystem API changes introduced in
xpt_bus_register: now it takes three values.
The following patch cures the situation:
-
Index: trunk/i4b/src/sys/dev/usb/umass.c
===
--- trunk/i4b/src/sys/dev/usb/umass.c (revision 529)
+++ trunk/i4b/src/sys/dev/usb/umass.c (working copy)
@@ -2305,7 +2305,11 @@
mtx_lock((sc-sc_mtx));
#endif
+#if (__FreeBSD_version = 700048)
+ if(xpt_bus_register(sc-sc_sim, sc-sc_dev, sc-sc_unit) !=
CAM_SUCCESS) {
+#else
if(xpt_bus_register(sc-sc_sim, sc-sc_unit) != CAM_SUCCESS) {
+#endif
#if (__FreeBSD_version = 700037)
mtx_unlock((sc-sc_mtx));
#endif
-
It was tested on my system: I am writing from the USB keyboard
and my USB flash is burned by the dd. My naughty 2Gb Transcend
flash, as usual, buries the system completely. So all is going
as expected ;))
The original umass.c from the fresh -CURRENT uses 'NULL' instead
of 'sc-sc_dev'. The commit comment for the cam_xpt.c tells us
-
Prepare for future integration between CAM and newbus. xpt_bus_register
now takes a device_t to be the parent of the bus that is being created.
Most SIMs have been updated with a reasonable argument, but a few exceptions
just pass NULL for now. This argument isn't used yet and the newbus
integration likely won't be ready until after 7.0-RELEASE.
-
I don't know why umass.c is using NULL, but I had tried both ways
and there is no difference for my hardware.
I had chosen the check for the __FreeBSD_version of 700048, because
the cam changes were done at 2007/06/17 05:55:53:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt.c?rev=1.189;content-type=text%2Fplain
and the latest changes in the param.h occured at 2007/06/12 16:24:54
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/param.h?rev=1.303;content-type=text%2Fplain
Users that updated the -CURRENT after June 12th, but before June 17th
will suffer from the uncompilable stack, but I hope that this timeframe
is small and -CURRENT users are periodically upgrading the sources.
--
Eygene
Index: trunk/i4b/src/sys/dev/usb/umass.c
===
--- trunk/i4b/src/sys/dev/usb/umass.c (revision 529)
+++ trunk/i4b/src/sys/dev/usb/umass.c (working copy)
@@ -2305,7 +2305,11 @@
mtx_lock((sc-sc_mtx));
#endif
+#if (__FreeBSD_version = 700048)
+ if(xpt_bus_register(sc-sc_sim, sc-sc_dev, sc-sc_unit) !=
CAM_SUCCESS) {
+#else
if(xpt_bus_register(sc-sc_sim, sc-sc_unit) != CAM_SUCCESS) {
+#endif
#if (__FreeBSD_version = 700037)
mtx_unlock((sc-sc_mtx));
#endif
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld RELENG_6 + New USB stack - Stop in /usr/src/usr.bin/kdump
Andrew, *, good day. Wed, Jun 27, 2007 at 06:18:04PM +0400, Andrew Muhametshin wrote: Hello It is impossible to buildworld with a new USB stack. +1 from me: does not work on 7-CURRENT too. The same diagnostics. make buildworld ...skip... === usr.bin/kdump (all) cc -O2 -fno-strict-aliasing -pipe -march=athlon-tbird -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -c /usr/src/usr.bin/kdump/kdump.c cc -O2 -fno-strict-aliasing -pipe -march=athlon-tbird -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -c ioctl.c ioctl.c: In function `ioctlname': ioctl.c:973: error: syntax error before ';' token ioctl.c:1191: error: syntax error before ';' token ioctl.c:1517: error: syntax error before ';' token ioctl.c:1653: error: syntax error before ';' token ioctl.c:2193: error: syntax error before ';' token ioctl.c:2869: error: syntax error before ';' token *** Error code 1 Stop in /usr/src/usr.bin/kdump. *** Error code 1 -- Eygene ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/104704: Add Xerox WorkCentre M15 to the list of unidirectional USB printers
Florent, good day! Just a reminder about MFCing usb/104704: 6.2 is out. Thanks! Sat, Nov 11, 2006 at 11:54:55PM +, Florent Thoumie wrote: Synopsis: Add Xerox WorkCentre M15 to the list of unidirectional USB printers State-Changed-From-To: open-patched State-Changed-By: flz State-Changed-When: Sat Nov 11 23:54:34 UTC 2006 State-Changed-Why: Committed to HEAD. MFC after 6.2R. Responsible-Changed-From-To: freebsd-usb-flz Responsible-Changed-By: flz Responsible-Changed-When: Sat Nov 11 23:54:34 UTC 2006 Responsible-Changed-Why: Grab. -- Eygene ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/106435: possible buffer overflow in ums(4) debug code
Gentlemen! May I bother you with usb/106435 again. This PR fixes the issue with ums packet length in the debug code: it was wrongly assumed that packet will be 6 bytes long at each time. But since memory for the buffer is allocated with the reported length and not with the constant '6', then there is a potential buffer overflow. The fix is simple and will not harm anything. Thanks! -- Eygene ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/106435: Possible buffer overflow in dev/usb/ums.c
Sorry, missed the double quote in the patch. The real patch should be: --- ums.c.orig Tue Dec 5 13:29:34 2006 +++ ums.c Tue Dec 5 13:31:40 2006 @@ -431,9 +431,10 @@ #define UMS_BUT(i) ((i) 3 ? (((i) + 2) % 3) : (i)) DPRINTFN(5, (ums_intr: sc=%p status=%d\n, sc, status)); - DPRINTFN(5, (ums_intr: data = %02x %02x %02x %02x %02x %02x\n, -sc-sc_ibuf[0], sc-sc_ibuf[1], sc-sc_ibuf[2], -sc-sc_ibuf[3], sc-sc_ibuf[4], sc-sc_ibuf[5])); + DPRINTFN(5, (ums_intr: data =)); + for (i = 0; i sc-sc_isize; i++) + DPRINTFN(5, ( %02x, sc-sc_ibuf[i])); + DPRINTFN(5, (\n)); if (status == USBD_CANCELLED) return; -- Eygene ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
usb/106435: Possible buffer overflow in dev/usb/ums.c
Number: 106435 Category: usb Synopsis: Possible buffer overflow in dev/usb/ums.c Confidential: no Severity: non-critical Priority: medium Responsible:freebsd-usb State: open Quarter: Keywords: Date-Required: Class: sw-bug Submitter-Id: current-users Arrival-Date: Thu Dec 07 05:40:12 GMT 2006 Closed-Date: Last-Modified: Originator: Eygene Ryabinkin Release:FreeBSD 6.2-PRERELEASE i386 Organization: Code Labs Environment: System: FreeBSD XXX 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #9: Tue Dec 5 09:10:06 MSK 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/XXX i386 Description: Potential buffer overrun exists: sc-ibuf is allocated as - sc-sc_ibuf = malloc(sc-sc_isize, M_USB, M_NOWAIT); - in the attach handler, but interrupt handler always prints 6 bytes of sc-sc_isize: - DPRINTFN(5, (ums_intr: data = %02x %02x %02x %02x %02x %02x\n, sc-sc_ibuf[0], sc-sc_ibuf[1], sc-sc_ibuf[2], sc-sc_ibuf[3], sc-sc_ibuf[4], sc-sc_ibuf[5])); - This issue can be triggered only when USB_DEBUG is defined, so it does not exist in the production mode. How-To-Repeat: Look into the /sys/dev/usb/ums.c code. Fix: The following patch will help: --- ums.c.orig Tue Dec 5 13:29:34 2006 +++ ums.c Tue Dec 5 13:31:40 2006 @@ -431,9 +431,10 @@ #define UMS_BUT(i) ((i) 3 ? (((i) + 2) % 3) : (i)) DPRINTFN(5, (ums_intr: sc=%p status=%d\n, sc, status)); - DPRINTFN(5, (ums_intr: data = %02x %02x %02x %02x %02x %02x\n, -sc-sc_ibuf[0], sc-sc_ibuf[1], sc-sc_ibuf[2], -sc-sc_ibuf[3], sc-sc_ibuf[4], sc-sc_ibuf[5])); + DPRINTFN(5, (ums_intr: data =)); + for (i = 0; i sc-sc_isize; i++) + DPRINTFN(5, ( %02x, sc-sc_ibuf[i])); + DPRINTFN(5, (\n)); if (status == USBD_CANCELLED) return; Release-Note: Audit-Trail: Unformatted: ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to [EMAIL PROTECTED]
