| Message ID | 200908132230.30833.lamarque@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, 13 Aug 2009, Lamarque Vieira Souza wrote: > Actually there is an error in the patch I sent in my last e-mail, this one > works (just one line change patch :-)). It was more simpler fix than I have > thought. The debugging output was better, still it didn't contain enough information for me to find out what exactly is happening (probably too small buffer still?). From your patch I guess that there is a separate HID device in the system which only produces the confusing usages and nothing else, and is completely separate from the "normal" system mouse, right? I'd need this described in the patch changelog.
Em Sexta-feira 14 Agosto 2009, Jiri Kosina escreveu: > The debugging output was better, still it didn't contain enough > information for me to find out what exactly is happening (probably too > small buffer still?). I do not think so, the last debugging output also covers some seconds before I switch the bluetooth mouse on. This mouse is problematic, in Windows XP installed on my notebook it is sluggish, in Windows 7 installed in my brother's notebook it is over accelerated (?!). Only when using input session in Linux it works as expected, or almost as expected, sometimes the cursor moves to the upper-left corner, but that is not often and I can live with that. > From your patch I guess that there is a separate HID device in the system > which only produces the confusing usages and nothing else, and is > completely separate from the "normal" system mouse, right? I'd need this > described in the patch changelog. Well, I think my USB hub has confused you. I have this USB hub, which has three USB 1.1 ports and two PS/2 ports, each PS/2 port is mapped to a HID device in Linux. I also have a PS/2 keyboard attached to one of those PS/2 ports and it is it that is sending the keyboards events in the dmesg output. Even disconnecting the USB does not help, actually I bought this USB this year and I have this problem in Linux for more than two years (since hid session was made default instead of input session in kernel 2.6.22). I have this notebook for almost four years and since the begining input session has always worked as expected, better than in Windows too. To make things clearer to see I restarted my notebook, disconnected the USB hub, see the attached dmesg output. Lines 2660.752077 until 2666.779123 shows the bluetooth controller being activated. Even though there is a timeout here it works after 10 to 15 seconds after pressing bluetooth switch on button. After controller was turned on I switched on the mouse, line 2711.077714 is the first one that shows something about the mouse.
Hi all, Any news about my last patch? It is just one line only, could you add it to the mainline kernel?
On Tue, 15 Sep 2009, Lamarque Vieira Souza wrote: > Any news about my last patch? It is just one line only, could you > add it to the mainline kernel? Hi, could you please resend your patch? It has either been lost somewhere on the way, or in the dark depths of my inbox, so I am not really sure which one you are referring to, sorry. Thanks,
diff -Nru --show-c-function a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c --- a/drivers/hid/hid-core.c 2009-08-13 20:45:11.000000000 -0300 +++ b/drivers/hid/hid-core.c 2009-08-13 22:25:54.504677594 -0300 @@ -1636,6 +1636,7 @@ static const struct hid_device_id hid_ig { HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_1_PHIDGETSERVO_20) }, { HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_8_8_4_IF_KIT) }, { HID_USB_DEVICE(USB_VENDOR_ID_YEALINK, USB_DEVICE_ID_YEALINK_P1K_P4K_B2K) }, + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_KYE, 0x0058) }, { } };