At Wed, 16 Dec 2009 09:24:45 -0800,
Dmitry Torokhov wrote:

On Wed, Dec 16, 2009 at 10:17:39AM +0100, Takashi Iwai wrote:

quoted

At Wed, 16 Dec 2009 00:23:16 -0800,
Dmitry Torokhov wrote:

quoted

On Wed, Dec 16, 2009 at 08:14:15AM +0100, Takashi Iwai wrote:

quoted

At Tue, 15 Dec 2009 22:56:53 -0800,
Dmitry Torokhov wrote:

quoted

On Wed, Dec 16, 2009 at 07:50:54AM +0100, Takashi Iwai wrote:

quoted

At Tue, 15 Dec 2009 18:59:34 -0800,
Dmitry Torokhov wrote:

quoted

On Tue, Dec 15, 2009 at 06:05:06PM -0700, Alex Chiang wrote:

quoted

* Dmitry Torokhov [off-list ref]:

quoted

The updated patch is below.

-- 
Dmitry

Should I test this one or wait one more iteration to address
Takashi's last comments?

Actually I think we took the wrong direction with the original patch and
we should do what other buttonless devices (bcm5974) do: report touchpad
click as left button and have Synaptics X driver provide enhanced
support. This way we can have both modes (ClickZones and ClickButtons)
and users will get to chose (provided that someone takes time to add
that support to Synaptics driver of course ;) ).

My concern is, still, how would you identify this device.  Will you
extend also some ioctls to expose caps and extcaps?  Otherwise it's
difficult to identify this device automatically from the user-space.

No.. Synaptics without right button == ClickPad.

So, is there only Clickpad device that has a single button?
No other option?

I have not seen any other Synaptics devices using less than 2 buttons.

quoted

quoted

quoted

The user-space can know that it's button-less, yes.  But, how can it
know whether the device should be emulated via ClickZone?
We can use a driver option to x11 synaptics driver for that, as I
already sent you another patch.  However, the driver option is
nowadays not preferred because xorg.conf is being dead on new
systems...

Driver still takes options, from UDEV/HAL. We could pick one behavior
by default and ovverride, by box vendor/model (DMI).

quoted

Or maybe HAL (or whatever upcoming one) can check the vendor/product
id of the machine (not the device) to provide the information.  OTOH
this will also need frequent updates.

Hopefully vendors won;t be flip/flopping between ClickZone and
ClickButtons too much. Still option is better than hardcoding ClickZone
for everyone.

Yeah, I agree that hard-coding isn't good, and that's why I first
posted separated patches.  OTOH, the kernel-side hack makes the device
working *as is* even without changing anything else.

For "ClickZone" - yes, but not all users would want this I guess and not
all laptops will have that zone marked. Pushing it off to userspace
gives more flexibility, including the ability to change zone size, etc.

As mentioned, I agree basically for the user-space implementation for
a long term solution.  My point is that the kernel hack can be
regarded as a quick hack for a short term while you have no patch yet
for the user-space driver.  It'll take time until the user-space
update will be deployed in many distros while people tend to update
only the kernel.

I strongly disagree here. The fact that some users are more likely to
update kernel than userspace bits is immaterial, besides such users can
easily patch their kernels with out-of-tree patches. Additionally kernel
patch would prevent writing proper userspace support because userspace
will not be able to reconstruct full device state (you are filtering out
some events).

Dmitry, as I clearly wrote a couple of times, I *DO* agree with the
user-space solution.  But you have no that solution yet ready, right?
That's why I mentioned about the kernel patch, for a poor man who
can't use the device properly yet.  If you can get things ready for
use, there can't be any complain.

So, honestly, I don't care which approach you take.  But I just hope
it'll be finished quickly enough :)


thanks,

Takashi