xf86-input-synaptics

Peter Hutterer peter.hutterer at who-t.net
Thu May 5 18:04:02 PDT 2011


On Fri, May 06, 2011 at 01:45:18AM +0100, Daniel Stone wrote:
> On Fri, May 06, 2011 at 10:23:48AM +1000, Peter Hutterer wrote:
> > On Fri, May 06, 2011 at 01:06:41AM +0100, Daniel Stone wrote:
> > > On Fri, May 06, 2011 at 09:16:38AM +1000, Peter Hutterer wrote:
> > > > On Thu, May 05, 2011 at 09:35:52AM +0200, Cedric Sodhi wrote:
> > > > > 2.) Would you consider including an option which turns the touchpad off
> > > > > on keyboard (or other) input into the driver - so that ones doesnt
> > > > > requie a helper program for that?
> > > > 
> > > > no, the driver doesn't know when keyboard input is made. and given that any
> > > > such option will soon want about 15 configuration options, it's better to
> > > > keep it in a client program.
> > > 
> > > Eh, it's actually easily doable; just have a per-device property for the
> > > time in millis to ignore all input for after a keyboard event, and do it
> > > all in DIX if that property is ever set on a device.
> > > 
> > > That way you can still have the clients in control, but you don't have
> > > to rely on an external daemon constantly enabling and disabling your
> > > touchpad.
> > 
> > do you want to enable/disable based on modifiers too?
> 
> No.  Why would you?
> 
> > only modifiers, but combos as well (ctrl+c, ctrl+v)?
> 
> As above.

yes. that's actually one of the rather important features. People get
annoyed if they can't use their mouse cursor while holding Ctrl down, or
just after ctrl+rc.

but then again, what is a modifier, what if the modifier is already in use
(or not in use) by a client library? IIRC gtk has a concept of "consumed
modifiers", so some modifiers may not qualify to disable the touchpad.

long story short, we should look at making it easier and less expensive for
a client to monitor keyboards and toggle functionality in other devices.

Cheers,
  Peter

> > do you want to only disable tapping/scrolling, but not movement?
> 
> No.
> 
> > seriously, the options will just pile up, requiring configuration, etc. and
> > the last thing we need is more config options and properties.
> 
> I agree, but we don't have to add them.

 


More information about the xorg-devel mailing list