On Sunday 18 January 2015 08:22:45 Dmitry Torokhov wrote: > 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... > Right your patch 6/6 does not initialize priv->psmouse. I looked into my original patch and it initialize it, so there was some copy-paste error. Look at other emails... can you fix problems and send new version of your patches for testing? > > 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. From documentation and also source code it looks like trackstick data are reported in ALPS 6bytes packets and not in bare 3bytes. 3 months ago Vadim Klishko (CCed) wrote me: "I don't think there is an Alps device that would mix 3-byte and 6-byte packets." -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
