[Pkg-bluetooth-maintainers] Bug#631620: there may be things you could help with

[Cristian Ionescu-Idbohrn]

Please skip the html-formated message mime part (gmail sickness).
The text/plain is sufficient.

On Sun, 24 Jul 2011, Mark Fletcher wrote:
> On Sat, Jul 23, 2011 at 5:57 PM, Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn at axis.com> wrote:
> > Bug #626975 may give you some ideas.
> >
> > The result from 'lsusb' paired with the rules in
> > /lib/udev/rules.d/*hid2hci.rules may be a start point.
>
> Well the first thing I notice is that the rules in that file in
> /lib/udev/rules.d are expressed completely differently between the two
> package versions. This is looking more like it was back in the 4.61 days
> (when nothing worked for this keyboard combo either).

I wouldn't know anything about that.  I jumped on that horse at 4.91-1 :)
I couldn't get my BT dongle working.

        Bus 001 Device 004: ID 046d:0b04 Logitech, Inc.
        Bus 001 Device 005: ID 046d:c713 Logitech, Inc.
        Bus 001 Device 006: ID 046d:c714 Logitech, Inc. diNovo Edge Keyboard
        Bus 001 Device 007: ID 046d:c709 Logitech, Inc. BT Mini-Receiver (HCI mode)

I know nothing about MX5500.  Does it come with a dongle?

	# dmesg

may reveal more details.

	# lsusb -v

does that too.

	# udevadm control --log-priority=debug

may also help.  So may 'udevadm monitor ...'.
There's also the bluez-hcidump and bluez-tools packages with monitoring
tools.

> 4.66-3 (which works) specifies the path to the hid2hci executable, in
> /usr/sbin. Meanwhile, 4.94-2 doesn't specify the path to the hid2hci
> executable, and puts the executable in /lib/udev by the look of it. Any
> chance the hid2hci executable is not being found?

udev, AFAIR, picks the executables (used in the "RUN" rules) from
/lib/udev.  Whole path need to be specified for other locations.

Please run this:

	# dpkg -S hid2hci

and show us the results.  On my sid and testing installations it shows:

	bluez: /usr/share/man/man8/hid2hci.8.gz
	bluez: /lib/udev/hid2hci
	bluez: /lib/udev/rules.d/62-bluez-hid2hci.rules

Those should be the only 'hid2hci' related files you should find on your
box.  At some point there was:

	udev: /lib/udev/hid2hci
	udev: /lib/udev/rules.d/70-hid2hci.rules
	bluez: /usr/sbin/hid2hci
	bluez: /lib/udev/rules.d/62-bluez-hid2hci.rules

with 2 different command line options/arguments and somewhat different
rules.  Recent udev versions don't ship hid2hci any more.

> I also notice the hid2hci executable has changed between the two
> versions, not just its path. The command line options etc are different.

Yes.  See above.

> Any chance the new one just doesn't work properly?

The bluez package /lib/udev/hid2hci used in
/lib/udev/rules.d/62-bluez-hid2hci.rules from 4.94-2 (look at the man page
too) is the correct one, AFAICT.

> Overall I'm inclined to think the rule is firing but is either not able
> to find the hid2hci executable it is supposed to be running, or else
> that executable is not doing its job properly.

What does:

	# hcitool dev

and:

	# hcitool scan

show?

> I looked over the bug you pointed me at but I'm quickly getting out of
> my depth. I'll take a more detailed look later if I have time later this
> evening (in Japan, Sunday evening here).
>
> I'd like to be able to see some evidence of what's happening in the logs
> but I am not sure which logs I should be looking in -- I don't know my
> way around the debian logging arrangements well enough at the moment. If
> you can give me a pointer on that I can maybe gather some more useful
> information.

Yes.  See above ('udevadm control ...').  You should be able to 'tail -f
/var/log/syslog' and find out more.

> And finally -- lsusb output (when 4.66-3 is installed -- ie working. Are
> you thinking it would be different when 4.94-2 is installed? No, right?)

Shouldn't matter.


Cheers,

-- 
Cristian