[Solved] Slow trackpoint - old solution stopped working

Questions about hardware, drivers and peripherals.
In the Original Post please also include the output of inxi -Fzx
dclement
Posts: 41
Joined: 14 Mar 2013 10:34
Location: France

[Solved] Slow trackpoint - old solution stopped working

Postby dclement » 27 Jun 2019 11:57

Hello all,

My main laptop is a fairly old Dell Precision M6400. It has an ALPS trackpoint (what an idea...) which is not recognized as a trackpoint. That makes it unbearably slow (really, virtually useless).

I used to apply this workaround. I made a startup app with this command line:

Code: Select all

xinput set-prop "PS/2 Generic Mouse" "Device Accel Profile" 6
and it gave me back a reasonable trackpoint speed.

Now, this worked under Debian Jessie, but no more under SolydX:

Code: Select all

xinput set-prop "PS/2 Generic Mouse" "Device Accel Profile" 6
property 'Device Accel Profile' doesn't exist, you need to specify its type and format
So, it's probably not a SolydX-specific issue, but maybe someone can help me translate my "magic" command line above, so that it will work again?

TIA - best regards, Daniel

User avatar
ilu
Posts: 2476
Joined: 09 Oct 2013 12:45

Re: Slow trackpoint - old solution stopped working

Postby ilu » 28 Jun 2019 00:15

I don't think "Device Accel Profile" is meant to set speed. It selects a profile with that number. The profile needs to be defined somewhere - which it maybe was but not is anymore. You have to find a suitable profile or create your own - or directly set the necessary values.

Have a look here https://wiki.archlinux.org/index.php/Mo ... ing_xinput, does that help? If not, here's the full documentation: https://www.x.org/wiki/Development/Docu ... eleration/

dclement
Posts: 41
Joined: 14 Mar 2013 10:34
Location: France

Re: Slow trackpoint - old solution stopped working

Postby dclement » 28 Jun 2019 05:55

Thanks for helping Ilu,
ilu wrote:
28 Jun 2019 00:15
I don't think "Device Accel Profile" is meant to set speed. It selects a profile with that number.
I definitely agree that "6" is a profile n° rather than a speed value. And this profile number doesn't seem to exist anymore.
The profile needs to be defined somewhere - which it maybe was but not is anymore. You have to find a suitable profile or create your own - or directly set the necessary values.
Hmm... I still have access to my old setup... Perhaps I could retrieve the profile, but I don't have a clue as to where they are stored.
Have a look here https://wiki.archlinux.org/index.php/Mo ... ing_xinput, does that help? If not, here's the full documentation: https://www.x.org/wiki/Development/Docu ... eleration/
Yes, I had come across these pages too, but I fail to apply any of the suggested settings. See:

Code: Select all

xinput list-props 'PS/2 Generic Mouse'
Device 'PS/2 Generic Mouse':
	Device Enabled (142):	1
	Coordinate Transformation Matrix (144):	1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
	libinput Accel Speed (280):	0.000000
	libinput Accel Speed Default (281):	0.000000
	libinput Accel Profiles Available (282):	1, 1
	libinput Accel Profile Enabled (283):	1, 0
	libinput Accel Profile Enabled Default (284):	1, 0
	[snip](a bunch of others...)
Good! I'd like to change Accel Speed or Accel Profile, but...

Code: Select all

xinput set-prop 'PS/2 Generic Mouse' 'Accel Profile' 2
property 'Accel Profile' doesn't exist, you need to specify its type and format
and

Code: Select all

xinput set-prop 'PS/2 Generic Mouse' 'Accel Speed' 2
property 'Accel Speed' doesn't exist, you need to specify its type and format
So, xinput doesn't let me change a property which it has just listed as available! :?

User avatar
ilu
Posts: 2476
Joined: 09 Oct 2013 12:45

Re: Slow trackpoint - old solution stopped working

Postby ilu » 29 Jun 2019 14:30

Did you try to use "Settings --> Mouse and Touchpad"? You can select your device and set acceleration there - nothing much more though. Stop here if that helps.

You are giving the wrong options to xinput. You need to use the numbers, see here https://unix.stackexchange.com/question ... ty-too-low.

I think the best way would be to create a X11 conf file like explained here https://wiki.archlinux.org/index.php/Mo ... celeration. I vaguely remember that I did this for my old mouse but I forgot how.

1. Did you create a xorg.conf file anywhere? You shouldn't. Delete it.

2. You can manually define settings for your device in /usr/share/X11/xorg.conf.d/. Look at the files that are already there, you can see that we already have some adjustments for trackballs and touchpads. Don't overwrite, create a new file starting with 53-. Use "MatchProduct" or "MatchVendor" or adress "Driver" if there is one. Use MatchIsTrackpoint instead of MatchIsMouse in the ArchWiki link.

Full documentation is here: https://www.x.org/releases/current/doc/ ... nf.5.xhtml, some general explanations here: https://fedoraproject.org/wiki/Input_de ... figuration.

3. If everything fails you might check that Gnome is not overriding your settings. Look at https://askubuntu.com/questions/26290/5 ... 7017#27017 and the next answer about gconf-editor (called dconf now, you might need to install it).

dclement
Posts: 41
Joined: 14 Mar 2013 10:34
Location: France

Re: Slow trackpoint - old solution stopped working

Postby dclement » 30 Jun 2019 16:39

ilu wrote:
29 Jun 2019 14:30
Did you try to use "Settings --> Mouse and Touchpad"? You can select your device and set acceleration there - nothing much more though. Stop here if that helps.
I already tried the settings for 'PS/2 generic mouse' (recall that's how the ALPS trackpoint is recognized). But neither parameter (acceleration or speed) has any effect.
You are giving the wrong options to xinput. You need to use the numbers, see here https://unix.stackexchange.com/question ... ty-too-low.
I see. Now with

Code: Select all

xinput set-prop 13 313 0.5
I can adjust 'Accel Speed' between 0 and 1 (found with some trial and error), but unfortunately the speed remains the same. (To give you an idea, pushing the trackpoint pretty firmly, it takes over 5s for the pointer to cross the screen!)
I think the best way would be to create a X11 conf file like explained here https://wiki.archlinux.org/index.php/Mo ... celeration. I vaguely remember that I did this for my old mouse but I forgot how.

1. Did you create a xorg.conf file anywhere? You shouldn't. Delete it.
There's no xorg.conf in my current setup. Maybe there was one in my old setup, and I could learn something from it.
2. You can manually define settings for your device in /usr/share/X11/xorg.conf.d/. Look at the files that are already there, you can see that we already have some adjustments for trackballs and touchpads. Don't overwrite, create a new file starting with 53-. Use "MatchProduct" or "MatchVendor" or adress "Driver" if there is one. Use MatchIsTrackpoint instead of MatchIsMouse in the ArchWiki link.[...]
That's where I am for now, I need some time to digest all this info and exemples. But then, can MatchIsTrackpoint work even though my trackpoint is seen as a mouse? Perhaps.
3. If everything fails you might check that Gnome is not overriding your settings. Look at https://askubuntu.com/questions/26290/5 ... 7017#27017 and the next answer about gconf-editor (called dconf now, you might need to install it).
I have dconf installed already, I'll give it a look, to check if a Gnome setting would not override everything.

User avatar
ilu
Posts: 2476
Joined: 09 Oct 2013 12:45

Re: Slow trackpoint - old solution stopped working

Postby ilu » 30 Jun 2019 18:38

dclement wrote: But then, can MatchIsTrackpoint work even though my trackpoint is seen as a mouse? Perhaps.
Or maybe not ... :? - best try both. Or try to fix this. People reported to have better results with the synaptic driver. Try this solution https://stackoverflow.com/questions/486 ... -studio-g4 - if not, search for yourself. I got a lot of results for "linux glidepoint alps".

dclement
Posts: 41
Joined: 14 Mar 2013 10:34
Location: France

Re: Slow trackpoint - old solution stopped working

Postby dclement » 01 Jul 2019 09:34

Well, not looking good.

1) Gnome does have (org/gnome/desktop/peripherals/mouse) a speed setting. It can be set (like the xinput property) between 0 and 1. Both those settings (Gnome and xinput) ignore each other, and have no effect.

