Mouse not reconnecting after Timeout
Hi,
My Logitech MX LASER does not reconnect after the idle timeout. If i either pull the dongle and replug it or switch off the mouse and switch it back on or do a
dbus-send --system --type=method_call \
--dest=org.bluez /org/bluez/hci0 \
org.bluez.Adapter.DisconnectRemoteDevice \
string:"00:07:61:3F:1B:6D"then it reconnects fine.
This happens with all dongles (The internal one in my hp2510p, one of the CSR based HAMA mini-dongles, ...)
I'm running 2.6.25.3 and bluez-{libs,utils}-3.31 with btusb (but it also happened with hci_usb).
My DELL BT Keyboard and other mice are working fine and reconnecting after timeout. I have reports of similar symptoms from apple bt-keyboard users.
root@stoetzler:/sys# hcitool info 00:07:61:3F:1B:6D
Requesting information ...
BD Address: 00:07:61:3F:1B:6D
Device Name: Logitech MX1000 mouse
LMP Version: 1.2 (0x2) LMP Subversion: 0x545
Manufacturer: Cambridge Silicon Radio (10)
Features: 0xfc 0xff 0x0f 0x00 0x08 0x08 0x00 0x00
<encryption> <slot offset> <timing accuracy> <role switch>
<hold mode> <sniff mode> <park state> <RSSI> <channel quality>
<SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log>
<CVSD> <paging scheme> <power control> <transparent SCO>
<AFH cap. slave> <AFH cap. master>root@stoetzler:/sys# hciconfig -a
hci0: Type: USB
BD Address: 00:1E:37:A7:C6:D8 ACL MTU: 1017:8 SCO MTU: 64:1
UP RUNNING PSCAN ISCAN
RX bytes:0 acl:55432 sco:0 events:1410 errors:0
TX bytes:1554 acl:43 sco:0 commands:51 errors:0
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: '2510p builtin'
Class: 0x100100
Service Classes: Object Transfer
Device Class: Computer, Uncategorized
HCI Ver: 2.0 (0x3) HCI Rev: 0x2129 LMP Ver: 2.0 (0x3) LMP Subver: 0x41cf
Manufacturer: Broadcom Corporation (15)I will attach a gzipped hcidump logfile obtained like that:
Wait until the timeout surely expired, then
- hcidump -X -V > /tmp/hcidump.out
- now move the mouse, nothing happens with my mouse cursor
- stop hcidump
- hcidump -X -V >> /tmp/hcidump.out
- move the mouse again
- disconnect the mouse with the above dbus-send command
- move it again, now it reconnects
I hope this helps to finally fix this old annoying bug ;-)
Thanks,
Stefan
Signature · 6 lines
Stefan Seyfried R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." This footer brought to you by insane German lawmakers: SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann
maintainerHi Stefan,
Quoted 9 lines
My Logitech MX LASER does not reconnect after the idle timeout. If i either pull the dongle and replug it or switch off the mouse and switch it back on or do a
dbus-send --system --type=method_call \ --dest=org.bluez /org/bluez/hci0 \ org.bluez.Adapter.DisconnectRemoteDevice \ string:"00:07:61:3F:1B:6D"
Quoted 8 lines
then it reconnects fine.
This happens with all dongles (The internal one in my hp2510p, one of the CSR based HAMA mini-dongles, ...)I'm running 2.6.25.3 and bluez-{libs,utils}-3.31 with btusb (but it also happened with
hci_usb).
My DELL BT Keyboard and other mice are working fine and reconnecting after timeout. I have reports of similar symptoms from apple bt-keyboard users.
so the first assumption is that we are causing this disconnect with the idle timeout setting. I committed a patch to the CVS that disables the timeout and provides a input.conf setting that would allow to change it without re-compiling. So we can actually set this to 1 minute for testing and see what happens.
If this actually fixes it, then it is only an interim fix since the real problem is that we are disconnecting the remote device wrongly. Current guess is that we still keep a reference count somewhere. Either inside the kernel or in user-space.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel