Touchpad stylus mode

[Bert Freudenberg]

On Mar 19, 2007, at 0:59 , Dan Williams wrote:

> On Sun, 2007-03-18 at 17:55 +0100, Bert Freudenberg wrote:
>> 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.
>
> This is essentially the plan we had long ago, but pretty much shelved
> when all the touchpad stuff was being worked out.  I think it's a  
> pretty
> good solution to the X 1:1 problem, the child gets to _see_ onscreen
> where their input will go.  There'd have to be a mechanism to move the
> "input bar" around the screen vertically of course.


*sigh* I'm not getting through to you guys. My point is that it is  
not enough to move the input bar vertically only. It needs to be  
moved both horizontally and vertically to match up the first stylus  
event with the last finger event. Otherwise I can't see how pixel- 
perfect drawing should be possible.

I guess I need to whip up a demo because it is hard to imagine - so  
can I access finger and stylus data separately right now?

- Bert -

> Dan
>
>>>> 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 -
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at laptop.org
>> http://mailman.laptop.org/mailman/listinfo/devel
>