<snip> * Starting Bluetooth ... * Running hid2hci ... [ ok ] * Starting hcid ... [ ok ] * Starting hidd ... Can't listen on HID control channel: Address already in use [ ok ] </snip>
try disabling the input.service: 1. Edit /etc/bluetooth/input.service 2. Replace Autostart=true to Autostart=false 3. Restart bluetooth (/etc/init.d/bluetooth restart) You can read more about the input service at: http://wiki.bluez.org/wiki/Input
(In reply to comment #1) > try disabling the input.service: Well, that helps, thanks. Doesn't solve the issue though... :) > You can read more about the input service at: > http://wiki.bluez.org/wiki/Input This link appears completely unresponsive...
Same problem here.. Setting Autostart=false helped me.
hmm...does thist mean that I have to reconnect keyboard/mouse with every reboot/disconnect?
No, but I'm experiencing the same issue with my notebook. Please make sure your hidd server is started, it also seems to help to keep your adapter visible and connectable (see bluetooth-applet from bluez-gnome).
(In reply to comment #2) > Doesn't solve the issue though... :) I suppose we shouldn't use hidd anymore but instead use the input service dbus interface: #!/usr/bin/python import dbus bus = dbus.SystemBus() # service activation bmgr = dbus.Interface(bus.get_object('org.bluez', '/org/bluez'), 'org.bluez.Manager') bus_id = bmgr.ActivateService('input') imgr = dbus.Interface(bus.get_object(bus_id, '/org/bluez/input'), 'org.bluez.input.Manager') # device creation path = imgr.CreateDevice('xx:xx:xx:xx:xx:xx') idev = dbus.Interface (bus.get_object(bus_id, path), 'org.bluez.input.Device') # host initiated connection idev.Connect() ########################### Could you please check if this works for you? It doesn't work for my dinovo :(
(In reply to comment #6) > Could you please check if this works for you? It doesn't work for my dinovo :( Nope, doesn't work... Plus, I really kinda prefer the old way. :)
hidd is gone in 3.10.1 The new service architecture is what should be used. If you want the old daemon use USE="old-daemons". Please test this using 3.10.1: ver 3.10.1: Add option to disable installation of manual pages. Fix input service encryption setup. Fix serial service methods. Fix network service connection handling. Provide a simple init script. the encryption setup could be what's borking it
Hi! I have upgraded to bluez-utils-3.10.1 with USE="-cups -debug -examples hal -old-daemons -test-programs usb" and now my bluetooth mouse no longer works... With bluez-utils-2.25-r1 it worked very well (automatic pairing without any user intervention). With bluez-utils-3.10-r1 automatic pairing no longer worked, but I could anyway use `hidd --search` or `hidd --connect` to manually connect to my mouse. Now hidd is gone and I cannot use my mouse :( Recompiling with USE="old-daemons" isn't a solution IMHO, because those daemon are deprecated, and I'd prefer to go back to the old behaviour of bluez-utils-2.25 (automatic pairing of input devices) anyway...
Btw, that little script from comment #6 does work for me... Where is it supposed to be put?
19:17 < holtmann> It works fine actually. However they have to repair the device. Please try repairing the device.
(In reply to comment #11) > 19:17 < holtmann> It works fine actually. However they have to repair the > device. > > Please try repairing the device. > How?
> Btw, that little script from comment #6 does work for me... Where is it supposed to be put? I think it should be adopted by bluez-gnome / kdebluetooth or another wizard thingy.
Sorry guys, but I really have some problems in understanding how this whole new "Services" thing works... For now I will use the script posted in comment #6 to connect to my mouse. I hope that kdebluetooth or some other tool will provide an easy and user-friendly interface to bluez as soon as possible...
Well...now the python script doesn't work anymore! :O Traceback (most recent call last): File "./MightyMouse-connect.py", line 13, in ? path = imgr.CreateDevice('00:14:51:C2:9B:F6') File "//usr/lib/python2.4/site-packages/dbus/proxies.py", line 63, in __call__ return self._proxy_method(*args, **keywords) File "//usr/lib/python2.4/site-packages/dbus/proxies.py", line 134, in __call__ args, File "//usr/lib/python2.4/site-packages/dbus/connection.py", line 595, in call_blocking reply_message = self.send_message_with_reply_and_block( dbus.DBusException: org.bluez.input.Error.AlreadyExists: Input Already exists
Created attachment 119461 [details] hidtool.py Improved script
(In reply to comment #16) > Created an attachment (id=119461) [edit] > hidtool.py > > Improved script > Reopening this bug until we have hid reported working
(In reply to comment #12) > > Please try repairing the device. > How? Well, the mouse should have a button to do connect/pairing. Press it and `hcitool scan` if dbus doesn't pick it up - this has nothing to do with repair as in hardware repair of a broken thing, I think you got confused :) (In reply to comment #14) > Sorry guys, but I really have some problems in understanding how this whole new > "Services" thing works... You are not the only one who's unhappy with this: https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/29506..
Could someone please (re)try the input service with the latest bluez-gnome-0.7 (now in portage). The new bluetooth-applet should ask for authorisation for incoming requests. hidtool.py is still required to add the input devices.
(In reply to comment #19) Yes, bluez-gnome-0.7 adds itself as authorization agent. Though I had to make sure that the "Automatically authorize..." setting was set since it will be quite hard to click on the notify balloon until the mouse is working. So to summarize: I have input.services, autostart=false; I ran hcitool scan to get the addresses of the keyboard and mouse. Used the hcitool.py script to add the addresses: hcitool.py --connect <myaddress> And I have to run hcitool.py without arguments on _every_ reboot to trigger the input daemon. As a side note, restarting my bluetooth gives: * Service bluetooth stopping * Service bluetooth stopped * Service bluetooth starting [ !! ] * Service bluetooth started
(In reply to comment #20) > And I have to run hcitool.py without arguments on _every_ reboot to trigger the input daemon. If I set input.service autostart=true, I don't have to run hcitool.py on every reboot. Thanks
(In reply to comment #21) > (In reply to comment #20) > > And I have to run hcitool.py without arguments on _every_ reboot to trigger the input daemon. > > > If I set input.service autostart=true, I don't have to run hcitool.py on every > reboot. > That's good to hear. Maybe add a hid use flag to make it autostart automatically.
I think we'd better use the old-daemons use flag to disable the input service, maybe we should add the hidd init.d script to start the hid daemon.
(In reply to comment #23) > I think we'd better use the old-daemons use flag to disable the input service, > maybe we should add the hidd init.d script to start the hid daemon. > Well as long as the input service has autostart=false, I don't see any problem in always installing it besides of course little bloat. Yes I think it would be prudent to add a hidd init script for now with the USE="old-daemons" use flag.
Created attachment 119911 [details] hidtool.py > I don't see any problem in always installing it Okay, we are talking about the same thing, I don't want to disable the input service, just setting autostart to false when old-daemons is enabled. I've updated the hidtool.py script so one can re-connect devices by 'path', list productid / vendorid and some cosmetic fixes :)
(In reply to comment #25) > > > I don't see any problem in always installing it > Okay, we are talking about the same thing, I don't want to disable the input > service, just setting autostart to false when old-daemons is enabled. > +*bluez-utils-3.11 (24 May 2007) + + 24 May 2007; Petteri Räty <betelgeuse@gentoo.org> + +files/3.11/conf.d-hidd, +files/3.11/init.d-hidd, + +bluez-utils-3.11.ebuild: + Version bump. Added an init script for the hidd daemon when the old-daemons + use flag is on as suggested in bug #178160. The input service is also disabled + by default when the old-daemons use flag is on. +
20:51 < Betelgeuse> holtmann: do you think it's better to install hidd or that custom script? 20:52 < holtmann> No No and No. The connect or create is only needed once. After that the HID connects back to you. It works this way. Period. 20:52 < Betelgeuse> holtmann: ok 20:52 < Betelgeuse> holtmann: so I install the helper and instruct people to run it the first time? 20:53 < holtmann> Have a script using input API is perfectly fine. I personally would prefer to use it C only. So no Python dependency for bluez-utils. So basically for the new service architechture we need some kind of a helper installed. Either what Dick wrote or installing hidd. I think kdebluetooth-1.0_rc3 has something for it too.
I suppose gnome-bluetooth will get that functionality too (there is some wizard code already in the tarball). Maybe I will rewrite hidtool.py to a C program.
(In reply to comment #28) > I suppose gnome-bluetooth will get that functionality too (there is some wizard > code already in the tarball). > Maybe I will rewrite hidtool.py to a C program. > kdebluetooth 1.0_beta3 should have a wizard for it too http://bluetooth.kmobiletools.org/1.0-beta3 being in python is not a problem for us but you could get your script upstream if you write it in C
Both bluez-gnome and kdebluetooth have GUI support for input devices nowadays and jakub reports that they work so marking this as fixed.
