Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux.slackware > #35649 > unrolled thread

Laptop mousepad not recognized after -current installed

Back to article view | Back to alt.os.linux.slackware

Contents

  Laptop mousepad not recognized after -current installed John Forkosh <forkosh@panix.com> - 2026-06-27 08:24 +0000
    Re: Laptop mousepad not recognized after -current installed John Forkosh <forkosh@panix.com> - 2026-06-27 10:18 +0000
      Re: Laptop mousepad not recognized after -current installed Sylvain Robitaille <syl@therockgarden.ca> - 2026-06-27 13:09 +0000
        Re: Laptop mousepad not recognized after -current installed Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-06-27 18:22 -0300
        Re: Laptop mousepad not recognized after -current installed John Forkosh <forkosh@panix.com> - 2026-06-28 06:17 +0000
          Re: Laptop mousepad not recognized after -current installed Sylvain Robitaille <syl@therockgarden.ca> - 2026-06-28 14:43 +0000
            Re: Laptop mousepad not recognized after -current installed John Forkosh <forkosh@panix.com> - 2026-06-29 09:02 +0000
              Re: Laptop mousepad not recognized after -current installed Sylvain Robitaille <syl@therockgarden.ca> - 2026-06-29 19:58 +0000
            Re: Laptop mousepad not recognized after -current installed Sylvain Robitaille <syl@therockgarden.ca> - 2026-06-29 19:37 +0000

#35649 — Laptop mousepad not recognized after -current installed

I've recently done some clean installs of Slack15.1x64-current,
downloaded 3/26/26, kernel 6.18.20. So far, installed it
on four desktops and one laptop. No problems whatsoever.
  Yesterday installed it on a second laptop, a Teclast F5r.
Install itself went as smoothly as ever, as far as I could tell.
But upon rebooting, mousepad was not recognized at all.
  It's physically working for sure -- it still works perfectly
when I instead boot from the partition with previous install, 
Slack15.0x64-current, downloaded 8/18/21, kernel 5.13.11.
  I compared and checked everything I could think of
between the two, e.g., rc.gpm is set up as -t imps2 for both,
etc. Then I had a bright idea -- booted from the Slacklive
usb stick that I'd also downloaded 3/26/26. Same mousepad
problem, not recognized at all. A little mouse pointer shows up
in the middle of the slacklive screen after booting and
logging in as "live", but the pointer just sits there
no matter what I do on the mousepad.
  So I'm guessing what would typically be the last thing
I'd guess -- something different between the two releases
is no longer supporting the particular mousepad on this
particular laptop.
  Anybody have any similar experience? Or any idea what
to further check, and/or how to get it working? Thanks,
-- 
John Forkosh

[toc] | [next] | [standalone]

#35650

John Forkosh <forkosh@panix.com> wrote:
<<snip>>
>   Anybody have any similar experience? Or any idea what
> to further check, and/or how to get it working? Thanks,

Not fixed (not by a long shot), but maybe a hint.
After further googling, I took a look at
  /lib/modules/6.18.20/kernel/drivers/mouse/   2026 non-working
versus
  /lib/modules/5.13.11/kernel/drivers/mouse/   2021 working
And they're indeed different. So I tried a little experiment:
  cd /lib/modules/6.18.20/kernel/drivers/      in new 2026 partition
  mv mouse mouse_6.18.20
  mkdir mouse_5.13.11
  rsync -av /mnt/lib/modules/5.13.11/kernel/drivers/mouse/  mouse_5.13.11/
  ln -s mouse_5.13.11/ mouse
That is, I made a copy of the old/working mouse drivers
in the new/non-working drivers/ directory, and linked to it.
Then rebooted.

Are you anxiously waiting to hear what happened with bated breath??? :) ...
  Well, mousepad is now recognized, sort of.
  If you touch it in any way at all, mouse cursor uselessly jumps all
  over the place, and continues to jump until you remove your finger.

