Touchpad stylus mode

[Dan Williams]

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.

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