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. 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 > [email protected] > http://mailman.laptop.org/mailman/listinfo/devel _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
