There seems to be a conflict between the new changes to the input
system (as in 2.6.9-rc2-mm4 and 2.6.9-rc2-bk13) and the alps patch.
I tried both with mm4 with the already included alps patch and with
bk11 and bk13 with the patch manually applied. In both cases when
starting X with the alps driver input is completely dead in X, both
mouse and keyboard, including sysrq keys and num-lock/caps-lock.
I can ssh in, kill X and everything is functional again (although the
keyboard behaves as if num-lock is presses, enabling/disabling it
solves that).
If I start X with the ImPS/2 driver with the same kernel then the input
works fine except for the mouse being a bit slow.
In console everything is working fine.
The same setup works in 2.6.9-rc2 and backward with the alps patch.
I've mostly exhausted my knowledge. Will be happy for pointers/ideas to
locate the cause.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Monday 27 September 2004 4:27 pm, Micha Feigin wrote:
> I tried both with mm4 with the already included alps patch and with
> bk11 and bk13 with the patch manually applied. In both cases when
> starting X with the alps driver input is completely dead in X, both
> mouse and keyboard, including sysrq keys and num-lock/caps-lock.
I had this problem when I accidentally used the event device for my keyboard
instead of the touchpad. It didn't help that every alps XF86Config example
out there points to event1, which is my keyboard.
cat /proc/bus/input/devices to see which event device to use.
- --
James Oakley
Engineering - SolutionInc Ltd.
[email protected]
http://www.solutioninc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBWGQ+4U2uQswGyDcRAh4bAJ93zzNwUXkLr6vLmfq9IR1BomfiEgCgjS5Q
pxHpu3Ev+ltw7Sz3mEBItGw=
=D5Kj
-----END PGP SIGNATURE-----
James Oakley <[email protected]> writes:
> On Monday 27 September 2004 4:27 pm, Micha Feigin wrote:
> > I tried both with mm4 with the already included alps patch and with
> > bk11 and bk13 with the patch manually applied. In both cases when
> > starting X with the alps driver input is completely dead in X, both
> > mouse and keyboard, including sysrq keys and num-lock/caps-lock.
>
> I had this problem when I accidentally used the event device for my keyboard
> instead of the touchpad. It didn't help that every alps XF86Config example
> out there points to event1, which is my keyboard.
>
> cat /proc/bus/input/devices to see which event device to use.
Or better yet, use the auto-dev feature, which should work if you have
a new enough X driver and kernel patch.
--
Peter Osterlund - [email protected]
http://w1.894.telia.com/~u89404340
On Mon, Sep 27, 2004 at 10:25:42PM +0200, Peter Osterlund wrote:
> James Oakley <[email protected]> writes:
>
> > On Monday 27 September 2004 4:27 pm, Micha Feigin wrote:
> > > I tried both with mm4 with the already included alps patch and with
> > > bk11 and bk13 with the patch manually applied. In both cases when
> > > starting X with the alps driver input is completely dead in X, both
> > > mouse and keyboard, including sysrq keys and num-lock/caps-lock.
> >
> > I had this problem when I accidentally used the event device for my keyboard
> > instead of the touchpad. It didn't help that every alps XF86Config example
> > out there points to event1, which is my keyboard.
> >
Thanks that solved the problem, no more lockups.
> > cat /proc/bus/input/devices to see which event device to use.
>
> Or better yet, use the auto-dev feature, which should work if you have
> a new enough X driver and kernel patch.
>
auto-dev doesn't work for me and I don't have time to check it
out. While poking around I did find another problem though.
There is also a kernel problem, to summarize, the touchpad is
identifying itself differently then with previous kernels and thus
isn't recognized at all by the kernel.
I don't know how much effect it actually has since some initialization
is also done through X.
The main problem I found:
Under 2.6.9-rc2-mm4 in alps.c under function alps_get_model, for the
call to ps2_command with PSMOUSE_CMD_GETINFO (the E6 report output) the
output is 00 00 14 instead of 00 00 64 like it was before and what is
expected, so the touchpad isn't recognized at all as an alps. (I can't
figure out whats causing the difference or how the return value is
received at all, and I don't have any more time to dig further into it).
Second problem is that hardware tapping is disabled by default
(I found no way to enable it externally) which in my case causes most
taps to be interpreted as double clicks instead of single clicks.
After fixing both things and X to use the right device things finally
work again.
> --
> Peter Osterlund - [email protected]
> http://w1.894.telia.com/~u89404340
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
>
On Monday 27 September 2004 10:46 pm, Micha Feigin wrote:
> > Or better yet, use the auto-dev feature, which should work if you have
> > a new enough X driver and kernel patch.
> >
>
> auto-dev doesn't work for me and I don't have time to check it
> out.
Addition of Kensington ThinkingMouse / ExpertMouse support caused Synaptics
and ALPS protocol numbers to move to 8 and 9 respectively which broke Peter's
auto-dev detection.
Vojtech, we need to keep protcol numbers stable, I propose something like this:
enum psmouse_type {
PSMOUSE_PS2 = 0,
PSMOUSE_PS2PP,
PSMOUSE_THINKPS,
PSMOUSE_GENPS = 64, /* 4 byte protocol start */
PSMOUSE_IMPS,
PSMOUSE_IMEX,
PSMOUSE_SYNAPTICS = 128, /* 5+ byte protocols start */
PSMOUSE_ALPS,
};
Peter, if we adopt the scheme above you will have to check both for old and
new protocol numbers; in addition you need to BTN_TOOL_FINGER device bit to
make sure you are dealing with a touchpad.
Any holes here?
--
Dmitry