Hi Benjamin, On Tue, Aug 30, 2022 at 02:45:11PM +0200, Benjamin Tissoires wrote: > On Thu, Aug 25, 2022 at 8:44 AM Marcus Folkesson > <marcus.folkesson@xxxxxxxxx> wrote: > > [...] > > > > > > Is the fact that more than one button share the same > > byte hard to describe in the report? > > No, this is actually easy to describe. You say that there is one usage > of "something" which has a report size of 1 bit, and then you have > another usage of "something else" with the same report size. > > But usually you have to add padding after to make up to 8 bits (so 6 > bits in that case). > > I was referring to the case where you are parsing the same bit on the > wire, and give a different usage based if you have received an odd or > an even number of reports. In that case, we probably need to use move > this bit to a const field in the original report descriptor and say > that the data is now not const: > > - initial report (completely random example): > X (2 bytes) | Y (2 bytes) | button this_or_that (1 bit, depending of > odd or even received reports) | 7 bits of padding > - we can declare it as: > X (2 bytes) | Y (2 bytes) | button this (1 bit) | button that (1 > bit) | 6 bits of padding How about if there is no unused bytes? The XTRG2FMS has 8 10-bit channels and use every byte in the report. Should I specify 8 8-bit channels instead and fix that in raw_event? If so, should I only use 8bit values then? (Are you at the ELCE conference btw?) Best regards Marcus Folkesson
Attachment:
signature.asc
Description: PGP signature
