Re: 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 <[EMAIL PROTECTED]> 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@laptop.org
http://mailman.laptop.org/mailman/listinfo/devel





_______________________________________________
Devel mailing list
Devel@laptop.org
http://mailman.laptop.org/mailman/listinfo/devel