Hi, Paul, I have modified the source code. There are three issues. #1. E7=73 03 28 Button pad device is not assigned "ALPS_BUTTONPAD" Flag correctly. #2. E7=73 03 28 devices are not assigned " ALPS_DUALPOINT" Flag correctly. #3. E7=73 03 28 device cursor speed is slow. Actually, the cause is all the same. E7=73 03 28 device does not get correct information from OTP. OTP is the device information byte. I specified correct bit. Then, I think it is also the issue. #4. Stick Pointer cursor speed is fast. I will check Stick parameter. Best Regards, Masaki Ota -----Original Message----- From: Paul Donohue [mailto:linux-kernel@xxxxxxxxxx] Sent: Tuesday, March 07, 2017 11:18 AM To: 太田 真喜 Masaki Ota <masaki.ota@xxxxxxxxxxx> Cc: Nick Fletcher <nick.m.fletcher@xxxxxxxxx>; Joseph Salisbury <joseph.salisbury@xxxxxxxxxxxxx>; ben@xxxxxxxxxxxxxxxx; mhocko@xxxxxxxx; dmitry.torokhov@xxxxxxxxx; pali.rohar@xxxxxxxxx; rydberg@xxxxxxxxxxx; linux@xxxxxxxxxxxx; open list:HID CORE LAYER <linux-input@xxxxxxxxxxxxxxx>; LKML <linux-kernel@xxxxxxxxxxxxxxx>; stable@xxxxxxxxxxxxxxx Subject: Re: [REGRESSION][v4.9.y][v4.10.y] Input: ALPS - set DualPoint flag for 74 03 28 devices Excellent! Thanks! Let me know if you see anything else that needs to change. On Mon, Mar 06, 2017 at 08:45:33AM +0000, Masaki Ota wrote: > Hi, Paul, > > I understand the current situation. > We have three devices that have ID: E7=73 03 28. > > DELL: Normal Pad type (There are Left and right button below > Touchpad.) > ID: E7=73 03 28, EC=73 01 13 > ID: E7=73 03 28, EC=73 01 22 > > TOSHIBA: Button Pad type > ID: E7=73 03 28, EC=73 01 14 > > I think Nick mentioned about TOSHIBA device. > I have checked the source code and I guess EC=73 01 14 device does not have "ALPS_BUTTONPAD" Flag, although it is the Button Pad. > Because "alps_update_btn_info_ss4_v2()" does not support E7=73 03 28 devices. > > E7=73 03 14 device can use below code. > is_btnless = (otp[1][1] >> 3) & 0x01; > > E7=73 03 28 device has to use below bit. > is_btnless = (otp[1][0] >> 1) & 0x01; > > I will check other parts of source code. > > Best Regards, > Masaki Ota > -----Original Message----- > From: Paul Donohue [mailto:linux-kernel@xxxxxxxxxx] > Sent: Monday, March 06, 2017 3:09 AM > To: Nick Fletcher <nick.m.fletcher@xxxxxxxxx>; 太田 真喜 Masaki Ota > <masaki.ota@xxxxxxxxxxx> > Cc: Joseph Salisbury <joseph.salisbury@xxxxxxxxxxxxx>; > ben@xxxxxxxxxxxxxxxx; mhocko@xxxxxxxx; dmitry.torokhov@xxxxxxxxx; > pali.rohar@xxxxxxxxx; rydberg@xxxxxxxxxxx; linux@xxxxxxxxxxxx; open > list:HID CORE LAYER <linux-input@xxxxxxxxxxxxxxx>; LKML > <linux-kernel@xxxxxxxxxxxxxxx>; stable@xxxxxxxxxxxxxxx > Subject: Re: [REGRESSION][v4.9.y][v4.10.y] Input: ALPS - set DualPoint > flag for 74 03 28 devices > > Oops, forgot the attachments > > On Sun, Mar 05, 2017 at 12:56:19PM -0500, Paul Donohue wrote: > > Masaki: Do you have any information about this touchpad you can share? Is the third byte in EC relevant to the protocol and something we should look for when identifying devices in the driver? > > > > Nick: > > > > Unfortunately, I didn't print quite enough information in the two-finger message, but yeah, this kinda looks like a different protocol. > > > > I've attached two tarballs this time: > > 1) alps_2a.tar.gz prints some additional info in the two-finger message which may help figure out what protocol your device is speaking: > > sudo -s > > dkms remove alps_ss5/1.0 --all > > cd /usr/src/ > > rm -rf alps_ss5-1.0 > > tar -xvzf alps_2a.tar.gz > > dkms install alps_ss5/1.0 > > modprobe -r psmouse ; modprobe psmouse # Try two-finger scrolling, > > then run: > > dmesg | grep 'two-finger' > > > > 2) alps_2b.tar.gz disables the driver unless the third byte in EC is 0x13 (the value my device uses) ... This driver should make your mouse work properly: > > sudo -s > > dkms remove alps_ss5/1.0 --all > > cd /usr/src/ > > rm -rf alps_ss5-1.0 > > tar -xvzf alps_2b.tar.gz > > dkms install alps_ss5/1.0 > > modprobe -r psmouse ; modprobe psmouse > > > > Try those out and let's see where that gets us. > > > > When you are done testing, you can revert back to whatever driver came with your kernel by running: > > sudo -s > > dkms remove alps_ss5/1.0 --all > > modprobe -r psmouse ; modprobe psmouse > > > > -Paul > > > > On Sun, Mar 05, 2017 at 09:09:01AM +0000, Nick Fletcher wrote: > > > Hi All, > > > > > > My touchpad has the physical buttons above the touchpad. > > > > > > I have cut and pasted the the results of the two dmesg commands > > > below. The trackpad of course stopped working correctly again > > > after installing alps_ss5-1.0. > > > > > > I'm afraid any experimenting with the code myself may be beyond my ability. > > > :-( > > > > > > root@brassneck-test:/usr/src# modprobe -r psmouse ; modprobe > > > psmouse root@brassneck-test:/usr/src# dmesg | grep 'ALPS ID' > > > [ 239.983818] psmouse serio1: alps: ALPS ID: E7=73 03 28, EC=73 > > > 01 > > > 14 [ 240.433532] psmouse serio1: alps: ALPS ID: E7=73 03 28, > > > EC=73 > > > 01 14 root@brassneck-test:/usr/src# dmesg | grep two-finger [ > > > 279.294490] psmouse serio1: alps: ALPS two-finger packet w/ button > > > (buttonpad: 0): d9 73 24 > > > > > > > > > Thank you for your help in this and thank you to Joseph for > > > building all the test kernels whilst attempting to find out which > > > commit first caused my issue. > > > > > > Cheers, > > > Nick. > > > > > > On 4 March 2017 at 16:15, Paul Donohue <linux-kernel@xxxxxxxxxx> wrote: > > > > > > > I have a 74 03 28 device on a Dell Precision laptop that handles > > > > two-finger scrolling fine. Without this patch, my mouse > > > > functions only as a dumb PS/2 mouse, which means I lose all > > > > multi-touch and scrolling capabilities entirely. So I would > > > > rather not see this reverted. :) > > > > > > > > I suspect one of two things: > > > > 1) My device has physical buttons below the touchpad. There are > > > > some different code paths for devices without physical buttons > > > > below the touchpad. Perhaps there is a bug in those alternate > > > > code paths? Does the buggy device have physical buttons? > > > > 2) Perhaps this is a new ALPS variant which speaks a new > > > > protocol that is not currently handled by the driver but which > > > > isn't properly identified/differentiated by the alps_identify() function? > > > > > > > > To get some additional data, grab the attached tarball, then: > > > > sudo -s > > > > cd /usr/src/ > > > > tar -xvzf alps_1.tar.gz > > > > apt install dkms > > > > dkms install alps_ss5/1.0 > > > > # Do not copy and paste the modprobe command! Type it manually! > > > > # Otherwise the mouse click used to paste the command at the > > > > same time as # reloading the driver may crash the kernel. > > > > modprobe -r psmouse ; modprobe psmouse dmesg | grep 'ALPS ID' > > > > > > > > In the dmesg output, you should see something like: > > > > psmouse serio1: alps: ALPS ID: E7=73 03 28, EC=73 01 13 > > > > > > > > Are the E7 and EC numbers identical to the above? > > > > > > > > Then try two-finger scrolling, then run: > > > > dmesg | grep 'two-finger' > > > > > > > > In the dmesg output, I expect you should see something like: > > > > psmouse serio1: alps: ALPS two-finger packet (buttonpad: 0): 1c > > > > 51 > > > > 46 > > > > > > > > We can compare your output to mine to see what is different. > > > > > > > > If you're willing to experiment with the code yourself to try to > > > > figure out more, the relevant code is in alps_decode_ss4_v2() in > > > > src/alps.c in that tarball. You should see the "ALPS two-finger > > > > packet" debug message I added there ... you can add additional > > > > debugging messages to figure out what exactly the decoder is > > > > doing. The SS4_* macros for bit manipulation and field > > > > extraction are defined near the top of src/alps.h. To recompile/reload the driver after making changes: > > > > dkms remove alps_ss5/1.0 --all > > > > dkms install alps_ss5/1.0 > > > > modprobe -r psmouse ; modprobe psmouse > > > > > > > > On Fri, Mar 03, 2017 at 02:58:34PM -0500, Joseph Salisbury wrote: > > > > > Hi Ben, > > > > > > > > > > A kernel bug report was opened against Ubuntu [0]. After a > > > > > kernel bisect, it was found that reverting the following > > > > > commit resolved this > > > > bug: > > > > > > > > > > commit aeaa881f9b17823028b464893b89c42db797b717 > > > > > Author: Ben Gamari <ben@xxxxxxxxxxxxxxxx> > > > > > Date: Tue Oct 4 11:43:30 2016 -0700 > > > > > > > > > > Input: ALPS - set DualPoint flag for 74 03 28 devices > > > > > > > > > > The regression was introduced as of v4.9-rc1. > > > > > > > > > > I was hoping to get your feedback, since you are the patch > > > > > author. Do you think gathering any additional data will help > > > > > diagnose this issue, or would it be best to submit a revert request? > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Joe > > > > > > > > > > [0] http://pad.lv/1662589 > > > > > > > > > >
Attachment:
4.10_kernel.tar.gz
Description: 4.10_kernel.tar.gz