Originally Posted by gokhanmoral
I have reuploaded rc6 with a possible fix for HID (usb mouse or keyboard) crash on disconnect (the patch is ported from kevinh's patches for galaxy tab).
I hope it fixes that nasty bug.
please test and report if you use usb HID device.
my eyes are already closing (12:30am)
EDIT: I forgot to tell you that newly uploaded rc6 is based on 3.0.28...
It appears to work for me
. Hotplugging on both ends is also possible now and so plug-in- and pull-out-order does not matter anymore
Some flaws remain for me, please only work on them if you have nothing more interesting floating around
After around 4-6 seconds of constant mouse-moving, the cursor seems to hang (it stays in clicked state if it was clicked) and the messages in kmsg also stop for a while. They appear for every movement of the mouse, so there is a load of
<6>[ 517.364386] OTG compare_ed(394): update ed 32 (0x20)
lines as long as the mouse works. Sometimes, mouse is detected but cursor does only appear after moving it around for some seconds, it feels like the same effect (because the messages only start to appear as soon as the mouse starts working
Some seconds after such a hang it also starts working again (happens with the two mice I tested for me), works for 4-6 seconds, and hangs again.
Maybe there is some usb-autosuspend or something like jumping in? But LEDs on the mice stay on during that time. It might be that I did not test long enough on the earlier rc6 so I did not notice the problem there, maybe someone can confirm whether he is also experiencing this.
I have also one small, cheaper mouse (non-optical, it has WHEELS below :P ) which worked in GB but is now not detected as a mouse it seems (this might also explain why some others also had problems with non-working mice).
A kmsg taken after attaching it is here on pastebin:
For comparison, I put up a kmsg from a working mouse here:
If I am not mistaken, the lines:
<6>[ 1325.164790] max8997-muic max8997-muic: max8997_muic_detect_dev: STATUS1:0x0, 2:0x41
<6>[ 1325.164880] max8997-muic max8997-muic: max8997_muic_detect_dev: ATTACHED
<6>[ 1325.164958] max8997-muic max8997-muic: max8997_muic_handle_attach: OTG charging pump
are the main difference, and they are missing for the mouse which does not work. Maybe it does not request power correctly.
On a real linux machine, it looks like that:
First device attached is the mouse which does not work on Android, the one after that works fine. As you can see, it might also be related to the "broken" usb device strings for the cheaper mouse (why do they sell stuff like that? And why did I buy it?). For me, it is not really important whether this mouse works or not, but I guess some of the non-working reports by others might have been caused by other "broken" mice like that one here.
And finally, after a lot of (re)plugging around just now, I managed to get another freeze, the end of kmsg is here:
<6>[ 449.288032] OTG otg_handle_interrupt(141): Port Interrupt
<6>[ 449.288154] OTG process_port_intr(42): detect connection
<6>[ 449.620118] OTG root_hub_feature(548): case SetPortFeature -USB_PORT_FEAT_RESET
<6>[ 449.679960] OTG otg_handle_interrupt(141): Port Interrupt
<6>[ 449.680008] OTG process_port_intr(54): port enable/disable changed
<6>[ 449.760337] usb 2-1: new low speed USB device number 4 using s3c_otghcd
<6>[ 449.762276] OTG compare_ed(394): update ed 8 (0x8)
<6>[ 449.781330] usb 2-1: New USB device found, idVendor=1241, idProduct=1122
<6>[ 449.781478] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
<6>[ 449.797149] OTG compare_ed(394): update ed 8 (0x8)
<6>[ 449.816677] OTG compare_ed(394): update ed 8 (0x8)
<6>[ 449.829288] input: HID 1241:1122 as /devices/platform/s3c_otghcd/usb2/2-1/2-1:1.0/input/input11
<6>[ 449.866431] generic-usb 0003:1241:1122.0003: input: USB HID v1.00 Mouse [HID 1241:1122] on usb-s3cotg-1/input0
<6>[ 449.866639] usb: otg_list_pop error
Maybe some index-out-of-bounds-stuff from that otg_list? Maybe I just plugged stuff too fast and it was still in the 30-seconds-device-descriptor-reading-timeout or something.
last_kmsg appears to only contain some messages from the Samsung-bootloader before it loads the kernel, so some final lines might be missing here.
Oh, and please prioritize your sleep higher than USB OTG
. And only work on the kmsgs here if you have nothing more interesting / important to do, you are always astonishing me with your ideas about new features and your speed of implementing them