The corresponding psmouse sources seem to be in
  /usr/src/linux-6.18.20/drivers/input/mouse/    (or linux-5.13.11)
The psmouse.h headers are identical except for one line:
  struct psmouse *psmouse_from_serio(struct serio *serio);
  is at line#133 in the 6.18.20 version, but not in the 5.13.11 version.
The psmouse-base.c files are more noticeably different,
and beyond my ken to try to explain here.

Don't know what any of this all means, but hoping it's
a step in the right direction.
-- 
John Forkosh

[toc] | [prev] | [next] | [standalone]

#35651

On 2026-06-27, John Forkosh wrote:

> Not fixed (not by a long shot), but maybe a hint.

You're definitely on the right track with looking closely at the kernel
drivers.  That's certainly where I am imagining you'll find the cause
of your problem.  I would be comparing dmesg output on both working
and non-working installations, to see if that can provide more insight.

Try "dmesg | grep -is synaptics" in each case and see how they differ.
Probably also worth trying "dmesg | grep -is mouse" and "dmesg |
grep -is touchpad", though they may each offer less insight.

It might also be easier to save the entire dmesg output in each case
to a different system, so you can compare them specifically.

"dmesg > /tmp/dmesg.working" and "dmesg > /tmp/dmesg.notworking"; copy
/tmp/dmesg.working and /tmp/dmesg.notworking to a different system, then

  diff -uwp /tmp/dmesg.working /tmp/dmesg.notworking |more

and examine the output carefully.  You'll likely spot some key
differencees, one or more of which might help you pinpoint a solution to
your touchpad problem.

I hope that this helps.

-- 
----------------------------------------------------------------------
Sylvain Robitaille                                syl@therockgarden.ca
----------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#35653

Sylvain Robitaille <syl@therockgarden.ca> writes:

> On 2026-06-27, John Forkosh wrote:
> 
> > Not fixed (not by a long shot), but maybe a hint.
> 
> You're definitely on the right track with looking closely at the kernel
> drivers.  That's certainly where I am imagining you'll find the cause
> of your problem.  I would be comparing dmesg output on both working
> and non-working installations, to see if that can provide more insight.
> 
> Try "dmesg | grep -is synaptics" in each case and see how they differ.
> Probably also worth trying "dmesg | grep -is mouse" and "dmesg |
> grep -is touchpad", though they may each offer less insight.

Ah, Synaptics.  I never did get a Synaptics mouse pad to work w/ Slack
14.2 on an Acer E17 despite lots of time wasted on trying.  Maybe
Synaptics is trying way too hard to produce the latest, coolest thing?

Probably just as well.  It's a "clickpad", no buttons; you rock the
pad for buttons 1 & 2.  No way to do button 3.  I'm happier with a
little USB dongle and 3-button wireless mouse.



-- 
Mike Spencer                  Nova Scotia, Canada

[toc] | [prev] | [next] | [standalone]

#35654

Sylvain Robitaille <syl@therockgarden.ca> wrote:
>
> John Forkosh wrote:
>> Not fixed (not by a long shot), but maybe a hint.
> 
> You're definitely on the right track with looking closely at the kernel
> drivers.  That's certainly where I am imagining you'll find the cause
> of your problem.  I would be comparing dmesg output on both working
> and non-working installations, to see if that can provide more insight.
> 
> Try "dmesg | grep -is synaptics" in each case and see how they differ.
> Probably also worth trying "dmesg | grep -is mouse" and "dmesg |
> grep -is touchpad", though they may each offer less insight.
> 
> It might also be easier to save the entire dmesg output in each case
> to a different system, so you can compare them specifically.
> 
> "dmesg > /tmp/dmesg.working" and "dmesg > /tmp/dmesg.notworking"; copy
> /tmp/dmesg.working and /tmp/dmesg.notworking to a different system, then
> 
>   diff -uwp /tmp/dmesg.working /tmp/dmesg.notworking |more
> 
> and examine the output carefully.  You'll likely spot some key
> differencees, one or more of which might help you pinpoint a solution to
> your touchpad problem.
> 
> I hope that this helps.

