Indeed, caution is the better part of valor . . . mainly because patterns are “permanent” to an install and can’t be selectively removed, if after testing there would be no impact on the issue. In that sense easier to nuke a whole partition if it also fails to make a significant difference . . . .
Malcolm:
Alrighty, basic suggestion, which often times the most simple method will indeed handle some problems . . . but where does the “this is only happening with Leap” on a machine that I have the option of testing and comparing behaviors over 8 distros with a number of DEs, problem being exclusive to Leap after observing for the last few weeks . . . come into it??? Leap 16 is more sensitive to dirt on its optical mice than the other kids???
@non_space I only run openSUSE products, something I noticed the other day on GNOME with Leap 16.0 cleaned the mouse and mouse pad and all is good…
Are all other systems, using the same kernel, same Mesa version, same libinput etc. It’s all very subjective without information. Are any kernel modules using the same parameters etc. Since it seems your using X11, the respective Xorg config for synaptics settings.
Indeed, very hard to compare “apples to apples” . . . even if only in openSUSE, in my case TW . . . likely nothing would be the same. But, a recurring issue in a single system, exclusively so far, points to . . . “a recurring issue in that system.” The question remains as to the why of it . . . .
But, OK, right, in the olden days there were adjustments that had to be made in the Xorg.config file in PPC linux that had to be done “in the black” of the console to get basic display function . . . gladly those days are long gone.
But, what exactly would we be looking for as far as synaptic settings . . . which as per Deano he is saying Leap uses “libinput” . . . what would I be running in the console to take a look, and what would be “the clue” to look for on it???
@deano_ferrari Sorry, I missed this post last night/this morning
host:~> grep -i "Using input driver" /var/log/Xorg.0.log
[ 9.531] (II) Using input driver 'libinput' for 'Power Button'
[ 9.568] (II) Using input driver 'libinput' for 'Video Bus'
[ 9.607] (II) Using input driver 'libinput' for 'Power Button'
[ 9.632] (II) Using input driver 'libinput' for 'Matias Keyboard Matias Wired Keyboard'
[ 9.649] (II) Using input driver 'libinput' for 'Matias Keyboard Matias Wired Keyboard'
[ 9.673] (II) Using input driver 'libinput' for 'HID 1bcf:08a0 Mouse'
[ 9.709] (II) Using input driver 'libinput' for 'HID 1bcf:08a0 Keyboard'
[ 9.735] (II) Using input driver 'libinput' for 'Logitech USB Headset Logitech USB Headset'
[ 9.782] (II) Using input driver 'libinput' for 'HID 1bcf:08a0 Keyboard'
Only in the above search did I “check Xorg.conf,” it’s been almost 20 years since I had to mess with Xorg in PPC linux . . . so no retention of the details on that front. But, running your suggested three commands, shows they are not installed?
host:~> xinput list
The program 'xinput' can be found in the following package:
* xinput [ path: /usr/bin/xinput, repository: openSUSE:repo-oss ]
Try installing with:
sudo zypper install xinput
host:~> libinput list-devices
The program 'libinput' can be found in the following package:
* libinput-tools [ path: /usr/bin/libinput, repository: openSUSE:repo-oss ]
Try installing with:
sudo zypper install libinput-tools
host:~> libinput debug-events
The program 'libinput' can be found in the following package:
* libinput-tools [ path: /usr/bin/libinput, repository: openSUSE:repo-oss ]
Try installing with:
sudo zypper install libinput-tools
I didn’t intend for you to run this now, although it gives you the idea and confirmation that libinput is used by default.
After installing the synaptics package and restarting the X-server (or rebooting), you can run it again to check that the pointing device is now being handled by the synaptics Xorg driver. (It is possible to edit the config files to pick which devices are handled by synaptics, but only worry about that if needed when the time comes.)
OK, another aspect of this problem again appeared, which I had forgotten about, on revival from sleep the mouse cursor was “frozen” and did not respond to mouse movements. I had to unplug and then replug the usb mouse in and movement returned. You can see in the “debug” data that small movements of the mouse are recorded there, I cut the list short when I could see each movement of the mouse was adding a line to the data . . . .
The libinput debugging suggests that kernel > libinput handling is working reliably - the mouse is not frozen at the input stack level at least. If the desktop experience is still “glitchy” with respect to mouse movements and typing within GUI apps, it points higher up the stack towards Xorg input handling, or XFCE (xfwm4) itself perhaps.
Trying xf86-input-synaptics might still be worth a shot as a diagnostic step, since it removes libinput from the X11 input path entirely. That said, I’d be surprised if it materially improves the behaviour. Given that you also described erratic typing, focus, and cursor movement within text widgets, this points much more toward the Xorg/desktop layer (xfwm4, focus handling) than to a mouse or touchpad driver as such.
Given the long-standing Xorg quirks around suspend/resume in some desktop environments, testing a Wayland session would be useful purely for comparison. It removes Xorg from the stack and helps determine whether the issue is X11-specific or more fundamental.
OK, thanks for the follow up on it . . . I would prefer to have a more concrete idea of what the problem is before adding more and more packages and/or patterns to just “see if it works,” rather what is the clear diagnosis??
Seemingly if the synaptics gambit is likely to not make a difference, then for now I think going with the fresh install of Leap 16 with experimental Wayland session seems to be the next step . . . into which then I could add the X session . . . and then if none of that turns anything up that disk could just be nullified . . . .
And then anything learned from that effort could be introduced into my current Leap 15.5/16 install . . . .
As far as the “revival from suspend in X” I did have repeat visits with that problem, traced to the nvidia driver . . . one of the reasons why in this machine I went with Ryzen cpu inboard graphics, etc.
Also “no problems” with suspend/revive here . . . no swap partition, running 32GB RAM in lieu of swap. That was just mentioned by Deano as an indication of the numerous problems historically affecting X . . . making a possible link to the present issue with X as the culprit . . . . Hence his mentioning of wayland numerous times throughout this discussion . . . .
Latest update: Running the new install of Leap 16, migrated from 15.6 . . . so far only one “glitch” noticed yesterday, when reviving from suspend the mouse “froze” for a bit, and then “unfroze” . . . .
So, hard to know if the fresh install had moved past some package that was causing problems . . . OR, it is just lulling me into submission until it decides to go “glitchy.”
Meaning I am waiting to install Wayland on this system, until such time as problems crop up.
OK . . . as reported on the Chat thread, while typing frantically into the thread I had what is now the second “glitch” event, where pressing keyboard the typing stopped as I continued to push the keys, and then couldn’t re-position the cursor to re-enter the words.
Does it affect all applications, or only particular applications when typing?
Does switching to another VT (Ctrl+Alt+F2, then back) restore input responsiveness (even temporarily)?
Watch the messaging with journalctl --user -fin a terminal window, and note/capture what is reported when issues are evident. That might yield more definitive info. You could simultaneously watch system messaging in another terminal with sudo journalctl -f
