Bug 9389 (BT-HID)

Summary: Bluetooth HID mouse support
Product: [Maemo Official Platform] Connectivity Reporter: Pelau Vadim <vadimpelau>
Component: BluetoothAssignee: unassigned <nobody>
Status: RESOLVED WONTFIX QA Contact: bluetooth-bugs
Severity: normal    
Priority: Unspecified CC: andre_klapper, davidsmoot, ericf2009, f2thak, gill1h, johan.hedberg, mr_abruce, vadimpelau, zeus2k
Version: 5.0/(2.2009.51-1)   
Target Milestone: ---   
Hardware: N900   
OS: Maemo   

Description Pelau Vadim (reporter) 2010-03-04 00:27:35 UTC
Some details:

I enabled mu logitech V470 via:

The mouse can be paired with code "0000".

Results are the following:
Open Arena "Tilt scroll right aka forward" acts as mouse 1 but it only gets one
click out of two.
Leafpad doesn't read any inputs as letters or characters.
MGutenberg allows scrolling, the trick is to first scroll up or else it will
quit unexpectedly.
EmelFM2, Contacts app, Modest one/a few lines and quits randomly.
Music player, calendar perfect scrolling!
Browser, horizontal only (any movement defaults to the top of the screen) and
really quick, and clicks (any) will move the cursor in the last used direction
(either left or right).
Scrolling on the desktop acts as a tap and the "configure desktop icon" and the
mouse appears to be right on top since the icon appears when moving the mouse
right + scroll; while moving left (over the menu, clock etc part of the screen)
nothing happens. However I haven't managed to click any items.
Pressing the screen and moving the mouse allows you to switch desktops but it's
limited by the place where your finger presses.

So far the buttons don't seem to work under any circumstance, the movement
function seems to be horizontal only while the scroll appears to work in
certain "lists".

Overall behavior is completely inconstant and makes the mouse unusable.

The expected outcome would be:
-an invisible but yet moving cursor in all four directions for the desktop.
-visible & working cursor for the web browser and other apps (eg quake 3 or
open arena) that display one)

