mjhjmtu

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
  

  
  

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", ATTRidVendor=="058f", ATTRidProduct=="6254", ENVID_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.