Re: [linux-usb-devel] hiddev
On Fri, 10 Aug 2007, Folkert van Heusden wrote: HIDIOCGSTRING - struct hiddev_string_descriptor (read/write) Gets a string descriptor from the device. The caller must fill in the index field to indicate which descriptor should be returned. Can you please tell me in what range this index is? Please refer to USB specification. The string descriptor indexes are fully optional and are referenced by the other descriptors (device descriptors, configuration descriptors, etc). So the valid range differs from device to device and depends of how much of the descriptor information has available the corresponding string (human readable) representation. -- Jiri Kosina - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] EHCI Regression in 2.6.23-rc2
On Fri, 10 Aug 2007, Daniel Exner wrote: Please CC me, as I'm currently not subscribed to this list, thx. Please also don't forget to CC relevant people/lists when reporting bugs, thanks. After some serious hangs with 2.6.23-rc2 I did some bisects and this was the result: 196705c9bbc03540429b0f7cf9ee35c2f928a534 is first bad commit commit 196705c9bbc03540429b0f7cf9ee35c2f928a534 Author: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thu May 3 08:58:49 2007 -0700 I guess that the patch attached to bug 8535 in kernel.org bugzilla -- http://bugzilla.kernel.org/attachment.cgi?id=12228action=view -- solves your issues, right? Stuart, did you submit this fix for upstream already please? -- Jiri Kosina - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes
On Fri, 3 Aug 2007, Adam Kropelin wrote: Although I have no proof immediately at hand, I suspect at a minimum HID power class devices should be blacklisted from autosuspend. Given the spotty USB implementations on many such devices I'd be surprised if suspend worked reliably. I agree here. Plus if you're connected to such a device for monitoring purposes you're probably powered by it as well, so you have little to gain from suspend even if it works. I currently don't have any HID UPS by hand to verify, but I'd be surprised if they would advertise remote wakeup capability ... ? Thanks, -- Jiri Kosina - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] USB: Only enable a utosuspend by default on certain device classes
On Fri, 3 Aug 2007, David Brownell wrote: And could you elaborate on many? What proportion of HID devices (by volume, model, etc) seem to have problems? Last time I tried with two random USB keyboards - one from Logitech and one from Chicony, I don't remember the exact PIDs, but could look them up if it is interesting for someone. The specific failure I saw was that the device advertised itself as supporting remote wakeup, but it couldn't issue that signaling. It came back from suspend just fine ... but moving or clicking would not do what it should. What I have been seeing with both these keyboards was: if connected to UHCI controller, root hub not auto-suspended, as soon as they got autosuspended, and keys were pressed on them rapidly, very often some keypressess got lost. I didn't experience this on OHCI, but I remember Alan saying that he triggered it on OHCI too, right? Seemed like a timing issue - by lowering the polling timeout we were able to make things much better, but that of course costs us more power etc. and it's even not sure if it is an ultimate solution. -- Jiri Kosina - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes
On Fri, 3 Aug 2007, Dave Jones wrote: Interesting. Which devices did you notice failing? Was it a case that they would sleep and not come back out of that state? Random keyboards, even connection to EHCI/OHCI seemed to make difference. We have been doing some experiments with Alan during OLS and it seemed quite hopeless. A few keyboards we have been testing with seemed to be losing keypressess when coming out of suspend (if and only if the root hub wasn't suspended too, etc. Magic). -- Jiri Kosina - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] USB: Only enable autosuspend by default on certain device classes
On Fri, 3 Aug 2007, Matthew Garrett wrote: Windows will autosuspend hubs, bluetooth devices, HID devices Hi Matthew, are you sure about windows suspending the HID devices in runtime? I have never seen LEDs of USB keyboard connected to windows host to go off after some time of not using it. We have been playing with runtime autosuspend of HID devices, are currently postponed the full support, as it turns out that many devices don't support this feature properly (probably due to not being tested in Windows). -- Jiri Kosina - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.23-rc1-mm2
On Thu, 2 Aug 2007, Alan Stern wrote: uhci_hcd :00:0c.0: dma_pool_free buffer-32, 6b6b6b6b/6b6b6b6b (bad dma) I guess the patch below (which I have just added to my tree) fixes that, right? Thanks. Yes - that's correct. This patch fixes the bug. Thanks. Does it also fix the dma_pool_free error? I believe it should -- caused by calling usb_buffer_free() with bogus dma_addr_t, as corresponding usbhid_device has been already kfree()d. -- Jiri Kosina - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.23-rc1-mm2
(CCs adjusted) On Wed, 1 Aug 2007, Andrew Morton wrote: usb 2-1: USB disconnect, address 2 BUG: atomic counter underflow at: [c010456a] show_trace_log_lvl+0x1a/0x30 [c010508d] show_trace+0x12/0x14 [c01051e0] dump_stack+0x15/0x17 [c01418cf] __free_pages+0x50/0x52 [c01418f0] free_pages+0x1f/0x21 [c010783d] dma_free_coherent+0x43/0x9c [c0315067] hcd_buffer_free+0x43/0x6a [c030b2b4] usb_buffer_free+0x23/0x29 [c0346db4] hid_free_buffers+0x23/0x71 [c0346eb2] hid_disconnect+0xb0/0xc8 [c0313676] usb_unbind_interface+0x30/0x72 [c02c6df0] __device_release_driver+0x6a/0x92 [c02c71c3] device_release_driver+0x20/0x36 [c02c6736] bus_remove_device+0x62/0x85 [c02c49f8] device_del+0x16d/0x27c [c0310f25] usb_disable_device+0x7a/0xe2 [c030d0bc] usb_disconnect+0x94/0xde [c030e030] hub_thread+0x2fe/0xc1b [c0128aee] kthread+0x36/0x58 [c0104233] kernel_thread_helper+0x7/0x14 === uhci_hcd :00:0c.0: dma_pool_free buffer-32, 6b6b6b6b/6b6b6b6b (bad dma) Mariusz, I guess the patch below (which I have just added to my tree) fixes that, right? Thanks. diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c index 6e73934..0a1f2b5 100644 --- a/drivers/hid/usbhid/hid-core.c +++ b/drivers/hid/usbhid/hid-core.c @@ -877,9 +877,9 @@ fail: usb_free_urb(usbhid-urbin); usb_free_urb(usbhid-urbout); usb_free_urb(usbhid-urbctrl); + hid_free_buffers(dev, hid); kfree(usbhid); fail_no_usbhid: - hid_free_buffers(dev, hid); hid_free_device(hid); return NULL; @@ -913,9 +913,9 @@ static void hid_disconnect(struct usb_interface *intf) usb_free_urb(usbhid-urbin); usb_free_urb(usbhid-urbctrl); usb_free_urb(usbhid-urbout); - kfree(usbhid); hid_free_buffers(hid_to_usb_dev(hid), hid); + kfree(usbhid); hid_free_device(hid); } - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Cleaning up the USBHID's blacklist.
On Tue, 31 Jul 2007, Chr wrote: But I have one (final?) question. Since I am sometimes stuck to 80x25 console... can we alphabetically sort the blacklist by the Vendor (the first field), instead of the quirk field(last field)? Or is there a technical/theoretical reason behind it? I find the blacklist sorted by quirk type more convenient - we typically want to know who has this particular quirk, but we generally don't care what quirks does this particular vendor have. -- Jiri Kosina - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usbhid: add ASUS LCM to the blacklist
On Mon, 30 Jul 2007, Chr wrote:
Ok, found it hid_blacklist is alphabetically sorted blacklist by quirk
type. But is there a Order for the bitfields? e.g
shouldn't: hid-quriks.c (line 439, 440)
{ USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_ANSI,
HID_QUIRK_POWERBOOK_HAS_FN | HID_QUIRK_IGNORE_MOUSE }
be:
{..., ..., HID_QUIRK_IGNORE_MOUSE | HID_QUIRK_POWERBOOK_HAS_FN }
This could be a possible cleanup for hid_blacklist[], if you are going to
make a patch I will happily accept it.
Thanks,
--
Jiri Kosina
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid keyboard packet from interrupt IN pipe
On Wed, 25 Jul 2007, Gabriel Maganis wrote: Is there anyway I can get an hid keyboard (a Dell, in my case) to send the host packets via the interrupt IN pipe i.e. something like emulating keypresses? Could you please be more specific about what you are trying to achieve? You want to make your USB keyboard to send the reports even if no key was pressed, or what? Thanks, -- Jiri Kosina - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch]minimal autosuspend support for USB HID devices
On Tue, 17 Jul 2007, Greg KH wrote: autosuspend for USB HID devices remains problematic as far as mice and keyboards are concerned. While I am working on a grand solution, here's a minimalist patch that works for those devices not continously in use. It'll work for joystick and some other devices. Signed-off-by: Oliver Neukum [EMAIL PROTECTED] Jiri, I'm guessing this will go through your tree? If so, feel free to add: Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] from me to the patch. Hi Greg, sorry for late reply, I was on vacation. Yes, this has been sitting in my tree for quite a some time already. Thanks a lot, -- Jiri Kosina - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH pd55] Add all Logitech Harmonies to HID blacklist
On Wed, 25 Jul 2007, Phil Dibowitz wrote: This patch adds the entire range of Logitech's ProductIDs that are reserved for their Harmony remotes. The in-kernel HID driver can't do anything with these, and now there is a GPL user-space application that can handle them: http://www.sf.net/projects/harmonycontrol I applied your cleaned-up .23 patch to my tree, thanks (sorry for not replying sooner, I was offline on vacation for quite some time). -- Jiri Kosina - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usbhid: add ASUS LCM to the blacklist
On Fri, 27 Jul 2007, Christian Lamparter wrote: Some of ASUS' notebooks (e.g G Series) include a tiny oled display, which is attached to an internal USB bus. Unfortunatly the device reports a wrong DeviceDescriptor and is therefore identified as a HID device... Hi Christian, I have slightly modified your patch (let's keep the hid_blacklist[] properly sorted) and applied it into my tree. Thanks, -- Jiri Kosina - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [patch]minimal autosuspend support for USB HID devices
On Wed, 11 Jul 2007, Oliver Neukum wrote: autosuspend for USB HID devices remains problematic as far as mice and keyboards are concerned. While I am working on a grand solution, here's a minimalist patch that works for those devices not continously in use. Hi Oliver, I like this patch until the ultimate solution comes (if there is any at all). Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [2.6.22-rc7] khubd NULL deref oops...
dfc9a600 dfc9a608 f8a12ac0 c0255e59 f8a12b88 [ 4771.448000]dfc9a600 dfc9a494 0246 c0255ee8 dfc9a400 f89f9b56 dfc9a400 [ 4771.448000]efc26800 f89f71fb efc26830 efc26800 f89f17e5 efc26af8 f41ce818 f8be1100 [ 4771.448000] Call Trace: [ 4771.448000] [c0255e59] class_device_del+0x99/0x120 [ 4771.448000] [c0255ee8] class_device_unregister+0x8/0x10 [ 4771.448000] [f89f9b56] __scsi_remove_device+0x26/0x60 [scsi_mod] [ 4771.448000] [f89f71fb] scsi_forget_host+0x4b/0x60 [scsi_mod] [ 4771.448000] [f89f17e5] scsi_remove_host+0x55/0xe0 [scsi_mod] [ 4771.448000] [f8bd2c3e] storage_disconnect+0xe/0x20 [usb_storage] [ 4771.448000] [f8a4ea24] usb_unbind_interface+0x44/0x90 [usbcore] [ 4771.448000] [c0255408] __device_release_driver+0x68/0xa0 [ 4771.448000] [c0255813] device_release_driver+0x23/0x40 [ 4771.448000] [c0254d1c] bus_remove_device+0x5c/0x90 [ 4771.448000] [c0253020] device_del+0x160/0x260 [ 4771.448000] [f8a4bf28] usb_disable_device+0x78/0xe0 [usbcore] [ 4771.448000] [f8a48285] usb_disconnect+0x95/0x130 [usbcore] [ 4771.448000] [f8a48910] hub_thread+0x270/0xc30 [usbcore] [ 4771.448000] [c012a4e6] do_exit+0x516/0x800 [ 4771.448000] [c0139b00] autoremove_wake_function+0x0/0x40 [ 4771.448000] [f8a486a0] hub_thread+0x0/0xc30 [usbcore] [ 4771.448000] [c0139834] kthread+0x34/0x60 [ 4771.448000] [c0139800] kthread+0x0/0x60 [ 4771.448000] [c0105397] kernel_thread_helper+0x7/0x10 [ 4771.448000] === [ 4771.448000] Code: 00 00 00 00 55 57 56 53 83 ec 04 31 ed 83 cb ff 89 c6 89 c7 89 14 24 89 d9 89 e8 f2 ae f7 d1 49 8b 04 24 89 ca 89 d9 8b 38 89 e8 f2 ae f7 d1 49 8d 44 0a 02 ba d0 00 00 00 e8 06 36 f2 ff 31 d2 [ 4771.448000] EIP: [c0255cc7] make_class_name+0x27/0x80 SS:ESP 0068:f7d05e5c [ 4771.448000] sd 6:0:0:0: [sdb] Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK,SUGGEST_OK [ 4771.448000] end_request: I/O error, dev sdb, sector 163846928 [ 4771.448000] printk: 84 messages suppressed. [ 4771.448000] Buffer I/O error on device sdb, logical block 20480866 [ 4771.448000] Buffer I/O error on device sdb, logical block 20480866 [ 4771.448000] [ 4771.448000] sd 6:0:0:0: [sdb] Attached SCSI disk [ 4771.448000] sd 6:0:0:0: Attached scsi generic sg2 type 0 [ 4771.556000] Buffer I/O error on device sdb, logical block 30015200 -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB mouse autosuspend
On Wed, 4 Jul 2007, Kay Sievers wrote: It's a recent standard and cheap Logitec mouse. If you can't reproduce it, let me know if I should try to capture the traffic. Hi Kay and Alan, actually I found a random logitech optical mouse here (VID:PID 046d:c019) and can observe precisely the same thing. box:/sys/kernel/debug/usbmon # rmmod usbhid box:/sys/kernel/debug/usbmon # cat 0t dfa47680 2300684403 S Ci:001:00 s 80 00 0002 2 dfa47680 2300684419 C Ci:001:00 0 2 = 0300 dff35f00 2300716442 S Ii:001:01 -115 2 dfa47880 2300716475 S Ci:001:00 s a3 00 0001 0004 4 dfa47880 2300716494 C Ci:001:00 0 4 = 03030400 dfa47880 2300716502 S Co:001:00 s 23 01 0012 0001 0 dfa47880 2300716507 C Co:001:00 0 0 dfa47880 2300716523 S Ci:001:00 s a3 00 0001 0004 4 dfa47880 2300716532 C Ci:001:00 0 4 = 0303 dfa47880 2300727360 S Ci:004:00 s 80 00 0002 2 dfa47880 2300731378 C Ci:004:00 0 2 = 0200 dfa47880 2300731395 S Co:004:00 s 00 01 0001 0 dfa47880 2300734375 C Co:004:00 0 0 dfa47880 2300734507 S Ci:001:00 s a3 00 0002 0004 4 dfa47880 2300734518 C Ci:001:00 0 4 = 0001 dfa47880 2302716073 S Co:004:00 s 00 03 0001 0 dfa47880 2302718099 C Co:004:00 0 0 dfa47880 2302718115 S Co:001:00 s 23 03 0002 0001 0 dfa47880 2302718125 C Co:001:00 0 0 dff35f00 2304728765 C Ii:001:01 -2 0 So both the wakeup and suspend requests can be seen (and the light also is turned on after the click and before the '23 03' request goes to the mouse). -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RT-friendly IRQ management in USB
On Mon, 2 Jul 2007, Alan Cox wrote: spin_lock_irqsave(some_lock, flags); ... spin_unlock(some_lock); usb_hcd_giveback_urb(hcd, urb); local_irq_restore(flags); or is there a better approach? Why not just bite the bullet and change the callback convention. The lock verification code should catch the cases that matter and which are overlooked on a code scan. You could also change the name of the callback to be sure it breaks anything out of tree that isn't fixed. Plus the code above code will break as soon as someone removes the preempt_disable() from spin_lock_irqsave() and preempt_enable() from spin_lock_irqrestore() -- which would in fact be a good optimization to do (local interrupts are disabled, so there is no need to disable preemption). But this has to wait until all the places in kernel which do this kind of incorrect pairing are fixed. I'd ceratinly vote for not adding any more of them. spin_lock_irqsave(some_lock, flags); ... preempt_disable(); spin_unlock(some_lock); usb_hcd_giveback_urb(hcd, urb); local_irq_restore(flags); preempt_enable(); Would make it working in both cases. Not a nice thing, indeed :) -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RT-friendly IRQ management in USB
On Tue, 3 Jul 2007, Felipe Balbi wrote:
So looks like we don't have (yet) a way to make it work nicely in both
cases... does anyone has a clue about how to implement this one??
You of course still can
local_irq_save(flags);
spin_lock(some_lock);
...
spin_unlock(some_lock);
usb_hcd_giveback_urb(hcd, urb);
local_irq_restore(flags);
which is safe even against future removal of preempt inc/dec from
spin_lock_irq{save,restore}() functions.
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] RT-friendly IRQ management in USB
On Tue, 3 Jul 2007, Steven Rostedt wrote: Unfortunately that would not work in the RT case either. Because in RT, that spin_lock can schedule, and we are not allowed to schedule with interrupts disabled. So how do you handle in RT all the current code everywhere in the tree, which does precisely this? (i.e. calls spin_lock() with interrupts disabled). Do you convert all such code to something different as a part of the RT work? -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB mouse autosuspend
On Tue, 3 Jul 2007, Alan Stern wrote: It's totally bogus! With no driver loaded, the mouse won't be enabled for remote wakeup. Consequently it should never be resumed, no matter what you do to it. If it does send a wakeup request then the mouse is buggy. Conversely, if the mouse doesn't get resumed then it shouldn't draw enough current to turn on an LED. Either way, the mouse isn't working right. Kay, by no drivers loaded you mean only usbhid driver unloaded, or also usb host/core drivers? It could be that only the light goes on for a few seconds (Alan, are you sure that the power would not suffice?), but the mouse is not issuing any wakeup request. Kay, if you have only usb hid unloaded but the rest of USB infrastructure is there, we could easily see from usbmon output whether the mouse really did issue a wakeup request. In the end, we may be forced not to autosuspend keyboards and mice. There are lots of problems. One is broken hardware, as we see here. And ISTR Dave Brownell mentioning a mouse which claimed to support remote wakeup but in fact did not. Another problem is that not all devices will support the wakeup events we want. For instance, a suspended optical mouse can't detect when you move it, so it can't send a wakeup request. A third problem is that users may find it rather disconcerting that the LEDs on their keyboards turn off from time to time. Sure, as we have been talking about it on OLS. Added Oliver to CC. Yet another problem is that devices don't always work reliably when they resume. Jiri, I did some more testing with two different USB keyboards, one from HP and one from Apple. They each have an internal hub. I see. Would you have by chance any possibility also to test keyboard with internal hub on your notebook, if it will also get stuck as in the case we have seen with my keyboard when it was not connected through the external hub? The HP keyboard was the one I tried before. It often loses keystrokes when waking up, no matter what the environment. It does this under both UHCI and OHCI, and when either the keyboard, the keyboard and hub, or the keyboard and hub and root hub are suspended. (It also acts strangely in that the LEDs go out when the internal hub is suspended, not when the keyboard device is suspended.) OK, it seems that vendors of usb keyboards probably rely too much on fact that the keyboards could be quite slow and flaky without anyone complaining under normal load, and therefore implement the things very badly. Oliver, I currently think that usb hid autosuspend would bring much more problems than it would give us. The Apple keyboard was better behaved. The only times it lost keystrokes were when the keyboard and hub were both suspended, using UHCI. Which is absolutely the opposite situation to what we have observed on my uhci-based notebook! (i.e. the resume worked well if and only if the root hub *was* suspended). And I continue to believe that it would be a big mistake to increase the CPU overhead by polling more frequently when a device is suspended! Absolutely agreed. Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [Bugme-new] [Bug 8564] New: ftdi_sio: BUG: unable to handle kernel NULL pointer dereference at virtual address
On Mon, 2 Jul 2007, Gene Heskett wrote: Its possible the patch was broken when I saved it since I used the copy/paste of the clipboard, can you please send it privately as a savable attachment? Hi Gene, copy/paste is very likely to break whitespaces, that's definitely not a good way to treat patches. -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #4
On Mon, 25 Jun 2007, Oliver Neukum wrote: I grabbed a random HUB (usbhub4c from Linksys) and this made it work nicely even on UHCI-based system I am testing on. Is it a 1.1 hub or a 2.0 hub? 1.1, the device is still handled by uhci_hcd. -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #4
On Fri, 22 Jun 2007, Oliver Neukum wrote: could you please run two tests? 1. set the autosuspend timeout to 0 (this'll kill usb mice) And it kills also my testing keyboard on the UHCI system. After the keyboard gets suspended and I hit a key, it wakes up (the LEDs come up), but no keypressess are produced and the keyboard gets suspended again. 2. use a 1.1 hub I grabbed a random HUB (usbhub4c from Linksys) and this made it work nicely even on UHCI-based system I am testing on. I will do some more debugging to check what exactly goes wrong, but I am leaving for OLS tomorrow. BTW I don't know if you recall - I reported previously that the keypresses are lost only if I try to hit the key very soon after the keyboard gets suspended. If I wait for 2 seconds (looks like exact value), then no keypressess are lost and the keyboard wakes up properly. When I change the autosuspend values of all devices in system from 2 (default) to 5, the value described in the previous paragraph (i.e. the minimum time for which the keyboard must be suspended before it could be woken up flawlessly) is still 2 seconds. -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #4
On Mon, 25 Jun 2007, Oliver Neukum wrote: 1.1, the device is still handled by uhci_hcd. That indicates that something's wrong in uhci's root hub code. Just for completness, below is what dev_dbg gives. This is the case which is OK - I turn the autosuspend on, let the keyboard suspend, wait for more than 2 seconds, hit a few keys, everything works: Jun 25 16:36:14 box kernel: uhci_hcd :00:1d.2: release dev 6 ep81-INT, period 8, phase 4, 118 us Jun 25 16:36:14 box kernel: usbhid 4-2:1.0: suspend Jun 25 16:36:14 box kernel: uhci_hcd :00:1d.2: release dev 6 ep82-INT, period 8, phase 4, 118 us Jun 25 16:36:14 box kernel: usbhid 4-2:1.1: suspend Jun 25 16:36:14 box kernel: usb 4-2: usb auto-suspend Jun 25 16:36:16 box kernel: hub 4-0:1.0: hub_suspend Jun 25 16:36:16 box kernel: usb usb4: suspend_rh Jun 25 16:36:16 box kernel: usb usb4: usb auto-suspend Jun 25 16:36:20 box kernel: usb usb4: usb resume Jun 25 16:36:20 box kernel: usb usb4: finish resume Jun 25 16:36:20 box kernel: hub 4-0:1.0: hub_resume Jun 25 16:36:20 box kernel: usb usb4: wakeup_rh Jun 25 16:36:20 box kernel: hub 4-0:1.0: state 7 ports 2 chg evt Jun 25 16:36:20 box kernel: uhci_hcd :00:1d.2: port 2 portsc 01a5,01 Jun 25 16:36:20 box kernel: usb 4-2: usb wakeup-resume Jun 25 16:36:20 box kernel: usb 4-2: finish resume Jun 25 16:36:20 box kernel: uhci_hcd :00:1d.2: reserve dev 6 ep81-INT, period 8, phase 4, 118 us Jun 25 16:36:20 box kernel: usbhid 4-2:1.0: resume status 0 Jun 25 16:36:20 box kernel: uhci_hcd :00:1d.2: reserve dev 6 ep82-INT, period 8, phase 4, 118 us Jun 25 16:36:20 box kernel: usbhid 4-2:1.1: resume status 0 Jun 25 16:36:20 box kernel: hub 4-0:1.0: resume on port 2, status 0 this is the failing case (i.e. hitting the keys without waiting two seconds after the keyboard is suspended): Jun 25 16:37:08 box kernel: uhci_hcd :00:1d.2: release dev 6 ep81-INT, period 8, phase 4, 118 us Jun 25 16:37:08 box kernel: usbhid 4-2:1.0: suspend Jun 25 16:37:08 box kernel: uhci_hcd :00:1d.2: release dev 6 ep82-INT, period 8, phase 4, 118 us Jun 25 16:37:08 box kernel: usbhid 4-2:1.1: suspend Jun 25 16:37:08 box kernel: usb 4-2: usb auto-suspend Jun 25 16:37:09 box kernel: hub 4-0:1.0: state 7 ports 2 chg evt 0004 Jun 25 16:37:09 box kernel: uhci_hcd :00:1d.2: port 2 portsc 0195,01 Jun 25 16:37:09 box kernel: usb 4-2: usb wakeup-resume Jun 25 16:37:09 box kernel: usb 4-2: finish resume Jun 25 16:37:09 box kernel: uhci_hcd :00:1d.2: reserve dev 6 ep81-INT, period 8, phase 4, 118 us Jun 25 16:37:09 box kernel: usbhid 4-2:1.0: resume status 0 Jun 25 16:37:09 box kernel: uhci_hcd :00:1d.2: reserve dev 6 ep82-INT, period 8, phase 4, 118 us Jun 25 16:37:09 box kernel: usbhid 4-2:1.1: resume status 0 Jun 25 16:37:09 box kernel: hub 4-0:1.0: resume on port 2, status 0 Jun 25 16:37:11 box kernel: uhci_hcd :00:1d.2: release dev 6 ep81-INT, period 8, phase 4, 118 us Jun 25 16:37:11 box kernel: usbhid 4-2:1.0: suspend Jun 25 16:37:11 box kernel: uhci_hcd :00:1d.2: release dev 6 ep82-INT, period 8, phase 4, 118 us Jun 25 16:37:11 box kernel: usbhid 4-2:1.1: suspend Jun 25 16:37:11 box kernel: usb 4-2: usb auto-suspend i.e. when the HUB is also suspended and then woken up, everything looks OK, but if it is only the device, without root hub going to suspend, it doesn't work. Alan, could this possibly be some race in uhci hub suspend handling (i.e. when the keyboard tries to resume while the root hub is trying to go to suspend, or something like that). -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #4
On Mon, 25 Jun 2007, Alan Stern wrote:
That indicates that something's wrong in uhci's root hub code.
Could well be. I'll try duplicating the experiment: suspend the
keyboard and less than 2 seconds later type some keys. I don't have the
HID-autosuspend patch installed, but a manual suspend with remote wakeup
should work pretty much the same.
It probably should, but just in case you are not able to reproduce the
problem in this way, I am attaching the Oliver's condensated patches I am
experimenting with, as one bigger patch below. It's based on 2.6.22-rc2.
Jiri, I'll look for you at OLS.
Great, I'll be having uhci-based notebook with me, and could easily bring
a tiny portable keyboard that reproduces the problem, so we could try to
figure out, if there is time. Thanks.
diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index 7f81789..3c5e7ba 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -940,6 +940,17 @@ int hidinput_find_field(struct hid_device *hid, unsigned
int type, unsigned int
}
EXPORT_SYMBOL_GPL(hidinput_find_field);
+int hidinput_has_ff(struct hid_device *hid)
+{
+ struct hid_input *hidinput;
+
+ list_for_each_entry(hidinput, hid-inputs, list)
+ if (test_bit(EV_FF, hidinput-input-evbit))
+ return 1;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(hidinput_has_ff);
+
static int hidinput_open(struct input_dev *dev)
{
struct hid_device *hid = input_get_drvdata(dev);
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index d91b9da..f646a9c 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -5,6 +5,7 @@
* Copyright (c) 2000-2005 Vojtech Pavlik [EMAIL PROTECTED]
* Copyright (c) 2005 Michael Haboustak [EMAIL PROTECTED] for Concept2, Inc
* Copyright (c) 2006-2007 Jiri Kosina
+ * Copyright (c) 2007 Oliver Neukum
*/
/*
@@ -26,6 +27,7 @@
#include asm/byteorder.h
#include linux/input.h
#include linux/wait.h
+#include linux/workqueue.h
#include linux/usb.h
@@ -63,8 +65,12 @@ MODULE_PARM_DESC(quirks, Add/modify USB HID quirks by
specifying
/*
* Input submission and I/O error handler.
*/
+static DEFINE_MUTEX(hid_open_mut);
+static struct workqueue_struct *resumption_waker;
static void hid_io_error(struct hid_device *hid);
+static int hid_submit_out(struct hid_device *hid);
+static int hid_submit_ctrl(struct hid_device *hid);
/* Start up the input URB */
static int hid_start_in(struct hid_device *hid)
@@ -74,7 +80,7 @@ static int hid_start_in(struct hid_device *hid)
struct usbhid_device *usbhid = hid-driver_data;
spin_lock_irqsave(usbhid-inlock, flags);
- if (hid-open 0 !test_bit(HID_SUSPENDED, usbhid-iofl)
+ if (hid-open 0 !test_bit(HID_REPORTED_IDLE, usbhid-iofl)
!test_and_set_bit(HID_IN_RUNNING, usbhid-iofl)) {
rc = usb_submit_urb(usbhid-urbin, GFP_ATOMIC);
if (rc != 0)
@@ -178,6 +184,50 @@ done:
spin_unlock_irqrestore(usbhid-inlock, flags);
}
+static void usbhid_mark_busy(struct usbhid_device *usbhid)
+{
+ struct usb_interface *intf = usbhid-intf;
+
+ usb_mark_last_busy(interface_to_usbdev(intf));
+}
+
+static int usbhid_restart_out_queue(struct usbhid_device *usbhid)
+{
+ struct hid_device *hid = usb_get_intfdata(usbhid-intf);
+ int kicked;
+
+ if (!hid)
+ return 0;
+
+ if ((kicked = (usbhid-outhead != usbhid-outtail))) {
+ dbg(Kicking head %d tail %d, usbhid-outhead,
usbhid-outtail);
+ if (hid_submit_out(hid)) {
+ clear_bit(HID_OUT_RUNNING, usbhid-iofl);
+ wake_up(hid-wait);
+ }
+ }
+ return kicked;
+}
+
+static int usbhid_restart_ctrl_queue(struct usbhid_device *usbhid)
+{
+ struct hid_device *hid = usb_get_intfdata(usbhid-intf);
+ int kicked;
+
+ WARN_ON(hid == NULL);
+ if (!hid)
+ return 0;
+
+ if ((kicked = (usbhid-ctrlhead != usbhid-ctrltail))) {
+ dbg(Kicking head %d tail %d, usbhid-ctrlhead,
usbhid-ctrltail);
+ if (hid_submit_ctrl(hid)) {
+ clear_bit(HID_CTRL_RUNNING, usbhid-iofl);
+ wake_up(hid-wait);
+ }
+ }
+ return kicked;
+}
+
/*
* Input interrupt completion handler.
*/
@@ -190,12 +240,14 @@ static void hid_irq_in(struct urb *urb)
switch (urb-status) {
case 0: /* success */
+ usbhid_mark_busy(usbhid);
usbhid-retry_delay = 0;
hid_input_report(urb-context, HID_INPUT_REPORT,
urb-transfer_buffer,
urb-actual_length, 1);
break;
case -EPIPE:/* stall
Re: [linux-usb-devel] autosuspend for HID devices, take #4
On Mon, 25 Jun 2007, Alan Stern wrote: These logs look correct. The difference might have something to do with the timing of the USB messages relative to the keystrokes. Or maybe the keyboard itself has some weird 2-second timer. Hi Alan, thanks for looking at it. I have tried with two different keyboards, both behave in the very same way - i.e. on OHCI, or when connected through 1.1 hub to UHCI, everything works nicely. Only when connected directly to UHCI root hub, the keystrokes are lost if pressed within that 2-sec period, etc. I'd be inclined to rule out purely keyboard issue here. I'll put some printk()s into the uhci root hub code to understand better what is going on. If you have any idea, please let me know. Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #4
On Mon, 25 Jun 2007, Alan Stern wrote: With usbmon it's possible to see exactly what packets are transferred. The packets used for doing the resume always follow the same pattern. The only difference is the Interrupt data carrying the keystroke information. The device simply does not send the data. Do you see how could the fact that the device is connected either to ohci or uhci root hub influence whether the device itself does or does not send the data? It'll be a lot easier to show you all this in person. And maybe I'll see something new when trying out your keyboard. Sure, see you in Ottawa. Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #4
On Mon, 28 May 2007, Oliver Neukum wrote: Sure, it still could be a HW issue (I have experienced this with two random keyboards I used for testing), but I'd guess it would be something different than what you describe. What do you think? Have you varied the computer or only the keyboard? Hi Oliver, sorry for not touching this for quite some time. I have now tested with the very same keyboards on OHCI machine (I have seen the issues I reported in this thread on UHCI), and there seem to be no problems at all - the keyboard is always woken up immediately and no loss of keypressess happens. I will verify on more various systems whether it is really related only to UHCI, but so far it seems like the best guess. Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Error -71 on device descriptor read/all
[ OK, it probably seems like a faulty hardware (controller or the device itself), which is not able to run at high speed, but runs nicely on full speed. Do you have a chance to try another high speed device in this machine to check whether it works? Adding linux-usb-devel into CC , just in case, and leaving the full original message below ] On Tue, 19 Jun 2007, Renato S. Yamane wrote: Jiri Kosina wrote: On Tue, 19 Jun 2007, Renato S. Yamane wrote: I see this in dmesg: usb 1-1: device descriptor read/all, error -71 Is this a USB 2.0 high-speed device? lspci -v | grep 1d.7 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 04) (prog-if 20 [EHCI]) My machine is a Laptop Toshiba M45-S355 Don't you for example have USB extension cable too long to work on-high speed? My only USB device is a mouse (Microsoft Notebook Optical Mouse) without extension cable (I use original cable, with less than 3 feets). I guess the situation improves when you force USB 1.1 (i.e. rmmod ehci_hcd), right? #rmmode ehci_hcd #tail /var/log/messages kernel: ehci_hcd :00:1d.7: remove, state 4 kernel: usb usb5: USB disconnect, address 1 kernel: ehci_hcd :00:1d.7: USB bus 5 deregistered kernel: ACPI: PCI interrupt for device :00:1d.7 disabled I don't see any error (-71). #modprobe ehci_hcd #tail /var/log/messages kernel: ACPI: PCI Interrupt :00:1d.7[A] - Link [LNKH] - GSI 10 (level, low) - IRQ 10 kernel: ehci_hcd :00:1d.7: EHCI Host Controller kernel: ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 5 kernel: ehci_hcd :00:1d.7: debug port 1 kernel: ehci_hcd :00:1d.7: irq 10, io mem 0xf400 kernel: ehci_hcd :00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 kernel: usb usb5: configuration #1 chosen from 1 choice kernel: hub 5-0:1.0: USB hub found kernel: hub 5-0:1.0: 8 ports detected kernel: usb 1-1: USB disconnect, address 4 kernel: usb 1-1: new low speed USB device using uhci_hcd and address 5 kernel: usb 1-1: configuration #1 chosen from 1 choice kernel: input: Microsoft Microsoft 3-Button Mouse with IntelliEye? as /class/input/input8 kernel: input: USB HID v1.00 Mouse [Microsoft Microsoft 3-Button Mouse with IntelliEye?] on usb-:00:1d.0-1 This error is present only in dmesg, see below (line 8): PCI: Setting latency timer of device :00:1d.7 to 64 ehci_hcd :00:1d.7: EHCI Host Controller ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 5 ehci_hcd :00:1d.7: debug port 1 PCI: cache line size of 32 is not supported by device :00:1d.7 ehci_hcd :00:1d.7: irq 10, io mem 0xf400 ehci_hcd :00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb 1-1: device descriptor read/all, error -71 usb usb5: configuration #1 chosen from 1 choice hub 5-0:1.0: USB hub found hub 5-0:1.0: 8 ports detected Clocksource tsc unstable (delta = -194969704 ns) ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 6 PCI: setting IRQ 6 as level-triggered Best regards, Renato - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 1/5]:hidbus prototype 070409:core headers
On Mon, 30 Apr 2007, Li Yu wrote: These are the splited patches of hid bus prototype 070409. I remember I posted them in attachment form ago ;) Now they are splited in some separable patches. I am afraid I can not receive in Labor Day. Hi Li, first, please apologize my delay in the reply, the patches are quite large and I have been busy with lots of different things lately. There had been quite a long discussion some time ago, regarding the proper way to design hidbus. As far as I recall it, we came to the conclusion that the best way would be to allow defining of two different hooks - one for raw data and another for parsed reports and let drivers decice which one they want to use. I am missing the possibility to hook the parsed data in your implementation, or did I just overlook something? Second, what is the exact point with hid_report_pre_event()? It is missing any explanatory comment (which applies to other code in your patches BTW) and I seem to be missing the point too. Third, as far as my memory goes, I think we agreed that in order to design the layering properly and allow individual specialized drivers to work properly, the HID bus code should provide a way to register a driver for a specific VID/PID and also the report id (one or more). Then all reports for which there is no specialized driver are going to be handled by the default HID-input driver (or could be handled into hidraw if the in-kernel HID parser is unable to parse them). The reports for ids with a special driver are handed over to the driver. I unfortunately seem to be missing this functionality in the patch too ... ? Last but not least, I have gone through this code several times, but I still don't fully understand why the 'hid_transport' abstraction is needed. I am still convinced that the current model works well, and there should be absolutely no need for hid_(un)register_transport() and the related things. Could some explanation please be put somewhere? (ideally in the patch's changelog entry). And more generally - the patches seem a little bit bigger than they could be, I am not sure whether the layering and data structures you have are not a little bit overdesigned. But this will need some more review. Thanks a lot, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb 2.0 driver performance issue
On Tue, 5 Jun 2007, Alan Stern wrote: What you need to do is reduce the amount of memory used for I/O buffers. However I don't know how you can control it. Maybe people on LKML can provide some advice. Playing with /proc/sys/vm/dirty* might be worthwile. -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Oops in khubd
387f0040 3881 38a1 38c0 4bd66b1d 813f005c [ 76.505905] 480c 4bdc5021 813d0410 3ba9fbf0 801d0410 2f80 419e0008 7c00022c -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Kernel 2.6.22-rc3 breaks USB: Unable to get HID descriptor (error sending control message: Operation not permitted)
I have looked into NUT source and it seems that this error message is output after interaction with libusb, not hiddev. It looks like libusb's usb_claim_interface() or usb_control_msg() in in 2.6.22-rc3 is failing with -EPERM. So I am adding USB devel mailinglist into CC and leaving the original message below for reference. On Sat, 2 Jun 2007, Justin Piszcz wrote: I use nut-2.0.4-4 with a UPS attached via USB and from 2.6.21.3 - 2.6.22-rc3 it stops working, see below. My .config is attached. 2.6.21.3: p34:~# /lib/nut/newhidups -u nut -DD auto Checking device (050D/0912) (005/002) - VendorID: 050d - ProductID: 0912 - Manufacturer: - Product: UPS - Serial Number: unknown - Bus: 005 Trying to match device Device matches HID descriptor retrieved (Reportlen = 820) Size read for the report descriptor: 820 Report descriptor retrieved (Reportlen = 820) Found HID device Network UPS Tools: New USB/HID UPS driver 0.28 (2.0.4) Report Descriptor size = 820 Report Descriptor: (200 bytes) = 05 84 09 04 A1 01 05 86 09 26 A1 02 85 01 75 08 Detected a UPS:/UPS Using subdriver: Belkin HID 0.1 Looking up 00840004 Looking up 00860026 Looking up 00860040 entering string_to_path() parsing UPS Looking up UPS hid_lookup_usage: found 840004 parsing BELKINConfig Looking up BELKINConfig hid_lookup_usage: found 860026 parsing BELKINConfigVoltage Looking up BELKINConfigVoltage hid_lookup_usage: found 860040 Path depth = 3 0: UPage(84), Usage(4) 1: UPage(86), Usage(26) 2: UPage(86), Usage(40) Entering libusb_get_report = Before exponent: 120, 0/0) = After conversion: 120.00 (120), 0/0) Report : (8 bytes) = 01 78 80 00 00 00 00 00 Path: UPS.BELKINConfig.BELKINConfigVoltage, Type: Feature, Value: 120.00 Looking up 00840004 Looking up 00860026 Looking up 00860042 (works fine) 2.6.22-rc3: p34:~# /lib/nut/newhidups -u nut -DD auto Checking device (050D/0912) (005/002) - VendorID: 050d - ProductID: 0912 - Manufacturer: unknown - Product: unknown - Serial Number: unknown - Bus: 005 Trying to match device Device matches failed to claim USB device, trying 2 more time(s)... detaching kernel driver from USB device... failed to detach kernel driver from USB device... trying again to claim USB device... failed to claim USB device, trying 1 more time(s)... detaching kernel driver from USB device... failed to detach kernel driver from USB device... trying again to claim USB device... failed to claim USB device, trying 0 more time(s)... detaching kernel driver from USB device... failed to detach kernel driver from USB device... trying again to claim USB device... Unable to get HID descriptor (error sending control message: Operation not permitted) -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Grabbing characters from a Symbol barcode scanner
On Wed, 30 May 2007, Andy Stewart wrote: I have a Symbol USB barcode scanner that appears to work with Linux. If I bring up a Konsole window and give it focus, characters are typed into that window as I scan barcodes. However, what I'd like to do is grab those characters in a C program. I suppose that I should be able to open the proper device and the characters would be available. Yes, just open the proper evdev interface in /dev/input/eventX and read the events directly from there. See Documentation/input/input.txt, section 5. You can use ioctl(EVIOCGID) to obtain vendor id/product id corresponding to the given input device, so you can easily look up the event device corresponding to the device you are looking for. -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #5
On Wed, 23 May 2007, Oliver Neukum wrote: del_timer_sync(usbhid-io_retry); + cancel_work_sync(usbhid-restart_work); flush_scheduled_work(); Hi Oliver, isn't the call to flush_scheduled_work() after cancel_work_sync() redundant? Also, we could very probably use the hotplug-safer cancel_work_sync() elsewhere in your patch where you introduce flush_scheduled_work(), right? Thanks, -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH 4/6] USB: add reset_resume method
On Wed, 30 May 2007, Alan Stern wrote: In addition, the pre_reset and post_reset method return types are changed; they now must return an error code. The return value is unused at present, but at some later time we may unbind drivers and re-probe if they encounter an error during reset handling. The existing pre_reset and post_reset methods in the usbhid, usb-storage, and hub drivers are updated to match the new requirements. For usbhid the post_reset routine is also used for reset_resume (duplicate method pointers); Signed-off-by: Alan Stern [EMAIL PROTECTED] CC: Jiri Kosina [EMAIL PROTECTED] CC: Matthew Dharm [EMAIL PROTECTED] Greg, as the changes to usbhid are really trivial (just prototype changes), it'd be probably the best way if you take it through your tree together with the rest of the changes, whenever they are going to be merged. For the trivial usbhid part Signed-off-by: Jiri Kosina [EMAIL PROTECTED] Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #4
On Wed, 23 May 2007, Alan Stern wrote: I suspect it is keyboard-dependent. For example, the keyboard's internal buffer might be able to hold no more than one event, because the designers expected the host to poll frequently. Since the polling can't occur during the wakeup interval, multiple events from that time will get lost. in such situation, I'd however expect the first N events to be lost, but the last events to arrive without problem. What I am experiencing, however, is that the missing events are usually the middle ones. It depends on how the buffer is implemented. It might work this way: The first keystroke is detected, goes into the buffer, and causes a remote wakeup request to be sent. Later keystrokes can't go into the buffer because the buffer is still full, so they are dropped. When the resume sequence is complete, the host reads the original keystroke and the buffer is once again empty. Hence any further keystrokes are processed as usual. Hi Alan, you are right, however there is still a reason I think that this is not the case. What I am seeing is that the keypresses are lost only if I hit a key (and thus wake the autosuspended keyboard up) only after a short time it goes to suspend. When I leave it autosuspended for 2 or more seconds (approximately), it behaves nicely. Sure, it still could be a HW issue (I have experienced this with two random keyboards I used for testing), but I'd guess it would be something different than what you describe. What do you think? Thanks, -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [BUG] USB input death then system freeze
On Thu, 24 May 2007, Nicolas Mailhot wrote: Most recent kernel where this bug did *NOT* occur: pre 2.6.21 mm kernels, non-mm 2.6.22-rc2 Distribution: Fedora Devel Hardware Environment: EHCI input on external powered hub with CK804 mainboard Software Environment: Nothing specific Problem Description: After a few hours of activity 2.6.22-rc1-mm1 and 2.6.22-rc2-mm1 will lose USB HID INPUT (keyboard or mice with no priority), then the system will freeze drivers/hid/usbhid/hid-core.c: input irq status -75 received This is now handled in bugzilla [1]. Zan Lynx also reported this problem, and from the HID_DEBUG output he provided is evident that it is caused by HID layer receiving a report of size 4294967284 (which corresponds to urb-actual_length of the URB received from USB core). Alan Stern suggested to reproduce the bug with CONFIG_USB_DEBUG and also collect the usbmon trace, so that we can clearly understand what happens. I am now inclined to think that this is caused by USB core messing up the URB somehow, HID core seems to receive the URB with already bogus values. [1] http://bugzilla.kernel.org/show_bug.cgi?id=8535 Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [BUG] USB input death then system freeze
On Fri, 25 May 2007, Jiri Kosina wrote: This is now handled in bugzilla [1]. Zan Lynx also reported this problem, and from the HID_DEBUG output he provided is evident that it is caused by HID layer receiving a report of size 4294967284 (which corresponds to urb-actual_length of the URB received from USB core). For completness, this is a snippet of HID_DEBUG output that Zan sent me in a private mail, which demonstrates the urb-actual_length badness: ... drivers/hid/hid-core.c: report (size 3) (unnumbered) drivers/hid/hid-core.c: report 0 (size 3) = 00 00 00 hid-debug: input Keyboard.00e0 = 0 hid-debug: input Keyboard.00e1 = 0 hid-debug: input Keyboard.00e2 = 0 hid-debug: input Keyboard.00e3 = 0 hid-debug: input Keyboard.00e4 = 0 hid-debug: input Keyboard.00e5 = 0 hid-debug: input Keyboard.00e6 = 0 hid-debug: input Keyboard.00e7 = 0 drivers/hid/hid-core.c: report (size 4294967284) (unnumbered) drivers/hid/hid-core.c: report 0 (size 4294967284) = hid-debug: input Keyboard.00e0 = 0 hid-debug: input Keyboard.00e1 = 0 hid-debug: input Keyboard.00e2 = 0 hid-debug: input Keyboard.00e3 = 0 hid-debug: input Keyboard.00e4 = 0 hid-debug: input Keyboard.00e5 = 0 hid-debug: input Keyboard.00e6 = 0 hid-debug: input Keyboard.00e7 = 0 drivers/hid/hid-core.c: report (size 6) (numbered) drivers/hid/hid-core.c: report 2 (size 5) = 00 00 00 00 00 hid-debug: input Button.0001 = 0 hid-debug: input Button.0002 = 0 hid-debug: input Button.0003 = 0 hid-debug: input Button.0004 = 0 hid-debug: input Button.0005 = 0 hid-debug: input Button.0006 = 0 hid-debug: input Button.0007 = 0 hid-debug: input Button.0008 = 0 hid-debug: input GenericDesktop.X = 0 hid-debug: input GenericDesktop.Y = 0 hid-debug: input GenericDesktop.Wheel = 0 Hangcheck: hangcheck value past margin! drivers/hid/usbhid/hid-core.c: input irq status -75 received ... -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.22-rc2-mm1
On Wed, 23 May 2007, Dmitry Torokhov wrote: It looks like you are now in the same position I was some time ago WRT to debug information for i8042 - constantly asking people to enable debug, recompile and send the results. May I recommend changing CONFIG_HID_DEBUG to default y if !EMBEDDED and controlling debug output via a module parameter? -ENOPATCH though... Hi Dmitry, this is exactly what I have been thinking a couple of days ago, I am currently in the process of creating a patch, it's quite annoying to ask people to recompile kernel every time. Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #4
On Wed, 23 May 2007, Oliver Neukum wrote: - waiting on Jiri's comment about what to do if waiting for io gets a timeout during suspend() Hi Oliver, I think that whenever usbhid_wait_io() times out during suspend, it is fine to kill the URB, as it doesn't seem to make any more harm compared to the situation when usbhid_wait_io() times out without suspend in progress. Other than that it has all features I planned for and were requested. It should work now. I am now taking comments on coding style :-) I request testing and remind you that cruelty is a virtue in that regard. I have quite a lot of things pending, but will test this ASAP. Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #4
On Wed, 23 May 2007, Oliver Neukum wrote: I have quite a lot of things pending, but will test this ASAP. I've tested normal operations on OHCI and EHCI and STR with a mouse, a keyboard and a PID joystick (just plugged in) Hi Oliver, well, I remember to having this reported also against one of the very first versions of your patch - I still experience loss of events from the device that is being woken up shortly after it goes to suspend. I.e. as soon as the device goes to suspend, I type 'asdf' on the keyboard, it wakes up and reports only 'af' or something like that. It seems that this is not reproducible after some time (a few seconds) the device is suspended. Are you able to reproduce this? I will try to figure out what is going on. -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #4
On Wed, 23 May 2007, Oliver Neukum wrote: well, I remember to having this reported also against one of the very first versions of your patch - I still experience loss of events from the device that is being woken up shortly after it goes to suspend. I.e. as soon as the device goes to suspend, I type 'asdf' on the keyboard, it wakes up and reports only 'af' or something like that. It seems that this is not reproducible after some time (a few seconds) the device is suspended. Are you able to reproduce this? I will try to figure out what is going on. No, sorry, but maybe I am just clumsy at hitting the keys at the correct time. I hit the keys as soon as LED diods go off. Then the events get lost. If I wait for approximately two seconds, everything works fine (waiting one second is not enough, it still loses data). I will debug. Maybe just this particular keyboard is clumsy. I will try with various different hardware. But if there are lots of HID hardware out there which expose this broken behavior, it would be bad. -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #4
On Wed, 23 May 2007, Alan Stern wrote: I suspect it is keyboard-dependent. For example, the keyboard's internal buffer might be able to hold no more than one event, because the designers expected the host to poll frequently. Since the polling can't occur during the wakeup interval, multiple events from that time will get lost. Hi Alan, in such situation, I'd however expect the first N events to be lost, but the last events to arrive without problem. What I am experiencing, however, is that the missing events are usually the middle ones. I have in the meantime tested with another USB keyboard on the same system, still the very same behavior with lost keypresses. I will try the same keyboards on another system now, to verify whether it could be a USB hub's fault instead. It wouldn't be surprising to find lots of USB HID devices suffering from this kind of problem. Which unfortunately would render suspending them quite impossible, as losing keypresses this often is a big no-no :( I will work on this a little bit more. Thanks, -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.22-rc2-mm1
On Wed, 23 May 2007, Zan Lynx wrote:
I am having weird problems with USB keyboard and mouse. The USB
keyboard will drop keystrokes, but not all of them. The mouse seems to
move fine but drops clicks. Could be that an occasional missed move
event isn't noticeable. Nothing is logged when a key is dropped.
However, I did have some of this when it was first booting:
BUG: at drivers/hid/hid-core.c:778 implement()
Call Trace:
[880bb5ac] :hid:hid_output_report+0x1dc/0x270
[880c651a] :usbhid:hid_submit_ctrl+0x7a/0x260
[880c68ee] :usbhid:usbhid_submit_report+0x11e/0x200
[880c9312] :usbhid:hiddev_ioctl+0x3e2/0xae0
[8053523e] do_page_fault+0x42e/0x880
[802b486d] do_ioctl+0x7d/0xa0
[802b4ab1] vfs_ioctl+0x221/0x2d0
[8025a711] trace_hardirqs_on+0xc1/0x160
[802b4ba9] sys_ioctl+0x49/0x80
[8020a16e] system_call+0x7e/0x83
OK, so something is touching one of your HID devices through hiddev, and
tries to push through it something that doesn't comply to the report
descriptor of the device. Are you aware of any userspace daemons running
which would touch /dev/hiddev*? (acupsd, nut, hid2hci, etc.).
Just for clarification, does situation get any better when you disable
hidraw, which I see you have enabled? (if that doesn't help, testing with
hiddev disabled should also be interesting - that would avoid the
possibility that userspace mocks the device up through hiddev).
BUG: at include/linux/slub_def.h:83 kmalloc_index()
Call Trace:
[802a2e09] get_slab+0xb9/0x180
[802a2965] kfree+0xc5/0x110
[802a2fd4] __kmalloc+0x24/0xc0
[8049ab18] get_modalias+0x68/0x120
[8049ac07] dmi_dev_uevent+0x37/0x60
[80443b63] dev_uevent+0x163/0x220
[803bcc97] kobject_uevent_env+0x2b7/0x500
[80444f50] bus_add_device+0x20/0x140
[804438d2] device_add+0x4a2/0x5b0
[807a0a1b] dmi_id_init+0x2cb/0x2f0
[807866e6] kernel_init+0x156/0x330
[80531f5c] trace_hardirqs_on_thunk+0x35/0x37
[8025a711] trace_hardirqs_on+0xc1/0x160
[8020b028] child_rip+0xa/0x12
[8020a710] restore_args+0x0/0x30
[803e6c10] vgacon_cursor+0x0/0x1f0
[8023ad5b] release_console_sem+0x4b/0x230
[80786590] kernel_init+0x0/0x330
[8020b01e] child_rip+0x0/0x12
This BTW needs a separate bugreport.
input,hiddev0,hidraw2: USB HID v1.10 Mouse [Logitech USB Receiver] on
usb-:00:02.2-2.2.1
This is pretty strange. Mouse shouldn't be claimed by hiddev. Seems like
this mouse probably has some interesting HID report descriptor. Could
you please recompile with CONFIG_HID_DEBUG enabled and send me the output?
===
[ INFO: possible circular locking dependency detected ]
2.6.22-rc2-mm1 #1
---
rhythmbox/6976 is trying to acquire lock:
(mm-mmap_sem){}, at: [80534f8c] do_page_fault+0x17c/0x880
but task is already holding lock:
(data-latch){}, at: [8034a701] get_exclusive_access+0x11/0x20
which lock already depends on the new lock.
This also needs a separate report.
Do you please have any indication which kernel versions were OK with the
same .config, with respect to the USB mouse/keyboard hogs you are seeing
with 2.6.22-rc2-mm1?
Thanks,
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #2
On Tue, 22 May 2007, Oliver Neukum wrote:
- Jiri, is there a _category_ of HID devices that should not be
autosuspended at all?
Hi Oliver,
thanks for updating the patch. I am not quite sure right now whether I can
come up with a category that should not be suspended at all, but I will
think a little bit more about this.
There is a principal issue. What is to be done with output requests?
Starting the queue as soon as one arrives seems the safest thing to do,
but it is fatal in a subset of situations, that is, it must not be done
during snapshotting and when going for system suspend. The freezer is
insufficient to prevent new requests from coming in.
Starting the queue immediately would be my preferred solution, as has been
already discussed previously in this thread.
Is anyone aware of any better solution for assuring whether it is possible
to restart the queue, apart from adding special hooks into usbcore? Don't
other USB drivers suffer from similar problems?
--- linux-2.6.22-rc1/drivers/hid/usbhid/hiddev.c 2007-05-13
03:45:56.0 +0200
+++ linux-2.6.22-rc1-autosuspend/drivers/hid/usbhid/hiddev.c 2007-05-22
09:51:08.0 +0200
@@ -248,10 +248,12 @@ static int hiddev_release(struct inode *
spin_unlock_irqrestore(list-hiddev-list_lock, flags);
if (!--list-hiddev-open) {
- if (list-hiddev-exist)
+ if (list-hiddev-exist) {
usbhid_close(list-hiddev-hid);
- else
+ usbhid_put_power(list-hiddev-hid);
+ } else {
kfree(list-hiddev);
+ }
}
What is the purpose of this hunk please?
It'd maybe be nice if you provide the cleanups (and this also includes
moving the comments around so that they are wrapped at 80 cols, etc) in a
separate patch. Thanks.
+static int hidinput_has_ff(struct hid_device *hid)
+{
+ struct hid_input *hidinput;
+
+ list_for_each_entry(hidinput, hid-inputs, list)
+ if (test_bit(EV_FF, hidinput-input-evbit))
+ return 1;
+ return 0;
+}
This should better go into hid-input.c if possible.
@@ -406,49 +497,53 @@ void usbhid_submit_report(struct hid_dev
if (usbhid-urbout dir == USB_DIR_OUT report-type ==
HID_OUTPUT_REPORT) {
- spin_lock_irqsave(usbhid-outlock, flags);
-
- if ((head = (usbhid-outhead + 1) (HID_OUTPUT_FIFO_SIZE - 1))
== usbhid-outtail) {
- spin_unlock_irqrestore(usbhid-outlock, flags);
- warn(output queue full);
- return;
- }
-
- usbhid-out[usbhid-outhead] = report;
- usbhid-outhead = head;
+ usbhid_queue_report_out(hid, report);
Is it OK that we don't check the return value of
usbhid_queue_report_out()? What if the queue becomes full, aren't we
losing the report? (applies also to usbhid_queue_report_ctrl() elsewhere).
Thanks,
--
Jiri Kosina
SUSE Labs
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for HID devices, take #2
On Tue, 22 May 2007, Alan Stern wrote: But if you kill the interrupt URB then there will be no more inputs and hence nothing to generate any more output. Thus, when suspending you should kill the inputs and wait for the outputs to drain (or else explicitly plug the output queue). Then it will be safe to autoresume whenever a new output queue entry arrives. Hi Alan, I think that this is unfortunately not true. Let's take system with multiple keyboards and their LEDs as an excellent example again. If you kill the interrupt URB, there is nothing what will prevent other keyboard (PS/2 or even USB keyboard, which is not yet suspended) to generate an input event (user presses CapsLock/NumLock at a 'right' time). Then you'll get out of sync, won't you? Thanks, -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for hid
On Mon, 21 May 2007, Oliver Neukum wrote:
- what to do with devices with force feedback? (or PID devices in
general). The effect could have up to infinite duration (until it is
stopped by appropriate stop method), and we definitely absolutely
must not autosuspend a device that is currently in a process of
playback.
I suggest we don't suspend them. We'd increment the pm usage count on
open and decrement it on close, basically the same we need to do for
generic HID devices. I just need a way to identify PID devices.
Hi Oliver,
what about something like
int hidinput_has_ff(struct hid_device *hid)
{
struct hid_input *hidinput;
list_for_each_entry(hidinput, hid-inputs, list)
if (test_bit(EV_FF, hidinput-input-evbit))
return 1;
return 0;
}
- think again about the output reports queuing. I am now inclined to think
that we should simply wake the device up once the output report is to be
delivered to it. There might be different situations other than just
keyboard LEDs (there can be simply any kind of exotic HID device being
controlled through hiddev and userspace could want to deliver the output
report to it immediately, without any queuing)
If we do busy style autosuspend only for devices we positively identify,
is the point rendered moot?
Sorry, could you be please more specific? I don't think I understand the
point here. Thanks.
- (and of course coding style)
It shall be done, but not until the principal features are clear.
Of course.
Thanks,
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Resubmit [PATCH] pu203 dual controller
On Sat, 19 May 2007, Sam Liddicott wrote: Do you actually own the hardware? I would appreciate if you could test whether really both of the quirks are needed - we don't want to add unneeded quirks to devices, that would just spread confusion. OK. I'm not sure how to tell if the poll quirk is needed or not. Any tips? Hi Sam, well there are basically two main things that could happen if the device needs HID_QUIRK_NOGET and we don't set it in hid_blacklist[] - either it could timeout for ~10 seconds during initialization (as it would just drop the Get request), or it could respond with bogus values to Get request, and therefore the subsequent data processing would return bogus values. The common symptom for both cases is - the device just won't work as expected :) =Also, could you please resend the patch with proper =Signed-off-by line? Oh yes, sorry. And also proper Changelog please (i.e. this device has that many input interfaces and so it needs HID_QUIRK_MULTI_INPUT and it acts so and so and therefore needs HID_QUIRK_NOGET). Thanks, -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Resubmit [PATCH] pu203 dual controller
On Fri, 18 May 2007, Sam Liddicott wrote: Cc'ding you guys directly, this patch send on 9 May doesn't seem to be picked up yet. Hi Sam, was I CCed on the original patch? I can't find your mail in my mailbox ... if it went just to linux-usb-devel/lkml, it could happen that I have missed it, sorry. It adds the same quirks for the PCS Ltd pu203 as I recently added for the Wisegroup quad controller. I don't exactly know if both quirks are required (for the pu203), but it works for me like this. Do you actually own the hardware? I would appreciate if you could test whether really both of the quirks are needed - we don't want to add unneeded quirks to devices, that would just spread confusion. Also, could you please resend the patch with proper Signed-off-by line? Thanks. -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] anybody have a working driver for ELO 1529L with Mag-Tek USB Swipe Reader?
On Thu, 17 May 2007, Jason Brewster wrote: Thanks, What kind of device is that? (could you please post at least output of lsusb, etc.). It might be that the device is standard-compliant (for example HID), so wouldn't require any extra driver. Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for hid
On Wed, 16 May 2007, Robert Marquardt wrote: Writing reports to a device from kernel? Why would that be needed? It is in my experience mainly needed for setting and clearing the LEDs. But I don't claim to know all input devices in the kernel tree. Does hat really have to be handled on low-level? It should be possible to forbid such interactions on the lower levels without getting regressions. Hi Robert, first, why did you remove me from CC when responding? Anyway, what would be your proposal here? Currently the output reports (for changing the keyboard LEDs, for example) are being submitted as soon as the corresponding input event occurs (on different keyboard), which makes sense. Could you be more elaborate on what are the exact drawbacks you see here, and what would your proposal be? (postponing it into workqueue? why?). Thanks. If handled at higher levels there are two way to handle suspended keyboard. Either first wake it up or decide to not write to it. If you decide not to write to it, it will get out of sync with all other keyboards attached to the system once it is woken up. I do know about special keyboards which do not have a concept of CAPS LOCK, SCROLL LOCK or NUM LOCK at all for the simple reason of not having the corresponding keys. Personally i do not think the keyboards should be held in sync (aka having a single virtual keyboard). If you think so, please raise this on linux-input mailing list (and CC at least me and Dmitry). Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for hid
On Tue, 15 May 2007, Oliver Neukum wrote: this is autosuspend for HID devices. It uses the new last_busy facility for USB devices. And for a few functions the pm counter. Hi Oliver, just a quick immediate note - I just tested it on my testing box, and it doesn't seem to work for me - the USB keyboard still seems to be awake (leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order to suspend it immediately. I will investigate. Thanks, -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for hid
On Wed, 16 May 2007, Robert Marquardt wrote: Anyway, what would be your proposal here? Currently the output reports (for changing the keyboard LEDs, for example) are being submitted as soon as the corresponding input event occurs (on different keyboard), which makes sense. Could you be more elaborate on what are the exact drawbacks you see here, and what would your proposal be? (postponing it into workqueue? why?). The basic problem is the difference between CAPS LOCK event and CAPS LOCK state. The state may be in user space only. Windows even has it on We have the LEDs states per-terminal. I do not think that changing this is going to happen. If you think so, please raise this on linux-input mailing list (and CC at least me and Dmitry). When i find time (yet another list to subscribe to). You don't have to be subscribed to post into this mailinglist. Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for hid
On Wed, 16 May 2007, Oliver Neukum wrote: just a quick immediate note - I just tested it on my testing box, and it doesn't seem to work for me - the USB keyboard still seems to be awake (leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order to suspend it immediately. I will investigate. You have compiled it with CONFIG_USB_SUSPEND, haven't you? I have, of course :) Otherwise I won't even have the 'autosuspend' file in sysfs, for example. -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for hid
On Wed, 16 May 2007, Oliver Neukum wrote: And as a sanity check, please check with lsusb whether your keyboard can do remote wakeup. I've never seen one that doesn't but it is within spec. Suspending of this keyboard used to work with older versions of your patches you sent me some weeks/months ago. -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for hid
On Wed, 16 May 2007, Robert Marquardt wrote: just a quick immediate note - I just tested it on my testing box, and it doesn't seem to work for me - the USB keyboard still seems to be awake (leds are on), even if I echo 0 into 'autosuspend' file in sysfs in order to suspend it immediately. Ah, that was nagging me. Is it at all possible to suspend a keyboard if you want to have the LEDs always in sync with their state? A suspended bus-powered USB device cannot drive LEDs so suspending an USB keyboard with CAPS LOCK on means it gets out of sync. I don't think that there is a better approach than what Oliver's code is currently doing - i.e. if the keyboard goes to sleep, queue the output reports which would change the state of the leds, and send them either when the keyboard wakes up, or when the queue is too long. Or we can simply just make any output report wake the device up. So this is going to make the leds state consistent as soon as the keyboard is woken up. This is also a reason why this is not going to fly with PID devices - we really want the force feedback to happen immediately, for example. -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for hid
On Wed, 16 May 2007, Oliver Neukum wrote: Actually, there's currently a race in the code that can trigger if you It is my understanding that a PID effect can be active long after the message went out to the device. Is that correct? Yes, I am afraid you can't assume that the effect playback has been already completed. -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for hid
On Wed, 16 May 2007, Oliver Neukum wrote: Suspending of this keyboard used to work with older versions of your patches you sent me some weeks/months ago. Yes, then it should keep working. My keyboard does suspend. Could you post your syslog? I have had also one very strange (and broken in many ways) usb mouse attached in a situation when things didn't suspend. After unplugging it, it seems to work. I will look at it in more detail now, thanks. -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] autosuspend for hid
On Wed, 16 May 2007, Pete Zaitcev wrote: I did not verify the function in detail, but the patch looks sane at a quick glance. Hi Pete and Oliver, (BTW, why was I again dropped from CC? :) ) I consider the things below crucial before this could be merged: - what to do with devices with force feedback? (or PID devices in general). The effect could have up to infinite duration (until it is stopped by appropriate stop method), and we definitely absolutely must not autosuspend a device that is currently in a process of playback. - think again about the output reports queuing. I am now inclined to think that we should simply wake the device up once the output report is to be delivered to it. There might be different situations other than just keyboard LEDs (there can be simply any kind of exotic HID device being controlled through hiddev and userspace could want to deliver the output report to it immediately, without any queuing) - (and of course coding style) Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] converting appletouch to usb autosuspend...
On Sat, 12 May 2007, Alan Stern wrote: While we are at it usb related powerhogs on this macbook pro are uhci_hcd (usb keyboard) and usb_hcd_poll_rh_status (rh_timer_func) too... They would use less power if the UHCI host controller were suspended. But obviously it cannot be suspended while devices attached to it (such as the USB keyboard and the appletouch device) remain active. A sidenote for completness, when this has been mentioned: Oliver has been working on autosuspend support for HID devices, he sent me some (yet incomplete) patches some time ago. So autosuspending of USB keyboards/mice/etc. is being worked on. Oliver, do you have any update please? Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] kernel option CONFIG_USB_HIDINPUT_POWERBOOK description update
On Mon, 7 May 2007, No?l Köthe wrote: config USB_HIDINPUT_POWERBOOK - bool Enable support for iBook/PowerBook special keys + bool Enable support for iBook/PowerBook/MacBook/MacBookPro special keys I will apply this into my tree, thanks. Great thanks. Does this mean it will go into your tree and then into the mainline kernel, or is there an additional step needed? No further steps needed on your side. Applied, thanks, -- Jiri Kosina- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] kernel option CONFIG_USB_HIDINPUT_POWERBOOK description update
On Wed, 2 May 2007, No?l Köthe wrote: The description of this option needs to be extended to be correct:) --- /usr/src/linux-2.6.21/drivers/usb/input/Kconfig 2007-04-27 18:02:46.0 +0200 +++ Kconfig.new 2007-05-02 16:47:56.0 +0200 @@ -28,12 +28,12 @@ depends on USB_HID INPUT=n config USB_HIDINPUT_POWERBOOK - bool Enable support for iBook/PowerBook special keys + bool Enable support for iBook/PowerBook/MacBook/MacBookPro special keys Hi, I will apply this into my tree, thanks. This option is needed on the Apple Intel Laptops, too. I would suggest to rename USB_HIDINPUT_POWERBOOK because its needed on Apple Laptops. Maybe USB_HIDINPUT_APPLELAPTOPS or something like this. Is a renaming patch for this welcome? The problem here is backwards compatibility - if we would like to do the change in a consistent way, we should rename all the places which (for historic reasons) mention powerbook only. Unfortunately this would also require renaming the module parameter hid_pb_fnmode, which might be a little too intrusive with respect to maintaining backward compatibility in userspace (ok, we have already been fiddling with this parameter anyway during the usbhid code split, but anyway). If you would care to make the patch which maintains backwards compatibility (for example by aliasing the variable pb_fnmode behing two module parameters), that might probably be ok. Thanks, -- Jiri Kosina- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Unitech USB barcode scanner issues
On Mon, 30 Apr 2007, Bret Towe wrote: I tested a de61 so far on an amd64 (previous testing was on a i386) and its working when I grabbed a few scanners to do testing tonight I apparently missed grabbing a de64 so I'll test that tomorrow Please let me know, thanks. and at the moment it looks like thats the only ids that are here I'm sure given enough time unitech will deside to swap chipsets again and break it again when that happens you will no doubt hear from me (hopefully with just a patch :) That should be fine anyway - the quirk will be only applied to de61 and de64 models with this patch - if there is any other product id that would need this byte swapping, it could be trivially added. The quirk won't be applied for other models. +#define rdesc_swap(n1,n2) tmp = rdesc[n2]; \ + rdesc[n2] = rdesc[n1]; \ + rdesc[n1] = tmp; wont someone complain about having a #define in a .c file? Sure, this was just for you to test, I will commit cleaned up version in my tree (you'll receive CC when this happens). Thanks, -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Unitech USB barcode scanner issues
On Sun, 29 Apr 2007, Bret Towe wrote:
There might be various reasons for this, most probably the report
descriptor of the device is broken. It might then be easy to fix the
report descriptor on the fly before it gets parsed, we are doing this
for various broken hardware already.
so this is a rather common issue then?
Hi Bret,
well not that common, but there are a few devices out there which have
broken report descriptors and we are fixing them before they enter the
parser. (some logitech keyboards, certain cymotion keyboard, etc.)
What product ID and vendor ID does your device have please? (you can
find out from the output of lsusb command).
Bus 005 Device 002: ID 04b4:de64 Cypress Semiconductor Corp.
this is one of the new ones that have the broken upper case bit I'll dig
around see if I can find a working old one to see if its id changed
since old and new were both broken with hid
Please try the patch below (against 2.6.21), it could solve your problem.
If it does, I would be interested in all other product IDs you are able to
reproduce this bug with, so that I can prepare proper patch, handling all
cypress hardware which is broken in the same way.
diff --git a/drivers/usb/input/hid-core.c b/drivers/usb/input/hid-core.c
index 827a75a..7cfee8d 100644
--- a/drivers/usb/input/hid-core.c
+++ b/drivers/usb/input/hid-core.c
@@ -1053,6 +1053,30 @@ static void hid_fixup_s510_descriptor(un
}
}
+#define rdesc_swap(n1,n2) tmp = rdesc[n2]; \
+ rdesc[n2] = rdesc[n1]; \
+ rdesc[n1] = tmp;
+static void hid_fixup_cypress_descriptor(unsigned char *rdesc, int rsize)
+{
+ char tmp;
+
+ if (rdesc[10] == 0x29 rdesc[12] == 0x19
+ rdesc[36] == 0x29 rdesc[38] == 0x19
+ rdesc[59] == 0x29 rdesc[61] == 0x19
+ rdesc[74] == 0x29 rdesc[76] == 0x19
+ rdesc[86] == 0x29 rdesc[88] == 0x19) {
+ info(Fixing up Cypress report descriptor\n);
+ rdesc[10] = rdesc[36] = rdesc[59] = rdesc[74] = rdesc[86] =
0x19;
+ rdesc[12] = rdesc[38] = rdesc[61] = rdesc[76] = rdesc[88] =
0x29;
+ rdesc_swap(11, 13);
+ rdesc_swap(37, 39);
+ rdesc_swap(60, 62);
+ rdesc_swap(75, 77);
+ rdesc_swap(87, 89);
+ } else
+ info(Not fixing Cypress report descriptor);
+}
+
static struct hid_device *usb_hid_configure(struct usb_interface *intf)
{
struct usb_host_interface *interface = intf-cur_altsetting;
@@ -1129,6 +1153,10 @@ static struct hid_device *usb_hid_config
if (quirks HID_QUIRK_LOGITECH_S510_DESCRIPTOR)
hid_fixup_s510_descriptor(rdesc, rsize);
+ if (le16_to_cpu(dev-descriptor.idVendor) == 0x04b4
+ le16_to_cpu(dev-descriptor.idProduct == 0xde64))
+ hid_fixup_cypress_descriptor(rdesc, rsize);
+
#ifdef CONFIG_HID_DEBUG
printk(KERN_DEBUG __FILE__ : report descriptor (size %u, read %d) = ,
rsize, n);
for (n = 0; n rsize; n++)
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] usb/hid:The HID Simple Driver Patches 0.5.1
On Mon, 30 Apr 2007, Li Yu wrote: This patch set include : 1. usb/hid: The HID Simple Driver Interface 0.5.0 (core) 2. usb/hid:Microsoft Natural Ergonomic Keyboard 4000 Driver 0.5.1 3. Some related kbuild changes. The changelog since 0.5.0: 1. The parameter ascii_keycode of usbnek4k.ko is on default. so the five custom keys can work without any care. 2. Add the parameter zoom_scroll of usbnek4k.ko, so we can use zoomin/zoomout handlers as mouse scrollwheel. this is on default too. Hi Li, is there any chance that you rather split up the hid bus patch you have been working on recently into independent reviewable patches instead, as we were discussing it previously? Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Unitech USB barcode scanner issues
On Mon, 30 Apr 2007, Bret Towe wrote: Please try the patch below (against 2.6.21), it could solve your problem. If it does, I would be interested in all other product IDs you are able to reproduce this bug with, so that I can prepare proper patch, handling all cypress hardware which is broken in the same way. patch works with the newer ones and the older id is below Hi Bret, thanks for confirmation, I will queue the (modified, tidied) version of the patch in my tree for 0x04b4/0xde64. the de64 btw is the one with the upper case issue Is this still the case with my patch applied to usbhid, or does this happen only with usbkbd module? this de61 model had acted fine I was unable to test this patch with it to see if it works right or not since the scanner I found was half toast (showed up on lsusb but didnt power on) Bus 001 Device 003: ID 04b4:de61 Cypress Semiconductor Corp. So this one worked even previously without the patch? Thanks, -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Unitech USB barcode scanner issues
On Mon, 30 Apr 2007, Bret Towe wrote: where is your tree? or could I get a copy of the cleaned up patch? My tree is hid.git on git.kernel.org. The cleaned up patch is not yet there, I will send it to you when I commit it. I am waiting for more of your feedback so that I put support for all product ids that need that. Is this still the case with my patch applied to usbhid, or does this happen only with usbkbd module? looks like it is working now (didnt have a barcode eariler to test) Great to hear that, thanks for testing. Bus 001 Device 003: ID 04b4:de61 Cypress Semiconductor Corp. So this one worked even previously without the patch? I stated that in a rather confusing way didn't I the de61 had acted fine reguarding case, I was unable to test it to see if the patch also fixed that models issue with using hid Is it possible that you will have chance to test it with patched hid-core.c in near future? (you will have to modify that if() condition trivially, so that it matches 0xde61 instead of 0xde64). Thanks, -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Unitech USB barcode scanner issues
On Mon, 30 Apr 2007, Bret Towe wrote: accutally as soon as i had sent off that previous email I went looking for scanners to make sure they all worked or not the below is what i got with a 61 [ 135.479986] usbhid 1-1:1.0: usb_probe_interface [ 135.479986] usbhid 1-1:1.0: usb_probe_interface - got id [ 135.479986] drivers/usb/input/hid-core.c: HID probe called for ifnum 0 [ 135.493319] drivers/usb/input/hid-core.c: Not fixing Cypress report descriptor [ 135.496653] drivers/usb/input/hid-core.c: report descriptor (size 64, read 64) = 05 01 09 06 a1 01 05 07 29 e7 19 e0 25 01 15 00 75 01 95 08 81 02 95 01 75 08 81 01 95 05 75 01 05 08 29 05 19 01 91 02 95 01 75 03 91 01 95 06 75 08 26 e7 00 15 00 05 07 29 e7 19 00 81 00 c0 [ 135.496653] drivers/usb/input/hid-core.c: parsing report descriptor failed [ 135.496653] usbcore: registered new interface driver usbhid [ 135.496653] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 136.949986] hub 5-0:1.0: hub_suspend [ 136.949986] ehci_hcd :00:1d.7: suspend root hub [ 136.949986] usb usb5: usb auto-suspend [ 137.496652] usb 1-1: usb auto-suspend [ 139.509986] hub 1-0:1.0: hub_suspend and i did this for the hid-core.c bit if (le16_to_cpu(dev-descriptor.idVendor) == 0x04b4 (le16_to_cpu(dev-descriptor.idProduct == 0xde64) || le16_to_cpu(dev-descriptor.idProduct == 0xde61))) I thought this would be more handy Thanks for the report - it clearly shows that Cypress produces different hardware with different report descriptors, all broken in a very similar way (improper order of usage minimum and maximum items), but not identical. This would require more general handling and care ... I will send you updated patch for test. -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Unitech USB barcode scanner issues
On Tue, 1 May 2007, Jiri Kosina wrote:
Thanks for the report - it clearly shows that Cypress produces different
hardware with different report descriptors, all broken in a very similar
way (improper order of usage minimum and maximum items), but not
identical. This would require more general handling and care ... I will
send you updated patch for test.
Bret,
please try the patch below and let me know. It should work with both the
broken cypress barcode readers, 0xde61 and 0xde64. If you are aware of any
other product ids which would require similar fixup, please let me know.
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
diff --git a/drivers/usb/input/hid-core.c b/drivers/usb/input/hid-core.c
index 827a75a..f5ef2e4 100644
--- a/drivers/usb/input/hid-core.c
+++ b/drivers/usb/input/hid-core.c
@@ -650,6 +650,8 @@ void usbhid_init_reports(struct hid_devi
#define USB_DEVICE_ID_CYPRESS_MOUSE0x0001
#define USB_DEVICE_ID_CYPRESS_HIDCOM 0x5500
#define USB_DEVICE_ID_CYPRESS_ULTRAMOUSE 0x7417
+#define USB_DEVICE_ID_CYPRESS_BARCODE_10xde61
+#define USB_DEVICE_ID_CYPRESS_BARCODE_20xde64
#define USB_VENDOR_ID_BERKSHIRE0x0c98
#define USB_DEVICE_ID_BERKSHIRE_PCWD 0x1140
@@ -945,6 +947,9 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS3_CONTROLLER,
HID_QUIRK_SONY_PS3_CONTROLLER },
+ { USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_BARCODE_1,
HID_QUIRK_SWAPPED_MIN_MAX },
+ { USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_BARCODE_2,
HID_QUIRK_SWAPPED_MIN_MAX },
+
{ USB_VENDOR_ID_CIDC, 0x0103, HID_QUIRK_IGNORE },
{ 0, 0 }
@@ -1053,6 +1058,30 @@ static void hid_fixup_s510_descriptor(un
}
}
+#define rdesc_swap(n1,n2) tmp = rdesc[n2]; \
+ rdesc[n2] = rdesc[n1]; \
+ rdesc[n1] = tmp;
+static void hid_fixup_cypress_descriptor(unsigned char *rdesc, int rsize)
+{
+ char tmp;
+ short fixed = 0;
+ int i;
+
+ for (i = 0; i rsize - 4; i++) {
+ if (rdesc[i] == 0x29 rdesc [i+2] == 0x19) {
+ fixed = 1;
+ rdesc[i] = 0x19;
+ rdesc[i+2] = 0x29;
+ rdesc_swap(i+1, i+3);
+ }
+ }
+
+ if (fixed)
+ info(Fixing up Cypress report descriptor);
+ else
+ info(Cypress report descriptor didn't require fixup);
+}
+
static struct hid_device *usb_hid_configure(struct usb_interface *intf)
{
struct usb_host_interface *interface = intf-cur_altsetting;
@@ -1129,6 +1158,9 @@ static struct hid_device *usb_hid_config
if (quirks HID_QUIRK_LOGITECH_S510_DESCRIPTOR)
hid_fixup_s510_descriptor(rdesc, rsize);
+ if (quirks HID_QUIRK_SWAPPED_MIN_MAX)
+ hid_fixup_cypress_descriptor(rdesc, rsize);
+
#ifdef CONFIG_HID_DEBUG
printk(KERN_DEBUG __FILE__ : report descriptor (size %u, read %d) = ,
rsize, n);
for (n = 0; n rsize; n++)
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 8c97d4d..0542c24 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -269,6 +269,7 @@ struct hid_item {
#define HID_QUIRK_SONY_PS3_CONTROLLER 0x0008
#define HID_QUIRK_LOGITECH_S510_DESCRIPTOR 0x0010
#define HID_QUIRK_DUPLICATE_USAGES 0x0020
+#define HID_QUIRK_SWAPPED_MIN_MAX 0x0040
/*
* This is the global environment of the parser. This information is
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB HID bug (was [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1)
On Sat, 28 Apr 2007, Vincent ETIENNE wrote:
No, it isn't a problem in the USB core. The device itself is messed up;
it really does report idVendor and idProduct both equal to 0.
So is it just a scary trace but without consequence that i could ignored
? May i ask you what is the device which is messed up ? ( Maybe should i
change it ? )
Hi Vincent,
yes, the device is messed up, but it shouldn't have any consequences for
you - the HID driver is able to correctly handle that, so as soon as we
don't need to add any extra quirks for such device, everything should be
fine. I have removed the WARN_ON from the code in my tree. I think we
still don't want users to add quirks for such broken devices (as it would
collide with hid_blakclist[] terminator), so I have left the initial
condition in usbhid_modify_dquirk() untouched.
From: Jiri Kosina [EMAIL PROTECTED]
USB HID: don't warn on idVendor == 0
It turns out that there are broken devices out there that incorrectly
report VID/PID as 0x000, see http://lkml.org/lkml/2007/4/27/496
Therefore we should not confuse users by dumping warnings and stacktraces
in such situation. It is not possible to add quirks for such horribly
broken devices, but currently that's not needed.
Signed-off-by: Jiri Kosina [EMAIL PROTECTED]
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 27188bd..17a8755 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -477,8 +477,6 @@ static struct hid_blacklist *usbhid_exis
struct quirks_list_struct *q;
struct hid_blacklist *bl_entry = NULL;
- WARN_ON(idVendor == 0);
-
list_for_each_entry(q, dquirks_list, node) {
if (q-hid_bl_item.idVendor == idVendor
q-hid_bl_item.idProduct == idProduct) {
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Unitech USB barcode scanner issues
On Fri, 27 Apr 2007, Bret Towe wrote: currently on 2.6.20.7 by data being processed you mean what should appear on screen in this case? ill update my laptop to .21 and add the debug items in the mean time ill just attach the usbmon logs of the plugin between upgrade and something else I need todo it will be a couple hours well that took longer than I would of liked attached is dmesg output with hid debug enabled has the device being rejected by hid and then working after i modprobe usbkbd Hi Bret, thanks for your output. It's clear from it that HID parser was unable to parse the report descriptor of the device and therefore didn't claim it. There might be various reasons for this, most probably the report descriptor of the device is broken. It might then be easy to fix the report descriptor on the fly before it gets parsed, we are doing this for various broken hardware already. What product ID and vendor ID does your device have please? (you can find out from the output of lsusb command). Your dump gives all the information I need to analyze the report descriptor and see what's broken in it - I'll hopefully find time to do it tomorrow and will send you a patch to test. Thanks, -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] USB HID bug (was [PROBLEM] Bonding driver in linux-2.6.21-rc6-mm1)
On Sat, 28 Apr 2007, Vincent ETIENNE wrote: I now don't immediately see how this could happen - the vendor ID seems to be propagated properly from hid_probe() (nothing has been changed in this codepath), so this would mean that hid_probe() has been passed usb_interface for which le16_to_cpu(interface_to_usbdev(intf).dev-descriptor.idVendor) is equal to zero ... and this definitely shouldn't happen for any sane device (could the original poster please verify with lsusb, just to be 100% sure?). You could download the result of lsusb -vvv from http://mail1.vetienne.net/linux/lsusb.log Hi Vincent, thanks for the report. It's pretty awesome though - all the USB devices seem to have vendor and product id set to 0x. Greg, have you ever met this? linux-usb-devel added to CC (full thread here: http://lkml.org/lkml/2007/4/27/496) So this definitely isn't a HID-specific problem, something is confusing the USB VID/PIDs. -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Unitech USB barcode scanner issues
On Thu, 26 Apr 2007, Bret Towe wrote: For some time now at a place I work at we have been using some Unitech MS-180 barcode scanners todo logins the work around we had in place basicly was using a 2.4 kernel on the thin clients doing the logins since 2.4 worked with them 2.6 had some issue and I had posted here asking for help and got some suggestions on how to precede, between the work around working and me not knowing the USB/HID code any I had ignored the issue. Hi Bret, do I get your mail right that 2.4 works fine with the hid driver, but to make things working in 2.6 you have to use usbkbd driver? If so, we certainly need to fix this regression. usbkbd should not be used in production. Checking the difference between the working older scanners and newer broken I saw the following via usbmon the below is from a scan of the same barcode from 2 scanners. all the C lines on the broken start with 01 and seem to be shifted compaired to the working working: 810035c5ea40 536368059 C Ii:005:01 0 8 = 0200 810035c5ea40 536368088 S Ii:005:01 -115 8 810035c5ea40 536376058 C Ii:005:01 0 8 = 02001800 810035c5ea40 536376080 S Ii:005:01 -115 8 810035c5ea40 536384057 C Ii:005:01 0 8 = 810035c5ea40 536384075 S Ii:005:01 -115 8 broken: 810035c5e980 593493403 C Ii:006:01 0 8 = 0102 810035c5e980 593493417 S Ii:006:01 -115 8 810035c5e980 593501397 C Ii:006:01 0 8 = 01020018 810035c5e980 593501413 S Ii:006:01 -115 8 810035c5e980 593509400 C Ii:006:01 0 8 = 0100 810035c5e980 593509419 S Ii:006:01 -115 8 This by itself doesn't necessairly mean that it's broken, the report descriptor for the two devices might be different, and therefore the individual bytes in the URB should have different meaning. also I do have usbmon logs of one of the scanners being plugged in with just hid loaded and with usbkbd loaded and unplugging again If wanted I can attach or upload somewhere from what I gather usbkbd should not have to be relied on unless your doing embedded work or inital boot requirements? Exactly. We certainly have to make this supported by the hid driver if possible. What kernel version do you use? Could you please grab any recent one (2.6.21 is preferred), and compile the kernel with CONFIG_HID_DEBUG option enabled? (you'll find it under Device Drivers - HID devices - HID debugging support in menuconfig), and post the output corresponsing both to the time the device is connected to the system and also when the data is being processed? Thanks, -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Writing HID driver for a USB phone handset IPEVO VP170 (0x1778:0x0403)
On Wed, 25 Apr 2007, Robin H. Johnson wrote: Notice the X and Y in the output. I have a detailed mapping of the keys below. [ 3479.472985] drivers/hid/hid-core.c: report (size 7) (unnumbered) [ 3479.472985] drivers/hid/hid-core.c: report 0 (size 7) = f0 XX YY 00 00 00 00 [ 3479.472985] hid-debug: input Consumer.00e9 = 0 [ 3479.472985] hid-debug: input Consumer.00ea = 0 [ 3479.472985] hid-debug: input Consumer.00e2 = 0 [ 3479.472985] hid-debug: input Consumer. = 0 [ 3479.472985] hid-debug: input Consumer. = 1 [ 3479.472985] hid-debug: input Consumer. = 1 [ 3479.472985] hid-debug: input Consumer. = 1 [ 3479.472985] hid-debug: input Consumer. = 1 [ 3479.472985] hid-debug: input Consumer. = XX [ 3479.472985] hid-debug: input Consumer. = YY [ 3479.472985] hid-debug: input Consumer. = 0 [ 3479.472985] hid-debug: input Consumer. = 0 [ 3479.472985] hid-debug: input Consumer. = 0 [ 3479.472985] hid-debug: input Consumer. = 0 Hi Robin, this doesn't look particularly good. YY is always 0..3, seems to be a small cycle counter (that wraps) over the scope of ALL buttons. Eg pressing Mute, then Keypad7 will increment the counter by two. XX mapping table (hex): 1c = 'Skype' c1 = 'Out'/+ c3 = 'List' 1d = Selector-Up 1e = Selector-Down 1f = No/Onhook 20 = Yes/Offhook 2f = Mute f1 = Circle (GROUP 0) f2 = Diamond f3 = Square 32 = Volume Up 33 = Volume Down b0 = Keypad 0 b1 = Keypad 1 b2 = Keypad 2 b3 = Keypad 3 b4 = Keypad 4 b5 = Keypad 5 b6 = Keypad 6 b7 = Keypad 7 b8 = Keypad 8 b9 = Keypad 9 ba = Keypad * bb = Keypad # This doesn't seem like it would be anyhow compatible with standardized HID Usage Tables - the codes are just different than what the standard specifies. I'll inspect the report descriptor in a further detail and will let you know if there is a possibility how to fix this on-the-fly, but maybe writing a separate (userland, using hiddev or just-being-created hidraw interface) driver would be better. Thanks for the report, -- Jiri Kosina SUSE Labs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.21-rc6-mm1 USB related boot hang - bisection result
On Fri, 27 Apr 2007, Helge Hafting wrote: 2.6.21-rc6 boots up fine. Both rc6 and rc7 has a different problem - the machine tends to hang after some minutes work in X. That hang is unusual in that moving the mouse still move the X cursor, but everything else stops and sysrq fails me. But that is another story. [...] The (first) hanging patch in 2.6.21-rc6-mm1 is: git-acpi.patch Hi Helge, thanks for the effort. If you take stock rc6-mm1 and revert just git-acpi.patch, doesn the machine behave correctly? -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
[linux-usb-devel] [PATCH] [RFC] xpad - support for Microsoft XBox controllers
Hi,
recently I have been looking into bugreports against xpad driver - the
complaints were that for some devices (I am aware of at least
0x045e/0x028e and 0x0738/0x4716), the driver doesn't work at all even if
the device ids are added into xpad_device[] array. In fact the driver
doesn't even get bound to the device.
This is caused by the fact that at least these controllers claim to be of
a vendor-specific class (0xff), and therefore the
{ USB_INTERFACE_INFO('X', 'B', 0) }
in module device table doesn't match them. There is a out-of-tree fork of
the driver at [1] which adds (among other things)
{ USB_INTERFACE_INFO( 255 , 93 , 1) }, /* Xbox 360 */
to the module device table. But that also does not going work, as
USB_INTERFACE_INFO for vendor-specific class is not going to be matched by
usb_match_one_id().
The cleanest solution seems to be to specify particular devices properly
by USB_DEVICE macros in module device table for those xpad devices which
have nonstandard and vendor-specific class/subclass. Below is a patch that
makes 0x045e/0x028e and 0x0738/0x4716 work with xpad driver (or at least
correctly bound to the device). (this is obviously not yet suitable for
being merged - I am not sure yet whether MAP_DPAD_TO_AXES is the correct
one for this device, etc).
We could need to do this for all devices which are currently present in
xpad_device[] and have 0xff as their USB class. I however currently have
no idea for which devices from xpad_device[] is this the case. Does anyone
have any details please? Thanks.
[1]
http://xbox.cvs.sourceforge.net/xbox-linux/kernel-2.6/drivers/usb/input/xpad.c?view=log
diff --git a/drivers/usb/input/xpad.c b/drivers/usb/input/xpad.c
index e4bc76e..9fbe694 100644
--- a/drivers/usb/input/xpad.c
+++ b/drivers/usb/input/xpad.c
@@ -103,6 +103,7 @@ static const struct xpad_device {
{ 0x045e, 0x0289, Microsoft X-Box pad v2 (US), MAP_DPAD_TO_AXES },
{ 0x045e, 0x0285, Microsoft X-Box pad (Japan), MAP_DPAD_TO_AXES },
{ 0x045e, 0x0287, Microsoft Xbox Controller S, MAP_DPAD_TO_AXES },
+ { 0x045e, 0x028e, Microsoft Xbox 360 controller, MAP_DPAD_TO_AXES },
{ 0x0c12, 0x8809, RedOctane Xbox Dance Pad, MAP_DPAD_TO_BUTTONS },
{ 0x044f, 0x0f07, Thrustmaster, Inc. Controller, MAP_DPAD_TO_AXES },
{ 0x046d, 0xca84, Logitech Xbox Cordless Controller, MAP_DPAD_TO_AXES
},
@@ -115,6 +116,7 @@ static const struct xpad_device {
{ 0x0738, 0x4536, Mad Catz MicroCON, MAP_DPAD_TO_AXES },
{ 0x0738, 0x4540, Mad Catz Beat Pad, MAP_DPAD_TO_BUTTONS },
{ 0x0738, 0x4556, Mad Catz Lynx Wireless Controller, MAP_DPAD_TO_AXES
},
+ { 0x0738, 0x4716, Mad Catz XBox 360 Controller, MAP_DPAD_TO_AXES },
{ 0x0738, 0x6040, Mad Catz Beat Pad Pro, MAP_DPAD_TO_BUTTONS },
{ 0x0c12, 0x8802, Zeroplus Xbox Controller, MAP_DPAD_TO_AXES },
{ 0x0c12, 0x8810, Zeroplus Xbox Controller, MAP_DPAD_TO_AXES },
@@ -162,6 +164,10 @@ static const signed short xpad_abs_pad[]
static struct usb_device_id xpad_table [] = {
{ USB_INTERFACE_INFO('X', 'B', 0) },/* X-Box USB-IF not approved
class */
+
+ /* devices with vendor-specific class */
+ { USB_DEVICE(0x045e, 0x028e) }, /* Microsoft XBox 360
Controller */
+ { USB_DEVICE(0x0738, 0x4716) }, /* Mad Catz XBox 360 controller
*/
{ }
};
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.21-rc6-mm1 USB related boot hang
On Wed, 25 Apr 2007, Helge Hafting wrote: Anyway, based on information you have provided in your later messages, it seems that it is probably not necessairly related neither to USB nor HID, as you are getting hangs at different stages of boot, depending on your local configuration/kernel version used. Is vanilla 2.6.21-rc6 ok? If so, would you have time to bisect the offending patch? I don't know about 2.6.21-rc6, but 2.6.21-rc7 (from fresh sources) is good. It boots up without hanging, and my USB devices works too. Should I test rc7-mm1 then? That would also be useful. But really identifying offending patch using bisection would help most. And it should be pretty easy and not too much time consuming for you, as the bug triggers immediately upon boot in your case. In case you are not convenient with bisecting by hand Andrew's quilt patchset, don't forget that it is also possible to obtain -mm tree through git, which provides very convenient means for bisecting. This is what I usually do. -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] current state of USB SUSPEND?
On Wed, 18 Apr 2007, Jeroen Janssen wrote: I noticed several recent USB SUSPEND related patches on this mailinglist and I was wondering if someone could tell me what the current state of USB SUSPEND is. Should USB devices be suspend 'automaticly' (by the kernel) when suspending to ram? Or do I need to manually suspend the devices somehow? Hi Jerome, USB suspend is not closely related to suspending of the system (swsusp/acpi). USB suspend is independent, and allows for USB-specific suspending of devices that have not been recently used, to reduce power consumption. The USB_SUSPEND feature has been present in mainline kernel for quite some time, under CONFIG_USB_SUSPEND option. The patches that have been discussed lately here were related to some changes of the usb suspend architecture, allowing per-device specification of timeout before putting device to suspend, etc. -- Jiri Kosina - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] hid: hid bus prototype 20070416
On Mon, 16 Apr 2007, Li Yu wrote:
HID bus prototype 20070416
Hi Li,
thanks for taking care. Well, the patch is quite huge, do you think you
could split it into separate independent parts (use quilt or something
similar for patch management) which could be reviewed independently?
As the code changes are often quite non-trivial, layering is changed,
lots of files are touched, etc. it would help a lot.
Notes from a quick skim through the patch:
- it seems that you accidentaly deleted the newly added quirk for
mightymouse in the bluetooth hid code?
- what is the point behind HID_QUIRK_SKIP? Why doesn't HID_QUIRK_IGNORE
suffice? And why is it defined in so strange way:
@@ -270,6 +271,7 @@ struct hid_item {
#define HID_QUIRK_LOGITECH_DESCRIPTOR 0x0010
#define HID_QUIRK_DUPLICATE_USAGES 0x0020
#define HID_QUIRK_RESET_LEDS 0x0040
+#define HID_QUIRK_SKIP 0x8000
- there are bunches of some easy codingstyle issues (spaces around '=',
etc)
But doing really thorough review is quite hard, as the patch contains lots
of unrelated changes. I'll look at it a little bit more, but when you send
a broken-out version with separate changes, that'd be great.
Thanks,
--
Jiri Kosina
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] hid drivers
On Fri, 13 Apr 2007, John Wojnaroski wrote: I'm writing a simple little driver to read three bytes from a hid device when plugged in it reports as hiddev96:__--usb-:00:1d.0-2 and shows up in /dev/usb/hiddev0 and is enumerated in /proc/bus/usb/devices. Thinking a simple usb_control_msg will be good and simple enough to have the device send the three bytes Hi John, there have been various discussions lately about many topics related to your question - please crawl through the list archives if interested (the best keywords probably are hid bus, hiddev, hidraw). Is there a way to do that with the hid interface using ioctl open/read/write functions or will it be necessary to use the usb_control_msg(...) call directly? What you describe is unfortunately not doable (in a trivial way) through hiddev - hiddev works in a way that it parses the reports based on the information obtained from the device's report descriptor, and processess the fields for outgoing reports also in this respect. Therefore it is not well suitable for straigforward submission of 'raw' HID data. Unfortunately, it's often what userland applications want most - they are willing to send the raw hid data to the device and don't want the kernel to tamper it in any way. There may be many reasons for them doing so, the most significant is broken/undocumented devices which have report descriptor that confuses the in-kernel HID layer and it parses reports/fields incorrectly. This is why many applications chose to use libhid/libusb instead. This passes the data directly to the USB transport layer, without letting the HID layer to touch it. And this is also the reason for the new 'hidraw' interface being created - the current prototype of mostly-feature-less version is in current -mm kernels, and also in the HID git tree. It's possible that both the API and the internals of the hidraw interface will change before being merged into mainline - most importantly there is a hid bus coming soon (hopefully), which might change things. But it might be interesting for you to look at. To sum things up - currently, hiddev doesn't seem to be a feasible option for you. You can either use libhid/libusb and submit the data directly to USB transport, or you can experiment with kernel-provided lightweight hidraw interface in -mm, but it's not guaranteed to be in a frozen-API state yet. Hope this helps, -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.21-rc6-mm1 USB related boot hang
On Thu, 12 Apr 2007, Helge Hafting wrote: OK. If you add initcall_debug to the kernel boot command line, what's the last thing we call? The last messages (handwritten, somewhat shortened) calling hid_init+0x0/0x10() returned 0 ran for 0 msec calling hid_init+0x0/0x50() usbcore registered new interface driver hiddev and then it hangs completely. Hi Helge, 2.6.21-rc6 (without any -mm patches) works fine? Could you please - try booting without any HID devices plugged in (i.e. usb mice, usb keyboards) if the problem persists? - recompile 2.6.21-rc6-mm1 with git-hid.patch reverted to see if it helps? I am unfortunately not able to reproduce it here on x86_64. Thanks, -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.21-rc6-mm1 USB related boot hang
On Thu, 12 Apr 2007, Jiri Kosina wrote: Could you please - try booting without any HID devices plugged in (i.e. usb mice, usb keyboards) if the problem persists? - recompile 2.6.21-rc6-mm1 with git-hid.patch reverted to see if it helps? Do you compile with CONFIG_HIDRAW? -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.21-rc6-mm1 USB related boot hang
On Thu, 12 Apr 2007, Jiri Kosina wrote: - try booting without any HID devices plugged in (i.e. usb mice, usb keyboards) if the problem persists? - recompile 2.6.21-rc6-mm1 with git-hid.patch reverted to see if it helps? Do you compile with CONFIG_HIDRAW? Helge, with your .config, my machine hangs upon IPMI initialization, the last thing I see before total freeze is ipmi_si: Trying PCI-specified kcs state machine at mem address 0xd0121000, slave address 0x0, irq 5 (this was run on 32bit machine) When I turn IPMI off, I can't reproduce your hang, evetything runs smoothly. Could you please try recompiling the kernel with IPMI disabled, if it could be related? Corey added to CC. Thanks, -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.21-rc6-mm1 USB related boot hang
On Thu, 12 Apr 2007, Andrew Morton wrote: Was that with ipmi linked into vmlinux? (Please send the output of grep IPMI .config) I thought we fixed that. Confirmed. 2.6.21-rc6-mm1 with CONFIG_IPMI_SI=y hangs upon boot on the already mentioned printk from ipmi_si. With CONFIG_IPMI_SI=m the boot succeeds. When manually trying to modprobe ipmi_si after that, the modprobe itself hangs, but the machine remains usable otherwise. I still wonder if this could be related to what Helge was originally reporting. -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.21-rc6-mm1 USB related boot hang
On Thu, 12 Apr 2007, Jiri Kosina wrote: CONFIG_IPMI_SI=y hangs upon boot on the already mentioned printk from ipmi_si. With CONFIG_IPMI_SI=m the boot succeeds. When manually trying to modprobe ipmi_si after that, the modprobe itself hangs, but the machine remains usable otherwise. Actually, after approximately 6 minutes 30 seconds, the modprobe finishes with -ENODEV and the following is spitted into dmesg: ipmi_si: There appears to be no BMC at this location ACPI: PCI interrupt for device :02:00.4 disabled ipmi_si: Unable to find any System Interface(s) Anyway I just checked that I get precisely the same behavior with plain 2.6.21-rc6, so we can rule out -mm with this issue. It's possible that this system has some broken KCS. I will try to narrow this down. Anyway, the USB-related hang Helge is seeing is therefore a different story. -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.21-rc6-mm1 USB related boot hang
On Thu, 12 Apr 2007, Helge Hafting wrote: The last messages (handwritten, somewhat shortened) calling hid_init+0x0/0x10() returned 0 ran for 0 msec calling hid_init+0x0/0x50() usbcore registered new interface driver hiddev and then it hangs completely. OK, so it hangs somewhere nearby usbhid's hid_init(), and the usb_register() has been already invoked. Could you please apply the superstupid patch below and send me the output up to the point it hangs? I am curious to know whether it hangs somewhere inside usb_register(), or elsewhere. Thanks. diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c index 1ddca31..d930f62 100644 --- a/drivers/hid/usbhid/hid-core.c +++ b/drivers/hid/usbhid/hid-core.c @@ -1550,15 +1550,22 @@ static int __init hid_init(void) retval = hiddev_init(); if (retval) goto hiddev_init_fail; + printk(KERN_DEBUG hid_init: before usb_register()\n); retval = usb_register(hid_driver); + printk(KERN_DEBUG hid_init: after usb_register(), retuned %d\n, retval); if (retval) goto usb_register_fail; info(DRIVER_VERSION : DRIVER_DESC); + printk(KERN_DEBUG hid_init: returning 0\n); + dump_stack(); return 0; usb_register_fail: + printk(KERN_DEBUG hid_init: calling hiddev_exit()\n); hiddev_exit(); hiddev_init_fail: + printk(KERN_DEBUG hid_init: returning %d\n, retval); + dump_stack(); return retval; } - 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.phpp=sourceforgeCID=DEVDEV ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] 2.6.21-rc6-mm1 USB related boot hang
On Thu, 12 Apr 2007, Helge Hafting wrote: Are you sure this is the correct patch - against 2.6.21-rc6-mm1 ? Hunk 1 out of 1 failed . . . Well I am pretty sure: box:~/scratch # wget ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/2.6.21-rc6-mm1.bz2/dev/null 21 box:~/scratch # wget ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.20.tar.bz2/dev/null 21 box:~/scratch # wget ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.21-rc6.bz2/dev/null 21 box:~/scratch # tar xf linux-2.6.20.tar.bz2 box:~/scratch # cd linux-2.6.20/ box:~/scratch/linux-2.6.20 # mv ../patch-2.6.21-rc6.bz2 . box:~/scratch/linux-2.6.20 # bunzip2 patch-2.6.21-rc6.bz2 box:~/scratch/linux-2.6.20 # patch -p1 patch-2.6.21-rc6 /dev/null 21; echo $? 0 box:~/scratch/linux-2.6.20 # mv ../2.6.21-rc6-mm1.bz2 . box:~/scratch/linux-2.6.20 # bunzip2 2.6.21-rc6-mm1.bz2 box:~/scratch/linux-2.6.20 # patch -p1 2.6.21-rc6-mm1 /dev/null 21; echo $? 0 box:~/scratch/linux-2.6.20 # cat tmp.patch diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c index 1ddca31..d930f62 100644 --- a/drivers/hid/usbhid/hid-core.c +++ b/drivers/hid/usbhid/hid-core.c @@ -1550,15 +1550,22 @@ static int __init hid_init(void) retval = hiddev_init(); if (retval) goto hiddev_init_fail; + printk(KERN_DEBUG hid_init: before usb_register()\n); retval = usb_register(hid_driver); + printk(KERN_DEBUG hid_init: after usb_register(), retuned %d\n, retval); if (retval) goto usb_register_fail; info(DRIVER_VERSION : DRIVER_DESC); + printk(KERN_DEBUG hid_init: returning 0\n); + dump_stack(); return 0; usb_register_fail: + printk(KERN_DEBUG hid_init: calling hiddev_exit()\n); hiddev_exit(); hiddev_init_fail: + printk(KERN_DEBUG hid_init: returning %d\n, retval); + dump_stack(); return retval; } box:~/scratch/linux-2.6.20 # patch -p1 tmp.patch patching file drivers/hid/usbhid/hid-core.c box:~/scratch/linux-2.6.20 # So I guess you are operating on some broken version of 2.6.21-rc6-mm1 codebase if you are getting rejects on this trivial patch. Anyway, based on information you have provided in your later messages, it seems that it is probably not necessairly related neither to USB nor HID, as you are getting hangs at different stages of boot, depending on your local configuration/kernel version used. Is vanilla 2.6.21-rc6 ok? If so, would you have time to bisect the offending patch? Thanks, -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] HID bus prototype - 20070408
On Sun, 8 Apr 2007, Li Yu wrote: The attachment is the latest HID bus prototype. It have such changes: 0. Move the hidp directory from net/bluetooth/ to drivers/hid/. Hi Li, we have been discussing this with Marcel previously, and the decission was to let the hidp code where it is right now, due to it being very closely connected to the bluetooth network stack. 1. HID/Bluetooth support, ONLY FOR HIGHLY EXPERIMENT. I have no any such device to test yet. I didn't have time yet to review the patch you sent previously, but I don't still quite understand why does the transport layer matter here? The generic HID layer, as it is in kernel now, makes an abstraction in a way that the HID-specific drivers should not care about the underlying transport layer. I am sorry for it is not in patch form. That's quite unfortunate. I'll try to review it nevertheless, but it'd be much more convenient if you manage to send a patch. Thanks, -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] [regression] hid-core: Do not discard truncated input reports
On Tue, 10 Apr 2007, Robert Marquardt wrote: Truncated reports should not be discarded since it prevents buggy devices from communicating with userspace. Does it really make sense to support such hopelessly broken devices? Do these devices work with Windows without special drivers? It definitely makes sense - at least due to the fact that such (hopelessly broken) devices have already been supported by the linux kernel, so accidentaly removing the support definitely is a regression, which is a thing we don't want to happen. Thanks, -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC] HID bus design overview.
On Wed, 4 Apr 2007, Adam Kropelin wrote: hiddev will have to stay for quite some time, exactly because of backward compatibility with userspace applications/drivers that use it (I am not aware of many of them though, but apparently there are some). Apcupsd is the one on my mind, but I believe there are others. I am aware only of apcupsd, nut and hid2hci. On Apcupsd we've recently introduced a libusb-based driver that does all HID parsing in userspace. Not only does that free us from hiddev, it also frees us from the umpteen other proprietary HID interfaces across various platforms. Although the hiddev-based driver is still the default for Linux platforms, I plan to change that in the next major release and thus begin migrating folks off of hiddev. Great. Do you use libusb to obtain raw hid events? Could you by any chance look at current implementation of hidraw (it's in -mm or I can send it to you as a separate patch) and check whether you have any comments on this? It would be good if you could use hidraw rather than reading raw usb data through libusb. Thanks. -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb hid: reset NumLock
On Wed, 4 Apr 2007, Dmitry Torokhov wrote: Unfortunately my patch is crap. We should not be sending events down dev-event() until dev-open() has been called because many drivers start hardware from there and not ready until then. So it is HID driver responsibility to properly reset leds after all. Pete, could you please resend your patch, with proper metadata, we need to merge your one then. Thanks, -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [PATCH] [regression] hid-core: Do not discard truncated input reports
On Thu, 5 Apr 2007, Adam Kropelin wrote: Truncated reports should not be discarded since it prevents buggy devices from communicating with userspace. Will push this for 2.6.21. Thanks, -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC] HID bus design overview.
On Wed, 4 Apr 2007, Adam Kropelin wrote: I apologize for picking up this thread late and asking what may be a question with an obvious answer... Will hiddev still exist after hidraw and the HID bus redesign work is done? I have a widely-deployed userspace app that relies on hiddev, and I'm looking for reassurance that it will still work as it always has... Hi Adam, hiddev will have to stay for quite some time, exactly because of backward compatibility with userspace applications/drivers that use it (I am not aware of many of them though, but apparently there are some). I won't allow it to vanish, don't worry. We just have to make sure that new users will use hidraw instead, as it provides more flexibility for the user, is not dependent on the underlying transport protocol, etc. -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb hid: reset NumLock
On Mon, 2 Apr 2007, Pete Zaitcev wrote:
How about this?
Looks quite fine to me.
But in case that Dmitry's patch Input: add generic suspend and resume for
uinput devices fixes your issue too, I wouldn't merge it as it won't be
needed. Could you please let me know?
@@ -947,6 +989,8 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_CIDC, 0x0103, HID_QUIRK_IGNORE },
+ { USB_VENDOR_ID_DELL, USB_DEVICE_ID_DELL_W7658, HID_QUIRK_RESET_LEDS },
+
As this quirk is only needed once in the initialization method, we could
probably get rid of it and just put and explicit test for PID and VID
there (with apropriate comment). We can't afford wasting quirk entries, as
we are slowly running out of them.
Depends on whether this is going to be needed for 1 PID.
I wasn't sure where to place the function, so I just put it above its
user, to signify that it's special-casing. Also, it's unclear where to
put the quirk entry and defines. There's a comment saying that they are
sorted alphabetically by quirk, but apparently the order was violated
with more recent additions.
Yep, the blacklist is ugly. I have a patch moving it to the proper place
and rearranging it to be sorted again, queued for 2.6.22.
Thanks,
--
Jiri Kosina
-
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.phpp=sourceforgeCID=DEVDEV
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC] HID bus design overview.
On Tue, 3 Apr 2007, Li Yu wrote: What's the position of hidraw? It only is used when all other driver is not usable on some report? or, it should be stick every working device. Current implementation (as you can see it in -mm or in my hid.git tree) is creating hidraw interface for just every HID device/interface. But this will get changed before merge. Passing just everything to hidraw is not a good option, as this could lead to confusion and duplicating of input events (i.e. in-kernel hid driver processes the report and generates input_event(), and also userland driver obtains data from hidraw and generates input event through uinput ... not good). PS: In last broken flip-flopping resolution, the USBHID work also need some changes ;) BTW as soon as you have some presentable code, could you please send it so that we could see what aproach you have taken? Debating over code is usualy more efficient than just ranting random ideas :) Thanks, -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] [RFC] HID bus design overview.
On Tue, 3 Apr 2007, Li Yu wrote: May be, we need some means to change blacklist in runtime. Paul Walmsley (added to CC) sent me patches some time ago that among other things implemented possibility to modify the hid_blacklist[] in runtime. The patches had some issues which Paul said will fix - Paul, what is the current status please? Thanks, -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb hid: reset NumLock
On Tue, 3 Apr 2007, Robert Marquardt wrote: As this quirk is only needed once in the initialization method, we could probably get rid of it and just put and explicit test for PID and VID there (with apropriate comment). We can't afford wasting quirk entries, as we are slowly running out of them. Is it a problem of table size or number of table entries? For the number of entries a simple change to PID ranges should help. It would also allow to move Wacom to the blacklist. I have sent a patch for that already, but it was rejected by Greg. The issue is that 32 bits of the quirk bitmask are going to be taken by the quirk entries (so no, it's not related to the size of the table). Thanks, -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] usb monitor
On Tue, 3 Apr 2007, nesta wrote: i want to catch the usb traffic rate over the usb bus. is there any gui for linux that enables me from monitoring the traffic rate over the usb? Read Documentation/usb/usbmon.txt I am not confident about your gui requirement though :) -- Jiri Kosina - 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.phpp=sourceforgeCID=DEVDEV ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
