On Fri, May 24, 2019 at 06:43:58PM +0800, Hui Wang wrote:
>
> On 2019/5/24 下午5:37, Peter Hutterer wrote:
> > On Fri, May 24, 2019 at 03:37:57PM +0800, Hui Wang wrote:
> > > On 2019/5/24 下午3:26, Pali Rohár wrote:
> > > > On Friday 24 May 2019 13:50:53 Hui Wang wrote:
> > > > > On 2019/5/24 下午1:36, Peter Hutterer wrote:
> > > > > > On Fri, May 24, 2019 at 01:25:52PM +0800, Hui Wang wrote:
> > > > > > > On 2019/5/23 下午2:01, Peter Hutterer wrote:
> > > > > > > > On Wed, May 22, 2019 at 09:40:30AM +0200, Pali Rohár wrote:
> > > > > > > > > On Wednesday 22 May 2019 07:30:43 Xiaoxiao Liu wrote:
> > > > > > > > > > Hi Pali,
> > > > > > > > > >
> > > > > > > > > > Ok, and cannot you set ALPS_DUALPOINT flag based on that
> > > > > > > > > > alps_check_is_trackpoint() result and then update
> > > > > > > > > > alps_process_packet_ss4_v3() code to supports also
> > > > > > > > > > V8 trackpoint packets?
> > > > > > > > > > --> Yes, we can do like so, when we use the v8 method to process the trackpoint , the mouse speed is not ideal.
> > > > > > > > > > Then we choose the standard mouse driver.
> > > > > > > > > Mouse speed is something which is configurable. Have you configured it
> > > > > > > > > somehow? Also there is libinput project should handle these settings
> > > > > > > > > more properly.
> > > > > > > > >
> > > > > > > > > Adding Peter Hutterer, maintainer of libinput to loop. I think he could
> > > > > > > > > help with this problem.
> > > > > > > > libinput has a quirk for a magic multiplier on trackpoints. it was the only
> > > > > > > > solution I found that came close to "working" given that every device seems
> > > > > > > > to provide some other random magic data. Doc for it is here:
> > > > > > > > https://wayland.freedesktop.org/libinput/doc/latest/trackpoint-configuration.html
> > > > > > > Hello Peter Hutterer,
> > > > > > >
> > > > > > > To adjust the trackpoint speed from userspace:
> > > > > > >
> > > > > > > If the libinput version is lower than 1.9.0, we could set
> > > > > > > POINTINGSTICK_CONST_ACCEL=0.25
> > > > > > >
> > > > > > > If the libinput version is higher than 1.12.0, we could set
> > > > > > > AttrTrackpointMultiplier=0.25
> > > > > > >
> > > > > > > But if we use libinput-1.10.0, how could we adjust the speed?
> > > > > > The LIBINPUT_ATTR_TRACKPOINT_RANGE property, which didn't end up working
> > > > > > well (hence why it got replaced again). See the docs here though:
> > > > > > https://wayland.freedesktop.org/libinput/doc/1.10.0/trackpoints.html
> > > > > >
> > > > > > Cheers,
> > > > > > Peter
> > > > > OK, got it, Thanks.
> > > > Is not here some database where for input device name / id is specified
> > > > that property? So users do not have to invent what is correct value for
> > > > their hardware?
> > > Since the libinput version in the ubuntu 18.04 is 1.10, I tried to set
> > > LIBINPUT_ATTR_TRACKPOINT_RANGE with different values (from 25, 20, 10, 5) in
> > > the udev hwdb database, I checked it with "udevadm info /dev/input/eventX"
> > > to confirm the value is set to LIBINPUT_ATTR_TRACKPOINT_RANGE successfully,
> > > but looks like the cursor speed doesn't change at all. So for ubuntu 18.04,
> > > looks like we have to adjust the speed in the kernel driver.
> > I don't think it's a good idea to make the kernel driver behaviour based on
> > an EOL libinput version just because one version of ubuntu ships with that.
> > 18.10 and 19.04 both ship with libinput 1.12.
> >
> > It'd be better to make sure it works well with a *current* version and then
> > patch libinput on 18.04 where needed.
>
> OK, that is sth we need to do. But anyway it is a bit risky to backport
> that much code and the whole folder of quirks to libinput 1.10.4, we need
> to do lots of test to make sure there is no regression on other machines.
>
> Probably we only need to keep the quirks/30-vendor-alps.quirks to 1.10.4 and
> drop other quirks, that will be better for our testing effort.
might be worth looking at what is in 1.10.7, e.g. a3b3e85c0e looks like it
may be of interest. That one suggests the range on some ALPS devices is over
100, so testing with 5-25 may really not have had any effect.
Cheers,
Peter
On 2019/5/24 下午6:58, Peter Hutterer wrote:
> On Fri, May 24, 2019 at 06:43:58PM +0800, Hui Wang wrote:
>> On 2019/5/24 下午5:37, Peter Hutterer wrote:
>>> On Fri, May 24, 2019 at 03:37:57PM +0800, Hui Wang wrote:
>>>>
>> OK, that is sth we need to do. But anyway it is a bit risky to backport
>> that much code and the whole folder of quirks to libinput 1.10.4, we need
>> to do lots of test to make sure there is no regression on other machines.
>>
>> Probably we only need to keep the quirks/30-vendor-alps.quirks to 1.10.4 and
>> drop other quirks, that will be better for our testing effort.
> might be worth looking at what is in 1.10.7, e.g. a3b3e85c0e looks like it
> may be of interest. That one suggests the range on some ALPS devices is over
> 100, so testing with 5-25 may really not have had any effect.
Oh, looks exactly the same as our issue, will have a try with it.
Thanks,
Hui.
>
> Cheers,
> Peter
>