You can watch the output of the PT by downloading and compiling evtest:<br><br>wget <a href="http://david.woodhou.se/evtest.c">http://david.woodhou.se/evtest.c</a><br>gcc -o evtest evtest.c<br>./evtest /dev/input/event5 0<br>

<br>It's event5 on my XO, you might have to use a different number.<br>

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.

<br><br>Best,<br><br>Wade<br><br><div class="gmail_quote">On Jan 14, 2008 11:29 AM, Patrick Dubroy <<a href="mailto:pdubroy@gmail.com">pdubroy@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

I'm the student Mike mentioned who will be working on this project.<br><br>Does anyone have any more details on how much low level work needs to<br>be done? I know there will need to be work done to map the input from

<br>the tablet to X events. Is the device driver fully functional?<br><br>I'd appreciate any more details that people could give me.<br><br>Thanks,<br><br>Pat<br><font color="#888888">--<br>Patrick Dubroy<br><a href="http://dubroy.com/blog" target="_blank">

http://dubroy.com/blog</a> - on programming, usability, and hci<br></font><div><div></div><div class="Wj3C7c"><br>On 1/10/08, Mike C. Fletcher <<a href="mailto:mcfletch@vrplumber.com">mcfletch@vrplumber.com</a>> wrote:

<br>> I have a student who's interested in doing a term project on the UI for<br>> the track sensor.  I've put together this quick summary.  Deadline looms<br>> for starting the project, so if people have "don't do that" or "we've

<br>> already done that" feedback, please speak up ASAP.<br>><br>> Background:<br>><br>>     * XO has two different devices, resistive glide-sensor and<br>>       pressure-sensitive tablet<br>>           o Both of these are currently showing up as "core pointer"

<br>>             events in X AFAIK<br>>           o Changes between pressure and glide-sensor activity have the<br>>             potential to cause "jumps" of the cursor (absolute versus<br>>             relative mode)

<br>>     * There is currently no UI to map the pressure-sensitive tablet's<br>>       area into a particular area on the screen (nor, AFAIK an API to<br>>       accomplish the mapping)<br>>           o Use case: use the entire drawing area to draw into a small

<br>>             area of a drawing in Paint<br>>     * Activities currently do not have control over the mapping of the area<br>>           o Use case: in a penmanship course, collect samples of the<br>>             child's letters in special widget areas within a "test",

<br>>             focusing a new area should remap the pen to that area<br>><br>> Trackpad UI Design Requirements:<br>><br>>     * API for configuring the resistive/pressure sensor allowing control<br>>       of all the major features

<br>>           o Note that there will likely be some X11 hacking here, to get<br>>             the pointer mapping working<br>>     * Standard UI controls for redirecting input areas<br>>           o Standard GTK UI for positioning, and scaling

<br>>           o Standard GTK widget for e.g. handwritten text entry, provide<br>>             access as a bitmap (or a series of strokes optional)<br>>                 + Allow for capturing all data (full resolution) or just

<br>>                   scaled data as configuration option<br>>           o Intuitive (HIG-compliant) standard mechanisms for<br>>             controlling the various configuration parameters<br>>           o A 6 year old should be able to figure out how to direct

<br>>             their drawings, written text and the like into the desired areas<br>>           o Standard feedback on where the tablet area is bounded on<br>>             screen when drawing with the tablet<br>

>     * System level (possibly on Sugar's Frame) trigger to bring up the<br>>       control mechanisms (optional)<br>>           o Most pen-aware applications will likely use internal logic<br>>             and the API to determine position and the like, but a

<br>>             general trigger to the functionality should be useful for<br>>             non-pen-aware activities<br>>     * Paint Controls<br>>           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.

<br>><br>> Discussions welcome,<br>> Mike<br>><br>> --<br>> ________________________________________________<br>>   Mike C. Fletcher<br>>   Designer, VR Plumber, Coder<br>>   <a href="http://www.vrplumber.com" target="_blank">

http://www.vrplumber.com</a><br>>   <a href="http://blog.vrplumber.com" target="_blank">http://blog.vrplumber.com</a><br>><br>><br>_______________________________________________<br>Devel mailing list<br><a href="mailto:Devel@lists.laptop.org">

Devel@lists.laptop.org</a><br><a href="http://lists.laptop.org/listinfo/devel" target="_blank">http://lists.laptop.org/listinfo/devel</a><br></div></div></blockquote></div><br>