Puppy Linux Discussion Forum

(Computer and OS in sig.)

I have had problems with the new "clickpads" that are now so common in lightweight laptops and chromebooks, when used with various Puppies. So I thought I might open a topic to see whether we can address them in general.

First some definitions:

"Clickpads" are different than "touchpads" only in that they have no external "mouse" buttons adjacent to the touch area. They are smooth surfaced. Touchpads have external buttons. Clickpads may have a button (or two) under the surface of the pad, so a portion of the the pad itself gets depressed in order to "click" it. But they don't have external buttons.

Generally clickpads may have various areas of the pad surface designated as "buttons" to tap in order to mimic the buttons normally found on a mouse. Or, they may use the actual physical button under the pad for that. Or they may map areas in conjunction with that physical button to provide multiple button functions. Or they may use particular taps, or single or multi-finger gestures on the touch surface to generate those buttons.

The big problem comes from this over-abundance of different possible control methods. Unless set up properly to start with, these various methods may easily overlap. And conflict with each other in the most frustrating way.

Unfortunately there is almost no good help explanation for an everyday user of how these should be set up. Unfortunately, front ends like flsynclient also do a poor job of explaining settings, sometimes even adding to the confusion. (Example: setting "touch sensitivity" to a higher value in flsynclient actually decreases touch sensitivity. It's really a touch threshold setting.)

With all of these potential settings conflicts and help logic problems, it's no wonder misbehaving clickpads can drive a person crazy.

Now I have a new laptop with a clickpad, and came to it after a dozen years of using a touchpad equipped laptop. The old laptop touchpad had two external buttons, and I had turned off all mapping, tapping and gesture functions via Puppy's psynclient. Everything was simple. The touchpad merely moved the cursor. All button functions were taken care of by actual physical buttons. Life was good. And simple.

Although my new laptop has physical button(s) as well, under the pad, unfortunately, there is no obvious way to get them to work separate from other functions on the pad as I once did. I couldn't just limit cursor movement to the portion of the pad above the "button area." There were always unexpected interactions. Also the pad was MUCH bigger than my old one, making it a huge stretch to use the right button, and causing lots of inadvertent pad hits while typing.

Worse than area conflicts, sometimes the screen cursor will just freeze up, or partially freeze, and I will struggle to close the current session and save my work without plugging in a mouse. I've gradually traced those occurrences to times when I have tried to use the clickpad's physical button(s). It doesn't always happen, but seems to, sooner or later in many sessions.

As a workaround I could practice never using the physical buttons, but this is the opposite of what I was used to, and liked. Sooner or later I do use them out of habit. I don't know just what function is causing the conflict, or when or why. But I believe I may have stumbled onto a solution which I'd like to share.

Apparently, my HP laptop's clickpad is not very different from some of the Apple's clickpads, and I found a so-called "quirk" exception in Xorg's config files that applied to Apples, and I'm now testing that out on my own laptop.

In F96-CE v.4 it is located in /usr/share/X11/xorg.conf.d/70-synaptics.conf

As an experiment, to make it apply to my laptop as well as Apple's, I have commented out "MatchProduct..." in the section below and rebooted.

# This option disables software buttons on Apple touchpads.
# This option is only interpreted by clickpads.
Section "InputClass"
        Identifier "Disable clickpad buttons on Apple touchpads"
        MatchProduct "Apple|bcm5974"
        MatchDriver "synaptics"
        Option "SoftButtonAreas" "0 0 0 0 0 0 0 0"
EndSection

So far the clickpad works as well as it has before the change, and I have not had a cursor freeze since. Time will tell if this has solved the problem.

Another improvement was, as mentioned earlier, realizing that flsynclient (psynclient) is labeled wrongly in the "touch sensitivity" section. I wanted to reduce touch sensitivity so I would reduce inadvertent hits while typing. Well increasing that number reduces sensitivity, not lowering the number. It's really a touch threshold figure. Right now I have it at the maximum permitted by the sliders, and I'd go higher if I could -- the pad is plenty sensitive enough as it is.

Another method of reducing inadvertent hits is using the "palm detect" feature. But that one hasn't worked out well so far - or perhaps I likewise have the settings wrong due to the weird way some of these are labeled.

Anyway, just thought I'd start the ball rolling for these clickpad issues, with some workarounds I've tried.

Investigating further with pSynclient (the Touchpad section of the Mouse/Keyboard Manager in F96-CE v4), I've found what looks like an issue with settings:

1.) I reverted my former alteration of /usr/share/X11/xorg.conf.d/70-synaptics.conf back to its as-shipped state (removed the commenting of the Apple line, in the prior post) and rebooted.

2.) I wanted to see if I could get a right bottom corner click to register as a right mouse button press. I opened Menu>Mouse/Keyboard Manager>Touchpad (Psynclient) and under "Tapping" I set "Bottom Right Corner" to "3-right button".

