On Sat, Feb 17, 2018 at 10:19:14PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > > So, do you mean to implement this "disable" action as ioctl for
> > > > > particular /dev/input/event* device (instead of sysfs entry)?
> > > >
> > > > Yes, so the device can be powered down without the device node
On Sat, Feb 17, 2018 at 10:19:14PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > > So, do you mean to implement this "disable" action as ioctl for
> > > > > particular /dev/input/event* device (instead of sysfs entry)?
> > > >
> > > > Yes, so the device can be powered down without the device node
Hi!
> > > > So, do you mean to implement this "disable" action as ioctl for
> > > > particular /dev/input/event* device (instead of sysfs entry)?
> > >
> > > Yes, so the device can be powered down without the device node being
> > > closed and made unavailable. I don't know whether that's
Hi!
> > > > So, do you mean to implement this "disable" action as ioctl for
> > > > particular /dev/input/event* device (instead of sysfs entry)?
> > >
> > > Yes, so the device can be powered down without the device node being
> > > closed and made unavailable. I don't know whether that's
On Wed, Jan 03, 2018 at 10:31:33AM +0100, Pali Rohár wrote:
> On Wednesday 03 January 2018 02:47:29 Bastien Nocera wrote:
> > On Tue, 2018-01-02 at 22:54 +0100, Pali Rohár wrote:
> > > On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> > > > I don't doubt that the use cases should be
On Wed, Jan 03, 2018 at 10:31:33AM +0100, Pali Rohár wrote:
> On Wednesday 03 January 2018 02:47:29 Bastien Nocera wrote:
> > On Tue, 2018-01-02 at 22:54 +0100, Pali Rohár wrote:
> > > On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> > > > I don't doubt that the use cases should be
On Thu, Jan 05, 2017 at 01:48:08PM +0100, Pali Rohár wrote:
> On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> > On Wed, 2017-01-04 at 09:43 +0200, Ivaylo Dimitrov wrote:
> > >
> > > On 3.01.2017 13:21, Bastien Nocera wrote:
> > > > On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár
On Thu, Jan 05, 2017 at 01:48:08PM +0100, Pali Rohár wrote:
> On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> > On Wed, 2017-01-04 at 09:43 +0200, Ivaylo Dimitrov wrote:
> > >
> > > On 3.01.2017 13:21, Bastien Nocera wrote:
> > > > On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár
On Wednesday 03 January 2018 02:47:29 Bastien Nocera wrote:
> On Tue, 2018-01-02 at 22:54 +0100, Pali Rohár wrote:
> > On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> > > I don't doubt that the use cases should be catered for, I
> > > essentially
> > > did that same work without
On Wednesday 03 January 2018 02:47:29 Bastien Nocera wrote:
> On Tue, 2018-01-02 at 22:54 +0100, Pali Rohár wrote:
> > On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> > > I don't doubt that the use cases should be catered for, I
> > > essentially
> > > did that same work without
On Tue, 2018-01-02 at 22:54 +0100, Pali Rohár wrote:
> On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> > I don't doubt that the use cases should be catered for, I
> > essentially
> > did that same work without kernel changes for GNOME. What I doubt
> > is
> > the fuzzy semantics, the
On Tue, 2018-01-02 at 22:54 +0100, Pali Rohár wrote:
> On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> > I don't doubt that the use cases should be catered for, I
> > essentially
> > did that same work without kernel changes for GNOME. What I doubt
> > is
> > the fuzzy semantics, the
On Tue, 2018-01-02 at 22:48 +0100, Pali Rohár wrote:
> On Tuesday 03 January 2017 12:21:21 Bastien Nocera wrote:
> > On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
> > > On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
> > > > On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
> >
On Tue, 2018-01-02 at 22:48 +0100, Pali Rohár wrote:
> On Tuesday 03 January 2017 12:21:21 Bastien Nocera wrote:
> > On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
> > > On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
> > > > On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
> >
On Tue, 2017-01-17 at 12:07 +0100, Pavel Machek wrote:
>
> We'd really like it to work on plain old text console, too, because
> that's what
> I'm using on n900, and with old maemo userspace, because that's what
> everyone
> else uses.
>
> You mentioned you think X.org can do this kind of
On Tue, 2017-01-17 at 12:07 +0100, Pavel Machek wrote:
>
> We'd really like it to work on plain old text console, too, because
> that's what
> I'm using on n900, and with old maemo userspace, because that's what
> everyone
> else uses.
>
> You mentioned you think X.org can do this kind of
On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> I don't doubt that the use cases should be catered for, I essentially
> did that same work without kernel changes for GNOME. What I doubt is
> the fuzzy semantics, the fact that the device is kept opened but no
> data is sent (that's
On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> I don't doubt that the use cases should be catered for, I essentially
> did that same work without kernel changes for GNOME. What I doubt is
> the fuzzy semantics, the fact that the device is kept opened but no
> data is sent (that's
On Tuesday 03 January 2017 12:21:21 Bastien Nocera wrote:
> On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
> > On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
> > > On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
> > > > This patch allows user to disable events from any input
On Tuesday 03 January 2017 12:21:21 Bastien Nocera wrote:
> On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
> > On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
> > > On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
> > > > This patch allows user to disable events from any input
Hi!
> > > > This is just a RFC patch, not tested yet. Original post about
> > > > motivation
> > > > about this patch is there: https://lkml.org/lkml/2014/11/29/92
> > >
> > > Having implemented something of that ilk in user-space (we
> > > automatically disable touch devices when the associated
Hi!
> > > > This is just a RFC patch, not tested yet. Original post about
> > > > motivation
> > > > about this patch is there: https://lkml.org/lkml/2014/11/29/92
> > >
> > > Having implemented something of that ilk in user-space (we
> > > automatically disable touch devices when the associated
On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> On Wed, 2017-01-04 at 09:43 +0200, Ivaylo Dimitrov wrote:
> >
> > On 3.01.2017 13:21, Bastien Nocera wrote:
> > > On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
> > > > On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
>
On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> On Wed, 2017-01-04 at 09:43 +0200, Ivaylo Dimitrov wrote:
> >
> > On 3.01.2017 13:21, Bastien Nocera wrote:
> > > On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
> > > > On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
>
On Wed, 2017-01-04 at 09:43 +0200, Ivaylo Dimitrov wrote:
>
> On 3.01.2017 13:21, Bastien Nocera wrote:
> > On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
> > > On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
> > > > On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
> > > > >
On Wed, 2017-01-04 at 09:43 +0200, Ivaylo Dimitrov wrote:
>
> On 3.01.2017 13:21, Bastien Nocera wrote:
> > On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
> > > On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
> > > > On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
> > > > >
On 3.01.2017 13:21, Bastien Nocera wrote:
On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
This patch allows user to disable events from any input device so
events
would not be
On 3.01.2017 13:21, Bastien Nocera wrote:
On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
This patch allows user to disable events from any input device so
events
would not be
On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
> On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
> > On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
> > > This patch allows user to disable events from any input device so
> > > events
> > > would not be delivered to userspace.
>
On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
> On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
> > On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
> > > This patch allows user to disable events from any input device so
> > > events
> > > would not be delivered to userspace.
>
On Monday 02 January 2017 17:44:38 David Herrmann wrote:
> Don't open the device, if you don't want events from it. Really.
There are existing applications which are doing it. This advice is good
but not for past.
> I assume the reason behind this is that you don't know how to make
> your
On Monday 02 January 2017 17:44:38 David Herrmann wrote:
> Don't open the device, if you don't want events from it. Really.
There are existing applications which are doing it. This advice is good
but not for past.
> I assume the reason behind this is that you don't know how to make
> your
On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
> On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
> > This patch allows user to disable events from any input device so
> > events
> > would not be delivered to userspace.
> >
> > Currently there is no way to disable particular input
On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
> On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
> > This patch allows user to disable events from any input device so
> > events
> > would not be delivered to userspace.
> >
> > Currently there is no way to disable particular input
Hi
On Sun, Dec 25, 2016 at 11:04 AM, Pali Rohár wrote:
> This patch allows user to disable events from any input device so events
> would not be delivered to userspace.
>
> Currently there is no way to disable particular input device by kernel.
> User for different reasons
Hi
On Sun, Dec 25, 2016 at 11:04 AM, Pali Rohár wrote:
> This patch allows user to disable events from any input device so events
> would not be delivered to userspace.
>
> Currently there is no way to disable particular input device by kernel.
> User for different reasons would need it for
On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
> This patch allows user to disable events from any input device so
> events
> would not be delivered to userspace.
>
> Currently there is no way to disable particular input device by
> kernel.
> User for different reasons would need it for
On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
> This patch allows user to disable events from any input device so
> events
> would not be delivered to userspace.
>
> Currently there is no way to disable particular input device by
> kernel.
> User for different reasons would need it for
This patch allows user to disable events from any input device so events
would not be delivered to userspace.
Currently there is no way to disable particular input device by kernel.
User for different reasons would need it for integrated PS/2 keyboard or
touchpad in notebook or touchscreen on
This patch allows user to disable events from any input device so events
would not be delivered to userspace.
Currently there is no way to disable particular input device by kernel.
User for different reasons would need it for integrated PS/2 keyboard or
touchpad in notebook or touchscreen on
40 matches
Mail list logo