On Thu, 6 Aug 2009, Lamarque Vieira Souza wrote: > One think I have discovered is that when using hid session the > mouse send several 9-bytes frames with this content: 0x05 0xff 0x6e > 0x6f 0x54 0xc6 0x10 0x00 0x02 (or 0x03 instead of 0x02). If I filter > those frames in hidp_recv_intr_frame (linux/net/bluetooth/hidp/core.c) > before calling hid_input_report, the cursor does not get stucked but the > overhead of doing that is too high, the cursor gets sluggish. Using > input session instead of hid session gets muth better results and is not > as uggly as filtering frames. Can someone help me to find a better > solution? Hi, we'd need to know a little bit more to be able to interpret that data packet. Could you please - compile the kernel with CONFIG_HID_DEBUG option set - modprobe the 'hid' module with 'debug=2' option and provide the dmesg output that appears when the device is connected (so that we have contents of the HID report descriptor and kernel interpretation of it) and also after the data packet containing the mentioned sequence has been received? Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
