On Fri, Nov 14, 2008 at 02:52:08PM -0800, Gareth Howlett wrote: > Hi, > > I've been tasked to get a USB touch screen working on DirectFB (1.20 > using the patches and adapted build process from DFPorting of Mozilla > (https://wiki.mozilla.org/Mobile/DFBPorting)). The main > implementation issue was proper scaling and offset. > > I've done some research and I've been looking into exactly how the > controller/calibration utility stores it's calibration and offset so I > can modify DirectFB behavior w/o having to recompile for each separate > controller/screen. It looks like there's no rhyme or reason to the > storage of parameters on the controller itself (file-based instead). > EVIOCGABS returns some useful but mostly incomplete data for this > particular controller. If I'm reading the code right, almost any > USB-based touch screen will be supported by the Linux event API and in > turn the DFB Input Driver "linux_input". I'm not 100% certain of how to > discriminate between a joystick and touch screen yet but anything which > gives absolute values will need to be scaled.
I'm not sure if anyone has thought about using linux_input with touchscreen devices. It does support touchpads but obviously the touchscreens need proper calibration. Typically one would use tslib for touchscreens. tslib already provides it's own calibration support. > I've hacked my fixes into abs_event(), but I'm thinking that it would > probably be best to expose these parameters via the directfbrc config > file. Writing a small utility for calibration output giving us the > upper-left/lower-right output to put in the config file. > > Something along these lines: > EVENT_#_OFFSET=25 > EVENT_#_ABS_MIN_X=35 > EVENT_#_ABS_MAX_X=950 > EVENT_#_ABS_MIN_Y=32 > EVENT_#_ABS_MAX_Y=980 AFAICS you should be able to use the EVIOCSABS ioctl to configure the limits in the kernel driver instead of having to add new configuration options to DirectFB. > Obviously the other 1/2 of the scaling is the resolution of the screen, > but that's already exposed via mode=. Getting the screen resolution from the mode= option is not a good idea. > Logically, all five params will > be required along with screen res. > > Thoughts: On-the-fly resolution switching would be a pain, but does > DirectFB even support that? It sure does. The screen size should obviously come from the screen code but that part of DirectFB is a bit thin and there's no support for screen size change notifications at the moment. Adding them shouldn't be difficult though. There's also the issue of multiple layers and layer positions. The device coordinates should probably be scaled to screen coordinates first and then translated/clipped to layer coordinates so that the windowstacks will work properly. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev