| Summary: | Alps Touchpad Stops Working in Kernel 2.6.12-rc5 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Matt T. Proud <khanreaper> |
| Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | RESOLVED TEST-REQUEST | ||
| Severity: | major | CC: | gad.kadosh, steev |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Matt T. Proud
2005-05-30 01:54:45 UTC
So for using the touchpad, /dev/psaux works but buttons are dead and /dev/input/mice does not work at all? have you tried individual ones like /dev/input/mouse0, /dev/input/mouse1, etc? Correction: The mouse does not function at all, so it is not the case of that
other bug that I referenced in this report, in which only the buttons stopped
working.
Due to the way odd way that this Dell's bios was designed, it passes events from
the touchpad, if I remember correctly, only to /dev/psaux. With events from USB,
however, they get sent to /dev/input/mice and the bios has routed them in a
duplicate manner through /dev/psaux at times. I am sure that much of this
probably sounds a bit odd, but I can assure you that this method has worked very
well for the past few years.
Earlier, I did try to access /dev/input/mouse{0,1,2}, but that effort appeared
fruitless.
I should have also mentioned that I compiled in mouse support to the kernel not
as a module but in a monolithic fashion when I reported the bug. Last night,
after reporting this bug, I reconfigured my kernel and compiled in these drivers
as modules. Today, when I booted my machine and loaded psmouse, things actually
to be working a bit better, but I am personally unconvinced that simply loading
the driver as a module fixes the problem, just because of the longstanding good
behavior of the past.
When you try it as modules, is the touchpad being used as a generic "PS/2 Mouse" or the ALPS GlidePoint? I'm sure you could get everything as you have always used it if the kernel uses the generic driver. This can be achieved by passing the kernel parameter psmouse.proto=exps at boot time. However, hopefully we can figgure out what the ALPS is doing wrong as you are by far not the only person who will have issues when 2.6.12 comes out. If I load the driver as a module, I still get the same dmesg output as before, though I do access the device through GPM and X.Org as a standard PS/2 device. In short, the kernel still recognizes it as two types. Is this "psmouse.proto=exps" something that one attempts to set with sysctl, because if it is, sysctl reports this as an unknown type and nothing results from its being set. (In reply to comment #4) > If I load the driver as a module, I still get the same dmesg output as before, > though I do access the device through GPM and X.Org as a standard PS/2 device. > In short, the kernel still recognizes it as two types. For both the Alps driver and the generic PS2 driver, user space apps can use PS/2 or IMPS/2 for the protocol type. > > Is this "psmouse.proto=exps" something that one attempts to set with sysctl, > because if it is, sysctl reports this as an unknown type and nothing results > from its being set. This is a boot option for the kernel, just append it to the other parameters you have in your boot loader. So, what sort of device is this anyway? Is it just a touchpad? or is it both a touchpad and a stick? I have not been able to find any major issues with the Alps touch pad on my Dell inspiron 8500 but just as a refrence, starting with the Alps driver in 2.6.12 seeing two mouse devices is normal if you have both a keyboard stick mouse and a touchpad as my laptop does. This is what my /proc/bus/input/devices looks like, almost identical to yours minus the eventX handlers: I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 H: Handlers=kbd mouse0 B: EV=120017 B: KEY=40000 4 2000000 3802078 f840d001 b2ffffdf ffefffff ffffffff fffffffe B: REL=140 B: MSC=10 B: LED=7 I: Bus=0011 Vendor=0002 Product=0008 Version=0000 N: Name="PS/2 Mouse" P: Phys=isa0060/serio1/input1 H: Handlers=mouse1 B: EV=7 B: KEY=70000 0 0 0 0 0 0 0 0 B: REL=3 I: Bus=0011 Vendor=0002 Product=0008 Version=6337 N: Name="AlpsPS/2 ALPS GlidePoint" P: Phys=isa0060/serio1/input0 H: Handlers=mouse2 B: EV=f B: KEY=420 0 70000 0 0 0 0 0 0 0 0 B: REL=3 B: ABS=1000003 so here /dev/input/mouse1 is the stick, /dev/input/mouse2 is the touchpad. /dev/input/mice will show both as it should. I have no idea why the keboard has /dev/input/mouse0, it doesn't do anything from what I can tell. I don't know if that info helps any, but just so you know the two devices showing up isn't a bad thing. On your machine, can you get some output when you cat /dev/input/mouse1 or /dev/input/mouse2? I checked it myself, so the 8200 is indeed a dual poing (both touchpad and stick). Matt, could you please respond with what the various /dev/input/ mouse devices will respond to? Thanks. (just using cat to check which will spew out garbage will work) I also have a problem with my ALPS touchpad since gentoo-sources-2.6.12. Xorg doesn't load anymore. The error in xorg log is: (EE) Touchpad no synaptics touchpad detected and no repeater device (EE) Touchpad Unable to query/initialize Synaptics hardware. (EE) PreInit failed for input device "Touchpad" I'm using in xorg.conf the /dev/input/event1 device. It was working for as long as I can remember. In dmesg I still had the touchpad detected by the kernel as ALPS though. Please post /proc/bus/input/* , dmesg output, and try modifying your X config so that it reads like the sample one on the synaptics website, and post your X config It appears 2.6.12 has changed the /dev/input/event* ordering or something, so now my touchpad is event2 instead of event1. Changing that in xorg.conf fixed the problem. I think if you use auto-dev as suggested on the synaptics website then you won't see this problem in future With regard to the statement, """I think if you use auto-dev as suggested on the synaptics website then you won't see this problem in future[,]""" where is this document of which you speak? Could you provide a reference to it? Synaptics homepage: http://web.telia.com/~u89404340/touchpad/ The sample X config which suggests auto-dev: http://web.telia.com/~u89404340/touchpad/xorg.conf The point is that I don't have psaux on my system (don't know why...) and I use eventX for the touchpad. The problem was that prior to 2.6.12 the touchpad was /dev/input/event1, and since 2.6.12 it became /dev/input/event2. Once I changed the config to reflect that it works again. I suppose udev could be configured to work that out better. Actually since 2.6.12 event1 became "PS/2 Mouse", which is not attached but maybe it's the touchpad too. event2 is now: "AlpsPS/2 ALPS GlidePoint". Yes, psaux has been going/gone for a while (replaced with /dev/input/mice) However I believe if you use auto-dev like suggested in the sample config, it will automatically use the correct event node without you having to specify it. I can't say for sure as I don't have this hardware myself. Here's some logs I found on some mailing list archives: (II) Synaptics touchpad driver version 0.13.3 (--) Synaptics Mouse auto-dev sets device to /dev/input/event1 (**) Option "Device" "/dev/input/event1" (**) Option "SHMConfig" "on" (**) Option "LeftEdge" "1700" (**) Option "RightEdge" "5300" (**) Option "TopEdge" "1700" (**) Option "BottomEdge" "4200" (**) Option "FingerLow" "25" (**) Option "FingerHigh" "30" (**) Option "MaxTapTime" "180" (**) Option "MaxTapMove" "220" (**) Option "VertScrollDelta" "100" (--) Synaptics Mouse synaptics touchpad found The user had chosen /dev/psaux in the config but the driver automatically chose to use /dev/input/event1 instead So your saying that I can set device to /dev/input/mice ? (I don't have psaux) You can set it to /dev/whateveryouwant It won't be used at all if you use auto-dev. It is only there for fallback reasons (the 2.4 driver doesn't support auto-dev, so the manual Device setting is only used as a fallback) I will try to see if it works also if I don't set at all the Device line. Thanks a lot ! (I think that's not generally related to this bug, right ?) Matt, are you still having problems even with 2.6.12 final? As a side note there does indeed seem to be something screwing going on. On vanilla 2.6.12 my laptop works perfectly, but using brix' ebuild for suspend2-sources the stick and it's buttons stops working (the piece that shows up as a generic PS/2 Mouse), the touchpad works perfectly in both cases. I'll investigate this further soon to see if the problem is only with suspend2 or if it can be made to show up elsewhere. Closing this bug since Matt never responded if this is still a problem in the 2.6.12 final release. |
