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 24Eg. 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[i] = 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.. note:: 121 122 This section is outdated. There are several fields here that don't 123 match what's there at include/linux/gameport.h. 124 125:: 126 127 struct gameport { 128 129 void *private; 130 131A private pointer for free use in the gameport driver. (Not the joystick 132driver!) 133 134:: 135 136 int number; 137 138Number assigned to the gameport when registered. Informational purpose only. 139 140:: 141 142 int io; 143 144I/O address for use with raw mode. You have to either set this, or ->read() 145to some value if your gameport supports raw mode. 146 147:: 148 149 int speed; 150 151Raw mode speed of the gameport reads in thousands of reads per second. 152 153:: 154 155 int fuzz; 156 157If the gameport supports cooked mode, this should be set to a value that 158represents the amount of noise in the data. See 159:ref:`gameport_pgm_cooked_mode`. 160 161:: 162 163 void (*trigger)(struct gameport *); 164 165Trigger. This function should trigger the ns558 oneshots. If set to NULL, 166outb(0xff, io) will be used. 167 168:: 169 170 unsigned char (*read)(struct gameport *); 171 172Read the buttons and ns558 oneshot bits. If set to NULL, inb(io) will be 173used instead. 174 175:: 176 177 int (*cooked_read)(struct gameport *, int *axes, int *buttons); 178 179If the gameport supports cooked mode, it should point this to its cooked 180read function. It should fill axes[0..3] with four values of the joystick axes 181and buttons[0] with four bits representing the buttons. 182 183:: 184 185 int (*calibrate)(struct gameport *, int *axes, int *max); 186 187Function for calibrating the ADC hardware. When called, axes[0..3] should be 188pre-filled by cooked data by the caller, max[0..3] should be pre-filled with 189expected maximums for each axis. The calibrate() function should set the 190sensitivity of the ADC hardware so that the maximums fit in its range and 191recompute the axes[] values to match the new sensitivity or re-read them from 192the hardware so that they give valid values. 193 194:: 195 196 int (*open)(struct gameport *, int mode); 197 198Open() serves two purposes. First a driver either opens the port in raw or 199in cooked mode, the open() callback can decide which modes are supported. 200Second, resource allocation can happen here. The port can also be enabled 201here. Prior to this call, other fields of the gameport struct (namely the io 202member) need not to be valid. 203 204:: 205 206 void (*close)(struct gameport *); 207 208Close() should free the resources allocated by open, possibly disabling the 209gameport. 210 211:: 212 213 struct gameport_dev *dev; 214 struct gameport *next; 215 216For internal use by the gameport layer. 217 218:: 219 220 }; 221 222Enjoy! 223