Just tried kernel 2.6.9-rc2-bk11 and when I start X input is completely
dead (including num-lock, caps-lock, sysrq and mouse). The computer is
otherwise functional (I can log in with ssh, kill X and everything is
functional again).
In the console is completely functional, before and after starting X.
I had exactly the same behavior with mm kernels from version 2.6.7 or
2.6.8 (not sure) onwards, which was fixed by reversing the bk-input
patch.
kernel 2.6.9-rc2 works fine.
The machine is Sony Vaio PCG-FXA53 laptop (amd 1500+ and via chipset).
The keyboard is recognized as ps2 AFAIK and the touchpad is an alps
(with the alps kernel patch).
Salut,
On Sun, Sep 26, 2004 at 11:04:51PM +0200, Micha Feigin wrote:
> Just tried kernel 2.6.9-rc2-bk11 and when I start X input is completely
> dead (including num-lock, caps-lock, sysrq and mouse). The computer is
> otherwise functional (I can log in with ssh, kill X and everything is
> functional again).
Which X do you use? And which version?
Tonnerre
On Sun, Sep 26, 2004 at 11:00:45PM +0200, Tonnerre wrote:
> Salut,
>
> On Sun, Sep 26, 2004 at 11:04:51PM +0200, Micha Feigin wrote:
> > Just tried kernel 2.6.9-rc2-bk11 and when I start X input is completely
> > dead (including num-lock, caps-lock, sysrq and mouse). The computer is
> > otherwise functional (I can log in with ssh, kill X and everything is
> > functional again).
>
> Which X do you use? And which version?
>
xfree 4.3 in debian unstable (I believe its somewhat modified), debian
calls it 4.3.0.dfsg.1-7.
The bk-input patch is a bit big for me to search for the problematic
change, but anyone has any leads I will happily poke around further.
> Tonnerre
On Mon, Sep 27, 2004 at 02:43:21PM +0200, Micha Feigin wrote:
> On Sun, Sep 26, 2004 at 11:00:45PM +0200, Tonnerre wrote:
> > Salut,
> >
> > On Sun, Sep 26, 2004 at 11:04:51PM +0200, Micha Feigin wrote:
> > > Just tried kernel 2.6.9-rc2-bk11 and when I start X input is completely
> > > dead (including num-lock, caps-lock, sysrq and mouse). The computer is
> > > otherwise functional (I can log in with ssh, kill X and everything is
> > > functional again).
> >
> > Which X do you use? And which version?
> >
>
> xfree 4.3 in debian unstable (I believe its somewhat modified), debian
> calls it 4.3.0.dfsg.1-7.
>
> The bk-input patch is a bit big for me to search for the problematic
> change, but anyone has any leads I will happily poke around further.
>
Did some more testing and apparently its something to do with the alps
touchpad patch. When using the alps as a touchpad all the input
completely dies on X startup, when I use it as a GlidePointPS/2 things
work fine (even with the alps patch), although mouse is a bit slow.
Will try and dig further and see if I come up with a fix.
> > Tonnerre
>
>
> -
> 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.
>
Resending as I forgot to CC Vojtech and Peter first time around...
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
On Tue, Sep 28, 2004 at 01:26:19AM -0500, Dmitry Torokhov wrote:
> Resending as I forgot to CC Vojtech and Peter first time around...
>
> 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.
Ouch. I suspected something bad will happen.
> 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,
> };
No, we really need to keep backwards compatibility with the numbering
here and solve the packetsize issue elsewhere. Probably the best would
be for each of the protocols to have its own packet collection routine,
like the Synaptics and ALPS already have. It could be shared among the
simpler protocols.
We'll need this anyway for a heuristic resynchronizer.
> 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?
I really would prefer if old installations of the X driver would work
with new kernel without the need to upgrade the X driver. I propose to
keep the protocol numbers intact, and if possible to also find a better
way for the X driver to detect a touchpad than relying on the IDs of the
input device, namely based on BTN_TOOL_FINGER presence.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Tuesday 28 September 2004 02:01 am, Vojtech Pavlik wrote:
> On Tue, Sep 28, 2004 at 01:26:19AM -0500, Dmitry Torokhov wrote:
> > Resending as I forgot to CC Vojtech and Peter first time around...
> >
> > 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.
>
> Ouch. I suspected something bad will happen.
>
> > 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,
> > };
>
> No, we really need to keep backwards compatibility with the numbering
> here and solve the packetsize issue elsewhere. Probably the best would
> be for each of the protocols to have its own packet collection routine,
> like the Synaptics and ALPS already have. It could be shared among the
> simpler protocols.
>
> We'll need this anyway for a heuristic resynchronizer.
>
Ok, for now I am killing PS2TPP which is not really useful and will allow
THINKPS take it's spot moving SYNAPTICS and ALPS to their former numbers.
--
Dmitry
On Tue, Sep 28, 2004 at 02:19:16AM -0500, Dmitry Torokhov wrote:
> Ok, for now I am killing PS2TPP which is not really useful and will allow
> THINKPS take it's spot moving SYNAPTICS and ALPS to their former numbers.
Where's the patch? ;)
--
Vojtech Pavlik
SuSE Labs, SuSE CR
On Tuesday 28 September 2004 06:06 am, Vojtech Pavlik wrote:
> On Tue, Sep 28, 2004 at 02:19:16AM -0500, Dmitry Torokhov wrote:
>
> > Ok, for now I am killing PS2TPP which is not really useful and will allow
> > THINKPS take it's spot moving SYNAPTICS and ALPS to their former numbers.
>
> Where's the patch? ;)
>
Right here in my queue ;) I should have the next set of patches ready either
tonight or tomorrow night.
--
Dmitry
On Llu, 2004-09-27 at 13:43, Micha Feigin wrote:
> xfree 4.3 in debian unstable (I believe its somewhat modified), debian
> calls it 4.3.0.dfsg.1-7.
>
> The bk-input patch is a bit big for me to search for the problematic
> change, but anyone has any leads I will happily poke around further.
Make sure that the Debian developers have included the
patches/configuration options so that the keyboard driver is not banging
the keyboard/mouse I/O ports directly. The input layer does not like
that, although I've yet to see a crash/hang from it.
Alan