Bug 2758

Created attachment 2132 [details] [review]
implementation

Here's an implementation that handles absolute movement events.

It can operate in two modes:

a) touchpad mode. The absolute x- and y-coordinates are compared with previous
values and the difference is reported as relational movements. This is for
touchpads.

b) normal mode. The absolute x- and y-coordinates are reported as absolute
movements. This is for touchscreens.

There's also support for tapping, so that a tap on the touchpad causes a button
click.

way cool, thanks!

component shift

this patch causes segfaults on 6.9 rc1 for me

Created attachment 3354 [details] [review]
pointers w/o BTN_TOOL_FINGER are always touching

I have a USB mouse that reports absolute coordinates.  It's more like a
touchscreen, but it does not report a BTN_TOOL_FINGER.	With the original
implementation, this meant the state was never touching, therefore the input
was ignored.  This is a simple change to fix that.

(In reply to comment #1)
>
> a) touchpad mode. The absolute x- and y-coordinates are compared with previous
> values and the difference is reported as relational movements. This is for
> touchpads.

   I'm not sure I understand the point of this mode.  Can someone explain the
usage model?  Why is it the default?  Is this another option that doesn't make
sense if you don't have a BTN_TOOL_FINGER and therefore can't take the pen off
the screen?

Created attachment 3367 [details] [review]
bug fix patch versus implementation

This patch includes the previous BTN_TOOL_FINGER and includes numerous bug
fixes.	The PostMotionEvent calls are moved up into the switch statement to
avoid calling them all the time, the initial and "finger up" oldabs value code
is fixed, and scaling factors are applied to all absolute data.  With these
changes, the "TouchPad" mode works and sort of makes sense, but I would argue
that this should not be the default.  I have therefore changed it.  A true
touchpad that reports absolute coordinates might still be useful when not in
"TouchPad" mode, but a touchscreen is not necessarily usable in touchpad mode. 
Non-touchpad mode therefore seems to be a more reasonable default.

(In reply to comment #6)
> (In reply to comment #1)
> >
> > a) touchpad mode. The absolute x- and y-coordinates are compared with previous
> > values and the difference is reported as relational movements. This is for
> > touchpads.
> 
>    I'm not sure I understand the point of this mode.  Can someone explain the
> usage model?  Why is it the default?  Is this another option that doesn't make
> sense if you don't have a BTN_TOOL_FINGER and therefore can't take the pen off
> the screen?

It's for touchpads that reports absolute coordinates. My laptop happens to do that.

It's a bit hard to explain.

In touchscreen mode, if you touch the upper-left corner of the touchpad, the
cursor will immediately jump to the upper-left corner of the screen. That's not
how you use a touchpad. 

When you touch the pad, nothing should happen. Only when you move your finger on
the pad, the cursor should move accordingly. When you reach the side of the pad,
you can lift your finger, move it to the other side of the pad, touch the pad
again and continue moving the cursor.

You're right, it doesn't make sense if you can't take the pen (= finger) of the
screen (= touchpad).

The default was arbitrary in my patch. I don't care which it is.

Heikki, thanks for the clarification.  Does your touchpad still behave well with
my additional patch?  I only have an absolute coordinate mouse to test with.  I
believe the only functional changes you might notice are that converted relative
coordinates are now scaled and a bug fix in the handling of finger up/down.  I
can see the advantages to the touchpad mode now that it works better for me,
mouse acceleration and the ability to lift your finger and restart w/o the mouse
jumping to another location.  I still think non-touchpad mode is likely a better
default though.  Perhaps there's an attribute we could use to detect which mode
to default to?  BTN_TOOL_FINGER wouldn't work since I would imagine a real
touchscreen would have that key.

(In reply to comment #9)
> Heikki, thanks for the clarification.  Does your touchpad still behave well with
> my additional patch?  I only have an absolute coordinate mouse to test with.  

Actually, I've been using this driver:

http://www.stz-softwaretechnik.de/~ke/lifebook/

for some time now. Are you aware of it? 

I feel that that evtouch driver has some issues with tapping, it seems to get
"stuck" sometimes. It also doesn't have the touchpad mode by default, I had to
add that on top of it. I ended up using that because it compiles easily as a
module. I didn't know how to do that otherwise.

Anyway, thanks for your patch! I'll give it a shot.

> I believe the only functional changes you might notice are that converted relative
> coordinates are now scaled and a bug fix in the handling of finger up/down.  I
> can see the advantages to the touchpad mode now that it works better for me,
> mouse acceleration and the ability to lift your finger and restart w/o the mouse
> jumping to another location.  I still think non-touchpad mode is likely a better
> default though.  Perhaps there's an attribute we could use to detect which mode
> to default to?  BTN_TOOL_FINGER wouldn't work since I would imagine a real
> touchscreen would have that key.

I can't think of a way to guess the right mode.

If you could please take a look at the code currently in the modular CVS tree
(I'll do a release sometime in the next few days) I'd appreciate it.

The code currently does not have proper support for handling BTN_TOOL_FINGER,
however both absolute and relative modes do exist and it is possible to switch
at runtime with xinput.

A new patch against the current code tree may be accepted for fixing the
BTN_TOOL_FINGER issue, however please try and keep the design clean.

(My ability to write proper code for this is limited due to not having an
absolute pointer device, donations to correct that are welcome, as are patches.)

Reassigned the bug to myself.

There's a patch available to implement USB mouse emulation in QEmu that reports
absolute coordinates.  Using it with the evdev driver causes an abort in the
driver (as I think is expected given the comments in CVS).  I mention it here as
it may be helpful in debugging things if noone donates an absolute input device :-)

http://www.cs.utexas.edu/users/aliguori/qemu-usb-tablet.diff

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

Any updates on this patch? It hasn't changed in over a year but the patch hasn't been applied either.

Alright, this is old old old.

And we've had functional absolute support in git for a while now, with a release with it even.

File new bugs if there are any remaining issues, and I'll get to them.