Ubuntu

Bluetooth Logitech Dinovo Keyboard/Mouse don't work

Reported by WillSmith on 2007-07-04
260
This bug affects 29 people
Affects Status Importance Assigned to Milestone
bluez (Ubuntu)
Medium
Unassigned
Declined for Intrepid by Martin Pitt
Declined for Jaunty by Martin Pitt
linux (Ubuntu)
Undecided
Unassigned
Declined for Intrepid by Martin Pitt
Declined for Jaunty by Martin Pitt
linux-source-2.6.22 (Ubuntu)
Medium
Unassigned
Declined for Intrepid by Martin Pitt
Declined for Jaunty by Martin Pitt
udev (Ubuntu)
Undecided
Unassigned
Declined for Intrepid by Martin Pitt
Declined for Jaunty by Martin Pitt

Bug Description

Testing Gutsy Gibbon Tribe 2 LiveCD and bluetooth keyboard and mouse will work until Nautilus starts. After Nautilus starts the keyboard and mouse are unresponsive and do not work.
I tried reconnecting the keyboard and mouse by using the discovery buttons on both the Bluetooth Dongle and Input device. The problem still persists.
Using Intel P4 2.8 Ghz Processor, 3 GB ddr400 ram, Intel D875PBZ motherboard. Logitech Dinovo media keyboard and mx1000 laser bluetooth mouse, with logitech mini bluetooth receiver.

Brian Murray (brian-murray) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. There is now a newer Tribe CD available and we were wondering if the problem exists with it. Thanks in advance.

Can you include the output of the command lsusb on a terminal.

Try the following:
1. Direct after gnome login open a terminal and enter the following command:
 $ cp /var/log/Xorg.0.log ~/Xorg.0.log
 $ cp /var/log/dmesg ~/dmesg_boot
2. Wait until your mouse and keyboard stop working.
3. Open a terminal by pressing Ctrl-Alt-F1.
4. Enter the following commands:
 $ LANG=C
 $ cp /var/log/Xorg.0.log ~/Xorg.0.log_tmp
 $ diff -ns ~/Xorg.0.log ~/Xorg.0.log_tmp > ~/Xorg.0.log_diff-ns
 $ dmesg > ~/dmesg
 $ diff -ns ~/dmesg_boot ~/dmesg > ~/dmesg_diff-ns
5. Attach Xorg.0.log, Xorg.0.log_diff-ns, dmesg_boot and dmesg_diff-ns to this bug report.

WillSmith (undertakingyou) wrote :

I am currently in using the tribe 3 CD. No bluetooth mouse or keyboard. On the media pad when I try to connect it says that there is no network. Let me emphasize. The keyboard works when the CD begins; i.e. at the startup menu. After gnome starts and everything is loaded the keyboard and mouse do not respond. I have attached the requested files. I attached a PS/2 keyboard and mouse to be able to get them.

WillSmith (undertakingyou) wrote :
WillSmith (undertakingyou) wrote :
WillSmith (undertakingyou) wrote :
WillSmith (undertakingyou) wrote :

The output of `lsusb`

ubuntu@ubuntu:~$ lsusb
Bus 005 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 005: ID 046d:c709 Logitech, Inc.
Bus 003 Device 003: ID 046d:c70b Logitech, Inc.
Bus 003 Device 004: ID 046d:c70c Logitech, Inc.
Bus 003 Device 002: ID 046d:0b02 Logitech, Inc.
Bus 003 Device 001: ID 0000:0000

Looking at your dmseg_diff-ns this looks like a kernel bug, can you provide the minimal information as described here: https://wiki.ubuntu.com/KernelTeamBugPolicies.
Can you also attach the output of the following command:
$ sudo lsusb -v > ~/lsusb-v

WillSmith (undertakingyou) wrote :

Here is the attachment of lsusb -v. I tried this in tribe 4, thinking that there is a possible change. There is no change. Still no bluetooth mouse or keyboard. Still won't connect.

Still missing the the minimal information as described here: https://wiki.ubuntu.com/KernelTeamBugPolicies.

WillSmith (undertakingyou) wrote :

Pascal, thank you you are quite right. The next few attachments are dmesg.log, llspci-vvnn.log unname-a.log and version.log. Happy to supply what I can for this bug.

WillSmith (undertakingyou) wrote :
WillSmith (undertakingyou) wrote :
WillSmith (undertakingyou) wrote :

Seems to be the same issue as described here: http://lkml.org/lkml/2007/2/16/215.

Assigning to the kernel team as described in https://wiki.ubuntu.com/KernelTeamBugPolicies.

Changed in linux-source-2.6.22:
assignee: pascal-devuyst → ubuntu-kernel-team
importance: Undecided → Medium
status: Incomplete → Triaged
Alex Mayorga (alex-mayorga) wrote :

I have the same Logitech set and to make it work I had to unplug and then plug again the Bluetooth receiver and I got back the keyboard and mouse, pretty much the case outlined on the link posted by Pascal.

If there's anything else needed I'd be glad to help.

It would be also good to know the bug upstream if it ever was raised.

Alex Mayorga (alex-mayorga) wrote :

The problem still prevails on Tribe 5.

description: updated
WillSmith (undertakingyou) wrote :

This persists in the latest updates of tribe 5 and, as a side note running "hcitool dev" says that there are no devices even when I get it working.

Alex Mayorga (alex-mayorga) wrote :

As of this update I see similar behavior (no devices listed in hcitool dev), but my dmesg (attached) show less breakage I believe.

user@host:~$ uname -a
Linux host 2.6.22-11-generic #1 SMP Fri Sep 7 05:07:05 GMT 2007 i686 GNU/Linux
user@host:~$ hcitool dev
Devices:

The keyboard and mouse seem to work in "embedded mode" as Logitech calls it, but I'm not able to discover my PC from my Bluetooth phone.

Again, anything anyone might need to get this one resolved, just ask.

Alex Mayorga (alex-mayorga) wrote :

Do you believe this is a duplicate of bug# 32415 ?

Kyle James (kvitale) wrote :

This is similar to bug #96036. It's been around for a while it seems.

