maemo.org Bugzilla – Full Text Bug Listing
|Summary:||Bluetooth HID mouse support|
|Product:||[Maemo Official Platform] Connectivity||Reporter:||Pelau Vadim <vadimpelau>|
|Status:||RESOLVED WONTFIX||QA Contact:||bluetooth-bugs|
|Priority:||Unspecified||CC:||andre_klapper, davidsmoot, ericf2009, f2thak, gill1h, johan.hedberg, mr_abruce, vadimpelau, zeus2k|
Some details: I enabled mu logitech V470 via: http://wiki.maemo.org/Fremantle_Unsupported_Bluetooth_profiles#HID_host_.28i.e._support_for_Bluetooth_keyboards.29 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) REPRODUCIBILITY: always
Johan, this is split from bug 1897 - can you take a look at it as it "should work"?
*** This bug has been confirmed by popular vote. ***
(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.
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 bug. I'm willing to provide testing / debug / logs for anyone working on this. David
id like to be able to toggle visible cursor
UPDATE: 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 downwards. The catch is that it will always tend to jump to the left side of the screen...
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
(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>".
(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 /etc/bluetooth/main.conf , 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!
Check out Bluetooth HID scripts in the app manager and don't forget to thank to all those who made this possible: http://talk.maemo.org/showthread.php?t=57427
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
(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?
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.
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 X-server. Cursor visibility issues, extra mouse button issues, and other related issues can be separate bugs.
The Maemo 5 platform components (e.g. libraries) are considered stable by Nokia. 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 )
Yeah, this is a WONTFIX for Maemo5. :-/