evie/android_kernel_oneplus_msm8998
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Input: joystick - use sizeof(VARIABLE) in documentation

Browse source 
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>
This commit is contained in:
Antonio Ospite 2013-12-16 01:52:17 -08:00 • committed by Dmitry Torokhov
parent 7d0e6192c2
commit c272985098
1 changed files with 18 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

36
Documentation/input/joystick-api.txt
View file

@ -23,7 +23,7 @@ By default, the device is opened in blocking mode.
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~
struct js_event e; struct js_event e;
read (fd, &e, sizeof(struct js_event)); read (fd, &e, sizeof(e));
where js_event is defined as where js_event is defined as
@ -34,8 +34,8 @@ where js_event is defined as
__u8 number; /* axis/button number */ __u8 number; /* axis/button number */
}; };
If the read is successful, it will return sizeof(struct js_event), unless If the read is successful, it will return sizeof(e), unless you wanted to read
you wanted to read more than one event per read as described in section 3.1. more than one event per read as described in section 3.1.
2.1 js_event.type 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.type & ~JS_EVENT_INIT) == JS_EVENT_BUTTON) {
if (js_event.value) if (js_event.value)
buttons_state |= (1 << js_event.number); buttons_state |= (1 << js_event.number);
else else
buttons_state &= ~(1 << js_event.number); buttons_state &= ~(1 << js_event.number);
} }
is much safer since it can't lose sync with the driver. As you would 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, For example,
while (1) { while (1) {
while (read (fd, &e, sizeof(struct js_event)) > 0) { while (read (fd, &e, sizeof(e)) > 0) {
process_event (e); process_event (e);
} }
/* EAGAIN is returned when the queue is empty */ /* EAGAIN is returned when the queue is empty */
if (errno != EAGAIN) { if (errno != EAGAIN) {
/* error */ /* error */
} }
/* do something interesting with processed events */ /* do something interesting with processed events */
} }
One reason for emptying the queue is that if it gets full you'll start 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 replace the read above with something like
struct js_event mybuffer[0xff]; 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 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 / 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; struct JS_DATA_TYPE js;
while (1) { while (1) {
if (read (fd, &js, JS_RETURN) != JS_RETURN) { if (read (fd, &js, JS_RETURN) != JS_RETURN) {
/* error */ /* error */
} }
usleep (1000); usleep (1000);
} }
As you can figure out from the example, the read returns immediately, As you can figure out from the example, the read returns immediately,