Synaptics touchpad erratic on Knoppix 7.x

The title is self-explanatory. I first discovered this issue with Knoppix 7.0.5 (IIRC), and it continued "well" into Knoppix 7.2 CD versions. I prefer to use CD versions of Knoppix, because of a lack of storage and download speeds. Yes! Mmh!!

Note, that to avoid fancy Compiz effects, I almost always use the no3d parameter at Knoppix startup.

The Synaptics touchpad is highly erratic (in Metacity), and until today, I had had nothing that would resemble workaround to make it less erratic. One of the symptoms in a browser, for example, is that text suddenly gets selected, and I can't release the selection. No, nothing helps. I could only use the keyboard to navigate, and LXDE/Metacity environments don't appear to have any keyboard shortcut to access the taskbar (start) menu.

Some of the workarounds:

1. An immediate workaround is to restart X from the console via restartx
   One can have a non-minimised terminal window (uxterm) ready in the background, and then use extant keyboard and menu commands to close active apps. Another is to use Ctrl-Alt-F1 to revert to the text-only console. Restarting X is not a longer-term solution, because the problem might return again.
2. Another is to fall back to Knoppix 6.7.1, which allows a stable pointer with the Synaptics touchpad, but this Knoppix release has outdated software (Iceweasel 6.0, for example).
3. Yet another in Knoppix 7.x consists of adding the psmouse parameter into the Knoppix start-up command-line:

   knoppix no3d psmouse.proto=imps

   The imps somehow changes the pointer input device. At least on my machine, the immediate effect was that cursor tracking (movement) with the touchpad became slower.
   While the terrible and annoying erratic behaviour was not there as much, it still kept being somewhat erratic in other ways, albeit less so, and in a more manageable manner. Then I discovered the following:
4. The thing is to never open the CompizConfig Settings Manager. — Because I noticed that it will start changing settings right after it's started or when a user changes settings on their own. That way, I have been able to evade issues that cause/d the pointer to misbehave so terribly.
5. 04.08.2018 update:
   At some point, I realised, that since the touchpad is misbehaving, it would be saner to use an external pointing device, such as a USB mouse (or PS/2, or what have you). That doesn't fix the problem, but prevents usage of the touchpad.
6. The issues crop up less, but even using an external USB mouse is not perfect enough for uninterrupted work. Disconnecting the external mouse from the USB port, using the touchpad for a short while to resolve the pointer hang, and re-connecting the USB mouse may help.
   
7. Then I got the idea, that perhaps I should disable the touchpad entirely, because I'd occasionally touch it by accident, and it interefered with the pointer driven by the external mouse, forcing the pointer to get stuck again.
   Here I got very nice instructions as to how to disable a misbehaving pointing device: The output of xinput --list with the pointing devices that X has identified:

   Virtual core pointer                          id=2    [master pointer  (3)]
     ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
     ↳ Logitech USB RECEIVER                     id=9    [slave  pointer  (2)]
     ↳ PS/2 Generic Mouse                        id=11   [slave  pointer  (2)]
     ↳ SynPS/2 Synaptics TouchPad                id=12   [slave  pointer  (2)]
   

   • "Virtual core XTEST pointer" is the first, and should never be shut down, as it will cause X to restart, and lose any unsaved work.
   • Logitech USB RECEIVER is the wireless USB mouse. It's the first wireless laser mouse, and as such, the receiver is a separately mains-powered cradle that connects to the USB port.
   • PS/2 Generic Mouse. I can't tell, if it belongs to an external mouse, or is identified separately by X. Because it's not the external USB RECEIVER mouse, and not then touchpad.
   
   Follow the id= number of the device, and use that to enable/disable it with the respective console commands below:
   
   xinput --disble 12
   xinpute --enable 12
   
   — to shut off what one could think is the offending device. Instructions from here.
   
   Then again, disabling the TouchPad didn't work, and I was still stuck with a stuck pointer. Ugh.
   
8. 19.11.2018 update: Use a different window manager, such as twm.
   
   At first, I thought the erraticity of the Synaptics Touchpad to be because of LXDE and its use of Metacity. No.
   
   I'd somehow installed twm (Klaus Knopper gutted the CD-version of Knoppix 7.2 so much, that he omitted twm from it).
   
   Switching between twm and LXDE requires creating and then editing the local .xinitrc file, and then launching restartx to choose the correct window manager / desktop environment.
   
   In .xinitrc, the execution commands for twm and lxde are different: For twm, it's just
   
   twm
   
   ; For LXDE, it's
   
   exec startlxde
   
   For one window manager to be chosen via $ restartx, comment the other out with a hash # sign.
   
   And so I thought at first to be safe from the Erratic Synaptics Touchpad. Well, no. That still happened, but somehow less, and it was easier to escape the erraticity and non-responsiveness of the pointer. On the other hand, if the pointer did become sticky, I'd be stuck until I'd restartx, sometimes even via Ctrl+Alt+Backspace, if hovering over a terminal window in twm would no longer switch focus to it to allow retartx to happen. In console (as in, Ctrl+Alt+F1...F4), restartx would start, but wouldn't display. Ugh.
   
   But at least now I know, that it's the fault somewhere in the driver and how X handles it, and not directly with LXDE.