This problem occurs in the gutsy beta also. I am not using the live CD.

As soon as Ubuntu loads to the login screen the dinovo edge keyboard and mouse stop responding. For me re-seating the dongle had no effect. I was able to get it working so i could login by powering off and back on the keyboard using the switch on the right hand side of the keyboard.

Once I logged on the keyboard and mouse worked fine. Only if I rebooted did the problem reoccur. My lsusb was normal once I was logged on.

However, when I pulled the dongle out, and ran lsusb using another keyboard, lsusb would not display anything... it would just sit at a blinking cursor. When I plugged the dongle back in, it was the same problem as original, in that I had to then power off the keyboard and power it back on, and it would still not display lsusb output. I would have to reboot to get it to display again.

The permanent fix for me was to uninstall "bluez-utils" using Synaptic Packet Manager. Although to be truthful, I don't know much about the live cd, but if you load ubuntu to your hard drive, then remove the "bluez-utils" package, your keyboard should work normally. At least it worked for me.

WillSmith (undertakingyou) wrote :

Just removed bluez-utils, which removes the rest of the bluetooth stuff. It does resolve this annoying behavior. Would be cool if I could use all of my hardware, like bluetooth though.

Alex Mayorga (alex-mayorga) wrote :

Will,

This is what worked for me and I still keep Bluetooth capabilities of the dongle http://ubuntuforums.org/showthread.php?p=2334318#post2334318

This is still a hack, hope it'll point the developers on the right direction.

Alex Mayorga (alex-mayorga) wrote :

Is Bug #148290 a duplicate of this?

Here is a fix (worked for me) for this issue which has at least been around since Feisty.
http://ubuntuforums.org/showthread.php?p=2334318#post2334318
I can also verify that OpenSuse 10.3 doesn't give any problems with DiNovo BT, it all works by default.

Alex Mayorga (alex-mayorga) wrote :

Fraser,

Is great that my post could help. Can you elaborate on the differences between OpenSuse and Ubuntu? Maybe we can "back port" whatever works there.

Fabián Rodríguez (magicfab) wrote :

@Alex: Bug #32415 is not a duplicate of this (or vice-versa)

I have marked quite a few duplicates for this bug. It's worth mentioning no one indicates having contacted the manufacturer and letting them know or ask them about using this keyboard under Ubuntu. It would be important that anyone having this hardware lets Logitech know they are using it (or trying to use it) with Ubuntu / Linux. It's not easy to provide support and test hardware when developers don't have it and no certification has been done for it. In some occasions the manufacturer do have documented workarounds and even drivers and I've seen this happen in quite a few bug reports where everyone's time could have been saved by asking the manufacturer initially, if only to rule their collaboration out from the beginning.

When and if any developers look at this bug it may be worth taking a look at the different duplicates I have marked as many more people have contributed information about this. If anyone is using Ubuntu Hardy beta with current updates, it would be useful to know what is the result of following this documentation (which I just reviewed and updated):
https://help.ubuntu.com/community/BluetoothInputDevices

Thank you.

Leon van der Ree (lvanderree) wrote :

I can add to this, that I did contact Logitech with my previous dinovo keyboard (the non-bluetooth, non-edge version). This had a mediapad with lcd-display, but they refused to give any support for Linux.

I don't know if that is changed in the meantime, but at that time I know I did not was the only one who asked them for support and they where very stubborn about it.

About the problem. I think it is due to the pairing.

I connected an old wired PS2 keyboard and used it to login at gdm.
When I was logged in, the bluetooth dongle was still working.
I could then pair my dinovo keyboard in the bluetooth settings and the keyboard worked flawlessly.
However after I rebooted, and I try to use the keyboard again at gdm it again has the time-out which brakes bluetooth after the first key-press. I think probably because the pairing is done under my account and in gdm I am not logged in yet, so the keyboard cannot pair either, since it would probably use global-account settings for that...
When I would reboot, login at gdm with my wired keyboard, and after login would use my dinovo, this does work.

if I had used my dinovo to login at gdm it would not respond after the first key-touch for a while (I think until the bluetooth drivers times-out) because pairing fails.
At the bios or during grub the keyboard does work immediately, probably since at that time there aren't any bluetooth drivers loaded yet.

Changed in bluez-utils:
importance: Undecided → Medium
status: New → Confirmed
DaveAbrahams (boostpro) wrote :

Fabián,

https://help.ubuntu.com/community/BluetoothInputDevices works for me with the latest Hardy beta + updates and a Logitech MX1000! Thank you!

I have to add that I have used this applet a thousand times but I had absolutely no idea that clicking on the "input service" row would bring up an empty device list, to which I could add my mouse with the "add" button. I think the fact that so many people are having problems with this indicates a serious usability bug in bluetooth-applet. GUIs are supposed to be "discoverable," and this one is not.

Jeroen T. Vermeulen (jtv) wrote :

Still doesn't work for me: bluetooth-properties still crashes with that D-Bus "out of memory" error after a fairly long wait (during which I see no noticeable rise in memory usage):

process 11360: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1074.
This is normally a bug in some application using the D-Bus library.

** ERROR **: Out of memory
aborting...
Aborted (core dumped)

This is with a Hardy patched up to 2008-04-08 on a dual-core amd64, connecting an Apple wireless keyboard to an Acer Aspire 5050's internal Bluetooth adapter. The only change I see with the latest updates is that I can no longer seem to conjure up the passphrase prompt.

Leon van der Ree (lvanderree) wrote :
Download full text (8.7 KiB)

Bluetooth now works, from gdm on (in latest hardy)

However I now have the same bug as mentioned somewhere else in launchpad (will try to find that bug and post there as well) When I don't use my bluetooth mouse/keyboard for a while (5/10minutes or something?) the bluetooth connection gets disconnected I think, and the keyboard doesn't work anymore.

I think this line in my syslog is related to the braking of the connection:
Apr 19 11:31:33 leon-desktop NetworkManager: <debug> [1208597493.546317] nm_hal_device_removed(): Device removed (hal udi is '/org/freedesktop/Hal/devices/bluetooth_acl_761755afb_0_logicaldev_input').

