diff options
author | Antonio Ospite <ospite@studenti.unina.it> | 2013-12-16 01:52:17 -0800 |
---|---|---|
committer | Dmitry Torokhov <dmitry.torokhov@gmail.com> | 2013-12-16 02:13:35 -0800 |
commit | c2729850985934a3124319f8ff1d46d8c72bb012 (patch) | |
tree | 74238d313e0479e72341accd1176270f69ea6b0b /Documentation/input | |
parent | 7d0e6192c2f36139e4aa5e4107f4d7fb56d9f290 (diff) | |
download | talos-obmc-linux-c2729850985934a3124319f8ff1d46d8c72bb012.tar.gz talos-obmc-linux-c2729850985934a3124319f8ff1d46d8c72bb012.zip |
Input: joystick - use sizeof(VARIABLE) in documentation
Use the preferred style sizeof(VARIABLE) instead of sizeof(TYPE) in the
joystick API documentation, Documentation/CodingStyle states that this
is the preferred style for allocations but using it elsewhere is good
too.
Also fix some errors like "sizeof(struct mybuffer)" which didn't mean
anything.
Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Diffstat (limited to 'Documentation/input')
-rw-r--r-- | Documentation/input/joystick-api.txt | 36 |
1 files changed, 18 insertions, 18 deletions
diff --git a/Documentation/input/joystick-api.txt b/Documentation/input/joystick-api.txt index f95f64838788..943b18eac918 100644 --- a/Documentation/input/joystick-api.txt +++ b/Documentation/input/joystick-api.txt @@ -23,7 +23,7 @@ By default, the device is opened in blocking mode. ~~~~~~~~~~~~~~~~ struct js_event e; - read (fd, &e, sizeof(struct js_event)); + read (fd, &e, sizeof(e)); where js_event is defined as @@ -34,8 +34,8 @@ where js_event is defined as __u8 number; /* axis/button number */ }; -If the read is successful, it will return sizeof(struct js_event), unless -you wanted to read more than one event per read as described in section 3.1. +If the read is successful, it will return sizeof(e), unless you wanted to read +more than one event per read as described in section 3.1. 2.1 js_event.type @@ -99,9 +99,9 @@ may work well if you handle JS_EVENT_INIT events separately, if ((js_event.type & ~JS_EVENT_INIT) == JS_EVENT_BUTTON) { if (js_event.value) - buttons_state |= (1 << js_event.number); - else - buttons_state &= ~(1 << js_event.number); + buttons_state |= (1 << js_event.number); + else + buttons_state &= ~(1 << js_event.number); } is much safer since it can't lose sync with the driver. As you would @@ -144,14 +144,14 @@ all events on the queue (that is, until you get a -1). For example, while (1) { - while (read (fd, &e, sizeof(struct js_event)) > 0) { - process_event (e); - } - /* EAGAIN is returned when the queue is empty */ - if (errno != EAGAIN) { - /* error */ - } - /* do something interesting with processed events */ + while (read (fd, &e, sizeof(e)) > 0) { + process_event (e); + } + /* EAGAIN is returned when the queue is empty */ + if (errno != EAGAIN) { + /* error */ + } + /* do something interesting with processed events */ } One reason for emptying the queue is that if it gets full you'll start @@ -181,7 +181,7 @@ at a time using the typical read(2) functionality. For that, you would replace the read above with something like struct js_event mybuffer[0xff]; - int i = read (fd, mybuffer, sizeof(struct mybuffer)); + int i = read (fd, mybuffer, sizeof(mybuffer)); In this case, read would return -1 if the queue was empty, or some other value in which the number of events read would be i / @@ -269,9 +269,9 @@ The driver offers backward compatibility, though. Here's a quick summary: struct JS_DATA_TYPE js; while (1) { if (read (fd, &js, JS_RETURN) != JS_RETURN) { - /* error */ - } - usleep (1000); + /* error */ + } + usleep (1000); } As you can figure out from the example, the read returns immediately, |