2.6.9-rc2-mm4 + alps locks input in X

2.6.9-rc2-mm4 + alps locks input in X

[Micha Feigin]

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.

Re: 2.6.9-rc2-mm4 + alps locks input in X

[James Oakley]

-----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.
joakley@solutioninc.com
http://www.solutioninc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBWGQ+4U2uQswGyDcRAh4bAJ93zzNwUXkLr6vLmfq9IR1BomfiEgCgjS5Q
pxHpu3Ev+ltw7Sz3mEBItGw=
=D5Kj
-----END PGP SIGNATURE-----

Re: 2.6.9-rc2-mm4 + alps locks input in X

[Peter Osterlund]

James Oakley <joakley@solutioninc.com> 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 - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: 2.6.9-rc2-mm4 + alps locks input in X (alps not identifying correctly)

[Micha Feigin]

On Mon, Sep 27, 2004 at 10:25:42PM +0200, Peter Osterlund wrote:
> James Oakley <joakley@solutioninc.com> 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 - petero2@telia.com
> http://w1.894.telia.com/~u89404340
> -
> 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/
>  
>  +++++++++++++++++++++++++++++++++++++++++++
>  This Mail Was Scanned By Mail-seCure System
>  at the Tel-Aviv University CC.
> 

Re: 2.6.9-rc2-mm4 + alps locks input in X (alps not identifying correctly)

[Dmitry Torokhov]

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