Date: Sun, 23 Oct 2005 11:34:10 -0400 From: Kris Maglione <bsdaemon@comcast.net> To: "Loren M. Lang" <lorenl@alzatex.com> Cc: freebsd-usb@freebsd.org Subject: Re: USB mouse, wheel doesn't work Message-ID: <20051023153314.GA54912@kris.home> In-Reply-To: <20051023053600.GA18930@alzatex.com> References: <20051021230147.GA40893@kris.home> <20051023053600.GA18930@alzatex.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 22, 2005 at 10:36:00PM -0700, Loren M. Lang wrote:
>Can you post the HID report descriptor for that device? All the
>information about the wheel should be described in there. I have a
>crude program to do that if you need.
This is the debug info that attach spits out. It's based on the HID
descriptor:
ums_attach: sc=0xc1ca8400
ums_attach: X 8/8
ums_attach: Y 16/8
ums_attach: Z 24/8
ums_attach: B1 0/1
ums_attach: B2 1/1
ums_attach: B3 2/1
ums_attach: B4 3/1
ums_attach: B5 4/1
ums_attach: B6 32/1
ums_attach: B7 33/1
ums_attach: size=15, id=0
Read as <Bits offset>/<Bits long>
Here's what usbhidctl shows:
# usbhidctl -f /dev/uhid0 -r
Report descriptor:
Total input size 0 bytes
Total output size 5 bytes
Total feature size 2 bytes
I also tried another experiment; a basic perl script with /dev/uhid0 as STDIN:
for (1..150) {
my $data;
sysread STDIN, $data, 150; # The max length it will read is 15
my @data = split //, $data;
@data = map { ord } @data;
printf "%02x %02x %02x %02x %02x -- " splice @data, 0, 5 for (1..3);
print "\n";
}
I got the same results as before: only the first three bytes ever changed, the
rest were filled with the same junk from the malloc.
--
Kris Maglione
You may know where the market is going, but you can't
possibly know where it's going after that.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051023153314.GA54912>