Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | Programming gameport drivers |
2 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
3 | ||
4 | 1. A basic classic gameport | |
5 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
6 | ||
7 | If the gameport doesn't provide more than the inb()/outb() functionality, | |
8 | the code needed to register it with the joystick drivers is simple: | |
9 | ||
10 | struct gameport gameport; | |
11 | ||
12 | gameport.io = MY_IO_ADDRESS; | |
13 | gameport_register_port(&gameport); | |
14 | ||
15 | Make sure struct gameport is initialized to 0 in all other fields. The | |
16 | gameport generic code will take care of the rest. | |
17 | ||
18 | If your hardware supports more than one io address, and your driver can | |
2fe0ae78 ML |
19 | choose which one to program the hardware to, starting from the more exotic |
20 | addresses is preferred, because the likelihood of clashing with the standard | |
1da177e4 LT |
21 | 0x201 address is smaller. |
22 | ||
23 | Eg. if your driver supports addresses 0x200, 0x208, 0x210 and 0x218, then | |
24 | 0x218 would be the address of first choice. | |
25 | ||
26 | If your hardware supports a gameport address that is not mapped to ISA io | |
27 | space (is above 0x1000), use that one, and don't map the ISA mirror. | |
28 | ||
29 | Also, always request_region() on the whole io space occupied by the | |
30 | gameport. Although only one ioport is really used, the gameport usually | |
31 | occupies from one to sixteen addresses in the io space. | |
32 | ||
33 | Please also consider enabling the gameport on the card in the ->open() | |
34 | callback if the io is mapped to ISA space - this way it'll occupy the io | |
35 | space only when something really is using it. Disable it again in the | |
36 | ->close() callback. You also can select the io address in the ->open() | |
37 | callback, so that it doesn't fail if some of the possible addresses are | |
38 | already occupied by other gameports. | |
39 | ||
40 | 2. Memory mapped gameport | |
41 | ~~~~~~~~~~~~~~~~~~~~~~~~~ | |
42 | ||
43 | When a gameport can be accessed through MMIO, this way is preferred, because | |
44 | it is faster, allowing more reads per second. Registering such a gameport | |
45 | isn't as easy as a basic IO one, but not so much complex: | |
46 | ||
47 | struct gameport gameport; | |
48 | ||
49 | void my_trigger(struct gameport *gameport) | |
50 | { | |
51 | my_mmio = 0xff; | |
52 | } | |
53 | ||
54 | unsigned char my_read(struct gameport *gameport) | |
55 | { | |
56 | return my_mmio; | |
57 | } | |
58 | ||
59 | gameport.read = my_read; | |
60 | gameport.trigger = my_trigger; | |
61 | gameport_register_port(&gameport); | |
62 | ||
63 | 3. Cooked mode gameport | |
64 | ~~~~~~~~~~~~~~~~~~~~~~~ | |
65 | ||
66 | There are gameports that can report the axis values as numbers, that means | |
67 | the driver doesn't have to measure them the old way - an ADC is built into | |
68 | the gameport. To register a cooked gameport: | |
69 | ||
70 | struct gameport gameport; | |
71 | ||
72 | int my_cooked_read(struct gameport *gameport, int *axes, int *buttons) | |
73 | { | |
74 | int i; | |
75 | ||
76 | for (i = 0; i < 4; i++) | |
77 | axes[i] = my_mmio[i]; | |
78 | buttons[i] = my_mmio[4]; | |
79 | } | |
80 | ||
81 | int my_open(struct gameport *gameport, int mode) | |
82 | { | |
83 | return -(mode != GAMEPORT_MODE_COOKED); | |
84 | } | |
85 | ||
86 | gameport.cooked_read = my_cooked_read; | |
87 | gameport.open = my_open; | |
88 | gameport.fuzz = 8; | |
89 | gameport_register_port(&gameport); | |
90 | ||
91 | The only confusing thing here is the fuzz value. Best determined by | |
92 | experimentation, it is the amount of noise in the ADC data. Perfect | |
93 | gameports can set this to zero, most common have fuzz between 8 and 32. | |
94 | See analog.c and input.c for handling of fuzz - the fuzz value determines | |
95 | the size of a gaussian filter window that is used to eliminate the noise | |
96 | in the data. | |
97 | ||
98 | 4. More complex gameports | |
99 | ~~~~~~~~~~~~~~~~~~~~~~~~~ | |
100 | ||
101 | Gameports can support both raw and cooked modes. In that case combine either | |
102 | examples 1+2 or 1+3. Gameports can support internal calibration - see below, | |
103 | and also lightning.c and analog.c on how that works. If your driver supports | |
104 | more than one gameport instance simultaneously, use the ->private member of | |
105 | the gameport struct to point to your data. | |
106 | ||
107 | 5. Unregistering a gameport | |
108 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
109 | ||
110 | Simple: | |
111 | ||
112 | gameport_unregister_port(&gameport); | |
113 | ||
114 | 6. The gameport structure | |
115 | ~~~~~~~~~~~~~~~~~~~~~~~~~ | |
116 | ||
117 | struct gameport { | |
118 | ||
119 | void *private; | |
120 | ||
121 | A private pointer for free use in the gameport driver. (Not the joystick | |
122 | driver!) | |
123 | ||
124 | int number; | |
125 | ||
126 | Number assigned to the gameport when registered. Informational purpose only. | |
127 | ||
128 | int io; | |
129 | ||
130 | I/O address for use with raw mode. You have to either set this, or ->read() | |
131 | to some value if your gameport supports raw mode. | |
132 | ||
133 | int speed; | |
134 | ||
135 | Raw mode speed of the gameport reads in thousands of reads per second. | |
136 | ||
137 | int fuzz; | |
138 | ||
139 | If the gameport supports cooked mode, this should be set to a value that | |
140 | represents the amount of noise in the data. See section 3. | |
141 | ||
142 | void (*trigger)(struct gameport *); | |
143 | ||
144 | Trigger. This function should trigger the ns558 oneshots. If set to NULL, | |
145 | outb(0xff, io) will be used. | |
146 | ||
147 | unsigned char (*read)(struct gameport *); | |
148 | ||
149 | Read the buttons and ns558 oneshot bits. If set to NULL, inb(io) will be | |
150 | used instead. | |
151 | ||
152 | int (*cooked_read)(struct gameport *, int *axes, int *buttons); | |
153 | ||
154 | If the gameport supports cooked mode, it should point this to its cooked | |
155 | read function. It should fill axes[0..3] with four values of the joystick axes | |
156 | and buttons[0] with four bits representing the buttons. | |
157 | ||
158 | int (*calibrate)(struct gameport *, int *axes, int *max); | |
159 | ||
160 | Function for calibrating the ADC hardware. When called, axes[0..3] should be | |
161 | pre-filled by cooked data by the caller, max[0..3] should be pre-filled with | |
162 | expected maximums for each axis. The calibrate() function should set the | |
163 | sensitivity of the ADC hardware so that the maximums fit in its range and | |
164 | recompute the axes[] values to match the new sensitivity or re-read them from | |
165 | the hardware so that they give valid values. | |
166 | ||
167 | int (*open)(struct gameport *, int mode); | |
168 | ||
169 | Open() serves two purposes. First a driver either opens the port in raw or | |
170 | in cooked mode, the open() callback can decide which modes are supported. | |
171 | Second, resource allocation can happen here. The port can also be enabled | |
172 | here. Prior to this call, other fields of the gameport struct (namely the io | |
173 | member) need not to be valid. | |
174 | ||
175 | void (*close)(struct gameport *); | |
176 | ||
177 | Close() should free the resources allocated by open, possibly disabling the | |
178 | gameport. | |
179 | ||
180 | struct gameport_dev *dev; | |
181 | struct gameport *next; | |
182 | ||
183 | For internal use by the gameport layer. | |
184 | ||
185 | }; | |
186 | ||
187 | Enjoy! |