Force feedback support for uinput
Subsystems (2)
PATCH 1/1 Force feedback support for uinput
Hello,
This patch adds support to uinput for Linux's force feedback interface. With these changes, it's possible to write drivers for force feedback joysticks and similar devices in userspace. It also adds a way to set the physical path of devices created via uinput, and it has a couple trivial bugfixes.
As far as I know, this means it's possible to emulate every feature of kernelspace input devices in userspace. The application I had in mind while writing this was a tool to make any Linux input device network- transparent; you can get the source to "inputpipe" from my Subversion repository if you're curious to see a use-case for this patch:
http://navi.cx/svn/misc/trunk/inputpipe/
The uinput driver doesn't provide a natural way to handle the effect uploading callbacks required for force feedback. It would be nice if uinput could simply let an application read() information about callback invocations, but we're locked into having read() only return input events.
My solution is to have a special input event, outside the range defined by the input system, that uinput sends to the application to signal when a callback has been entered. A particular callback invocation is identified by a request ID stored in this event.
The process using uinput, upon receiving one of these special input events, makes an ioctl() to get the parameters passed to the callback. Once the callback has been run in userspace, another ioctl() is performed to provide a return value and signal completion. During this time, the original user of the force feedback callback (typically another process making an ioctl() via evdev) sleeps.
This is fast, shoudln't break compatibility with anything, and isn't all that awful. If anyone has a better method I'd love to hear it, but this is the best I could come up with that wouldn't break compatibility.
I've only tested this with "rumble"-type force feedback devices, but it should support any type as it doesn't interpret the contents of the ff_effect structure. This has had the most testing on 2.6.8, but it doesn't look like anything has changed in uinput between that and 2.6.10-rc1.
(Not subscribed, please CC: replies)
--Micah
include/linux/uinput.h renamed from include/linux/uinput.h.orig +92 -0
@@ -22,6 +22,9 @@* Author: Aristeu Sergio Rozanski Filho <[email protected]> * * Changes/Revisions: +* 0.2 16/10/2004 (Micah Dowty <[email protected]>) +* - added force feedback support +* - added UI_SET_PHYS * 0.1 20/06/2002 * - first public version */
@@ -29,10 +32,25 @@#define UINPUT_MINOR 223#define UINPUT_NAME "uinput"#define UINPUT_BUFFER_SIZE 16 +#define UINPUT_NUM_REQUESTS 16/* state flags => bit index for {set|clear|test}_bit ops */ #define UIST_CREATED 0 +struct uinput_request { +int id; +int code;/* UI_FF_UPLOAD, UI_FF_ERASE */ + +int retval; +wait_queue_head_t waitq; +int completed; + +union { +int effect_id; +struct ff_effect * effect; + } u; +}; +struct uinput_device {struct input_dev *dev;unsigned long state;
@@ -41,13 +59,30 @@ head, tail;struct input_event buff[UINPUT_BUFFER_SIZE ]; + +struct uinput_request *requests[UINPUT_NUM_REQUESTS ]; +wait_queue_head_t requests_waitq; + struct semaphore requests_sem; };#endif /* __KERNEL__ */ +struct uinput_ff_upload { +int request_id; +int retval; +struct ff_effect effect; +}; + +struct uinput_ff_erase { +int request_id; +int retval; +int effect_id; +}; +/* ioctl */ #define UINPUT_IOCTL_BASE 'U'#define UI_DEV_CREATE _IO(UINPUT_IOCTL_BASE, 1)#define UI_DEV_DESTROY _IO(UINPUT_IOCTL_BASE, 2) +#define UI_SET_EVBIT _IOW(UINPUT_IOCTL_BASE, 100, int)#define UI_SET_KEYBIT _IOW(UINPUT_IOCTL_BASE, 101, int)#define UI_SET_RELBIT _IOW(UINPUT_IOCTL_BASE, 102, int)
@@ -56,6 +91,63 @@#define UI_SET_LEDBIT _IOW(UINPUT_IOCTL_BASE, 105, int)#define UI_SET_SNDBIT _IOW(UINPUT_IOCTL_BASE, 106, int)#define UI_SET_FFBIT _IOW(UINPUT_IOCTL_BASE, 107, int) +#define UI_SET_PHYS _IOW(UINPUT_IOCTL_BASE, 108, char*) + +#define UI_BEGIN_FF_UPLOAD _IOWR(UINPUT_IOCTL_BASE, 200, struct uinput_ff_upload) +#define UI_END_FF_UPLOAD _IOW(UINPUT_IOCTL_BASE, 201, struct uinput_ff_upload) +#define UI_BEGIN_FF_ERASE _IOWR(UINPUT_IOCTL_BASE, 202, struct uinput_ff_erase) +#define UI_END_FF_ERASE _IOW(UINPUT_IOCTL_BASE, 203, struct uinput_ff_erase) + +/* To write a force-feedback-capable driver, the upload_effect +* and erase_effect callbacks in input_dev must be implemented. +* The uinput driver will generate a fake input event when one of +* these callbacks are invoked. The userspace code then uses +* ioctls to retrieve additional parameters and send the return code. +* The callback blocks until this return code is sent. +* +* The described callback mechanism is only used if EV_FF is set. +* Otherwise, default implementations of upload_effect and erase_effect +* are used. +* +* To implement upload_effect(): +* 1. Wait for an event with type==EV_UINPUT and code==UI_FF_UPLOAD. +* A request ID will be given in 'value'. +* 2. Allocate a uinput_ff_upload struct, fill in request_id with +* the 'value' from the EV_UINPUT event. +* 3. Issue a UI_BEGIN_FF_UPLOAD ioctl, giving it the +* uinput_ff_upload struct. It will be filled in with the +* ff_effect passed to upload_effect(). +* 4. Perform the effect upload, and place the modified ff_effect +* and a return code back into the uinput_ff_upload struct. +* 5. Issue a UI_END_FF_UPLOAD ioctl, also giving it the +* uinput_ff_upload_effect struct. This will complete execution +* of our upload_effect() handler. +* +* To implement erase_effect(): +* 1. Wait for an event with type==EV_UINPUT and code==UI_FF_ERASE. +* A request ID will be given in 'value'. +* 2. Allocate a uinput_ff_erase struct, fill in request_id with +* the 'value' from the EV_UINPUT event. +* 3. Issue a UI_BEGIN_FF_ERASE ioctl, giving it the +* uinput_ff_erase struct. It will be filled in with the +* effect ID passed to erase_effect(). +* 4. Perform the effect erasure, and place a return code back +* into the uinput_ff_erase struct. +* and a return code back into the uinput_ff_erase struct. +* 5. Issue a UI_END_FF_ERASE ioctl, also giving it the +* uinput_ff_erase_effect struct. This will complete execution +* of our erase_effect() handler. +*/ + +/* This is the new event type, used only by uinput. +* 'code' is UI_FF_UPLOAD or UI_FF_ERASE, and 'value' +* is the unique request ID. This number was picked +* arbitrarily, above EV_MAX (since the input system +* never sees it) but in the range of a 16-bit int. +*/ +#define EV_UINPUT 0x0101 +#define UI_FF_UPLOAD 1 +#define UI_FF_ERASE 2#ifndef NBITS #define NBITS (x) ((((x)-1)/(sizeof(long)*8))+1)
drivers/input/misc/uinput.c renamed from drivers/input/misc/uinput.c.orig +199 -8
260 lines not on this page · raw message
Signature · 1 line
Only you can prevent creeping featurism!
Quoted 1 line
Hello,
Hi!
Quoted 5 lines
This patch adds support to uinput for Linux's force feedback interface. With these changes, it's possible to write drivers for force feedback joysticks and similar devices in userspace. It also adds a way to set the physical path of devices created via uinput, and it has a couple trivial bugfixes.
nice!
Quoted 4 lines
My solution is to have a special input event, outside the range defined by the input system, that uinput sends to the application to signal when a callback has been entered. A particular callback invocation is identified by a request ID stored in this event.
(snip)
include/linux/uinput.h line 148
Quoted 7 lines
include/linux/uinput.h renamed from include/linux/uinput.h.orig +7
-0+/* This is the new event type, used only by uinput. +* 'code' is UI_FF_UPLOAD or UI_FF_ERASE, and 'value' +* is the unique request ID. This number was picked +* arbitrarily, above EV_MAX (since the input system +* never sees it) but in the range of a 16-bit int. +*/ +#define EV_UINPUT 0x0101
I guess it should be moved to input.h with other types of events.
Quoted 6 lines
+/* To write a force-feedback-capable driver, the
upload_effect
+ * anderase_effectcallbacks ininput_devmust be implemented.
+ * The uinput driver will generate a fake input event when one of
+ * these callbacks are invoked. The userspace code then uses
+ * ioctls to retrieve additional parameters and send the return code.
+ * The callback blocks until this return code is sent.
(snip)
what about moving this long comment to Documentation/input/uinput.txt?
the rest of the patch seems fine to me
thanks,
(p.s.: sorry for the delay and the dup that will follow. my server is offline due adsl problems and the first answer is stuck there :)
--
Aristeu
Quoted 2 lines · On Fri, Nov 12, 2004 at 10:09:12AM -0200, [email protected] wrote:
Quoted 1 line
+#define
EV_UINPUT0x0101I guess it should be moved to
input.hwith other types of events.
Done. I didn't do this before since it isn't used anywhere other than between uinput and its applications. I added a short note to this effect in input.h
Quoted 8 lines
Quoted 6 lines
+/* To write a force-feedback-capable driver, the
upload_effect
+ * anderase_effectcallbacks ininput_devmust be implemented.
+ * The uinput driver will generate a fake input event when one of
+ * these callbacks are invoked. The userspace code then uses
+ * ioctls to retrieve additional parameters and send the return code.
+ * The callback blocks until this return code is sent.(snip)
what about moving this long comment toDocumentation/input/uinput.txt?
Also done. Since uinput.txt didn't have any documentation at all, I added a short section on basic usage. It should be expanded, but it's better than nothing.
Quoted 2 lines
(p.s.: sorry for the delay and the dup that will follow. my server is offline due adsl problems and the first answer is stuck there :)
No problem at all, I've been really busy lately.
Here's the revised patch, also including Andrew Morton's cleanups:
Documentation/input/uinput.txt +66 -0
@@ -0,0 +1,66 @@ +uinput: user level driver support for input subsystem +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +1. Basic use +~~~~~~~~~~~~ + +The uinput driver creates a character device, usually at /dev/uinput, that can +be used to create Linux input devices from userspace. The rest of this text +assumes you are already familiar with writing input drivers in kernelspace. + +The device's capabilities and identity are established primarily by write()'ing +a struct uinput_device. Information not contained in this structure is provided +with the UI_SET_* family of ioctl()s. After all this, UI_DEV_CREATE actually +registers a new device with the input subsystem. Between UI_DEV_CREATE and +UI_DEV_DESTROY, the UI_SET_* ioctl()s can't be used. + +Once the device has been created, /dev/uinput acts much like an event device. +write() sends a struct input_event out of the device, read() fetches input +events sent back to the driver by applications. Note that events written will +also be echoed back on read. + +2. Force Feedback +~~~~~~~~~~~~~~~~~ + +To write a force-feedback-capable driver, the upload_effect and erase_effect +callbacks in input_dev must be implemented. The uinput driver will generate a +fake input event when one of these callbacks are invoked. The userspace code +then uses ioctls to retrieve additional parameters and send the return code. +The callback blocks until this return code is sent. + +The described callback mechanism is only used if EV_FF is set. Otherwise, +default implementations of upload_effect and erase_effect are used. + +To implement upload_effect(): + + 1. Wait for an event with type==EV_UINPUT and code==UI_FF_UPLOAD. A request + ID will be given in 'value'. + + 2. Allocate a uinput_ff_upload struct, fill in request_id with the 'value' + from the EV_UINPUT event. + + 3. Issue a UI_BEGIN_FF_UPLOAD ioctl, giving it the uinput_ff_upload struct. + It will be filled in with the ff_effect passed to upload_effect(). + + 4. Perform the effect upload. Place the modified ff_effect and a return + code back into the uinput_ff_upload struct. + + 5. Issue a UI_END_FF_UPLOAD ioctl, also giving it the uinput_ff_upload_effect + struct. This will complete execution of our upload_effect() handler. + +To implement erase_effect(): + + 1. Wait for an event with type==EV_UINPUT and code==UI_FF_ERASE. A request + ID will be given in 'value'. + + 2. Allocate a uinput_ff_erase struct, fill in request_id with the 'value' + from the EV_UINPUT event. + + 3. Issue a UI_BEGIN_FF_ERASE ioctl, giving it the uinput_ff_erase struct. + It will be filled in with the effect ID passed to erase_effect(). + + 4. Perform the effect erasure, and place a return code back into the + uinput_ff_erase struct. + + 5. Issue a UI_END_FF_ERASE ioctl, also giving it the uinput_ff_erase_effect + struct. This will complete execution of our erase_effect() handler.
drivers/input/misc/uinput.c +204 -10
284 lines not on this page · raw message
include/linux/input.h +2 -0
@@ -94,6 +94,8 @@ struct input_absinfo {#define EV_FF_STATUS 0x17#define EV_MAX 0x1f +#define EV_UINPUT 0x0101/* Used only between /dev/uinput and applications */ +/* * Synchronization events. */
include/linux/uinput.h +45 -0
80 lines not on this page · raw message
Signature · 1 line
Only you can prevent creeping featurism!
Hi,
Quoted 3 lines
Also done. Since uinput.txt didn't have any documentation at all, I added a short section on basic usage. It should be expanded, but it's better than nothing.
that was the idea :)
Quoted 1 line
+The uinput driver creates a character device, usually at
/dev/uinput, that can
the default is '/dev/input/uinput'
Thanks for your work!
--
Aristeu
Quoted 2 lines · Aristeu Sergio Rozanski Filho
Quoted 1 line
+The uinput driver creates a character device, usually at
/dev/uinput, that canthe default is '
/dev/input/uinput'
Really? I haven't tried udev yet (shamefully enough) but with devfs at least it shows up as /dev/misc/uinput with a symlink at /dev/uinput.
If it really can be either /dev/uinput or /dev/input/uinput, I guess the document and some of my userspace code needs modifying ;)
--Micah
Signature · 1 line
Only you can prevent creeping featurism!
Quoted 9 lines · Aristeu Sergio Rozanski Filho
Quoted 2 lines
Quoted 1 line
+The uinput driver creates a character device, usually at
/dev/uinput, that canthe default is '
/dev/input/uinput'Really? I haven't tried udev yet (shamefully enough) but with devfs at least it shows up as
/dev/misc/uinputwith a symlink at/dev/uinput.If it really can be either
/dev/uinputor/dev/input/uinput, I guess the document and some of my userspace code needs modifying ;)
well, at least I think everything related to input subsystem should be inside /dev/input/ and I always did so because it seems more logical. I guess udev is also using /dev/input/uinput, but I'm not sure. As soon I finish some user space stuff I'm working on I'll add more documentation on uinput.txt and check devfs and udev.
Signature · 1 line
Aristeu