2) xorg.conf.d. I made a custom file and tested both options: with MatchIsMouse (no effect) and MatchIsTrackpoint (even worse; I could not boot into graphical environment!).

I'm beginning to think that if I'm to solve that, I must get a proper ALPS driver. The Synaptics driver does a good job of handling the touchpad part, but the trackpoint part is completely ignored.

I came across 2 possible solutions in this thread:
- one using a deb file provided by Dell (but I was unable to locate it);
- the other involving a custom kernel patch to be installed with dkms.
Trouble is, both are pretty outdated.

Next, I'll try and boot into my old install (under Jessie), to help me recall how it was working there.

User avatar
ilu
Posts: 2476
Joined: 09 Oct 2013 12:45

Re: Slow trackpoint - old solution stopped working

Postby ilu » 01 Jul 2019 16:49

I can see in /boot/config-4.9.0.9-amd64 that the stretch kernel is build with CONFIG_MOUSE_PS2_ALPS=y. Every kernel I have is. I can't find any other relevant kernel parameter. So I don't think kernel compilation will get you anywhere.

You need to get the correct device picked up. There might be bugs involved but it seems that synaptics driver is right for the touchpad at least. Try the libinput stuff and look at the conf file again. And post it.

Here is something newer from the gentoo people about handling the ALPS PS/2 mouse protocol extension. It's about the touchpad though. But also the trackpoint gets picked up correctly by xinput:
https://wiki.gentoo.org/wiki/Alps_PS/2
Look at the xinput output posted here https://forums.gentoo.org/viewtopic-t-1 ... ight-.html. Yours should look similar. If it doesn't research that problem first. Post dmesg | grep alps. If it does read archwiki about configuring libinput: https://wiki.archlinux.org/index.php/Li ... figuration.

Yeah, and if you still have your Solydx8 install, look at the conf, obviously. Just mounting the old root is enough to save the conf in /etc and /usr/share and (if any) /usr/local. That's something I always do before ditching an old install. If it still boots you can run xinput and libinput diagnostic there and save the output too. The old system might not have used libinput, I_m not sure.

Ah, and look at this: https://bugs.launchpad.net/ubuntu/+sour ... ug/1767178. Read also his last post.

dclement
Posts: 41
Joined: 14 Mar 2013 10:34
Location: France

Re: Slow trackpoint - old solution stopped working

Postby dclement » 02 Jul 2019 08:45

ilu wrote:
01 Jul 2019 16:49
I can see in /boot/config-4.9.0.9-amd64 that the stretch kernel is build with CONFIG_MOUSE_PS2_ALPS=y. Every kernel I have is. I can't find any other relevant kernel parameter. So I don't think kernel compilation will get you anywhere.
And it's not about every ALPS device. My secondary laptop is a Dell with (another) ALPS dual pointing device. Under the very same SolydX setup, this one is perfectly detected (as ALPS, both for trackpoint and touchpad).
You need to get the correct device picked up. There might be bugs involved but it seems that synaptics driver is right for the touchpad at least.
Yes, precisely. Thankfully the touchpad behaves correctly, even though it's mistaken for a Synaptics one.
Try the libinput stuff and look at the conf file again. And post it.
Not quite sure what you want me to try there. I can't use libinput like the Gentoo folks do:

Code: Select all

libinput-list-devices | sed -n '/DualPoint/,/^$/p'
bash: libinput-list-devices : commande introuvable
I have no /etc/X11/xorg.conf.d/30-touchpad.conf file (should I?), so I'm posting /usr/share/X11/xorg.conf.d/40-libinput.conf for reference:

Code: Select all