I can use my normal mouse and right click the still visible bluetooth icon and click on the disconnect-button in the connection-overview, and than the bluetooth icon will dissapear as well, but my bluetooth keyboard/mouse start responding again (probably because the bluetooth-functionality of the receiver gets unloaded/disabled by some bug).

I think these lines are related to the stop of the bluetooth driver, and the re-attachement of my keyboard in 'normal-modus' (after pressing the disconnect button):
Apr 19 12:01:24 leon-desktop input[9433]: /org/bluez/input: org.bluez.input.Manager.ListDevices()
Apr 19 12:01:24 leon-desktop audio[9434]: /org/bluez/audio: org.bluez.audio.Manager.ListDevices()
Apr 19 12:01:24 leon-desktop input[9433]: /org/bluez/input/keyboard0: org.bluez.input.Device.GetAdapter()
Apr 19 12:01:24 leon-desktop input[9433]: /org/bluez/input/keyboard0: org.bluez.input.Device.GetAddress()
Apr 19 12:01:24 leon-desktop input[9433]: /org/bluez/input/keyboard0: org.bluez.input.Device.GetName()
Apr 19 12:01:31 leon-desktop NetworkManager: <debug> [1208599291.549884] nm_hal_device_removed(): Device removed (hal udi is '/org/freedesktop/Hal/devices/bluetooth_acl_761755afb_0').
Apr 19 12:01:36 leon-desktop kernel: [ 6832.718073] usb 2-2: USB disconnect, address 3
Apr 19 12:01:36 leon-desktop kernel: [ 6832.718080] usb 2-2.1: USB disconnect, address 6
Apr 19 12:01:36 leon-desktop hcid[9412]: HCI dev 0 down
Apr 19 12:01:36 leon-desktop hcid[9412]: Stopping security manager 0
Apr 19 12:01:36 leon-desktop hcid[9412]: Device hci0 has been disabled
Apr 19 12:01:36 leon-desktop NetworkManager: <debug> [1208599296.987656] nm_hal_device_removed(): Device removed (hal udi is '/org/freedesktop/Hal/devices/usb_device_46d_c709_0007617BCBF1_if0_bluetooth_hci_7617bcbf1_1').
Apr 19 12:01:37 leon-desktop hcid[9412]: HCI dev 0 unregistered
Apr 19 12:01:37 leon-desktop hcid[9412]: Unregister path: /org/bluez/hci0
Apr 19 12:01:37 leon-desktop hcid[9412]: Device hci0 has been removed
Apr 19 12:01:37 leon-desktop kernel: [ 6832.973623] usb 2-2.2: USB disconnect, address 4
Apr 19 12:01:37 leon-desktop NetworkManager: <debug> [1208599297.237027] nm_hal_device_removed(): Device removed (hal udi is '/org/freedesktop/Hal/devices/usb_device_46d_c709_0007617BCBF1_if0_bluetooth_hci_7617bcbf1').
Apr 19 12:01:37 leon-desktop NetworkManager: <debug> [1208599297.238849] nm_hal_device_removed(): Device removed (hal udi is '/org/freedesktop/Hal/devices/usb_device_46d_c709_0007617BCBF1_if0_bluetooth_hci_7617bcbf1_0').
Apr 19 12:01:37 leon-desktop...

Read more...

per http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355497

Type this command in a terminal:
sudo gedit /etc/default/bluetooth

Then look for the line that says:
HID2HCI_ENABLED=1

and change it to this:
HID2HCI_ENABLED=0

I think Ubuntu Hardy is treating the Logitech DiNovo bluetooth keyboard/mouse adapter as an all-purpose bluetooth device. The above fix worked for me even with bluez installed.

How do you get a bug unduplicated? Bug #140668 is not at all the same issue, and the bug I want to be subscribed to. Thanks!

ikesterhaney (ikesterhaney) wrote :

Here a verbose log from lsusb.
I did not have to pair anything on the linux side.
The Mouse is supposed to be pre-paired at the factory.

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this bug to the new "linux" package. However, development has already began for the upcoming Intrepid Ibex 8.10 release. It would be helpful if you could test the upcoming release and verify if this is still an issue - http://www.ubuntu.com/testing . If the issue still exists, please update this report by changing the Status of the "linux" task from "Incomplete" to "New". We appreciate your patience and understanding as we make this transition. Thanks!

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

I don't think this problem has to do with the kernel version. It's more of a
integration problem in the development of startup-script for bluez bluetooth
services. When the package bluez-utils is removed, the problem goes away.

Before bluez start, everything works fine. After bluez is started I have to
reconect my keyboard-dongle for the deskset to work.

Regards
Fredrik

2008/8/29 Leann Ogasawara <email address hidden>

> The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the
> upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would
> appreciate it if you could please test this newer 2.6.27 Ubuntu kernel.
> There are one of two ways you should be able to test:
>
> 1) If you are comfortable installing packages on your own, the linux-
> image-2.6.27-* package is currently available for you to install and
> test.
>
> --or--
>
> 2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer
> 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4.
> Please watch http://www.ubuntu.com/testing for Alpha5 to be announced.
> You should then be able to test via a LiveCD.
>
> Please let us know immediately if this newer 2.6.27 kernel resolves the
> bug reported here or if the issue remains. More importantly, please
> open a new bug report for each new bug/regression introduced by the
> 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please
> specifically note if the issue does or does not appear in the 2.6.26
> kernel. Thanks again, we really appreicate your help and feedback.
>
> ** Tags added: cft-2.6.27
>
> --
> Bluetooth Logitech Dinovo Keyboard/Mouse don't work
> https://bugs.launchpad.net/bugs/123920
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

bubbalouie (ryan-gossink) wrote :
Download full text (3.3 KiB)

Fredrik,

It sounds as though bluez-utils is telling your dongle to operate as a
bluetooth dongle instead of a USB HID dongle, I might be wrong, but it
may also save some time in the long run for you, please look in:

  /etc/default/bluetooth

For the following line:

  HID2HCI_ENABLED=1

And change it to:

  HID2HCI_ENABLED=0

