As per the summary. The touchpad in the installer was completely unresponsive as regards moving the mouse cursor or using the buttons. There is only the single touchpad, but harddrake2 lists two devices: 1) Atmel Atmel maXTouch Digitizer Vendor ID: 0x03eb Device ID: 0x8ab1 Bus: USB Module: mouse0 2) ELAN1300:00 04F3:3028 Touchpad Vendor ID: 0x04f3 Device ID: 0x3028 Module: mouse1 A USB mouse worked during both the install and in the installed system.
CC: (none) => marja11Assignee: bugsquad => mageiatools
The installer may be missing some libinput files. But we would need the installer logs as usual... (/root/drakx/report.bug.xz)
Keywords: (none) => NEEDINFOCC: (none) => thierry.vignaud
(I was thinking about /usr/lib/udev/hwdb.d/90-libinput-model-quirks.hwdb)
Created attachment 8974 [details] report.bug.xz
Keywords: NEEDINFO => (none)
Please attach (not paste) the output of lspcidrake from the installed system (in order to compare with the output from the installer logs). Also please attach the output of the /sbin/lsmod command. We might lack a hid driver (not probable but who knows...) Last but not least, please provide the output of libinput-list-devices?
Keywords: (none) => NEEDINFO
Created attachment 8976 [details] lspcidrake
Created attachment 8977 [details] lsmod
Created attachment 8978 [details] libinput-list-devices
humm... Could you also attach the output of dmesg on the installed system?
Created attachment 8982 [details] dmesg
commit da3fbca1326c9e013902929a679cffa528fa8d1e Author: Thierry Vignaud <thierry.vignaud@...> Date: Thu Mar 2 10:24:03 2017 +0100 list input & HID devices in report.bug (mga#20327) --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=da3fbca1326c9e013902929a679cffa528fa8d1e
commit 7fb691c667686a96e8b96d29e891c67e72a2e6b8 Author: Thierry Vignaud <thierry.vignaud@...> Date: Tue Mar 7 11:55:16 2017 +0100 include libinput-list-devices (mga#20327) --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=7fb691c667686a96e8b96d29e891c67e72a2e6b8
Can you attach installer's libinput-list-devices from a recent netinstall? (it now includes it). Or even better, the report.bug.xz of a new install which now list HID & input devices :-)
Created attachment 9065 [details] report.bug from current test Touchpad still does not respond.
I can confirm this bug for Mageia 6 RC. The touchpad works fine with the Plasma 64-bit Live DVD. But during the install with the 64-bit Classical Installer DVD the touchpad didn't respond at all. I had to attach a mouse. After the installation the mousepad worked fine. Information in mcc about my mousepad: Connexion Identifiant du fabricant: 0x04f3 Identifiant du périphérique: 0x3059 Fonctionnalités Molette émulée: Non Divers Fabricant: Description: ELAN1300:00 04F3:3059 Touchpad Module: mouse0
CC: (none) => ed1
As stated in comment #12, please attach installer's libinput-list-devices from a recent install? (it's not logged)
Created attachment 9364 [details] log output of libinput-list-devices I guess I should have go with sg like this (untested)
I haven't tested this lately and won't be able to for some time as that machine is damaged...
commit 45f902d20d5ce559e0b1f468f8fc33465ecf2e00 Author: Thierry Vignaud <thierry.vignaud@...> Date: Tue May 30 18:25:31 2017 +0200 log output of libinput-list-devices (mga#20327) --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=45f902d20d5ce559e0b1f468f8fc33465ecf2e00
Created attachment 9366 [details] Output of libinput-list-devices This is the output of libinput-list-devices on my notebook.
Created attachment 9454 [details] include udev's hwdb Could you test this patch?
@Thomas, Remi, Colin: this is a regression from Mga5 I think my patch should fix it. WDYT? Should we include it for mga6?
CC: (none) => mageia, rverschelde, tmb
@Franck,Béat,any_reporter: Can you check if temporary moving those files in eg /root and restarting the system does enable to reproduce the bug on the real system: /usr/lib/udev/hwdb.d/69-libmtp.hwdb /usr/lib/udev/hwdb.d/20-usb-vendor-model.hwdb /usr/lib/udev/hwdb.d/20-usb-media-players.hwdb /usr/lib/udev/hwdb.d/90-libinput-model-quirks.hwdb /usr/lib/udev/hwdb.d/60-evdev.hwdb /usr/lib/udev/hwdb.d/60-keyboard.hwdb
The machine in question got an unintended bath and is out getting its power button assembly replaced. It should be back in a week, but that's probably not in time for release testing.
Machine is back, but seeing the same problem with an install from today's cauldron. Did your patch get moved ? I got to the initial stage2 screen (languages), saw the touchpad failure, and flipped to tty2. There is a mounted /usr/lib/udev directory, but it has no hwdb.d subdirectory, just: ata_id libinput-device-group libinput-model-quirks pcmcia-socket-startup rules.d scsi_id
One step backward in current cauldron: now the touchpad doesn't work in the booted new system (sddm) as well. There isn't even a visible mouse cursor.
(In reply to Frank Griffin from comment #24) > Machine is back, but seeing the same problem with an install from today's > cauldron. Did your patch get moved ? > No, Thierry's patch only exists in our Bugzilla, it was never committed, because it needed to be tested: (In reply to Thierry Vignaud from comment #20) > Created attachment 9454 [details] > include udev's hwdb > > Could you test this patch? and Thierry did also ask: (In reply to Thierry Vignaud from comment #22) > @Franck,Béat,any_reporter: > Can you check if temporary moving those files in eg /root and restarting the > system does enable to reproduce the bug on the real system: > /usr/lib/udev/hwdb.d/69-libmtp.hwdb > /usr/lib/udev/hwdb.d/20-usb-vendor-model.hwdb > /usr/lib/udev/hwdb.d/20-usb-media-players.hwdb > /usr/lib/udev/hwdb.d/90-libinput-model-quirks.hwdb > /usr/lib/udev/hwdb.d/60-evdev.hwdb > /usr/lib/udev/hwdb.d/60-keyboard.hwdb (Maybe I misunderstand the question, but this implies that this bug only occurs in VBox installs and such, correct?) I think this issue should go into the errata now. https://wiki.mageia.org/en/Mageia_6_Errata Frank, do you mind adding it and then replacing the "FOR_ERRATA6" keyword with "IN_ERRATA6"? (In reply to Frank Griffin from comment #25) > One step backward in current cauldron: now the touchpad doesn't work in the > booted new system (sddm) as well. There isn't even a visible mouse cursor. Ouch! I can't imagine that's the same bug, though... do you mind filing a separate one and attaching the "journalctl -b" output (as root)?
Keywords: (none) => FOR_ERRATA6
(In reply to Frank Griffin from comment #25) > One step backward in current cauldron: now the touchpad doesn't work in the > booted new system (sddm) as well. There isn't even a visible mouse cursor. I'll hold off on this, because I suspect that the person who reassembled the laptop didn't properly reconnect the ribbon cable for the touchpad.
(In reply to Marja van Waes from comment #26) > and Thierry did also ask: > > (In reply to Thierry Vignaud from comment #22) > > @Franck,Béat,any_reporter: I addressed this above; those files do not exist. > > (Maybe I misunderstand the question, but this implies that this bug only > occurs in VBox installs and such, correct?) No, this is real hardware. > > I think this issue should go into the errata now. > https://wiki.mageia.org/en/Mageia_6_Errata > Frank, do you mind adding it and then replacing the "FOR_ERRATA6" keyword > with "IN_ERRATA6"? I tried, but no go. The wiki won't let me log in with my Mageia ID, but when I try to recreate the ID it complains it's already in use.
rpm -qf /usr/lib/udev/hwdb.d/90-libinput-model-quirks.hwdb /usr/lib/udev/hwdb.d/60-keyboard.hwdb /usr/lib/udev/hwdb.d/20-usb-vendor-model.hwdb libinput-udev-1.8.0-0.1.mga6 systemd-230-12.mga6 systemd-230-12.mga6 So if you don't have those files, your system is pretty corrupted
(In reply to Thierry Vignaud from comment #29) > rpm -qf /usr/lib/udev/hwdb.d/90-libinput-model-quirks.hwdb > /usr/lib/udev/hwdb.d/60-keyboard.hwdb > /usr/lib/udev/hwdb.d/20-usb-vendor-model.hwdb > libinput-udev-1.8.0-0.1.mga6 > systemd-230-12.mga6 > systemd-230-12.mga6 > > So if you don't have those files, your system is pretty corrupted The problem occurs at the start of stage 2, not in a running system, so I assumed your directions referred to the filesystem at the start of stage 2. Maybe the fact that they're missing is the cause of the problem ?
I specifically write "on the real system". I do know they're not in the installer as my patch's goal is to add them there...
(In reply to Thierry Vignaud from comment #31) > I specifically write "on the real system". "on the installed system" would have been easier for me to understand ;-) > I do know they're not in the installer as my patch's goal is to add them > there...
(In reply to Thierry Vignaud from comment #21) > @Thomas, Remi, Colin: this is a regression from Mga5 > I think my patch should fix it. > WDYT? > Should we include it for mga6? So, in the end, has the patch been included or is the regression still present and worth an errata entry?
commit 102339802fe667e53d517f522d24bb9e4c652019 Author: Thierry Vignaud <thierry.vignaud@...> Date: Sun Jul 2 16:39:00 2017 +0200 include part of udev's hwdb (mga#20327) Let's hope it fixes touchpad in installer. Such a missing file might also explain why adding the udev rule wasn't enough for mga#20074. --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=102339802fe667e53d517f522d24bb9e4c652019 Bug links: Mageia https://bugs.mageia.org/20327 https://bugs.mageia.org/20074
(In reply to Samuel Verschelde from comment #33) > So, in the end, has the patch been included or is the regression still > present and worth an errata entry? Nope, I would not have blindly an untested patch while we were frozen...
I had the same problem today on a Lenovo Ideapad 320. May I help?
CC: (none) => mageia
This is still happening, and now on a brand new Asus machine. Ping ?
Can you paste the logs of an install with latest Cauldron?
Created attachment 10255 [details] report.bug from install on Asus laptop Here you go.
Created attachment 10256 [details] include more HID/I2C modules (mga#20327) Could you try building drakx-installer-images with that patch & boot the resulting iso image in the generated RPM?
I'm not getting very far with this, probably because I don't know what I'm doing. I created a ~/rpm directory structure and downloaded the SRPM to SRPMS. I put your patch in SOURCES as test.diff. I then did an "rpm -ivh" from SRPMS and an "rpmbuild -ba" from SPECS, but I get a lot of absent dependencies. When pull them down and try to build them, b43-tools fails. Should I be using urpmi to install the dependencies on the real system rather than trying to build them in ~/rpm ?
yes; just use "sudo urpmi SPECS/*spec"
That helped. urpmi installed everything successfully. Then I started from scratch, did an "rpmbuild --rebuild" on the SRPM to unpack the RPM, then added your patch starting with the "---a/kernel" line to SOURCES/test.patch. I edited the spec file to add "Patch0: test.patch" after "Source0" and "%patch0 -p1" after "%autosetup" and ran "rpmbuild -ba". But it complains that the patch is reversed or previously applied: ################################################################## Executing(%prep): /bin/sh -e /home/ftg/rpm/tmp/rpm-tmp.aKMdK0 + umask 022 + cd /home/ftg/rpm/BUILD + '[' 1 -eq 1 ']' + '[' 1 -eq 1 ']' + '[' 1 -eq 1 ']' + cd /home/ftg/rpm/BUILD + rm -rf drakx-installer-images-2.50 + /usr/bin/xz -dc /home/ftg/rpm/SOURCES/drakx-installer-images-2.50.tar.xz + /usr/bin/tar -xof - + STATUS=0 + '[' 0 -ne 0 ']' + cd drakx-installer-images-2.50 + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . + /usr/bin/cat /home/ftg/rpm/SOURCES/test.patch + /usr/bin/patch -p1 -s --fuzz=0 --no-backup-if-mismatch + echo 'Patch #0 (test.patch):' Patch #0 (test.patch): + /usr/bin/patch --no-backup-if-mismatch -p1 --fuzz=0 patching file kernel/list_modules.pm Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 2 out of 2 hunks ignored -- saving rejects to file kernel/list_modules.pm.rej error: Bad exit status from /home/ftg/rpm/tmp/rpm-tmp.aKMdK0 (%prep) RPM build errors: Bad exit status from /home/ftg/rpm/tmp/rpm-tmp.aKMdK0 (%prep) ################################################################ What am I doing wrong ?
> I edited the spec file to add "Patch0: test.patch" after "Source0" and "%patch0 -p1" after "%autosetup" and ran "rpmbuild -ba". But it complains that the patch is reversed or previously applied: `%autosetup -p1` already applies all patches listes as `Patch#`, so you shouldn't use `%patch0 -p1` afterwards. (You would need it if it was `%setup` instead of `%autosetup`, the latter is a recent adding to RPM packaging to simplify the %prep step.
Ah, that makes sense. I haven't played with rpm in a while. Thanks for the pointers.
OK, the patch built correctly, but the behavior's still the same. I found the libinput xorg.conf.d in /usr/shae/X11/xorg.conf.d and the touchpad section is present and looks correct (except for not enabling tap-to-click :-) ), so it's not that. I'll attach the new report.bug.
Created attachment 10261 [details] report.bug after patch
This is still failing in current cauldron. As we're not in freeze, could you commit this patch yourself just to be sure I didn't screw it up, and I'll retest ?
Actually I already did the day before on 25th :-)
I retested with this morning's cauldron, and the touchpad is still unresponsive :-(
Can you provide lsmod output from when it works in an installed system ?
[root@ftglap data]# lsmod Module Size Used by sr_mod 28672 0 usb_storage 73728 0 iptable_filter 16384 0 dm_zero 16384 0 cmac 16384 1 rfcomm 86016 14 rpcsec_gss_krb5 40960 0 nfsv4 679936 3 nfs 307200 9 nfsv4 fscache 405504 2 nfsv4,nfs ip_vs 208896 0 nf_conntrack 147456 1 ip_vs af_packet 45056 6 bnep 24576 2 vboxnetadp 28672 0 vboxnetflt 32768 0 vboxdrv 487424 2 vboxnetadp,vboxnetflt dm_mirror 28672 0 dm_region_hash 16384 1 dm_mirror dm_log 20480 2 dm_region_hash,dm_mirror dm_mod 151552 3 dm_zero,dm_log,dm_mirror arc4 16384 2 snd_soc_skl 118784 0 joydev 24576 0 intel_rapl 24576 0 uvcvideo 110592 0 snd_soc_skl_ipc 73728 1 snd_soc_skl x86_pkg_temp_thermal 16384 0 intel_powerclamp 16384 0 coretemp 16384 0 snd_soc_sst_ipc 16384 1 snd_soc_skl_ipc videobuf2_vmalloc 16384 1 uvcvideo videobuf2_memops 16384 1 videobuf2_vmalloc snd_soc_sst_dsp 36864 1 snd_soc_skl_ipc kvm_intel 233472 0 snd_hda_ext_core 28672 1 snd_soc_skl videobuf2_v4l2 28672 1 uvcvideo videobuf2_common 53248 2 videobuf2_v4l2,uvcvideo snd_soc_acpi 16384 1 snd_soc_skl iwlmvm 339968 0 kvm 724992 1 kvm_intel hid_multitouch 24576 0 btusb 53248 0 snd_soc_core 258048 1 snd_soc_skl videodev 212992 3 videobuf2_v4l2,uvcvideo,videobuf2_common spi_pxa2xx_platform 28672 0 8250_dw 16384 0 hid_generic 16384 0 btrtl 16384 1 btusb btbcm 16384 1 btusb mac80211 823296 1 iwlmvm btintel 24576 1 btusb bluetooth 593920 41 btrtl,btintel,btbcm,bnep,btusb,rfcomm iTCO_wdt 16384 0 snd_hda_codec_hdmi 57344 1 iTCO_vendor_support 16384 1 iTCO_wdt irqbypass 16384 1 kvm crct10dif_pclmul 16384 0 media 45056 2 videodev,uvcvideo crc32_pclmul 16384 0 snd_hda_codec_generic 86016 1 crc32c_intel 24576 6 snd_compress 24576 1 snd_soc_core ghash_clmulni_intel 16384 0 ac97_bus 16384 1 snd_soc_core iwlwifi 249856 1 iwlmvm ecdh_generic 24576 2 bluetooth snd_hda_intel 45056 6 pcbc 16384 0 snd_hda_codec 151552 3 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel aesni_intel 200704 2 aes_x86_64 20480 1 aesni_intel snd_hda_core 94208 6 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_soc_skl crypto_simd 16384 1 aesni_intel snd_hwdep 16384 1 snd_hda_codec cfg80211 774144 3 iwlmvm,iwlwifi,mac80211 cryptd 28672 3 crypto_simd,ghash_clmulni_intel,aesni_intel glue_helper 16384 1 aesni_intel snd_pcm 147456 8 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_soc_core,snd_soc_skl,snd_hda_core intel_cstate 16384 0 intel_uncore 135168 0 snd_timer 36864 1 snd_pcm mei_me 45056 0 intel_rapl_perf 16384 0 ipmi_devintf 20480 0 snd 98304 20 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_compress,snd_soc_core,snd_pcm idma64 20480 2 virt_dma 16384 1 idma64 mei 110592 1 mei_me soundcore 16384 1 snd asus_nb_wmi 28672 0 asus_wmi 32768 1 asus_nb_wmi i2c_i801 32768 0 processor_thermal_device 16384 0 intel_lpss_pci 20480 0 sparse_keymap 16384 1 asus_wmi intel_pch_thermal 16384 0 intel_lpss 16384 1 intel_lpss_pci input_leds 16384 0 rfkill 28672 9 asus_wmi,bluetooth,cfg80211 intel_soc_dts_iosf 16384 1 processor_thermal_device wmi_bmof 16384 0 tpm_crb 16384 0 thermal 20480 0 tpm_tis 16384 0 tpm_tis_core 20480 1 tpm_tis ac 16384 0 tpm 65536 3 tpm_tis,tpm_crb,tpm_tis_core int3400_thermal 16384 0 evdev 24576 31 int3403_thermal 16384 0 acpi_thermal_rel 16384 1 int3400_thermal asus_wireless 16384 0 int340x_thermal_zone 16384 2 int3403_thermal,processor_thermal_device battery 24576 0 rng_core 16384 1 tpm acpi_pad 16384 0 vboxguest 40960 0 cuse 16384 3 fuse 118784 4 cuse nfsd 421888 13 auth_rpcgss 73728 2 nfsd,rpcsec_gss_krb5 nfs_acl 16384 1 nfsd lockd 118784 2 nfsd,nfs grace 16384 2 nfsd,lockd nvram 16384 0 sunrpc 430080 38 nfsd,nfsv4,auth_rpcgss,lockd,rpcsec_gss_krb5,nfs_acl,nfs sch_fq_codel 20480 5 ip_tables 28672 1 iptable_filter x_tables 45056 2 iptable_filter,ip_tables ipv6 524288 192 ip_vs crc_ccitt 16384 1 ipv6 autofs4 49152 2 ipmi_msghandler 61440 1 ipmi_devintf nouveau 2174976 0 xhci_pci 16384 0 xhci_hcd 266240 1 xhci_pci usbcore 294912 5 xhci_hcd,usb_storage,uvcvideo,btusb,xhci_pci ttm 122880 1 nouveau serio_raw 16384 0 usb_common 16384 1 usbcore i915 1720320 13 i2c_hid 24576 0 mxm_wmi 16384 1 nouveau hid 139264 3 i2c_hid,hid_multitouch,hid_generic i2c_algo_bit 16384 2 i915,nouveau drm_kms_helper 188416 2 i915,nouveau video 45056 3 asus_wmi,i915,nouveau wmi 28672 4 asus_wmi,wmi_bmof,mxm_wmi,nouveau button 16384 2 i915,nouveau drm 454656 16 drm_kms_helper,i915,ttm,nouveau
No offence, but you could've added that output to a document and added that as an attachment.
CC: (none) => hamnisdude
Sorry, Kristoffer, I didn't think it was that large.
Still happening in current cauldron.
I think I am experimenting the same bug on a new laptop. Model: Lenovo V330-15IKB Model name: 81AX I tried to install Mga7-beta2 (from Mageia-7-beta2-x86-64.iso dated Jan. 30th) but I couldn't proceed with the installer because the touchpad was unresponsive. I finally installed Mga6.1 from the Live Plasma iso. To finish, I booted on Mageia-7-beta2-Live-Plasma-x86_64.iso and the touchpad worked perfectly. That's why I ended up with the same conclusion that the touchpad is not recognized by the installer, but works after the system is installed. I'm also sending 3 files with the results of: - lsmod - lspcidrake - libinput-list-devices (all from Mga6.1) I will not have access to this computer very often, so please be patient if you need more info... sorry about that!
CC: (none) => sebsweb
Created attachment 10741 [details] Result of lsmod on the Lenovo laptop
Created attachment 10742 [details] Result of lspcidrake on the Lenovo laptop
Created attachment 10743 [details] Result of libinput-list-devices on the Lenovo laptop
I haven't tried an install recently, but from the dat on comment#56 this is still happening.
The common modules between the 2 lsmod that we miss in installer are: ghash_clmulni_intel GHASH Message Digest Algorithm, accelerated by PCLMULQDQ-NI i2c_algo_bit I2C-Bus bit-banging algorithm "I2C bit-banging interfaces" intel_lpss_pci Intel LPSS PCI driver "Intel Low Power Subsystem support in PCI mode" -> unrelated shpchp (unrelated, now a builtin anyway & actually disabled in latest kernel builds anyway) So I would bet my money on i2c_algo_bit which I'm going to add to installer images
Can you try with yesterday's boot.iso?
(In reply to Thierry Vignaud from comment #63) > Can you try with yesterday's boot.iso? I dont think you added the fix... I only see a rel bump: http://svnweb.mageia.org/packages/cauldron/drakx-installer-images/current/SPECS/drakx-installer-images.spec?r1=1378639&r2=1378638&pathrev=1378639
arg. I'm really uploading the new version now...
I'm away for a week, but I'll test when I get back.
And to be clear, please test images from install/images/. eg: http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/install/images/ Images must be not earlier than March 19th
Ping?
I made an install with Mageia Beta 3. The problem is still there. The touchpad didn't work during the install and I had to use a mouse. After the install the touchpad worked normally.
I'll try this later today with cauldron.
Sorry to say, but using the X86_64 nonfree network install image in cauldron from Apr. 19, it still fails.
hum... As you own the hardware, could you compare the output of lsmod on your machine in the installer & in the installed system? Then try to rmmod one by one the modules that are loaded in the installed system but are not loaded in the installer? In order to find out if it's a missing module and if yes, which one? Else I wonder if we're missing some udev rule or some udev hwdb file or some libinput file...
I'm uploading a new stage2 with a fix for libinput quirks Can you try that one once it reachs your mirror? If it still doesn't work, then you can try the above rmmod trials in order to find out any missing kernel module for your touchpad.
Created attachment 10970 [details] [PATCH] include the whole hwdb (mga#20327) You could also try to rebuild drakx-installer-stage2 with this patch to see if the issue is a missing hwdb udev file. Though you would need to overwrite x86_64/install/stage2/mdkinst.sqfs on some local mirror Or you could just create a fake mirror with VERSION & install/stage2/mdkinst.sqfs See bug#4724 comment#c17 (https://bugs.mageia.org/show_bug.cgi?id=4724#c17) That should be enough to get stage2 up. You wouldn't be able to install of course but you could still test the touchpad on the license, language & keyboard steps at least
You can try the stage2 I uploaded this morning: http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/install/stage2/ install/stage2/VERSION must contains "18.14". eg: http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/install/stage2/VERSION Can you test this one before trying rmmod or my patch?
OK, I tested with the 18.14-1 stage2, still no joy. Comparing lsmod from the install and the live system, here's what's in the install system but not in the live: Module Size Used by dm_zero 16384 0 ide_cd_mod 40960 0 ide_core 131072 1 ide_cd_mod psmouse 176128 0 squashfs 69632 1 loop 36864 2 sr_mod 28672 0 uas 28672 0 usb_storage 81920 1 uas and here's what's in the live but not the install: Module Size Used by rfcomm 90112 14 rpcsec_gss_krb5 40960 0 nfsv4 696320 3 nfs 319488 6 nfsv4 fscache 409600 2 nfsv4,nfs ip_vs 204800 0 nf_conntrack 147456 1 ip_vs nf_defrag_ipv6 24576 2 nf_conntrack,ip_vs nf_defrag_ipv4 16384 1 nf_conntrack vboxnetadp 28672 0 bnep 28672 2 vboxnetflt 32768 0 vboxdrv 487424 2 vboxnetadp,vboxnetflt arc4 16384 2 joydev 28672 0 uvcvideo 114688 0 intel_rapl 28672 0 8250_dw 20480 0 x86_pkg_temp_thermal 20480 0 intel_powerclamp 20480 0 hid_multitouch 28672 0 spi_pxa2xx_platform 32768 0 coretemp 20480 0 kvm_intel 278528 0 snd_soc_skl 118784 0 mei_hdcp 24576 0 kvm 733184 1 kvm_intel snd_soc_hdac_hda 24576 1 snd_soc_skl iTCO_wdt 16384 0 irqbypass 16384 1 kvm iTCO_vendor_support 16384 1 iTCO_wdt crc32_pclmul 16384 0 snd_hda_ext_core 36864 2 snd_soc_hdac_hda,snd_soc_skl snd_soc_skl_ipc 69632 1 snd_soc_skl snd_soc_sst_ipc 20480 1 snd_soc_skl_ipc snd_hda_codec_hdmi 69632 1 snd_soc_sst_dsp 40960 1 snd_soc_skl_ipc ghash_clmulni_intel 16384 0 snd_soc_acpi_intel_match 28672 1 snd_soc_skl snd_soc_acpi 16384 2 snd_soc_acpi_intel_match,snd_soc_skl snd_hda_codec_generic 90112 1 ledtrig_audio 16384 1 snd_hda_codec_generic snd_soc_core 270336 2 snd_soc_hdac_hda,snd_soc_skl input_leds 16384 0 snd_compress 28672 1 snd_soc_core wmi_bmof 16384 0 ac97_bus 16384 1 snd_soc_core snd_hda_intel 49152 6 snd_hda_codec 155648 4 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_soc_hdac_hda snd_hda_core 102400 7 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_soc_hdac_hda,snd_soc_skl snd_hwdep 16384 1 snd_hda_codec intel_cstate 16384 0 intel_uncore 135168 0 ipmi_devintf 20480 0 intel_rapl_perf 16384 0 mei_me 45056 1 idma64 20480 2 virt_dma 20480 1 idma64 mei 118784 3 mei_hdcp,mei_me intel_xhci_usb_role_switch 16384 0 intel_lpss_pci 20480 0 roles 16384 1 intel_xhci_usb_role_switch processor_thermal_device 16384 0 intel_lpss 16384 1 intel_lpss_pci intel_soc_dts_iosf 20480 1 processor_thermal_device intel_pch_thermal 16384 0 ac 16384 0 int3403_thermal 16384 0 int340x_thermal_zone 16384 2 int3403_thermal,processor_thermal_device tpm_crb 20480 0 tpm_tis 16384 0 tpm_tis_core 24576 1 tpm_tis tpm 73728 3 tpm_tis,tpm_crb,tpm_tis_core int3400_thermal 20480 0 acpi_thermal_rel 16384 1 int3400_thermal asus_wireless 20480 0 thermal 20480 0 acpi_pad 20480 0 nfsd 430080 13 vboxsf 36864 0 vboxguest 45056 1 vboxsf cuse 16384 3 fuse 122880 4 cuse auth_rpcgss 102400 2 nfsd,rpcsec_gss_krb5 nfs_acl 16384 1 nfsd lockd 114688 2 nfsd,nfs grace 16384 2 nfsd,lockd nvram 16384 0 sch_fq_codel 20480 1 sunrpc 446464 34 nfsd,nfsv4,auth_rpcgss,lockd,rpcsec_gss_krb5,nfs_acl,nfs ip_tables 32768 0 x_tables 49152 1 ip_tables autofs4 53248 2 ipmi_msghandler 61440 1 ipmi_devintf nouveau 2244608 0 ttm 114688 1 nouveau i915 1789952 30 i2c_algo_bit 16384 2 i915,nouveau drm_kms_helper 208896 2 i915,nouveau button 20480 1 nouveau drm 471040 21 drm_kms_helper,i915,ttm,nouveau I don't see anything in live that suggests mouse or touchpad handling, but I notice that the install has psmouse loaded but not the live. Is it possible that mice and touchpads are now handled by the kernel and psmouse is getting in the way ?
We're getting down to the wire on this since it can't be fixed for MGA7 after release....
Thierry, we do force load psmouse in installer since we switched to modular psmouse... But as we now use udev in installer, should we do this ? (same question goes for evdev) diff --git a/perl-install/install/install2.pm b/perl-install/install/install2.pm index bd037cf04..466d7c580 100644 --- a/perl-install/install/install2.pm +++ b/perl-install/install/install2.pm @@ -736,9 +736,6 @@ sub main { # perl_checker: require install::steps_stdio require "install/steps_$o->{interactive}.pm" if $o->{interactive}; - # psmouse is now modular: - eval { modules::load("psmouse") }; - #- FIXME loading evdev should prevent crash of following line eval { modules::load("evdev") };
Could that really be an issue? From what I read in bug #15660, I'm not sure it would be unusable. If yes, yeah we could kill that line. After all psmouse provides aliases usable by udev... And we do include all rules that talk about serio aliases @Franck: could you try building & test a stage2 with the above patch? @tmb: or maybe should we just kill that line & upload a new stage2...
@Thierry I can try, but my expertise at rebuilding RPMs with patches has been suspect in the past. If you don't object to uploading a new stage2, that would be preferable, and would also allow the others (both here and in bug#24833 ) to test as well.
*** Bug 24833 has been marked as a duplicate of this bug. ***
CC: (none) => unruh
I tested the patch from comment 78 on a machine affected by this bug. The psmouse module wasn't loaded when I ran the installer, but the touch pad still didn't work.
Good & Bad. What's nice: we've someone which knows how to hack drakx & can reproduce the bug. Could you try attachment #10970 [details] from comment #74 ? (modulo s!hwdb.d/6"!hwdb.d/"!)
Attachment 9454 is obsolete: 0 => 1
Attachment 10256 is obsolete: 0 => 1
May not be the same root cause for me. In my working system, the elan_i2c kernel module is being used, and that's not available in the installer. I'll try adding it.
In Frank's list of modules on the live system I also notice hid_multitouch
CC: (none) => pterjan
(In reply to Pascal Terjan from comment #85) > In Frank's list of modules on the live system I also notice hid_multitouch That one is included in the installer. I tried loading it, but it didn't help.
Does the installer use an xorg.conf ? If so, perhaps the touchpad section is incorrect, and the problem isn't a driver at all.
Adding the elan_i2c module gives me a working touchpad in the installer. But on reviewing the comments, that's unlikely to help anyone else.
(In reply to Frank Griffin from comment #87) > Does the installer use an xorg.conf ? If so, perhaps the touchpad section > is incorrect, and the problem isn't a driver at all. Sorry, this has been outstanding for so long that I forgot I raised this (and tried to address it) in comment#46.
(In reply to Thierry Vignaud from comment #83) > Could you try attachment #10970 [details] from comment #74 ? > (modulo s!hwdb.d/6"!hwdb.d/"!) Tested this locally, and it has no obvious ill effects. Should we just push this out for people to try?
(In reply to Martin Whitaker from comment #90) > (In reply to Thierry Vignaud from comment #83) > > Could you try attachment #10970 [details] from comment #74 ? > > (modulo s!hwdb.d/6"!hwdb.d/"!) > > Tested this locally, and it has no obvious ill effects. Should we just push > this out for people to try? Please do. Looking at "grep -i touchpad /usr/lib/udev/hwdb.d/*", it's likely 90-libinput-model-quirks.hwdb, but given the small size of the contents of the entire directory, having the other files shouldn't hurt.
CC: (none) => davidwhodgins
I doubt it. We don't write input sections in xorg.conf, we are now just relying on udev & libinput for *all* input devices, http://gitweb.mageia.org/software/drakx/commit/?id=10bfe94d200738adda8a2e8981f2ae65712376d3 (which did bring support for some touchpads whereas we previously didn't supported them)
(I was obviously referring to adding input sections to xorg.conf)
(In reply to Dave Hodgins from comment #91) > Please do. Looking at "grep -i touchpad /usr/lib/udev/hwdb.d/*", it's likely > 90-libinput-model-quirks.hwdb, but given the small size of the contents of > the entire directory, having the other files shouldn't hurt. Note that we already include all files mentionning input (but for 90-libinput-model-quirks.hwdb which doesn't exist) We do already include /usr/lib/udev/rules.d/90-libinput-model-quirks.rules too
We don't include /usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb though. And from Frank's attachment 8982 [details]: [ 0.480807] pci 0000:00:15.1: [8086:9d61] type 00 class 0x118000 [ 12.893548] intel-lpss 0000:00:15.1: enabling device (0000 -> 0002) [ 15.432043] input: ELAN1300:00 04F3:3028 Touchpad as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-ELAN1300:00/0018:04F3:3028.0005/input/input14 and from /usr/lib/udev/hwdb.d/20-pci-vendor-model.hwdb pci:v00008086d00009D61* ID_MODEL_FROM_DATABASE=Sunrise Point-LP Serial IO I2C Controller #1 In Frank's attachment 9065 [details] there's no sign of the intel-lpss driver being active.
I've added all of /usr/lib/udev/hwdb.d to the installer stage2. But looking at the kernel modules available in the installer, intel-lpss is not present - nor is anything else from kernel/drivers/mfd. So we may need to add more stuff.
Yeah, I think we need to add the intel-lpss ones ... @Martin: As I cant do it right now... Can you add them to drakx and roll new drakx-installer* packages for RC ? I think I have one affected laptop here so I will try to test the same, but I wont have time to test it yet, so ...
OK, intel-lpss* added in drakx-installer-images-2.62-1. Those affected by this bug can test whether this helps when the new netinstall images reach the mirrors. I've respun the RC ISOs to include this.
Please NO! Read comment #62
(In reply to Thierry Vignaud from comment #99) > Please NO! > Read comment #62 Read comment 95. If we don't have the driver for the I2C controller, it's very unlikely we will be able to use the I2C peripherals attached to it.
Eureka ! Working now.
OK I stand corrected.
Status: NEW => RESOLVEDResolution: (none) => FIXED
I have to point out that it took me a while to figure out that this had more to do with the stage 1 ISO than the stage 2 package. So, I didn't reburn the boot ISO every time I tested. It's possible that the now-working code was the result of multiple fixes, some of which may have been unnecessary. If you want to back them out one by one, I'll be happy to retest to see what actually did it. @Martin could you describe the process you used to test your interim solutions so we can adopt these tests for the next time ? I had no confidence in what I did way back when because it didn't work and I couldn't be sure if that was because the fix was bad or I had screwed it up.
During the install of Mageia 7 RC I was able use the mousepad without problem. Thanks for fixing this bug.