Description of problem: I've Dell N5110 laptop with ALPS GlidePoint touchpad , The touchpad does only three things, Move , right click and left click , no scrolling and no multi touch just like any PS/2 Generic mouse Version-Release number of selected component (if applicable): 3.3.1-3.fc16.x86_64 How reproducible: Just try to scroll vertically or horizontally Actual results: Nothing but right, left click and moving cursor works Expected results: There should be as least vertical/horizontal scroll Additional info: $ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ PS/2 Generic Mouse id=13 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Video Bus id=8 [slave keyboard (3)] ↳ Power Button id=9 [slave keyboard (3)] ↳ Sleep Button id=10 [slave keyboard (3)] ↳ Laptop_Integrated_Webcam_HD id=11 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)] ↳ Dell WMI hotkeys id=14 [slave keyboard (3)] I: Bus=0011 Vendor=0002 Product=0001 Version=0000 N: Name="PS/2 Generic Mouse" P: Phys=isa0060/serio1/input0 S: Sysfs=/devices/platform/i8042/serio1/input/input5 U: Uniq= H: Handlers=mouse0 event5 B: PROP=0 B: EV=7 B: KEY=70000 0 0 0 0 B: REL=3 I've seen some people says it worked with them on laster versions of kernel when psmouse module was regular module
same here, Dell Inspiron 15R N5110 with Fedora 16 on kernel 3.3.2-1.fc16.x86_64 (from updates-testing repo) I: Bus=0011 Vendor=0002 Product=0001 Version=0000 N: Name="PS/2 Generic Mouse" P: Phys=isa0060/serio1/input0 S: Sysfs=/devices/platform/i8042/serio1/input/input5 U: Uniq= H: Handlers=mouse0 event5 B: PROP=0 B: EV=7 B: KEY=70000 0 0 0 0 B: REL=3 The workarounds on google, require users to recompile the kernel and is meant for older version of the kernel.
Same he on a Dell E6430 with Fedora 17 on kernel 3.4.4-3.fc17.x86_64 I: Bus=0011 Vendor=0002 Product=0001 Version=0000 N: Name="PS/2 Generic Mouse" P: Phys=isa0060/serio1/input0 S: Sysfs=/devices/platform/i8042/serio1/input/input5 U: Uniq= H: Handlers=mouse0 event5 B: PROP=0 B: EV=7 B: KEY=70000 0 0 0 0 B: REL=3 Best lead I've got so far is https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/681904/comments/59 but it's beyond me to compile and test this patch.
Hmmm, is this something to do with https://bugzilla.redhat.com/show_bug.cgi?id=590880 coming back to haunt us?
*** Bug 825326 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > Hmmm, is this something to do with > https://bugzilla.redhat.com/show_bug.cgi?id=590880 coming back to haunt us? I doubt it. That was to add basic support for ALPS in general. There are variations of ALPS that require different protocol support in the alps driver. The newest version is v4, and that only has semi-MT support added in the upcoming 3.5 kernel. Unfortunately, there isn't a very handy way to figure out from userspace which version is present in a machine. Given that nobody has indicated the scroll or MT features worked in a previous kernel, I'm inclined to think the models here are all v4. If that's the case, then it's a matter of waiting for 3.5 to land in f16/f17 most likely.
Created attachment 596668 [details] alps-reg-dump If someone wanted to run the attached alps-reg-dump binary as root, it might give a bit more insight as to which ALPS model is present in these machines. It has been compiled on an F17 system, but should work elsewhere as well.
(In reply to comment #6) > Created attachment 596668 [details] > alps-reg-dump > > If someone wanted to run the attached alps-reg-dump binary as root, it might > give a bit more insight as to which ALPS model is present in these machines. > It has been compiled on an F17 system, but should work elsewhere as well. If you do that, you might need to load the 'serio_raw' module if it isn't already loaded.
http://www.spinics.net/lists/linux-input/msg21496.html highlights the crux of the issue mostly.
I reported Bug 825326. The normal functionality such as side/horizontal doesn't work from the start. The only thing that works properly is moving the cursor around and using the left/right click to select. The touch click isn't working great as well either. I tried out the attached alps-reg-dump binary as root after enabling the "serio_raw" module. And following is the output; Found serio mouse at /sys/bus/serio/devices/serio1/ E7 report: 73 03 50 Not a v3 ALPS touchpad Do let me know of if you got any other options to debug this touchpad bug, I'll be happy to help. :)
This scratch build contains the trial patch mentioned in the thread in comment #8. For those of you willing, please install this when it completes building and provide the output of dmesg after boot. http://koji.fedoraproject.org/koji/taskinfo?taskID=4223741
(In reply to comment #10) > This scratch build contains the trial patch mentioned in the thread in > comment #8. For those of you willing, please install this when it completes > building and provide the output of dmesg after boot. > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4223741 Sorry, I'm abit unfamiliar with installing from Koji, how do you go about doing that? Do I just download the kernel-3.4.4-5.1.fc17.x86_64.rpm from there and install?
(In reply to comment #11) > (In reply to comment #10) > > This scratch build contains the trial patch mentioned in the thread in > > comment #8. For those of you willing, please install this when it completes > > building and provide the output of dmesg after boot. > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4223741 > > Sorry, I'm abit unfamiliar with installing from Koji, how do you go about > doing that? Do I just download the kernel-3.4.4-5.1.fc17.x86_64.rpm from > there and install? Yes. Just download it and then 'yum localinstall --nogpg kernel-3.4.4-5.1.fc17.x86_64.rpm'
Created attachment 597622 [details] output of dmesg after boot As requested here is the output of dmesg after boot, after installing the kernel from the scratch koji build.
(In reply to comment #13) > Created attachment 597622 [details] > output of dmesg after boot > > As requested here is the output of dmesg after boot, after installing the > kernel from the scratch koji build. OK, so you have the same results the upstream reporter did. Which is unfortunate because basically Linux does not know how to talk to this version of the ALPS at all. The protocol will have to be reverse engineered and without direct access to the hardware that will be difficult to do. If someone wishes to tackle it themselves, Seth Forshee wrote up a how he did this originally for the ALPS here: http://swapspace.forshee.me/2011/11/touchpad-protocol-reverse-engineering.html I'm going to move this to rawhide as there will not be a fix coming in the near future.
Same here with Dell Vostro 3360, kernel 3.4.4-5.fc17.x86_64. $ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ PS/2 Generic Mouse id=12 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Power Button id=8 [slave keyboard (3)] ↳ Sleep Button id=9 [slave keyboard (3)] ↳ Laptop_Integrated_Webcam_E4HD id=10 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=11 [slave keyboard (3)] ↳ Dell WMI hotkeys id=13 [slave keyboard (3)]
*** Bug 846263 has been marked as a duplicate of this bug. ***
Just to point out in the main report I have also a dell M4700 and I have the same problem. Here there is a bug report for another dell laptop that might be related: https://bugzilla.kernel.org/show_bug.cgi?id=45201 And a mailing list: http://www.spinics.net/lists/linux-input/msg21728.html
Result from executing the alps-reg-dump Found serio mouse at /sys/bus/serio/devices/serio1/ E7 report: 73 03 0a Not a v3 ALPS touchpad
Some more information, I decided to hack a bit on the alps.c code and adding the next lines make the touchpad to be detected: { { 0x73, 0x03, 0x0a }, 0x00, ALPS_PROTO_V2, 0xcf, 0xcf, ALPS_PASS | ALPS_DUALPOINT | ALPS_PS2_INTERLEAVED }, nacho@winterfell mouse]$ xinput -list⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ DualPoint Stick id=12 [slave pointer (2)] ⎜ ↳ AlpsPS/2 ALPS DualPoint TouchPad id=14 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Power Button id=8 [slave keyboard (3)] ↳ Sleep Button id=9 [slave keyboard (3)] ↳ Laptop_Integrated_Webcam_E4HD id=10 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=11 [slave keyboard (3)] ↳ Dell WMI hotkeys id=13 [slave keyboard (3)] Although it does not seem to make any different. Maybe due to the magic 0xcf, 0xcf which I don't really know what to put there. As you can see it is detected when using the protocol version 2, but it is not detected with the v3 and neither with the v4. Can you please provide some more information on why this could not be working properly?
Also having the same issue on Dell Inspiron 15R N5110 running F17 3.5.0-2.fc17.x86_64.
I unable to get the system to even recognize the Alps touchpad. Would anyone be able to point out a way to do that (new to this level of tinkering)? I am building alps.c in a local directory and installing using [1] with the following modification: { { 0x73, 0x03, 0x50 }, 0x00, ALPS_PROTO_V2, 0x8f, 0x8f, ALPS_DUALPOINT } alps-reg-dump produces the following output: Found serio mouse at /sys/bus/serio/devices/serio1/ E7 report: 73 03 50 Not a v3 ALPS touchpad Issuing the make install command places alps.ko in /lib/modules/3.5.1-1.fc17.x86_64/extra rather than /lib/modules/3.5.1-1.fc17.x86_64/kernel/drivers/input/mouse. Is this correct or I am doing something wrong? http://fedoraproject.org/wiki/Building_a_custom_kernel#Building_Only_Kernel_Modules_.28Out_Of_Tree_Modules.29
Hey guys, I just tested the patch here: https://github.com/bgamari/linux/tree/alps and it seems to be working like a charm for me. This was tested with linux 3.5.0 so if you can please patch the next version of the kernel would be great.
(In reply to comment #22) > Hey guys, I just tested the patch here: > https://github.com/bgamari/linux/tree/alps > and it seems to be working like a charm for me. This was tested with linux > 3.5.0 so if you can please patch the next version of the kernel would be > great. Needs to be submitted upstream and reviewed first.
*** Bug 850800 has been marked as a duplicate of this bug. ***
I also tried the patch from comment 22 and everything works fine on my Dell Latitude E6430.
I have same problem on Dell Inspiron 7720. After installing modules with patch nothing is changed. I tried to replace old modules by new ones, but it did not help.
Received Dell Vostro V3360 today, currently running 3.5.3-1.fc17.x86_64 and having same issues as decribed above (bare touchpad actions, no finger scrolling etc.). alps-dump-reg produces: Found serio mouse at /sys/bus/serio/devices/serio1/ E7 report: 73 03 50 Not a v3 ALPS touchpad I am happy and willing to tinker with alps.c sources found at [1] (as suggested in comment #22) and rebuild the kernel module to find working combination, however I'm stuck and would appreciate any guidance how to do it properly. Basically, I'm following advice in [2] to compile the module in local dir and the result of that is as follows: 23:29 evad@v3350 alps $ make make -C /lib/modules/3.5.3-1.fc17.x86_64/build M=/home/evad/Downloads/alps modules make[1]: Entering directory `/usr/src/kernels/3.5.3-1.fc17.x86_64' Building modules, stage 2. MODPOST 1 modules WARNING: "psmouse_reset" [/home/evad/Downloads/alps/alps.ko] undefined! make[1]: Leaving directory `/usr/src/kernels/3.5.3-1.fc17.x86_64' 23:29 evad@v3350 alps $ sudo insmod alps.ko Error: could not insert module alps.ko: Unknown symbol in module If anyone could point out how to corrently rebuild the module, I'd be more than grateful. [1] https://github.com/bgamari/linux/commit/1527416a726b823225f97c4d733dcdd9df7f50d6 [2] http://fedoraproject.org/wiki/Building_a_custom_kernel#Building_Only_Kernel_Modules_.28Out_Of_Tree_Modules.29
Let me just point out that the laptop originally shipped with pre-installed Ubuntu 11.10 where touchpad was properly supported with features like two-finger scrolling etc. It was appearing in syslog as: Sep 17 21:13:17 dell-desktop kernel: [ 24.389806] input: GlidePoint Virtual Touchpad as /devices/virtual/input/input12 I can still boot that original Ubuntu from the external drive so can possibly help digging out additional details from there.
Hello -- I have a new Dell E6430 that I'd really like to get the scrolling function working and would like to try to patch listed in comment 22. However, I just can't find a way to get it in a way that I'm familiar with. If I knew how to pull down the patch files I think I can handle the rest. Thanks.
(In reply to comment #28) > Let me just point out that the laptop originally shipped with pre-installed > Ubuntu 11.10 where touchpad was properly supported with features like > two-finger scrolling etc. It was appearing in syslog as: > > Sep 17 21:13:17 dell-desktop kernel: [ 24.389806] input: GlidePoint Virtual > Touchpad as /devices/virtual/input/input12 > > I can still boot that original Ubuntu from the external drive so can > possibly help digging out additional details from there. Can you share your backup of Ubuntu? I erase my system without saving and now missed about it.
(In reply to comment #30) > Can you share your backup of Ubuntu? I erase my system without saving and > now missed about it. Are you asking me to provide a full image of my Ubuntu installation?
(In reply to comment #31) > (In reply to comment #30) > > Can you share your backup of Ubuntu? I erase my system without saving and > > now missed about it. > > Are you asking me to provide a full image of my Ubuntu installation? Yes
(In reply to comment #32) > > Are you asking me to provide a full image of my Ubuntu installation? > > Yes Hmm, I don't have recovery DVD, it just didn't ship with the laptop.
I've just gotten a Dell latitude E6430 and the problem as described here persists. I did look at the patches mentioned in comment #22 but I would rather that it is made upstream. Anyone know if the patches have been sent upstream yet? I'm running 3.5.4-2.fc17.x86_64. Thanks.
I also have a Dell Latitude E6430 and have yesterday uninstalled Ubuntu 12.04 in favor of Fedora 17. I am running 3.5.5-2.fc17.x86_64 and also with this version the problem still persists $ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Logitech USB-PS/2 Optical Mouse id=11 [slave pointer (2)] ⎜ ↳ PS/2 Generic Mouse id=14 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Video Bus id=8 [slave keyboard (3)] ↳ Power Button id=9 [slave keyboard (3)] ↳ Sleep Button id=10 [slave keyboard (3)] ↳ Laptop_Integrated_Webcam_E4HD id=12 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)] ↳ Dell WMI hotkeys id=15 [slave keyboard (3)] In Ubuntu I have tried the patches as mentioned in comment #22 but have removed the patches since it resulted in very twitchy mouse movements. Haven't tried the patch yet in Fedora but a bit hesitant to do so based on previous experiences.
I'm not sure where this is at upstream, but each time a new kernel is released for f17 I'm adding the following patch and then recompiling without issue. Any chance this patch could be added to the builds until upstream delivers it?
Created attachment 643828 [details] patch for kernel to get alps working I've applied this to every kernel since it joined this bug and it's worked fine. Can it be added to the list of patched so it just works?
(In reply to comment #38) > Created attachment 643828 [details] > patch for kernel to get alps working > > I've applied this to every kernel since it joined this bug and it's worked > fine. Can it be added to the list of patched so it just works? Not as-is. Did you author the patch? If so, can you send it to the linux-input mailing list for incluion, including your Signed-off-by:? If you didn't author it, where did you get it or derive it from? The tree pointed to in comment #22?
Created attachment 643927 [details] patch for kernel to get alps working I've applied this to every kernel since I joined this bug and it's worked fine. Can it be added to the list of patched so it just works?
(In reply to comment #40) > Created attachment 643927 [details] > patch for kernel to get alps working > > I've applied this to every kernel since I joined this bug and it's worked > fine. Can it be added to the list of patched so it just works? Er... yes. You said that earlier in comment #38. All of the questions I asked in comment #39 still stand.
Ah, yes sorry about comment #40, had some internet issues and the posting got a little wiggle and I didn't realized I'd posted twice. I didn't author the patch, so that should clear up question number one. I'm pretty sure I yanked it from the tree pointed to in comment #22. I'm pretty sure I used it as is and didn't need to perform any jiggery pokey.
I am having this problem as well with an Dell Latitude e6430: the touchpad is recognized as a regular mouse. It's not possible to disable the touchpad while typing, which is a little annoying. A patched kernel would be appreciated :)
(In reply to comment #42) > I didn't author the patch, so that should clear up question number one. OK. > I'm pretty sure I yanked it from the tree pointed to in comment #22. I'm Sigh. OK. I guess I'll have to email this person and ask them why they're sitting on code and not pushing it upstream.
For the sake of completeness I think ubuntu made another patch by themselves. Although I haven't tested it, the one that I still use is the one I pointed out in previous comments. I also made a contact with Ben not too long ago and he said that there was something missing and that was the reason to not include it upstream. Although I would still apply this downstream. It is better having it working than not working at all. Once it is working upstream you can always drop the patch downstream.
There is the ALPS v5 and v6 support at http://www.dahetral.com/public-download AUR package psmouse-alps-driver works fine. https://bugzilla.kernel.org/show_bug.cgi?id=45201#c8 https://bbs.archlinux.org/viewtopic.php?id=144118&p=1 seems fedora kernel config doesn't build psmouse and alps as kernel module, so I didn't get the ko. Can we have a kernel build with this patch before upstream merge it? Thanks.
Just wanted to add, that installing "psmouse-alps kernel patch candidate" from http://www.dahetral.com/public-download against 3.6.10-2.fc17.x86_64 worked for Dell Inspiron 17R 7720. Unfortunately it required recompiling kernel with psmouse built as module. $ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Logitech Gaming Mouse G400 id=11 [slave pointer (2)] ⎜ ↳ PS/2 Mouse id=14 [slave pointer (2)] ⎜ ↳ AlpsPS/2 ALPS GlidePoint id=15 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Video Bus id=8 [slave keyboard (3)] ↳ Power Button id=9 [slave keyboard (3)] ↳ Sleep Button id=10 [slave keyboard (3)] ↳ Laptop_Integrated_Webcam_HD id=12 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)] ↳ Dell WMI hotkeys id=16 [slave keyboard (3)]
I can also confirm comment 47. I downloaded the kernel sources, added the modified alps.c and alps.h to the source, and recompiled the kernel. This is on a Dell Latitude E6430 % xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ DualPoint Stick id=12 [slave pointer (2)] ⎜ ↳ AlpsPS/2 ALPS DualPoint TouchPad id=13 [slave pointer (2)] ⎜ ↳ Logitech Unifying Device. Wireless PID:101a id=18 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Power Button id=8 [slave keyboard (3)] ↳ Sleep Button id=9 [slave keyboard (3)] ↳ Laptop_Integrated_Webcam_E4HD id=10 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=11 [slave keyboard (3)] ↳ Dell WMI hotkeys id=14 [slave keyboard (3)] ↳ UVC Camera (046d:0825) id=15 [slave keyboard (3)] ↳ Dell Dell USB Keyboard Hub id=16 [slave keyboard (3)] ↳ Dell Dell USB Keyboard Hub id=17 [slave keyboard (3)]
Can we please face that this has not been fixed yet in the new kernel 3.7.x so it would be nice to have it for now fixed downstream?
(In reply to comment #49) > Can we please face that this has not been fixed yet in the new kernel 3.7.x > so it would be nice to have it for now fixed downstream? If I can get a viable patchset with an actual Signed-off-by from an author that says they actually wrote the patch, then I'd probably bring it in. As of yet, that hasn't happened. There's a random patch someone wrote and didn't bother to push upstream. Then there's another patch that someone wrote, didn't push upstream, and then said it isn't correct. Then there's some Ubuntu thing I've yet to see anywhere. I understand people are frustrated with this bug, but the origin of the code actually matters. I'm willing to carry something out of tree for a while assuming it: 1) follows the normal patch submission rules and includes a Signed-off-by from the original author(s) 2) has been submitted to upstream and is being worked on actively 3) doesn't break anything for other people
Seems that here is where the development is happening: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238 And as spotted there the code can be found here: http://www.dahetral.com/public-download Although there seems to not be a real signed off patch that we can directly apply....
Hmmm, as of 3.7.1-2 in f18 the patch I've been using no longer applies for me. I get: + ApplyPatch linux-3.5-e6430.patch + local patch=linux-3.5-e6430.patch + shift + '[' '!' -f /home/rodd/rpmbuild/SOURCES/linux-3.5-e6430.patch ']' Patch99000: linux-3.5-e6430.patch + case "$patch" in + patch -p1 -F1 -s 1 out of 6 hunks FAILED -- saving rejects to file drivers/input/mouse/alps.c.rej error: Bad exit status from /var/tmp/rpm-tmp.FSZPXN (%prep)
Created attachment 676678 [details] patch for kernel to get alps working on kernels after 3.7.x
*** Bug 895065 has been marked as a duplicate of this bug. ***
So it seems that in the ubuntu bug it can be found the format patches signed off, here are the direct links: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238/+attachment/3413410/+files/0001-alps.patch https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238/+attachment/3413411/+files/0002-alps.patch https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238/+attachment/3418538/+files/alps_patch_fix_for_e6530.patch https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238/+attachment/3424714/+files/0003-alps.patch Please consider the inclusion.
(In reply to comment #55) > So it seems that in the ubuntu bug it can be found the format patches signed > off, here are the direct links: > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238/+attachment/ > 3413410/+files/0001-alps.patch > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238/+attachment/ > 3413411/+files/0002-alps.patch > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238/+attachment/ > 3418538/+files/alps_patch_fix_for_e6530.patch > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238/+attachment/ > 3424714/+files/0003-alps.patch > > Please consider the inclusion. I looked these over today. They aren't immediately applicable. I emailed the author of the patches. He said they're against the Ubuntu 3.2 kernel (12.04 release I think?). At best they'll need to be forward ported to the appropriate kernel versions before they can be tested. In the meantime I'm trying to help/encourage their submission to upstream. So progress is being made, but it will not be quick. Thank you for pointing these patches out.
Is there anything I can do to make it quicker? Maybe I could try to port them to the new kernel version
I gave this a try and the result is here: https://github.com/nacho/alps-kernel-3-7/ IMHO these patches need some more cleanup. I managed to apply them and backport the things that didn't cleanly apply but there are things in these patches that looks just like a cleanup. For my laptop a Dell Precision M4700 seems to work correctly although it would be bad a cleanup.
I'm on a Dell Latitude E6530 on Fedora 18 3.7.4-204.fc18.x86_64 Appreciate the post Ignacio: https://github.com/nacho/alps-kernel-3-7/ However I'm having issues generating the psmouse.ko using your script: [root@Philo mouse]# make -C /lib/modules/`uname -r`/build M=`pwd` psmouse.ko make: Entering directory `/usr/src/kernels/3.7.4-204.fc18.x86_64' CC /root/alps-kernel-3-7/drivers/input/mouse/psmouse-base.o CC /root/alps-kernel-3-7/drivers/input/mouse/synaptics.o CC /root/alps-kernel-3-7/drivers/input/mouse/alps.o CC /root/alps-kernel-3-7/drivers/input/mouse/elantech.o CC /root/alps-kernel-3-7/drivers/input/mouse/logips2pp.o CC /root/alps-kernel-3-7/drivers/input/mouse/lifebook.o CC /root/alps-kernel-3-7/drivers/input/mouse/sentelic.o CC /root/alps-kernel-3-7/drivers/input/mouse/trackpoint.o LD /root/alps-kernel-3-7/drivers/input/mouse/psmouse.o MODPOST 0 modules make: Leaving directory `/usr/src/kernels/3.7.4-204.fc18.x86_64' I tried using the fix posted here: http://www.dahetral.com/public-download/psmouse-alps-dst-1.1.tbz/view which supposedly has fixes for my laptop model but it doesn't seem to be updated for kernel 3.7.x would really like to see a fix for this, thanks
(In reply to comment #59) > I'm on a Dell Latitude E6530 on Fedora 18 3.7.4-204.fc18.x86_64 > > Appreciate the post Ignacio: > > https://github.com/nacho/alps-kernel-3-7/ > See that in order to use this in fedora first you need to rebuild the kernel to make the psmouse a module. And then is when you can replace the module with the one you built from my branch. See the steps here to know how to build a custom kernel: http://fedoraproject.org/wiki/Building_a_custom_kernel And you have to just change the line in config-generic from: CONFIG_MOUSE_PS2=y to CONFIG_MOUSE_PS2=m Hope it helps. > However I'm having issues generating the psmouse.ko using your script: > > [root@Philo mouse]# make -C /lib/modules/`uname -r`/build M=`pwd` psmouse.ko > make: Entering directory `/usr/src/kernels/3.7.4-204.fc18.x86_64' > CC /root/alps-kernel-3-7/drivers/input/mouse/psmouse-base.o > CC /root/alps-kernel-3-7/drivers/input/mouse/synaptics.o > CC /root/alps-kernel-3-7/drivers/input/mouse/alps.o > CC /root/alps-kernel-3-7/drivers/input/mouse/elantech.o > CC /root/alps-kernel-3-7/drivers/input/mouse/logips2pp.o > CC /root/alps-kernel-3-7/drivers/input/mouse/lifebook.o > CC /root/alps-kernel-3-7/drivers/input/mouse/sentelic.o > CC /root/alps-kernel-3-7/drivers/input/mouse/trackpoint.o > LD /root/alps-kernel-3-7/drivers/input/mouse/psmouse.o > MODPOST 0 modules > make: Leaving directory `/usr/src/kernels/3.7.4-204.fc18.x86_64' > > I tried using the fix posted here: > > http://www.dahetral.com/public-download/psmouse-alps-dst-1.1.tbz/view > > which supposedly has fixes for my laptop model but it doesn't seem to be > updated for kernel 3.7.x > > would really like to see a fix for this, thanks
Ignacio I'll give this a shot. Keep in mind the fix from http://www.dahetral.com/public-download/psmouse-alps-dst-1.1.tbz/view uses DKMS which Fedora supports meaning a kernel recompile isn't needed. Like I said, I don't think the above patch has been updated for kernel 3.7, however it does include fixes for the touchpad on the Latitude E6530. Have you had reports of any successes on this model with your patch from: https://github.com/nacho/alps-kernel-3-7/ ? Just trying to see what I need to add to my "todo" list. When I run a diff between the code bases I don't think I saw any "conflicts" just different revisions to different areas, though my C is pretty weak so I may have missed something.
Sam P, just tried it with my laptop a Precision M4700
After having a colleague tinker with it we got it working on my setup with the patch from: https://github.com/nacho/alps-kernel-3-7/ Despite Fedora supporting DKMS, if the "module" is already compiled into the kernel then it can't be replaced; there is no starting psmouse.ko file to work with. He was able to recompile the kernel specifying psmouse.ko to be generated as a module which allowed it to be replaced with a custom psmouse.ko built from Ignacio's source. The mouse is working fine; I haven't encountered any issues yet. Would really like to see this patched upstream in a kernel update so I don't have to keep rebuilding the kernel each time. Thanks for the help Ignacio, Dave, and Kevin.
Is anything else to do? I dont see psmouse.ko to load. [mateus@mluvison mouse]$ make -C /lib/modules/`uname -r`/build M=`pwd` psmouse.ko make: Entering directory `/usr/src/kernels/3.7.5-201.fc18.x86_64' CC /tmp/alps-kernel-3-7-master/drivers/input/mouse/psmouse-base.o CC /tmp/alps-kernel-3-7-master/drivers/input/mouse/synaptics.o CC /tmp/alps-kernel-3-7-master/drivers/input/mouse/alps.o CC /tmp/alps-kernel-3-7-master/drivers/input/mouse/elantech.o CC /tmp/alps-kernel-3-7-master/drivers/input/mouse/logips2pp.o CC /tmp/alps-kernel-3-7-master/drivers/input/mouse/lifebook.o CC /tmp/alps-kernel-3-7-master/drivers/input/mouse/sentelic.o CC /tmp/alps-kernel-3-7-master/drivers/input/mouse/trackpoint.o LD /tmp/alps-kernel-3-7-master/drivers/input/mouse/psmouse.o MODPOST 0 modules make: Leaving directory `/usr/src/kernels/3.7.5-201.fc18.x86_64' [mateus@mluvison mouse]$ uname -a Linux mluvison 3.7.5-201.fc18.x86_64 #1 SMP Mon Jan 28 19:54:41 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Thanks.
MODPOST 0 modules means that it failed. You'll need to increase the verbosity on your make command to see the error. Did you recompile the kernel? Before you even start trying to build psmouse.ko you need one to switch out in the first place. The prebuilt kernel that ships with fed 18 has psmouse built into it; not as a module. Recompile your kernel, but per Ignacio: """ And you have to just change the line in config-generic from: CONFIG_MOUSE_PS2=y to CONFIG_MOUSE_PS2=m """ once you've recompiled the kernel you should see a psmouse.ko in the build directory that you can replace.
As this seems to be a long and tortuous road. Would it not be a plan to get psmouse separated out as a .ko in the stock Fedora build, so at least those wanting to do this don't have to rebuild every kernel they want to use?
The latest development seems to be a series of 14 patches actually submitted upstream: http://thread.gmane.org/gmane.linux.kernel.input/29102 Those have the support of the author of the patches from the ubuntu bug mentioned in comment #55: http://article.gmane.org/gmane.linux.kernel.input/29197 They haven't been pulled into the input git tree yet, but hopefully they'll get some review and inclusion soon.
I've started a scratch build with a kernel that has the 14 patch series applied. Assuming it finishes building, testing would be appreciated: http://koji.fedoraproject.org/koji/taskinfo?taskID=4953214
*** Bug 851649 has been marked as a duplicate of this bug. ***
(In reply to comment #68) > I've started a scratch build with a kernel that has the 14 patch series > applied. Assuming it finishes building, testing would be appreciated: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4953214 Awesome, hope to see this in the main channels in the upcoming weeks. For testing can you make a build for fc18?
Josh, any chance to make a build for f18 so we can get it a bit more testing?
Ran the artefacts at http://koji.fedoraproject.org/koji/taskinfo?taskID=4953214 The machine (Dell Latitude 6530) booted as far as: kernel: [ 88.792396] cgroup: libvirtd (1600) created nested cgroup for controller "blkio" which has incomplete hierarchy support. Nested cgroups may change behavior in the future. Then jammed solid. This was under F18 though.
An F18 kernel will take longer to do, as the patches need some minor backporting. I'll try to get to it today. Andrew's issues aside, the 3.8-rc7 kernel should be compatible with F18 anyway. Andrew, if you could test any other rawhide kernel to see if it is these specific patches causing he issues, that would be appreciated.
Here's an F18 kernel to test when it finishes building: http://koji.fedoraproject.org/koji/taskinfo?taskID=4956595
(In reply to comment #74) > Here's an F18 kernel to test when it finishes building: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4956595 For some reason gdm doesn't start for me with this kernel. Probably something related with the nvidia prop driver.
> Here's an F18 kernel to test when it finishes building: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4956595 I tried this new one and sadly it jams at the same point as http://koji.fedoraproject.org/koji/taskinfo?taskID=4953214
(In reply to comment #75) > (In reply to comment #74) > > Here's an F18 kernel to test when it finishes building: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4956595 > > For some reason gdm doesn't start for me with this kernel. Probably > something related with the nvidia prop driver. Yeah, don't use that. Or rebuild/update it. (In reply to comment #76) > > Here's an F18 kernel to test when it finishes building: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4956595 > > I tried this new one and sadly it jams at the same point as > http://koji.fedoraproject.org/koji/taskinfo?taskID=4953214 Are you also using a proprietary driver?
> Are you also using a proprietary driver? I am using the nVidia driver. The nouveau driver is badly broken on my platform; it will lock up several times a day. Separate bug already raised.
(In reply to comment #78) > > Are you also using a proprietary driver? > > I am using the nVidia driver. The nouveau driver is badly broken on my > platform; it will lock up several times a day. Separate bug already raised. OK, well given the limited information you've presented, I'd be willing to say that is causing your issues and not the ALPS patches. Unfortunately, it also means you can't test the touchpad. We'll need someone not using the nVidia driver to give one of these kernels a try on their machine.
See that I am using the akmod driver, and it was working with all the kernels till now... might nvidia has not updated the driver for 3.7.7... it works though with 3.7.4
> OK, well given the limited information you've presented, I'd be willing > to say that is causing your issues and not the ALPS patches. > Unfortunately, it also means you can't test the touchpad. Sadly this means that once this update has made its way through, Fedora will become unusable on a whole series of Dell laptops. The Nouveau drivers freeze, crash gnome-shell, fail suspend and if that works fail resume. Now it seems that once this comes through, those who have decided to use the nvidia drivers in order to get anywhere with their laptop, won't even be able to boot.
(In reply to comment #80) > See that I am using the akmod driver, and it was working with all the > kernels till now... might nvidia has not updated the driver for 3.7.7... it > works though with 3.7.4 The nvidia build scripts have a broken version check that fails after 3.7.4. It's already been reported multiple places. There's nothing we can do about that.
(In reply to comment #74) > Here's an F18 kernel to test when it finishes building: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4956595 Where is the build at? I'm using an E6530 with the intel driver on fc18 so I'd want to test this kernel but I can't find your build. If you point me to it I'll be happy to test it for you.
(In reply to comment #83) > (In reply to comment #74) > > Here's an F18 kernel to test when it finishes building: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4956595 > > Where is the build at? Right there... click the green x86_64 or i686 link, then download the kernel package from the output section on that page.
(In reply to comment #74) > Here's an F18 kernel to test when it finishes building: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4956595 Ok, downloaded and installed the kernel: 3.7.7-201.5.fc18.x86_64 #1 SMP Wed Feb 13 15:54:19 UTC 2013 Although I get these "Mouse & Touchpad" options (see pic): http://www.mavjs.org/tmp/alps-touch-nogo/image and according to `xinput list`: ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ PS/2 Mouse id=14 [slave pointer (2)] ⎜ ↳ AlpsPS/2 ALPS GlidePoint id=15 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Video Bus id=8 [slave keyboard (3)] ↳ Power Button id=9 [slave keyboard (3)] ↳ Sleep Button id=10 [slave keyboard (3)] ↳ Laptop_Integrated_Webcam_HD id=11 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)] ↳ Dell WMI hotkeys id=16 [slave keyboard (3)] I still can't do scrolling. I'm on a Dell Inspiron 15R N5110.
(In reply to comment #84) > (In reply to comment #83) > > (In reply to comment #74) > > > Here's an F18 kernel to test when it finishes building: > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4956595 > > > > Where is the build at? > > Right there... click the green x86_64 or i686 link, then download the > kernel package from the output section on that page. Derp. Well I installed it and it appears to be working fine. I haven't tested bumblebee/optimus but I've been having other issues with that anyway. Any idea on when we can see this upstream?
(In reply to comment #85) > (In reply to comment #74) > > Here's an F18 kernel to test when it finishes building: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4956595 > > Ok, downloaded and installed the kernel: > > 3.7.7-201.5.fc18.x86_64 #1 SMP Wed Feb 13 15:54:19 UTC 2013 Great. Thanks for testing. > I still can't do scrolling. I'm on a Dell Inspiron 15R N5110. According to the patches, that machine has a "Dolphin" model touchpad. The support for that is experimental and still being worked on. According to the upstream thread, they know there are some pressure sensing issues at the edges, so that is probably why scrolling doesn't work for you: http://thread.gmane.org/gmane.linux.kernel.input/29102 it's being worked on. There is hope.
(In reply to comment #86) > (In reply to comment #84) > > (In reply to comment #83) > > > (In reply to comment #74) > > > > Here's an F18 kernel to test when it finishes building: > > > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4956595 > > > > > > Where is the build at? > > > > Right there... click the green x86_64 or i686 link, then download the > > kernel package from the output section on that page. > > Derp. Well I installed it and it appears to be working fine. I haven't > tested bumblebee/optimus but I've been having other issues with that anyway. > Any idea on when we can see this upstream? Great, thanks for testing. Optimus is entirely outside the scope of this bug, but yeah it's in a known suboptimal state. The ALPS patches were pulled into the upstream linux-input maintainer's git tree, so they should be officially upstream in 3.9. We can carry them as patches in Fedora until then.
(In reply to comment #87) > (In reply to comment #85) > > (In reply to comment #74) > > > Here's an F18 kernel to test when it finishes building: > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4956595 > > > > Ok, downloaded and installed the kernel: > > > > 3.7.7-201.5.fc18.x86_64 #1 SMP Wed Feb 13 15:54:19 UTC 2013 > > Great. Thanks for testing. > > > I still can't do scrolling. I'm on a Dell Inspiron 15R N5110. > > According to the patches, that machine has a "Dolphin" model touchpad. The > support for that is experimental and still being worked on. According to > the upstream thread, they know there are some pressure sensing issues at the > edges, so that is probably why scrolling doesn't work for you: > > http://thread.gmane.org/gmane.linux.kernel.input/29102 > > it's being worked on. There is hope. Argh, read that thread a couple of days ago, but not thoroughly. Noted! Thanks. :)
I've been using the 2.8.x kernel and it's working a treat.
I tried the 3.7.7-201.5 fc18 kernel in a Dell Inspiron 7720 (17Rse). Indeed the ALPS Glidepoint is now recognized (Xorg.0.log, xinput, etc) but still NO scrolling possible. I tried the new Sabayon_Linux_amd64_G.iso (live) and there the ALPS worked perfectly with scrolling! They also use synaptics driver but I didn't compare the settings in Xorg.0.log with those in F18 when using 3.7.7-201.5. I do not know if they are using the same patches.
Arggh, didn't do so well posting that last comment. Troubles in tablet land. Sorry. What I should have said was I've been using 3.8.0-0.rc7.git0.2.5.fc19.x86_64 on a Dell E6430 and it's been working wonderfully.
Here's a slightly updated F18 build for testing: http://koji.fedoraproject.org/koji/taskinfo?taskID=5032773 Theoretically things should work better for those of you with 17Rse or N5110 machines as I've pulled in the first two patches from this thread: http://thread.gmane.org/gmane.linux.kernel.input/29273 Testing would be appreciated. If things are working well overall, I'll get these committed to the Fedora kernel.
Will these changes also be committed to the Fedora 17 kernel? I'm still using fedora 17 and I would love to have these fixes available.
(In reply to comment #96) > Will these changes also be committed to the Fedora 17 kernel? I'm still > using fedora 17 and I would love to have these fixes available. If someone tests them and they don't break things, yes.
I can test them!
(In reply to comment #98) > I can test them! http://koji.fedoraproject.org/koji/taskinfo?taskID=5032968 There you go. Test away when it finished building and let us know how it goes.
(In reply to comment #95) > Here's a slightly updated F18 build for testing: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=5032773 > > Theoretically things should work better for those of you with 17Rse or N5110 > machines as I've pulled in the first two patches from this thread: > > http://thread.gmane.org/gmane.linux.kernel.input/29273 > > Testing would be appreciated. If things are working well overall, I'll get > these committed to the Fedora kernel. Tried this FC18 build and it worked fine on my Dell Latitude E6530, thanks Josh
(In reply to comment #95) > Here's a slightly updated F18 build for testing: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=5032773 > > Theoretically things should work better for those of you with 17Rse or N5110 > machines as I've pulled in the first two patches from this thread: > > http://thread.gmane.org/gmane.linux.kernel.input/29273 > > Testing would be appreciated. If things are working well overall, I'll get > these committed to the Fedora kernel. woot! works like a charm. Although, there's a weird thing where I set my Touchpad speed to the fastest (I like my Touchpad speeds fast! :) ), then I close the settings windows. When you close it the speed doesn't stay at the point where you set it to. It will always revert back to somewhere around middle range, I can see that once I reopen the "Touchpad settings".
Works perfectly on fedora 17 and Dell Latitude E6430. Thanks a lot! Looking forward to see the official update in fedora 17.
OK. I've committed the changes to all currently supported Fedora branches. Thanks to everyone for testing. They should show up with the next submitted update on the stable releases, and in rawhide tomorrow-ish.
(In reply to comment #103) > OK. I've committed the changes to all currently supported Fedora branches. > Thanks to everyone for testing. They should show up with the next submitted > update on the stable releases, and in rawhide tomorrow-ish. Yay no more custom kernels and now VirtualBox will work again!
I am extremely sorry to be the only dissenting voice but kernel-3.7.9-201.5.fc18 does not work on Dell Inspiron 7720 (17Rse). It is even a regression compared to the 3.7.7-201.5 fc18 kernel because now the Alps is not even recognized! I am left with the 'PS/2 Generic Mouse'. I shall ask the Sabayon developers what they did to get it recognized and working. Thanks anyway for the extra work you did Josh.
(In reply to comment #105) > I am extremely sorry to be the only dissenting voice but > kernel-3.7.9-201.5.fc18 does not work on Dell Inspiron 7720 (17Rse). > > It is even a regression compared to the 3.7.7-201.5 fc18 kernel because > now the Alps is not even recognized! I am left with the 'PS/2 Generic Mouse'. Then you have a "Dolphin V2" touchpad. That patch is a work in progress. It's the third patch in the thread I liked to in comment #95. It wasn't included because it's a WIP. I'll keep an eye on it and add it if/when it's confirmed to work.
I would appreciate that very much. Thanks.
kernel-3.7.9-205.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kernel-3.7.9-205.fc18
kernel-3.7.9-104.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/kernel-3.7.9-104.fc17
Just installed kernel-3.7.9-201.5.fc18.x86_64 on a Dell Latitude E5530 (w/Fedora 17), and it's working great - the touchpad is now recognized as AlpsPS/2. Thanks!
Now running kernel-3.7.9-201.fc18.x86_64 on Dell E6530 w/ proprietary nVidia drivers .. Sadly no different. Trackpad seen as generic mouse. Is the E6530 patch going to be ready for general release soon?
kernel-3.7.9-205.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Josh, thanks a lot, it works perfectly for my Dell Precision M4700 as well.
Just upgrade to 3.7.9-205.fc18.x86_64 on Dell Latitude E6430 Touchpad is correctly recognized and two finger scrolling works. $ xinput ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ DualPoint Stick id=13 [slave pointer (2)] Thanks for the fix!
kernel-3.7.9-205.fc18.x86_64 $ xinput ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Logitech USB-PS/2 Optical Mouse id=11 [slave pointer (2)] ⎜ ↳ DualPoint Stick id=14 [slave pointer (2)] ⎜ ↳ AlpsPS/2 ALPS DualPoint TouchPad id=15 [slave pointer (2)] NICE ! Thanks for all your efforts. I so missed scrolling :-)
Sorry .. addendum to above .. Dell Latitude E6530
Confirmed that it works on my Dell Latitude 6430. Thanks!
Upgraded to kernel-3.7.9-205.fc18.x86_64 on Dell Inspiron 17Rse (7720). I am sorry to report that this kernel makes NO difference. The Alps Glidepoint Touchpad still is not recognized and scrolling does not work. Again I would like to mention that it is possible to get this version of the Alps touchpad recognized and scrolling to work! I tried the recent Sabayon Linux Live CD (Sabayon_Linux_11_amd64_G.iso) and the Alps was recognized and scrolling worked perfectly. They are also using a 3.7.x kernel but I have not yet found out what patches they used. (Sabayon is a Gentoo derivative).
This kernel works fine on my Dell Latitude E6430. Thank you so much!! Now I'm a happy Fedora user again.
kernel-3.7.9-104.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Still broken on a Fujitsu Lifebook AH532 on Fedora 17 with: $ uname -r 3.7.9-104.fc17.x86_64 $ dmesg | grep alps [ 1.226464] psmouse serio1: alps: Unknown ALPS touchpad: E7=73 03 50, EC=73 02 02 I'm assuming that I have one of the Dolphin V2 pads with the WIP support that didn't make it. I don't have any experience in driver dev, but if I get around to playing with the code, is this the right bug for tracking progress?
Worked great with kernel-3.7.9-205.fc18.x86_64. However, after updating to kernel-3.8.1-201.fc18.x86_64 it doesn't work. dmesg | grep alps [ 1.471002] psmouse serio1: alps: Unknown ALPS touchpad: E7=73 03 50, EC=73 01 0d Dell inspiron N5110
Tested on 3.8.4-102.fc17.x86_64 on Dell Latitude E6330. The touchpad settings appear correctly in the GNOME control panel and two-finger scrolling works. Thank you for the fix.
Same issue as Kiko, Works on 3.7.9-205.fc18.x86_64 but not on 3.8.5-201.fc18.x86_64. dmesg |grep alps [ 1.534591] psmouse serio1: alps: Unknown ALPS touchpad: E7=73 03 50, EC=73 01 0d
For those of you having troubles with the 3.8 f18 kernels, can you try the scratch build below when it finishes and let us know if it works again: http://koji.fedoraproject.org/koji/taskinfo?taskID=5237496
Works for me! Thank you.
Works for me as well. Thanks Josh. On a side note, the kernel registers it twice. Id 14 is there when the touchpad is not detected correctly. Doesn't appear in 3.7.9-205, not sure if thats a problem. ⎜ ↳ AlpsPS/2 ALPS GlidePoint id=15 [slave pointer (2)] ⎜ ↳ PS/2 Mouse id=14 [slave pointer (2)] Output is from xinput.
Great, thanks for testing. Seems we had an patch regression in the 3.8 rebase. I'm reopening the bug and fixing it again. Bodhi will leave the usual comments when it is fixed in the repositories.
kernel-3.8.7-201.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kernel-3.8.7-201.fc18
Package kernel-3.8.7-201.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.8.7-201.fc18' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-5617/kernel-3.8.7-201.fc18 then log in and leave karma (feedback).
kernel-3.8.7-201.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Alps Glidepoint in Dell Inspiron 17Rse (7720) still not recognized. Only PS/2 Generic Mouse available!
Same on Dell Vostro 3360. Touchpad is not recognized. xinput: ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ PS/2 Generic Mouse id=12 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Power Button id=8 [slave keyboard (3)] ↳ Sleep Button id=9 [slave keyboard (3)] ↳ Laptop_Integrated_Webcam_HD id=10 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=11 [slave keyboard (3)] ↳ Dell WMI hotkeys id=13 [slave keyboard (3)] Kernel: 3.8.7-201.fc18.x86_64
For those of you that still don't have a working touchpad, it is likely because of the reason mentioned in comment #106. The support for that version of touchpad hasn't been included yet. If you want to open a new bug to track Dolphin V2 support, feel free.
FWIW, I'm running F19a and it appears the Touchpad is recognized correctly on my Dell E6430 running kernel 3.9.0-0.rc8.git0.2.fc19.x86_64
Is there any hope of a fix for RHEL 6, which is running 2.6.32-358?
Hello, Same problem on Fedora 19 on DELL XPS1530 : ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Broadcom Corp id=11 [slave pointer (2)] ⎜ ↳ PS/2 ALPS GlidePoint id=13 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Video Bus id=6 [slave keyboard (3)] ↳ Power Button id=7 [slave keyboard (3)] ↳ Sleep Button id=8 [slave keyboard (3)] ↳ Laptop Integrated Webcam id=9 [slave keyboard (3)] ↳ Broadcom Corp id=10 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)] ↳ Dell WMI hotkeys id=14 [slave keyboard (3)] - Kernel-3.9.4-300.fc19.x86_64 - synclient Couldn't find synaptics properties. No synaptics driver loaded? Thx
I have a similar problem on a laptop aer5542g Distribution: Fedora 19 KDE (86_ 64) Kernel Version: Linux Acer5542g 3.9.8-300.fc19.x86_64 # 1 SMP Thu Jun 27 19:24:23 UTC 2013 x86_64 x86_64 x86_64 GNU / Linux xinput without a mouse http://paste.fedoraproject.org/23025/37295375 ⎡ Virtual core pointer id = 2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id = 4 [slave pointer (2)] ⎜ ↳ AlpsPS / 2 ALPS GlidePoint id = 13 [slave pointer (2)] ⎜ ↳ PS / 2 Mouse id = 12 [slave pointer (2)] ⎣ Virtual core keyboard id = 3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id = 5 [slave keyboard (3)] ↳ Power Button id = 6 [slave keyboard (3)] ↳ Video Bus id = 7 [slave keyboard (3)] ↳ Power Button id = 8 [slave keyboard (3)] ↳ Sleep Button id = 9 [slave keyboard (3)] ↳ Video WebCam id = 10 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id = 11 [slave keyboard (3)] xinput with a mouse http://paste.fedoraproject.org/23024/37295371 ⎡ Virtual core pointer id = 2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id = 4 [slave pointer (2)] ⎜ ↳ AlpsPS / 2 ALPS GlidePoint id = 13 [slave pointer (2)] ⎜ ↳ Genius Optical Mouse id = 14 [slave pointer (2)] ⎜ ↳ PS / 2 Mouse id = 12 [slave pointer (2)] ⎣ Virtual core keyboard id = 3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id = 5 [slave keyboard (3)] ↳ Power Button id = 6 [slave keyboard (3)] ↳ Video Bus id = 7 [slave keyboard (3)] ↳ Power Button id = 8 [slave keyboard (3)] ↳ Sleep Button id = 9 [slave keyboard (3)] ↳ Video WebCam id = 10 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id = 11 [slave keyboard (3)] xinput without a mouse http://paste.fedoraproject.org/23025/37295375 ⎡ Virtual core pointer id = 2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id = 4 [slave pointer (2)] ⎜ ↳ AlpsPS / 2 ALPS GlidePoint id = 13 [slave pointer (2)] ⎜ ↳ PS / 2 Mouse id = 12 [slave pointer (2)] ⎣ Virtual core keyboard id = 3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id = 5 [slave keyboard (3)] ↳ Power Button id = 6 [slave keyboard (3)] ↳ Video Bus id = 7 [slave keyboard (3)] ↳ Power Button id = 8 [slave keyboard (3)] ↳ Sleep Button id = 9 [slave keyboard (3)] ↳ Video WebCam id = 10 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id = 11 [slave keyboard (3)]
(In reply to Josh Boyer from comment #95) > Here's a slightly updated F18 build for testing: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=5032773 > > Theoretically things should work better for those of you with 17Rse or N5110 > machines as I've pulled in the first two patches from this thread: > > http://thread.gmane.org/gmane.linux.kernel.input/29273 > > Testing would be appreciated. If things are working well overall, I'll get > these committed to the Fedora kernel. Scratched with this patches for F19 latest kernel: http://koji.fedoraproject.org/koji/taskinfo?taskID=5576711 Can anyone test this ? =)
(In reply to Igor Gnatenko from comment #139) > (In reply to Josh Boyer from comment #95) > > Here's a slightly updated F18 build for testing: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=5032773 > > > > Theoretically things should work better for those of you with 17Rse or N5110 > > machines as I've pulled in the first two patches from this thread: > > > > http://thread.gmane.org/gmane.linux.kernel.input/29273 > > > > Testing would be appreciated. If things are working well overall, I'll get > > these committed to the Fedora kernel. > Scratched with this patches for F19 latest kernel: > http://koji.fedoraproject.org/koji/taskinfo?taskID=5576711 > Can anyone test this ? =) I've installed this kernel http://koji.fedoraproject.org/koji/taskinfo?taskID=5576714 with no result on Dell Vostro 3360. Touchpad recognized as Generic PS/2 Mouse. It recognizes properly and works great with this psmouse module: http://www.dahetral.com/public-download/alps-psmouse-dlkm-for-3-2-and-3-5/view
> Scratched with this patches for F19 latest kernel: > http://koji.fedoraproject.org/koji/taskinfo?taskID=5576711 > Can anyone test this ? =) (Ended up building from the srpm) FWIW, I tried this on my Fujitsu Lifebook AH532 on F19 and it still doesn't work. $ uname -r ; dmesg | grep alps 3.9.9-302.rhbz812111.fc19.x86_64 [ 0.954797] psmouse serio1: alps: Unknown ALPS touchpad: E7=73 03 50, EC=73 02 02 I do notice that two-finger-scroll is detected as something other than normal finger movement, because the system knows enough not to move the mouse pointer normally. It moves normally with one finger, but with two fingers, it just sits there.