Description of problem: This bug report concerns centos 5, I am unable to test on a RHEL5 machine at this time but it will most likely also apply. I have filed a bug for centos and was asked to report it here: http://bugs.centos.org/view.php?id=4192 . Using a fully up to date centos 5 x86_64 on a Dell Lattitude E6400, the touchpad is not detected as a synaptics/ALPS device. As a result, it can work as a regular mouse but the nice capabilities of the synaptics touchpad driver are not available (eg scrolling). I've tracked this down to a problem in drivers/input/mouse/alps.c , which doesn't know the signature of the newer Dell touchpad. The attached trivial patch solves the issue. I have tested by rebuilding the latest C5 kernel (kernel-2.6.18-164.11.1.el5.x86_64) with this patch applied via the SPEC file. The patch comes from: http://lkml.org/lkml/2008/9/7/133 [^] (solution for E6400 and E6500) http://lkml.org/lkml/2007/8/4/41 [^] (solves same problem for Vostro 1400) Version-Release number of selected component (if applicable): kernel-2.6.18-164.11.1.el5.x86_64 How reproducible: Always. Steps to Reproduce: 1. Install centos 5 x86_64 on a Dell Lattitude E6400, apply all updates. 2. Install synaptics. 3. Configure the touchpad using synaptics driver in xorg.conf, restart X. Actual results: Advanced synaptics capabilities don't work (in fact X would not start for me, I had to revert the xorg.conf changes to start it). Expected results: Advanced touchpad stuff (such as scrolling using the edge of the pad) should work. Additional info:
Created attachment 390458 [details] patch that solves the issue looks like I forgot to attach the patch last night, here it is.
As suggested on the centos bug tracker, I have tested the RHEL5.5 beta kernel kernel-2.6.18-186.el5.x86_64 , obtained here: http://people.redhat.com/jwilson/el5/186.el5/x86_64/ The problem is still present in that kernel.
Anyone wishing to test the kernel with the patch provided by Nicolas can download it from: http://centos.toracat.org/kernel/centos5/bug4139plus/ Be sure to get the one named "kernel-2.6.18-164.11.1.el5.bug4139.4192.ayplus"
Bug definitely affects RHEL 5.4 and RHEL 5.5 beta 1. Also impacts other models in the Dell Latitude E-series, including the E6500. Since the Dell Latitude E-series is, IMO, an extremely common hardware platform for enterprises who tend to run RHEL, could the priority of this bug perhaps be increased to medium? Will this be fixed in RHEL 5.5 final?
This patch is now in the official centosplus kernel (kernel-2.6.18-164.15.1.el5.centos.plus). People with affected hardware can now test with this kernel.
Akemi, in case your last comment was directed to me, I am a RHEL user, not a CentOS user. So this will only benefit me if this is fixed in the RHEL kernel.
I now see this bug's flag for target milestone: rc. If this is correct then please ignore my earlier comments about increasing priority.
David, my note is not for anyone particular. I am offering it for RHEL (or CentOS) users who just want to test to see if the patch fixes their problem. The goal is to get the patch in the RHEL kernel, of course. Nothing else. :)
Just an FYI for RH kernel team - ALPS signature 0x62, 0x02, 0x14 requires ALPS_INTERLEAVED option so there some additional backporting needed.
Created attachment 463740 [details] Add support for Dell DualPoint touchpads Backports the ALPS_INTERLEAVE code to RHEL5 and add the new ALPS ID's. Please test if this patch properly fixes the issue.
I will test the new patch in the next centos plus kernel when it gets updated. However since the previous patched kernel worked for me and I never noticed anything wrong with it, I will only be able to assess whether the new patch causes a regression for me compared to the old one. I guess the new patch with the ALPS_PS2_INTERLEAVED stuff solves some issues that don't occur in my typical usage (which is admittedly limited, I mainly use this laptop for conferences or lectures).
Nicolas (and anyone with the affected hardware), I rebuilt the cplus kernel using the patch in Comment 10. Please test if you can. http://centos.toracat.org/kernel/centos5/bz564086/
I just tested the x86_64 kernel built by Akemi: http://centos.toracat.org/kernel/centos5/bz564086/ [^] It works for me as before. Furthermore, I played around with the old patched version and managed to break it by using the touchpad and trackpoint simultaneously. I never use the trackpoint so I had probably not triggered the problem before. The kernel logged some error messages such as: psmouse.c: DualPoint TouchPad at isa0060/serio1/input0 lost sync at byte [some number] and then scrolling no longer worked. I tried reproducing this breakage with the new patched kernel but could not. So, the new patch seems all good! Thank you.
Thanks, Nicolas for the good news. Thanks, Mauro, for the patch.
Just checked the RHEL 5.6 beta kernel 2.6.18-229 and confirmed that it does not have the patch. Is it too late to get it included?
I don't understand why this bug report has been closed as "WONTFIX". The patch that fixes the problem was offered in Comment 10. We tested it, and it was proven to work. So, why isn't this patch applied to RHEL ? Why WONTFIX?
(In reply to comment #17) > I don't understand why this bug report has been closed as "WONTFIX". > > The patch that fixes the problem was offered in Comment 10. We tested it, and > it was proven to work. So, why isn't this patch applied to RHEL ? Why WONTFIX? I assume that the patch has missed the cut off point for inclusion into 5.6 and should, therefore be included into 5.7 However, it appears that the issue has been muddled by a junior (who has been given a position of triaging bugs) and the wrong option was selected. Unfortunately this sort of occurrence seems to becoming more prevalent within Red Hat . . .
Continuing on from Comment 18. If one looks at the official Red Hat definition of the resolution "WONTFIX" we see -- "WONTFIX The problem described is a bug which will never be fixed. An example of why this might be true is due to significant divergence from upstream.. An explaination (sic) of why this resolution has been chosen should be supplied." This clearly is _not_the_case_ here and, _most_importantly_, the closer of this bug has failed to provide an explanation of why that resolution was chosen.
Akemi/Alan, This is a friendly reminder that Red Hat Bugzilla is not a support tool. If you wish to receive support for bugs such as this, please contact Red Hat support (www.redhat.com/support) and work with us via those support channels to ensure that bugs and patches such as this get included in a future release of Red Hat Enterprise Linux (RHEL). RHEL is a customer driven product, and for that to happen we need to hear directly from our customers via the proper support channels. Thank You Jeremy West Red Hat Support Supervisor
(In reply to comment #19) > Continuing on from Comment 18. > > If one looks at the official Red Hat definition of the resolution "WONTFIX" we > see -- > > "WONTFIX > The problem described is a bug which will never be fixed. An example of why > this might be true is due to significant divergence from upstream.. An > explaination (sic) of why this resolution has been chosen should be supplied." > > This clearly is _not_the_case_ here and, _most_importantly_, the closer of this > bug has failed to provide an explanation of why that resolution was chosen. You make a very good point. I apologize for this. We have closed this bug WONTFIX in order to prioritize more urgent bugs being reported by our customer base. Again, per comment #20, if you would like to see this bug fixed, please contact Red Hat Support and we'll make sure this gets handled appropriately. Jeremy West
I am fully aware that Red Hat Bugzilla is not a support tool. I was not looking for support. I don't even have the hardware this bug was reported for. I thought that, by testing proposed patch(es), I was helping make RHEL a better product. But then, if/when a customer with the affected hardware submits a help request, you now have a solution that is confirmed to work. So, hopefully the time and effort spent in this bugzilla report is not totally wasted.
Thanks for understanding Akemi, I assure you that the work on this bug has not been wasted. If we have a customer request for this hardware, this bug will be reopened and prioritized appropriately. Jeremy West