aboutsummaryrefslogtreecommitdiff
path: root/Documentation/input
diff options
context:
space:
mode:
authorAntonio Ospite <ospite@studenti.unina.it>2013-12-16 01:52:17 -0800
committerDmitry Torokhov <dmitry.torokhov@gmail.com>2013-12-16 02:13:35 -0800
commitc2729850985934a3124319f8ff1d46d8c72bb012 (patch)
tree74238d313e0479e72341accd1176270f69ea6b0b /Documentation/input
parent7d0e6192c2f36139e4aa5e4107f4d7fb56d9f290 (diff)
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.txt36
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,