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 > <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
