Bug 827015 - KVM switch StarTech SV431DDVDUA does not work
KVM switch StarTech SV431DDVDUA does not work
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
17
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-31 08:43 EDT by Matteo Castellini
Modified: 2012-06-25 04:07 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-25 04:07:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Matteo Castellini 2012-05-31 08:43:35 EDT
Description of problem:
Under Fedora 17 I cannot use keyboard and mouse connected to the KVM switch  StarTech SV431DDVDUA. I was able to use it without any problem under Fedora 16


Version-Release number of selected component (if applicable):
xorg-x11-server-Xorg-1.12.0-5.fc17.x86_64


How reproducible:
Always


Steps to Reproduce:
1. Boot the computer
2. Connect the KVM switch
3. Try using either keyboard or mouse connected to the KVM switch
  
Actual results:
No response from keyboard (nothing happens even tapping Caps lock) or mouse


Expected results:
keyboard and mouse work properly


Additional info:
I attached directly to the computer keyboard and mouse are working without any problem
Comment 1 Andy Sturrock 2012-06-07 18:29:02 EDT
I can also confirm this bug.  I reinstalled F16 to check the KVM still worked and it's fine.  F17 does not recognise the keyboard or mouse.  They work fine if plugged directly into the machine.

They also don't work during the Anaconda install/upgrade process from the DVD.  However it does seem as though they are recognised by the Plymouth splash screen as hitting escape shows the textual progress.

dmesg doesn't show anything obvious.  Sensible looking things like this show:
[    2.693483] usb 2-1.2.4: new low-speed USB device number 7 using ehci_hcd
[    2.786512] usb 2-1.2.4: New USB device found, idVendor=046d, idProduct=c504
[    2.786517] usb 2-1.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.786520] usb 2-1.2.4: Product: USB Receiver
[    2.786522] usb 2-1.2.4: Manufacturer: Logitech
[    2.790162] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2.4/2-1.2.4:1.0/input/input4
[    2.790366] generic-usb 0003:046D:C504.0003: input,hidraw2: USB HID v1.10 Keyboard [Logitech USB Receiver] on usb-0000:00:1d.0-1.2.4/input0
[    2.798030] input: Logitech USB Receiver as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2.4/2-1.2.4:1.1/input/input5
[    2.798401] generic-usb 0003:046D:C504.0004: input,hidraw3: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:1d.0-1.2.4/input1
Comment 2 Matteo Castellini 2012-06-14 11:28:39 EDT
The problem is present on xorg-x11-server-Xorg-1.12.2-1.fc17.x86_64 as well. Any pointers / directions on how to provide any meaningful informations for debugging?
Comment 3 Andy Sturrock 2012-06-22 11:24:56 EDT
I just did a "yum -y update" followed by a reboot and the problem seems to be fixed.
Comment 4 Matteo Castellini 2012-06-25 04:07:07 EDT
Fixed for me too, looks like something in the last updates fixed it. Closing it as this bug report is not needed anymore.

Note You need to log in before you can comment on or make changes to this bug.