Touchpad stylus mode

[Bert Freudenberg]

On Mar 18, 2007, at 8:22 , Zephaniah E. Hull wrote:

> On Sat, Mar 17, 2007 at 11:16:36PM -0400, Albert Cahalan wrote:
>> On 3/17/07, Zephaniah E. Hull <warp at aehallh.com> wrote:
>>> On Sat, Mar 17, 2007 at 09:08:30PM -0400, Albert Cahalan wrote:
>>>> Bert Freudenberg and Jim Gettys had the right idea on March 7th.
>>>> It goes something like this:
>>>>
>>>> a. Mode switches do not move the pointer.
>>>
>>> Mode switches themselves do not move the pointer, however the  
>>> only way
>>> to trigger a GS to PT switch is to put a stylus on the unit,  
>>> immediately
>>> after switching to PT mode we get coordinate data for the stylus,  
>>> which
>>> does cause the pointer to move.
>>
>> So, from the user's view, mode switches DO move the pointer.
>> That is generally defective as a user interface.
>
> It is also the nature of a absolute device in X for there to be a 1:1
> mapping between a point on the touchpad, and a point on the screen.

Yes, and this is something we need to change. The pen tablet cannot  
be absolute because it does not cover the whole screen without  
distortion. It cannot be relative either because that would defeat  
its original purpose, namely being able to write and draw.

What Jim and me were proposing was a hybrid absolute/relative mode  
for the pen data, as Albert tried to explain below.

>> BTW, I'd rather you didn't use "GS" and "PT", especially without
>> explaining them. I can deal with resistive/capacitive I think, if
>> I'm right that the middle thing is capacitive.
>
> Sorry about that, I can't keep resistive/capacitive straight in my  
> head,
> and all the documentation from ALPS refers to it as the GS and the PT,
> GS being the Glide Sensor (for use with a finger), and PT being the  
> Pen
> Tablet (for use with a stylus).

Thanks - this is the first explanation of the terms I saw. Would be  
nice to stick to some consistent terminology. In user-speak, finger- 
touch vs. stylus-draw is the important distinction, capacitive/ 
resistive is to techy. But I'm no native speaker so someone should  
propose the terms. The HIG is not consistent in itself, maybe finger- 
mode and stylus-mode would fit it:

http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/ 
The_Sugar_Interface/Input_Systems#Trackpad

>> The stylus device is not shaped properly to cover the whole screen.
>> Distortion would be very bad. Cropping it would work OK, but would
>> waste 2/3 of the device. Unless you have some fantastic new idea,
>> the stylus device's screen mapping needs to be able to move.
>
> Agreed, however as previously mentioned in this thread, this requires
> XInput protocol changes which are still in the X.org git tree.  Along
> with xf86-input-evdev changes.
>>
>> Mode switches can be disorienting and surprising. There are a
>> number of things that can be done to deal with that:
>>
>> Upon mode switch to stylus mode, one might draw an outline of
>> the stylus device on the screen.
>
> An outline of the stylus drawing area would be useful, however that is
> the wrong point to draw it, IMHO.

No, it would be the perfect time to draw it, because it then outlines  
the area the your tablet will be mapped to. Instead of an outline I'd  
imagine a half-transparent gray overlay with a clear window  
indicating the stylus area, but that may be too expensive performance- 
wise.

>> Preventing sudden pointer movement on mode switch is critical.
>> To the raw stylus data, subtract the initial (post-mode-switch)
>> stylus data and add the pre-mode-switch screen location.
>
> That roughly describes how we use the GS as a relative device, it is
> useful for moving the cursor around for use on menus, however the PT
> sensor is there for use with drawing, that _absolutely_ requires that
> there be jumps when you lift the stylus and move it to another  
> point on
> the touchpad.
>
> Please keep in mind, the GS sensor is not usable at all while in PT
> mode, and the only indication that we have that we may wish to go back
> to GS mode is the device indicating that there is no longer a stylus
> touching the touchpad.  Thus, every lift and move to another  
> position is
> going to involve a mode switch to GS, then a mode switch to PT.

That may be the case in the low-level driver. But in a higher-level  
view, the mode switch should be exactly when there is a movement in  
the touchpad, not earlier. This is also the time when the tablet  
outline gets erased, so it's very easy to tell in which mode you are.

> Thus, according to everything I know about how absolute devices are
> used, you very strongly want a jump when you put the stylus down on  
> the
> unit, it's pretty much the definition of what an absolute device is.

As noted above, we cannot use the tablet as totally absolute device.  
It is absolute while in tablet mode, but its offset is set when  
entering tablet mode. The offset is chosen so that no pointer  
movement will be introduced by the mode switch, the tablet outline  
will be placed accordingly.

Is there a way currently to not map the tablet to the X core pointer  
but make it available as an Xinput device? So we could try how this  
scheme would feel?

> Now, what I would suggest is either a button on the keyboard, or
> something accessable through the frame, to bring up an outline of  
> the PT
> area, and cause the GS input to move that outline around.  The support
> for this is not all there, however I really do believe that this is
> going to be the optimal route if we do not wish to stretch the PT over
> the whole screen.
>
> The protocol support for moving the area around is in the X.org git
> tree, however at the moment nothing ties into it.

This is all good except for "cause the GS input to move that outline  
around". Since you cannot know in advance where the first tablet  
event will be, it is impossible to move the tablet area around with  
the touchpad in advance.

You have to imagine how this will be used. What I was aiming at is  
that it becomes possible to do pixel-perfect drawing. Like, say there  
are two dots on the screen that I want to connect by drawing with the  
stylus. In the scheme I am proposing, you would move the pointer with  
the finger to the first dot, and then use the pen to draw the line. I  
cannot imagine how this should work as precisely when you move the  
tablet area around first to be somewhere around the first dot, and  
then try to hit the tablet at the exact spot that is mapped to the  
dot. Sounds next to impossible to me.

Also, my proposal would not even need any other button or key,  
switching into and out of tablet mode is as simple as using your  
finger to move the pointer.

We have a unique situation here, which requires a unique solution.  
Other absolute input devices do have absolute feedback - they are  
either located exactly on the display, or they have a "hover" mode  
that is distinguishable from the "pen-down" mode. We don't have that,  
so we need to come up with something that works under our specific  
circumstances. Or maybe there is some device out there with similar  
needs that we are not aware of? Maybe this has been solved already.

- Bert -