On Tue, Mar 8, 2011 at 10:14, Henrik Rydberg <rydberg@xxxxxxxxxxx> wrote:
>> >> struct mt_slot {
>> >> __s32 x, y, p, w, h;
>> >> @@ -63,6 +64,9 @@ struct mt_class {
>> >> __s32 sn_move; /* Signal/noise ratio for move events */
>> >> __s32 sn_pressure; /* Signal/noise ratio for pressure events */
>> >> __u8 maxcontacts;
>> >> + __u8 override_logical_limits; /* correct the reported X/Y range */
>> >> + __u32 logical_min[2];
>> >> + __u32 logical_max[2];
>> >
>> > Please think about byte alignment here, keeping elements of the same
>> > size together. Also, the override needs a specific name, given that it
>> > applies to the whole class, not just the x and y positions. Perhaps
>> > the override should be triggered with a quirk instead?
>>
>> I'm not in favor of a quirk in this particular case: the information
>> is already here: max > 0.
>
> Only if min == 0, which is far from always the case. And setting a
> special value for a special hardware does what a quirk does, so maybe
> it is a quirk after all.
>
I think there is a misunderstanding:
if the class provides max_x (so > 0), or min_x, that means that the
person in charge of adding the driver wants to replace the two values
min/max.
No need for a quirk that will be redundant with the hand-provided values.
It won't change anything to other devices as they do not provide min/max.
Cheers,
Benjamin
--
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
