> >> This patch introduce also MT_CLS_DUAL_DEFAULT which has the same purpose
> >> than MT_CLS_DEFAULT, but for dual touch panels.
> >
> > But it is used anywhere?
>
> Hi Henrik,
>
> In it's current form, no. I often rely on it to make a quick patch
> (just adding the ids in hid-ids, hid-core and hid-multitouch) to test
> a new (dual touch) device. I thought it would be useful to be
> mainstream.
I see. However, it is just as easy to keep as a local patch. Quite
generally, there really is a difference between what we do in our
computers and what ends up in mainline, and it is almost always for a
good reason.
> >> @@ -65,10 +66,11 @@ struct mt_class {
> >> };
> >>
> >> /* classes of device behavior */
> >> -#define MT_CLS_DEFAULT 1
> >> -#define MT_CLS_DUAL1 2
> >> -#define MT_CLS_DUAL2 3
> >> -#define MT_CLS_CYPRESS 4
> >> +#define MT_CLS_DEFAULT 1
> >> +#define MT_CLS_DUAL_DEFAULT 2
> >> +#define MT_CLS_DUAL_INRANGE_CONTACTID 3
> >> +#define MT_CLS_DUAL_INRANGE_CONTACTNUMBER 4
> >> +#define MT_CLS_CYPRESS 10
> >
> > There is no need to change the numbering for unchanged names.
>
> I just wanted to keep device-specific at the end of the list. Hence
> the 10 to keep a little space between generic and devices:
> MT_CLS_DUAL_CONFIDENCE_CONTACT* are coming...
It is very often the case that one would like to modify something to
keep to a certain aesthetic classification or idea, but there is a
very good reason not to do it. In order to maintain more than one
branch, for instance a stable tree and several distributions, having
simple patches makes a huge difference in maintenance burden. Not to
mention how hard it can be to merge trees with unrelated changes in
them. So please, keep patches short, sweet and to the point.
Thanks,
Henrik
--
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
