On Wed, Oct 15, 2014 at 08:28:59PM +0200, Pali Rohár wrote: > On Wednesday 15 October 2014 20:17:40 Dmitry Torokhov wrote: > > On Wed, Oct 15, 2014 at 08:06:45PM +0200, Pali Rohár wrote: > > > On Wednesday 15 October 2014 19:55:24 Dmitry Torokhov wrote: > > > > Hi Pali, > > > > > > > > On Fri, Oct 03, 2014 at 03:51:12PM +0200, Pali Rohár wrote: > > > > > Sometimes laptops with closed lid receive invalid ALPS > > > > > protocol V3 packets with last bit7 set. > > > > > > > > > > This happens on Dell Latitude laptops and it looks like > > > > > it is BIOS bug. Probably EC does not correctly split > > > > > keyboard and touchpad PS/2 data and when laptop lid is > > > > > closed it adds 0xFF packet into touchpad PS/2 data. > > > > > > > > Is it always 0xff or do you see different values with the > > > > 7th bit set? Also, the "bad data" - does is always stop > > > > on the 6th byte of the data stream or the "real" 6th byte > > > > comes after the bad one? > > > > > > > > Thanks. > > > > > > In this case stream is: > > > > > > 0 1 2 3 4 5 0 1 2 3 4 5 0 1 2 3 4 5 ... > > > V V V V V X V V V V V X V V V V V X ... > > > > > > number packet position in buffer, V means that packet at > > > specified position in buffer is valid (and also all previous > > > packets in buffer are valid), X means packet at position is > > > invalid. > > > > > > It means that alps driver receive 5 valid packets and after > > > that one is invalid. And again it receive 5 valid and last > > > invalid... > > > > > > I looked into my logs and X was always 0xFF. > > > > OK, then I think we should change the test to explicitly look > > for 0xff when returning PSMOUSE_PACKET_FULL. > > > > Thanks. > > Tommy, this patch was originally written by you. (here is) Hmm, if that was originally done by Tommy I'd need his signed-off-by on the patch please. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html