I have one system which uses a dinvo set as USB HID devices this way
and it experiences no problems. However, there is also another machine
which uses an internal bluetooth adapter to connect to a different
dinovo set, this machine has some serious reconnection issues which
can not be easily addressed (the bluetooth services must be restarted
in order for the devices to repair if the machine is left to sit
'still' for a while, even though at boot time and after hours of use
everything is fine, just leavinng the machine can cause bluetooth to
fail). I think it is perfectly possible that these problems could be
caused by a driver or kernel issue in my particular case, I suspect it
has something to do with the way the dinovo gear comes out of its own
power saving mode not being very well handled by the linux bluetooth
system.

In any case, I hope this helps a little :).

Cheers

Ryan

On Sun, Aug 31, 2008 at 10:44 AM, Foffa <email address hidden> wrote:
> I don't think this problem has to do with the kernel version. It's more of a
> integration problem in the development of startup-script for bluez bluetooth
> services. When the package bluez-utils is removed, the problem goes away.
>
> Before bluez start, everything works fine. After bluez is started I have to
> reconect my keyboard-dongle for the deskset to work.
>
> Regards
> Fredrik
>
>
> 2008/8/29 Leann Ogasawara <email address hidden>
>
>> The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the
>> upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would
>> appreciate it if you could please test this newer 2.6.27 Ubuntu kernel.
>> There are one of two ways you should be able to test:
>>
>> 1) If you are comfortable installing packages on your own, the linux-
>> image-2.6.27-* package is currently available for you to install and
>> test.
>>
>> --or--
>>
>> 2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer
>> 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4.
>> Please watch http://www.ubuntu.com/testing for Alpha5 to be announced.
>> You should then be able to test via a LiveCD.
>>
>> Please let us know immediately if this newer 2.6.27 kernel resolves the
>> bug reported here or if the issue remains. More importantly, please
>> open a new bug report for each new bug/regression introduced by the
>> 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please
>> specifically note if the issue does or does not appear in the 2.6.26
>> kernel. Thanks again, we really appreicate your help and feedback.
>>
>> ** Tags added: cft-2.6.27
>>
>> --
>> Bluetooth Logitech Dinovo Keyboard/Mouse don't work
>> https://bugs.launchpad.net/bugs/123920
>> You received this bug notification because you are a direct subscriber
>> of a duplicate bug.
>>
>
> --
> Bluetooth Logitech Dinovo Keyboard/Mouse don't ...

Read more...

wonko (oekj) wrote :

Had the same problem in kubuntu 8.10 beta, with my logitech dinovo edge keyboard and bluetooth dongle: After system restart, I need to unplug, replug and reconnect ("pair") the dongle. Following Ryan's advice, I disabled HID2HCI in /etc/default/bluetooth, and now it's working again :) So thanks bubbalouie!
Btw: I also had this problem in kubuntu 8.04 (and maybe earlier too). It seems to me to be better leaving this option off by default, and instead offer it as an option in the bluez-utils setup...

Martin G Miller (mgmiller) wrote :

Confirmed with ubuntu 8.10 beta and logitech denovo edge. It worked out of the box in Hardy, did not work at all in Intrepid. The bluetooth utility didn't even see the dongle. I modified /etc/default/bluetooth as noted above and now it works. This default needs to be changed.

Still not a duplicate of #140668 (see above). Please stop sending me irrelevant emails, and please keep separate issues separate so they can be fixed.

sheikki (sheikki2302) wrote :

Logitech Dinovo Media Desktop keyboard does not work with the latest 8.10 beta. What fixed it for me was the removal of everything "bluez" related (and all dependencies) from Synaptic Package Manager.

Martin G Miller (mgmiller) wrote :

The latest updates to bluez in intepid beta replaced the /etc/default/bluetooth file with a greatly shortened one, but it caused the problem to return. Again, editing the file to "HID2HCI_ENABLED=0" returns normal function to the Logitech Dinovo.

bubbalouie (ryan-gossink) wrote :

@Kristoffer

I agree with you, however, people can address the 'quasi bug' here of
not being able to connect. Perhaps once this problem is fixed, the
real issue that you and I are experiencing can be addressed, perhaps
even in 9.04. As much as I hate to say it though, I think it will
probably require that this 'bug' be solved, the original report will
then get closed, and then we can report our problem again, it is
rather inefficient, but, fingers crossed a dinvo keyboard might work
with a real pure bluetooth adapter before 2010 :) (as opposed to using
the logitech supplied dongle in HID mode).

To be honest, I have not tested the Intrepid beta as I need my systems
to be reliable for work, it may be solved there, but as before, you
are right, this is NOT A DUPLICATE OF #140668. We may just need to be
patient, or even delve in and fix the code causing the problem
ourselves (this is partly what OSS is about after all).

Cheers

Ryan

On Tue, Oct 7, 2008 at 5:31 PM, Kristoffer Lundén
<email address hidden> wrote:
> Still not a duplicate of #140668 (see above). Please stop sending me
> irrelevant emails, and please keep separate issues separate so they can
> be fixed.
>
> --
> Bluetooth Logitech Dinovo Keyboard/Mouse don't work
> https://bugs.launchpad.net/bugs/123920
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

buzz (buzzheavyyear) wrote :

Just to add to this that I've just installed 8.10 and the dinovo mouse/keyboard work fine (after pressing the appropriate connect buttons).

My only gripe is that there is a very bad lag on the mouse pointer - it slowly follows the physical mouse, requiring the hand to always compensate.

On the other hand, a thousand thanks for getting the dinovo to work with a straight forward installation.

Cheers
Nick

Leon van der Ree (lvanderree) wrote :

I can partially confirm buzz's experience!

However I do not notice any lag

Ubuntu (8.10) and dinovo edge are friends finally!

Thanks for the improvements!

buzz (buzzheavyyear) wrote :

I've just spent a little more time trying to work out what the issue is. I had a pretty loaded machine a couple of days ago.

I've booted up. I have two mice attached to the machine, one dinovo the other a usb mouse. The usb mouse works fine and fast. The dinovo mouse exhibits the following:

