Lines Matching +full:read +full:- +full:to +full:- +full:read
1 .. _joystick-api:
7 :Author: Ragnar Hojland Espinosa <[email protected]> - 7 Aug 1998
14 encouraged to switch to the generic event (``evdev``) interface.
16 The 1.0 driver uses a new, event based approach to the joystick driver.
18 driver now reports only any changes of its state. See joystick-api.txt,
24 Any call to the joystick driver using the old interface will return values
25 that are compatible to the old interface. This interface is still limited
26 to 2 axes, and applications using it usually decode only 2 buttons, although
27 the driver provides up to 32.
35 (JS_EVENT_INIT) that you can read to obtain the initial state of the
49 read (fd, &e, sizeof(e));
60 If the read is successful, it will return sizeof(e), unless you wanted to read
61 more than one event per read as described in section 3.1.
65 -------------
79 If you choose not to differentiate between synthetic or real events
86 ---------------
88 The values of ``number`` correspond to the axis or button that
102 Hats vary from one joystick type to another. Some can be moved in 8
108 --------------
110 For an axis, ``value`` is a signed integer between -32767 and +32767
112 don't read a 0 when the joystick is ``dead``, or if it doesn't span the
136 have to write a separate handler for JS_EVENT_INIT events in the first
141 -------------
152 If you open the device in blocking mode, a read will block (that is,
153 wait) forever until an event is generated and effectively read. There
154 are two alternatives if you can't afford to wait forever (which is,
157 a) use select to wait until there's data to be read on fd, or
161 b) open the device in non-blocking mode (O_NONBLOCK)
165 ----------
167 If read returns -1 when reading in O_NONBLOCK mode, this isn't
169 are no events pending to be read on the driver queue. You should read
170 all events on the queue (that is, until you get a -1).
177 while (read (fd, &e, sizeof(e)) > 0) {
191 The other reason is that you want to know all that happened, and not
195 mentioned, or because too much time elapses from one read to another
196 and too many events to store in the queue get generated. Note that
197 high system load may contribute to space those reads even more.
199 If time between reads is enough to fill the queue and lose an event,
200 the driver will switch to startup mode and next time you read it,
201 synthetic events (JS_EVENT_INIT) will be generated to inform you of
207 As of version 1.2.8, the queue is circular and able to hold 64
212 In the above code, you might as well want to read more than one event
213 at a time using the typical read(2) functionality. For that, you would
214 replace the read above with something like::
217 int i = read (fd, mybuffer, sizeof(mybuffer));
219 In this case, read would return -1 if the queue was empty, or some
220 other value in which the number of events read would be i /
221 sizeof(js_event) Again, if the buffer was full, it's a good idea to
238 For example, to read the number of axes::
245 -------------
247 JSIOGCVERSION is a good way to check in run-time whether the running
249 IOCTL will fail. For a compile-time decision, you can test the
257 ----------
259 JSIOCGNAME(len) allows you to get the name string of the joystick - the same
261 buffer provided by the application asking for the name. It is used to avoid
271 -------------
273 For usage on JSIOC[SG]CORR I suggest you to look into jscal.c They are
276 to be in the stable part of the API, and therefore may change without
279 Both JSIOCSCORR and JSIOCGCORR expect &js_corr to be able to hold
304 if (read (fd, &js, JS_RETURN) != JS_RETURN) {
310 As you can figure out from the example, the read returns immediately,
323 To test the state of the buttons,
331 except that the values are non-negative. The 1.2.8+ drivers use a
337 doesn't try to be compatible with that interface.
348 U to "Use The Source Luke" or, at your convenience, Vojtech ;)