# Match on all types of devices but tablet devices and joysticks
Section "InputClass"
        Identifier "libinput pointer catchall"
        MatchIsPointer "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection

Section "InputClass"
        Identifier "libinput keyboard catchall"
        MatchIsKeyboard "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection

Section "InputClass"
        Identifier "libinput touchpad catchall"
        MatchIsTouchpad "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection

Section "InputClass"
        Identifier "libinput touchscreen catchall"
        MatchIsTouchscreen "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection

Section "InputClass"
        Identifier "libinput tablet catchall"
        MatchIsTablet "on"
        MatchDevicePath "/dev/input/event*"
        Driver "libinput"
EndSection

Here is something newer from the gentoo people about handling the ALPS PS/2 mouse protocol extension. [...]
Look at the xinput output posted here https://forums.gentoo.org/viewtopic-t-1 ... ight-.html. Yours should look similar. If it doesn't research that problem first.
It definitely doesn't:

Code: Select all

xinput
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad              	id=12	[slave  pointer  (2)]
⎜   ↳ PS/2 Generic Mouse                      	id=13	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	[...]
The 2nd line is wrong (should be AlpsPS/2 ALPS DualPoint TouchPad) but still works, the 3rd line is totally wrong (should be AlpsPS/2 ALPS DualPoint Stick).
Post dmesg | grep alps. [...]
The output of dmesg | grep alps is empty!
Yeah, and if you still have your Solydx8 install,
It was not SolydX but Linux Mint Debian (sorry!)--anyway, basically Debian Jessie.
look at the conf, obviously. Just mounting the old root is enough to save the conf in /etc and /usr/share and (if any) /usr/local. That's something I always do before ditching an old install. If it still boots you can run xinput and libinput diagnostic there and save the output too. The old system might not have used libinput, I_m not sure.
I'm not sure which conf file you want me to retrieve, so I try to sum up the differences:
[*] The old install had a xorg.conf file, but I guess it was auto-generated by the Nvidia drivers, and the problem was there anyhow;
[*] The contents of /usr/share/X11/xorg.conf.d was a bit different:

Code: Select all

/media/daniel/5521c167-88a4-4e9f-9f06-d240cc206630/usr/share/X11/xorg.conf.d$ ls
10-evdev.conf   50-synaptics.conf  50-wacom.conf
10-quirks.conf  50-vmmouse.conf
[*]The output of xinput list was exactly the same as above, but I had more options under xinput list-props:

Code: Select all

xinput list-props 13
Device 'PS/2 Generic Mouse':
	Device Enabled (142):	1
	Coordinate Transformation Matrix (144):	1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
	Device Accel Profile (266):	6
	Device Accel Constant Deceleration (267):	1.000000
	Device Accel Adaptive Deceleration (268):	1.000000
	Device Accel Velocity Scaling (269):	10.000000
	Device Product ID (261):	2, 1
	Device Node (262):	"/dev/input/event15"
	Evdev Axis Inversion (304):	0, 0
	Evdev Axes Swap (306):	0
	Axis Labels (307):	"Rel X" (152), "Rel Y" (153)
	Button Labels (308):	"Button Left" (145), "Button Middle" (146), "Button Right" (147), "Button Wheel Up" (148), "Button Wheel Down" (149)
	Evdev Scrolling Distance (309):	0, 0, 0
	Evdev Middle Button Emulation (310):	0
	Evdev Middle Button Timeout (311):	50
	Evdev Third Button Emulation (312):	0
	Evdev Third Button Emulation Timeout (313):	1000
	Evdev Third Button Emulation Button (314):	3
	Evdev Third Button Emulation Threshold (315):	20
	Evdev Wheel Emulation (316):	0
	Evdev Wheel Emulation Axes (317):	0, 0, 4, 5
	Evdev Wheel Emulation Inertia (318):	10
	Evdev Wheel Emulation Timeout (319):	200
	Evdev Wheel Emulation Button (320):	4
	Evdev Drag Lock Buttons (321):	0
