xf86-input-synaptics 1.0.99.3

[Colin Guthrie]

'Twas brillig, and Peter Hutterer at 05/03/09 00:24 did gyre and gimble:

> For tapping:
> This is a definitive break to 0.15, with the feature being disabled now by
> default on most touchpads. There's arguments to both sides, one being that
> tapping enabled causes erroneous clicks, especially for those with reduced
> dexteriority. The other argument is of course that it's a feature that makes
> the touchpad attractive. Members from both groups can be quite vocal, so
> either default is wrong in some way.
> 
> I don't care strongly enough either way. Tap has been disabled in the driver
> since September now, so I want to stick with it. Subjectively bad but
> predictable defaults are better than defaults that change every month.

Yes, personally I prefer this as it's not uncommon, even with my awesome 
dexterity, to accidentally start dragging something I didn't meant etc. 
But I'm just one opinion in a sea of complainants ;)

> For scrolling:
> Many devices seem to be going towards multi-touch and for this reason I think
> two-finger scrolling is the better default. That's pretty much the only
> reason. 

Yeah I prefer this too after forcing myself to use it and working 
through a few awkward releases/rcs where the support wasn't perfect. 
Seems good now.

>>   B. Configure things in the FDI file, and patch the Xserver to ignore 
>> synaptics in the same way it currently ignores keyboard and [vm]mouse. 
>> If the user does not want to use hal then they wire it up themselves - 
>> they should be canny enough to work out the configuration needed if they 
>> are configuring their config in this way.
>>
>> That said, I'm looking for the path of least maintenance too. I think B 
>> is the "neater" solution, but only if you see this ultimately going into 
>> the xserver.
>>
>> So, in short WDYT?
> 
> If synclient/gsynaptics are insufficient, I'd patch the driver.
> fdi files as configuration were always frowned upon and were mostly used
> because of a lack of alternatives.

Hmm, strange. I was kinda basing my approach on the comments in the 
Fedora synaptic package's FDI file...

> Patching the server to ignore synaptics xorg.conf devices will not only
> increase maintainance for you (maintaining patches in two different repos,
> different behaviour to other distros)

Well there are not patches to the synaptic driver, just a custom fdi 
file (same as the Fedora synaptics package, but with some defaults set.

For the latter point, yes, perfectly valid, which is why I was asking 
here ;)

> but also create _a lot_ of complaints
> about the xorg.conf devices not working. synaptics is about the only device
> where xorg.conf sections have continued to work through the whole input system
> rework.

Isn't inconcistency worse than breaking this one approach here. At 
present only a subset of input drivers are configurable in xorg.conf and 
others are not. If I have to explain to a user that they cannot set they 
keyboard locale in xorg.conf but they can configure their synaptics 
options, is this not a more confusing response to someone? They feel 
like you just have to "know" in order to know!

This is a genuinely open question by me, I'm not trying to put a 
particular slant on it or push it one way, I'm just a bit confused now 
as to why some drivers work one way and others another.

Perhaps I'm just not seeing the strategy here... what is the intended 
plan moving forward? Push more stuff into hal or less? Or perhaps make 
hal+conf parsing augment each other rather than hal overriding the conf? 
Whatever the plan is, I'd argue consistency should be a key consideration.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]