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