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>
This commit is contained in:
parent
7d0e6192c2
commit
c272985098
1 changed files with 18 additions and 18 deletions
|
@ -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,
|
||||
|
|
Loading…
Reference in a new issue