1. if I move the mouse very, very slowly then the mouse moves in an expected fashion.

2. if I speed up the movement of the mouse it begins to judder. It moves smoothly for a couple of millimeters, pauses then jumps a couple of millimeters, as though the bluetooth streaming is slow and ubuntu is always playing catch-up.

When I'm just using ubuntu normally, this is not an issue. When I'm using netbeans and the mouse movements go though a fair amount of additional processing, then the juddering steps up another level and, as I posted above, I keep on having to compensate for the mouse position. I've actually just noticed it again, here, whilst writing this. If I move the mouse to edit another part of this port, more likely than not, as I'm about to click the right button with the mouse stationary it will jump past the correct position and I will then have to move the mouse back a fraction.

The dinovo dongle is less than half a meter from the mouse.

When I used the dinovo in previous versions of ubuntu I was never aware/conscious of this behaviour.

Using the usb mouse gives no such problems.

Once again, a thousand thanks for getting dinovo to work.

Cheers

buzz (buzzheavyyear) wrote :

Update

It's now 4 hours later than my last post and the juddering seems to have disappeared - not too sure what to put it down to. It's a big machine with dualcore, so it can't be processing power.

Anyhow, if it returns I'll leave another post.

Thanks again

Cheers

Nick

Matt Hanyok (matthew-hanyok) wrote :

Hello all,

A suggestion: What if the HID->HCI switch happened after login and some sort of automatic setup of the mouse occured?

For example: at the login screen the dongle is in HID mode. After login, when the desktop loads, Bluez switches the dongle from HID to HCI mode and, if no devices have been previously setup, automatically prompts the user to press the mouse's "connect" button to pair with the mouse.

From there the keyboard and media pad could be added using the "Setup new device" option (which can be navigated with just the mouse paired). This would be similar to the functionality of their Setpoint software in Windows, where, after installed, it asks you to press the "connect" button on the mouse, detects it and then you can click through a few menus to get the keyboard/media pad set up.

Just a thought.

bubbalouie (ryan-gossink) wrote :

The lag you describe is usually a connection issue in my experience,
try moving the receiver closer to the mouse itself (using a USB
extension cable for example) and make certain that no other 2.4ghz
sources can interfere with the dongle....

On Thu, Nov 6, 2008 at 6:19 PM, buzz <email address hidden> wrote:
> I've just spent a little more time trying to work out what the issue is.
> I had a pretty loaded machine a couple of days ago.
>
> I've booted up. I have two mice attached to the machine, one dinovo the
> other a usb mouse. The usb mouse works fine and fast. The dinovo mouse
> exhibits the following:
>
> 1. if I move the mouse very, very slowly then the mouse moves in an
> expected fashion.
>
> 2. if I speed up the movement of the mouse it begins to judder. It moves
> smoothly for a couple of millimeters, pauses then jumps a couple of
> millimeters, as though the bluetooth streaming is slow and ubuntu is
> always playing catch-up.
>
> When I'm just using ubuntu normally, this is not an issue. When I'm
> using netbeans and the mouse movements go though a fair amount of
> additional processing, then the juddering steps up another level and, as
> I posted above, I keep on having to compensate for the mouse position.
> I've actually just noticed it again, here, whilst writing this. If I
> move the mouse to edit another part of this port, more likely than not,
> as I'm about to click the right button with the mouse stationary it will
> jump past the correct position and I will then have to move the mouse
> back a fraction.
>
> The dinovo dongle is less than half a meter from the mouse.
>
> When I used the dinovo in previous versions of ubuntu I was never
> aware/conscious of this behaviour.
>
> Using the usb mouse gives no such problems.
>
> Once again, a thousand thanks for getting dinovo to work.
>
> Cheers
>
> --
> Bluetooth Logitech Dinovo Keyboard/Mouse don't work
> https://bugs.launchpad.net/bugs/123920
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Download full text (3.6 KiB)

Sorry for the delay in getting back to you on this one. I've been sitting here trying to work out what the problem is.

The bluetooth dongle is 0.5 meters away from the mouse and there is nothing in the way and the rechargeable batteries are new. There are no other 2.4GHz sources nearby - a wifi source is 10m away.

I still have the same issue. The juddering is always there when I start the machine. I use just firefox, thunderbird and netbeans. Sometimes the juddering stops after a couple of hours, somethimes after 6 hours, most of the time it's still there at 7pm when I turn off the machine for the day.

When browsing, this isn't an issue. When editing code and trying to place the cursor at an exact spot in the editor and then the cursor jumps away from the correct spot (just as I'm clicking for insertion) - this is a real pain.

But, if no one else is experiancing this then it must be related to the way I originally set up the machine (nothing fancy, just a regular/vanilla install).

> From: <email address hidden>
> To: <email address hidden>
> Date: Tue, 11 Nov 2008 01:20:57 +0000
> Subject: Re: [Bug 123920] Re: Bluetooth Logitech Dinovo Keyboard/Mouse don't work
>
> The lag you describe is usually a connection issue in my experience,
> try moving the receiver closer to the mouse itself (using a USB
> extension cable for example) and make certain that no other 2.4ghz
> sources can interfere with the dongle....
>
> On Thu, Nov 6, 2008 at 6:19 PM, buzz <email address hidden> wrote:
> > I've just spent a little more time trying to work out what the issue is.
> > I had a pretty loaded machine a couple of days ago.
> >
> > I've booted up. I have two mice attached to the machine, one dinovo the
> > other a usb mouse. The usb mouse works fine and fast. The dinovo mouse
> > exhibits the following:
> >
> > 1. if I move the mouse very, very slowly then the mouse moves in an
> > expected fashion.
> >
> > 2. if I speed up the movement of the mouse it begins to judder. It moves
> > smoothly for a couple of millimeters, pauses then jumps a couple of
> > millimeters, as though the bluetooth streaming is slow and ubuntu is
> > always playing catch-up.
> >
> > When I'm just using ubuntu normally, this is not an issue. When I'm
> > using netbeans and the mouse movements go though a fair amount of
> > additional processing, then the juddering steps up another level and, as
> > I posted above, I keep on having to compensate for the mouse position.
> > I've actually just noticed it again, here, whilst writing this. If I
> > move the mouse to edit another part of this port, more likely than not,
> > as I'm about to click the right button with the mouse stationary it will
> > jump past the correct position and I will then have to move the mouse
> > back a fraction.
> >
> > The dinovo dongle is less than half a meter from the mouse.
> >
> > When I used the dinovo in previous versions of ubuntu I was never
> > aware/conscious of this behaviour.
> >
> > Using the usb mouse gives no such problems.
> >
> > Once again, a thousand thanks for getting dinovo to work.
> >
> > Cheers
> >
> > --
> > Bluetooth Logitech Dinovo Keyboard/Mouse don't work
> > https:...

