diff mbox

[2/3] Input: wacom - Provide a range for the ABS_MISC axis

Message ID 1377220537-1474-2-git-send-email-killertofu@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Gerecke, Jason Aug. 23, 2013, 1:15 a.m. UTC
Android marks found axes as 'valid' only if they have a minimum
and maximum value that aren't equal. Since we don't actually
assign any range information for ABS_MISC, Android doesn't bother
to mark it such. This prevents userspace from being able to make
use of tool serial information.

Signed-off-by: Jason Gerecke <killertofu@gmail.com>
---
 drivers/input/tablet/wacom_wac.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

Dmitry Torokhov Aug. 24, 2013, 11:50 p.m. UTC | #1
Hi Jason,

On Thu, Aug 22, 2013 at 06:15:36PM -0700, Jason Gerecke wrote:
> Android marks found axes as 'valid' only if they have a minimum
> and maximum value that aren't equal. Since we don't actually
> assign any range information for ABS_MISC, Android doesn't bother
> to mark it such. This prevents userspace from being able to make
> use of tool serial information.

That should be fixed in Android code. Min/max are filled on best effort
basis and 0/0 is effectively unknown.

Thanks.
Gerecke, Jason Aug. 25, 2013, 5:43 p.m. UTC | #2
On Sat, Aug 24, 2013 at 4:50 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Hi Jason,
>
> On Thu, Aug 22, 2013 at 06:15:36PM -0700, Jason Gerecke wrote:
> > Android marks found axes as 'valid' only if they have a minimum
> > and maximum value that aren't equal. Since we don't actually
> > assign any range information for ABS_MISC, Android doesn't bother
> > to mark it such. This prevents userspace from being able to make
> > use of tool serial information.
>
> That should be fixed in Android code. Min/max are filled on best effort
> basis and 0/0 is effectively unknown.
>
> Thanks.
>
> --
> Dmitry

If userspace is written with the assumption that 0/0 == unknown, then
this patch changes nothing since the consumer will expect any value
between INT_MIN and INT_MAX anyway. Furthermore, if some userspace
program strictly interprets 0/0 to mean "will always be equal to 0",
then this patch actually provides it with the correct range. Either
way, setting the values to INT_MIN and INT_MAX does nothing more than
explicitly state the correct range.

I agree that Google should re-visit the function which does this
"valid" filtering, but I don't see a problem with this patch.

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two,     /
But you can’t take seven from three,    /
So you look at the sixty-fours....
--
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
diff mbox

Patch

diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index 8ccfe91..869e9c9 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -1468,6 +1468,8 @@  static void wacom_abs_set_axis(struct input_dev *input_dev,
 {
 	struct wacom_features *features = &wacom_wac->features;
 
+	input_set_abs_params(input_dev, ABS_MISC, INT_MIN, INT_MAX, 0, 0);
+
 	if (features->device_type == BTN_TOOL_PEN) {
 		input_set_abs_params(input_dev, ABS_X, 0, features->x_max,
 				     features->x_fuzz, 0);