What happens here is that we switch the Bluetooth device from HID mode to HCI
mode -- i.e. make it actually admit to being a Bluetooth device instead of
pretending to be a USB keyboard/mouse. Then hcid and hidd are supposed to
communicate with the keyboard for themselves.

I don't know why hcid isn't starting up correctly. Can you set
HID2HCI_ENABLE=false in /etc/sysconfig/bluetooth temporarily so that you
actually get to keep using the keyboard, and then 'strace -o hcitrace.txt hcid
-n' and attach the resulting hcitrace.txt.

Created attachment 114468 [details]
strace output from hcid -n

Well, it runs fine from the command line, so perhaps there is a startup race
condition?

Actually, hcid gets started even with HID2HCI_ENABLE=false, so I'm not sure that
was a good test.

hcid is supposed to be started. It's hid2hci which is stopped. 

Okay.  Let me know if you need anything else.

I need the strace of hcid when it's failing. If it only fails during boot,
please try adding the strace command to the init script.

Created attachment 114472 [details]
hcid strace output

Had to turn on HID2HCI_ENABLE again to get it to fail.	Looks like it's looking
for /var/run/dbus/system_bus_socket which doesn't get created until dbus-daemon
gets started.  Bluetooth starts at S25, dbus starts at S97.

Did you attach the wrong file? That one shows it finding
/var/run/dbus/system_bus_socket and only exiting when you hit Ctrl-C.

Please add '-s 1024' to your strace command line so we can see the strings it logs.

Created attachment 114529 [details]
hcid strace output

Try again to get the right trace.  Okay, it's not the dbus thing, but seems to
be with the bluetooth socket.  I'm going to try again with selinux turned off
as I'm seeing some other weirdness.

Looks like an selinux issue:

type=KERNEL msg=audit(1116445121.005:0): avc:  denied  { read } for 
path=socket:[6591] dev=sockfs ino=6591 scontext=system_u:system_r:bluetooth_t
tcontext=system_u:system_r:bluetooth_t tclass=socket
type=KERNEL msg=audit(1116445121.560:0): avc:  denied  { write } for 
scontext=system_u:system_r:bluetooth_t tcontext=system_u:system_r:bluetooth_t
tclass=socket

Note that with selinux disabled, I still need to set HID2HCI_ENABLE=false for
the keyboard and mouse to work.

Is hidd being run?

Yes, with selinux in permissive mode, hicd runs.

When you say 'hicd runs' do you mean 'hcid runs', in which case you didn't
answer my question -- or do you mean 'hidd runs', in which case what arguments
does it run with? Does it work better if you set HIDDARGS to '--search' in
/etc/sysconfig/hidd?

Do you have a real keyboard, or network login, so you can play with this while
your bluetooth keyboard isn't working?

Sorry, though you had a typo.  I do network logins to test, so no problem there. 

hidd was not running, so I enabled and started it:

[root@mini init.d]# chkconfig --list hidd
service hidd supports chkconfig, but is not referenced in any runlevel (run
'chkconfig --add hidd')
[root@mini init.d]# chkconfig --add hidd
[root@mini init.d]# service hidd start
Starting hidd:                                             [  OK  ]

messages:
May 19 17:33:17 mini kernel: Bluetooth: HIDP (Human Interface Emulation) ver 1.1
May 19 17:33:17 mini hidd[3843]: Bluetooth HID daemon

But no response.

Rebooted but still no go.  Mouse responds until bluetooth services are started.
 Does not come back when hidd is started.

FWIW, I do have the same problem with FC4T3 and a Logitech MX900 USB/Bluetooth
mouse. I'm quite sure that dwmw2's HID=>HCI switch thing is the problem.

I use a bluetooth mouse almost all the time now. When hidd is running, it
listens for connections. When I power on the mouse, it attempts to reconnect to
the computer. It also reconnects after the hid2hci switch at boot time. 

If running hidd with '--server' doesn't work with your mouse, can you try
'--search' instead?. Show hcidump output from both 'hidd --server' and power
cycling the mouse, and with 'hidd --search' while the mouse is turned on.

Here is hcidump from hidd --server after power cycling the mouse:

HCI sniffer - Bluetooth packet analyzer ver 1.18
device: hci0 snap_len: 1028 filter: 0xffffffff
> HCI Event: Connect Request (0x04) plen 10
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
    bdaddr 00:0A:95:0A:A4:34 role 0x01
    Role: Slave
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Connect Complete (0x03) plen 11
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
    handle 46 policy 0x0f
    Link policy: RSWITCH HOLD SNIFF PARK
> HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
> ACL data: handle 46 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 17 scid 0x0040
< ACL data: handle 46 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
> HCI Event: Command Complete (0x0e) plen 6
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
    handle 46 ptype 0xcc18
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Connection Packet Type Changed (0x1d) plen 5
> HCI Event: Disconn Complete (0x05) plen 4

Mouse/Keyboard does not work.

hcidump from --search:

HCI sniffer - Bluetooth packet analyzer ver 1.18
device: hci0 snap_len: 1028 filter: 0xffffffff
> HCI Event: Connect Request (0x04) plen 10
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
    bdaddr 00:0A:95:0A:A4:34 role 0x01
    Role: Slave
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Connect Complete (0x03) plen 11
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
    handle 46 policy 0x0f
    Link policy: RSWITCH HOLD SNIFF PARK
> HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
> ACL data: handle 46 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 17 scid 0x004c
< ACL data: handle 46 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0000 scid 0x004c result 2 status 0
> HCI Event: Command Complete (0x0e) plen 6
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
    handle 46 ptype 0xcc18
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Connection Packet Type Changed (0x1d) plen 5

here is keyboard:

> HCI Event: Connect Request (0x04) plen 10
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
    bdaddr 00:0A:95:40:74:09 role 0x01
    Role: Slave
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Connect Complete (0x03) plen 11
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
    handle 47 policy 0x0f
    Link policy: RSWITCH HOLD SNIFF PARK
> HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
> ACL data: handle 47 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 17 scid 0x00bc
< ACL data: handle 47 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0000 scid 0x00bc result 2 status 0
> HCI Event: Command Complete (0x0e) plen 6
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
    handle 47 ptype 0xcc18
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Connection Packet Type Changed (0x1d) plen 5
> HCI Event: Disconn Complete (0x05) plen 4

Neither works.

I also experience this bug with a recent build of Rawhide using a logitech
bluetooth mouse and keyboard. Please let me know how I can assist in fixing this
bug.

This bug seems to of been fixed in rawhide, this is on a x86_64 box using a
build of rawhide around the 9th of november using a Logitech bluetooth keyboard
and mouse.

FC4-ppc  -  clean fresh install
apple-bluetooth keyboard and mouse are ok until the bluetooth service is started.
i had to disable bluetooth in interactive mode and execute `chkconfig bluetooth
off` to keep it running after reboot.
`service bluetooth start` and both devices are lost again.

is this bug still present in fc5tn?

Still present in latest rawhide.

*** Bug 180665 has been marked as a duplicate of this bug. ***

Can you try running 'hidd --server' _before_ running 'hid2hci'? 

Well, I booted with hidd and bluetooth enabled but with HID2HCI_ENABLE=false so
that hid2hci did not run.  Keyboard and mouse worked okay.  But as soon as I run:

# hid2hci --tohci
Switching device 05ac:1000 to HCI mode was successful

the keyboard and mouse stop working.

We're experimenting with an Apple Bluetooth keyboard... it seems to work _only_
when we run 'hidd --connect xx:xx:xx:xx:xx:xx' with its bdaddr. 

I'm not sure how we can make this work in the general case. Marcel?

You need to connect the keyboard once and make sure it has been authenticated
and the encryption has been turned on. Should be the default for the Apple
keyboard, because it uses security mode 3. So once you have a link key for the
it, then disconnect and on the next connect everything should be fine. For the
HID proxy dongle from CSR it is important that it sees the initial pairing.
Otherwise it won't work. The local device must also have page scan enabled,
because otherwise the keyboard can't reconnect.

If you've got "hidd --server" running, and hcid running, and the dongle is in
hci mode, then you get this when you power cycle the keyboard:

1144878416.130487 > HCI Event: Connect Request (0x04) plen 10
  FC DF 42 95 0A 00 40 25 00 01
1144878416.130511 < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
  FC DF 42 95 0A 00 01
1144878416.151482 > HCI Event: Command Status (0x0f) plen 4
  00 01 09 04
1144878416.484481 > HCI Event: Connect Complete (0x03) plen 11
  00 2E 00 FC DF 42 95 0A 00 01 00
1144878416.484517 < HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
 2E 00 0F 00
1144878416.485482 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
  FC DF 42 95 0A 00 01
1144878416.490484 > ACL data: handle 46 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 17 scid 0x0043
1144878416.490508 < ACL data: handle 46 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0043 result 0 status 0
      Connection successful
1144878416.501480 > HCI Event: Command Complete (0x0e) plen 6
  01 0D 08 00 2E 00
1144878416.501497 < HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
  2E 00 18 CC
1144878416.518483 > HCI Event: Command Status (0x0f) plen 4
  00 01 0F 04
1144878416.519488 > HCI Event: Connection Packet Type Changed (0x1d) plen 5
  00 2E 00 18 00
1144878436.507387 > HCI Event: Disconn Complete (0x05) plen 4
  00 2E 00 08

Nothing happens WRT hidd whatsoever, nothing goes to syslog, etc.  Note that the
address of the keyboard is 00:0a:95:42:df:fc (the initiator of the connect
request, of course)

stil the same problem in fc6t1 + all rawhide updates.
mac mini, intel core duo 1,66 ghz

thanks to boot camp "restore the bootvolume as singlevolume"

bye fedora on the mactel mini.

Same problem here with a mac mini and my wireless keyboard. I got this when I installed FC5, and again 
when I updraded to FC6t3. The transition to FC6_final was smooth but this morning the "bluez" packages 
were upgraded and the problem got back...

I can't find my livecd to correct the thing (and I do not have any USB keyboard), so I'm stuck for a while on 
OSX. This is SO annoying, and must be a huge blocker for many of mac users.

iirc you can boot into the interactive mode "i" or "I"
or boot into runlevel 1. iirc grub = "a" or "e"
you do not need a livecd.

Confirmed here too with bluez-utils-3.7-2.  Setting HID2HCI_ENABLE=false in
/etc/sysconfig/bluetooth still fixes it.  I couldn't get it to work with
HID2HCI_ENABLE=true and bluez-utils-2.25-12 either.

Reporting the same problem with F7, bluez-utils-3.9-2.fc7.i386

I am using a Toshiba Tecra M5 with Logitech DiNovo bluetooth mouse and keyboard.
Keyboard and mouse are active partway through boot up sequence but become
inactive at some point during boot up and I can't type in my user name to log
in. If I pull the bluetooth USB dongle out and put it back in, the problem goes
away.

Problem is recreatable, happens every time.

Thanks,

David

Still happening with a fresh install of F7. HUGE blocker.

*** Bug 247496 has been marked as a duplicate of this bug. ***

There's no easy way to support hci proxy dongles because we can't create the
linkkeys and HID report descriptor ourselves (no hardware docs means we don't
know how to get some of the info from the dongle when in HID mode).

See this thread for details:
http://thread.gmane.org/gmane.linux.bluez.devel/12584/focus=12601

Maybe hid2hci should be disabled by default until such time we get some docs?

I disabled hid2hci in the default configuration in rawhide. If you see the
problem, plug in a USB keyboard, or use the network to disable hid2hci in
/etc/sysconfig/bluetooth (comment the HID2HCI_ENABLE line).