Comment 1 Andre Klapper maemo.org 2010-03-04 13:37:04 UTC
Johan, this is split from bug 1897 - can you take a look at it as it "should
Comment 2 kmet.josef 2010-03-04 14:22:43 UTC
*** This bug has been confirmed by popular vote. ***
Comment 3 Andre Klapper maemo.org 2010-03-10 20:51:40 UTC
Johan: ping?
Comment 4 Johan Hedberg nokia 2010-03-13 15:16:25 UTC
(In reply to comment #3)
> Johan: ping?

Sorry, missed this initially (I've been on holiday & travelling the last few
weeks). Unfortunately I don't quite see what I could do about this. If the
device gets connected and creates a new input device for the X server I doubt
this has anything to do with the Bluetooth subsystem (i.e. most likely you'd
get the same behavior with a USB mouse too). I also don't have a Bluetooth
mouse myself to test this out. Probably someone experienced with the X server
as well as the windowing system (probably our window manager + input methods)
could be of more help.
Comment 5 David Smoot 2010-03-14 23:46:21 UTC
I can confirm a different model bluetooth HID mouse is also producing
unexpected and buggy behavior.  I have a "Microsoft Bluetooth Notebook Mouse
5000" and I too performed the wiki steps to enable bluetooth HID devices.  My
bluetooth keyboard works fine but the mouse does not.

The mouse pairs just fine but I get no visible cursor in any application nor do
I get behavior that looks like an invisible cursor.  All I can do repeatably is
if I press the mousewheel (middle button) and scroll, then the current
application closes.

It may very well be this is not a bluetooth bug but a general pointer device

I'm willing to provide testing / debug / logs for anyone working on this.

Comment 6 F2thaK 2010-03-20 16:57:36 UTC
id like to be able to toggle visible cursor
Comment 7 Pelau Vadim (reporter) 2010-03-24 13:04:16 UTC

Teeworlds seems to "support the mouse" somewhat better than the before
mentioned apps.

Although the movement is erratic it appears that the mouse can also be moved

The catch is that it will always tend to jump to the left side of the screen...
Comment 8 edoman 2010-04-09 04:58:31 UTC
Here are my findings:
Install the bluez packages for Maemo.

Go into /etc/bluetooth/main.conf
Find the DisablePlugins line and change it so that "input" isn't in it.
Restart bluetooth service.
stop bluetoothd
start bluetoothd

Find and download Ubuntu bluez-compat armel deb package
Open the deb archive and remove the "hidd" arm binary.
Copy the binary to the N900 (i.e. to /home/user ).

Click on the "discoverable" button on the bluetooth mouse.
Go into N900 bluetooth settings, and set it active.
Within N900 bluetooth settings, add new device and pair with the mouse (key
0000 usually)
On the xterm, run:
hcitool scan
You should see the mouse and its mac address.
If you don't then click the button on the mouse to put it into discoverable
mode again.

On the command line, run the following:
./hidd --search

This searches for and connects to the bluetooth mouse.
Once connected the white bluetooth symbol on the desktop goes blue.

Certain applications respond to the mouse, although there is a major
sensitivity issue.

You can activate a mouse icon in the web browser by swiping left-right.
Vulture's Eye game responds to mouse. Probably others too.

There is a problem with mouse sensitivity. The mouse icon goes up to the
top left corner or disappears. Using the touch screen sometimes brings the
mouse icon back.

So.... the sensitivity issue needs resolving.
Also.... why isn't "hidd" binary in bluez packages?
I would have expected it to appear in maemo-bluez-compat
Comment 9 Johan Hedberg nokia 2010-04-09 11:23:08 UTC
(In reply to comment #8)
> So.... the sensitivity issue needs resolving.
> Also.... why isn't "hidd" binary in bluez packages?

Because it conflicts with the input plugin. If you're going to use hidd for
creating HID connections then there really isn't any point in enabling the
input plugin. Doing "hidd --search" does a device discovery and connects HID to
the first peripheral type device found. The same can be accomplished through
the input pluging by calling the org.bluez.Input.Connect D-Bus method on the
appropriate D-Bus object (from the command line with the bluez-test package
you'd do "bluez-test-input connect <address>".
Comment 10 Eric Foster 2010-04-30 22:47:44 UTC
(In reply to comment #8)
I would like to confirm the same behavior with another HID device, this one a
keyboard with trackpad, the Adesso WKB-4000BB.  Following the instructions
above for removing input from the DisablePlugins entry of
, the stop and start of bluetoothd, and following Odessa's instructions the
keyboard paired with my N900 on the first attempt. The keyboard mostly worked,
won't go into details since this bug is about the mouse.  On enabling the
on-screen mouse cursor in the browser, any touch on the trackpad jumped the
cursor to the upper left corner, where it stayed no matter what.  So they are
communicating, but still dysfunctional.
I would much appreciate any clues to how to enable this cursor throughout the
device, not just the browser.  And of course any progress on calibrating it to
be actually useful!
Comment 11 Pelau Vadim (reporter) 2010-07-20 17:23:33 UTC
Check out Bluetooth HID scripts in the app manager and don't forget to thank to
all those who made this possible:

Comment 12 Alan Bruce maemo.org 2010-07-20 20:09:52 UTC
I'm trying to reopen this bug, because the patched evdev_drv.so is not perfect
(there's problems with kinetic scrolling with the patched driver), the scripts
are preliminary, and everything's community-created and hackish.

Source code for the evdev_drv.so patch (and a bluetooth.ko patch) is attached
to this post:

Comment 13 Pelau Vadim (reporter) 2010-07-21 11:29:10 UTC
(In reply to comment #12)
> I'm trying to reopen this bug, because the patched evdev_drv.so is not perfect
> (there's problems with kinetic scrolling with the patched driver), the scripts
> are preliminary, and everything's community-created and hackish.
> Source code for the evdev_drv.so patch (and a bluetooth.ko patch) is attached
> to this post:
> http://talk.maemo.org/showpost.php?p=736008&postcount=24

Perhaps the mods should change the name of the bug to something like "HID
support bugs" and  change the first post to have an accurate description of the
actual issue?

Perhaps even a new bug report for accuracy?
Comment 14 Andre Klapper maemo.org 2010-07-21 22:29:22 UTC
So I'm wondering what the exact request is. If it is "make everything work and
officially supported" it for sure is a WONTFIX for Maemo5.
Comment 15 Alan Bruce maemo.org 2010-07-28 18:39:27 UTC
I sure would like to see the mouse working (even if not officially supported),
because hacking the evdev driver (that causes a reboot when you replace it) is
not a very good solution.

My bug report could be narrowed down to: 

External mouse is too sensitive to be used; when an external mouse is connected
and moved, the cursor moves too fast and too far, and it quickly becomes
"stuck" in the top left corner of the screen.

This bug is the most important, as it is very difficult for the community to
provide a workaround or fix, since the driver is such a core element of the

Cursor visibility issues, extra mouse button issues, and other related issues
can be separate bugs.
Comment 16 Andre Klapper maemo.org 2010-08-24 21:09:30 UTC
The Maemo 5 platform components (e.g. libraries) are considered stable by
Only major issues have a chance of being addressed by Nokia, which most likely
means WONTFIX for this request for Maemo5.

(MeeGo Handset is where the unstable development is taking place. If you are a
developer (not a "normal" end-user) feedback about MeeGo Handset User Interface
issues is specially welcome, e.g. via the MeeGo bugtracker at
https://bugs.meego.com )
Comment 17 Andre Klapper maemo.org 2010-10-26 15:11:40 UTC
Yeah, this is a WONTFIX for Maemo5. :-/