Re: [PATCH 0/6] Fixes for ALPS trackstick

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Sat, Jan 17, 2015 at 11:01:56AM +0100, Pali Rohár wrote:
> On Thursday 15 January 2015 22:02:16 Dmitry Torokhov wrote:
> > On Thu, Jan 15, 2015 at 09:28:41PM +0100, Pali Rohár wrote:
> > > On Thursday 15 January 2015 20:38:18 Dmitry Torokhov wrote:
> > > > On Thu, Jan 15, 2015 at 08:19:59PM +0100, Pali Rohár wrote:
> > > > > On Thursday 15 January 2015 19:18:20 Dmitry Torokhov 
> wrote:
> > > > > > On Thu, Jan 15, 2015 at 11:49:32AM +0100, Pali Rohár 
> wrote:
> > > > > > > On Wednesday 14 January 2015 23:55:48 Dmitry
> > > > > > > Torokhov
> > > 
> > > wrote:
> > > > > > > > Hi Pali,
> > > > > > > > 
> > > > > > > > This series try to address the issue you brought
> > > > > > > > regarding trackstick initialization on Dell
> > > > > > > > Latitudes in a different way than the patches you
> > > > > > > > proposed. Basically in this series we move
> > > > > > > > resetting and all detection in alps_detect() and
> > > > > > > > make sure we keep the state so alps_init() can
> > > > > > > > reuse it and not perform the detection all over
> > > > > > > > again. Doing this allows us to set up device
> > > > > > > > characteristics (name, version, etc) properly
> > > > > > > > from the get go while still performing reset only
> > > > > > > > once.
> > > > > > > > 
> > > > > > > > This is untested as I do not have any ALPS devices
> > > > > > > > anymore so I'd appreciate you giving it a spin.
> > > > > > > > 
> > > > > > > > Thanks!
> > > > > > > 
> > > > > > > Hi Dmitry,
> > > > > > > 
> > > > > > > on top of which branch/repository should I apply
> > > > > > > your patches?
> > > > > > 
> > > > > > Should be applicable to my 'next' branch (which I just
> > > > > > upreved to 3.19-rc4).
> > > > > > 
> > > > > > Thanks.
> > > > > 
> > > > > Not working at top of next (0c3e994).
> > > > > 
> > > > > Applying: Input: ALPS - renumber protocol numbers
> > > > > Applying: Input: ALPS - make Rushmore a separate
> > > > > protocol error: patch failed:
> > > > > drivers/input/mouse/alps.c:1275 error:
> > > > > drivers/input/mouse/alps.c: patch does not apply Patch
> > > > > failed at 0002 Input: ALPS - make Rushmore a separate
> > > > > protocol
> > > > 
> > > > Hmm.. I created a new alps branch (based on 3.19-rc4), can
> > > > you try it?
> > > > 
> > > > Thanks.
> > > 
> > > Compiled from your new alps branch (with "if (!priv)" fix)
> > > and modprobing psmouse.ko caused laptop freeze :-( Even
> > > sysrq not responded. So something is not working...
> > 
> > Hmm, is it on text console or in X? Any chance you could go
> > through pathes - there are only 8 of them including 2 of
> > yours that should be unmodified.
> > 
> > Thanks.
> 
> Hi, now I tested patch by patch and kernel crash is caused only 
> by last patch 6/6 and only after I touch touchpad or trackstick.
> 
> In text console it prints lot of panic messages and because it 
> prints lot of messages I cannot read (or record) more then last.
> 
> In last call trace I see that alps_register_bare_ps2_mouse() was 
> called and it generated page_fault.

That happens because while you added priv->psmouse pointer it looks like
you forgot to initialize it and I missed that too...

> I do not understand why that 
> function was ever called (I do not have connected any PS/2 mouse 
> which can generate bare 3 bytes PS/2 packet) and also why that 
> function caused page fault.

Hmm... my memory might be hazy but I seem to recall that
trackstick data can come as either dedicated packets or bare PS/2
format, I am not sure if we can actually split the data streams into 2
devices.

I do not have boxes with ALPS devices though so I am unable to
experiment.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html