Hi,
Le 12/10/2011 20:10, Simon Busch a écrit :
On 12.10.2011 10:02, Eric Bénard wrote:
Le 12/10/2011 09:45, Martin Jansa a écrit :
From: Simon Busch<morp...@gravedo.de>
In most cases we don't need tslib in std. configuration as touchscreen
access in most
devices today is done with linux input interface. If some specific
machine has a need for
tslib support it should add the dependency in it's machine layer again
and modify the
profile script accordingly.
When using a resistive touchscreen, tslib is a common solution to handle
calibration and raw value processing : do you think this is a good thing
to remove this ?
Thats up to the environment you are using qt4-embedded in. In my case
the setup is a little bit more complicated. We're using tslib but not
directly in qt4-embedded (we can get rid of tslib completely but time is
missing).
I removed the dependency from qt4-embedded as qt4-embedded in oe-core
should be the general thing used in all environments and therefore
should be only a minimal setup with minimal dependencies.
If someone needs tslib for qt4-embedded for his machine layer he should
include tslib support in the machine layer itself.
removing tslib plugin in qt4e seems not the good solution as this plugin can
be built but not installed by default.
In my opinion that's only the qte.sh script which could be more generic and
maybe could be in its own configuration package so that several machines can
share the same qt4e packages (picking the plugins they need) and have their
own qte-config (for example) package.
Else, why don't you akso remove plugin-gfx-transformed which is not used be
many machines, or plugin-gfx-vnc or plugin-gfx-directfb which is only used on
machine needing directfb or plugin-gfx-qvfb as real machine don't need a
virtual framebuffer or even qt-mouse-pc as you may think that pc with mouses
don't need qtembedded ... in the end we may also notice that basic platforms
can use qt without a display, so why not removing graphic support at all to
make the think even more generic and reduce the number of dependencies ;-)
Eric
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