Yes, immensely (but, unfortunately, not completely). See below.

And, very appropriately (also see below) Mike Spencer followed up with...
> Ah, Synaptics.  I never did get a Synaptics mouse pad to work w/ Slack
> 14.2 on an Acer E17 despite lots of time wasted on trying.  Maybe
> Synaptics is trying way too hard to produce the latest, coolest thing?
>    Probably just as well.  It's a "clickpad", no buttons; you rock the
> pad for buttons 1 & 2.  No way to do button 3.  I'm happier with a
> little USB dongle and 3-button wireless mouse.

"Ah, Synaptics", indeed! And  dmesg  indeed produced a lot of
useful output. That got me googling, finding some additional
suggestions to try  libinput  which produced an easier-to-read
synopsis, indeed identifying -- you guessed it -- Synaptics.
Below's a synopsis of the libinput synopsis,
i.e., libinput|grep Device   and then I manually added
      a few of the details for the "SYNA" devices

From older, working 5.13.11 kernel...
Device:           Video Bus
Device:           Lid Switch
Device:           Power Button
Device:           USB Camera: USB Camera
Device:           SYNA3602:00 0911:5288 Touchpad
   Kernel:        /dev/input/event8
   Group:         5
   Seat:          seat0, default
   Size:          91x53mm
   etc
Device:           SYNA3602:00 0911:5288 Mouse
   Kernel:        /dev/input/event7
   Group:         5
   Seat:          seat0, default
   etc
Device:           Goodix Capacitive TouchScreen
Device:           Intel HID events
Device:           Intel HID 5 button array
Device:           AT Translated Set 2 keyboard

From newer, non-working 6.18.20 kernel...
Device:           Video Bus
Device:           Lid Switch
Device:           Power Button
Device:           SYNA3602:00 0911:5288 Touchpad
   Kernel:        /dev/input/event7
   Id:            i2c:0911:5288
   Group:         4
   Seat:          seat0, default
   Size:          91x53mm
   etc
Device:           Goodix Capacitive TouchScreen
Device:           Intel HID events
Device:           Intel HID 5 button array
Device:           AT Translated Set 2 keyboard

Note how both recognize the "SYNA3602:00 0911:5288 Touchpad",
but the "SYNA3602:00 0911:5288 Mouse" is completely absent
from 6.18.20 (it's also missing the "USB Camera", but that's
not particularly important for me).
   And 6.18.20 has that "Id:" field (for every Device),
that's not given for any of the 5.13.11 Devices.
Could that be confusing 6.18.20, e.g., maybe Touchpad
and Mouse have been assigned the same Id, causing 6.18.20
to ignore the second such Device (the Mouse)?
   Adding to that, note that on 5.13.11 both Touchpad and
Mouse have the same "Group: 5". But other than that,
on both 5.13.11 and 6.18.20, every listed Device is given
a sequential Group:#, starting with Group:1 (and 6.18.20's
Touchpad is Group:4, rather than 5, simply because it's missing
the USB Camera). So, could the same Group:# for Touchpad and
Mouse be further confusing 6.18.20?

Anyhow, with your and Mike's focus on Synaptics,
and libinput's output confirming "SYNA...",
I further tried googling
    SYNA3602:00 0911:5288 not working on linux laptop
which coughs up pages of hits. Some suggest an existing
patch, e.g.,
    https://bugzilla.kernel.org/show_bug.cgi?id=198627
    points to
       https://patchwork.kernel.org/patch/10046575/
but complains, "that patch didn't solve the problem in my laptop."
So, I'm probably just going to leave that laptop booting 5.13.11,
unless you guys know of a patch that works, or some other solution.
In any event, thanks so much for all your help, which at least
identified the problem.
-- 
John Forkosh

[toc] | [prev] | [next] | [standalone]

#35655

On 2026-06-28, John Forkosh wrote:

> So, I'm probably just going to leave that laptop booting 5.13.11,
> unless you guys know of a patch that works, or some other solution.
> In any event, thanks so much for all your help, which at least
> identified the problem.

You might have mentioned this already, and if you have but I've simply
forgotten, I do apologize ... since you're looking at a 6.18.x kernel,
is this perhaps a Slackware-current system?  (... though the fallback
to 5.13.x certainly suggests otherwise ...)

I'm asking because I have Slackware-current on a system on which I'm
unable to use the pre-packaged 6.18.x (and presumably the 7.x kernels
in testing, but I've not tried those) kernels because I'm unable to
build the device driver for my (hardware) RAID controller on them.
I haven't taken the time to dig into why that's happening ... I
don't actually need the newer kernel for anything on this system.
So on that system, I stick with Linux-6.12.x kernels, updating to
whichever version is latest available when I do my routine patching.
The kernels are built using Slackware's kernel build scripts, so they
build into "proper" Slackware packages, just at version 6.12.x.

This approach might be useful to you as well, permitting you to
nudge your kernel version up some.  Perhaps the 5.15.x kernels from
Slackware-15.0?, or the 6.12.x kernels from before current moved
to 6.18.x could get you a newer kernel while still fully supoorting
your touchpad.

It's a thought that might help, anyway ...

-- 
----------------------------------------------------------------------
Sylvain Robitaille                                syl@therockgarden.ca
----------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#35663

Sylvain Robitaille <syl@therockgarden.ca> wrote:
> John Forkosh wrote:
> 
>> So, I'm probably just going to leave that laptop booting 5.13.11,
>> unless you guys know of a patch that works, or some other solution.
>> In any event, thanks so much for all your help, which at least
>> identified the problem.
> 
> You might have mentioned this already, and if you have but I've simply
> forgotten, I do apologize ... since you're looking at a 6.18.x kernel,
> is this perhaps a Slackware-current system?  (... though the fallback
> to 5.13.x certainly suggests otherwise ...)

Yeah, both -current, at least at time of downloading: original post
refers to them as
       "Slack15.1x64-current, downloaded 3/26/26, kernel 6.18.20"
and to "Slack15.0x64-current, downloaded 8/18/21, kernel 5.13.11"
And if it's of any interest, I've always been downloading from
   http://mirrors.kernel.org/slackware/slackware64-current/
using rsync in the form
   rsync://mirrors.kernel.org/slackware/slackware64-current/  \
   slackware64-current-yyyymmdd/
to an empty directory with yyyymmdd set to the then-current date.
Finally, to get the bootable usb stick used for install,
I execute usbimg2disk.sh (which you have to chmod 755 yourself)
in the usb-and-pxe-installers/ directory. Has always worked great.
Never any problems (before this), at least none that I ran into,
though (as you discuss below) I suppose there were likely some
bugs that I didn't run into.
   Oh, and no need to apologize, whatsoever...
   But don't let it happen again :)

> I'm asking because I have Slackware-current on a system on which I'm
> unable to use the pre-packaged 6.18.x (and presumably the 7.x kernels
> in testing, but I've not tried those) kernels because I'm unable to
> build the device driver for my (hardware) RAID controller on them.
> I haven't taken the time to dig into why that's happening ... I
> don't actually need the newer kernel for anything on this system.
> So on that system, I stick with Linux-6.12.x kernels, updating to
> whichever version is latest available when I do my routine patching.
> The kernels are built using Slackware's kernel build scripts, so they
> build into "proper" Slackware packages, just at version 6.12.x.
> 
> This approach might be useful to you as well, permitting you to
> nudge your kernel version up some.  Perhaps the 5.15.x kernels from
> Slackware-15.0?, or the 6.12.x kernels from before current moved
> to 6.18.x could get you a newer kernel while still fully supoorting
> your touchpad.
> 
> It's a thought that might help, anyway ...

Thanks again, Sylvain. It had briefly crossed my mind to try
installing some intermediate (between 2021 and 2026) -currents that
I still have lying around in several of those "yymmdd" directories
mentioned above. I'd updated several other PCs, but never bothered
with that little Teclast. I use it for precisely one purpose:
I like reading (and making marginal notes in, etc) technical books
and papers in hard copy form. But it's extremely useful to be able
to search them while you're reading, which can't be done in hardcopy.
So I always keep a pdf (sometimes ps) of whatever I'm reading
displayed on the Teclast. And the firefox version it has is fine
for that purpose (though https://www.mozilla.org/en-US/firefox/linux/
allows easy upgrades without affecting anything else -- it comes
complete with all its own libs). So in all likelihood, in my case
and for my purpose, I'll just leave the Teclast booting 5.13.11.
-- 
John Forkosh

[toc] | [prev] | [next] | [standalone]

#35668

On 2026-06-29, John Forkosh wrote:

> ... if it's of any interest, I've always been downloading from
>    http://mirrors.kernel.org/slackware/slackware64-current/
> using rsync in the form
>    rsync://mirrors.kernel.org/slackware/slackware64-current/  \
>    slackware64-current-yyyymmdd/
> to an empty directory with yyyymmdd set to the then-current date.
> Finally, to get the bootable usb stick used for install,
> I execute usbimg2disk.sh (which you have to chmod 755 yourself)
> in the usb-and-pxe-installers/ directory. Has always worked great.

... or (skipping the chmod step),
"sh /path/to/usb-and-pxe-installers/usbimg2disk.sh", but I digress ...

In contrast, I keep a local mirror of slackware-current, updated
nightly, also with rsync, but don't make me look up the script to
find the exact command used ...

The mirror, accessible to a PXE-boot server then serves as my
installation source, and during patch-cycle updates, the source location
for my update script.  My mirror doesn't actually delete previous
versions of packages as newer versions come in.  This *is* -current,
so I want to be able to easily revert if a new package breaks something.

... but because of that, I needed to slightly modify
usr/lib/setup/slackinstall in the installer's miniroot environment,
to use only the highest numbered version of any given package it's
installing.  I'm not sure that you want to know how I realized that
I had overlooked that otherwise when I tell the installer to install
"kernel-generic" (for example, and among the many other packages
selected at installation time) it will gleefully try to install *every*
instance of ".../a/kernel/kernel-generic-*.t?z" that it finds ...

Anyway, so I always have an -up-to-date -current mirror, with the
ability to easily back out of any package updates. I can mostly
treat and update the -current system(s) in the same manor that I do
for the stable systems, but I do not have the "snapshot" state of
-current that you have from any given day. ... and I don't need to
make any bootable USB drives.  I just boot by PXE and install over
the network.  It's mostly working well.

-- 
----------------------------------------------------------------------
Sylvain Robitaille                                syl@therockgarden.ca
----------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#35667

On 2026-06-28, I wrote:

> I'm asking because I have Slackware-current on a system on which I'm
> unable to use the pre-packaged 6.18.x (and presumably the 7.x kernels
> in testing, but I've not tried those) kernels because I'm unable to
> build the device driver for my (hardware) RAID controller on them.
> I haven't taken the time to dig into why that's happening ...

... and by the end of the same day, I'd made progress on that very
thing!

In case anyone else is using a HighPoint RocketRaid
RR640L RAID controller on a Slackware system and
would like to update to a kernel newer than the 6.12.x
versions, I've put a patch for their device driver at
https://github.com/syl-robitaille/HighPoint-RR640L-Linux-Driver-Update

I hope that it's useful to someone.

-- 
----------------------------------------------------------------------
Sylvain Robitaille                                syl@therockgarden.ca
----------------------------------------------------------------------

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.linux.slackware

csiph-web