[PATCH] Restoring usages used by the pen.

[PATCH] Restoring usages used by the pen.

[Rafi Rubin]

Restoring usages used by the pen.

Signed-off-by: Rafi Rubin <rafi@seas.upenn.edu>
---
 drivers/hid/hid-ntrig.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/hid/hid-ntrig.c b/drivers/hid/hid-ntrig.c
index 75ed9d2..aeab973 100644
--- a/drivers/hid/hid-ntrig.c
+++ b/drivers/hid/hid-ntrig.c
@@ -62,11 +62,15 @@ static int ntrig_input_mapping(struct hid_device *hdev, struct hid_input *hi,

 	case HID_UP_DIGITIZER:
 		switch (usage->hid) {
+
+		/* these are actually used by the pen */
+		case HID_DG_INVERT: /* high when the eraser button is pressed */
+		case HID_DG_ERASER: /* high when the tip and eraser are both pressed */
+		case HID_DG_BARRELSWITCH:  /* doubtful */
+			return 0;
+
 		/* we do not want to map these for now */
-		case HID_DG_INVERT: /* value is always 0 */
-		case HID_DG_ERASER: /* value is always 0 */
 		case HID_DG_CONTACTID: /* value is useless */
-		case HID_DG_BARRELSWITCH:  /* doubtful */
 		case HID_DG_INPUTMODE:
 		case HID_DG_DEVICEINDEX:
 		case HID_DG_CONTACTCOUNT:
@@ -233,6 +237,7 @@ static int ntrig_probe(struct hid_device *hdev, const struct hid_device_id *id)

 	if (ret)
 		kfree (nd);
+
 	return ret;
 }

-- 
1.6.3.1

Re: [PATCH] Restoring usages used by the pen.

[Stéphane Chatty]

Le 17 juin 09 à 04:39, Rafi Rubin a écrit :

> Restoring usages used by the pen.
>
> +
> +		/* these are actually used by the pen */
> +		case HID_DG_INVERT: /* high when the eraser button is pressed */
> +		case HID_DG_ERASER: /* high when the tip and eraser are both  
> pressed */
> +		case HID_DG_BARRELSWITCH:  /* doubtful */
> +			return 0;

I just tested this on my multitouch-enabled Touchsmart tx2 (that is,  
one on which the Windows 7 driver published by NTrig in March 2009  
was installed, which triggered a firmware install).

This is tricky:
  - as one can expect, the multitouch events are still emitted  
properly. Fine.
  - but the Wacom Xorg driver patched by Rafi is not interested in  
the device anymore. I had managed to emit touchscreen-like events for  
the first finger detected on the screen, so as to feed Xorg with  
pointer events. This does not work anymore. This probably has to do  
with the complex rules that have been designed over time to decide  
what type of device should be handled by what driver. I remember  
having to dig deep in the code of hid, input *and* the Wacom driver  
last month to fit in these rules.

TBH, this is not a big loss to me personally, because:
  - so far I had not been able to give the appropriate Xmax and Ymax  
parameters to the Wacom Xorg driver, so the pointer was badly warped  
and this was pretty useless anyway.
  -  at some point we'll probably want the NTrig digitizer to be  
managed by another Xorg driver than the Wacom driver. Peter? Bryan?  
What do you think?

I guess the whole issue is to try and understand what will be the  
most popular uses of this device:
  - with which version of the firmware? the one with stylus and  
single touch? the one with multitouch but no stylus?
  - as a touch screen? as a pen computer?

Leaving aside the pain of having incompatible versions of the  
firmware around, it looks this type of dual device (stylus + finger)  
challenges the way linux-hid, linux-input and Xorg regard touch  
devices: yes, something that looks like a touchscreen can be a  
digitizer too... Maybe we should create two Linux devices, one for  
the stylus and one for fingers?


--
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

Re: [PATCH] Restoring usages used by the pen.

[Mohamed Ikbel Boulabiar]

> Leaving aside the pain of having incompatible versions of the firmware
> around, it looks this type of dual device (stylus + finger) challenges the
> way linux-hid, linux-input and Xorg regard touch devices: yes, something
> that looks like a touchscreen can be a digitizer too... Maybe we should
> create two Linux devices, one for the stylus and one for fingers?


This is another example raising questions about the input system, from
the kernel to Xorg to finally reach applications.

I will write another mail about this later (maybe RFC), but it seems
that some code should be modified in the kernel and input devices
should have an input daemon outside the kernel and not in X, to easily
deal with new devices and new constraints without modifying many
layers of the whole system.

(in this case, we maybe need 2 devices because the constructor
included this as a feature, but if simple users want to add some)

Re: [PATCH] Restoring usages used by the pen.

[Rafi Rubin]

I did in fact submit a patch to linuxwacom a while ago specifically to solve that problem.

Perhaps in the long run a separate driver would be better.  But on the other hand, there is so much that is similar in the way the
devices behave and in the output we'd like from the driver, that it really seems a shame to have to fork or rewrite.


diff -r1.39 wcmUSB.c
510c510,511
< 	{ 0x9A, 2540, 2540, &usbTabletPC   }  /* TabletPC 0x9A */
---
> 	{ 0x9A, 2540, 2540, &usbTabletPC   },  /* TabletPC 0x9A */
> 	{ 0x1, 935, 1122, &usbTabletPC   }  /* TabletPC 0x9A */
529c530
< 	if (sID[1] == 0x056A)
---
> 	if (sID[1] == 0x056A || sID[1] == 0x1b96)
552c553
< 		if (common->tablet_id == 0x9A || common->tablet_id == 0x93 || common->tablet_id == 0x90)
---
> 		if (common->tablet_id == 0x9A || common->tablet_id == 0x93 || common->tablet_id == 0x90 || common->tablet_id==1)


Stéphane Chatty wrote:
> 
> Le 17 juin 09 à 04:39, Rafi Rubin a écrit :
> 
>> Restoring usages used by the pen.
>>
>> +
>> +        /* these are actually used by the pen */
>> +        case HID_DG_INVERT: /* high when the eraser button is pressed */
>> +        case HID_DG_ERASER: /* high when the tip and eraser are both
>> pressed */
>> +        case HID_DG_BARRELSWITCH:  /* doubtful */
>> +            return 0;
> 
> I just tested this on my multitouch-enabled Touchsmart tx2 (that is, one
> on which the Windows 7 driver published by NTrig in March 2009 was
> installed, which triggered a firmware install).
> 
> This is tricky:
>  - as one can expect, the multitouch events are still emitted properly.
> Fine.
>  - but the Wacom Xorg driver patched by Rafi is not interested in the
> device anymore. I had managed to emit touchscreen-like events for the
> first finger detected on the screen, so as to feed Xorg with pointer
> events. This does not work anymore. This probably has to do with the
> complex rules that have been designed over time to decide what type of
> device should be handled by what driver. I remember having to dig deep
> in the code of hid, input *and* the Wacom driver last month to fit in
> these rules.
> 
> TBH, this is not a big loss to me personally, because:
>  - so far I had not been able to give the appropriate Xmax and Ymax
> parameters to the Wacom Xorg driver, so the pointer was badly warped and
> this was pretty useless anyway.
>  -  at some point we'll probably want the NTrig digitizer to be managed
> by another Xorg driver than the Wacom driver. Peter? Bryan? What do you
> think?
> 
> I guess the whole issue is to try and understand what will be the most
> popular uses of this device:
>  - with which version of the firmware? the one with stylus and single
> touch? the one with multitouch but no stylus?
>  - as a touch screen? as a pen computer?
> 
> Leaving aside the pain of having incompatible versions of the firmware
> around, it looks this type of dual device (stylus + finger) challenges
> the way linux-hid, linux-input and Xorg regard touch devices: yes,
> something that looks like a touchscreen can be a digitizer too... Maybe
> we should create two Linux devices, one for the stylus and one for fingers?
> 
> 
> -- 
> 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
> 
--
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

Re: [PATCH] Restoring usages used by the pen.

[Stéphane Chatty]

Le 17 juin 09 à 20:34, Rafi Rubin a écrit :

> I did in fact submit a patch to linuxwacom a while ago specifically  
> to solve that problem.
>

Good!

Then I have a minor suggestion: it would be better to just remove  
these lines. The point of this switch is to catch the values that we  
want to handle in a special way. All others (and that's quite a few)  
just make it through the switch.

St.


--
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

Re: [PATCH] Restoring usages used by the pen.

[Rafi Rubin]

Stéphane Chatty wrote:
> 
> Le 17 juin 09 à 20:34, Rafi Rubin a écrit :
> 
>> I did in fact submit a patch to linuxwacom a while ago specifically to
>> solve that problem.
>>
> 
> Good!
> 
> Then I have a minor suggestion: it would be better to just remove these
> lines. The point of this switch is to catch the values that we want to
> handle in a special way. All others (and that's quite a few) just make
> it through the switch.

Fair enough.  I partly just wanted to document the behavior.  I'll adjust shortly.
--
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

Re: [PATCH] Restoring usages used by the pen.

[Rafi Rubin]

> TBH, this is not a big loss to me personally, because:
>  - so far I had not been able to give the appropriate Xmax and Ymax
> parameters to the Wacom Xorg driver, so the pointer was badly warped and
> this was pretty useless anyway.

Certainly early on, I was not able to get the wacom to accept the the ranges for the touch device, so I just put the values in my
xorg.conf and have not looked back.  I think the limitation was in the userspace driver, not the device or kernel space.  It was
getting the correct parameters for the pen input device.

> I guess the whole issue is to try and understand what will be the most
> popular uses of this device:
>  - with which version of the firmware? the one with stylus and single
> touch? the one with multitouch but no stylus?
>  - as a touch screen? as a pen computer?

It would be really nice if we could get ntrig to weigh in on the firmwares.  At this point we have no way to know what the real
limitations are.  It would be really nice of them to provide a firmware that gives maximal functionality.  Perhaps they ran into
some design flaws which they are still trying to work around.

Anyone out there have any experience extracting firmware from windows drivers?  And if we do get the raw firmware, how do we load it?

> Leaving aside the pain of having incompatible versions of the firmware
> around, it looks this type of dual device (stylus + finger) challenges
> the way linux-hid, linux-input and Xorg regard touch devices: yes,
> something that looks like a touchscreen can be a digitizer too... Maybe
> we should create two Linux devices, one for the stylus and one for fingers?

On the surface, I like the idea of separate devices.  But if we still have to deal with the different fingers in user space, does it
make more sense to just use the same code to differentiate the pen?