Hi Dmitry
I posted all these ~2 months ago, but haven't seen any comments from you. Seeing
that you switched jobs (congratulations, btw!), I guess you were quite busy the
last few weeks. Hence, here's a resend of all the evdev changes squashed into a
single series. They're also available in my fdo
This moves basic checks and setup from uinput_setup_device() into
uinput_validate_absbits() to make it easier to use. This way, we can call
it from other places without copying the boilerplate code.
Reviewed-by: Peter Hutterer
Signed-off-by: David Herrmann
---
drivers/input/misc/uinput.c | 40 +
This adds a new ioctl UINPUT_DEV_SETUP that replaces the old device setup
method (by write()'ing "struct uinput_user_dev" to the node). The old
method is not easily extendable and requires huge payloads. Furthermore,
overloading write() without properly versioned objects is error-prone.
Therefore,
Hardware manufacturers group keys in the weirdest way possible. This may
cause a power-key to be grouped together with normal keyboard keys and
thus be reported on the same kernel interface.
However, user-space is often only interested in specific sets of events.
For instance, daemons dealing with
This ioctl is the counterpart to EVIOCGVERSION and returns the
uinput-version the kernel was compiled with.
Reviewed-by: Peter Hutterer
Signed-off-by: David Herrmann
---
drivers/input/misc/uinput.c | 6 ++
include/uapi/linux/uinput.h | 9 +
2 files changed, 15 insertions(+)
diff --
When we introduced the slotted MT ABS extensions, we didn't take care to
make SYN_DROPPED recoverable. Imagine a client recevies a SYN_DROPPED and
syncs its current state via EVIOCGABS. It has to call this ioctl for each
and every ABS code separately. Besides being horribly slow, this series
of ioc
On Fri, 18 Jul 2014, Dmitry Torokhov wrote:
> > The area where it must interact with power management is wakeup, both remote
> > wakeup at run time and wakeup from system suspend. In particular, there's
> > the question whether or not a device ignoring its input should be regarded
> > as a wakeup
On Sat, Jul 19, 2014 at 7:51 AM, Alan Stern wrote:
> On Fri, 18 Jul 2014, Dmitry Torokhov wrote:
>
>> > The area where it must interact with power management is wakeup, both
>> > remote
>> > wakeup at run time and wakeup from system suspend. In particular, there's
>> > the question whether or no
Recent version of xf86-input-wacom no longer support directly accessing
serial tablets. Instead xf86-input-wacom now expects all wacom tablets to
be driven by the kernel and to show up as evdev devices.
This has caused old serial Wacom tablets to stop working for people who still
have such tablets
Hi All,
Recent version of xf86-input-wacom no longer support directly accessing
serial tablets. Instead xf86-input-wacom now expects all wacom tablets to
be driven by the kernel and to show up as evdev devices.
This has caused old serial Wacom tablets to stop working for people who still
have suc
On Sat, 19 Jul 2014, Benson Leung wrote:
> > This raises an interesting question. Suppose the system gets suspended
> > while the lid is closed. At that point, shouldn't wakeup devices be
> > enabled, even if they were already inhibited?
>
> It's possible that this could be a policy decision, i
On Saturday, July 19, 2014 01:59:01 PM Alan Stern wrote:
> On Sat, 19 Jul 2014, Benson Leung wrote:
> > > This raises an interesting question. Suppose the system gets suspended
> > > while the lid is closed. At that point, shouldn't wakeup devices be
> > > enabled, even if they were already inhib
On Saturday, July 19, 2014 11:21:52 AM Dmitry Torokhov wrote:
> On Saturday, July 19, 2014 01:59:01 PM Alan Stern wrote:
> > On Sat, 19 Jul 2014, Benson Leung wrote:
> > > > This raises an interesting question. Suppose the system gets suspended
> > > > while the lid is closed. At that point, shou
Dnia 2014-07-10, czw o godzinie 14:44 -0400, Benjamin Tissoires pisze:
> Hi guys,
>
> Continuing on the Wacom cleanup, here are 5 patches.
>
> The first two enhance the battery reporting for the Wireless receiver by
> adding the status of the battery (discharging, full, charging) - inspired by
>
Hi Hans,
On Sat, Jul 19, 2014 at 06:38:40PM +0200, Hans de Goede wrote:
> Recent version of xf86-input-wacom no longer support directly accessing
> serial tablets. Instead xf86-input-wacom now expects all wacom tablets to
> be driven by the kernel and to show up as evdev devices.
>
> This has cau
On Sat, Jul 19, 2014 at 06:38:39PM +0200, Hans de Goede wrote:
> Hi All,
>
> Recent version of xf86-input-wacom no longer support directly accessing
> serial tablets. Instead xf86-input-wacom now expects all wacom tablets to
> be driven by the kernel and to show up as evdev devices.
>
> This has
We attempt to remove noise from coordinates reported by devices in
input_handle_abs_event(), unfortunately, unless we were dropping the
event altogether, we were ignoring the adjusted value and were passing
on the original value instead.
Reviewed-by: Andrew de los Reyes
Reviewed-by: Benson Leung
17 matches
Mail list logo
