Slow uhid performance on Saitek X45 joystick

Trevor Blackwell tlb at tlb.org
Wed Sep 21 17:09:16 PDT 2005


I'm using a Saitek X45 joystick, with the uhid driver, and it all works
great except that the update rate is quite slow, about 7 per second or
140 mS between updates. I see the same behavior both on a 1.8 GHz P4 and
on a dual 3.0 GHz Xeon both running FreeBSD 5.4-RELEASE-p6.

Plugging in the device (with USB_DEBUG) gives:

uhid0: Saitek Saitek X45 Flight Control Stick, rev 2.00/4.02, addr 3, iclass 3/0
uhid_attach: bLength=7 bDescriptorType=5 bEndpointAddress=1-in bmAttributes=3 wMaxPacketSize=8 bInterval=10
usbd_alloc_xfer() = 0xc31b8c00
usbd_transfer: xfer=0xc31b8c00, flags=2, pipe=0xc29c5580, running=0
usbd_dump_queue: pipe=0xc29c5580
usb_insert_transfer: pipe=0xc29c5580 running=0 timeout=5000
uhci_device_control type=0x81, request=0x06, wValue=0x2200, wIndex=0x0000 len=131, addr=3, endpt=0
uhci_alloc_std_chain: addr=3 endpt=0 len=131 speed=1 flags=0x2
usb_schedsoftintr: polling=0

The bInterval suggests it should sample every 10 mS. When I open it I
get...

uhidopen: sc=0xc29a5780
usbd_open_pipe_intr: address=0x81 flags=0x4 len=11
usbd_open_pipe: iface=0xc226ed20 address=0x81 flags=0x1
usbd_setup_pipe: dev=0xc2987800 iface=0xc226ed20 ep=0xc2a783d0 pipe=0xe3f0798c
uhci_open: pipe=0xc2009800, addr=3, endpt=129 (1)
uhci_device_setintr: pipe=0xc2009800
uhci_device_setintr: ival=10 npoll=13
uhci_device_setintr: bw=0 offs=1
uhci_add_intr: n=1 sqh=0xc1ffd820
uhci_add_intr: n=11 sqh=0xc1ffd840
uhci_add_intr: n=21 sqh=0xc1ffd860
uhci_add_intr: n=31 sqh=0xc1ffd880
uhci_add_intr: n=41 sqh=0xc1ffd8a0
uhci_add_intr: n=51 sqh=0xc1ffd8c0
uhci_add_intr: n=61 sqh=0xc1ffd8e0
uhci_add_intr: n=71 sqh=0xc1ffd900
uhci_add_intr: n=81 sqh=0xc1ffd920
uhci_add_intr: n=91 sqh=0xc1ffd940
uhci_add_intr: n=101 sqh=0xc1ffdee0
uhci_add_intr: n=111 sqh=0xc1ffde80
uhci_add_intr: n=121 sqh=0xc1ffd7e0
uhci_device_setintr: returns 0xc2009800
usbd_clear_endpoint_stall
usbd_alloc_xfer() = 0xc31b8c00
usbd_transfer: xfer=0xc31b8c00, flags=2, pipe=0xc29c5580, running=0
usbd_dump_queue: pipe=0xc29c5580
usb_insert_transfer: pipe=0xc29c5580 running=0 timeout=5000
uhci_device_control type=0x02, request=0x01, wValue=0x0000, wIndex=0x0081 len=0, addr=3, endpt=0

And then, repeating about 7 times per second when the joystick is moving...

usb_transfer_complete: pipe=0xc2009800 xfer=0xc31b8c00 status=0 actlen=11
usb_transfer_complete: repeat=1 new head=0xc31b8c00
uhid_intr: status=0 cc=11
uhid_intr: data = ff f7 7f c2 80 aa 63 00 21 00 00
uhid_intr: waking 0xc29a57b4
uhci_device_intr_done: length=11
uhci_device_intr_done: requeing
uhci_alloc_std_chain: addr=3 endpt=1 len=11 speed=1 flags=0x4
uhidread: woke, error=0
uhidread: got 11 chars
uhidread
uhidread: sleep on 0xc29a57b4
usb_schedsoftintr: polling=0

so everything works just like I'd expect, except for the slow update
rate. 7/second may sound like a lot, but it's unusable for controlling
things.

Other USB devices have high update rates on this system, such as a:

uhid0: Phidgets Inc. PhidgetInterfaceKit, rev 1.10/8.0b, addr 4, iclass 3/0

which gives a reliable 50 updates/sec with an 8-byte input record.

The joystick is popular for flight simulators under Linux, and I haven't
found reports of a similar problem with the Linux kernel

The relevant uhci and uhub devices are:

uhci0: <Intel 82801BA/BAM (ICH2) USB controller USB-A> port 0xef40-0xef5f irq 19 at device 31.2 on pci0
uhci0: LegSup = 0x0030
usb0: <Intel 82801BA/BAM (ICH2) USB controller USB-A> on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub2: D-Link product 0xf103, class 9/0, rev 2.00/1.00, addr 2
uhub2: 7 ports with 7 removable, self powered


I've spend a couple hours poking around with no revelations yet, but if
someone could give me a push in the right direction I might be able to
fix it.

-- 
Trevor Blackwell      tlb at tlb.org          (650) 776-7870




More information about the freebsd-usb mailing list