* Proposal for synaptics driver
@ 2010-10-12 16:23 Chase Douglas
2010-10-12 17:58 ` Henrik Rydberg
2010-10-12 18:41 ` Chris Bagwell
0 siblings, 2 replies; 8+ messages in thread
From: Chase Douglas @ 2010-10-12 16:23 UTC (permalink / raw)
To: Dmitry Torokhov, Chris Bagwell, Henrik Rydberg, Takashi Iwai,
Peter Hutterer <peter.hutterer@
Cc: linux-input, linux-kernel
Hi all,
There's been many patches and discussions on the synaptics MT work, so I
wanted to gather thoughts into one thread to push things forward.
First, I want to note something that I think has been overlooked. We've
been talking about "ClickPad" devices quite a bit. One can find the
product page for these devices at:
http://www.synaptics.com/solutions/products/clickpad
As a brief overview, ClickPads are an MT surface where the entire
surface clicks. The click may be uniform over the touchpad, or it may be
hinged on one of the edges. It appears that Takashi has figured out the
appropriate bits in the extended capabilities flags to recognized a
ClickPad. I can't confirm this, but it sounds like the device emits a
middle mouse button click when the touchpad is depressed.
Here's the confusing part: Synaptics has a different series of touchpads
where only certain regions of the touchpad click. This is the case on my
Dell Mini 1012. Unfortunately, I can't find any documentation for these
touchpads on Synaptics' website. As another brief overview, my touchpad
has two buttons integrated into the bottom ~20% of the touchpad. The
left half of the button area clicks separately from the right half, and
the device emits left and right buttons as appropriate. The rest of the
touchpad is stationary and does not click. If no one has a better name
for these touchpads, I'll refer to them as "integrated buttons"
touchpads. Also unfortunately, I don't know which cap bits inform us of
an integrated buttons touchpad, though I have suspicions it's bit
0x200000 of the 0c extended caps mask.
Now onto implementation decisions. I feel that a kernel driver should
provide a usable mouse without needing an X input module. There are
projects like Wayland that don't use X, and I think people use gpm for
consoles still. My definition of a usable mouse is single touch and left
click support (including click and drag using a physical button).
To answer another recurring question throughout the thread, other MT
drivers send both ABS_MT_* and regular ABS_* events. One of the MT
touches is assigned for single touch emulation at any given time. This
supports legacy user space software that expects ST events while
allowing for MT events to be used by more advanced software. I think we
should do the same for Synaptics, and we should track the ST emulation
touch as Henrik suggested.
For ClickPad devices, my feeling is that we should translate middle
button clicks to left button clicks in the kernel, and MT+ST emulation
should be performed. Middle and right click functionality may be
provided for in userspace, like in xf86-input-synaptics or through a
gesture stack. I think this level of support meets my personal criteria
for kernel level functionality specified above.
Integrated buttons devices pose more of a challenge due to the need to
properly support click and drag. Lets first assume that we can detect
such a touchpad and determine the button area (I'll revisit this later).
I think we should disable single touch support over the buttons due to
the following scenario:
User positions cursor over button on screen, attempts to click physical
touchpad button, cursor moves because of motion on touchpad when user
depresses button.
However, we should support MT over the entire touchpad surface. Perhaps
proper filtering and such could make the above scenario work better, and
an advanced user space software, like xf86-input-synaptics, could listen
to the MT events to get the data if it wants.
Integrated buttons have ST emulation support, but only over the
non-button area of the touchpad. If a touch moves over the button area,
it disappears as far as ST-only aware software is concerned. ST
emulation does not switch to another touch because that would look like
a dragged touch. Since a touch beginning over the button area is never
sent through ST emulation, click and drag will always work no matter
which touch goes down first.
Now the bit about integrated button touchpad detection. First, I would
be interested in learning if anyone can disprove bit 0x200000 of the 0c
extended caps flags means integrated buttons. I wonder if we shouldn't
solicit for caps bits of various devices too? I'd be happy to look into
setting up a web survey form if people think this would be useful.
Otherwise, should we try using that bit to see if it works for people or
causes regressions? If that bit isn't correct, should we make it a
module parameter to enable integrated button functionality? What about
button area size? Should we assume it's the same across all such
touchpads?
I would argue that if we can't detect integrated buttons touchpads we
should have a module parameter. I believe we can use udev to specify
module parameter quirks for machine types that are known to have
integrated buttons. Until we hear of regressions, I would assume the
same button area across all such devices.
I'd like to reach some sort of consensus before we proceed with more
patches, otherwise things will just end up confusing :). I think what
I've outlined above should be reasonably easy to implement, the hard
part is just agreeing on what is best.
Thanks,
-- Chase
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Proposal for synaptics driver
2010-10-12 16:23 Proposal for synaptics driver Chase Douglas
@ 2010-10-12 17:58 ` Henrik Rydberg
2010-10-12 19:26 ` Chase Douglas
2010-10-12 18:41 ` Chris Bagwell
1 sibling, 1 reply; 8+ messages in thread
From: Henrik Rydberg @ 2010-10-12 17:58 UTC (permalink / raw)
To: Chase Douglas
Cc: Dmitry Torokhov, Chris Bagwell, Takashi Iwai, Peter Hutterer,
linux-input, linux-kernel
On 10/12/2010 06:23 PM, Chase Douglas wrote:
[...]
> The rest of the
> touchpad is stationary and does not click. If no one has a better name
> for these touchpads, I'll refer to them as "integrated buttons"
> touchpads.
The name "integrated button" is the term in use for the later Macbook models,
where there is a button that clicks anywhere on the pad.
[...]
> My definition of a usable mouse is single touch and left
> click support (including click and drag using a physical button).
This has been stated several times already in related threads.
[...]
> For ClickPad devices, my feeling is that we should translate middle
> button clicks to left button clicks in the kernel, and MT+ST emulation
> should be performed. Middle and right click functionality may be
> provided for in userspace,
Having the physical click map to BTN_LEFT, regardless of where on the pad, and
flagging the presence of an integrated button via the version field in the
device id, would be consistent with existing drivers.
[...]
> I think we should disable single touch support over the buttons due to
> the following scenario:
>
> User positions cursor over button on screen, attempts to click physical
> touchpad button, cursor moves because of motion on touchpad when user
> depresses button.
The location and number of buttons could be freely mappable in userspace, so I
think we want to put minimum energy into the emulation part, considering it is
reworked in userspace anyways.
[...]
> Now the bit about integrated button touchpad detection. First, I would
> be interested in learning if anyone can disprove bit 0x200000 of the 0c
> extended caps flags means integrated buttons.
I think the easiest way to learn this is to produce a dkms package for people to
test.
Henrik
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Proposal for synaptics driver
2010-10-12 17:58 ` Henrik Rydberg
@ 2010-10-12 19:26 ` Chase Douglas
0 siblings, 0 replies; 8+ messages in thread
From: Chase Douglas @ 2010-10-12 19:26 UTC (permalink / raw)
To: Henrik Rydberg
Cc: Dmitry Torokhov, Chris Bagwell, Takashi Iwai, Peter Hutterer,
linux-input, linux-kernel
On Tue, 2010-10-12 at 19:58 +0200, Henrik Rydberg wrote:
> On 10/12/2010 06:23 PM, Chase Douglas wrote:
> [...]
>
> > The rest of the
> > touchpad is stationary and does not click. If no one has a better name
> > for these touchpads, I'll refer to them as "integrated buttons"
> > touchpads.
>
>
> The name "integrated button" is the term in use for the later Macbook models,
> where there is a button that clicks anywhere on the pad.
Ok, that sounds like the Synaptics ClickPad. An unfortunate name
clash :). How about "embedded buttons" touchpads?
> [...]
>
> > Now the bit about integrated button touchpad detection. First, I would
> > be interested in learning if anyone can disprove bit 0x200000 of the 0c
> > extended caps flags means integrated buttons.
>
>
> I think the easiest way to learn this is to produce a dkms package for people to
> test.
Good idea, I'll make a dkms package when I've got some patches to test.
Thanks,
-- Chase
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Proposal for synaptics driver
2010-10-12 16:23 Proposal for synaptics driver Chase Douglas
2010-10-12 17:58 ` Henrik Rydberg
@ 2010-10-12 18:41 ` Chris Bagwell
2010-10-12 20:11 ` Chase Douglas
1 sibling, 1 reply; 8+ messages in thread
From: Chris Bagwell @ 2010-10-12 18:41 UTC (permalink / raw)
To: Chase Douglas
Cc: Dmitry Torokhov, Henrik Rydberg, Takashi Iwai, Peter Hutterer,
linux-input, linux-kernel
On Tue, Oct 12, 2010 at 11:23 AM, Chase Douglas
<chase.douglas@canonical.com> wrote:
> Hi all,
>
> There's been many patches and discussions on the synaptics MT work, so I
> wanted to gather thoughts into one thread to push things forward.
>
> First, I want to note something that I think has been overlooked. We've
> been talking about "ClickPad" devices quite a bit. One can find the
> product page for these devices at:
>
> http://www.synaptics.com/solutions/products/clickpad
>
> As a brief overview, ClickPads are an MT surface where the entire
> surface clicks. The click may be uniform over the touchpad, or it may be
> hinged on one of the edges. It appears that Takashi has figured out the
> appropriate bits in the extended capabilities flags to recognized a
> ClickPad. I can't confirm this, but it sounds like the device emits a
> middle mouse button click when the touchpad is depressed.
>
> Here's the confusing part: Synaptics has a different series of touchpads
> where only certain regions of the touchpad click. This is the case on my
> Dell Mini 1012. Unfortunately, I can't find any documentation for these
> touchpads on Synaptics' website. As another brief overview, my touchpad
> has two buttons integrated into the bottom ~20% of the touchpad. The
> left half of the button area clicks separately from the right half, and
> the device emits left and right buttons as appropriate. The rest of the
> touchpad is stationary and does not click. If no one has a better name
> for these touchpads, I'll refer to them as "integrated buttons"
> touchpads. Also unfortunately, I don't know which cap bits inform us of
> an integrated buttons touchpad, though I have suspicions it's bit
> 0x200000 of the 0c extended caps mask.
Ahh, that clears some things up to me. Based on Takashi's
xf86-input-synaptic patches, it seems the click area is still in this
~20% range even for clickpads. It sounds like the main difference
between clickpad's and "integrated button" touchpads is clickpads have
a way of reporting X/Y events in that click area *without* declaring
button press. If one really wanted to, this same clickpad behavior
could be emulated based on pressure but thats probably best for
userspace. BTW, is there any pressure thresholds for your touchpad?
>
> Now onto implementation decisions. I feel that a kernel driver should
> provide a usable mouse without needing an X input module. There are
> projects like Wayland that don't use X, and I think people use gpm for
> consoles still. My definition of a usable mouse is single touch and left
> click support (including click and drag using a physical button).
>
> To answer another recurring question throughout the thread, other MT
> drivers send both ABS_MT_* and regular ABS_* events. One of the MT
> touches is assigned for single touch emulation at any given time. This
> supports legacy user space software that expects ST events while
> allowing for MT events to be used by more advanced software. I think we
> should do the same for Synaptics, and we should track the ST emulation
> touch as Henrik suggested.
I haven't had time to review the code Henrik pointed to and don't
think exact behavior was spelled out in thread. Since it applies to
my touchpad's, I'd like to state it briefly so we know how this rule
will be bent in later part of email.
I believe basic intent is to support ST emulation by continuing to
report the same touch for life of touch and if its released first the
emulation will revert to remaining tracked touch and advertise this
transition using BTN_TOOL_DOUBLETAP going from 1->0.
>
> For ClickPad devices, my feeling is that we should translate middle
> button clicks to left button clicks in the kernel, and MT+ST emulation
> should be performed. Middle and right click functionality may be
> provided for in userspace, like in xf86-input-synaptics or through a
> gesture stack. I think this level of support meets my personal criteria
> for kernel level functionality specified above.
Agree. I would consider click and drag as optional with ST emulation
but hopefully we can get it working with some thought.
>
> Integrated buttons devices pose more of a challenge due to the need to
> properly support click and drag. Lets first assume that we can detect
> such a touchpad and determine the button area (I'll revisit this later).
> I think we should disable single touch support over the buttons due to
> the following scenario:
>
> User positions cursor over button on screen, attempts to click physical
> touchpad button, cursor moves because of motion on touchpad when user
> depresses button.
I think for this exact scenario its probably not needed but your in
best position to say. I can do a button press-like touch on my
touchpad today with no cursor movement though.
Here is a close version of filtering ST when in click area that may or
may not be better option. We could instead modify rule to track 1st
touch to track 1st touch unless its in click area and then prefer
second touch instead.
Let me try to convince myself that we won't see cursor jumps in X.
1st touch in click area:
BTN_LEFT=1/BTN_TOUCH=1/ABS_X=1st_finger/ABS_Y=1st_finger. 2nd touch
in drag area: BTN_TOOL_DOUBLETAP=1/ABS_X=2nd_finger/ABS_Y=2nd_finger.
Release 2nd finger:
BTN_TOOL_DOUBLETAP=0/ABS_X=1st_finger/ABS_Y=1st_finger.
xf86-input-synaptics can handle those transitions without jumping.
Maybe not gpm or similar but should be small fixes to applications.
This approach should allow click and drag to work and also allow ST
only applications to convert BTN_LEFT into left/middle/right as long
as it knows its an "integrated button" or "clickpad" touchpad.
BTW, I think both mouse movement issue and click and drag issue
applies to clickpad as well and so can use same decisions for it.
>
> However, we should support MT over the entire touchpad surface. Perhaps
> proper filtering and such could make the above scenario work better, and
> an advanced user space software, like xf86-input-synaptics, could listen
> to the MT events to get the data if it wants.
>
> Integrated buttons have ST emulation support, but only over the
> non-button area of the touchpad. If a touch moves over the button area,
> it disappears as far as ST-only aware software is concerned. ST
> emulation does not switch to another touch because that would look like
> a dragged touch. Since a touch beginning over the button area is never
> sent through ST emulation, click and drag will always work no matter
> which touch goes down first.
Do you know if hardware is doing any filtering? For example, if you
move 1 finger from middle to click area does it do simple thing and
start reporting button press? If it is filtering then that may change
the story a little.
I think both filtering approach and "prefer non-click touch" approach
allow click-and-drag. If you do something like 2 finger touch in
center and move tracked finger into click area then it would need to
start reporting other touch and turn into a click-and-drag operation.
This ST tracking switch shouldn't seem different to user space then
case of user releasing tracked finger and moving to click area I
think. Since BTN_TOOL_DOUBLETAP will go from 1 to 0 in both these
cases, user space has something to understand tracking switch.
Chris
>
> Now the bit about integrated button touchpad detection. First, I would
> be interested in learning if anyone can disprove bit 0x200000 of the 0c
> extended caps flags means integrated buttons. I wonder if we shouldn't
> solicit for caps bits of various devices too? I'd be happy to look into
> setting up a web survey form if people think this would be useful.
> Otherwise, should we try using that bit to see if it works for people or
> causes regressions? If that bit isn't correct, should we make it a
> module parameter to enable integrated button functionality? What about
> button area size? Should we assume it's the same across all such
> touchpads?
>
> I would argue that if we can't detect integrated buttons touchpads we
> should have a module parameter. I believe we can use udev to specify
> module parameter quirks for machine types that are known to have
> integrated buttons. Until we hear of regressions, I would assume the
> same button area across all such devices.
>
> I'd like to reach some sort of consensus before we proceed with more
> patches, otherwise things will just end up confusing :). I think what
> I've outlined above should be reasonably easy to implement, the hard
> part is just agreeing on what is best.
>
> Thanks,
>
> -- Chase
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Proposal for synaptics driver
2010-10-12 18:41 ` Chris Bagwell
@ 2010-10-12 20:11 ` Chase Douglas
2010-10-12 20:23 ` Takashi Iwai
2010-10-12 21:11 ` Chris Bagwell
0 siblings, 2 replies; 8+ messages in thread
From: Chase Douglas @ 2010-10-12 20:11 UTC (permalink / raw)
To: Chris Bagwell
Cc: Dmitry Torokhov, Henrik Rydberg, Takashi Iwai, Peter Hutterer,
linux-input, linux-kernel
On Tue, 2010-10-12 at 13:41 -0500, Chris Bagwell wrote:
> On Tue, Oct 12, 2010 at 11:23 AM, Chase Douglas
> <chase.douglas@canonical.com> wrote:
> > Hi all,
> >
> > There's been many patches and discussions on the synaptics MT work, so I
> > wanted to gather thoughts into one thread to push things forward.
> >
> > First, I want to note something that I think has been overlooked. We've
> > been talking about "ClickPad" devices quite a bit. One can find the
> > product page for these devices at:
> >
> > http://www.synaptics.com/solutions/products/clickpad
> >
> > As a brief overview, ClickPads are an MT surface where the entire
> > surface clicks. The click may be uniform over the touchpad, or it may be
> > hinged on one of the edges. It appears that Takashi has figured out the
> > appropriate bits in the extended capabilities flags to recognized a
> > ClickPad. I can't confirm this, but it sounds like the device emits a
> > middle mouse button click when the touchpad is depressed.
> >
> > Here's the confusing part: Synaptics has a different series of touchpads
> > where only certain regions of the touchpad click. This is the case on my
> > Dell Mini 1012. Unfortunately, I can't find any documentation for these
> > touchpads on Synaptics' website. As another brief overview, my touchpad
> > has two buttons integrated into the bottom ~20% of the touchpad. The
> > left half of the button area clicks separately from the right half, and
> > the device emits left and right buttons as appropriate. The rest of the
> > touchpad is stationary and does not click. If no one has a better name
> > for these touchpads, I'll refer to them as "integrated buttons"
> > touchpads. Also unfortunately, I don't know which cap bits inform us of
> > an integrated buttons touchpad, though I have suspicions it's bit
> > 0x200000 of the 0c extended caps mask.
>
> Ahh, that clears some things up to me. Based on Takashi's
> xf86-input-synaptic patches, it seems the click area is still in this
> ~20% range even for clickpads.
Hmm, based on the synaptics product page I figured the click area of a
ClickPad would be the entire surface. Takashi, do you have any input
here? Maybe the ClickPad devices people have been using is of the hinged
type, where it's easier to click on the bottom of the pad instead of the
top?
> It sounds like the main difference
> between clickpad's and "integrated button" touchpads is clickpads have
> a way of reporting X/Y events in that click area *without* declaring
> button press.
On my touchpad, the "embedded buttons" (what I'm calling "integrated
buttons" now due to the name clash with the bcm5974 semantics) are touch
sensitive, so the device still reports X/Y events no matter whether the
button is depressed or not..
> If one really wanted to, this same clickpad behavior
> could be emulated based on pressure but thats probably best for
> userspace. BTW, is there any pressure thresholds for your touchpad?
What do you mean by pressure thresholds? My device does report pressure.
> > Now onto implementation decisions. I feel that a kernel driver should
> > provide a usable mouse without needing an X input module. There are
> > projects like Wayland that don't use X, and I think people use gpm for
> > consoles still. My definition of a usable mouse is single touch and left
> > click support (including click and drag using a physical button).
> >
> > To answer another recurring question throughout the thread, other MT
> > drivers send both ABS_MT_* and regular ABS_* events. One of the MT
> > touches is assigned for single touch emulation at any given time. This
> > supports legacy user space software that expects ST events while
> > allowing for MT events to be used by more advanced software. I think we
> > should do the same for Synaptics, and we should track the ST emulation
> > touch as Henrik suggested.
>
> I haven't had time to review the code Henrik pointed to and don't
> think exact behavior was spelled out in thread. Since it applies to
> my touchpad's, I'd like to state it briefly so we know how this rule
> will be bent in later part of email.
>
> I believe basic intent is to support ST emulation by continuing to
> report the same touch for life of touch and if its released first the
> emulation will revert to remaining tracked touch and advertise this
> transition using BTN_TOOL_DOUBLETAP going from 1->0.
The way I implemented this in the hid-magicmouse driver for the Magic
Trackpad is that the first finger touching the surface is the only ST
emulated touch until all fingers are lifted off the device
simultaneously. The following events illustrate the pattern:
1. First finger goes down, gets ST emulation
2. Second finger goes down
3. First finger goes up, no ST emulation
4. Third finger does down, still no ST emulation
5. All fingers go up
6. First finger goes down, gets ST emulation
etc.
I think this would work fine here as well, except for the scenario where
two fingers start in the non-button area, and one moves to a button area
and presses. The second finger would not control ST emulation, so no
drags would be performed. I don't see this as an often seen scenario
though.
More likely, a user would start with one finger over the button and the
other in the non-button area. No matter which order of touch is
performed, the above algorithm would work fine because the touch over
the button area isn't figured into the ST emulation.
As for multifinger support (BTN_TOOL_DOUBLETAP, etc.), I was thinking
that should be based on all touches whether they occur over a button
area or not. However, if anyone has a convincing argument against this
I'm happy to reconsider :).
BTW, ST emulation algorithms haven't been standardized. Some drivers can
begin ST emulation on new touches while other touches are still present.
> > For ClickPad devices, my feeling is that we should translate middle
> > button clicks to left button clicks in the kernel, and MT+ST emulation
> > should be performed. Middle and right click functionality may be
> > provided for in userspace, like in xf86-input-synaptics or through a
> > gesture stack. I think this level of support meets my personal criteria
> > for kernel level functionality specified above.
>
> Agree. I would consider click and drag as optional with ST emulation
> but hopefully we can get it working with some thought.
What's the issue with ClickPad click and drag? I was thinking it should
just work. The user touches the pad with one finger, depressing the
ClickPad button. Now the left button depress event is emitted, and the
user drags the finger.
> > Integrated buttons devices pose more of a challenge due to the need to
> > properly support click and drag. Lets first assume that we can detect
> > such a touchpad and determine the button area (I'll revisit this later).
> > I think we should disable single touch support over the buttons due to
> > the following scenario:
> >
> > User positions cursor over button on screen, attempts to click physical
> > touchpad button, cursor moves because of motion on touchpad when user
> > depresses button.
>
> I think for this exact scenario its probably not needed but your in
> best position to say. I can do a button press-like touch on my
> touchpad today with no cursor movement though.
Sadly I can't. I tried it for a few hours, but it just wasn't possible
on my Dell Mini 1012 to click without moving while thinking about
anything else at the same time :).
> Here is a close version of filtering ST when in click area that may or
> may not be better option. We could instead modify rule to track 1st
> touch to track 1st touch unless its in click area and then prefer
> second touch instead.
>
> Let me try to convince myself that we won't see cursor jumps in X.
> 1st touch in click area:
> BTN_LEFT=1/BTN_TOUCH=1/ABS_X=1st_finger/ABS_Y=1st_finger. 2nd touch
> in drag area: BTN_TOOL_DOUBLETAP=1/ABS_X=2nd_finger/ABS_Y=2nd_finger.
> Release 2nd finger:
> BTN_TOOL_DOUBLETAP=0/ABS_X=1st_finger/ABS_Y=1st_finger.
>
> xf86-input-synaptics can handle those transitions without jumping.
> Maybe not gpm or similar but should be small fixes to applications.
I hadn't thought of using BTN_TOOL_* as barriers across which the ST
emulated touch could change. I'm concerned about legacy applications, as
you noted, but if everyone feels this is a better resolution then I'm
fine with it as well. I think it would allow for ST emulation across the
entire touchpad surface of an "embedded buttons" device, until any
buttons are depressed.
As an alternative, we could generate a dummy sequence for the
transition:
First of two fingers goes to button area, then:
BTN_TOUCH 0
SYNC
BTN_TOUCH 1
ABS_X from second finger
ABS_Y from second finger
ABS_PRESSURE from second finger
SYNC
The wrinkle I can envision here is that a quick first finger move from
the non-button area to the button area will look like a tap because the
BTN_TOUCH went down and up in a short period of time.
> This approach should allow click and drag to work and also allow ST
> only applications to convert BTN_LEFT into left/middle/right as long
> as it knows its an "integrated button" or "clickpad" touchpad.
"Embedded button" devices correctly report the appropriate button press
because they have physically distinct buttons. I think this is merely an
issue for ClickPads.
> BTW, I think both mouse movement issue and click and drag issue
> applies to clickpad as well and so can use same decisions for it.
They might be. Once we play with it some we might find this to be the
case.
> > However, we should support MT over the entire touchpad surface. Perhaps
> > proper filtering and such could make the above scenario work better, and
> > an advanced user space software, like xf86-input-synaptics, could listen
> > to the MT events to get the data if it wants.
> >
> > Integrated buttons have ST emulation support, but only over the
> > non-button area of the touchpad. If a touch moves over the button area,
> > it disappears as far as ST-only aware software is concerned. ST
> > emulation does not switch to another touch because that would look like
> > a dragged touch. Since a touch beginning over the button area is never
> > sent through ST emulation, click and drag will always work no matter
> > which touch goes down first.
>
> Do you know if hardware is doing any filtering? For example, if you
> move 1 finger from middle to click area does it do simple thing and
> start reporting button press? If it is filtering then that may change
> the story a little.
I'm not sure I understand the question. On my laptop, it emits the
appropriate button presses when the button is physically depressed. It
also emits X/Y values whether the button is depressed or not. I'm not
sure what filtering you may be referring to.
> I think both filtering approach and "prefer non-click touch" approach
> allow click-and-drag. If you do something like 2 finger touch in
> center and move tracked finger into click area then it would need to
> start reporting other touch and turn into a click-and-drag operation.
> This ST tracking switch shouldn't seem different to user space then
> case of user releasing tracked finger and moving to click area I
> think. Since BTN_TOOL_DOUBLETAP will go from 1 to 0 in both these
> cases, user space has something to understand tracking switch.
I think we're in agreement on everything except for the possibility of
using BTN_TOOL_* to distinguish between ST emulation touch switches. The
BTN_TOOL_* switch could allow full ST emulation over the button area of
an "embedded buttons" trackpad until a button is pressed, but might
slightly break legacy clients like gpm. Again, I'm open to both options,
so if anyone feels particularly strong about this please speak up :).
Thanks for the feedback Chris!
-- Chase
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Proposal for synaptics driver
2010-10-12 20:11 ` Chase Douglas
@ 2010-10-12 20:23 ` Takashi Iwai
2010-10-12 21:11 ` Chris Bagwell
1 sibling, 0 replies; 8+ messages in thread
From: Takashi Iwai @ 2010-10-12 20:23 UTC (permalink / raw)
To: Chase Douglas
Cc: Chris Bagwell, Dmitry Torokhov, Henrik Rydberg, Peter Hutterer,
linux-input, linux-kernel
At Tue, 12 Oct 2010 16:11:36 -0400,
Chase Douglas wrote:
>
> On Tue, 2010-10-12 at 13:41 -0500, Chris Bagwell wrote:
> > On Tue, Oct 12, 2010 at 11:23 AM, Chase Douglas
> > <chase.douglas@canonical.com> wrote:
> > > Hi all,
> > >
> > > There's been many patches and discussions on the synaptics MT work, so I
> > > wanted to gather thoughts into one thread to push things forward.
> > >
> > > First, I want to note something that I think has been overlooked. We've
> > > been talking about "ClickPad" devices quite a bit. One can find the
> > > product page for these devices at:
> > >
> > > http://www.synaptics.com/solutions/products/clickpad
> > >
> > > As a brief overview, ClickPads are an MT surface where the entire
> > > surface clicks. The click may be uniform over the touchpad, or it may be
> > > hinged on one of the edges. It appears that Takashi has figured out the
> > > appropriate bits in the extended capabilities flags to recognized a
> > > ClickPad. I can't confirm this, but it sounds like the device emits a
> > > middle mouse button click when the touchpad is depressed.
> > >
> > > Here's the confusing part: Synaptics has a different series of touchpads
> > > where only certain regions of the touchpad click. This is the case on my
> > > Dell Mini 1012. Unfortunately, I can't find any documentation for these
> > > touchpads on Synaptics' website. As another brief overview, my touchpad
> > > has two buttons integrated into the bottom ~20% of the touchpad. The
> > > left half of the button area clicks separately from the right half, and
> > > the device emits left and right buttons as appropriate. The rest of the
> > > touchpad is stationary and does not click. If no one has a better name
> > > for these touchpads, I'll refer to them as "integrated buttons"
> > > touchpads. Also unfortunately, I don't know which cap bits inform us of
> > > an integrated buttons touchpad, though I have suspicions it's bit
> > > 0x200000 of the 0c extended caps mask.
> >
> > Ahh, that clears some things up to me. Based on Takashi's
> > xf86-input-synaptic patches, it seems the click area is still in this
> > ~20% range even for clickpads.
>
> Hmm, based on the synaptics product page I figured the click area of a
> ClickPad would be the entire surface. Takashi, do you have any input
> here? Maybe the ClickPad devices people have been using is of the hinged
> type, where it's easier to click on the bottom of the pad instead of the
> top?
(Just a few points as I was explicitly asked :)
There are actually two types of Clickpad devices. The "ClickZone" one
has a hinge on the top, thus you can't click at the top, more easily at
the bottom position. More importantly, button areas are drawn on the
touchpad, thus it's supposed to push these areas.
> > It sounds like the main difference
> > between clickpad's and "integrated button" touchpads is clickpads have
> > a way of reporting X/Y events in that click area *without* declaring
> > button press.
>
> On my touchpad, the "embedded buttons" (what I'm calling "integrated
> buttons" now due to the name clash with the bcm5974 semantics) are touch
> sensitive, so the device still reports X/Y events no matter whether the
> button is depressed or not..
Right, it is the merit of clickpad after all: you'll have a larger area
for touching. Thus, sensing in the button area is somewhat a required
feature. So does my patch [PATCH 07/18] Allow touching in clickpad
button area.
(It's late here, and I'll follow up more tomorrow...)
thanks,
Takashi
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Proposal for synaptics driver
2010-10-12 20:11 ` Chase Douglas
2010-10-12 20:23 ` Takashi Iwai
@ 2010-10-12 21:11 ` Chris Bagwell
1 sibling, 0 replies; 8+ messages in thread
From: Chris Bagwell @ 2010-10-12 21:11 UTC (permalink / raw)
To: Chase Douglas
Cc: Dmitry Torokhov, Henrik Rydberg, Takashi Iwai, Peter Hutterer,
linux-input, linux-kernel
On Tue, Oct 12, 2010 at 3:11 PM, Chase Douglas
<chase.douglas@canonical.com> wrote:
> On Tue, 2010-10-12 at 13:41 -0500, Chris Bagwell wrote:
>> On Tue, Oct 12, 2010 at 11:23 AM, Chase Douglas
>> <chase.douglas@canonical.com> wrote:
>> > Hi all,
>> >
>> > There's been many patches and discussions on the synaptics MT work, so I
>> > wanted to gather thoughts into one thread to push things forward.
>> >
>> > First, I want to note something that I think has been overlooked. We've
>> > been talking about "ClickPad" devices quite a bit. One can find the
>> > product page for these devices at:
>> >
>> > http://www.synaptics.com/solutions/products/clickpad
>> >
>> > As a brief overview, ClickPads are an MT surface where the entire
>> > surface clicks. The click may be uniform over the touchpad, or it may be
>> > hinged on one of the edges. It appears that Takashi has figured out the
>> > appropriate bits in the extended capabilities flags to recognized a
>> > ClickPad. I can't confirm this, but it sounds like the device emits a
>> > middle mouse button click when the touchpad is depressed.
>> >
>> > Here's the confusing part: Synaptics has a different series of touchpads
>> > where only certain regions of the touchpad click. This is the case on my
>> > Dell Mini 1012. Unfortunately, I can't find any documentation for these
>> > touchpads on Synaptics' website. As another brief overview, my touchpad
>> > has two buttons integrated into the bottom ~20% of the touchpad. The
>> > left half of the button area clicks separately from the right half, and
>> > the device emits left and right buttons as appropriate. The rest of the
>> > touchpad is stationary and does not click. If no one has a better name
>> > for these touchpads, I'll refer to them as "integrated buttons"
>> > touchpads. Also unfortunately, I don't know which cap bits inform us of
>> > an integrated buttons touchpad, though I have suspicions it's bit
>> > 0x200000 of the 0c extended caps mask.
>>
>> Ahh, that clears some things up to me. Based on Takashi's
>> xf86-input-synaptic patches, it seems the click area is still in this
>> ~20% range even for clickpads.
>
> Hmm, based on the synaptics product page I figured the click area of a
> ClickPad would be the entire surface. Takashi, do you have any input
> here? Maybe the ClickPad devices people have been using is of the hinged
> type, where it's easier to click on the bottom of the pad instead of the
> top?
>
>> It sounds like the main difference
>> between clickpad's and "integrated button" touchpads is clickpads have
>> a way of reporting X/Y events in that click area *without* declaring
>> button press.
>
> On my touchpad, the "embedded buttons" (what I'm calling "integrated
> buttons" now due to the name clash with the bcm5974 semantics) are touch
> sensitive, so the device still reports X/Y events no matter whether the
> button is depressed or not..
>
>> If one really wanted to, this same clickpad behavior
>> could be emulated based on pressure but thats probably best for
>> userspace. BTW, is there any pressure thresholds for your touchpad?
>
> What do you mean by pressure thresholds? My device does report pressure.
OK, that was my confusion. I didn't realize these also had real
buttons and so can also report X/Y in click area without button press.
I was assuming the firmware was detecting button press based on
pressure or finger width and that it needed to go above some very low
threshold before activated. So the parts of my email you weren't
quite sure about are explained to me now by this answer.
[ .. ]
>
>> I think both filtering approach and "prefer non-click touch" approach
>> allow click-and-drag. If you do something like 2 finger touch in
>> center and move tracked finger into click area then it would need to
>> start reporting other touch and turn into a click-and-drag operation.
>> This ST tracking switch shouldn't seem different to user space then
>> case of user releasing tracked finger and moving to click area I
>> think. Since BTN_TOOL_DOUBLETAP will go from 1 to 0 in both these
>> cases, user space has something to understand tracking switch.
>
> I think we're in agreement on everything except for the possibility of
> using BTN_TOOL_* to distinguish between ST emulation touch switches. The
> BTN_TOOL_* switch could allow full ST emulation over the button area of
> an "embedded buttons" trackpad until a button is pressed, but might
> slightly break legacy clients like gpm. Again, I'm open to both options,
> so if anyone feels particularly strong about this please speak up :).
I'm going to go off and also study the hid-magicmouse now and a few
other things to make sure I understand how tracking could be
implemented based on past work.
I do want to point out more that when synaptics hw is not in this new
MT-mode that it is BTN_TOOL_DOUBLETAP that is saving the day for
preventing cursor jumps from 2 finger touches anywhere on touchpad...
not just click areas. The current ABS_X/ABS_Y values do change
fingers they are tracking but it happens to correspond to changes in
finger counts as well.
The story is harder for my touchpad (with external buttons) since it
doesn't support finger count but instead only finger width. I think
this behavior is same for these "embedded button" touchpads, right?
Its harder to inform all applications to treat finger width changes
same as BTN_TOOL_DOUBLETAP transitions to prevent cursor jumps.
I'm hoping my touchpad supports this MT-mode so that we can start
reporting BTN_TOOL_DOUBLETAP which should fix a wider list of apps
from having cursor jumps during tracking changes.
Anyways, since the logic is really needed in user land to work with
certain hardware/kernel releases anyways, it seems fair to elevate it
to a requirement also for MT devices and take advantage of it.
Chris
>
> Thanks for the feedback Chris!
>
> -- Chase
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Proposal for synaptics driver
@ 2010-10-13 3:16 Joey Lee
0 siblings, 0 replies; 8+ messages in thread
From: Joey Lee @ 2010-10-13 3:16 UTC (permalink / raw)
To: chase.douglas
Cc: rydberg, chris, dmitry.torokhov, Michael Chang, tiwai,
linux-input, linux-kernel, peter.hutterer
Add CC. Michael Chang
於 二,2010-10-12 於 16:11 -0400,Chase Douglas 提到:
> On Tue, 2010-10-12 at 13:41 -0500, Chris Bagwell wrote:
> > On Tue, Oct 12, 2010 at 11:23 AM, Chase Douglas
> > <chase.douglas@canonical.com> wrote:
> > > Hi all,
> > >
> > > There's been many patches and discussions on the synaptics MT work, so I
> > > wanted to gather thoughts into one thread to push things forward.
> > >
> > > First, I want to note something that I think has been overlooked. We've
> > > been talking about "ClickPad" devices quite a bit. One can find the
> > > product page for these devices at:
> > >
> > > http://www.synaptics.com/solutions/products/clickpad
> > >
> > > As a brief overview, ClickPads are an MT surface where the entire
> > > surface clicks. The click may be uniform over the touchpad, or it may be
> > > hinged on one of the edges. It appears that Takashi has figured out the
> > > appropriate bits in the extended capabilities flags to recognized a
> > > ClickPad. I can't confirm this, but it sounds like the device emits a
> > > middle mouse button click when the touchpad is depressed.
> > >
> > > Here's the confusing part: Synaptics has a different series of touchpads
> > > where only certain regions of the touchpad click. This is the case on my
> > > Dell Mini 1012. Unfortunately, I can't find any documentation for these
> > > touchpads on Synaptics' website. As another brief overview, my touchpad
> > > has two buttons integrated into the bottom ~20% of the touchpad. The
> > > left half of the button area clicks separately from the right half, and
> > > the device emits left and right buttons as appropriate. The rest of the
> > > touchpad is stationary and does not click. If no one has a better name
> > > for these touchpads, I'll refer to them as "integrated buttons"
> > > touchpads. Also unfortunately, I don't know which cap bits inform us of
> > > an integrated buttons touchpad, though I have suspicions it's bit
> > > 0x200000 of the 0c extended caps mask.
> >
> > Ahh, that clears some things up to me. Based on Takashi's
> > xf86-input-synaptic patches, it seems the click area is still in this
> > ~20% range even for clickpads.
>
> Hmm, based on the synaptics product page I figured the click area of a
> ClickPad would be the entire surface. Takashi, do you have any input
> here? Maybe the ClickPad devices people have been using is of the hinged
> type, where it's easier to click on the bottom of the pad instead of the
> top?
>
> > It sounds like the main difference
> > between clickpad's and "integrated button" touchpads is clickpads have
> > a way of reporting X/Y events in that click area *without* declaring
> > button press.
>
> On my touchpad, the "embedded buttons" (what I'm calling "integrated
> buttons" now due to the name clash with the bcm5974 semantics) are touch
> sensitive, so the device still reports X/Y events no matter whether the
> button is depressed or not..
>
> > If one really wanted to, this same clickpad behavior
> > could be emulated based on pressure but thats probably best for
> > userspace. BTW, is there any pressure thresholds for your touchpad?
>
> What do you mean by pressure thresholds? My device does report pressure.
>
> > > Now onto implementation decisions. I feel that a kernel driver should
> > > provide a usable mouse without needing an X input module. There are
> > > projects like Wayland that don't use X, and I think people use gpm for
> > > consoles still. My definition of a usable mouse is single touch and left
> > > click support (including click and drag using a physical button).
> > >
> > > To answer another recurring question throughout the thread, other MT
> > > drivers send both ABS_MT_* and regular ABS_* events. One of the MT
> > > touches is assigned for single touch emulation at any given time. This
> > > supports legacy user space software that expects ST events while
> > > allowing for MT events to be used by more advanced software. I think we
> > > should do the sam> > > touch as Henrik suggested.
> >
> > I haven't had time to review the code Henrik pointed to and don't
> > think exact behavior was spelled out in thread. Since it applies to
> > my touchpad's, I'd like to state it briefly so we know how this rule
> > will be bent in later part of email.
> >
> > I believe basic intent is to support ST emulation by continuing to
> > report the same touch for life of touch and if its released first the
> > emulation will revert to remaining tracked touch and advertise this
> > transition using BTN_TOOL_DOUBLETAP going from 1->0.
>
> The way I implemented this in the hid-magicmouse driver for the Magic
> Trackpad is that the first finger touching the surface is the only ST
> emulated touch until all fingers are lifted off the device
> simultaneously. The following events illustrate the pattern:
>
> 1. First finger goes down, gets ST emulation
> 2. Second finger goes down
> 3. First finger goes up, no ST emulation
> 4. Third finger does down, still no ST emulation
> 5. All fingers go up
> 6. First finger goes down, gets ST emulation
> etc.
>
> I think this would work fine here as well, except for the scenario where
> two fingers start in the non-button area, and one moves to a button area
> and presses. The second finger would not control ST emulation, so no
> drags would be performed. I don't see this as an often seen scenario
> though.
>
> More likely, a user would start with one finger over the button and the
> other in the non-button area. No matter which order of touch is
> performed, the above algorithm would work fine because the touch over
> the button area isn't figured into the ST emulation.
>
> As for multifinger support (BTN_TOOL_DOUBLETAP, etc.), I was thinking
> that should be based on all touches whether they occur over a button
> area or not. However, if anyone has a convincing argument against this
> I'm happy to reconsider :).
>
> BTW, ST emulation algorithms haven't been standardized. Some drivers can
> begin ST emulation on new touches while other touches are still present.
>
> > > For ClickPad devices, my feeling is that we should translate middle
> > > button clicks to left button clicks in the kernel, and MT+ST emulation
> > > should be performed. Middle and right click functionality may be
> > > provided for in userspace, like in xf86-input-synaptics or through a
> > > gesture stack. I think this level of support meets my personal criteria
> > > for kernel level functionality specified above.
> >
> > Agree. I would consider click and drag as optional with ST emulation
> > but hopefully we can get it working with some thought.
>
> What's the issue with ClickPad click and drag? I was thinking it should
> just work. The user touches the pad with one finger, depressing the
> ClickPad button. Now the left button depress event is emitted, and the
> user drags the finger.
>
> > > Integrated buttons devices pose more of a challenge due to the need to
> > > properly support click and drag. Lets first assume that we can detect
> > > such a touchpad and determine the button area (I'll revisit this later).
> > > I think we should disable single touch support over the buttons due to
> > > the following scenario:
> > >
> > > User positions cursor over button on screen, attempts to click physical
> > > touchpad button, cursor moves because of motion on touchpad when user
> > > depresses button.
> >
> > I think for this exact scenario its probably not needed but your in
> > best position to say. I can do a button press-like touch on my
> > touchpad today with no cursor movement though.
>
> Sadly I can't. I tried it for a few hours, but it just wasn't possible
> on my Dell Mini 1012 to click without moving while thinking about
> anything else at the same time :).
>
> > Here is a close version of filtering ST when in click area that may or
> > may not be better option. We could instead modify rule to track 1st
> > touch to track 1st touch unless its in click area and then prefer
> > > Let me try to convince myself that we won't see cursor jumps in X.
> > 1st touch in click area:
> > BTN_LEFT=1/BTN_TOUCH=1/ABS_X=1st_finger/ABS_Y=1st_finger. 2nd touch
> > in drag area: BTN_TOOL_DOUBLETAP=1/ABS_X=2nd_finger/ABS_Y=2nd_finger.
> > Release 2nd finger:
> > BTN_TOOL_DOUBLETAP=0/ABS_X=1st_finger/ABS_Y=1st_finger.
> >
> > xf86-input-synaptics can handle those transitions without jumping.
> > Maybe not gpm or similar but should be small fixes to applications.
>
> I hadn't thought of using BTN_TOOL_* as barriers across which the ST
> emulated touch could change. I'm concerned about legacy applications, as
> you noted, but if everyone feels this is a better resolution then I'm
> fine with it as well. I think it would allow for ST emulation across the
> entire touchpad surface of an "embedded buttons" device, until any
> buttons are depressed.
>
> As an alternative, we could generate a dummy sequence for the
> transition:
>
> First of two fingers goes to button area, then:
> BTN_TOUCH 0
> SYNC
> BTN_TOUCH 1
> ABS_X from second finger
> ABS_Y from second finger
> ABS_PRESSURE from second finger
> SYNC
>
> The wrinkle I can envision here is that a quick first finger move from
> the non-button area to the button area will look like a tap because the
> BTN_TOUCH went down and up in a short period of time.
>
> > This approach should allow click and drag to work and also allow ST
> > only applications to convert BTN_LEFT into left/middle/right as long
> > as it knows its an "integrated button" or "clickpad" touchpad.
>
> "Embedded button" devices correctly report the appropriate button press
> because they have physically distinct buttons. I think this is merely an
> issue for ClickPads.
>
> > BTW, I think both mouse movement issue and click and drag issue
> > applies to clickpad as well and so can use same decisions for it.
>
> They might be. Once we play with it some we might find this to be the
> case.
>
> > > However, we should support MT over the entire touchpad surface. Perhaps
> > > proper filtering and such could make the above scenario work better, and
> > > an advanced user space software, like xf86-input-synaptics, could listen
> > > to the MT events to get the data if it wants.
> > >
> > > Integrated buttons have ST emulation support, but only over the
> > > non-button area of the touchpad. If a touch moves over the button area,
> > > it disappears as far as ST-only aware software is concerned. ST
> > > emulation does not switch to another touch because that would look like
> > > a dragged touch. Since a touch beginning over the button area is never
> > > sent through ST emulation, click and drag will always work no matter
> > > which touch goes down first.
> >
> > Do you know if hardware is doing any filtering? For example, if you
> > move 1 finger from middle to click area does it do simple thing and
> > start reporting button press? If it is filtering then that may change
> > the story a little.
>
> I'm not sure I understand the question. On my laptop, it emits the
> appropriate button presses when the button is physically depressed. It
> also emits X/Y values whether the button is depressed or not. I'm not
> sure what filtering you may be referring to.
>
> > I think both filtering approach and "prefer non-click touch" approach
> > allow click-and-drag. If you do something like 2 finger touch in
> > center and move tracked finger into click area then it would need to
> > start reporting other touch and turn into a click-and-drag operation.
> > This ST tracking switch shouldn't seem different to user space then
> > case of user releasing tracked finger and moving to click area I
> > think. Since BTN_TOOL_DOUBLETAP will go from 1 to 0 in both these
> > cases, user space has something to understand tracking switch.
>
> I think we're in agreement on everything except for the possibility of
> using BTN_TOOL_* to distinguish between ST emulation touch switches. The
> BTN_TOOL_* switch could allow full ST > an "embedded buttons" trackpad until a button is pressed, but might
> slightly break legacy clients like gpm. Again, I'm open to both options,
> so if anyone feels particularly strong about this please speak up :).
>
> Thanks for the feedback Chris!
>
> -- Chase
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-10-13 3:16 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-10-12 16:23 Proposal for synaptics driver Chase Douglas
2010-10-12 17:58 ` Henrik Rydberg
2010-10-12 19:26 ` Chase Douglas
2010-10-12 18:41 ` Chris Bagwell
2010-10-12 20:11 ` Chase Douglas
2010-10-12 20:23 ` Takashi Iwai
2010-10-12 21:11 ` Chris Bagwell
-- strict thread matches above, loose matches on Subject: below --
2010-10-13 3:16 Joey Lee
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).