3.) This allowed me to click the clickpad's right lower corner internal button, which acted like a right mouse button, as hoped. However after some tests scrolling and clicking on the desktop with the clickpad's internal physical buttons, I again reached a condition where the cursor froze, and I had to use a USB mouse to escape and close the session.

4.) I rebooted and in pSynclient I disabled the lower right corner as a button. I rebooted. Then as a check, I opened a terminal and entered "synclient" this gives a list of all the current settings. Unfortunately the right lower corner settings were still in effect. Here's a screenshot of synclient's output next to pSynclient's supposed setting of 0-disabled for the lower right corner. They don't agree. The terminal should show all zeros for mapped button areas.

The culprit seems to be /usr/share/X11/xorg.conf.d/70-synaptics.conf which apparently overrides Puppy's Touchpad manager (pSynclient) .
That configuration file contains the following stanza:

# This option enables the bottom right corner to be a right button on clickpads
# and the right and middle top areas to be right / middle buttons on clickpads
# with a top button area.
# This option is only interpreted by clickpads.
Section "InputClass"
        Identifier "Default clickpad buttons"
        MatchDriver "synaptics"
        Option "SoftButtonAreas" "50% 0 82% 0 0 0 0 0"
        Option "SecondarySoftButtonAreas" "58% 0 0 15% 42% 58% 0 15%"
EndSection

In it, the "SoftButtonAreas" line explicitely defines a right soft button area at 50% of the pad width and located 82% down from the top of the pad.

The next line for SecondarySoftButtonAreas divides up other portions of the pad for mapping as buttons. This line in particular is probably responsible for my cursor freezing at odd times.

These button mappings seem to be defaults. It's unclear how pSynclient interracts with them.

Sometimes user settings in pSynclient seem to have an effect, other times they don't. I suspect there is some problematic code in pSynclient. To me pSynclient should always override default settings in configuration files -- or it should overwrite those files.

A settings manager should take highest priority over config files, or what's the point of having one?

Further study....

Looks like the Synaptics config file only maps out a button area, while pSynclient activates that area as a button. So they don't actually overlap in function. Or shouldn't.

With that distinction in mind, I'm trying a new setup now which seems to work to mimic my old touchpad with the two buttons separate from the pad. I've turned off tapping completely, and then mapped the left and right lower pad areas to act as buttons. I have to physically depress the pad in those mapped areas to to activate them, which actually feels like having two separate physical buttons.

Here's what this new setup looks like in the settings. I've commented out the extra soft button areas in the config file, and I've made the left button area smaller, and the right larger via the 40% figure. This is because the touchpad is so large on my laptop that reaching across for a right click is difficult with the left hand.

After fairly extensive use tonight, I have not had a cursor freeze-up since I made those last changes. Fingers crossed...........so to speak!

All was well for a few days, but I started to notice some cursor freeze-ups again last night. Generally I could wrangle my way out of them by left clicking and randomly moving a finger on the touchpad. And then rebooting without saving.

BUT this afternoon I tried that, rebooted, unfortunately having to save my work, the laptop now is totally unresponsive to the touchpad. I have to use a mouse.

I was able to regain touchpad control finally by opening the computer's BIOS manager, and then closing it again without actually changing anything.

However, touchpad usage is flakey, sorry to say, on this laptop with F96-CE despite all of the settings I've tried. Things seem to work for a short while but inevitably the cursor will begin to get stuck at times and then eventually freeze, needing a mouse to recover.

I'm going to try to use libinput instead of synaptics as the touchpad driver.

This is accomplished by symlinking /usr/share/X11/xorg.conf.d/40-libinput.conf into /etc/X11/xorg.conf.d/ . When that is done, it takes precedence over higher numbered configuration files in the /usr/share/X11/xorg.conf.d1/xorg.conf.d directory. The Synaptics configuration file is numbered 70, and normally overrides the 40 of libinput. But whatever is in /etc/X11/.... has higher priority.

A side effect is that the Puppy mouse and keyboard manager's Psynclient no longer works to set touchpad parameters.

But libinput may be more stable for modern hardware.... We'll see! It's active now as I'm typing this, and feels stable so far.

How it is working:

Left click at pad bottom is left mouse click
Right click at pad bottom is right mouse click
Single finger tap is left mouse click
Two finger tap is right mouse click
Two finger drag is mouse scroll wheel

Touchpad sliding cursor is a little slower than I am used to but acceleration is good so I can reach across the full screen with a quick gesture.

These all seem quite usable as-is even without a settings manager. After a couple hours of use this is seeming rock stable. Also I'm no longer getting cursor jumps while typing long passages (those were extremely annoying). I think this is going to be the solution. Dump synaptics in favor of libinput.

After a full day of use the touchpad is error free. No jumps or freezes. No inadvertent jumps while typing.

Let's hope this is the end to touchpad problems on this laptop. I'm pretty confident at this point that we're good to go.

I do wonder whether the change from synaptics to libinput is do-able in vanilla F96-CE v4 or whether my changing kernels in it enabled making that switch.

I'll try to test that out and put an answer up here FYI......