On Wed, Jan 13, 2010 at 8:22 PM, Chaogui Zhang <czhang@xxxxxxxxxxxx> wrote: > On Wed, Jan 13, 2010 at 2:53 AM, Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx> wrote: >> Hi Chaogui, >> >> I was looking at the driver again and I have some concerns with the >> foolowing fragment: >> >> On Tue, Dec 15, 2009 at 07:53:57PM -0500, Chaogui Zhang wrote: >>> + >>> + /* The lower 5 bits of the first byte of each packet indicates the size >>> + * of the transferred buffer, not including the first byte itself. >>> + */ >>> + >>> + length = (remote->in_buffer[0]) & 0x1f; >>> + for (i = 0; i <= length; i++) >>> + snprintf(codes + i * 3, 4, "%02x ", remote->in_buffer[i]); >>> + >>> + /* 0x80 at the end of a regular packet or in a separate packet >>> + indicates key release */ >>> + >>> + if (i < TIVOIR_RECV_SIZE && remote->in_buffer[i] == 0x80) >>> + snprintf(codes + i * 3, 4, "%02x ", remote->in_buffer[i]); >>> + >> >> So does this mean that 0x80 indicating release is not included in the >> size of the received packet. >> > > Hi, Dimitry, > > Sorry that you are getting this message twice. I accidentally dropped > the list from the cc again. > > You are correct and the 0x80 signals the end of the packet and > To finish my sentence: ... and it is NOT included in the packet size. I don't know what is going on with me today. Silly things like this keep happening. My sincere apologies. -- Chaogui Zhang -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
