Bug 59478 - edge-scrolling works erratically on a recent ALPS touchpad (E7 : 73 03 50)
Summary: edge-scrolling works erratically on a recent ALPS touchpad (E7 : 73 03 50)
Status: RESOLVED NOTOURBUG
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/synaptics (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Peter Hutterer
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-16 19:00 UTC by vincent.vanackere
Modified: 2013-10-31 14:36 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
synclient -l (2.20 KB, text/plain)
2013-01-16 19:00 UTC, vincent.vanackere
no flags Details
evemu-describe (822 bytes, text/plain)
2013-01-16 19:01 UTC, vincent.vanackere
no flags Details
evemu-record : right edge scrolling attempt, bottom to top (7.74 KB, text/plain)
2013-01-16 19:02 UTC, vincent.vanackere
no flags Details

Description vincent.vanackere 2013-01-16 19:00:39 UTC
Created attachment 73162 [details]
synclient -l

Ubuntu 12.04/amd64, using the latest version of every package.
Laptop is a Fujitsu A512, touchpad is an ALPS, E7 report 73 03 50.
xserver-xorg-input-synaptics package is version 1.6.2-1ubuntu1~precise2

Preliminary information : this touchpad is not supported by any current distribution : I compiled a working driver starting from the latest one at http://www.dahetral.com/public-download with only slight modifications in the initialization sequence (I tweaked the initialisation sequence to match exactly the one sent by the windows driver running on the same hardware through qemu...).

Everything is working fine with the notable exception of egde scrolling, which is very hard to obtain (only works once every 3 or 4 attempts).
I'm attaching an evemu trace of edge scrolling (bottom to top) that does not result in the expected behaviour.
It may be the fault of the driver or it may be a problem with the synaptics input driver but at this point I need further help. If this is the former, I'm very interested in any hint about what should be done in the kernel driver to fix this behaviour.
Comment 1 vincent.vanackere 2013-01-16 19:01:44 UTC
Created attachment 73163 [details]
evemu-describe
Comment 2 vincent.vanackere 2013-01-16 19:02:54 UTC
Created attachment 73164 [details]
evemu-record : right edge scrolling attempt, bottom to top
Comment 3 Peter Hutterer 2013-01-16 22:11:46 UTC
Don't think this is a kernel problem here. Device announces a pressure range of 0..127, the sequence you posted has  pressure values in the 10-13 range.

Synaptics has a min pressure before it accepts a finger (FingerHigh in synclient) and that is set to 15. If you change FingerHigh and FingerLow to be less than 10, then scrolling works fine.

Now the question is of course, is the 127 range correct here, i.e. do you need to press (subjectively) too hard to trigger the proper values? given that you say it works otherwise fine, this may be a hw issue with the touchpad not detecting pressure as well at the edge?


btw, I noticed ABS_MT_PRESSURE is missing despite ABS_PRESSURE being present.
Comment 4 vincent.vanackere 2013-01-16 23:23:01 UTC
Many thanks for your help ! You're indeed completely right :
- pressure values at the egde of the touchpad are indeed in the 7-13 range (I can get up to 18 only by pressing very hard)
- pressure values on the other areas of the touchpad are usually in the 18-26 range (it goes up to 40 with two finger at the same time)
- setting FingerLow=5 and FingerHigh=6 indeed make edge scrolling work much better...

I now have some further questions :
- is there a way to tweak the kernel driver so that the synaptics driver can choose the right defaults for this touchpad ?
- wrt ABS_MT_PRESSURE missing : is it just a simple call to input_report_abs(dev, ABS_MT_PRESSURE, ...) missing ? How can I test that this is then working as intended ?
Comment 5 Peter Hutterer 2013-01-17 00:51:29 UTC
Benjamin will know re ABS_MT_PRESSURE, cc-ing him. Not that important for the synaptics driver though.

The defaults are picked by the driver based on the axis ranges the touchpad reports. We don't really have code to adjust the finger pressure depending on the area of the touchpad. tbh, not too keen to add it either unless this problem becomes more widespread.

You should also find that this device uses two-finger scrolling by default, so switching to edge-scrolling is already a configuration change.

Also, reducing the values by default can lead to unexpected touches too.
Comment 6 vincent.vanackere 2013-01-18 15:27:24 UTC
(In reply to comment #5)
> Benjamin will know re ABS_MT_PRESSURE, cc-ing him. Not that important for
> the synaptics driver though.
> 
> The defaults are picked by the driver based on the axis ranges the touchpad
> reports. We don't really have code to adjust the finger pressure depending
> on the area of the touchpad. tbh, not too keen to add it either unless this
> problem becomes more widespread.

From my experience with the device we don't need to adjust the finger pressure depending on the area : setting eg FingerLow=5 and FingerHigh=6 make the touchpad behave well (without any unexpected touches).
I'd just need a way to set this from the driver (or perhaps if there is no better choice I can cheat and artificially increase the pressure reported by the driver ?).

> You should also find that this device uses two-finger scrolling by default,
> so switching to edge-scrolling is already a configuration change.

I'm afraid I don't understand this sentence... All I can tell is that, at least with the default Ubuntu desktop environment (unity), I found edge-scolling enabled by defaut as soon as the touchpad was recognized.
Comment 7 Benjamin Tissoires 2013-01-18 17:29:33 UTC
wrt to the missing ABS_MT_PRESSURE:
- The declaration of ABS_PRESSURE [ input_set_abs_params(dev1, ABS_PRESSURE, 0, 127, 0, 0); ] should occurs _before_ the call of input_mt_init_slots. Actually, input_mt_init_slots copies the content of ABS_X, ABS_Y and ABS_PRESSURE into ABS_MT_POSITION_X, ABS_MT_POSITION_Y and ABS_MT_PRESSURE.

- Then, you need to call indeed input_report_abs(dev, ABS_MT_PRESSURE, ...) in a per-slot basis.

Cheers,
Benjamin
Comment 8 Peter Hutterer 2013-01-21 02:47:02 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Benjamin will know re ABS_MT_PRESSURE, cc-ing him. Not that important for
> > the synaptics driver though.
> > 
> > The defaults are picked by the driver based on the axis ranges the touchpad
> > reports. We don't really have code to adjust the finger pressure depending
> > on the area of the touchpad. tbh, not too keen to add it either unless this
> > problem becomes more widespread.
> 
> From my experience with the device we don't need to adjust the finger
> pressure depending on the area : setting eg FingerLow=5 and FingerHigh=6
> make the touchpad behave well (without any unexpected touches).
> I'd just need a way to set this from the driver (or perhaps if there is no
> better choice I can cheat and artificially increase the pressure reported by
> the driver ?).

I think until we see more devices like this it's probably best to add a quirk configuration snippet for this model and ship that with the distributions. MatchUSBID seems like a candidate here.

> > You should also find that this device uses two-finger scrolling by default,
> > so switching to edge-scrolling is already a configuration change.
> 
> I'm afraid I don't understand this sentence... All I can tell is that, at
> least with the default Ubuntu desktop environment (unity), I found
> edge-scolling enabled by defaut as soon as the touchpad was recognized.

oh, right. we have two defaults, one that's assigned by the driver, one that is used by the desktop environment. the driver-one is to default to two-finger scrolling if two-finger capabilities are found. The DE defaults are the user-specific settings and you can change them in whatever config tool the DE provides.
Comment 9 vincent.vanackere 2013-10-31 14:36:46 UTC
Hi,

 This problem is solved by the latest ALPS driver posted at http://marc.info/?l=linux-input&m=138235576025208&w=1. So this behaviour was indeed the driver's fault and I'm closing this issue. Thanks for the feedback !


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.