O teclado / mouse não funciona quando conectado ao hub USB, mas somente no Fedora - funciona em outras distribuições

Question

Para o registro , o mesmo problema acontece no openSUSE, e a solução é a mesma. Foi corrigido tanto no Fedora 18 (até onde eu sabia: acabei de inicializar um live CD) como no openSUSE 12.3.

Instalei o Fedora 17 no meu laptop, onde uso um teclado (Logitech K120) e mouse (mouse USB genérico) conectado a um hub.

Então notei que nem o teclado nem o mouse funcionavam. No entanto:

• Eles funcionam no Arch Linux, no Windows, no GRUB e no console (eles só morrem quando o X é iniciado), independentemente de estarem conectados a um hub ou não.
• Se eu conectar o mouse / teclado diretamente nas portas USB, elas funcionarão corretamente.

Isso mostra que nem o hub USB nem o teclado / mouse estão danificados.

lsusb dos dispositivos relevantes (hub USB, teclado e mouse, respectivamente):

Bus 002 Device 004: ID 058f:6254 Alcor Micro Corp. USB Hub
Bus 002 Device 006: ID 046d:c31c Logitech, Inc. Keyboard K120 for Business
Bus 002 Device 005: ID 093a:2521 Pixart Imaging, Inc.   

Alguma pista?

Editando os comentários de sch:

• O teclado funciona no console.
• O teclado / mouse aparece em xinput list , somente quando eles estão conectados diretamente às portas USB; não quando eles estão conectados ao hub.
• Há uma alteração em /proc/interrupts quando eu movo o mouse, mesmo que o cursor não se mova.

• Quando eu conecto o mouse / teclado através do hub , nada acontece nos logs X. Quando eu os conecto diretamente, recebo as informações de registro padrão:

  [   407.686] (II) config/udev: Adding input device USB OPTICAL MOUSE (/dev/input/mouse1)
  [   407.686] (II) No input driver specified, ignoring this device.
  [   407.686] (II) This device may have been added with another device file.
  [   407.686] (II) config/udev: Adding input device USB OPTICAL MOUSE (/dev/input/event8)
  [   407.686] (**) USB OPTICAL MOUSE: Applying InputClass "evdev pointer catchall"
  [   407.686] (II) Using input driver 'evdev' for 'USB OPTICAL MOUSE'
  [   407.686]    Option "XkbRules" "evdev"
  [   407.686]    Option "XkbModel" "evdev"
  [   407.686]    Option "XkbLayout" "us"
  [   407.686]    Option "_source" "server/udev"
  [   407.686]    Option "name" "USB OPTICAL MOUSE"
  [   407.686]    Option "path" "/dev/input/event8"
  [   407.686]    Option "device" "/dev/input/event8"
  [   407.686]    Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1c.3/0000:04:00.0/usb3/3-2/3-2:1.0/input/input30/event8"
  [   407.686]    Option "driver" "evdev"
  [   407.686] (**) USB OPTICAL MOUSE: always reports core events
  [   407.686] (**) evdev: USB OPTICAL MOUSE: Device: "/dev/input/event8"
  [   407.686] (--) evdev: USB OPTICAL MOUSE: Vendor 0x93a Product 0x2521
  [   407.686] (--) evdev: USB OPTICAL MOUSE: Found 9 mouse buttons
  [   407.686] (--) evdev: USB OPTICAL MOUSE: Found scroll wheel(s)
  [   407.686] (--) evdev: USB OPTICAL MOUSE: Found relative axes
  [   407.686] (--) evdev: USB OPTICAL MOUSE: Found x and y relative axes
  [   407.686] (II) evdev: USB OPTICAL MOUSE: Configuring as mouse
  [   407.686] (II) evdev: USB OPTICAL MOUSE: Adding scrollwheel support
  [   407.686] (**) evdev: USB OPTICAL MOUSE: YAxisMapping: buttons 4 and 5
  [   407.686] (**) evdev: USB OPTICAL MOUSE: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
  [   407.687] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1c.3/0000:04:00.0/usb3/3-2/3-2:1.0/input/input30/event8"
  [   407.687] (II) XINPUT: Adding extended input device "USB OPTICAL MOUSE"  (type: MOUSE, id 17)
  [   407.687] (II) evdev: USB OPTICAL MOUSE: initialized for relative axes.
  [   407.687] (**) USB OPTICAL MOUSE: (accel) keeping acceleration scheme 1
  [   407.687] (**) USB OPTICAL MOUSE: (accel) acceleration profile 0
  [   407.687] (**) USB OPTICAL MOUSE: (accel) acceleration factor: 2.000
  [   407.687] (**) USB OPTICAL MOUSE: (accel) acceleration threshold: 4
  

Answer 1

É um bug conhecido no Fedora 17. O /lib/udev/rules.d/71-seat.rules tem uma regra para um dispositivo " Mimo 720 " (um monitor USB com seu próprio hub USB) que usa o mesmo chipset ( assim, o mesmo ID USB) para esta tarefa.

No entanto, como não estou usando um Mimo 720, ele fica mal configurado.

A solução está editando /lib/udev/rules.d/71-seat.rules e comentando a linha

SUBSYSTEM=="usb", ATTR{idVendor}=="058f", ATTR{idProduct}=="6254", ENV{ID_AUTOSEAT}="1"

Então funciona perfeitamente. Na verdade, verificado no Arch Linux e usa uma estratégia diferente para detectar esse dispositivo:

# Mimo 720, with integrated USB hub, displaylink graphics, and e2i
# touchscreen. This device carries no proper VID/PID in the USB hub,
# but it does carry good ID data in the graphics component, hence we
# check it from the parent. There's a bit of a race here however,
# given that the child devices might not exist yet at the time this
# rule is executed. To work around this we'll trigger the parent from
# the child if we notice that the parent wasn't recognized yet.