Bug 2758 - Absolute pointer support for evdev input driver
Summary: Absolute pointer support for evdev input driver
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/evdev (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: high enhancement
Assignee: Zephaniah E. Hull
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 968
  Show dependency treegraph
 
Reported: 2005-03-17 11:33 UTC by Heikki Linnakangas
Modified: 2007-04-23 21:05 UTC (History)
11 users (show)

See Also:
i915 platform:
i915 features:


Attachments
implementation (13.40 KB, patch)
2005-03-17 11:48 UTC, Heikki Linnakangas
no flags Details | Splinter Review
pointers w/o BTN_TOOL_FINGER are always touching (422 bytes, patch)
2005-09-21 14:40 UTC, Alex Williamson
no flags Details | Splinter Review
bug fix patch versus implementation (5.63 KB, patch)
2005-09-22 14:49 UTC, Alex Williamson
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Heikki Linnakangas 2005-03-17 11:33:13 UTC
The evdev input driver doesn't currently support absolute pointer devices. That
includes touchscreens and touchpads.
Comment 1 Heikki Linnakangas 2005-03-17 11:48:44 UTC
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.
Comment 2 Adam Jackson 2005-03-18 19:13:06 UTC
way cool, thanks!
Comment 3 Adam Jackson 2005-07-30 03:54:49 UTC
component shift
Comment 4 Seemant Kulleen 2005-08-25 12:57:47 UTC
this patch causes segfaults on 6.9 rc1 for me
Comment 5 Alex Williamson 2005-09-21 14:40:43 UTC
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.
Comment 6 Alex Williamson 2005-09-21 15:18:51 UTC
(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?
Comment 7 Alex Williamson 2005-09-22 14:49:32 UTC
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.
Comment 8 Heikki Linnakangas 2005-09-23 00:10:03 UTC
(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.
Comment 9 Alex Williamson 2005-09-23 07:48:12 UTC
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.
Comment 10 Heikki Linnakangas 2005-09-29 09:39:44 UTC
(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.
Comment 11 Zephaniah E. Hull 2006-02-16 10:32:46 UTC
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.)
Comment 12 Zephaniah E. Hull 2006-02-16 10:34:38 UTC
Reassigned the bug to myself.
Comment 13 Anthony Liguori 2006-04-10 13:49:47 UTC
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
Comment 14 Daniel Stone 2007-02-27 01:25:47 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 15 Giuseppe Bilotta 2007-04-23 05:48:55 UTC
Any updates on this patch? It hasn't changed in over a year but the patch hasn't been applied either.
Comment 16 Zephaniah E. Hull 2007-04-23 21:05:54 UTC
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.