On 04/01/2011 01:25 PM, Joonyoung Shim wrote:

On 2011-04-01 오후 6:58, Iiro Valkonen wrote:

quoted

Hi,

On 04/01/2011 09:10 AM, Joonyoung Shim wrote:

quoted

quoted

quoted

@@ -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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html