|
Bugzilla – Full Text Bug Listing |
| Summary: | ElanTech Touchpad not working | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 13.1 | Reporter: | Sverre Moe <sverre.moe> |
| Component: | X.Org | Assignee: | E-mail List <xorg-maintainer-bugs> |
| Status: | RESOLVED UPSTREAM | QA Contact: | E-mail List <xorg-maintainer-bugs> |
| Severity: | Major | ||
| Priority: | P2 - High | CC: | bwiedemann, forgotten_9iTWBKwBCB, forgotten_j4V1xdTU7G, forgotten_wm10pd-IdS, forgotten_zSqj9GjxKD, tiwai |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 13.1 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
Various touchpad information
Xorg.0.log from Factory Live Patch for ElanTech touchpads Patch for elantech.c Patch for elantech.h dmesg output Patch to add support for Fujitsu Lifebook U745 patch to add nomux for U745 |
||
The problem is still persistent on these kernels: kernel-desktop-3.15.1-1 kernel-desktop-3.15.1-2 (now running on) device appears in Xorg log, so it might not be a kernel problem Created attachment 600177 [details]
Xorg.0.log from Factory Live
Tried running OpenSUSE Factory Live ISO from USB stick. It has the latest Xorg which is 1.16.0. Still the Touchpad did not work.
Attachment Xorg.0.log from running the Factory Live.
I have tried several suggestion found online Since psmouse is built-in I reckon the following does not work rmmod psmouse && modprobe psmouse Adding one of the following options to /etc/modprobe.d/psmouse.conf options psmouse proto=bare options psmouse proto=imps options psmouse proto=exps My latest attempt was to add the following to the kernel command line on boot: psmouse.force_elantech=1 It didn't work either. I found a kernel bug report regarding this same issue with ElanTech touchpad on a Fujitsu H730. https://bugzilla.kernel.org/show_bug.cgi?id=48161 I have also tried to run Live USB with the latest Ubuntu, Fedora and Linux Mint. The Touchpad didn't work in any of them. There was previous a fix in xf86-input-synaptics for Elantech v3 touchpads: http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=704c0fa3b677d5d648d0ab9d65cd03043797f3bf I can confirm I am using a version of this package that contains this fix (v1.7.1). I believe (unconfirmed) that I have v4 of Elantech touchpad. I have come over a temporary workaround that works on my Fujitsu H730 laptop. Recompile a kernel with the following: # disable under Device Drivers -> Input device support -> Mice -> PS/2 mouse ->Elantech PS/2 protocol extension The general idea is to avoid detection of the elantech protocol. If the kernel is no longer detecting the elantech touchpad the new touchpad is no longer the issue and X11 takes a surrogate. In this case a PS2 wheel mouse. *** Bug 898051 has been marked as a duplicate of this bug. *** FYI, passing modprobe.d for psmouse option doesn't work because psmouse driver is built-in for SUSE kernels. You have to pass psmouse.proto=bare or whatever in the boot option. (In reply to Takashi Iwai from comment #9) > FYI, passing modprobe.d for psmouse option doesn't work because psmouse > driver is built-in for SUSE kernels. You have to pass psmouse.proto=bare or > whatever in the boot option. I have tried that option as well. It didn't work. I have tried =imps, =bare and =exps in kernel boot option. I remember I tried using psmouse.proto=bare in the kernel boot options. However I tried again now, with kernel 3.16.4 and it worked. The touchpad now works fine. Is there any recent improvement regarding this issue? The v4 ElanTech touchpad in my Fujitsu U745 ultrabook does not work with kernel versions available in 13.2, and it is quite annoying to apply a patch after every kernel update to make my touchpad functional. Opensuse 13.2 kernel version 3.16.7-29 does not support this touchpad. I tried Fedora 23 live (kernel v4.3.2) but that did not seem to work either. Can someone confirm that Leap supports v4 ElanTech touchpads? Just try the newer (e.g. Leap) kernel on 13.2 system. It shouldn't break anything, and you can remove it if it doesn't help. Kernel 4.1.12 (vanilla) does not help, no support for this touchpad. (In reply to Balazs Nagy from comment #14) > Kernel 4.1.12 (vanilla) does not help, no support for this touchpad. Which machine are you using? Fujitsu H730 is supported in 4.1.x. Fujitsu T725 seems some fix in addition in 4.2. Also, there is another fix for pre-v4 elantech device in 4.2. Both patches look easy to backport, so I can prepare a test kernel later, once when you confirmed that it works with 4.2 kernel. (In reply to Takashi Iwai from comment #15) > (In reply to Balazs Nagy from comment #14) > > Kernel 4.1.12 (vanilla) does not help, no support for this touchpad. > > Which machine are you using? Fujitsu H730 is supported in 4.1.x. > > Fujitsu T725 seems some fix in addition in 4.2. Also, there is another fix > for pre-v4 elantech device in 4.2. Both patches look easy to backport, so I > can prepare a test kernel later, once when you confirmed that it works with > 4.2 kernel. I have a Fujitsu U745. I use the patch (psmouse-elantech-v7right.tar.bz2) described in this thread: http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linux It works fine with kernel versions 3.16.X and also with 4.1.12-3. (In reply to Balazs Nagy from comment #16) > (In reply to Takashi Iwai from comment #15) > > (In reply to Balazs Nagy from comment #14) > > > Kernel 4.1.12 (vanilla) does not help, no support for this touchpad. > > > > Which machine are you using? Fujitsu H730 is supported in 4.1.x. > > > > Fujitsu T725 seems some fix in addition in 4.2. Also, there is another fix > > for pre-v4 elantech device in 4.2. Both patches look easy to backport, so I > > can prepare a test kernel later, once when you confirmed that it works with > > 4.2 kernel. > > I have a Fujitsu U745. > I use the patch (psmouse-elantech-v7right.tar.bz2) described in this thread: > http://superuser.com/questions/619582/right-elantech-touchpad-button-not- > working-in-linux > It works fine with kernel versions 3.16.X and also with 4.1.12-3. Please report *this* to upstream. It must be handled there at first, then we can backport the fixes. So, what's not working in your case is only about the right button? (In reply to Takashi Iwai from comment #17) > (In reply to Balazs Nagy from comment #16) > > (In reply to Takashi Iwai from comment #15) > > > (In reply to Balazs Nagy from comment #14) > > > > Kernel 4.1.12 (vanilla) does not help, no support for this touchpad. > > > > > > Which machine are you using? Fujitsu H730 is supported in 4.1.x. > > > > > > Fujitsu T725 seems some fix in addition in 4.2. Also, there is another fix > > > for pre-v4 elantech device in 4.2. Both patches look easy to backport, so I > > > can prepare a test kernel later, once when you confirmed that it works with > > > 4.2 kernel. > > > > I have a Fujitsu U745. > > I use the patch (psmouse-elantech-v7right.tar.bz2) described in this thread: > > http://superuser.com/questions/619582/right-elantech-touchpad-button-not- > > working-in-linux > > It works fine with kernel versions 3.16.X and also with 4.1.12-3. > > Please report *this* to upstream. It must be handled there at first, then > we can backport the fixes. > So, what's not working in your case is only about the right button? Nope, it's about the whole touchpad. No buttons, no scroll, no tap, no anything. (In reply to Balazs Nagy from comment #18) > > So, what's not working in your case is only about the right button? > > Nope, it's about the whole touchpad. No buttons, no scroll, no tap, no > anything. Hmm, which patch did you apply to which kernel? Please attach to this bugzilla. In anyway, if a wild patch works and still needed, please report it to upstream, at best, by yourself who has the test hardware. Just report it on bugzilla.kernel.org, for example. Feel free to put me to Cc in case you need any assist, and point this bugzilla entry. Created attachment 654990 [details]
Patch for ElanTech touchpads
(In reply to Takashi Iwai from comment #19) > Hmm, which patch did you apply to which kernel? Please attach to this > bugzilla. Patch is attached. I applied it to kernel 3.16.7-24-desktop and it worked fine. It also worked fine with all previous kernel versions. However, it didn't work with 3.16.7-29-desktop for some unknown reason. It worked fine again with version 4.1.12. Today I upgraded from OS 13.2 to Leap and now I am testing if the patch still works. The default stock kernel in Leap does not support the touchpad. > In anyway, if a wild patch works and still needed, please report it to > upstream, at best, by yourself who has the test hardware. Just report it on > bugzilla.kernel.org, for example. Feel free to put me to Cc in case you > need any assist, and point this bugzilla entry. Thanks, I'll do that. (In reply to Balazs Nagy from comment #21) > (In reply to Takashi Iwai from comment #19) > > > Hmm, which patch did you apply to which kernel? Please attach to this > > bugzilla. > > Patch is attached. It doesn't look like a "patch". What kind of data did you attach? A patch is a diff file to be applied to a C source... (In reply to Takashi Iwai from comment #22) > It doesn't look like a "patch". What kind of data did you attach? A patch > is a diff file to be applied to a C source... Okay, I am definitely not an expert in os debugging. I attached the actual C source files. In order to make the touchpad work, the original elantech.c file in /usr/src/linux-xxx/drivers/input/mouse directory has to be overwritten with the attached one. Then, after rebuilding the kernel the touchpad works as expected. (In reply to Balazs Nagy from comment #23) > (In reply to Takashi Iwai from comment #22) > > > It doesn't look like a "patch". What kind of data did you attach? A patch > > is a diff file to be applied to a C source... > > Okay, I am definitely not an expert in os debugging. I attached the actual C > source files. In order to make the touchpad work, the original elantech.c > file in /usr/src/linux-xxx/drivers/input/mouse directory has to be > overwritten with the attached one. Then, after rebuilding the kernel the > touchpad works as expected. So you didn't apply a patch but compiled the wild driver code from the scratch. It makes things to hard to debug since you don't know what change you have against the current version. You need to create a patch and identify what change is actually needed. There must be a base upstream version that your driver code was created. Then make a diff file against it (diff -up oldfile.c newfile.c), and this is the patch file we're interested in. Created attachment 654999 [details]
Patch for elantech.c
Created attachment 655000 [details]
Patch for elantech.h
(In reply to Takashi Iwai from comment #24) > (In reply to Balazs Nagy from comment #23) > > (In reply to Takashi Iwai from comment #22) > > > > > It doesn't look like a "patch". What kind of data did you attach? A patch > > > is a diff file to be applied to a C source... > > > > Okay, I am definitely not an expert in os debugging. I attached the actual C > > source files. In order to make the touchpad work, the original elantech.c > > file in /usr/src/linux-xxx/drivers/input/mouse directory has to be > > overwritten with the attached one. Then, after rebuilding the kernel the > > touchpad works as expected. > > So you didn't apply a patch but compiled the wild driver code from the > scratch. It makes things to hard to debug since you don't know what change > you have against the current version. > > You need to create a patch and identify what change is actually needed. > There must be a base upstream version that your driver code was created. > Then make a diff file against it (diff -up oldfile.c newfile.c), and this is > the patch file we're interested in. I attached patches for source files elantech.h and elantech.c. Thanks. As you can see, the patch removes lots of codes. This implies that you're creating a patch against the newer version, not the base version where your driver was created. Your driver seems based on the VERY old kernel. Maybe 3.12 or such. You can try to regenerate the patch to see whether to get more reasonable result. In anyway: please give the dmesg output, too. There must be an info line showing the firmware version. This can be another hint. Also, with the recent upstream driver, try to turn on "crc_enabled" sysfs file. In /sys/devices subdirectories, there must be a directory containing "crc_enabled" file (as well as "reg_07", "debug", "particycheck", etc). Try to run like: find /sys/devices -name crc_enabled If there is, write "1" (as root). Below is an example when the file above is found in/sys/devices/platform/i8042/serio3/crc_enabled: echo -n 1 > /sys/devices/platform/i8042/serio3/crc_enabled (In reply to Takashi Iwai from comment #28) > Also, with the recent upstream driver, try to turn on "crc_enabled" sysfs > file. > In /sys/devices subdirectories, there must be a directory containing > "crc_enabled" file (as well as "reg_07", "debug", "particycheck", etc). > Try to run like: > find /sys/devices -name crc_enabled > > If there is, write "1" (as root). Below is an example when the file above > is found in/sys/devices/platform/i8042/serio3/crc_enabled: > echo -n 1 > /sys/devices/platform/i8042/serio3/crc_enabled So, I don't know what exactly it does but works like a charm!! Created attachment 655015 [details]
dmesg output
(In reply to Balazs Nagy from comment #29) > (In reply to Takashi Iwai from comment #28) > > > Also, with the recent upstream driver, try to turn on "crc_enabled" sysfs > > file. > > In /sys/devices subdirectories, there must be a directory containing > > "crc_enabled" file (as well as "reg_07", "debug", "particycheck", etc). > > Try to run like: > > find /sys/devices -name crc_enabled > > > > If there is, write "1" (as root). Below is an example when the file above > > is found in/sys/devices/platform/i8042/serio3/crc_enabled: > > echo -n 1 > /sys/devices/platform/i8042/serio3/crc_enabled > > So, I don't know what exactly it does but works like a charm!! My last question: How can I make this change permanent? (In reply to Balazs Nagy from comment #29) > (In reply to Takashi Iwai from comment #28) > > > Also, with the recent upstream driver, try to turn on "crc_enabled" sysfs > > file. > > In /sys/devices subdirectories, there must be a directory containing > > "crc_enabled" file (as well as "reg_07", "debug", "particycheck", etc). > > Try to run like: > > find /sys/devices -name crc_enabled > > > > If there is, write "1" (as root). Below is an example when the file above > > is found in/sys/devices/platform/i8042/serio3/crc_enabled: > > echo -n 1 > /sys/devices/platform/i8042/serio3/crc_enabled > > So, I don't know what exactly it does but works like a charm!! OK, good to hear. Then the simple is simpler than I thought. Some Fujitsu devices need this workaround, and it's applied based on DMI string check. We need to add the name matching with your device. Please give the output of: cat /sys/class/dmi/id/sys_vendor cat /sys/class/dmi/id/product_name Then I can cook a patch. One more question: does the workaround with crc_check works for 4.1.x Leap kernel, too? (In reply to Balazs Nagy from comment #31) > (In reply to Balazs Nagy from comment #29) > > (In reply to Takashi Iwai from comment #28) > > > > > Also, with the recent upstream driver, try to turn on "crc_enabled" sysfs > > > file. > > > In /sys/devices subdirectories, there must be a directory containing > > > "crc_enabled" file (as well as "reg_07", "debug", "particycheck", etc). > > > Try to run like: > > > find /sys/devices -name crc_enabled > > > > > > If there is, write "1" (as root). Below is an example when the file above > > > is found in/sys/devices/platform/i8042/serio3/crc_enabled: > > > echo -n 1 > /sys/devices/platform/i8042/serio3/crc_enabled > > > > So, I don't know what exactly it does but works like a charm!! > > My last question: How can I make this change permanent? The best is to fix the kernel :) Alternatively, you can add your own systemd unit file to perform the above, or do it in a still existing /etc/init.d/boot.local or such. (In reply to Takashi Iwai from comment #32) > > OK, good to hear. Then the simple is simpler than I thought. Some Fujitsu > devices need this workaround, and it's applied based on DMI string check. > We need to add the name matching with your device. > Please give the output of: > cat /sys/class/dmi/id/sys_vendor FUJITSU > cat /sys/class/dmi/id/product_name LIFEBOOK U745 > > Then I can cook a patch. Thank you very much! > One more question: does the workaround with crc_check works for 4.1.x Leap > kernel, too? I am using the default Leap kernel 4.1.12-1-default, so the answer is yes. Created attachment 655018 [details]
Patch to add support for Fujitsu Lifebook U745
Could you confirm the patch above? Once when confirmed, I'll submit it to the upstream and backport to openSUSE kernels. (In reply to Takashi Iwai from comment #36) > Could you confirm the patch above? Once when confirmed, I'll submit it to > the upstream and backport to openSUSE kernels. I can confirm the patch with kernel version 4.1.12-1. Thank you very much for helping with this issue. Great. Now I submitted the patch to upstream, and it was accepted. It'll be included in 4.4-rc1 and eventually backported to stable kernels. Menawhile I already backported the fix to openSUSE-42.1 and master kernel branches so that it'll be included in the next Leap and FACTORY kernel updates (FACTORY might be at next of next, though). You can use the latest kernel in OBS Kernel:openSUSE-42.1 repo. It's refreshed once per day or so. I close this bug now as it's apparently working with 42.1 and FACTORY. If any similar device doesn't work, feel free to reopen, or even better open another bug report and mention this bug there. Thanks. (In reply to Takashi Iwai from comment #38) > Great. Now I submitted the patch to upstream, and it was accepted. It'll > be included in 4.4-rc1 and eventually backported to stable kernels. > > Menawhile I already backported the fix to openSUSE-42.1 and master kernel > branches so that it'll be included in the next Leap and FACTORY kernel > updates (FACTORY might be at next of next, though). > > You can use the latest kernel in OBS Kernel:openSUSE-42.1 repo. It's > refreshed once per day or so. > > I close this bug now as it's apparently working with 42.1 and FACTORY. If > any similar device doesn't work, feel free to reopen, or even better open > another bug report and mention this bug there. Thanks. Great. Thank you. openSUSE-SU-2015:2232-1: An update that solves 5 vulnerabilities and has 16 fixes is now available. Category: security (moderate) Bug References: 883192,944978,945825,948758,949936,951533,952384,952579,952976,953527,953559,953717,954404,954421,954647,954757,954876,955190,955363,955365,956856 CVE References: CVE-2015-5307,CVE-2015-6937,CVE-2015-7799,CVE-2015-7990,CVE-2015-8104 Sources used: openSUSE Leap 42.1 (src): kernel-debug-4.1.13-5.1, kernel-default-4.1.13-5.1, kernel-docs-4.1.13-5.4, kernel-ec2-4.1.13-5.1, kernel-obs-build-4.1.13-5.2, kernel-obs-qa-4.1.13-5.1, kernel-obs-qa-xen-4.1.13-5.1, kernel-pae-4.1.13-5.1, kernel-pv-4.1.13-5.1, kernel-source-4.1.13-5.1, kernel-syms-4.1.13-5.1, kernel-vanilla-4.1.13-5.1, kernel-xen-4.1.13-5.1 Hi, Sorry for resurrecting this bug. I also have a Lifebook U745 but the above patch was not enough, the touchpad was still not working at all. I have a different BIOS version (mine is 1.10, I see Balazs' is 1.08 from the attached dmesg log), this may explain the difference. On my laptop I also need i8042.nomux=1 for the touchpad to work. @Balazs, it would be great if you could check if your touchpad still works well when booted with the kernel option "i8042.nomux=1" (or the attached patch)? If this works I'll submit this patch upstream. Thanks, Aurélien Created attachment 660360 [details]
patch to add nomux for U745
Hi Aurélien, My touchpad works fine with the i8042.nomux=1 option. Balazs (In reply to Aurélien Francillon from comment #41) > Hi, > > Sorry for resurrecting this bug. I also have a Lifebook U745 but the above > patch was not enough, the touchpad was still not working at all. > > I have a different BIOS version (mine is 1.10, I see Balazs' is 1.08 from > the attached dmesg log), this may explain the difference. > > On my laptop I also need i8042.nomux=1 for the touchpad to work. > > @Balazs, it would be great if you could check if your touchpad still works > well when booted with the kernel option "i8042.nomux=1" (or the attached > patch)? If this works I'll submit this patch upstream. > > Thanks, > Aurélien (In reply to Balazs Nagy from comment #43) > Hi Aurélien, > > My touchpad works fine with the i8042.nomux=1 option. Awesome, thanks for the quick test ! Best, Aurélien Hi everybody, I just installed the current Tumbleweed on a Fujitsu Lifebook E546 (as stated by /sys/class/dmi/id/sys_vendor and /sys/class/dmi/id/product_name) and had probably the same problem: touchpad not working. # uname -r 4.9.0-1-default I could solve the problem by appending "psmouse.proto=bare" to the kernel boot options. If you need any more details I'm happy to provide them. Best regards, Andreas (In reply to Andreas Bockhold from comment #45) > Hi everybody, > > I just installed the current Tumbleweed on a Fujitsu Lifebook E546 (as > stated by /sys/class/dmi/id/sys_vendor and /sys/class/dmi/id/product_name) > and had probably the same problem: touchpad not working. > > # uname -r > 4.9.0-1-default > > I could solve the problem by appending "psmouse.proto=bare" to the kernel > boot options. > > If you need any more details I'm happy to provide them. > > Best regards, > Andreas Could you rather report to upstream? You can try bugzilla.kernel.org, for example, although linux-input ML might get better response. |
Created attachment 595041 [details] Various touchpad information User-Agent: Opera/9.80 (X11; Linux x86_64) Presto/2.12.388 Version/12.16 The ElanTech Touchpad on my Fujitsu Celsius H730 does not work. Every time I touch the Touchpad the following output in /var/log/messages 2014-06-18T13:36:38.590522+02:00 machine kernel: [16561.131699] psmouse serio4: Touchpad at isa0060/serio4/input0 lost sync at byte 6 2014-06-18T13:36:38.599954+02:00 machine kernel: [16561.140887] psmouse serio4: Touchpad at isa0060/serio4/input0 lost sync at byte 6 2014-06-18T13:36:38.608547+02:00 machine kernel: [16561.149751] psmouse serio4: Touchpad at isa0060/serio4/input0 lost sync at byte 6 2014-06-18T13:36:38.617273+02:00 machine kernel: [16561.158496] psmouse serio4: Touchpad at isa0060/serio4/input0 lost sync at byte 6 2014-06-18T13:36:38.626209+02:00 machine kernel: [16561.167412] psmouse serio4: Touchpad at isa0060/serio4/input0 lost sync at byte 6 2014-06-18T13:36:38.626223+02:00 machine kernel: [16561.167416] psmouse serio4: issuing reconnect request Clicking on the right and left Touchpad buttons: 2014-06-18T13:37:39.027531+02:00 machine kernel: [16621.617646] psmouse serio4: Touchpad at isa0060/serio4/input0 lost sync at byte 6 2014-06-18T13:37:39.155018+02:00 machine kernel: [16621.745236] psmouse serio4: Touchpad at isa0060/serio4/input0 lost sync at byte 6 Clicking on the middle Touchpad button: 2014-06-18T13:39:44.049662+02:00 machine kernel: [16746.740984] psmouse serio4: Touchpad at isa0060/serio4/input0 - driver resynced. 2014-06-18T13:39:44.277859+02:00 machine kernel: [16746.969352] psmouse serio4: Touchpad at isa0060/serio4/input0 lost sync at byte 6 Attached text document with various output from /proc/bus/input/devices, xinput, dmesg and /var/log/Xorg.0.log I have tried the kernel-desktop-3.11.10-11 that comes with OpenSUSE 13.1 I have tried the latest stable kernel-desktop-3.15.0-1 I have tried the latest stable kernel-vanilla-3.15.0-1 This problem persists in all these kernel versions. Tried with both KDE 4.13.2 and LXQt. I tried to start the laptop with the OpenSUSE install ISO booted from USB. Touchpad not working there either. Have verified that the Touchpad is working in Windows. So it is not a hardware problem. Reproducible: Always Steps to Reproduce: 1. Touch Touchpad 2. 3. Actual Results: Mouse pointer standing still Expected Results: Move mouse pointer