Keyboard won't sync after update

eArquilla · 2010-07-13 00:28:05

after a massive upgrade about two days ago i ran into a few problems, notably what ended up being a graphics driver malfunction that wouldn't let me start X for a while, but i managed to fix everything except one.

for some reason, my logitech dinovo edge keyboard will not sync to the bluetooth usb thingamabob once my computer boots. it WILL sync while booting, so i know it is not a keyboard malfunction, i am successfully able to toggle between the boot menus and such. but once i get to either the console login or X starts, nothing. no matter how much i try to connect it via the connect buttons... nothing.

maybe this is an easy fix, but i can't logically think of a setting in my computer that prevents my keyboard from syncing.
my desktop does not have bluetooth built in.

and i am using a different keyboard that directly plugs in to type this.

thank you very much for any replies... i waited 2 days and tried countless google searches before creating this (my first) post in the arch linux forums.
and i have been happily using arch for 2 years now

*edit* just tested it, it connects on other linux and windows machines perfectly.

Last edited by eArquilla (2010-07-13 01:39:27)

Eniotan · 2010-07-13 16:42:52

Same problem for me with my Logitech Dinovo Edge.

uname -a

2.6.34-ARCH #1 SMP PREEMPT Mon Jul 5 22:12:11 CEST 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz GenuineIntel GNU/Linux

For the moment, I have to synchronize manually: press the connect button under the keyboard and:

sudo hidd --search

I have tested different solutions with bluetooth daemon configuration but it don't work by this way. It seems logical because before these upgrade of udev , synchronization was automatic.

wonder · 2010-07-13 17:41:27

maybe because bluez is actually broken and can't be started? http://bugs.archlinux.org/task/20161

eArquilla · 2010-07-13 18:22:18

Eniotan wrote:

Same problem for me with my Logitech Dinovo Edge.
uname -a
2.6.34-ARCH #1 SMP PREEMPT Mon Jul 5 22:12:11 CEST 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz GenuineIntel GNU/Linux
For the moment, I have to synchronize manually: press the connect button under the keyboard and:
sudo hidd --search
I have tested different solutions with bluetooth daemon configuration but it don't work by this way. It seems logical because before these upgrade of udev , synchronization was automatic.

this worked for me! anybody have an idea for a permanent solution?

Eniotan · 2010-07-13 19:01:02

@wonder:
If bluez is broken, why can we have good synchro at boot (ability to choose a kernel at the GRUB's time with the keyboard) ? I don't have bluetooth in my rc.conf...

sudo /etc/rc.d/bluetooth restart
:: Stopping bluetooth subsystem:  pand dund rfcomm hidd bluetoothd                                                                                                                                     [DONE] 
:: Starting bluetooth subsystem:  bluetoothd                                                                                                                                                            [DONE]

My packages are: bluez 4.67-1 ; udev 160-1

After searches, it seems to be a recurrent problem for Logitech's keyboards and more related to udev than to bluez... (it's what I understood -> mistake because of my poor level in english langage/linux comprehension?)

RobertMe · 2010-07-13 19:08:21