Read more...

Florian Ehrenthal (dizzinger) wrote :

I am seeing the exact same behavior as 'buzz'. My MX900 bluetooth mouse lags badly.

It used to work fine until i upgraded from 8.04 to 8.10.

I will try to investigate in the next days and get back.

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Alex Mayorga (alex-mayorga) wrote :

I think I'm also being bitten by this bugger on Jaunty:

alex-mayorga@inspiron-1501:~$ lsusb |grep Logitech
Bus 003 Device 006: ID 046d:c70c Logitech, Inc. BT Mini-Receiver (HID proxy mode)
Bus 003 Device 005: ID 046d:c70b Logitech, Inc. BT Mini-Receiver (HID proxy mode)
Bus 003 Device 004: ID 046d:0b02 Logitech, Inc. BT Mini-Receiver (HID proxy mode)
alex-mayorga@inspiron-1501:~$ hcitool dev
Devices:
alex-mayorga@inspiron-1501:~$ hid2hci
Switching device 046d:c70c to HCI mode failed (No such file or directory)
Switching device 046d:c70b to HCI mode failed (No such file or directory)

Per Logitech official information we seem to be on our own here; "The diNovo Media Desktop Laser is not supported on Windows 98, Windows ME, Windows 2000, UNIX, Linux or Macintosh operating systems."
http://logitech-en-amr.custhelp.com/cgi-bin/logitech_en_amr.cfg/php/enduser/std_adp.php?p_faqid=9747

Also has anyone with access to a Windows system tried to update to SetPoint 4.7 or SetPoint 4.72? In the past I've seen that some updates include firmware updates for the Bluetooth dongle.

Anything I can provide please don't hesitate to ask.

Martin G Miller (mgmiller) wrote :

Alex, have you tried editing /etc/default/bluetooth as noted above? This worked perfectly for me in Intrepid. It did require a reboot.

Stefan Handschuh (handschuh) wrote :

@buzz, Florian
I also register partially huge lags both on keyboard AND mouse since upgrading to 8.10.

Christian Reis (kiko) wrote :

People running Lucid that are concerned about the dongle not running in embedded mode should know it is possible to still have it work in that mode just commenting out the hid2hci line in /lib/udev/70-hid2hci.rules; I've blogged about it here: http://async.com.br/~kiko/diary.html?date=06.08.2010

Andy Whitcroft (apw) wrote :

Looking at Christians write up in comment #58, it seems very much that the device is behaving correctly at the kernel level (lucid and up at least). The device has two modes after conversion from hci mode usability compromised due to the need to pair the device. In both modes however it appears to be working as expected at the kernel level. I am therefore closing out the development kernel task. As it may be appropriate to suppress this mode conversion for this specific device I am opening a udev task to investigate how that might be done.

Changed in linux (Ubuntu):
status: Incomplete → Invalid
Andy Whitcroft (apw) wrote :

It also seems likely that bluez is acting correctly, but I will leave it to the maintainers there to confirm and close.

Changed in udev (Ubuntu):
status: New → Confirmed
Gema Gomez (gema) wrote :

This problem is still happening. The fix is a regression, have a look at this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589388#10

Gema Gomez (gema) wrote :

This problem is still happening. The fix is a regression, have a look at this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589388#10

Gema Gomez (gema) wrote :

Please, find patch attached. Can someone fix this? It is holding my testing since I use this keyboard.

The attachment "hid2hci.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Martin G Miller (mgmiller) wrote :

Total regression with this issue in 11.10 32 bit

I had this dinovo edge bluetooth keyboard/trackpad working perfectly in 11.04. Since the upgrade to 11.10 "Oneiric" I am back to not being able to use it. It refuses to pair and the old entry (changing hiddraw to hidraw) in lib/udev/rules.d/70-hid2hic.rules is gone. If I put it in it still does not work. The bluetooth pairing apple just goes around in circles, asking to enter a code number that appears on screen, followed by a failed to pair. If you just try to use the keyboard without running the bluetooth applet, it pops up a dialog asking to grant permission, but checking the box and telling it grant does not work. Also, my Apple magic track pad, which worked perfectly in 11.04 also fails to pair in 11.10. It now asks for a key which does not exist. In 11.04 it just asked to pair and then worked.

Martin G Miller (mgmiller) wrote :

Total regression with this issue in 11.10 32 bit

Martin G Miller (mgmiller) wrote :

I have sorted this for now. See bug report 872940 for my findings and workaround.

On Thu, October 13, 2011 00:16, Martin G Miller wrote:
> I have sorted this for now. See bug report 872940 for my findings and
> workaround.

Why a new bug? Why not add this to the existing bug?

Martin Pitt (pitti) on 2011-10-13
Changed in udev (Ubuntu):
status: Confirmed → Invalid
affects: bluez-utils (Ubuntu) → bluez (Ubuntu)
Changed in bluez (Ubuntu):
status: Confirmed → Triaged
Martin Pitt (pitti) wrote :

Can someone who is affected by this please mail this problem to <email address hidden> with the proposed rule change? We have patched this at least four times, and evertime we do it, some other device stopped working. Instead of keeping to fiddle with this at the distro level, it would be a lot better if this could be fixed/applied upstream, and affected people could then try out potential other solutions suggested by the bluez developers.

Thanks!

Martin Pitt (pitti) wrote :

