On Sat, 2 Dec 2006, Adam Sulmicki wrote:

> now, this is bizzare, according to usbmon 'modprobe usbkbd' generages
> a single event :
> 
>          c8be93c0 709211974 S Ii:004:01 -115 8 <
> 
> It seems this single event is enough for the remote to work again.

No, you have misinterpreted what is happening.  It's not clear from the
log what gets the remote to start working again, but that event definitely
isn't it.  In fact, if you check the log you'll see the same sort of event
when you modprobe usbhid.

> full log at :
> 
>          http://www.missl.cs.umd.edu/~adam/cy/usbmon.txt
> 
> -----------------------------------------------------
> 
> c8be93c0                URB Tag (adress)
> 709211974               timestamp
> S                       submission
> Ii                      interrupt input
> 004                     device addres
> 1                       endpoint number
> -115                    N/A for submission
> 8                       length
> <                       missing data
> 
> -----------------------------------------------------
> 
> where can I find hacked version of usbmon that dumps whole data?

You don't need it; the log already contains all the important information.  
For instance, that '<' at the end of the line doesn't mean any data was
left out of the dump; it means that no data was there in the first place.  
Not surprising, since this line shows the computer asking the remote to
report on any button presses, so of course there won't be any data --
the computer is _asking_ for the data.

> is it ready for prime time?

No.

> Also how do I decode address field, given :
> 
>       # cat 1t
>       c9b69640 4089458779 S Ii:002:01 -115 8 <

You can't decode it, since it doesn't mean anything useful.

> I have tried :
> 
>       # grep -i ^c9b /proc/kallsyms
> 
> but no results.
> 
> # tail /proc/kallsyms
> c013e4dd U __kmalloc    [usbcore]
> ca87c1e0 d usb_generic_driver   [usbcore]
> c01479f3 U cdev_del     [usbcore]
> c0117a6d U __request_region     [usbcore]
> ca86185f t usb_alloc_dev        [usbcore]
> c023f8da U device_remove_file   [usbcore]
> ca8652f2 t usb_root_hub_lost_power      [usbcore]
> c015a705 U simple_pin_fs        [usbcore]
> c0240b58 U bus_register [usbcore]
> ca8655d7 t usb_mon_register     [usbcore]

It's not going to be in there.  And even if it were, it wouldn't tell you 
anything except perhaps that the URB was sent by usbhid, which you already 
know.

Alan Stern


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to