Date: Fri, 3 Jan 2003 16:40:10 +0000 From: Richard Airlie <richard@darq.net> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/46734: joystick driver doesn't allow for anything but joy0 Message-ID: <20030103164010.A5004@phear.darq.net>
next in thread | raw e-mail | index | archive | help
>Number: 46734
>Category: kern
>Synopsis: joystick driver doesn't allow for anything but joy0
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Jan 03 08:50:01 PST 2003
>Closed-Date:
>Last-Modified:
>Originator: Richard Airlie <richard@darq.net>
>Release: FreeBSD 4.7-STABLE i386
>Organization:
>Environment:
System: FreeBSD kenya.darq.net 4.7-STABLE FreeBSD 4.7-STABLE #44: Fri Dec 20 19:20:23 GMT 2002 root@kenya.darq.net:/usr/src/sys/compile/KENYA i386
3-Axis 4 button analogue joystick connected to ISA game port on PCI sound card.
>Description:
The ISA game port allows for 4 axes and 4 buttons, which FreeBSD logically
splits into 2 joystick devices, each with 2 axes and 2 buttons. However it is
not actually possible to have both joy0 and joy1 at port IO_GAME, because
joy_attach() in joy.c calls bus_alloc_resource with RF_ACTIVE. Changing this
to RF_ACTIVE|RF_SHAREABLE allows both joy0 and joy1 to share the resource.
Also, the joystick driver always uses 0 as the minor device number to make_dev,
meaning that only joy0 ever gets attached by joy_attach().
Finally, there is a further problem I encountered whereby reading the game port
too quickly gave unreliable results. What seems to be happening is:
- A read of /dev/joy0 causes a byte to be written to the game port, causing
the timing of all 4 axes to begin.
- We wait in a loop until the two bits corresponding to the X and Y axes of
joy0 have gone low, then return the results to userland.
- A read of /dev/joy1 causes a byte to be written to the game port, causing
the timing of all 4 axes to begin. HOWEVER! a timing may already be in
progress at this point, since we only waited for the bits corresponding to
joy0's axes to go low last time.
By waiting for the previous timing to finish before starting a new one this
problem disappears. Unfortunately I do not have access to a 4 axis stick to
test this more thoroughly
From looking at the same code in -CURRENT, it appears that this problem will
also be seen there.
>How-To-Repeat:
1) On a machine with an ISA game port, build a kernel with the following:
device joy0 at isa? port IO_GAME
device joy1 at isa? port IO_GAME
2) Reboot with this kernel and try to open /dev/joy1
(eg: cat /dev/joy1 |hexdump). It will not be possible as joy1 is not
successfully attached.
>Fix:
--- usr/src/sys/isa/joy.c Tue Dec 17 10:50:50 2002
+++ /home/kaneda/joy_fix.c Tue Dec 17 10:52:44 2002
@@ -134,13 +134,13 @@
struct resource *res;
struct joy_softc *joy = device_get_softc(dev);
- res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, 0, ~0, 1, RF_ACTIVE);
+ res = bus_alloc_resource(dev, SYS_RES_IOPORT, &rid, 0, ~0, 1, RF_ACTIVE|RF_SHAREABLE);
if (res == NULL)
return ENXIO;
joy->bt = rman_get_bustag(res);
joy->port = rman_get_bushandle(res);
joy->timeout[0] = joy->timeout[1] = 0;
- make_dev(&joy_cdevsw, 0, 0, 0, 0600, "joy%d", unit);
+ make_dev(&joy_cdevsw, unit, 0, 0, 0600, "joy%d", unit);
return 0;
}
@@ -198,6 +198,12 @@
#else
disable_intr ();
#endif
+ nanotime(&t);
+ end.tv_sec = 0;
+ end.tv_nsec = joy->timeout[joypart(dev)] * 1000;
+ timespecadd(&end, &t);
+ for( ; timespeccmp(&t, &end, <) && (bus_space_read_1(bt, port, 0) & 0x0f); nanotime(&t) );
+
bus_space_write_1 (bt, port, 0, 0xff);
nanotime(&start);
end.tv_sec = 0;
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030103164010.A5004>