Can someone who is affected by this please mail this problem to <email address hidden> with the proposed rule change? We have patched this at least four times, and evertime we do it, some other device stopped working. Instead of keeping to fiddle with this at the distro level, it would be a lot better if this could be fixed/applied upstream, and affected people could then try out potential other solutions suggested by the bluez developers.

You might also try joining #bluez on freenode and ask there. If you catch a developer there, the discussion turnaround is usually a lot faster.

Thanks!

Christian Elkjaer (c.elkjaer) wrote :

I can confirm that the fix proposed by Martin G Miller (mgmiller) in the above works.

Thomas Kluyver (takluyver) wrote :

Similarly with the logitech MX 5500 wireless keyboard after upgrading to Oneiric. The dongle was recognised as a Bluetooth adapter, but I couldn't get it to connect to either the keyboard or my phone (pairing succeeds, but then the connection to the device goes 'off', and the toggle to turn it on is greyed out).

Changing the udev rule from "hiddev*" to "hidraw*" sets it back to working as a plain external keyboard.

Bao Liang (timbao) wrote :

Yes, I have the exact the same problem(same HW configuration). And the approach posted by Martin fixes the problem prefectly. Just curious, why the new udev rules includes the device which is supposed to be a raw device?

Martin G Miller (mgmiller) wrote :

I sent all this info off to: <email address hidden> as requested. Hopefully it will help get this fixed permanently.

Rob Bruce (r-bruce) wrote :

Martin's workaround/fix worked for me. I've got a Dell-branded Logitech Bluetooth mouse/keyboard combo. Like the others, the input devices are pre-paried with the included adapter.

And this bug seems to be as regular as the leaves falling each Autumn: it recurs in every x.10 distribution. I just try to remember to dig out the old USB keyboard as part of my preparation for an upgrade.

Dhanish Patel (dhanish) wrote :

Just experienced this issue again....this time on upgrade to Precise from 11.10. Coincidently, exprienced exact same issue with when trying out Debian Wheezy/testing.

Also, worked is around the issue by changing the /lib/udev/rules.d/97-bluetooth-hid2hci.rules from "hiddev*" to "hidraw*" for Logitech devices.

lsusb shows....

Bus 006 Device 002: ID 046d:0b02 Logitech, Inc. BT Mini-Receiver (HID proxy mode)
Bus 006 Device 004: ID 046d:c70e Logitech, Inc. MX1000 Bluetooth Laser Mouse
Bus 006 Device 005: ID 046d:c70a Logitech, Inc. MX5000 Cordless Desktop

dmesg | grep 046D shows...

[ 3.672924] generic-usb 0003:046D:C70E.0002: input,hidraw1: USB HID v1.11 Keyboard [Logitech Logitech BT Mini-Receiver] on usb-0000:00:1d.0-1.2/input0
[ 3.918857] generic-usb 0003:046D:C70A.0003: input,hiddev0,hidraw2: USB HID v1.11 Mouse [Logitech Logitech BT Mini-Receiver] on usb-0000:00:1d.0-1.3/input0

I don't quite understand all of this but it seems following patch could be the source of the regression:

https://git.kernel.org/?p=bluetooth/bluez.git;a=commitdiff;h=63c3e0561a616dd72f1b78fcd9fd5e88015f2b31

It's scary to see patch actually say "This fix is going to cause major regressions in distros..."

So what is the long term solution for us? Patch seems to indicate that its fixing wrong behavior:

[quote]
From 63c3e0561a616dd72f1b78fcd9fd5e88015f2b31 Mon Sep 17 00:00:00 2001
From: Peter Hurley <email address hidden>
Date: Fri, 3 Jun 2011 16:53:03 -0400
Subject: [PATCH] Fix udev rule for Logitech devices

The *real* history of this file is a nightmare. Now that it's
back in the bluez project, fix the problems that were added
while it was in udev.

1) Only hiddev* devices provide the ioctl interface hid2hci uses
to switch from HID->HCI for --method=logitech-hid. (inquiring
minds can look in the kernel git tree at drivers/hid/usbhid/hiddev.c)
2) hidraw* devices don't belong to subsystem=usb (they are
subsystem=hidraw). This means that the udev rule that matched based on
hidraw* would never have been run anyway because of the early-out
subsystem!=usb on line 4.

This fix is going to cause major regressions in distros because there
is currently no way provided by bluez to *NOT* run hid2hci.

Many, many users (and maintainers) mistakenly believe that because
the keyboard and mouse works when the vid/pid of their device is matched
by the hidraw* rule, that "bluetooth" must be working. Of course, what's
really happening is the keyboard and mouse are working as HID input
devices instead.
[/quote]

Rob Bruce (r-bruce) wrote :

And it's back again in 12.04!

Wireless keyboard and mouse work fine at POST and grub, then disappear when the OS loads and can't be re-connected.

lsusb and dmesg report the same thing as Dhanish above.

Work-around is editing 97-bluetooth-hid2hci.rules, again just as Dhanish described above.

I also noticed that when I first booted with my backup keyboard/mouse, that when I brought up the Bluetooth configuration by clicking the tray icon that I now had two adapters! The system recognized both my "real" Bluetooth adapter -- the one I use to pair with phones, etc. -- and the adapter for the Logitech keyboard/mouse. In addition, this "new" adapter had become my default one. When the keyboard/mouse is operating normally, the Logitech adapter doesn't appear here. After fixing 97-bluetooth-hid2hci.rules and rebooting, the supernumerary adapter disappears from the Bluetooth configuration (as expected).

Finally, since there seems to be nothing that can be done about this problem that recurs with each distribution upgrade, I have composed a little Haiku:

Springtime and Autumn
I grab old keyboard and mouse
For distro upgrade.

Bao Liang (timbao) wrote :

I don't understand why this is not an issue which shall get fixed in
upstream? Because the Logitech adapter shall be taken as a Bluetooth
adapter?

