USB 허브에 연결하면 키보드/마우스가 작동하지 않지만 Fedora에서만 작동합니다. - 다른 배포판에서는 작동합니다.

USB 허브에 연결하면 키보드/마우스가 작동하지 않지만 Fedora에서만 작동합니다. - 다른 배포판에서는 작동합니다.

기록을 위해, openSUSE에서도 같은 문제가 발생하며 해결 방법은 동일합니다. 이 문제는 Fedora 18(제가 아는 한: 방금 Live CD를 부팅했습니다)과 openSUSE 12.3에서 수정되었습니다.

내 노트북에 Fedora 17이 설치되어 있고 허브에 연결된 키보드(Logitech K120)와 마우스(일반 USB 마우스)를 사용하고 있습니다.

그러다가 키보드나 마우스가 작동하지 않는다는 사실을 발견했습니다. 하지만:

  • 허브에 연결되어 있는지 여부에 관계없이 Arch Linux, Windows, GRUB 및 콘솔(X 부팅 시에만 사라짐)에서 작동합니다.
  • 마우스/키보드를 USB 포트에 직접 연결하면 제대로 작동합니다.

이는 USB 허브나 키보드/마우스가 손상되지 않았음을 나타냅니다.

관련 장치(각각 USB 허브, 키보드 및 마우스)에 대한 lsusb:

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.   

어떤 단서가 있나요?


sch의 의견을 바탕으로 편집하십시오.

  • 키보드는 콘솔에서 작동합니다.
  • xinput list키보드/마우스는 USB 포트에 직접 연결된 경우에만 표시됩니다.아니요허브에 연결되었을 때.
  • /proc/interrupts마우스를 움직이면 커서가 움직이지 않는데도 변경됩니다.
  • 마우스/키보드를 연결할 때허브를 통해, X 로그에는 아무 일도 일어나지 않습니다. 직접 삽입하면 표준 로그 메시지가 표시됩니다.

    [   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
    

답변1

이것은 알려진 버그입니다.Fedora 17에는 /lib/udev/rules.d/71-seat.rules"샤오미 720"장치(자체 USB 허브가 있는 USB 모니터)는 동일한 칩셋(따라서 동일한 USB ID)을 사용하여 이 작업을 수행합니다.

하지만 Mimo 720을 사용하지 않기 때문에 잘못 구성되었습니다.

/lib/udev/rules.d/71-seat.rules해결책은 해당 줄을 편집하고 주석을 추가하는 것입니다.

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

그러면 완벽하게 작동합니다. 실제로 Arch Linux를 확인하면 다른 전략을 사용하여 장치를 감지합니다.

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

관련 정보