In particular this 3rd line with more 'Device Accel Profiles' which allowed me to apply the workaround I described in my OP.
Ah, and look at this: https://bugs.launchpad.net/ubuntu/+sour ... ug/1767178. Read also his last post.
Not quite sure what it means in the end (too many files in my /usr/share/X11/xorg.conf.d?), but I notice that right from the beginning, his ALPS glidepoint is correctly identified (I guess this one doesn't have a trackpoint).

User avatar
ilu
Posts: 2476
Joined: 09 Oct 2013 12:45

Re: Slow trackpoint - old solution stopped working

Postby ilu » 02 Jul 2019 13:24

To get the libinput commands working you need to install libinput-tools.

The conf files don't help as long as we don't know whether device detection works correctly. You need to know what the old system detected differently. Please compare the output on both systems of
- just xinput (without parameters)
- sudo libinput list-devices
- dmesg | grep alps and dmesg | grep PS
- sudo dmidecode (no idea what to grep for, you'll have to look for the relevant entries)

Sadly I'm just digging in the dark here since I can't test anything myself. I'm venting ideas to somehow get to the core of the problem.

dclement
Posts: 41
Joined: 14 Mar 2013 10:34
Location: France

Re: Slow trackpoint - old solution stopped working

Postby dclement » 02 Jul 2019 16:18

ilu wrote:
02 Jul 2019 13:24
To get the libinput commands working you need to install libinput-tools.
Sorry, I won't be able to post this comparison, because AFAICT there is (was) no libinput-tools package in Jessie. Below I'm posting the differences between the outputs of the other commands (compared in Meld).
[...] Please compare the output on both systems of
- just xinput (without parameters) [...]
The result is exactly the same (the useful part was in my previous post);
- dmesg | grep alps
There's a big difference here: on the newer system, the output is empty, whereas on the older system I got

Code: Select all

dmesg | grep alps
[   17.589162] psmouse serio2: alps: Unknown ALPS touchpad: E7=10 00 64, EC=10 00 64
and dmesg | grep PS
Apart from the variation in indexes, I got 2 more lines on the older system:

Code: Select all

dmesg | grep PS
[...]
[   15.130366] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  340.96  Sun Nov  8 22:33:28 PST 2015
[   17.589162] psmouse serio2: alps: Unknown ALPS touchpad: E7=10 00 64, EC=10 00 64
[...]
The 1st line is irrelevant, it's just that the older system used the proprietary Nvidia driver. The 2nd line is the same as above.
- sudo dmidecode (no idea what to grep for, you'll have to look for the relevant entries)
No noteworthy difference there, just the current processor speed and this (very marginal) change, which I post only for the sake of completeness:

Code: Select all

Handle 0xB000, DMI type 176, 5 bytes
OEM-specific Type
	Header and Data:
		B0 05 00 B0 39
(ended with 36 on the old system...)
Sadly I'm just digging in the dark here since I can't test anything myself. I'm venting ideas to somehow get to the core of the problem.
Could it be this "Unknown ALPS touchpad"?

User avatar
ilu
Posts: 2476
Joined: 09 Oct 2013 12:45

Re: Slow trackpoint - old solution stopped working

Postby ilu » 03 Jul 2019 11:37

I think that's the touchpad ehich is working anyway.
From these results I don't think the device recognition is the difference between old and new system. But we know from xinput list-props that the old system used evdev driver and the new uses libinput driver. I've found another tidbit:
https://www.reddit.com/r/thinkpad/comments/6jdvxk/e470_trackpoint_scrolling_on_ubuntu/ wrote:I've seen a lot of complaints about the track point being too slow under libinput. If it does work, great because it's usually the default driver. I know on my X1 carbon 5th gen setting the maximum accel speed still renders it too slow. Under evdev driver I'm able to make it as fast as I want.
So maybe follow that track? The thread indicates a conf.d file change:
My x1 carbon 5th running Mint 18.1 + kernel 4.8.0-58-generic is having a "PS/2 Generic Mouse"
/usr/share/X11/xorg.conf.d/11-evdev-trackpoint.conf is

Section "InputClass"
Identifier "trackpoint catchall"
MatchIsPointer "true"
MatchProduct "TrackPoint|DualPoint Stick"
MatchDevicePath "/dev/input/event*"
Option "Emulate3Buttons" "true"
Option "EmulateWheel" "true"
Option "EmulateWheelButton" "2"
Option "XAxisMapping" "6 7"
Option "YAxisMapping" "4 5"
EndSection

Simply modifying
MatchProduct "TrackPoint|DualPoint Stick"
into
MatchProduct "TrackPoint|DualPoint Stick|PS/2 Generic Mouse"
gave me middle button scrolling.
Try that change in 11-solydxk-evdev-trackpoint.conf. If that doesn't help you'll have to find out how to move from libinput to evdev. I'm a bit short on time so I can't help with that. But if you run into a dead end, just post again and I'll see what I can do. And if you find a solution, please report back so others can profit too.

dclement
Posts: 41
Joined: 14 Mar 2013 10:34
Location: France

Re: Slow trackpoint - old solution stopped working

Postby dclement » 05 Jul 2019 07:59

I'm coming to report some success:
ilu wrote:
03 Jul 2019 11:37
[...]Try that change in 11-solydxk-evdev-trackpoint.conf.
I did, but that alone did not suffice.
If that doesn't help you'll have to find out how to move from libinput to evdev. [...]
That may well be the key to a solution. After some searching I came across this thread. The user did not hesitate to remove xserver-xorg-input-libinput. So did I. After that, two good surprises:
1. The PS/2 Generic Mouse did accept various "Device Accel Profile", in particular the n°6 that I was using under Jessie;
2. Plus (possible with the 1st part of the solution) it reacted to the settings under "mouse and touchpad" so I was able to tweak the acceleration and sensitivity to a satisfactory response.

Now there are 2 caveats:
1. Removing xserver-xorg-input-libinput is rather extreme and may not suit everyone having this problem;
2. The solution does not survive a reboot. I guess I have to create a dedicated startup app like the one I described in my OP.

And finally... my trackpoint cap is dead, it's falling to pieces and I'll have to remove it carefully or I'll get full of tiny rubber parts underneath my keyboard. I need to get my hands on a spare before I can test any further and report that everything is OK.

But right now a big thanks to you Ilu for your patience and continued help!

User avatar
ilu
Posts: 2476
Joined: 09 Oct 2013 12:45

Re: Slow trackpoint - old solution stopped working

Postby ilu » 05 Jul 2019 14:01

Glad that worked out! We went in tangents but found the solution at last. And documented it here. So yeah!
xinput settings not surviving a reboot works as intended, you'll have to either find out the right xorg.conf.d changes or use a startup skript.
And I hope you can rescue your trackpoint - not that all this work was in vain.

dclement
Posts: 41
Joined: 14 Mar 2013 10:34
Location: France

Re: Slow trackpoint - old solution stopped working

Postby dclement » 13 Jul 2019 09:53

Well, that's it. As an epilogue to this long thread, just a couple of things that I wanted to add:
* I made the solution persistent by adding the startup line with xinput, the solution described in my OP that I used before, and which is working again after the removal of xserver-xorg-input-libinput.
* As for the hardware part, I had an old M6400 keyboard but the trackpoint was in the same bad condition. I was able to reuse the rubber part of an old Latitude keyboard. The fit is a little wobbly (square hole onto round bit). But I can use the system's preferences to really fine tune the speed and sensitivity. That makes the trackpoint really nice to use.
* In the meantime, I learned that Dell has equipped this line of PCs (Precision M6400) with Synaptics or ALPS trackpoints. Since I changed the keyboard ad some point (hence the trackpoint, but not the touchpad), it's quite possible that this PC has a Synaptics touchpad with an ALPS trackpoint. Who knows...
I'm now marking this thread as solved. BR, Daniel


Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 3 guests