2012/5/16 Rob Bruce <email address hidden>:
> And it's back again in 12.04!
>
> Wireless keyboard and mouse work fine at POST and grub, then disappear
> when the OS loads and can't be re-connected.
>
> lsusb and dmesg report the same thing as Dhanish above.
>
> Work-around is editing 97-bluetooth-hid2hci.rules, again just as Dhanish
> described above.
>
> I also noticed that when I first booted with my backup keyboard/mouse,
> that when I brought up the Bluetooth configuration by clicking the tray
> icon that I now had two adapters! The system recognized both my "real"
> Bluetooth adapter -- the one I use to pair with phones, etc. -- and the
> adapter for the Logitech keyboard/mouse. In addition, this "new" adapter
> had become my default one. When the keyboard/mouse is operating
> normally, the Logitech adapter doesn't appear here. After fixing 97
> -bluetooth-hid2hci.rules and rebooting, the supernumerary adapter
> disappears from the Bluetooth configuration (as expected).
>
> Finally, since there seems to be nothing that can be done about this
> problem that recurs with each distribution upgrade, I have composed a
> little Haiku:
>
> Springtime and Autumn
> I grab old keyboard and mouse
> For distro upgrade.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (872940).
> https://bugs.launchpad.net/bugs/123920
>
> Title:
>  Bluetooth Logitech Dinovo Keyboard/Mouse don't work
>
> Status in Bluez-utils - bluez-bcm203x, bluez-pcmcia-support, bluez-cups, bluez-utils:
>  New
> Status in “bluez” package in Ubuntu:
>  Triaged
> Status in “linux” package in Ubuntu:
>  Invalid
> Status in “linux-source-2.6.22” package in Ubuntu:
>  Won't Fix
> Status in “udev” package in Ubuntu:
>  Invalid
>
> Bug description:
>  Testing Gutsy Gibbon Tribe 2 LiveCD and bluetooth keyboard and mouse will work until Nautilus starts.  After Nautilus starts the keyboard and mouse are unresponsive and do not work.
>  I tried reconnecting the keyboard and mouse by using the discovery buttons on both the Bluetooth Dongle and Input device.  The problem still persists.
>  Using Intel P4 2.8 Ghz Processor, 3 GB ddr400 ram, Intel D875PBZ motherboard.  Logitech Dinovo media keyboard and mx1000 laser bluetooth mouse, with logitech mini bluetooth receiver.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/bluez-utils-old/+bug/123920/+subscriptions

Dhanish Patel (dhanish) wrote :
Download full text (6.4 KiB)

Definitely would be nice for this issue to go away permemnantly so we don't have to keep digging out those trusty PS/2 or USB keyboards every major upgrade.

I've dug into this little further...gained bit more understanding of all this...and may have a proper solution...at least for MX5000 devices.

[tl;dr]
Bluetooth dongle that came with my MX5000 starts in HID mode by default when plugged in. I can force it to start in HCI mode by holding the red button on the dongle when its being plugged in (ID for HID proxy mode 046d:0b02 and additinal HCI device with ID 046d:c709.)

Can others confirm if their Logitech devices or any similar devices have switch/button that allows user to control HID or HCI mode and provide their IDs from lsusb?

If there is such control offered by the devices, for immediate solution, we just need to disable the udev rule that causes the dongle to switch to HCI mode and let user decide to enable HCI mode with hardware switch.
[/tl;dr]

Long version...

First, just in case there are others like me who didn't bother looking up what HID or HCI modes mean...HCI mode means dongle acts as regular Bluetooth adapter requiring paring of keyboard/mouse while HID mode means dongle acts as regular USB keyboard/mouse device so it can work in BIOS and GRUB screens.

Logitech Bluetooth devices (that match following udev rules conditions: ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[345abce]|c71[34bc]") are devices that can run in both HID and HCI mode with HID mode being default as it should be. It is up to me a user to decide if I want to use the device in HCI mode.

I don't know exactly how other Logitech devices behave but the Bluetooth dongle that came with my MX5000 starts in HID mode by default when plugged in. I can force it to start in HCI mode by holding the red button on the dongle when its being plugged in. ID for HID proxy mode 046d:0b02 and additinal HCI device with ID 046d:c709.

Now a days I prefer to run in HID mode because it requires no configuration changes across multiple computers/OS. However, when I did prefer to run in HCI mode (unknownigly mind you until I looked up HID and HCI recently) I used to copy around the same pairing keys across multiple computers/OS.

If I did decide to go back to running in HCI mode, I would probably look into mx5000tools as well. I only found them recently and I have not had a chance to test but these tools seem to make it possible to control MX5000 keyboard's "LCD and to use some of the keys that are not recognized by the stock Linux HID driver." Take look at the mx5000tools homepage if you are interested: http://home.gna.org/mx5000tools/

My preferred long term solution would be to use HID mode by default and have a driver similar to Logitech's Windows drivers that I can install optionally. It would be awesome if the driver provided feature parity with existing Windows driver and it would be super awesome if Logitech themselves can release such driver for Linux...one can hope, no?

Fedora's current solution to this bug is to simply prevent switching to HCI mode by removing hid2hci. I don't like Fedora's solution but it does work. [[https://bugzilla.redhat.com/show_bug.cgi...

Read more...

Rob Bruce (r-bruce) wrote :

My particular affected keyboard/mouse is labeled Dell. It's a "Y-RAQ-DEL2" model . In actuality, the guts are Logitech, you can even read the logo on the PCB through the semi-transparent case of the dongle.

lsusb reports:

Bus 003 Device 002: ID 046d:0b02 Logitech, Inc. BT Mini-Receiver (HID proxy mode)
Bus 003 Device 003: ID 046d:c70e Logitech, Inc. MX1000 Bluetooth Laser Mouse
Bus 003 Device 004: ID 046d:c70a Logitech, Inc. MX5000 Cordless Desktop

The dongle does have a button, a blue one. I have not tried to unpair they keyboard/mouse from the dongle, since I didn't get any real documentation with it, and am not sure I could get them re-paired. Unlike a Logitech packaged MX5000, the keyboard doesn't have an LCD.

It does start in HID mode, and the button suggests that I could switch it to HCI, but I doubt that I would ever be using this in HCI mode: first, I'm not certain how to pair it, and second, I'd need to switch back if I needed to do anything with the CMOS or grub. As is, it works 6 months at a time with Linux.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.