This is something I've actually been thinking of lately. It's so obvious I'm 
sure it's already been discussed and theres a valid reason for it not being 
pursued. However, I'll ask anyway :)

I understand the requirement for the multi-plane graphical chips in a legacy 
situation. However, given the move towards GPU accelerated drawing and 
compositing, is this still a requirement of the TV/STB hardware ? I've CC'd the 
meego-tv list on this question too as I think it's pertinent, especially with 
regard to getting dev boards up and running and not having sufficient drivers 
available for the CE4100 chipset.

Could Wayland+GPU not act as the multi-plane compositor now, composing the 
resulting TV image of the Picture, OSD etc. ?



On 5 Jul 2011, at 06:28, Zhao, Juan J wrote:

> Meego TV platform have a special function--multi plane(multi pipeline).
> On Xorg, we use window manager to support this multi plane function.
> When moving to wayland, I think the compositor is still the best place to 
> support such functionality.
> So I raised this question; want to follow the meego compositer authors and 
> help to add our special functionality into that compositor.
> 
> -----
> *^_^* BRs,
> Juan
> 
> 
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Kristian H?gsberg
>> Sent: Thursday, June 30, 2011 10:46 PM
>> To: Ville M. Vainio
>> Cc: [email protected]
>> Subject: Re: [MeeGo-dev] which compositer will meego use for wayland?
>> 
>> On Thu, Jun 30, 2011 at 10:22 AM, Ville M. Vainio <[email protected]>
>> wrote:
>>> On Thu, Jun 30, 2011 at 2:41 PM, Thiago Macieira <[email protected]> wrote:
>>> 
>>>> It doesn't. I was going to ask steven what reasons he had for using the qt
>>>> compositor. It's just a sample compositor, showing what is possible to do 
>>>> if
>>>> you integrate the wayland libraries into a QML-based application. I've seen
>>>> other experiments doing the same, some of which would definitely never
>> qualify
>>>> for a product.
>>> 
>>> One advantage of using Qt Compositor as starting point would be making
>>> the compositor easy to modify, e.g. for OEM's looking for
>>> differentiated experience at compositor level.
>>> 
>>> If you don't get worse performance with Qt Compositor, is there a good
>>> reason not to use it (as a starting point again, since it's not a
>>> "product" in itself)?
>> 
>> It's not ready yet, and won't be for 1.3.
>> 
>> Kristian
>> _______________________________________________
>> MeeGo-dev mailing list
>> [email protected]
>> http://lists.meego.com/listinfo/meego-dev
>> http://wiki.meego.com/Mailing_list_guidelines
> _______________________________________________
> MeeGo-dev mailing list
> [email protected]
> http://lists.meego.com/listinfo/meego-dev
> http://wiki.meego.com/Mailing_list_guidelines

--
Glen Gray
<[email protected]>




_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines

Reply via email to