Bug 1095796

Bug #999098 mentioned above was reported against Leap 42.3 and is marked as fixed.

Steffen, can you check?

Stefan, are we missing some input drivers here?

No, but we have no fix for Christian's issue at the moment.

https://bugzilla.suse.com/show_bug.cgi?id=999098#c27

Ok. So the workaround here is to install the xf86-input-synaptics driver after installation in addition. Christian, you may want to test the kernel-of-the-day, so we can see whether the issue has been fixed in current kernels, so in the future libinput driver will work out-of-the-box.

Just this workaround for him to install xf86-input-synaptics driver after installation.

Hmm. But it seems there is no xf86-input-synaptics package any longer on Leap 15 (which is good!). So for me it seems, the kernel from installation is different than the one after installation. For whatever reasons. Or he is running a Wayland session after installation. During installation YaST is using still X.

Christian, could you verify, whether you're using Wayland OR X11 after installation? Output of

  ps aux | grep X

should tell us this.

If I may join in and offer some information as well... I have the same problem with my ThinkPad T450s, which currently runs Leap 42.3 without any problem.

The touchpad and trackpoint are both non-functional in LEAP 15.0 installer. Both devices are working if I boot the KDE Live CD version of LEAP 15.0

The same problem exists in Tumbleweed installer (snapshot 20180530) - neither touchpad nor trackpoint are working - and, similarly, both are working if I boot the Tumbleweed KDE live CD.

It does seem that there is a kernel difference between the LEAP 15.0 installer and the installed system:

LEAP 15.0 DVD (installer): 4.12.14-lp150.12.4-default (broken)
LEAP 15.0 KDE (live CD):   4.12.14-lp150.11-default (works)

Checking the same for Tumbleweed:

20180530 DVD installer: 4.16.12-default (broken)
20180530 KDE live CD:   4.16.12-1-default (works)

So in both cases it looks as if the kernel was revised in some way between the installer and the live system. I have not (yet) borrowed a mouse and gone ahead with the installation to see what happens when I boot an installed system instead of a live CD version or the installer.

Just to confirm, I am using X11, not Wayland.

Hi,
i will answer x vs. Wayland asap - for the Moment SSD and notebook are separater and out of Office. When i get my notebook back i will write an answer.

I font trink that it is the Kernel Version between Installation and After Installation, because i had the Same Problem in oder versions of leap Witz oder kernels.

Installation of sth AFTER Installation is Not needed - it works After Installation, Problem exists only while installation, using usb-mouse works in installation-system too!

For the Lenovo T450s there is bug 1095289; the next Tumbleweed release should
contain that fix (*after* 20180606). I've no idea whether this makes a difference here, too.

https://bugzilla.suse.com/show_bug.cgi?id=1095289#c2

makes a lot of sense to me. Could one not even test this easily via a DUD (driver update disk) via network?

Theoretically yes, but I don't have an explicit list of the modules. Easier is
to just wait for the next TW release.

The advice in the link mentioned by Stefan seems to be a viable workaround:

https://bugzilla.suse.com/show_bug.cgi?id=1095289#c2


I've tested this by grabbing the latest kernel-default from the Leap 15.0 update repository (kernel-default-4.12.14-lp150.12.4.1.x86_64.rpm) and using mksusecd as follows:

mksusecd -c leap_15.0_mod.iso --modules rmi_smbus.ko --kernel kernel-default-4.12.14-lp150.12.4.1.x86_64.rpm -- openSUSE-Leap-15.0-DVD-x86_64.iso

The resulting leap_15.0_mod.iso image boots the installer as normal and the T450s touchpad and trackpad are both working as expected.

I'll use my modified image for my installations now. Many thanks for the useful advice!

Cheers,
Laurence.

Well, but since the report is against Leap 15 I'm not sure the reporter is going to test an installation with TW ...

It's actually possible to use the TW net iso to do a Leap install.

Or add the modules required to the list and do comment 10. As said, I simply
don't know which module would be needed.

So this bug seems to be stuck in NEEDINFO. What are we going to do here?

AFAICS we need a machine with that touchpad or somebody who has access to such a machine who is willing to test things; otherwise I don't see how we can go forward with this bug.

It's unlikely we'll find such a machine. Probably best is to assume the issue has been fixed with Steffen's changes. Otherwise the reporter can reopen the bug again when trying to install Leap 15.1 in about a year or so.

here am I :-)

