input: mt: Document the MT event slot protocol (rev4)
in [Kernel]
|
Prev: buffer_head: remove redundant test from wait_on_buffer
Next: [PATCH] fbdev: bfin-t350mcqb-fb: avoid unused warnings in backlight code
From: Ping Cheng on 24 May 2010 13:10 On Mon, May 24, 2010 at 12:13 AM, Henrik Rydberg <rydberg(a)euromail.se> wrote: > Ping Cheng wrote: >> What I am thinking is that we only need one SYN_ call for both _MT_ >> and regular data combined, which is a call to input_sync() at the end >> of the whole packet. The SYN_MT_ can be replaced by the following >> example, which I think is more "client-friendly". This solution is >> based on the fact that the major difference between type A and type B >> is whether we need to filter the data or not: >> >> ABS_MT_RANDOM 0 >> ABS_MT_POSITION_X x[0] >> ABS_MT_POSITION_Y y[0] >> ABS_MT_ RANDOM 1 >> ABS_MT_POSITION_X x[1] >> ABS_MT_POSITION_Y y[1] >> SYN_REPORT >> >> input_set_abs_params(input_dev, ABS_MT_RANDOM, 0, 2, 0, 0); >> >> would tell the clients that they can expect two random touches. > > And if you do s/RANDOM/SLOT/, you end up with what? ;-) Haha, I know what you are thinking :). Maybe I didn't make my point clear. I didn't mean to make SLOT backward compatible. I meant to replace SYN_MT_REPORT event with the ABS_MT_ RANDOM label so we only sync the whole packet once at the end. This way both types of MT_ data follow the same input event reporting flow.... SLOT and RANDOM are both needed since they deal with two different types of MT data, filtered (type B) and unfiltered (type A). There is no midunderstanding there. Ping -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Henrik Rydberg on 24 May 2010 14:10 Ping Cheng wrote: > On Mon, May 24, 2010 at 12:13 AM, Henrik Rydberg <rydberg(a)euromail.se> wrote: >> Ping Cheng wrote: >>> What I am thinking is that we only need one SYN_ call for both _MT_ >>> and regular data combined, which is a call to input_sync() at the end >>> of the whole packet. The SYN_MT_ can be replaced by the following >>> example, which I think is more "client-friendly". This solution is >>> based on the fact that the major difference between type A and type B >>> is whether we need to filter the data or not: >>> >>> ABS_MT_RANDOM 0 >>> ABS_MT_POSITION_X x[0] >>> ABS_MT_POSITION_Y y[0] >>> ABS_MT_ RANDOM 1 >>> ABS_MT_POSITION_X x[1] >>> ABS_MT_POSITION_Y y[1] >>> SYN_REPORT >>> >>> input_set_abs_params(input_dev, ABS_MT_RANDOM, 0, 2, 0, 0); >>> >>> would tell the clients that they can expect two random touches. >> And if you do s/RANDOM/SLOT/, you end up with what? ;-) > > Haha, I know what you are thinking :). > > Maybe I didn't make my point clear. I didn't mean to make SLOT > backward compatible. I meant to replace SYN_MT_REPORT event with the > ABS_MT_ RANDOM label so we only sync the whole packet once at the end. > This way both types of MT_ data follow the same input event reporting > flow.... You mean changing the type A protocol, breaking the current code base? That is a big no-no. > SLOT and RANDOM are both needed since they deal with two different > types of MT data, filtered (type B) and unfiltered (type A). There is > no midunderstanding there. > > Ping Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Torokhov on 24 May 2010 14:20 On Mon, May 24, 2010 at 08:02:40PM +0200, Henrik Rydberg wrote: > Ping Cheng wrote: > > On Mon, May 24, 2010 at 12:13 AM, Henrik Rydberg <rydberg(a)euromail.se> wrote: > >> Ping Cheng wrote: > >>> What I am thinking is that we only need one SYN_ call for both _MT_ > >>> and regular data combined, which is a call to input_sync() at the end > >>> of the whole packet. The SYN_MT_ can be replaced by the following > >>> example, which I think is more "client-friendly". This solution is > >>> based on the fact that the major difference between type A and type B > >>> is whether we need to filter the data or not: > >>> > >>> ABS_MT_RANDOM 0 > >>> ABS_MT_POSITION_X x[0] > >>> ABS_MT_POSITION_Y y[0] > >>> ABS_MT_ RANDOM 1 > >>> ABS_MT_POSITION_X x[1] > >>> ABS_MT_POSITION_Y y[1] > >>> SYN_REPORT > >>> > >>> input_set_abs_params(input_dev, ABS_MT_RANDOM, 0, 2, 0, 0); > >>> > >>> would tell the clients that they can expect two random touches. > >> And if you do s/RANDOM/SLOT/, you end up with what? ;-) > > > > Haha, I know what you are thinking :). > > > > Maybe I didn't make my point clear. I didn't mean to make SLOT > > backward compatible. I meant to replace SYN_MT_REPORT event with the > > ABS_MT_ RANDOM label so we only sync the whole packet once at the end. > > This way both types of MT_ data follow the same input event reporting > > flow.... > > You mean changing the type A protocol, breaking the current code base? That is a > big no-no. > We, however, could say that SYN_MT_REPORT may be omitted by the drivers using slotting mechanism. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Henrik Rydberg on 24 May 2010 14:40 Dmitry Torokhov wrote: > On Mon, May 24, 2010 at 08:02:40PM +0200, Henrik Rydberg wrote: >> Ping Cheng wrote: >>> On Mon, May 24, 2010 at 12:13 AM, Henrik Rydberg <rydberg(a)euromail.se> wrote: >>>> Ping Cheng wrote: >>>>> What I am thinking is that we only need one SYN_ call for both _MT_ >>>>> and regular data combined, which is a call to input_sync() at the end >>>>> of the whole packet. The SYN_MT_ can be replaced by the following >>>>> example, which I think is more "client-friendly". This solution is >>>>> based on the fact that the major difference between type A and type B >>>>> is whether we need to filter the data or not: >>>>> >>>>> ABS_MT_RANDOM 0 >>>>> ABS_MT_POSITION_X x[0] >>>>> ABS_MT_POSITION_Y y[0] >>>>> ABS_MT_ RANDOM 1 >>>>> ABS_MT_POSITION_X x[1] >>>>> ABS_MT_POSITION_Y y[1] >>>>> SYN_REPORT >>>>> >>>>> input_set_abs_params(input_dev, ABS_MT_RANDOM, 0, 2, 0, 0); >>>>> >>>>> would tell the clients that they can expect two random touches. >>>> And if you do s/RANDOM/SLOT/, you end up with what? ;-) >>> Haha, I know what you are thinking :). >>> >>> Maybe I didn't make my point clear. I didn't mean to make SLOT >>> backward compatible. I meant to replace SYN_MT_REPORT event with the >>> ABS_MT_ RANDOM label so we only sync the whole packet once at the end. >>> This way both types of MT_ data follow the same input event reporting >>> flow.... >> You mean changing the type A protocol, breaking the current code base? That is a >> big no-no. >> > > We, however, could say that SYN_MT_REPORT may be omitted by the drivers > using slotting mechanism. > Yes. If that is still unclear from the documentation, I will happily modify it. Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ping Cheng on 25 May 2010 12:40
On Mon, May 24, 2010 at 11:02 AM, Henrik Rydberg <rydberg(a)euromail.se> wrote: > Ping Cheng wrote: >> On Mon, May 24, 2010 at 12:13 AM, Henrik Rydberg <rydberg(a)euromail.se> wrote: >>> Ping Cheng wrote: >>>> What I am thinking is that we only need one SYN_ call for both _MT_ >>>> and regular data combined, which is a call to input_sync() at the end >>>> of the whole packet. The SYN_MT_ can be replaced by the following >>>> example, which I think is more "client-friendly". This solution is >>>> based on the fact that the major difference between type A and type B >>>> is whether we need to filter the data or not: >>>> >>>> ABS_MT_RANDOM 0 >>>> ABS_MT_POSITION_X x[0] >>>> ABS_MT_POSITION_Y y[0] >>>> ABS_MT_ RANDOM 1 >>>> ABS_MT_POSITION_X x[1] >>>> ABS_MT_POSITION_Y y[1] >>>> SYN_REPORT >>>> >>>> input_set_abs_params(input_dev, ABS_MT_RANDOM, 0, 2, 0, 0); >>>> >>>> would tell the clients that they can expect two random touches. >>> And if you do s/RANDOM/SLOT/, you end up with what? ;-) >> >> Haha, I know what you are thinking :). >> >> Maybe I didn't make my point clear. �I didn't mean to make SLOT >> backward compatible. �I meant to replace SYN_MT_REPORT event with the >> ABS_MT_ RANDOM label so we only sync the whole packet once at the end. >> This way both types of MT_ data follow the same input event reporting >> flow.... > > You mean changing the type A protocol, breaking the current code base? That is a > big no-no. Hi Henrik, I saw your new patchset, very much appreciated. There are reasons that I am not "attacking" your new patches: 1. I don't want to ruin your hard work; 2. It would be easier for others to understand what I am talking about along this thread. I came up with another "crazy" idea which doesn't break the existing type A protocol/code. We leave the existing code as is. However, we make the new SLOT format support both type A and type B. This unified approach offers a benefit for future X driver and client developers to treat both types the same way. As we've discussed before, the major difference between type A and type B is the filtering and tracking mechanism. Filtering is tied to the tracking ID since we do not apply filter to the untracked touch poinsts. From this point of view, ABS_MT_SLOT doesn't lead to the filter. The existence of an unique tracking ID triggers the filter. Pure type A format (no filter applied): ABS_MT_SLOT 0 ABS_MT_POSITION_X x[0] ABS_MT_POSITION_Y y[0] ABS_MT_ SLOT 1 ABS_MT_POSITION_X x[1] ABS_MT_POSITION_Y y[1] SYN_REPORT Pure type B format (filter applied upon the detection of a tracking ID) ABS_MT_SLOT 0 ABS_MT_TRACKING_ID 45 ABS_MT_POSITION_X x[0] ABS_MT_POSITION_Y y[0] ABS_MT_SLOT 1 ABS_MT_TRACKING_ID 46 ABS_MT_POSITION_X x[1] ABS_MT_POSITION_Y y[1] SYN_REPORT Hybrid format (filter applied only when a tracking ID is detected): ABS_MT_SLOT 0 ABS_MT_POSITION_X x[0] ABS_MT_POSITION_Y y[0] ABS_MT_SLOT 1 ABS_MT_TRACKING_ID 46 ABS_MT_POSITION_X x[1] ABS_MT_POSITION_Y y[1] ABS_MT_SLOT 2 ABS_MT_TRACKING_ID 20 ABS_MT_POSITION_X x[2] ABS_MT_POSITION_Y y[2] SYN_REPORT So, one protocol covers both cases for the future. Ping -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |