Re: Controlling the Glide/Pressure sensor
I've got my hands on a B2 machine, and finally got around to giving this a go. When I boot into the firmware tests and get to the tablet test, it doesn't seem to detect anything at all except in the center third (the capactive area). Does this mean that the firmware in this machine doesn't support the pressure tablet at all? On 1/14/08, Wade Brainerd [EMAIL PROTECTED] wrote: You can watch the output of the PT by downloading and compiling evtest: wget http://david.woodhou.se/evtest.c gcc -o evtest evtest.c ./evtest /dev/input/event5 0 It's event5 on my XO, you might have to use a different number. Anyway, then drag something around on the PT and watch the output. This is the output from the olpc.c driver in the kernel. So the driver appears to be working, but there is something preventing X (possibly the HAL?) from recognizing the events as mouse movement. I'm not sure whether the driver correctly reports the GS's (quite limited) pressure sensitivity though. If you want to see the raw data, just boot the XO with the left gamepad key held down and run through the firmware tests to the one which tests the tablet, it lets you see both GS and PT input as well as pressure. Best, Wade On Jan 14, 2008 11:29 AM, Patrick Dubroy [EMAIL PROTECTED] wrote: I'm the student Mike mentioned who will be working on this project. Does anyone have any more details on how much low level work needs to be done? I know there will need to be work done to map the input from the tablet to X events. Is the device driver fully functional? I'd appreciate any more details that people could give me. Thanks, Pat -- Patrick Dubroy http://dubroy.com/blog - on programming, usability, and hci On 1/10/08, Mike C. Fletcher [EMAIL PROTECTED] wrote: I have a student who's interested in doing a term project on the UI for the track sensor. I've put together this quick summary. Deadline looms for starting the project, so if people have don't do that or we've already done that feedback, please speak up ASAP. Background: * XO has two different devices, resistive glide-sensor and pressure-sensitive tablet o Both of these are currently showing up as core pointer events in X AFAIK o Changes between pressure and glide-sensor activity have the potential to cause jumps of the cursor (absolute versus relative mode) * There is currently no UI to map the pressure-sensitive tablet's area into a particular area on the screen (nor, AFAIK an API to accomplish the mapping) o Use case: use the entire drawing area to draw into a small area of a drawing in Paint * Activities currently do not have control over the mapping of the area o Use case: in a penmanship course, collect samples of the child's letters in special widget areas within a test, focusing a new area should remap the pen to that area Trackpad UI Design Requirements: * API for configuring the resistive/pressure sensor allowing control of all the major features o Note that there will likely be some X11 hacking here, to get the pointer mapping working * Standard UI controls for redirecting input areas o Standard GTK UI for positioning, and scaling o Standard GTK widget for e.g. handwritten text entry, provide access as a bitmap (or a series of strokes optional) + Allow for capturing all data (full resolution) or just scaled data as configuration option o Intuitive (HIG-compliant) standard mechanisms for controlling the various configuration parameters o A 6 year old should be able to figure out how to direct their drawings, written text and the like into the desired areas o Standard feedback on where the tablet area is bounded on screen when drawing with the tablet * System level (possibly on Sugar's Frame) trigger to bring up the control mechanisms (optional) o Most pen-aware applications will likely use internal logic and the API to determine position and the like, but a general trigger to the functionality should be useful for non-pen-aware activities * Paint Controls o Work with Paint's authors to provide intuitive controls to make using the pen/tablet intuitive within the context of paint Obviously we would need to find a machine to work on to make the project feasible. I'll see if we can repurpose one that's local to the task. Discussions welcome, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder
Re: Controlling the Glide/Pressure sensor
I'm the student Mike mentioned who will be working on this project. Does anyone have any more details on how much low level work needs to be done? I know there will need to be work done to map the input from the tablet to X events. Is the device driver fully functional? I'd appreciate any more details that people could give me. Thanks, Pat -- Patrick Dubroy http://dubroy.com/blog - on programming, usability, and hci On 1/10/08, Mike C. Fletcher [EMAIL PROTECTED] wrote: I have a student who's interested in doing a term project on the UI for the track sensor. I've put together this quick summary. Deadline looms for starting the project, so if people have don't do that or we've already done that feedback, please speak up ASAP. Background: * XO has two different devices, resistive glide-sensor and pressure-sensitive tablet o Both of these are currently showing up as core pointer events in X AFAIK o Changes between pressure and glide-sensor activity have the potential to cause jumps of the cursor (absolute versus relative mode) * There is currently no UI to map the pressure-sensitive tablet's area into a particular area on the screen (nor, AFAIK an API to accomplish the mapping) o Use case: use the entire drawing area to draw into a small area of a drawing in Paint * Activities currently do not have control over the mapping of the area o Use case: in a penmanship course, collect samples of the child's letters in special widget areas within a test, focusing a new area should remap the pen to that area Trackpad UI Design Requirements: * API for configuring the resistive/pressure sensor allowing control of all the major features o Note that there will likely be some X11 hacking here, to get the pointer mapping working * Standard UI controls for redirecting input areas o Standard GTK UI for positioning, and scaling o Standard GTK widget for e.g. handwritten text entry, provide access as a bitmap (or a series of strokes optional) + Allow for capturing all data (full resolution) or just scaled data as configuration option o Intuitive (HIG-compliant) standard mechanisms for controlling the various configuration parameters o A 6 year old should be able to figure out how to direct their drawings, written text and the like into the desired areas o Standard feedback on where the tablet area is bounded on screen when drawing with the tablet * System level (possibly on Sugar's Frame) trigger to bring up the control mechanisms (optional) o Most pen-aware applications will likely use internal logic and the API to determine position and the like, but a general trigger to the functionality should be useful for non-pen-aware activities * Paint Controls o Work with Paint's authors to provide intuitive controls to make using the pen/tablet intuitive within the context of paint Obviously we would need to find a machine to work on to make the project feasible. I'll see if we can repurpose one that's local to the task. Discussions welcome, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Controlling the Glide/Pressure sensor
You can watch the output of the PT by downloading and compiling evtest: wget http://david.woodhou.se/evtest.c gcc -o evtest evtest.c ./evtest /dev/input/event5 0 It's event5 on my XO, you might have to use a different number. Anyway, then drag something around on the PT and watch the output. This is the output from the olpc.c driver in the kernel. So the driver appears to be working, but there is something preventing X (possibly the HAL?) from recognizing the events as mouse movement. I'm not sure whether the driver correctly reports the GS's (quite limited) pressure sensitivity though. If you want to see the raw data, just boot the XO with the left gamepad key held down and run through the firmware tests to the one which tests the tablet, it lets you see both GS and PT input as well as pressure. Best, Wade On Jan 14, 2008 11:29 AM, Patrick Dubroy [EMAIL PROTECTED] wrote: I'm the student Mike mentioned who will be working on this project. Does anyone have any more details on how much low level work needs to be done? I know there will need to be work done to map the input from the tablet to X events. Is the device driver fully functional? I'd appreciate any more details that people could give me. Thanks, Pat -- Patrick Dubroy http://dubroy.com/blog - on programming, usability, and hci On 1/10/08, Mike C. Fletcher [EMAIL PROTECTED] wrote: I have a student who's interested in doing a term project on the UI for the track sensor. I've put together this quick summary. Deadline looms for starting the project, so if people have don't do that or we've already done that feedback, please speak up ASAP. Background: * XO has two different devices, resistive glide-sensor and pressure-sensitive tablet o Both of these are currently showing up as core pointer events in X AFAIK o Changes between pressure and glide-sensor activity have the potential to cause jumps of the cursor (absolute versus relative mode) * There is currently no UI to map the pressure-sensitive tablet's area into a particular area on the screen (nor, AFAIK an API to accomplish the mapping) o Use case: use the entire drawing area to draw into a small area of a drawing in Paint * Activities currently do not have control over the mapping of the area o Use case: in a penmanship course, collect samples of the child's letters in special widget areas within a test, focusing a new area should remap the pen to that area Trackpad UI Design Requirements: * API for configuring the resistive/pressure sensor allowing control of all the major features o Note that there will likely be some X11 hacking here, to get the pointer mapping working * Standard UI controls for redirecting input areas o Standard GTK UI for positioning, and scaling o Standard GTK widget for e.g. handwritten text entry, provide access as a bitmap (or a series of strokes optional) + Allow for capturing all data (full resolution) or just scaled data as configuration option o Intuitive (HIG-compliant) standard mechanisms for controlling the various configuration parameters o A 6 year old should be able to figure out how to direct their drawings, written text and the like into the desired areas o Standard feedback on where the tablet area is bounded on screen when drawing with the tablet * System level (possibly on Sugar's Frame) trigger to bring up the control mechanisms (optional) o Most pen-aware applications will likely use internal logic and the API to determine position and the like, but a general trigger to the functionality should be useful for non-pen-aware activities * Paint Controls o Work with Paint's authors to provide intuitive controls to make using the pen/tablet intuitive within the context of paint Obviously we would need to find a machine to work on to make the project feasible. I'll see if we can repurpose one that's local to the task. Discussions welcome, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Controlling the Glide/Pressure sensor
I have a student who's interested in doing a term project on the UI for the track sensor. I've put together this quick summary. Deadline looms for starting the project, so if people have don't do that or we've already done that feedback, please speak up ASAP. Background: * XO has two different devices, resistive glide-sensor and pressure-sensitive tablet o Both of these are currently showing up as core pointer events in X AFAIK o Changes between pressure and glide-sensor activity have the potential to cause jumps of the cursor (absolute versus relative mode) * There is currently no UI to map the pressure-sensitive tablet's area into a particular area on the screen (nor, AFAIK an API to accomplish the mapping) o Use case: use the entire drawing area to draw into a small area of a drawing in Paint * Activities currently do not have control over the mapping of the area o Use case: in a penmanship course, collect samples of the child's letters in special widget areas within a test, focusing a new area should remap the pen to that area Trackpad UI Design Requirements: * API for configuring the resistive/pressure sensor allowing control of all the major features o Note that there will likely be some X11 hacking here, to get the pointer mapping working * Standard UI controls for redirecting input areas o Standard GTK UI for positioning, and scaling o Standard GTK widget for e.g. handwritten text entry, provide access as a bitmap (or a series of strokes optional) + Allow for capturing all data (full resolution) or just scaled data as configuration option o Intuitive (HIG-compliant) standard mechanisms for controlling the various configuration parameters o A 6 year old should be able to figure out how to direct their drawings, written text and the like into the desired areas o Standard feedback on where the tablet area is bounded on screen when drawing with the tablet * System level (possibly on Sugar's Frame) trigger to bring up the control mechanisms (optional) o Most pen-aware applications will likely use internal logic and the API to determine position and the like, but a general trigger to the functionality should be useful for non-pen-aware activities * Paint Controls o Work with Paint's authors to provide intuitive controls to make using the pen/tablet intuitive within the context of paint Obviously we would need to find a machine to work on to make the project feasible. I'll see if we can repurpose one that's local to the task. Discussions welcome, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Controlling the Glide/Pressure sensor
On Jan 10, 2008, at 16:46 , Mike C. Fletcher wrote: I have a student who's interested in doing a term project on the UI for the track sensor. A year ago we discussed a design that would naturally integrate the finger (GS) and stylus (PT) operation. It would not require any special UI and could be the default for activities that do not have particular provisions for the pressure sensor. See this thread: http://lists.laptop.org/pipermail/devel/2007-March/004090.html Nothing has happened since then AFAICT, the last time the tablet was enabled we did not even get up/down events. That's why PT is disabled in current builds (only GS works). Great someone is finally taking this on! - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Controlling the Glide/Pressure sensor
We put a lot of thought into how this might work for the Paint activity in particular, which seems like it would be a prime example for it's use in an arbitrarily large space. Special care was taken to minimize the extent to which one would have to switch between stylus and finger while drawing. Naturally, designs for activities like chat, or handwriting, etc. may not depend on the ability to adjust the location of the mapped input region on screen. http://wiki.laptop.org/go/Draw#Tablet_Support - Eben On Jan 10, 2008 11:04 AM, Bert Freudenberg [EMAIL PROTECTED] wrote: On Jan 10, 2008, at 16:46 , Mike C. Fletcher wrote: I have a student who's interested in doing a term project on the UI for the track sensor. A year ago we discussed a design that would naturally integrate the finger (GS) and stylus (PT) operation. It would not require any special UI and could be the default for activities that do not have particular provisions for the pressure sensor. See this thread: http://lists.laptop.org/pipermail/devel/2007-March/004090.html Nothing has happened since then AFAICT, the last time the tablet was enabled we did not even get up/down events. That's why PT is disabled in current builds (only GS works). Great someone is finally taking this on! - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