This is probably related to udev 158. There is (was, is closed) a bug report in the bugtracker (FS#20039) for the Logitech MX5500 and Logitech diNovo Media, which is patched in Arch. Downgrade udev to an older version (157 or older) to see if it is indeed a udev problem. If it is I would recommend you to open a bug report in the bug tracker stating it's related to FS#20039

cl10k · 2010-07-13 19:13:32

The Problem indeed is udev 158 but with the new 159 the problem is fixed...

Eniotan · 2010-07-13 19:40:06

The problem persists with udev 157-1.
It's ok at GRUB, no more at the login manager step and after...

qqa · 2010-07-15 10:42:34

I had this problem too...

in: "/lib/udev/rules.d/70-hid2hci.rules"
I had these lines:

# Logitech devices (hidraw)
KERNEL=="hiddev*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[345e]|c71[34]", \
  RUN+="hid2hci --method=logitech-hid --devpath=%p"
KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[abc]|c71[bc]", \
  RUN+="hid2hci --method=logitech-hid --devpath=%p"

i removed the upper one (after i had read some sugestions on some boards and buggtragers)
so now i only have the hidraw* back

It seams to work flawlessly... i dont know why, but i just wanted to let say it, meybe it can help you to see what the problem is and make a real selution and just not a workaround.

sorry my english is not so good, but i hope that you can understand

Have a nice day.

RobertMe · 2010-07-15 17:15:47

Eniotan wrote:

It's ok at GRUB, no more at the login manager step and after...

That's normal because GRUB uses the keyboard and mouse from the BIOS (which uses your keyboard and mouse as a "dump" keyboard and mouse) for the BIOS there's no difference between a 10 year old PS/2 keyboard and mouse and a state of the art bluetooth keyboard and mouse connected using a usb receiver. When Arch boots it wants to take control over the keyboard and mouse so a state of the art keyboard and mouse can be use as a state of the art keyboard and mouse, which in this case (obviously) fails which leaves you without a working keyboard and mouse.

qqa wrote:

It seams to work flawlessly... i dont know why, but i just wanted to let say it, meybe it can help you to see what the problem is and make a real selution and just not a workaround.

It's probably best to add a task in the bugtracker so someone can work on a proper fix. When you do so, make sure you note the model name and the product id's, of which the later can be found by running cat /proc/bus/input/devices and search for the line which says 'Name="Logitech ..."' above it there's a line which mentions the vendor id (046d in case of a Logitech device) and the product id.

Mine (Logitech MX5500) looks like this:

I: Bus=0003 Vendor=046d Product=c71c Version=0111
N: Name="Logitech Logitech BT Mini-Receiver"

where the product id is c71c. There are probably two Logitech lines of which both have a different product id (one for the keyboard and one for the mouse) so make sure to post both.

Eniotan · 2010-07-17 15:42:40

I had to reinstall my Arch (because I've changed my old HDD for a SSD) and the fix in the "/lib/udev/rules.d/70-hid2hci.rules" works.
My actual 70-hid2hci.rules:

ACTION=="remove", GOTO="hid2hci_end"
SUBSYSTEM!="usb", GOTO="hid2hci_end"

# Variety of Dell Bluetooth devices - match on a mouse device that is
# self powered and where a HID report needs to be sent to switch modes
# Known supported devices: 413c:8154, 413c:8158, 413c:8162
#ATTR{bInterfaceClass}=="03", ATTR{bInterfaceSubClass}=="01", ATTR{bInterfaceProtocol}=="02", \
#  ATTRS{bDeviceClass}=="00", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
#  RUN+="hid2hci --method=dell --devpath=%p", ENV{HID2HCI_SWITCH}="1"

# Logitech devices (hidraw)
#KERNEL=="hiddev*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[345e]|c71[34]", \
# RUN+="hid2hci --method=logitech-hid --devpath=%p"
KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[abc]|c71[bc]", \
  RUN+="hid2hci --method=logitech-hid --devpath=%p"

ENV{DEVTYPE}!="usb_device", GOTO="hid2hci_end"

# When a Dell device recovers from S3, the mouse child needs to be repoked
# Unfortunately the only event seen is the BT device disappearing, so the mouse
# device needs to be chased down on the USB bus.
ATTR{bDeviceClass}=="e0", ATTR{bDeviceSubClass}=="01", ATTR{bDeviceProtocol}=="01", ATTR{idVendor}=="413c", \
  ENV{REMOVE_CMD}="/sbin/udevadm trigger --action=change --subsystem-match=usb --property-match=HID2HCI_SWITCH=1"

# CSR devices
ATTR{idVendor}=="0a12|0458|05ac", ATTR{idProduct}=="1000", RUN+="hid2hci --method=csr --devpath=%p"

LABEL="hid2hci_end"

For the bugtracker:
1/ If it's a rule's problem, it's udev the problem ? (I'm not sure)
2/ I don't know which is the keyboard in /proc/bus/input/devices :

I: Bus=0003 Vendor=046d Product=c713 Version=0111
N: Name="Logitech Logitech BT Mini-Receiver"
P: Phys=usb-0000:00:1d.2-1.2/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1.2/8-1.2:1.0/input/input7
U: Uniq=000761E0C0A4
H: Handlers=kbd event7 
B: EV=120013
B: KEY=1000000000007 ff800000000007ff febeffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=1f

I: Bus=0003 Vendor=046d Product=c714 Version=0111
N: Name="Logitech Logitech BT Mini-Receiver"
P: Phys=usb-0000:00:1d.2-1.3/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1.3/8-1.3:1.0/input/input8
U: Uniq=000761E0C0A4
H: Handlers=kbd mouse1 event8 
B: EV=1f
B: KEY=837fff002c3027 bf00444400000000 fff0001 f848b27c000 667bfad941dfed 9e000000000000 0
B: REL=143
B: ABS=100000000
B: MSC=10

RobertMe · 2010-08-12 08:07:32

In the new udev version released yesterday there are fixes for different Logitech keyboards including the MX5500 and different Edge models. So you'll just have to wait till it's in the repo's

qqa · 2010-08-12 09:45:19

Great news! Thanks

Arch Linux

#1 2010-07-13 00:28:05

Keyboard won't sync after update

#2 2010-07-13 16:42:52

Re: Keyboard won't sync after update

#3 2010-07-13 17:41:27

Re: Keyboard won't sync after update

#4 2010-07-13 18:22:18

Re: Keyboard won't sync after update

#5 2010-07-13 19:01:02

Re: Keyboard won't sync after update

#6 2010-07-13 19:08:21

Re: Keyboard won't sync after update

#7 2010-07-13 19:13:32

Re: Keyboard won't sync after update

#8 2010-07-13 19:40:06

Re: Keyboard won't sync after update

#9 2010-07-15 10:42:34

Re: Keyboard won't sync after update

#10 2010-07-15 17:15:47

Re: Keyboard won't sync after update

#11 2010-07-17 15:42:40

Re: Keyboard won't sync after update

#12 2010-08-12 08:07:32

Re: Keyboard won't sync after update

#13 2010-08-12 09:45:19

Re: Keyboard won't sync after update

Board footer