Clicking the touchpad used to work on kernel versions prior to 2.6.11-gentoo-r2, for example now I reverted to 2.6.10-gentoo-r7 and it works Reproducible: Always Steps to Reproduce: 1. 2. 3.
It used to work previously, I reverted to 2.6.10-gentoo-r7 and it works
So using 2.6.11 you can't click at all? Actually pressing the "click" button, and tapping the touchpad, does not result in any clicks happening?
I faced the same problem (I assume Tudor is only talking about tapping). This is most probably caused by the new ALPS touchpad support. It disables tapping (in order to let eg the synaptics driver take care of that). From what I have read I gather that this behaviour is likely to change in 2.6.12, as it seems not to work with ALPS touchpads. There is a patch available (posted somewhere on the LKML) that reenables hardware tapping. That works fine for me (together with the synaptics xorg driver).
The tapping doesn't work any more, sorry for the confusion
Created attachment 53086 [details, diff] Alps button fix oh, gee, Sorry guys for not posting this earlier. I made a patch the other day that should fix this problem in 2.6.11 (dsd: probably should go in g-d-s?). The patch is only a temporary fix as the ALPS driver was reworked (new driver can be found in the mm tree). So untill 2.6.12 comes out, use the attached patch. :-)
Did this patch indeed fix the problem for you?
I had to do some dependency analysis for some advanced compilers class so I had absolutely no time to try on the patch, and due to the cold cold Ithaca and my stupidity (I started the laptop as soon as I got home after I left it in the car for 2 hours) I had to send it to Sony Support :(. I'll have to wait for it to return before I try the patch.
Markus: Can you please point us to the patch that you are using?
Sorry, my patch doesn't actually fix the tapping problem that is the subject of this bug (but does fix a different button problem). As for this bug, an alternative to what Markus did would be to disable the Alps driver compleetly and use a default driver as kernels previous to 2.6.11 did. This can be accomplished by passing the kernel the following option: psmouse.proto=exps
The patches can be found here: http://web.telia.com/~u89404340/patches/touchpad/2.6.11/ (see also http://web.telia.com/~u89404340/touchpad/index.html) The problem is already fixed by the very first patch (p00001_alps-hwtaps). However, the other patches seem not to hurt either. There is also a short discussion at http://lkml.org/lkml/2005/2/24/295
Fixed in gentoo-dev-sources-2.6.11-r4
*** Bug 85775 has been marked as a duplicate of this bug. ***
Reopening as of Bug 85775 Markus, can you confirm that tapping in gentoo-dev-sources-2.6.11-r4 does or does not work for you? Stuart, can you try the other patches from http://web.telia.com/~u89404340/patches/touchpad/2.6.11/ and see if they fix your problem? (the first one is already present in 2.6.11-r4)
Well, for me 2.6.11-r4 works fine. There are differences to prior behaviour though (e.g. dragging on the fb console seems not to work, and behaves a little strange in X as well). But both tapping and double-tapping _do_ work as expected. (And as mentioned, they did _not_ work in 2.6.11 prior to -r4) Stuart, what does your kernel say about "Enabling hardware tapping"? Maybe it is unsuccessful for some reason? If everything else fails, one can still use the "old" ps2 interface by giving the kernel parameter "psmouse.proto=exps".
*** Bug 85932 has been marked as a duplicate of this bug. ***
Um... reading bug 85932 I wonder whether people reporting problems actually also switched to the synaptics X11 driver. If you do not use the synaptics driver but continue to use the "mouse" driver instead, you will probably have to stick to "psmouse.proto=exps" (I suppose; I will try this next).
No, using the "mouse" driver also works for me. Must be a problem I cannot reproduce.
I'm using an AlpsPS/2 ALPS TouchPad (Dualpoint, E6 report: 00 00 64, E7 report: 63 03 c8) with the synaptics-0.14.1 X driver. Without genpatches-2.6-11.04/2900_alps-tapping.patch, tapping and double tapping worked, tap-move (select or drag) worked, but tap-tap-move (select words) didn't. After the patch, tapping didn't work but double tapping did, tap-move only worked sometimes, and tap-tap-move worked. The tapping was restored by increasing the synaptics driver parameter maxtaptime from 120 to 180. The problem with tap-move appears to be related to whether the second touch is in precisely the same place as the first touch. Increasing maxtapmove from 30 to 110, made the response much more reliable although care still needs to be taken to ensure that the two touches occur at the same place on the pad. Both these new parameters are actually the recommended numbers from README.alps.gz from the synaptics package. The former parameters just seemed to work a little better with the versions prior to 2.6.11-gentoo-r4. Moving the track stick works before and after the patch. Tapping the stick doesn't do anything. I don't know if it is meant to and I think its probably good that it doesn't because I don't use it and I don't want to bump it while typing.
Right. Can people please try 2.6.12-rc1. If the problems are solved there then I will attempt to backport the changes.
I tried the 2.6.11-gentoo-r4, and my touchpad goes bazark, it "clicks" at random and the precision is poor (for the 2.6.10-gentoo-r7 it used to work with the same paramenters extremly well).
I've not had chance to test 2.6.12 yet (this week, hopefully...) but I have noticed something else odd which might help to pin down the console problem: If I apply the Bluetooth-HID patches (to allow Bluetooth mice to work correctly) from http://www.holtmann.org/linux/kernel/patch-2.6.10-mh2.gz, then the previously-working 2.6.10 kernel *also* exhibits the strange gpm/console-mouse-not-working behavior... Presumably one of the common changes between the patch to 2.6.11 and the bluetooth patches is causing the problem.
I've encountered problems with an Alps touchpad and kernel 2.6.11-gentoo-r5 using the standard psmouse driver, too. Tapping on the touchpad produces a double-click, not a single-click. I've also noticed that the cursor moves noticeably slower. The latter also effects the mouse attached on the usb port. I've always been content with the default behaviour, so I never tried the synaptics driver. However, as mentioned the kernel parameter "psmouse.proto=exps" restores the old behaviour. I assume this to be only a temporary fix. I'm wondering how to deal with this issue in future releases.
Please see comment #20. By the way, 2.6.12-rc2 is out now.
I admit, I've not tried 2.6.12 yet - I'll give that a shot now. Just to add more, though, I've tried using 2.6.11 with the "psmouse.proto=exps" parameter: The mouse speed and sensitivity is restored - good. However, tapping to click in the console is still broken, and selecting text on the console is still broken that it appears to detect the mouse button being released when it isn't... this feels as if it's related to the speed at which the cursor has been moved.
Still waiting for someone to test 2.6.12-rc2, pretty please. If this is an issue there then we need to get it reported upstream so that it is fixed before 2.6.12 is released as final.
Okay - I've briefly tested 2.6.12-rc2 ... and it's almost there: Even without using the psmouse.proto=exps argument, the tracking speed is fixed and you can select areas of text on the VT at any speed, and it doesn't forget the you're holding the button down. But there are a couple of things that are better, but not quite right: The first of these may actually be a video driver issue, rather than input: I noticed that if I typed to the console fast - being sure not to touch the touchpad at all - the mouse cursor would sometimes flash briefly. For example, typing "dmesg " would cause the cursor to flash once in the centre of the screen alsmost every time I hit the spacebar. Not a problem as such, but distracting once you notice it... This is not something I've seen prior to 2.6.12. Secondly, it is still occasionally detecting clicks during movement: If I move the cursor around the screen, then it occasionally selects the character beneath it in mid-movement. I've never had this happen on kernels prior to 2.6.11, so I assume it's something in the kernel that needs tuning a little further, rather than me being heavy-handed. In all, much better - but still in need of a few last tweaks. NB: I didn't test with X, so this is purely the behavior from a Radeon-driven FB VT.
Ok, progress! Please can you file a bug at http://bugzilla.kernel.org for the problem you experience in 2.6.12-rc2. Note that there is already bug 4281 there, you might consider just adding to that one instead. Please post the URL to the bug that you open/report on here so that I can keep an eye on it.
Above entry posted to Kernel Bugzilla Bug 4281.
*** Bug 89029 has been marked as a duplicate of this bug. ***
If anyone has the time, it would be worth testing 2.6.12_rc4 and updating http://bugzilla.kernel.org/show_bug.cgi?id=4281 with any progress.
Tested -rc4, updated Kernerl Bug Tracker. Nothing seems to have changed, which is disappointing :(
You could try this patch: http://lkml.org/lkml/2005/5/17/13
Bump..please try applying the above patch to a recent 2.6.12-rc release.
Also please re-read http://bugzilla.kernel.org/show_bug.cgi?id=4281 Looks like it might be fixed in 2.6.12_rc5 .. ?
Closing due to no response. It looks like this is fixed in 2.6.12.
Bug 85932 was made a duplicate of this bug. It's the trackpoint not working on my dell inspiron 8500 with an alps dualpoint device. This is still not fixed in 2.6.12. It's also intermittent (was before too) if i reboot a few times, sometimes the trackpoint will initialize, other times it will not. Perhaps my bug should be re-opened standalone since it doesn't seem to be the same problem.
(In reply to comment #37) > Bug 85932 was made a duplicate of this bug. It's the trackpoint not working on > my dell inspiron 8500 with an alps dualpoint device. This is still not fixed in > 2.6.12. It's also intermittent (was before too) if i reboot a few times, > sometimes the trackpoint will initialize, other times it will not. Perhaps my > bug should be re-opened standalone since it doesn't seem to be the same problem. How about I just a big "Alps is being rude" tracker bug, and make it depend on bugs for each seperate issue. That should help keep track of the individual issues.
Patch mentioned in Comment #33 is present in 2.6.12, but Alps touchpads seem to be as broken as ever... The suggestion from Kernel Bug 4281 is to revert alps.c to the 2.6.11 version, which I'll have a go at now and report back.
Nope - even with the suggested alps.c from 2.6.11, the problem is still there: Even with "psmouse.proto=exps2" specified in the Kernel command-line, the ALPS touchpad is broken in the console with gpm. To re-iterate, simply moving the mouse around the screen can generate a click event. When holding down a hardware button to select text, a release event will always occur, so often few lines of text can be selected Another strange occurance (that I've not managed to reproduce yet) happened when trying to select text on another console - the start-point of the selection was fixed at the point where it had been on the first console. In X things generally seem to work, but there's been at least 5 of cases of either a click (from a hardware button) or a drag (using tapping) suddenly being released while I'm still holding the button or pad, or when additional click events have occured without me touching anything. These are much less frequent, but have happened frequently enough that I'm sure it's not just me. In all, the new Alps driver seems to be significantly broken - *please* could we revert to the 2.6.10 driver? I've not been able to use 2.6.11 or 2.6.12 on my laptop because of these problems... which it a pretty high price to pay when the driver changes were in the name of enhanced functionality :( Please re-open this bug.
*** Bug 105007 has been marked as a duplicate of this bug. ***
Reopening, still an issue. :/
(In reply to bug #105007 comment #0) > ... following on from Bug 84657 (which is marked RESOLVED) > > I've just installed Linux 2.6.13-gentoo, and the ALPS touchpad problem is still > evident. > > To recap, this is kernel.org Bug 4281: > > * In a text-mode console, the touchpad randomly taps during movement and is > incapable of selecting large areas of text (I run a 1400x1050 text-console, and > after selecting over about 1/3 of this strange selection behavior occurs) If possible, please explain this strange selection behaviour in a bit more detail. > * In a text-mode console, moving the cursor around the screen leaves > single-character artifacts where a character is left in reverse-video (as if the > cursor was still positioned over it) after the cursor has moved on. > * In X using any of the *PS/2 drivers, dragging and tapping don't work, and the > mouse randomly clicks during movement. > > This is when the kernel is started with "psmouse.proto=ps2" - IIRC, without this > the trackpad doesn't work. Please confirm this. > I know that the synaptics driver for X is available - but this only solves the > problems in X and is very difficult to configure correctly. Plus, I don't think > I should need a third-party driver to get something as simple as a PS/2 pointing > device to work reliably. > > Could Gentoo developers put pressure on kernel developers to let them know that > this driver has now been broken for 3 kernel versions? Infact, a patch to > revert the ALPS driver to its state as of 2.6.10 would be brilliant!
> > This is when the kernel is started with "psmouse.proto=ps2" - IIRC, without > > this the trackpad doesn't work. > > Please confirm this. > Okay - with an older kernel (2.6.11?) this setting was suggested to allow the ALPS device to work properly. Now, on 2.6.13 this setting makes no difference at all, whether the value is not present, "bare", or "exps". This factor can now be discounted.
> > * In a text-mode console, the touchpad randomly taps during movement and is > > incapable of selecting large areas of text (I run a 1400x1050 text-console, > > and after selecting over about 1/3 of this strange selection behavior occurs) > > If possible, please explain this strange selection behaviour in a bit more > detail. > 1400x1050 gives a 175x65 console. Just moving the mouse around the console (via gpm) in 2.6.11+ causes the mouse to apparently randomly detect taps, and so it will highlight the single character currently highlighted. Strangely, this seems to happen at multiples of semi-regular intervals... This may be related to the problem of selecting text - even when holding down one of the hardware mouse-buttons (so there's no chance of accidentally clicking off) the held mouse button seems to release after a short time. Infact, it seems to depend both on time and on number of characters selected. For example, if you try to copy a few lines of text by starting at the top-left of the paragraph and dragging diagonally down and right, then after about 2.5 lines of text, the mouse will click-off and not select any more (although at this point phantom clicks are then often detected which will de-select the selected region). Performing the same operation again soon afterwards will often result in the mouse clicking off again in exactly the same place - so this seems somewhat deterministic. However, by keeping the mouse at the left of the screen and only moving downwards, much more text can be highlighted before the inevitable click-off occurs. To confirm, this hardware (still!) works perfectly in 2.6.10 - something was badly broken in 2.6.11, and has been broken ever since. This means that I'm *still* using 2.6.10-gentoo-r6 on my laptop, simple because the trackpad *does not work reliably* for any later kernel. This is a terrible state of affairs, and I'm willing to do whatever I can to help to get the problem fixed.
Ok, and how is gpm interfacing with the mouse? Using /dev/input/mice or the event interface?
Also, 2.6.14-rc1 includes one change related to processing of packets from the ALPS devices. It would be worth you doing some more testing under vanilla-sources-2.6.14_rc1 when you have time.
(In reply to comment #46) > Ok, and how is gpm interfacing with the mouse? Using /dev/input/mice or the > event interface? I've tried both, and the results are as follows: 2.6.10-gentoo-r6 - mice: Works evdev: With default settings, the acceleration is too high (the cursor tends to rocket around the screen), but otherwise works fine. 2.6.12-gentoo-r10 - 2.6.13-gentoo-r1 - 2.6.14-rc1 - mice: Selection problems as described previously (see msg 45) evdev: When the touchpad is interacted with, the cursor does appear - so events are being passed to gpm which is responding to them. However, the cursor *never* moves - it remains stuck in the dead centre of the screen. This is on exactly the same machine with exactly the same gpm - all that has changed is a reboot to the new kernel, and that 2.6.10-gentoo-r6 uses /dev/input/event1 for the ALPS pad (event2 doesn't exist) and the other kernels use /dev/input/event2 (which, when watched with hexcat, is the device where mouse events arrive - neither event0 nor event1 show any reaction when the pad is used on these other kernels). This *may* be a gpm issue (although it *does* work on 2.6.10 and using /dev/input/mice on all kernels - to a degree), but to me it does look like another symptom of the ALPS breakage in recent kernels.
(In reply to comment #47) > Also, 2.6.14-rc1 includes one change related to processing of packets from the > ALPS devices. It would be worth you doing some more testing under > vanilla-sources-2.6.14_rc1 when you have time. Nope - I'm afraid I could see no ALPS-related differences between 2.6.12-gentoo-r10, 2.6.13-gentoo-r1, and 2.6.14-rc1 :( P.S. I should have mentioned in my previous reply that 2.6.10-gentoo-r6 is also the last kernel where hardware tapping works. On all later kernels, even using /dev/input/mice, clicking is only possible using the hardware buttons, not by tapping on the pad. Is reverting the ALPS input driver in later kernels to its 2.6.10 state in any way a viable proposition, or has so much changed in the input layer between then and now that it just wouldn't be practical?
It is not a viable proposition and is not the correct solution. Developers have worked hard to introduce extra functionality by converting ALPS into its own driver and many users have benefitted from this. Reverting out their work is going in the wrong direction. The only way forward is getting the info required to fixing it and giving that to the developers. Please stop suggesting reverting it, as this has a slightly negative tone to it, and you are supposed to be motivating people to fix this :) I will send some emails out now. Thanks for the info you have provided so far.
Sorry Stuart, one more thing I'd like to check myself before sending the mail. Could you please attach /proc/bus/input/devices from 2.6.14-rc1, one version when you haven't booted with any extra args, and one where you have booted with "psmouse.proto=exps" Thanks.
While we're at it, a captured "dmesg" output from a boot where you have "psmouse.proto=exps" may also be useful.
(In reply to comment #50) > Reverting out their work is going in the wrong direction. The only way forward > is getting the info required to fixing it and giving that to the developers. > Please stop suggesting reverting it, as this has a slightly negative tone to it, > and you are supposed to be motivating people to fix this :) I'm sorry - I didn't mean to suggest this in a negative way, more I was thinking that "Use old ALPS driver" and "Use new ALPS driver" could be kernel configuration options and then those people having problems with the new driver would be able to use their devices still until the problems are resolved. I'm certainly not trying to diminish the efforts of everyone trying to enhance drivers - but at the same time from a user's perspective it's incredibly fruistrating to keep trying new kernel versions only for the same problems to be present, when the original seemed to work just fine! Of course, once we can get this fixed I'll be over the moon ;)
Created attachment 68521 [details] 2.6.14-rc1 dmesg output
Created attachment 68522 [details] 2.6.14-rc1 dmesg output with psmouse_max_proto option
(In reply to comment #52) > While we're at it, a captured "dmesg" output from a boot where you have > "psmouse.proto=exps" may also be useful. It seems that the kernel option (but not the documentation, natch) has changed from "psmouse.proto=" to "psmouse_max_proto=". I've attached both dmesg outputs, but the differences are as follows: *** dmesg Thu Sep 15 18:21:42 2005 --- dmesg.psmouse_max_proto=bare Thu Sep 15 18:06:51 2005 *************** *** 1,4 **** ! 130928 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 126832 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 --- 1,6 ---- ! 000000100000000 (reserved) ! 511MB LOWMEM available. ! On node 0 totalpages: 130928 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 126832 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 *************** *** 12,18 **** ACPI: PM-Timer IO Port: 0x1008 Allocating PCI resources starting at 30000000 (gap: 20000000:df800000) Built 1 zonelists ! Kernel command line: ro root=/dev/hda3 lapic idebus=33 video=radeon fbcon=scrollback:128k ide_setup: idebus=33 Local APIC disabled by BIOS -- reenabling. Found and enabled local APIC! --- 14,20 ---- ACPI: PM-Timer IO Port: 0x1008 Allocating PCI resources starting at 30000000 (gap: 20000000:df800000) Built 1 zonelists ! Kernel command line: ro root=/dev/hda3 lapic idebus=33 video=radeon fbcon=scrollback:128k psmouse_max_proto=bare ide_setup: idebus=33 Local APIC disabled by BIOS -- reenabling. Found and enabled local APIC! *************** *** 20,26 **** Initializing CPU#0 CPU 0 irqstacks, hard=c0364000 soft=c0363000 PID hash table entries: 2048 (order: 11, 32768 bytes) ! Detected 1687.230 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) --- 22,28 ---- Initializing CPU#0 CPU 0 irqstacks, hard=c0364000 soft=c0363000 PID hash table entries: 2048 (order: 11, 32768 bytes) ! Detected 1687.152 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) *************** *** 91,97 **** ACPI: PCI Interrupt 0000:02:05.0[A] -> Link [LNKF] -> GSI 9 (level, low) -> IRQ 9 Simple Boot Flag at 0x36 set to 0x1 audit: initializing netlink socket (disabled) ! audit(1126804813.616:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API --- 93,99 ---- ACPI: PCI Interrupt 0000:02:05.0[A] -> Link [LNKF] -> GSI 9 (level, low) -> IRQ 9 Simple Boot Flag at 0x36 set to 0x1 audit: initializing netlink socket (disabled) ! audit(1126803857.716:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API *************** *** 170,176 **** Real Time Clock Driver v1.12 ACPI: CPU0 (power states: C1[C1] C2[C2]) ACPI: Processor [CPU0] (supports 8 throttling states) ! ACPI: Thermal Zone [ATF0] (56 C) ACPI: Battery Slot [BAT1] (battery absent) ACPI: AC Adapter [ACAD] (on-line) ACPI: Lid Switch [LID0] --- 172,178 ---- Real Time Clock Driver v1.12 ACPI: CPU0 (power states: C1[C1] C2[C2]) ACPI: Processor [CPU0] (supports 8 throttling states) ! ACPI: Thermal Zone [ATF0] (59 C) ACPI: Battery Slot [BAT1] (battery absent) ACPI: AC Adapter [ACAD] (on-line) ACPI: Lid Switch [LID0] *************** *** 206,214 **** uhci_hcd 0000:00:1d.2: irq 9, io base 0x00001840 hub 3-0:1.0: USB hub found hub 3-0:1.0: 2 ports detected - usb 1-2: new full speed USB device using uhci_hcd and address 2 - hub 1-2:1.0: USB hub found - hub 1-2:1.0: 3 ports detected ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 9 ACPI: PCI Interrupt 0000:00:1d.7[D] -> Link [LNKH] -> GSI 9 (level, low) -> IRQ 9 PCI: Setting latency timer of device 0000:00:1d.7 to 64 --- 208,213 ---- *************** *** 218,226 **** ehci_hcd 0000:00:1d.7: irq 9, io mem 0xd0000000 PCI: cache line size of 32 is not supported by device 0000:00:1d.7 ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004 hub 4-0:1.0: USB hub found hub 4-0:1.0: 6 ports detected - usb 1-2: USB disconnect, address 2 ACPI: PCI Interrupt 0000:02:05.0[A] -> Link [LNKF] -> GSI 9 (level, low) -> IRQ 9 Yenta: CardBus bridge found at 0000:02:05.0 [104d:8140] Yenta: ISA IRQ mask 0x04b8, PCI irq 9 --- 217,225 ---- ehci_hcd 0000:00:1d.7: irq 9, io mem 0xd0000000 PCI: cache line size of 32 is not supported by device 0000:00:1d.7 ehci_hcd 0000:00:1d.7: USB 2.0 initialized, EHCI 1.00, driver 10 Dec 2004 + usb 1-2: new full speed USB device using uhci_hcd and address 2 hub 4-0:1.0: USB hub found hub 4-0:1.0: 6 ports detected ACPI: PCI Interrupt 0000:02:05.0[A] -> Link [LNKF] -> GSI 9 (level, low) -> IRQ 9 Yenta: CardBus bridge found at 0000:02:05.0 [104d:8140] Yenta: ISA IRQ mask 0x04b8, PCI irq 9 *************** *** 236,251 **** ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 9 ACPI: PCI Interrupt 0000:02:05.1[B] -> Link [LNKG] -> GSI 9 (level, low) -> IRQ 9 ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[9] MMIO=[d0202000-d02027ff] Max Packet=[2048] e100: Intel(R) PRO/100 Network Driver, 3.4.14-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 9 ACPI: PCI Interrupt 0000:02:08.0[A] -> Link [LNKE] -> GSI 9 (level, low) -> IRQ 9 e100: eth0: e100_probe: addr 0xd0200000, irq 9, MAC addr 08:00:46:B0:FF:5C - usb 2-2: new full speed USB device using uhci_hcd and address 2 - usb 3-1: new full speed USB device using uhci_hcd and address 2 eth1394: $Rev: 1264 $ Ben Collins <bcollins@debian.org> eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0) - ieee1394: Host added: ID:BUS[0-00:1023] GUID[080046030176ccbc] Bluetooth: Core ver 2.7 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized --- 235,248 ---- ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 9 ACPI: PCI Interrupt 0000:02:05.1[B] -> Link [LNKG] -> GSI 9 (level, low) -> IRQ 9 ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[9] MMIO=[d0202000-d02027ff] Max Packet=[2048] + usb 2-2: new full speed USB device using uhci_hcd and address 2 e100: Intel(R) PRO/100 Network Driver, 3.4.14-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 9 ACPI: PCI Interrupt 0000:02:08.0[A] -> Link [LNKE] -> GSI 9 (level, low) -> IRQ 9 e100: eth0: e100_probe: addr 0xd0200000, irq 9, MAC addr 08:00:46:B0:FF:5C eth1394: $Rev: 1264 $ Ben Collins <bcollins@debian.org> eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0) Bluetooth: Core ver 2.7 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized *************** *** 256,271 **** Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized i2c /dev entries driver ! SCSI subsystem initialized ! Initializing USB Mass Storage driver... ! scsi0 : SCSI emulation for USB Mass Storage devices ! usb-storage: device found at 2 ! usb-storage: waiting for device to settle before scanning ! usbcore: registered new driver usb-storage ! USB Mass Storage support registered. ! drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 1 proto 2 vid 0x067B pid 0x2305 ! usbcore: registered new driver usblp ! drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver kjournald starting. Commit interval 5 seconds EXT3 FS on hda10, internal journal EXT3-fs: mounted filesystem with ordered data mode. --- 253,260 ---- Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized i2c /dev entries driver ! usb 3-1: new full speed USB device using uhci_hcd and address 2 ! ieee1394: Host added: ID:BUS[0-00:1023] GUID[080046030176ccbc] kjournald starting. Commit interval 5 seconds EXT3 FS on hda10, internal journal EXT3-fs: mounted filesystem with ordered data mode. *************** *** 278,283 **** --- 267,282 ---- kjournald starting. Commit interval 5 seconds EXT3 FS on hda12, internal journal EXT3-fs: mounted filesystem with ordered data mode. + drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 1 proto 2 vid 0x067B pid 0x2305 + usbcore: registered new driver usblp + drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver + SCSI subsystem initialized + Initializing USB Mass Storage driver... + scsi0 : SCSI emulation for USB Mass Storage devices + usb-storage: device found at 2 + usb-storage: waiting for device to settle before scanning + usbcore: registered new driver usb-storage + USB Mass Storage support registered. Vendor: Sony Model: MSC-U03 Rev: 2.00 Type: Direct-Access ANSI SCSI revision: 00 usb-storage: device scan complete *************** *** 303,309 **** eth2: Radio is disabled by RF switch. ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 9 (level, low) -> IRQ 9 PCI: Setting latency timer of device 0000:00:1f.5 to 64 ! intel8x0_measure_ac97_clock: measured 52770 usecs intel8x0: clocking to 48000 ip_tables: (C) 2000-2002 Netfilter core team Netfilter messages via NETLINK v0.30. --- 302,308 ---- eth2: Radio is disabled by RF switch. ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 9 (level, low) -> IRQ 9 PCI: Setting latency timer of device 0000:00:1f.5 to 64 ! intel8x0_measure_ac97_clock: measured 52707 usecs intel8x0: clocking to 48000 ip_tables: (C) 2000-2002 Netfilter core team Netfilter messages via NETLINK v0.30.
Ah - this is interesting! When copying/pasting the diff of the dmesg output, I found that even under X I couldn't reliably select a screenful of text - it would frequently be as if I'd released the left button whilst I was still selecting text with the button held firmly down. So it's *definitely* nothing to do with gpm - the problem affects X reading from /dev/input/mice too!
/proc/bus/input/devices with psmouse_max_proto=bare: I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 H: Handlers=kbd event0 B: EV=120013 B: KEY=4 2000000 3802078 f840d001 f2ffffdf ffefffff ffffffff fffffffe 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=mouse0 event1 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=7321 N: Name="AlpsPS/2 ALPS GlidePoint" P: Phys=isa0060/serio1/input0 H: Handlers=mouse1 event2 B: EV=f B: KEY=420 0 70000 0 0 0 0 0 0 0 0 B: REL=3 B: ABS=1000003
/proc/bus/input/devices: I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 H: Handlers=kbd event0 B: EV=120013 B: KEY=4 2000000 3802078 f840d001 f2ffffdf ffefffff ffffffff fffffffe 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=mouse0 event1 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=7321 N: Name="AlpsPS/2 ALPS GlidePoint" P: Phys=isa0060/serio1/input0 H: Handlers=mouse1 event2 B: EV=f B: KEY=420 0 70000 0 0 0 0 0 0 0 0 B: REL=3 B: ABS=1000003
... so that's identical. Is that what's expected? Should I repeat using psmouse_max_proto=exps rather than =bare? (Looking through the input driver code, exps just enables additional functionality over bare, so bare should show everything than exps does - it's more restricted. I could be wrong...)
From attachment 68522 [details] in comment #55: Kernel command line: ro root=/dev/hda3 lapic idebus=33 video=radeon fbcon=scrollback:128k psmouse_max_proto=bare You have used "psmouse_max_proto=bare" when the instruction was to use "psmouse.proto=exps" - please correct and repeat that test (and get new dmesg and /proc/bus/input/devices")
(In reply to comment #61) > You have used "psmouse_max_proto=bare" when the instruction was to use > "psmouse.proto=exps" - please correct and repeat that test (and get new dmesg > and /proc/bus/input/devices") Having looked through the psmouse source, "bare" removes more cases that "exps" so would presumably have a greater chance of not doing something silly to the controller's state. In any case, I've not gathered the same data with "psmouse_max_proto=exps", as requested, and the output is yet again identical: $# cat devices I: Bus=0011 Vendor=0001 Product=0001 Version=ab41 N: Name="AT Translated Set 2 keyboard" P: Phys=isa0060/serio0/input0 H: Handlers=kbd event0 B: EV=120013 B: KEY=4 2000000 3802078 f840d001 f2ffffdf ffefffff ffffffff fffffffe 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=mouse0 event1 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=7321 N: Name="AlpsPS/2 ALPS GlidePoint" P: Phys=isa0060/serio1/input0 H: Handlers=mouse1 event2 B: EV=f B: KEY=420 0 70000 0 0 0 0 0 0 0 0 B: REL=3 B: ABS=1000003 dmesg states: mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard on isa0060/serio0 input: PS/2 Mouse on isa0060/serio1 input: AlpsPS/2 ALPS GlidePoint on isa0060/serio1 ... as before (full dmesg in attachment to follow)
Created attachment 68568 [details] 2.6.14-rc1 demsg with psmouse_max_proto=exps
No, the argument you need to use is psmouse DOT proto EQUALS exps :) "psmouse.proto=exps" not "psmouse_max_proto=exps"
If I use the old-style "psmouse.proto=exps" then I just get a kprint/dmesg line saying "Unknown argument: psmouse.proto=exps". We are still talking about 2.6.14-rc1, yes? If you look at the code for the input layer/psmouse driver, you'll see that what was "psmouse.proto" is now "psmouse_max_proto"... Give me 5 minutes and I'll reboot to get the exact message
P.S. $ cd /usr/src/linux-2.6.14-rc1 $ find . -type f -name \*.c -exec grep -H "psmouse_max_proto" {} \; | \ > cut -d":" -f1 | sort | uniq | wc -l 1 $ find . -type f -name \*.c -exec grep -H "psmouse\.proto" {} \; | \ > cut -d":" -f1 | sort | uniq | wc -l 0 ... so "psmouse.proto" has definitely gone!
No - your understanding is wrong. Both Linux 2.6.13 and 2.6.14-rc1 contain this code in drivers/input/mouse/psmouse.c: static struct serio_driver psmouse_drv = { .driver = { .name = "psmouse", }, This means that any parameters prefixed "psmouse" followed by a . will be sent to that driver. Both Linux 2.6.13 and 2.6.14-rc1 also contain this line further up in the same file: module_param_named(proto, psmouse_max_proto, proto_abbrev, 0644); This means, take the parameter named "proto", store its value in a local variable called "psmouse_max_proto", the parameter type is a proto_abbrev and the sysfs permissions on the module option are 0644 Hence psmouse.proto is the right argument to use on the command line and psmouse_max_proto is not
Just confirmed this on 2.6.14-rc1 here, psmouse.proto has the desired effect and psmouse_max_proto doesn't do anything. As it looks like you may have been testing wrong previously, please reconfirm that the issues are present on 2.6.14-rc1 once you have got the proto=exps parameter into play and there is some visible difference in /proc/bus/input/devices
Oops... my bad ;) (I'm sorry - I've had an incredibly long and tiring week) The thing that confused me most is that the (incorrect) option I was using previously was apparently accepted, whereas I now get: Kernel command line: ro root=/dev/hda3 lapic idebus=33 video=radeon fbcon=scroll back:128k psmouse.proto=exps ide_setup: idebus=33 Unknown boot option `psmouse.proto=exps': ignoring Am I doing something incredibly stupid here? In any case, with this option /proc/bus/input/devices is the same as before. P.S. I noticed that in 2.6.14-rc1 using /dev/input/mice as the mouse device under X, window dragging has the same problem as selecting text: You can move a window for about 1/3 of the screen at a time, then it is dropped as if the button has been released.
Argh, fsck it! I've got psmouse compiled as a module, and I guess this means that parameters can *only* be passed when loading the module, rather than via the kernel command line? (Or should the kernel not be ignoring the psmouse.proto argument, even if the psmouse module isn't loaded?) But in any case, with an "options psmouse proto=exps" in /etc/modules.d/, my trackpad now works just as it did previously in 2.6.10 in 2.6.14! D'oh! I'm now mortally embarrased and, erm, I'll get my coat... :D Seriously - sorry for wasting everyone's time, and many thanks for all the help along the way. I'll just check that 2.6.12 and .13 work (which I'm now sure they will) and report back that it's okay to close this one.
If you have it as a module then you can't specify the parameters on the kernel command line. I was going to suggest you check this, but I looked at your dmesg output and that seemed to indicate that you had it built in - apparently I misinterpreted that :) Marking as fixed. I still feel this is a minor bug as it doesn't completely work "out of the box", I've written this on the upstream bug report and will write here if any patches become available for testing.
Yep - it's fixed in everything from 2.6.12 to 2.6.14-rc1, and I'm (as promised) over the moon ;) I agree though, it would probably be helpful if ALPS pads did work without having to add additional module options (and then finding that people have forgotten whether the module is built-in or not... d'oh!), perhaps by adding a kernel option to "Limit protocol for ALPS touchpads" (or similar).
