[OE-core] [oe-core 1/4] qt4-embedded: remove dependency on tslib and use std. linux input

[Eric Bénard]

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<morphis at 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