Input: uinput - add UI_SET_SWBIT ioctl
Signed-off-by: Dmitry Torokhov <[email protected]>
---
drivers/input/misc/uinput.c | 4 ++++
include/linux/uinput.h | 1 +
2 files changed, 5 insertions(+)
Index: work/drivers/input/misc/uinput.c
===================================================================
--- work.orig/drivers/input/misc/uinput.c
+++ work/drivers/input/misc/uinput.c
@@ -495,6 +495,10 @@ static long uinput_ioctl(struct file *fi
retval = uinput_set_bit(arg, ffbit, FF_MAX);
break;
+ case UI_SET_SWBIT:
+ retval = uinput_set_bit(arg, swbit, SW_MAX);
+ break;
+
case UI_SET_PHYS:
if (udev->state == UIST_CREATED) {
retval = -EINVAL;
Index: work/include/linux/uinput.h
===================================================================
--- work.orig/include/linux/uinput.h
+++ work/include/linux/uinput.h
@@ -91,6 +91,7 @@ struct uinput_ff_erase {
#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_SET_SWBIT _IOW(UINPUT_IOCTL_BASE, 109, int)
#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)
On Sun, 2005-11-20 at 01:36 -0500, Dmitry Torokhov wrote:
> plain text document attachment (uinput-add-sw-ioctl.patch)
> Input: uinput - add UI_SET_SWBIT ioctl
>
> Signed-off-by: Dmitry Torokhov <[email protected]>
All these new ioctl's and no compat layer for 32 bits apps on 64 bits
kernels ...
I'll send a patch later today for the current ones, but please, do it
from day #1 next time :)
Ben.
Oh,and ... ARGH !
So you pass that nice structure
struct input_event {
struct timeval time;
__u16 type;
__u16 code;
__s32 value;
};
to userland via read() ... cool, a structure that is not compatible
between 32 and 64 bits passed around via a read call. that will be fun
to fix.
Ben.
On Thu, 2005-11-24 at 09:54 +1100, Benjamin Herrenschmidt wrote:
> On Sun, 2005-11-20 at 01:36 -0500, Dmitry Torokhov wrote:
> > plain text document attachment (uinput-add-sw-ioctl.patch)
> > Input: uinput - add UI_SET_SWBIT ioctl
> >
> > Signed-off-by: Dmitry Torokhov <[email protected]>
>
> All these new ioctl's and no compat layer for 32 bits apps on 64 bits
> kernels ...
>
> I'll send a patch later today for the current ones, but please, do it
> from day #1 next time :)
Ok, forget my promise, I won't do a compat layer for it today. Way too
much crap in there, read's of structs made of other structs & unions
etc... all of this would need compat versions etc... no time for that.
Couldn't you have designed that properly in the first place ?
Ben.
On 11/23/05, Benjamin Herrenschmidt <[email protected]> wrote:
> Oh,and ... ARGH !
>
> So you pass that nice structure
>
> struct input_event {
> struct timeval time;
> __u16 type;
> __u16 code;
> __s32 value;
> };
>
> to userland via read() ... cool, a structure that is not compatible
> between 32 and 64 bits passed around via a read call. that will be fun
> to fix.
>
It would need the same treatment as evdev got. Entire uinput is not
32/64 bit friendly (hostorically). However, it should be used by an
userspace "driver", not an ordinary program, so we probably shoudl
just require using native-sized binary with uinput.
--
Dmitry
On 11/23/05, Benjamin Herrenschmidt <[email protected]> wrote:
> On Thu, 2005-11-24 at 09:54 +1100, Benjamin Herrenschmidt wrote:
> > On Sun, 2005-11-20 at 01:36 -0500, Dmitry Torokhov wrote:
> > > plain text document attachment (uinput-add-sw-ioctl.patch)
> > > Input: uinput - add UI_SET_SWBIT ioctl
> > >
> > > Signed-off-by: Dmitry Torokhov <[email protected]>
> >
> > All these new ioctl's and no compat layer for 32 bits apps on 64 bits
> > kernels ...
> >
> > I'll send a patch later today for the current ones, but please, do it
> > from day #1 next time :)
>
> Ok, forget my promise, I won't do a compat layer for it today. Way too
> much crap in there, read's of structs made of other structs & unions
> etc... all of this would need compat versions etc... no time for that.
>
> Couldn't you have designed that properly in the first place ?
>
I couldn't event design it improperly ;)
--
Dmitry
> > to userland via read() ... cool, a structure that is not compatible
> > between 32 and 64 bits passed around via a read call. that will be fun
> > to fix.
> >
>
> It would need the same treatment as evdev got. Entire uinput is not
> 32/64 bit friendly (hostorically). However, it should be used by an
> userspace "driver", not an ordinary program, so we probably shoudl
> just require using native-sized binary with uinput.
Not realistic. Some distros still don't have 64 bits userland ...
Ben.