Messages in this thread | | | Subject | Re: PATCH - ALPS glidepoint/dualpoint driver for 2.5.7x | From | Felipe Alfaro Solana <> | Date | 27 Jun 2003 09:41:28 +0200 |
| |
On Fri, 2003-06-27 at 04:38, Neil Brown wrote: > Hi, > The following adds support for the ALPS glidepoint/dualpoint pointing > devices to the mouse driver in 2.5.7x > > It "works-for-me" but there are issues that probably need to be > addressed. > > 1/ The code is based on other code fragments I have collected off the > internet. I have found no documentation and the one request I made to > ALPS has so-far been unanswered. So I cannot be sure it is right, > but as I say it seems to work. > > 2/ It appears (but see 1) that it is not possible to reliably detect > an ALPS device. There is a sequence where you send 3 SetRes2:1 > commands, and then a GetStatus command and you get something which > isn't really a status, but I don't know what range of status > values mean "ALPS". I tried checking for "any status which must > be wrong" i.e. any status that say the device is in 1:1 mode, or > is enabled etc. But a Logitech mouse seem to respond > interestingly to that sequence too. > > Also, there is no guarantee that the reply will come from the ALPS > device. For example, on my Dell Latitude D800, if I have a > logitech mouse plugged in the expansion port, the GetStatus reply > comes from the logitech and not the ALPS. So it would seem that > reliable detection is impossible. > > So the current code always sends the ALPS set-absolute-mode > sequence (4 disables before the enable) unless a > non-3-byte-protocol device was detected. > > There are two consequences of always assuming an ALPS that may not > be good. > 1) The mouse always claims to generate various ABS events even > when there might not be any ABS-generating device behind the > mouse. > 2) The driver could misinterpret a normal mouse event that > overflowed in the negative direction for both X and Y as part > of an ALPS absolute event. This is because ALPS absolute > events are detected by checking if the top 5 bits of the first > byte are all one. I doubt this is a real problem as double > overflows are very unlikely (aren't they?) > > 3/ I haven't set the Min and Max absolute values (though both X and > Y seem to range from 0 to 100 in practice on my notebook). > This was because declaring a Min and Max causes the mousedev > driver to scale values to fit a supposed screen size, and I don't > think that is really appropriate for a touchpad. Would there be > some other way to decide when to scale? I would like to be able > to include Min and Max so that a post-processor (possibly in > mousedev) would be able to differentiate edge based activity > (scroll regions, corner taps, etc). > > > This patch also includes a fix for mousedev_event that allows it to > work sensibly with a touchpad in absolute mode. With a touchpad, if > you lift your finger and place it down again you don't want that to > be interpreted as movement, but mousedev_event currently will. > I have changed it so that if ABS_PRESSURE is an available event, > then a new ABS_{X,Y} event while the current ABS_PRESSURE is zero > will not generate any movement.
Is there any trick to force enabling ALPS support? I'm using a NEC Chrom@ laptop with an ALPS GlidePoint touchpad, 2.5.73-mm1 and your patch, but I can't seem to get the enhanced functionality of my touchpad, like using the edges of the touchpad to simulate the wheel or else. It seems to behave like a normal PS/2 mouse.
Also, on dmesg, I can't see any reference to an ALPS input device being detected. Any ideas?
Thanks!
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |