|
Bugzilla – Full Text Bug Listing |
| Summary: | bluetooth devices no longer useable --hidd missing | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.3 | Reporter: | Clark Tompsett <clarkt> |
| Component: | Network | Assignee: | Forgotten User ZhJd0F0L3x <forgotten_ZhJd0F0L3x> |
| Status: | RESOLVED INVALID | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | birkoff, jkosina, msvec, postadal |
| Version: | Alpha 4plus | ||
| Target Milestone: | Alpha 5 | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Beta-Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Clark Tompsett
2007-06-12 13:51:18 UTC
hidd has been folded into hcid and is no longer necessary. You can configure your input devices easily with kdebluetooth for example. This should work in Alpha5. Unless Daniel or Tom object, i'll say this is "Fixed in Alpha5". The only thing which is missing is the update case. Converting a hidd setup to the new BlueZ input service. I'm working on an upstream solution. Thats very frustrating. I've been using my bluetooth mouse on ubuntu for some time now, than i decided to try Suse... My first impression ws very good, but I cant manage to make the bluetooth mouse work. I read here that this is "fixed" and that "HCI" should do the job "easily", but I am a experienced linux user and I cant make it work, trying for some hours and google didnt helped at all with a solution. hcitool scan detects mouse, but i have no idea how to actualy make it work as a mouse. And i dont want to use kdebluetooth since i was plannig to use gnome. Could someone realy close this saying how to make mouse work with this new version? If it is easy, should be like it was before, hidd --search and it was done... For KDE and GNOME there is an introduction on the openSUSE wiki how to setup Bluetooth input devices: http://en.opensuse.org/Bluetooth hidd will be hopefully in future completely disappear. So please make yourself comfortable with the new and hopefully more user frienldy Bluetooth environment. For KDE 3 we compeltely rewritten the whole kdebluetooth framework and created also the "kinputwizard" which allows to setup Bluetooth Input devices without being root and without using any console. Unfortunately for GNOME the bluez-gnome application in the latest upstream version missed the 10.3 release. The latest version includes a equal Bluetooth Wizard which works the similar to the kinputwizard. In the BuildService you can find the latest version of bluez-gnome in the GNOME:Community repository. JFYI: There is also a bug which discuss about doing an version update of bluez-gnome to provide this wizard https://bugzilla.novell.com/show_bug.cgi?id=330461#c8 I don't seem to be able to find any reasonable documentation explaining how to perform the transition from hidd to hcid from the command-line user point of view (or generally any user using neither KDE nor GNOME). So this in fact might create a regression that can't be easily solved for those users which had working hidd setup in previous releases. I'd strongly ask for re-enabling the compilation of hidd for backward compatibility (of course the KDE/GNOME applets could still configure hcid). No. Just adding hidd (the binary) will not make it work. The framework changed. Get used to it. The BlueZ Wiki Howtos are very good (and linked from http://en.opensuse.org/Bluetooth). http://wiki.bluez.org/wiki/HOWTO/InputDevices Cristian: if non of those Documentation pages help you, feel free to reopen again. Jiri: Console users, just get your act together and write some console tool to configure input devices. Right now, only the desktop folks have contributed code AFAICT. These KDE and Gnome tools don't work in kdm/gdm. Therefore you're not able to log in using your bluetooth keyboard - that was possible before by altering bootup scripts slightly. Given the fact there exist a bluetooth keyboard-only computers (like Dell XPS M2010) this seems to be a major regression. The howto dealing with the dbus-send command linked in the comment #7 is not enough for creating a workable solution - there is not written how can be "X" in "/org/bluez/input/keyboardX" obtained for the particular keyboard and how errors are reported. Also, adding one line ("hidd --search" or "hidd --connect XYZ") to /etc/init.d/boot.local is something a slightly experienced user can do; writing a program for parsing dbus-send output is a tough task. If hidd is really not usable anymore, there should be at least an easily accessible script that provides similar functionality, including proper error handling. (In reply to comment #9 from Jiri Benc) > These KDE and Gnome tools don't work in kdm/gdm. Therefore you're not able to > log in using your bluetooth keyboard After you setup your bluetooth input devices, did you setup "trust" for the input devices? kbluetooth would ask if you want to "Accept" or "Always Accept" (settings the device as trusted device). The bluetooth input service don't need bluez-gnome or kbluetooth running as authorization agent if those device has trust set. So using bluetooth input device with kdm/gdm should work, IF those device set as trusted devices. http://wiki.bluez.org/wiki/HOWTO/Authorization#TrustedDevices: " The BlueZ daemon keeps a list of trusted devices. Trusted means that authorization is not required to accept incoming connections or other operations that need the user response. Once a given device is added to the list, the BlueZ daemon will reply authorized without call the Authorization agent. " This looks for me more like a usability problem. Maybe we should add some extra hint when setting up bluetooth input devices - or offer directly the option to set trust when setting up input devices. "Do you want to accept always connection by this input device? (recommended)" jfyi, to set trust for a device - without any GUI: dani@marvin:~> dbus-send --system --print-reply --dest=org.bluez /org/bluez/service_input org.bluez.Service.SetTrusted string:AA:FF:EE:AA:FF:EE method return sender=:1.24 -> dest=:1.3154 dani@marvin:~> dbus-send --system --print-reply --dest=org.bluez /org/bluez/service_input org.bluez.Service.ListTrusts method return sender=:1.24 -> dest=:1.3155 array [ string "AA:FF:EE:AA:FF:EE" ] The option to set the device as trusted when setting up input devices would indeed help. Overall, this seems to be more a documentation problem - people using hidd (which is incredibly easy to use) are not able to find information how to migrate to the new framework. Informations are scattered and incomplete. Waiting for somebody to write a console tool is a bit unrealistic in such situation. No, it's just not true. The first hit when googling for "bluez input device" takes you to the wiki page where all the information is available. http://wiki.bluez.org/wiki/Input |