Re: [alps] Timing patch, revised again :-)

From: Sebastian Kapfer <sebastian_kapfer@gmx.net>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Linux Input ML <linux-input@vger.kernel.org>
Subject: Re: [alps] Timing patch, revised again :-)
Date: Sun, 06 Dec 2009 20:53:57 +0100	[thread overview]
Message-ID: <1260129237.21632.7.camel@sardelle.necksus.de> (raw)
In-Reply-To: <200912041549.48949.dmitry.torokhov@gmail.com>

Hi Dmitry!

On Fr, 2009-12-04 at 15:49 -0800, Dmitry Torokhov wrote:
[...]
> > Given this behaviour of the hw, I'd favour not reporting button presses
> > on a device while the corresponding button on the other device is down.
> > (Dave called this behaviour 'masking'.)  Code implementing this was in
> > the patch I sent to linux-input dated Nov. 11 (see the parts involving
> > the btn_state variable).  I have not put it back in the patch below
> > because I'd like to await your opinion on this first.
> 
> OK, Let me take a look at that patch again.

I think it's pretty straightforward.  Let me know what you think.

> > There is still one failure mode left that causes de-sync.  It happens
> > when the else branch in  alps_handle_interleaved_ps2 gets called more
> > than once, i.e. we're accidentially reconstructing a 12-, 15- etc byte
> > packet.  This was easier to deal with in my first patch, I just
> > collected the whole 9 bytes in a buffer and implicitly knew when the
> > packet was over.  Example of this happening:
> > 
> > Dec  4 21:03:22 sardelle kernel: [410740.786121] alps.c: handle: cf
> > Dec  4 21:03:22 sardelle kernel: [410740.787499] alps.c: handle: 79
> > Dec  4 21:03:22 sardelle kernel: [410740.788688] alps.c: handle: 12
> > Dec  4 21:03:22 sardelle kernel: [410740.789979] alps.c: handle: 1f
> > Dec  4 21:03:22 sardelle kernel: [410740.791146] alps.c: handle: ff
> > Dec  4 21:03:22 sardelle kernel: [410740.792299] alps.c: handle: 1
> > <suspect 9byte (really is)>
> > Dec  4 21:03:22 sardelle kernel: [410740.796899] alps.c: handle: 4f
> > <yup, it is, fold back>
> 
> Ah, ok, so when we report all 3 buttons pressed we mistaken it as interleaved 
> packet again... Insteado f waiting till 9th byte can't we just forcefully
> exit inetrleaved mode (once we processed the bare packet) by doing:
> 
>      psmouse->packet[3] &= 0xf7;

Hmm I guess we could do something like this, but IMHO it makes the code
needlessly arcane.  What would be the point?  Save 3 bytes of buffer?
Deliver the mouse movement a microsecond earlier?  Given that the
interleaved packet is somehow a coherent piece of data sent by the
touchpad, I'd store it exactly like that.

Greetings!

-- 
Sebastian Kapfer
 Inst. für Theoretische Physik I        Office +49-9131-85-2-8450
 Universität Erlangen                   Mobile +49-160-9577-6436
 Staudtstr. 7, Raum 02.583.             sebastian.kapfer@physik.uni-erlangen.de

--
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