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

Reply via email to