Keyboard/mouse do not work when connected to USB hub, but only on Fedora - works on other distros

Question

For the record, the same problem happens in openSUSE, too, and the solution is the same. It is fixed in both Fedora 18 (as far as I could tell: I just booted a live CD) and openSUSE 12.3.

I installed Fedora 17 on my laptop, where I use a keyboard (Logitech K120) and mouse (generic USB mouse) connected to a hub.

Then I noticed that neither the keyboard nor the mouse worked. However:

• They do work in Arch Linux, Windows, GRUB and on the console (they only die when X starts), regardless if they're connected to a hub or not.
• If I plug the mouse/keyboard directly into the USB ports, they work properly.

This shows that neither the USB hub nor the keyboard/mouse are damaged.

lsusb of the relevant devices (USB hub, keyboard and mouse, respectively):

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.   

Any clues?

---

Editing as per sch's comments:

• The keyboard works on the console.
• The keyboard/mouse appears on xinput list, only when they're connected directly to the USB ports; not when they are connected to the hub.
• There is a change in /proc/interrupts when I move the mouse, even though the cursor doesn't move.

• When I plug the mouse/keyboard through the hub, nothing happens in the X logs. When I plug them directly I get the standard log information:

  [   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

It is a known bug in Fedora 17. The /lib/udev/rules.d/71-seat.rules has a rule for a "Mimo 720" device (an USB monitor with its own USB hub) which uses the same chipset (thus the same USB ID) for this task.

However, because I am not using a Mimo 720, it gets misconfigured.

Solution is editing /lib/udev/rules.d/71-seat.rules and commenting the line

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

Then it works perfectly. In fact, checked on Arch Linux and it uses a different strategy to detect that device:

# 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.