On 04/01/2011 01:25 PM, Joonyoung Shim wrote:
> On 2011-04-01 ìí 6:58, Iiro Valkonen wrote:
>> Hi,
>>
>> On 04/01/2011 09:10 AM, Joonyoung Shim wrote:
>>>>> @@ -837,6 +847,17 @@ static int mxt_initialize(struct mxt_data *data)
>>>>> return 0;
>>>>> }
>>>>>
>>>>> +static void mxt_calc_resolution(struct mxt_data *data)
>>>>> +{
>>>>> + if (data->pdata->orient& MXT_XY_SWITCH) {
>>>>> + data->x_size = data->pdata->y_size;
>>>>> + data->y_size = data->pdata->x_size;
>>>>> + } else {
>>>>> + data->x_size = data->pdata->x_size;
>>>>> + data->y_size = data->pdata->y_size;
>>>>> + }
>>>>> +}
>>>>> +
>>>>
>>>> What's the reason for this? If we have set the x/y switch in the config, then
>>>> we probably want to swap the axes. Or is this axis swap something that should be
>>>> done on upper layers? Even so, then we shouldn't have the MXT_XY_SWITCH bit set
>>>> in the config, and we could just say "data->x_max_value = data->pdata->xsize - 1"
>>>> (and same for y) in the probe function. We wouldn't need Touch orient bit defines
>>>> either.
>>>>
>>>
>>> If we set XY_SWITCH for special purpose then the axis is swapped and
>>> driver will report also coordinates out of max value.
>>>
>>
>> Right, of course.
>>
>
> I mean it is the reason to add above codes, i think driver should
> consider a case MXT_XY_SWITCH is setted.
Yes, I agree, the above code is fine. I was thinking that the x & y resolution
would also get swapped. But that's not the case, and this mxt_calc_resolution
function is correct the way you originally wrote it.
BR,
--
Iiro
--
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