i tried the tw-snapshot-iso-dvd from 20180618 which showed the same behaviour.
Installation starts, internal TP (elantec, BIOS=advanced) not working, external mouse is OK. I aborted installation.

the installed leap 15-system runs X and without any special configuration works the internal TP.

root      1510  2.3  1.5 291964 60924 tty7     Ssl+ 12:16   0:08 /usr/bin/X -nolisten tcp -auth /run/sddm/{7068aa19-ec5a-4132-978c-047482c39353} -background none -noreset -displayfd 18 -seat seat0 vt7
salome    2743  0.0  0.0   8688   924 pts/0    S+   12:22   0:00 grep --color=auto X

the notebook (Acer Travelmate B116) is now complete and working again so I can provide technical information fast and easy

what is different in the configuration of the installation system compared to the installed system which doesnt have any TP problems...

Christian

Well, I'm not sure whether Steffen's changes are already in tw-snapshot-iso-dvd from 20180618 ...

https://lists.opensuse.org/opensuse-factory/2018-06/msg00252.html

The fix in this TW release.

Maybe it's time to compare /var/log/Xorg.0.log.

give me commands - i will post the results :-)

I didn't understand if another TW-version might have the last changes and to what X.log-files need to be compared.

I can download any version and test it

Steffen wanted to compare /var/log/Xorg.0.log from installation and from installed system. But I guess we then also need the list of loaded kernel modules to compare. So you would need to open a terminal somehow or get access to Linux console to type in commands and copy files to an USB stick. Not sure whether we have documented how this works somewhere ...

