Created attachment 1010270 [details] Journal output from Fedora 21 Live Media Description of problem: Sorry for the noise on rhbz #1110011. Booting a Fedora 21 Live Media on ASUS X550ZE, the touchpad was recognized as "ETPS/2 Elantech Touchpad" according to the xinput command. For some reason, it has trouble connecting as displayed: Apr 02 12:40:19 localhost kernel: psmouse serio4: issuing reconnect request Apr 02 12:40:19 localhost kernel: psmouse serio4: Touchpad at isa0060/serio4/input0 lost sync at byte 6 The bug was succesfully reproduced on other version of Fedora i.e. 22 Beta using Gnome on Wayland while the regular X session backtrace but to regression on xserver as described on rhbz #1206733. Version-Release number of selected component (if applicable): 3.17.4-301 and above (including 4.0.0 as tested on F22 Beta) How reproducible: Always Steps to Reproduce: 1. Boot a live media 2. 3. Actual results: Touchpad detected but refused to work due to Apr 02 12:40:19 localhost kernel: psmouse serio4: issuing reconnect request Apr 02 12:40:19 localhost kernel: psmouse serio4: Touchpad at isa0060/serio4/input0 lost sync at byte 6 Expected results: Touchpad works out of box Additional info: $ xinput list-props "ETPS/2 Elantech Touchpad" Device 'ETPS/2 Elantech Touchpad': Device Enabled (136): 1 Coordinate Transformation Matrix (138): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 Device Accel Profile (266): 1 Device Accel Constant Deceleration (267): 2.500000 Device Accel Adaptive Deceleration (268): 1.000000 Device Accel Velocity Scaling (269): 12.500000 Synaptics Edges (292): 123, 2974, 114, 2005 Synaptics Finger (293): 1, 1, 0 Synaptics Tap Time (294): 180 Synaptics Tap Move (295): 165 Synaptics Tap Durations (296): 180, 180, 100 Synaptics ClickPad (297): 1 Synaptics Middle Button Timeout (298): 0 Synaptics Two-Finger Pressure (299): 282 Synaptics Two-Finger Width (300): 7 Synaptics Scrolling Distance (301): 75, 75 Synaptics Edge Scrolling (302): 0, 0, 0 Synaptics Two-Finger Scrolling (303): 1, 1 Synaptics Move Speed (304): 1.000000, 1.750000, 0.053305, 0.000000 Synaptics Off (305): 0 Synaptics Locked Drags (306): 0 Synaptics Locked Drags Timeout (307): 5000 Synaptics Tap Action (308): 0, 0, 0, 0, 0, 0, 0 Synaptics Click Action (309): 1, 3, 2 Synaptics Circular Scrolling (310): 0 Synaptics Circular Scrolling Distance (311): 0.100000 Synaptics Circular Scrolling Trigger (312): 0 Synaptics Circular Pad (313): 0 Synaptics Palm Detection (314): 0 Synaptics Palm Dimensions (315): 10, 200 Synaptics Coasting Speed (316): 20.000000, 50.000000 Synaptics Pressure Motion (317): 30, 160 Synaptics Pressure Motion Factor (318): 1.000000, 1.000000 Synaptics Grab Event Device (319): 0 Synaptics Gestures (320): 1 Synaptics Capabilities (321): 1, 0, 0, 1, 1, 1, 1 Synaptics Pad Resolution (322): 32, 31 Synaptics Area (323): 0, 0, 0, 0 Synaptics Soft Button Areas (324): 1548, 0, 1737, 0, 0, 0, 0, 0 Synaptics Noise Cancellation (325): 18, 18 Device Product ID (255): 2, 14 Device Node (256): "/dev/input/event6"
Created attachment 1010271 [details] Full dmesg
We can't fix the F21 live media at this point. Do you have the same problem with the F22 Alpha (or better yet, can you test the upcomming beta)?
(In reply to Josh Boyer from comment #2) > We can't fix the F21 live media at this point. Do you have the same problem > with the F22 Alpha (or better yet, can you test the upcomming beta)? Yes, all version of Fedora 22 Alpha and recently Beta TC6 encounters the same problem. Here is the output from xinput which uses libinput by default: $ xinput list-props "ETPS/2 Elantech Touchpad" Device 'ETPS/2 Elantech Touchpad': Device Enabled (113): 1 Coordinate Transformation Matrix (115): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000 libinput Tapping Enabled (254): 0 libinput Accel Speed (248): 0.000000 libinput Natural Scrolling Enabled (249): 0 libinput Send Events Modes Available (234): 1, 1 libinput Send Events Mode Enabled (235): 0, 0 libinput Left Handed Enabled (250): 0 libinput Scroll Methods Available (251): 1, 0, 0 libinput Scroll Method Enabled (252): 1, 0, 0 libinput Click Methods Available (255): 1, 1 libinput Click Method Enabled (256): 1, 0 Device Node (236): "/dev/input/event5" Device Product ID (237): 2, 14 I am including the journalctl report as well. Note that due to the regression from possibly xserver I had to use nomodeset parameter.
Created attachment 1010312 [details] Journal output from Fedora 22 Beta TC6
Created attachment 1010503 [details] New X.log output after xserver update 1.17.1-7.fc22 Included Xorg.0.log. It looks like the touchpad was detected but cannot be used due to the clash with a mouse device file. Here is the relevant part: [ 122.961] (II) Using input driver 'libinput' for 'ETPS/2 Elantech Touchpad' [ 122.961] (**) ETPS/2 Elantech Touchpad: always reports core events [ 122.961] (**) Option "Device" "/dev/input/event5" [ 122.961] (II) input device 'ETPS/2 Elantech Touchpad', /dev/input/event5 is tagged by udev as: Touchpad [ 122.961] (II) input device 'ETPS/2 Elantech Touchpad', /dev/input/event5 is a touchpad [ 122.961] (**) Option "config_info" "udev:/sys/devices/platform/i8042/serio4/input/input12/event5" [ 122.961] (II) XINPUT: Adding extended input device "ETPS/2 Elantech Touchpad" (type: TOUCHPAD, id 14) [ 122.962] (**) Option "AccelerationScheme" "none" [ 122.962] (**) ETPS/2 Elantech Touchpad: (accel) selected scheme none/0 [ 122.962] (**) ETPS/2 Elantech Touchpad: (accel) acceleration factor: 2.000 [ 122.962] (**) ETPS/2 Elantech Touchpad: (accel) acceleration threshold: 4 [ 122.962] (II) input device 'ETPS/2 Elantech Touchpad', /dev/input/event5 is tagged by udev as: Touchpad [ 122.962] (II) input device 'ETPS/2 Elantech Touchpad', /dev/input/event5 is a touchpad [ 122.963] (II) config/udev: Adding input device ETPS/2 Elantech Touchpad (/dev/input/mouse0) [ 122.963] (II) No input driver specified, ignoring this device. [ 122.963] (II) This device may have been added with another device file. The issue seems similar to https://bugzilla.redhat.com/show_bug.cgi?id=1110011
Switched to Fedora 22.
More info from /proc/bus/input/devices if needed: I: Bus=0011 Vendor=0002 Product=000e Version=0000 N: Name="ETPS/2 Elantech Touchpad" P: Phys=isa0060/serio1/input0 S: Sysfs=/devices/platform/i8042/serio1/input/input6 U: Uniq= H: Handlers=mouse1 event7 B: PROP=5 B: EV=b B: KEY=e420 10000 0 0 0 0 B: ABS=661800011000003
Created attachment 1013218 [details] Screenshot showing the touchpad is detected and active Taken from Fedora 22 Beta RC1.
Proposed as a Blocker for 22-final by Fedora user luya using the blocker tracking app because: This bug seems affecting most Elantech based touchpad especially the newer version. Similar to rhbz #1110011 with a difference using a newer ASUS X550ZE based on AMD Kaveri. The touchpad is correctly activated (see the big information) but the input failed to run due to these lines: [ 122.963] (II) config/udev: Adding input device ETPS/2 Elantech Touchpad (/dev/input/mouse0) [ 122.963] (II) No input driver specified, ignoring this device. [ 122.963] (II) This device may have been added with another device file. It looks like an udev problem assigning to the right device. Workaround is possible for the beta release of Fedora 22 by setting "psmouse.proto=bare" as boot parameter (see rhgz #1110011) . It would be great if the touchpad is fully functional for the final release.
Same comment as I made on your other bug you proposed. This is limited to this specific machine and I don't see it meeting blocker criteria. It would be a nice to have for sure.
Noted.
(In reply to Fedora Blocker Bugs Application from comment #9) > [ 122.963] (II) config/udev: Adding input device ETPS/2 Elantech Touchpad > (/dev/input/mouse0) > [ 122.963] (II) No input driver specified, ignoring this device. > [ 122.963] (II) This device may have been added with another device file. > > It looks like an udev problem assigning to the right device. No. This info message is common to all installation. The kernel creates 2 nodes per touchpad (one event*, which is used and one mouse* which we discard). The problem you really have is what you referred in the description: Apr 02 12:40:19 localhost kernel: psmouse serio4: issuing reconnect request Apr 02 12:40:19 localhost kernel: psmouse serio4: Touchpad at isa0060/serio4/input0 lost sync at byte 6 That means that the kernel has problem dealing with your touchpad. Ideally, I'd like Hans to look into it given that he fixed most of the Focaltech/Elantech PS/2 touchpads, but if we do not hear from him in the next week or so, I'll try to look deeper into it.
(In reply to Benjamin Tissoires from comment #12) > No. This info message is common to all installation. The kernel creates 2 > nodes per touchpad (one event*, which is used and one mouse* which we > discard). > > The problem you really have is what you referred in the description: > > Apr 02 12:40:19 localhost kernel: psmouse serio4: issuing reconnect request > Apr 02 12:40:19 localhost kernel: psmouse serio4: Touchpad at > isa0060/serio4/input0 lost sync at byte 6 > > That means that the kernel has problem dealing with your touchpad. Ideally, > I'd like Hans to look into it given that he fixed most of the > Focaltech/Elantech PS/2 touchpads, but if we do not hear from him in the > next week or so, I'll try to look deeper into it. Thank you for the explanation. Does that problem occur on every newer version of Focaltech/Elantech touchpad?
Removal of blocker.
Hi Luya, Please first try the quick fix method for this, add i8042.nomux=1 i8042.reset=1 to the kernel commandline, and see if things work that way. If they work that way, then try adding only one of them, and let us know if you can get things to work with either one or both of them. If that works you can stop reading here :) If things do not work that way, then add: "dyndbg=file drivers/input/mouse/elantech.c +p" to your kernel commandline including the "" around it, then reboot and work on the laptop until the touchpad stops working, then do "dmesg > dmesg.log" and attach the dmesg.log file here. After this also please collect a raw ps2 data dump (in a separate boot / test-run): I'm not sure if the touchpad does not stops working immediately at startup, or if it works for a while. Can you please do the following: 1) Change your login password to something simple, this needs to be a throw away password 2) Add i8042.debug=1 to your kernel commandline 3) Boot, login, start a terminal, do dmesg > dmesg.txt 4) Check dmesg.txt you should see some raw ps2 packets dumped in there, note this contains your laptop keyboard keypresses including your (temporary) password. If the touchpad works for a while then after step 2 do: 3) Do "sudo dmesg --clear" to clear the dmesg log, so that your password is gone from it 4) Use your laptop normally, whenever you type a password do: "sudo dmesg --clear" 5) When the touchpad stops working do "dmesg > dmesg.txt" and attach the generated dmesg.txt here. Regards, Hans
Created attachment 1014436 [details] dmesg.log with requested parameter Adding i8042.nomux=1 i8042.reset=1 have no effect so "dyndbg=file drivers/input/mouse/elantech.c +p" is included.
Created attachment 1014438 [details] dmesg with i8042.debug enabled dmesg with i8042.debug enabled. The touchpad seems unresponsive or stuck.
Hi Luya, Thanks for the logs. It looks like the touchpad stays in psmouse emulation mode and is sending standard ps mouse packets after we've told it to switch to absolute mode. We've some contacts inside elantech I'll ask them for help. In the mean time you can add "psmouse.proto=bare" to the kernel commandline to work around this (and remove all the other special options), at least I think that that should work. Regards, Hans
(In reply to Hans de Goede from comment #18) > We've some contacts inside elantech I'll ask them for help. > > In the mean time you can add "psmouse.proto=bare" to the kernel commandline > to work around this (and remove all the other special options), at least I > think that that should work. > > Regards, > > Hans Hi Hans, Adding that parameter does the trick for the touchpad. I will wait for the update about the elantech support status. Regards, Luya
Hi Luya, I will help you deal with this problem. Please follow below steps and get log file: ---------------- Step1.find device node $cat /proc/bus/input/device Example: Name: "ETPS/2 Elantech Touchpad" /devices/platform/isa0060/serio4/input/ ---------------- Step2. Open debug function. $sudo su $echo 2 > /sys/devices/platform/isa0060/serio4/debug ---------------- Step3. Put your forefinger on Touchpad and move. ---------------- Step4. Confirm the correctness of the information. example message: psmouse serio4: elantech: PS/2 packet[..]… dmesg ---------------- Step5.save log message dmesg >> fingerLog.txt --------------- Step6.send fingerLog.txt file to me. (email: sam.hung.tw) --------------- BR, Sam Elan corp.
Created attachment 1019287 [details] Requested fingerlog.txt (In reply to yi-ju hung from comment #20) > Hi Luya, > > I will help you deal with this problem. > > Please follow below steps and get log file: > ---------------- > Step1.find device node > $cat /proc/bus/input/device Step1. Find device node ------------------- I: Bus=0011 Vendor=0002 Product=000e Version=0000 N: Name="ETPS/2 Elantech Touchpad" P: Phys=isa0060/serio4/input0 S: Sysfs=/devices/platform/i8042/serio4/input/input12 U: Uniq= H: Handlers=mouse0 event5 B: PROP=5 B: EV=b B: KEY=e420 10000 0 0 0 0 B: ABS=661800011000003 > ---------------- > Step2. Open debug function. > $sudo su > $echo 2 > /sys/devices/platform/isa0060/serio4/debug > ---------------- > Step3. Put your forefinger on Touchpad and move. > ---------------- > Step4. Confirm the correctness of the information. example message: > psmouse serio4: elantech: PS/2 packet[..]… > dmesg Extract of result below: [15540.333473] 0x08 , 0x02 , 0x00 , 0x08 , 0x01 , 0x00 ] [15540.333482] psmouse serio4: Touchpad at isa0060/serio4/input0 lost sync at byte 6 [15540.372025] psmouse serio4: elantech: PS/2 packet [ [15540.372035] 0x28 , 0x01 , 0xff , 0x28 , 0x00 , 0xff ] [15540.372048] psmouse serio4: Touchpad at isa0060/serio4/input0 lost sync at byte 6 [15540.398100] psmouse serio4: elantech: PS/2 packet [ [15540.398110] 0x38 , 0xfe , 0xfe , 0x38 , 0xfe , 0xfe ] [15540.398123] psmouse serio4: Touchpad at isa0060/serio4/input0 lost sync at byte 6 [15540.703645] psmouse serio4: elantech: PS/2 packet [ [15540.703656] 0x09 , 0x00 , 0x00 , 0x08 , 0x00 , 0x00 ] [15540.703669] psmouse serio4: Touchpad at isa0060/serio4/input0 lost sync at byte 6 [15540.703673] psmouse serio4: issuing reconnect request > ---------------- > Step5.save log message > dmesg >> fingerLog.txt > --------------- > Step6.send fingerLog.txt file to me. (email: sam.hung.tw) > --------------- File sent via email. Attachment included.
Hi All, It seems to be switching mode failure cause cursor can not move. (Relative Mode-->Absolute Mode) But we follow the rules to execute switch command. We propose an workaround solution for test, Please follow below steps: Step1. cd /sys/devices/platform/isa0060/serio4/ Step2. echo -n 0x01 > reg_7 Step3: Put your forefinger on Touchpad and move,check cursor move or not? BR, Sam Elan corp.
Hi All, A few additional explanations, Please follow below steps and get mode state: Step1. Read mode state,before switch Absolute Mode cat reg_7 Step2. cd /sys/devices/platform/isa0060/serio4/ echo -n 0x01 > reg_7 Step3. Read mode state,after switch Absolute Mode cat reg_7 Step4: Put your forefinger on Touchpad and move,check cursor move or not? cat value before and after switch mode?
Hi Sam, (In reply to yi-ju hung from comment #23) > Step1. Read mode state,before switch Absolute Mode > cat reg_7 0x00 > Step2. > cd /sys/devices/platform/isa0060/serio4/ > echo -n 0x01 > reg_7 In my case, I did cd /sys/devices/platform/i8042/serio4/ echo -n 0x01 > reg_ 07 > Step3. Read mode state,after switch Absolute Mode > cat reg_7 0x01 Absolute Mode > Step4: > Put your forefinger on Touchpad and move,check cursor move or not? Cursor does not move. > cat value before and after switch mode? cat value before switch: 0x00 cat value after switch: 0x01
(In reply to yi-ju hung from comment #22) > > Step3: > Put your forefinger on Touchpad and move,check cursor move or not? Please disregard my comment the step4 on comment #24. I forgot to turn on the Touchpad on Settings > Mouse & Touchpad. The cursor is now moving. I tested "Tap to Click", "Two finger scroll" and "Natural scroll". They are all working.
So in summary, (In reply to yi-ju hung from comment #23) > Hi All, > > A few additional explanations, > Please follow below steps and get mode state: > > Step1. Read mode state,before switch Absolute Mode > cat reg_7 0x00 > Step2. > cd /sys/devices/platform/isa0060/serio4/ > echo -n 0x01 > reg_7 Done > Step3. Read mode state,after switch Absolute Mode > cat reg_7 0x01 > Step4: > Put your forefinger on Touchpad and move,check cursor move or not? Cursor is moving. > cat value before and after switch mode? cat value before switch: 0x00 cat value after switch: 0x01 The downside is the workaround is not preserved after reboot.
Dear All, We will modify the mechanism of switch mode instruction. BR, Sam Elan corp.
Hi, (In reply to yi-ju hung from comment #27) > Dear All, > > We will modify the mechanism of switch mode instruction. > > BR, > Sam > Elan corp. Thanks if you can provide a patch against elantech.c in the upstream kernel then I can do a kernel scratch-build for Luya to test, Regards, Hans
Greetings, I just updated to kernel 4.0.2-300.fc22.x86_64 which allows the touchpad to work. See https://bugzilla.redhat.com/show_bug.cgi?id=1182816 also the issue is related to the touchscreen laptop. Since upstream Elantech will bring the change themselves, I'll wait before closing the bug report as they seem to have a better approach.
Just notifying the touchpad is working fine since kernel 4.0.2-300 update. I am not sure how the fix also affected this Elantech touchpad from ASUS X500Z. I am hesitating to close this report but I would like to hear the update from upstream. Thanks.
Does your touchpad work correctly with Secure Boot Enabled?
Yes, it does since the fix from bug #1182816 that related the touchscreen. My installation was done with default setting from the manufacturer. Apparently the bug affect kernels version < 4.x. Because the manufacturer was involved into the bug and haven't been heard since, I hesitate to close the bug. Now that you mentioned about disabling Secure Boot, I will test on the separate bug affecting Fn keyboard input: https://bugzilla.redhat.com/show_bug.cgi?id=1206862
Hi, I Also have this kind of problem in my fujitsu. the "psmouse.proto=bare" work for me, but as you said features will be removed. I have tried to follow the steps that worked for Luya. but unfortunately I don't have a directory called isa0060 under the /sys/devices/platform/ BTW. Thanks, at least my touchpad is now workingg
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs. Fedora 22 has now been rebased to 4.2.3-200.fc22. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
I just got the request after a flood of bug report. Having intensively tested the kernel since 4.0.2-300, Elantech touhcpad is working smoothly without issue. This bug can be closed.