On 1/13/10 2:53 AM, Dmitry Torokhov 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. This receiver is essentially identical to all the windows media center transceivers out there (and can in fact be driven as such by simply adding its device id to the lirc_mceusb driver). They all signal the start of an incoming packet with an 0x8y header byte, where y is the number of bytes contained in the packet following the header (but excluding the header). So the empty packet 0x80 is used to signal the end of a transmitted IR command. -- Jarod Wilson jarod@xxxxxxxxxx -- 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