Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

<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 an attachment (id=119461) [details]
hidtool.py

Improved script

(In reply to comment #16)
> Created an attachment (id=119461) [edit] [details]
> 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 an attachment (id=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.