Hi,
On 10/06/2014 09:44 PM, Bill Spitzak wrote:
On 10/06/2014 05:59 AM, Peter Hutterer wrote:
FORCE_ENABLED - Bypass anything that makes the device stop reporting events.
why would you want that setting? if it's disabled when it shouldn't be then
this is a bug we need to fix.
It is what
On 10/07/2014 01:46 AM, Hans de Goede wrote:
More over, in the future we may get disabled_on_lid_close and
disabled_on_tablet_mode,
etc. The idea being that these are flags which can be or-ed together (using them
together with the unconditional disabled / enabled flags will lead to an EINVAL
On Tue, Sep 30, 2014 at 11:36:30AM -0700, Bill Spitzak wrote:
On 09/11/2014 07:34 AM, Bastien Nocera wrote:
I don't like the Smart disable as a name because the consumer of the
API might only see one device for both the trackpoint and the touchpad
in which case you want to disable
On 10/06/2014 05:59 AM, Peter Hutterer wrote:
FORCE_ENABLED - Bypass anything that makes the device stop reporting events.
why would you want that setting? if it's disabled when it shouldn't be then
this is a bug we need to fix.
It is what you are calling enabled.
My complaint is that the
On Thu, 2014-08-21 at 16:18 +1000, Peter Hutterer wrote:
replying to myself, now that I've had a bit of a think about this all.
On Wed, Aug 20, 2014 at 01:18:48PM +1000, Peter Hutterer wrote:
This patchset adds two new API hooks, libinput_device_suspend() and
libinput_device_resume() which
On 09/11/2014 07:34 AM, Bastien Nocera wrote:
I don't like the Smart disable as a name because the consumer of the
API might only see one device for both the trackpoint and the touchpad
in which case you want to disable one-half of it. Or the trackpoint and
touchpad are independent but the
Hi,
On 09/15/2014 07:39 AM, Peter Hutterer wrote:
On Thu, Sep 11, 2014 at 04:34:48PM +0200, Bastien Nocera wrote:
On Thu, 2014-08-21 at 16:18 +1000, Peter Hutterer wrote:
replying to myself, now that I've had a bit of a think about this all.
On Wed, Aug 20, 2014 at 01:18:48PM +1000, Peter
On Thu, Sep 11, 2014 at 04:34:48PM +0200, Bastien Nocera wrote:
On Thu, 2014-08-21 at 16:18 +1000, Peter Hutterer wrote:
replying to myself, now that I've had a bit of a think about this all.
On Wed, Aug 20, 2014 at 01:18:48PM +1000, Peter Hutterer wrote:
This patchset adds two new API
On 08/24/2014 05:44 PM, Peter Hutterer wrote:
this is *not* about palm detection. palm detection is already always enabled
where possible and with the parameters sensible for that specific touchpad.
This option is for the optional disabling of the touchpad when an external
mouse is connected.
On Mon, Aug 25, 2014 at 10:23:09AM -0700, Bill Spitzak wrote:
On 08/24/2014 05:44 PM, Peter Hutterer wrote:
this is *not* about palm detection. palm detection is already always enabled
where possible and with the parameters sensible for that specific touchpad.
This option is for the
On Fri, Aug 22, 2014 at 06:50:04PM -0700, Bill Spitzak wrote:
On 08/22/2014 06:16 PM, Peter Hutterer wrote:
My main point is I don't think you need to distinguish enabled from
smart enabled. The smartness is in the device driver and could be
considered part of how it generates events,
I was imagining a trackpad that is not smart and somebody wants to
define a global hotkey to turn it off because they keep getting unwanted
events. The disable state would allow this to be done without rewriting
the trackpad driver.
My main point is I don't think you need to distinguish
On 23/08/2014 06:03 , Bill Spitzak wrote:
I was imagining a trackpad that is not smart and somebody wants to
define a global hotkey to turn it off because they keep getting unwanted
events. The disable state would allow this to be done without rewriting
the trackpad driver.
My main point is I
On 08/22/2014 06:16 PM, Peter Hutterer wrote:
My main point is I don't think you need to distinguish enabled from
smart enabled. The smartness is in the device driver and could be
considered part of how it generates events, and there should be no
reason to turn it off.
only if our palm
On Thu, Aug 21, 2014 at 04:18:41PM +1000, Peter Hutterer wrote:
replying to myself, now that I've had a bit of a think about this all.
On Wed, Aug 20, 2014 at 01:18:48PM +1000, Peter Hutterer wrote:
This patchset adds two new API hooks, libinput_device_suspend() and
On Thu, Aug 21, 2014 at 10:16:49PM +0200, Jonas Ådahl wrote:
On Thu, Aug 21, 2014 at 04:18:41PM +1000, Peter Hutterer wrote:
replying to myself, now that I've had a bit of a think about this all.
On Wed, Aug 20, 2014 at 01:18:48PM +1000, Peter Hutterer wrote:
This patchset adds two new
Seems to me you only need two states: what you call disabled and what
you are calling smart disable.
The fully disabled is so a button the hardware does not know about can
disable the device. Or a wayland compositor could use a mouse being
added to disable the device.
But the smart disable
On Thu, Aug 21, 2014 at 06:35:57PM -0700, Bill Spitzak wrote:
Seems to me you only need two states: what you call disabled and what you
are calling smart disable.
The fully disabled is so a button the hardware does not know about can
disable the device. Or a wayland compositor could use a
18 matches
Mail list logo
