^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. _joystick-api:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) Programming Interface
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) :Author: Ragnar Hojland Espinosa <ragnar@macula.net> - 7 Aug 1998
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) Introduction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) ============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) .. important::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) This document describes legacy ``js`` interface. Newer clients are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) encouraged to switch to the generic event (``evdev``) interface.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) The 1.0 driver uses a new, event based approach to the joystick driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) Instead of the user program polling for the joystick values, the joystick
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) driver now reports only any changes of its state. See joystick-api.txt,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) joystick.h and jstest.c included in the joystick package for more
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) information. The joystick device can be used in either blocking or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) nonblocking mode, and supports select() calls.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) For backward compatibility the old (v0.x) interface is still included.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) Any call to the joystick driver using the old interface will return values
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) that are compatible to the old interface. This interface is still limited
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) to 2 axes, and applications using it usually decode only 2 buttons, although
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) the driver provides up to 32.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) Initialization
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) Open the joystick device following the usual semantics (that is, with open).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) Since the driver now reports events instead of polling for changes,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) immediately after the open it will issue a series of synthetic events
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) (JS_EVENT_INIT) that you can read to obtain the initial state of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) joystick.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) By default, the device is opened in blocking mode::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) int fd = open ("/dev/input/js0", O_RDONLY);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) Event Reading
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) =============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) struct js_event e;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) read (fd, &e, sizeof(e));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) where js_event is defined as::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) struct js_event {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) __u32 time; /* event timestamp in milliseconds */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) __s16 value; /* value */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) __u8 type; /* event type */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) __u8 number; /* axis/button number */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) If the read is successful, it will return sizeof(e), unless you wanted to read
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) more than one event per read as described in section 3.1.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) js_event.type
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) -------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) The possible values of ``type`` are::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) #define JS_EVENT_BUTTON 0x01 /* button pressed/released */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) #define JS_EVENT_AXIS 0x02 /* joystick moved */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) #define JS_EVENT_INIT 0x80 /* initial state of device */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) As mentioned above, the driver will issue synthetic JS_EVENT_INIT ORed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) events on open. That is, if it's issuing a INIT BUTTON event, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) current type value will be::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) int type = JS_EVENT_BUTTON | JS_EVENT_INIT; /* 0x81 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) If you choose not to differentiate between synthetic or real events
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) you can turn off the JS_EVENT_INIT bits::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) type &= ~JS_EVENT_INIT; /* 0x01 */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) js_event.number
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) ---------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) The values of ``number`` correspond to the axis or button that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) generated the event. Note that they carry separate numeration (that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) is, you have both an axis 0 and a button 0). Generally,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) =============== =======
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) Axis number
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) =============== =======
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) 1st Axis X 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) 1st Axis Y 1
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) 2nd Axis X 2
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) 2nd Axis Y 3
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) ...and so on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) =============== =======
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) Hats vary from one joystick type to another. Some can be moved in 8
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) directions, some only in 4, The driver, however, always reports a hat as two
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) independent axis, even if the hardware doesn't allow independent movement.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) js_event.value
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) --------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) For an axis, ``value`` is a signed integer between -32767 and +32767
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) representing the position of the joystick along that axis. If you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) don't read a 0 when the joystick is ``dead``, or if it doesn't span the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) full range, you should recalibrate it (with, for example, jscal).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) For a button, ``value`` for a press button event is 1 and for a release
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) button event is 0.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) Though this::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) if (js_event.type == JS_EVENT_BUTTON) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) buttons_state ^= (1 << js_event.number);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) may work well if you handle JS_EVENT_INIT events separately,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) if ((js_event.type & ~JS_EVENT_INIT) == JS_EVENT_BUTTON) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) if (js_event.value)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) buttons_state |= (1 << js_event.number);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) else
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) buttons_state &= ~(1 << js_event.number);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) is much safer since it can't lose sync with the driver. As you would
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) have to write a separate handler for JS_EVENT_INIT events in the first
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) snippet, this ends up being shorter.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) js_event.time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) -------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) The time an event was generated is stored in ``js_event.time``. It's a time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) in milliseconds since ... well, since sometime in the past. This eases the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) task of detecting double clicks, figuring out if movement of axis and button
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) presses happened at the same time, and similar.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) Reading
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) =======
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) If you open the device in blocking mode, a read will block (that is,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) wait) forever until an event is generated and effectively read. There
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) are two alternatives if you can't afford to wait forever (which is,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) admittedly, a long time;)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) a) use select to wait until there's data to be read on fd, or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) until it timeouts. There's a good example on the select(2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) man page.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) b) open the device in non-blocking mode (O_NONBLOCK)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) O_NONBLOCK
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) ----------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) If read returns -1 when reading in O_NONBLOCK mode, this isn't
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) necessarily a "real" error (check errno(3)); it can just mean there
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) are no events pending to be read on the driver queue. You should read
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) all events on the queue (that is, until you get a -1).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) For example,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) while (1) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) while (read (fd, &e, sizeof(e)) > 0) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) process_event (e);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) /* EAGAIN is returned when the queue is empty */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) if (errno != EAGAIN) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) /* error */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) /* do something interesting with processed events */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) One reason for emptying the queue is that if it gets full you'll start
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) missing events since the queue is finite, and older events will get
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) overwritten.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) The other reason is that you want to know all what happened, and not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) delay the processing till later.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) Why can get the queue full? Because you don't empty the queue as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) mentioned, or because too much time elapses from one read to another
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) and too many events to store in the queue get generated. Note that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) high system load may contribute to space those reads even more.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) If time between reads is enough to fill the queue and lose an event,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) the driver will switch to startup mode and next time you read it,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) synthetic events (JS_EVENT_INIT) will be generated to inform you of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) the actual state of the joystick.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) .. note::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) As of version 1.2.8, the queue is circular and able to hold 64
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) events. You can increment this size bumping up JS_BUFF_SIZE in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) joystick.h and recompiling the driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) In the above code, you might as well want to read more than one event
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) at a time using the typical read(2) functionality. For that, you would
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) replace the read above with something like::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) struct js_event mybuffer[0xff];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) int i = read (fd, mybuffer, sizeof(mybuffer));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) In this case, read would return -1 if the queue was empty, or some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) other value in which the number of events read would be i /
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) sizeof(js_event) Again, if the buffer was full, it's a good idea to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) process the events and keep reading it until you empty the driver queue.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) IOCTLs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) ======
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) The joystick driver defines the following ioctl(2) operations::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) /* function 3rd arg */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) #define JSIOCGAXES /* get number of axes char */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) #define JSIOCGBUTTONS /* get number of buttons char */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) #define JSIOCGVERSION /* get driver version int */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) #define JSIOCGNAME(len) /* get identifier string char */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) #define JSIOCSCORR /* set correction values &js_corr */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) #define JSIOCGCORR /* get correction values &js_corr */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) For example, to read the number of axes::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) char number_of_axes;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) ioctl (fd, JSIOCGAXES, &number_of_axes);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) JSIOGCVERSION
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) -------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) JSIOGCVERSION is a good way to check in run-time whether the running
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) driver is 1.0+ and supports the event interface. If it is not, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) IOCTL will fail. For a compile-time decision, you can test the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) JS_VERSION symbol::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) #ifdef JS_VERSION
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) #if JS_VERSION > 0xsomething
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) JSIOCGNAME
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) ----------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) JSIOCGNAME(len) allows you to get the name string of the joystick - the same
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) as is being printed at boot time. The 'len' argument is the length of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) buffer provided by the application asking for the name. It is used to avoid
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) possible overrun should the name be too long::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) char name[128];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) if (ioctl(fd, JSIOCGNAME(sizeof(name)), name) < 0)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) strncpy(name, "Unknown", sizeof(name));
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) printf("Name: %s\n", name);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) JSIOC[SG]CORR
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271) -------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) For usage on JSIOC[SG]CORR I suggest you to look into jscal.c They are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274) not needed in a normal program, only in joystick calibration software
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) such as jscal or kcmjoy. These IOCTLs and data types aren't considered
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276) to be in the stable part of the API, and therefore may change without
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) warning in following releases of the driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279) Both JSIOCSCORR and JSIOCGCORR expect &js_corr to be able to hold
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280) information for all axis. That is, struct js_corr corr[MAX_AXIS];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282) struct js_corr is defined as::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284) struct js_corr {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) __s32 coef[8];
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) __u16 prec;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287) __u16 type;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) and ``type``::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) #define JS_CORR_NONE 0x00 /* returns raw values */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293) #define JS_CORR_BROKEN 0x01 /* broken line */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) Backward compatibility
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) ======================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299) The 0.x joystick driver API is quite limited and its usage is deprecated.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) The driver offers backward compatibility, though. Here's a quick summary::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302) struct JS_DATA_TYPE js;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) while (1) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304) if (read (fd, &js, JS_RETURN) != JS_RETURN) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) /* error */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307) usleep (1000);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310) As you can figure out from the example, the read returns immediately,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) with the actual state of the joystick::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313) struct JS_DATA_TYPE {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314) int buttons; /* immediate button state */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315) int x; /* immediate x axis value */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316) int y; /* immediate y axis value */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319) and JS_RETURN is defined as::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) #define JS_RETURN sizeof(struct JS_DATA_TYPE)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323) To test the state of the buttons,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327) first_button_state = js.buttons & 1;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328) second_button_state = js.buttons & 2;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) The axis values do not have a defined range in the original 0.x driver,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331) except for that the values are non-negative. The 1.2.8+ drivers use a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332) fixed range for reporting the values, 1 being the minimum, 128 the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333) center, and 255 maximum value.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335) The v0.8.0.2 driver also had an interface for 'digital joysticks', (now
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336) called Multisystem joysticks in this driver), under /dev/djsX. This driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) doesn't try to be compatible with that interface.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340) Final Notes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341) ===========
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) ____/| Comments, additions, and specially corrections are welcome.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) \ o.O| Documentation valid for at least version 1.2.8 of the joystick
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347) =(_)= driver and as usual, the ultimate source for documentation is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) U to "Use The Source Luke" or, at your convenience, Vojtech ;)
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags