Re: synaptics touchpad doesn't click

[Takashi Iwai]

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:
> > At Wed, 16 Dec 2009 00:23:16 -0800,
> > Dmitry Torokhov wrote:
> > > 
> > > On Wed, Dec 16, 2009 at 08:14:15AM +0100, Takashi Iwai wrote:
> > > > At Tue, 15 Dec 2009 22:56:53 -0800,
> > > > Dmitry Torokhov wrote:
> > > > > 
> > > > > On Wed, Dec 16, 2009 at 07:50:54AM +0100, Takashi Iwai wrote:
> > > > > > At Tue, 15 Dec 2009 18:59:34 -0800,
> > > > > > Dmitry Torokhov wrote:
> > > > > > > 
> > > > > > > On Tue, Dec 15, 2009 at 06:05:06PM -0700, Alex Chiang wrote:
> > > > > > > > * Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>:
> > > > > > > > >
> > > > > > > > > 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.
> > > 
> > > > > > 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).
> > > > > 
> > > > > > 
> > > > > > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/