Hmm..
configuration will get messy if there are more devices using the
linux_input driver.
Alternatively, you can use the input driver 'divine', which really
accepts events from programs.
i.e. you will encapsulate your driver in a program, and link it against
divine so you can do stuff line
DFBInputEvent event;
event.flags = DIEF_AXISABS | DIEF_FOLLOW | DIEF_MIN | DIEF_MAX;
event.type = DIET_AXISMOTION;
event.axis = DIAI_X;
event.min = xmin;
event.max = xmax;
event.axisabs = x;
divine_send_event( <id>, &event );
event.flags = DIEF_AXISABS | DIEF_MIN | DIEF_MAX;
event.type = DIET_AXISMOTION;
event.axis = DIAI_Y;
event.min = ymin;
event.max = ymax;
event.axisabs = y;
divine_send_event( <id>, &event );
..where DIEF_FOLLOW makes sure the 2 events are treated as 1.
hth
Niels
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'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
>
> Obviously the other 1/2 of the scaling is the resolution of the screen,
> but that's already exposed via mode=. 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?
>
> In the past - this was discussed but it looks like it never made it
> into production builds:
> http://mail.directfb.org/pipermail/directfb-dev/2005-September/000704.html
>
> http://mail.directfb.org/pipermail/directfb-dev/2006-January/001439.html
>
> http://mail.directfb.org/pipermail/directfb-dev/2006-January/001445.html
>
> http://mail.directfb.org/pipermail/directfb-dev/2006-January/001447.html
>
>
> I'm not an expert on touch screen controllers, but I'd suggest that the
> hardware support and/or implementations vary widely in terms of
> calibration storage from model to model/company to company. It's
> probably a nightmare to support, but generic, event-level support for
> scaling and offset should be implemented and the DirectFB level is
> better then the application level as it would require a lot more coding
> to implement properly on the application level (simply consider a GTK+
> app which does it's own pointer movement/event correction).
>
> I'll be working this into a patch which will work for my particular
> controller at the very least, so I might as well make it generic if I
> can.
>
> Any thoughts/comments?
>
> Cheers,
>
> Gareth Howlett
> Software Engineer, Sea Tel Products
> Cobham SATCOM
> Marine Systems
>
>
> (çy E-mail and any files transmitted with it (E-mail) is intended solely
> for the addressee(s) and may contain confidential and/or legally
> privileged information. If you are not the addressee(s), any disclosure,
> reproduction, copying, distribution or other use of this E-mail is
> prohibited. If you received this E-mail in error please delete it and
> notify the sender immediately via our switchboard at 01.925.798.7979 or
> via return E-mail.
> Neither the company, nor any individual sending this E-mail accepts any
> liability in respect of the content (including errors and omissions) and
> timeliness of this E-mail which arise as a result of this transmission.
> If verification is required, please request a hard copy version.
> This email was scanned by Postini, the leading provider in Managed Email
> Security. For more information visit
> www.groveis.com
>
> _______________________________________________
> directfb-dev mailing list
> directfb-dev@directfb.org
> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
>
--
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