(In reply to Stefan Dirsch from comment #19)
> Steffen wanted to compare /var/log/Xorg.0.log from installation and from
> installed system. But I guess we then also need the list of loaded kernel
> modules to compare. So you would need to open a terminal somehow or get
> access to Linux console to type in commands and copy files to an USB stick.
> Not sure whether we have documented how this works somewhere ...

And this all also *during* installation!

Created attachment 774869 [details]
X.log - while installation (TP fail)

Created attachment 774870 [details]
X.log - running system (TP working)

Created attachment 774872 [details]
lsmod - running system (TP working)

Created attachment 774874 [details]
lsmod - installation system (TP fail)

I hope that this works for you for the moment - that was an easy task. I didnt copy X.log and lsmod from installation system while an external mouse is installed and working (only 2 USB ports (for external DVD, USB-Stick) and no usb hub at the moment availiable for the third usb device (mouse))

If you need more detailed versions let me know

Created attachment 774922 [details]
lsmod Diff

(In reply to Christian Lorch from comment #21)
> Created attachment 774869 [details]
> X.log - while installation (TP fail)

No pointer device detected.

(In reply to Christian Lorch from comment #22)
> Created attachment 774870 [details]
> X.log - running system (TP working)

[    14.212] (II) config/udev: Adding input device Logitech USB Receiver (/dev/input/event12)
[    14.212] (**) Logitech USB Receiver: Applying InputClass "evdev pointer catchall"
[    14.212] (**) Logitech USB Receiver: Applying InputClass "evdev pointer catchall"
[    14.212] (**) Logitech USB Receiver: Applying InputClass "libinput pointer catchall"
[    14.212] (II) Using input driver 'libinput' for 'Logitech USB Receiver'
[    14.212] (**) Logitech USB Receiver: always reports core events
[    14.212] (**) Option "Device" "/dev/input/event12"
[    14.212] (**) Option "_source" "server/udev"
[    14.273] (II) event12 - Logitech USB Receiver: is tagged by udev as: Mouse
[    14.273] (II) event12 - Logitech USB Receiver: device is a pointer
[    14.273] (II) event12 - Logitech USB Receiver: device removed
[    14.304] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:046D:C518.0002/input/input14/event12"
[    14.304] (II) XINPUT: Adding extended input device "Logitech USB Receiver" (type: MOUSE, id 10)

(In reply to Stefan Dirsch from comment #26)
> Created attachment 774922 [details]
> lsmod Diff

Could it be that 

  hid_generic 

is missing?

No, it's there,

Created attachment 774981 [details]
missing modules

Here's a list of modules that are loaded in the installed system but not in
the installation system and do not exist in the installation system.

Stefan, anything important in this list?

Created attachment 774984 [details]
not loaded modules

Maybe even more interesting, this is the list of modules that are loaded in
the installed system but not during installation but which *do* exist in
the installation system.

Those two hid_* modules stick out...

Christian, could you try to load the modules manually with modprobe?

For this, boot with startshell=1. This drops you into a bash prompt right before
the installer would have been started.

There, load the modules, then just run 'yast'. When you exit yast you're back
into the shell. You can repeat this as often as you want.

Please try the two hid_* modules from the list. Maybe replace '_' with '-' to
get the real module name if modprobe complains.

Does it improve things?

(In reply to Steffen Winterfeldt from comment #31)
> Created attachment 774981 [details]
> missing modules
> 
> Here's a list of modules that are loaded in the installed system but not in
> the installation system and do not exist in the installation system.
> 
> Stefan, anything important in this list?

No

(In reply to Steffen Winterfeldt from comment #33)
> Christian, could you try to load the modules manually with modprobe?
> 
> For this, boot with startshell=1. This drops you into a bash prompt right
> before
> the installer would have been started.
> 
> There, load the modules, then just run 'yast'. When you exit yast you're back
> into the shell. You can repeat this as often as you want.
> 
> Please try the two hid_* modules from the list. Maybe replace '_' with '-' to
> get the real module name if modprobe complains.
> 
> Does it improve things?

i tried modprobe hid-generic, hid_generic (and with _ instead of -), all 4 commands did show an error message.

hid-genericc resulted in FATAL: Modprobe hid-genericc not found in directory /libmodules/4.16.12-2-default

the internal TP didnt work - any other things to try?

(In reply to Stefan Dirsch from comment #28)
> (In reply to Christian Lorch from comment #22)
> > Created attachment 774870 [details]
> > X.log - running system (TP working)
> 
> [    14.212] (II) config/udev: Adding input device Logitech USB Receiver
> (/dev/input/event12)
> [    14.212] (**) Logitech USB Receiver: Applying InputClass "evdev pointer
> catchall"
> [    14.212] (**) Logitech USB Receiver: Applying InputClass "evdev pointer
> catchall"
> [    14.212] (**) Logitech USB Receiver: Applying InputClass "libinput
> pointer catchall"
> [    14.212] (II) Using input driver 'libinput' for 'Logitech USB Receiver'
> [    14.212] (**) Logitech USB Receiver: always reports core events
> [    14.212] (**) Option "Device" "/dev/input/event12"
> [    14.212] (**) Option "_source" "server/udev"
> [    14.273] (II) event12 - Logitech USB Receiver: is tagged by udev as:
> Mouse
> [    14.273] (II) event12 - Logitech USB Receiver: device is a pointer
> [    14.273] (II) event12 - Logitech USB Receiver: device removed
> [    14.304] (**) Option "config_info"
> "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:046D:C518.
> 0002/input/input14/event12"
> [    14.304] (II) XINPUT: Adding extended input device "Logitech USB
> Receiver" (type: MOUSE, id 10)

that mighty be from the additional external mouse (which is an old wireless logitech mouse), TP is elantech. shall i provide X.log and lsmod definitely w/o external device?

(In reply to Christian Lorch from comment #36)
> (In reply to Steffen Winterfeldt from comment #33)
> > Christian, could you try to load the modules manually with modprobe?
> > 
> > For this, boot with startshell=1. This drops you into a bash prompt right
> > before
> > the installer would have been started.
> > 
> > There, load the modules, then just run 'yast'. When you exit yast you're back
> > into the shell. You can repeat this as often as you want.
> > 
> > Please try the two hid_* modules from the list. Maybe replace '_' with '-' to
> > get the real module name if modprobe complains.
> > 
> > Does it improve things?
> 
> i tried modprobe hid-generic, hid_generic (and with _ instead of -), all 4
> commands did show an error message.
> 
> hid-genericc resulted in FATAL: Modprobe hid-genericc not found in directory
> /libmodules/4.16.12-2-default
> 
> the internal TP didnt work - any other things to try?

sorry: all 4 commands did NOT show an error message!

then I tried an obviously wrong module name hid-generic to generate an error message.

(In reply to Christian Lorch from comment #37)
> > [    14.304] (II) XINPUT: Adding extended input device "Logitech USB
> > Receiver" (type: MOUSE, id 10)
> 
> that mighty be from the additional external mouse (which is an old wireless
> logitech mouse), TP is elantech. shall i provide X.log and lsmod definitely
> w/o external device?

Aha! Yes, this would have been the purpose of this exercise ...

(In reply to Christian Lorch from comment #38)
> > i tried modprobe hid-generic, hid_generic (and with _ instead of -), all 4
> > commands did show an error message.
> > 
> > hid-genericc resulted in FATAL: Modprobe hid-genericc not found in directory
> > /libmodules/4.16.12-2-default
> > 
> > the internal TP didnt work - any other things to try?
> 
> sorry: all 4 commands did NOT show an error message!
> 
> then I tried an obviously wrong module name hid-generic to generate an error
> message.

Thanks for clarifying! So modules are there and can be loaded.

Created attachment 775015 [details]
lsmod - running system (TP working) w/o mouse

Created attachment 775016 [details]
X.log - running system (TP working) w/o mouse

Ok. Just noticed that you're using a 32bit medium for installation, but afterwards are running a 64 bit system. 

And for whatever reasons touchpad is not detected during installation. Maybe we need 

   /etc/X11/xorg.conf.d/40-libinput.conf

already during installation.

In case there is udevadm already available during installation you can run

  udevadm info -e 

and search for ID_INPUT_TOUCHPAD in the output.

Created attachment 775118 [details]
libinput.conf - installation system (TP not working)

Created attachment 775119 [details]
udevadm output - installation system (TP not working)

found some INPUT entrys, but nothing with TOUCH*

here is the complete output - hope that you find more information inside

(In reply to Stefan Dirsch from comment #43)
> Ok. Just noticed that you're using a 32bit medium for installation, but
> afterwards are running a 64 bit system. 
> 
> And for whatever reasons touchpad is not detected during installation. Maybe
> we need 
> 
>    /etc/X11/xorg.conf.d/40-libinput.conf
> 
> already during installation.

32bit can be ok, but I took the regular download LEAP or TW dvd-iso-file and didnt choose any special option (after booting the installation dvd I pressed only ENTER, ENTER, ENTER, ... or sometimes I changed Language or Videomode, nothing else)

Ok. IF the touchpad isn't detected during instllation - even not after loading the hid modules manually - matching on it in libinput.conf doesn't help either! Thanks for providing it. The content looks good so far.

Sorry, I'm runnin out of ideas ... :-(

No idea why this is still assigned to the installer after 48 comments. This problem is either in the kernel or in the X11 area.

(In reply to Stefan Hundhammer from comment #49)
> No idea why this is still assigned to the installer after 48 comments. This
> problem is either in the kernel or in the X11 area.

just to clearify: after installation (doesnt matter if with additional external mouse or with keyboard-only installation) everything works without changing anything!

can comment 11 from https://bugzilla.opensuse.org/show_bug.cgi?id=999100 lead to a solution? Some kind of bad initialisation of the system/hardware/installer?
Or UEFI/BIOS-Legacy/32bit/64bit?

(In reply to Stefan Hundhammer from comment #49)
> No idea why this is still assigned to the installer after 48 comments. This
> problem is either in the kernel or in the X11 area.

Well, it's related to installation system. I still believe it's related to some component missing during installation. But whatever ...

Most likely it's pinctrl_cherryview, which is missing during installation.

Christian, can you try?

(In reply to Steffen Winterfeldt from comment #53)
> Christian, can you try?

oh now, I forgot to answer...

I tried TW 20180618 startshell=1 and tried to modprobe pinctrl_cherryview, but that module was not found.

I tried some other modules with familar names like hid_cherry which I found in the modules folder, all of them got loaded without an error message, but no touchpad in yast...

(In reply to Christian Lorch from comment #54)
> (In reply to Steffen Winterfeldt from comment #53)
> > Christian, can you try?
> 
> oh now, I forgot to answer...
> 
> I tried TW 20180618 startshell=1 and tried to modprobe pinctrl_cherryview,
> but that module was not found.
> 
> I tried some other modules with familar names like hid_cherry which I found
> in the modules folder, all of them got loaded without an error message, but
> no touchpad in yast...

I found the exact names of the tried modules, all tried with - and _
hid_cherry
demux_pinctrl
mux_pinctrl

all of them got loaded but without bringing the touchpad to work...

(In reply to Christian Lorch from comment #54)
> (In reply to Steffen Winterfeldt from comment #53)
> > Christian, can you try?
> 
> oh now, I forgot to answer...
> 
> I tried TW 20180618 startshell=1 and tried to modprobe pinctrl_cherryview,
> but that module was not found.

Then that's the problem.  The GPIO / I2C can't be initialized without pinctrl driver on Cherry Trail devices.  You'd need to copy it from somewhere dynamically, e.g. from the net, or rebuild an ISO including the module...

Steffen would need to add it to installation-images package and then we would need a new ISO for testing ...

4.12.14-lp150.12.4-default>ls -l ./kernel/drivers/pinctrl/intel/
total 296
-rw-r--r-- 1 root root 56304 May 23 21:52 pinctrl-broxton.ko
-rw-r--r-- 1 root root 46272 May 23 21:52 pinctrl-cannonlake.ko
-rw-r--r-- 1 root root 62672 May 23 21:52 pinctrl-cherryview.ko
-rw-r--r-- 1 root root 17976 May 23 21:52 pinctrl-denverton.ko
-rw-r--r-- 1 root root 30096 May 23 21:52 pinctrl-geminilake.ko
-rw-r--r-- 1 root root 38472 May 23 21:52 pinctrl-intel.ko
-rw-r--r-- 1 root root 34376 May 23 21:52 pinctrl-sunrisepoint.ko

I would guess of those at least pinctrl-cherryview.ko would be needed.

Adding it as outlined in comment 10 should do the trick. Christian, can you try this?

(In reply to Steffen Winterfeldt from comment #58)
> 4.12.14-lp150.12.4-default>ls -l ./kernel/drivers/pinctrl/intel/
> total 296
> -rw-r--r-- 1 root root 56304 May 23 21:52 pinctrl-broxton.ko
> -rw-r--r-- 1 root root 46272 May 23 21:52 pinctrl-cannonlake.ko
> -rw-r--r-- 1 root root 62672 May 23 21:52 pinctrl-cherryview.ko
> -rw-r--r-- 1 root root 17976 May 23 21:52 pinctrl-denverton.ko
> -rw-r--r-- 1 root root 30096 May 23 21:52 pinctrl-geminilake.ko
> -rw-r--r-- 1 root root 38472 May 23 21:52 pinctrl-intel.ko
> -rw-r--r-- 1 root root 34376 May 23 21:52 pinctrl-sunrisepoint.ko
> 
> I would guess of those at least pinctrl-cherryview.ko would be needed.

Basically all these pinctrl-* drivers should be included in the installer.
They serve for different chipsets.  This particular bug is about Cherry Trail, but the similar problem would be seen on other chipsets.

... and on TW, there is yet another one (pinctrl-lewisburg), IIRC.

added these modules:

https://github.com/openSUSE/installation-images/pull/255

(In reply to Steffen Winterfeldt from comment #61)
> added these modules:
> 
> https://github.com/openSUSE/installation-images/pull/255

Reviewed.

Latest TW image contains this fix.

Subject: [opensuse-factory] New Tumbleweed snapshot 20180714 released!

[..]
==== installation-images-Kubic ====
Version update (14.377 -> 14.378)

- merge gh#openSUSE/installation-images#255
- add pinctrl-* modules (bsc#1095796)
- 14.378

So please test.

it works (tested it with latest tw-iso)
can you make sure that further leap-versions also use the solution?
not sure if it can be marked as fixed because I just tested it with TW.

It is my understanding, that we're going to fix this not only for TW (upcoming sle16/Leap16), but also for sle15-sp1/Leap 15.1. Steffen?

It will be fixed in all future releases (Leap 15.1 etc).

SUSE-RU-2019:1470-1: An update that has 9 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1040492,1095289,1095796,1099327,1103208,1106114,1108005,1108289,1108905
CVE References: 
Sources used:
SUSE Linux Enterprise Module for Basesystem 15 (src):    installation-images-SLED-14.385-3.3.2, installation-images-SLES-14.385-3.3.2

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

openSUSE-RU-2019:2025-1: An update that has 9 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1040492,1095289,1095796,1099327,1103208,1106114,1108005,1108289,1108905
CVE References: 
Sources used:
openSUSE Leap 15.0 (src):    installation-images-openSUSE-14.385-lp150.7.1

SUSE-RU-2019:1470-2: An update that has 9 recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 1040492,1095289,1095796,1099327,1103208,1106114,1108005,1108289,1108905
CVE References: 
Sources used:
SUSE Linux Enterprise Module for Open Buildservice Development Tools 15-SP1 (src):    installation-images-SLED-14.385-3.3.2, installation-images-SLES-14.385-3.3.2, installation-images-SLES_SAP-14.385-3.3.2
SUSE Linux Enterprise Module for Open Buildservice Development Tools 15 (src):    installation-images-SLES-14.385-3.3.2

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.