Re: [MeeGo-dev] which compositer will meego use for wayland?
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: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Kristian H?gsberg Sent: Thursday, June 30, 2011 10:46 PM To: Ville M. Vainio Cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] which compositer will meego use for wayland? On Thu, Jun 30, 2011 at 10:22 AM, Ville M. Vainio vivai...@gmail.com wrote: On Thu, Jun 30, 2011 at 2:41 PM, Thiago Macieira thi...@kde.org 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 MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines -- Glen Gray sla...@slaine.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
I understand the requirement for the multi-plane graphical chips in a legacy situation. Why do you say this is one legacy situation? I do believe it will provide better performance than original HW overlay solution for video experience. Could Wayland+GPU not act as the multi-plane compositor now, composing the resulting TV image of the Picture, OSD etc. ? Yes, I also want this answer. And want to get along with it early. I do hope that compositor can work as directFB and will provide such layer functionalities. And how will this work? Can the client set its own plane directly? And I got the information that dri already took this considered. - *^_^* BRs, Juan -Original Message- From: Glen Gray [mailto:sla...@slaine.org] Sent: Tuesday, July 05, 2011 5:50 PM To: Zhao, Juan J Cc: Kristian H?gsberg; meego...@lists.meego.com; Ville M. Vainio; meego-dev list) Subject: Re: [MeeGo-dev] which compositer will meego use for wayland? 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. 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: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Kristian H?gsberg Sent: Thursday, June 30, 2011 10:46 PM To: Ville M. Vainio Cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] which compositer will meego use for wayland? On Thu, Jun 30, 2011 at 10:22 AM, Ville M. Vainio vivai...@gmail.com wrote: On Thu, Jun 30, 2011 at 2:41 PM, Thiago Macieira thi...@kde.org 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 MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines -- Glen Gray sla...@slaine.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
On 5 Jul 2011, at 11:02, Zhao, Juan J wrote: I understand the requirement for the multi-plane graphical chips in a legacy situation. Why do you say this is one legacy situation? I do believe it will provide better performance than original HW overlay solution for video experience. What I meant by a legacy situation was that, historically the chips used in TV and STB products where lower power, didn't have an embedded GPU and so enabled compositing via specialized hardware for multiple planes. So I understand how that situation is around. But to my mind, given the proliferation of mobile embedded CPU and GPU technology and software compositing that runs on these devices, I'm not sure that requirement for specialized multi-plane hardware is relevant anymore. If anything, it's probably becoming an impediment. Could Wayland+GPU not act as the multi-plane compositor now, composing the resulting TV image of the Picture, OSD etc. ? Yes, I also want this answer. And want to get along with it early. I do hope that compositor can work as directFB and will provide such layer functionalities. And how will this work? Can the client set its own plane directly? And I got the information that dri already took this considered. - *^_^* BRs, Juan -Original Message- From: Glen Gray [mailto:sla...@slaine.org] Sent: Tuesday, July 05, 2011 5:50 PM To: Zhao, Juan J Cc: Kristian H?gsberg; meego...@lists.meego.com; Ville M. Vainio; meego-dev list) Subject: Re: [MeeGo-dev] which compositer will meego use for wayland? 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. 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: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Kristian H?gsberg Sent: Thursday, June 30, 2011 10:46 PM To: Ville M. Vainio Cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] which compositer will meego use for wayland? On Thu, Jun 30, 2011 at 10:22 AM, Ville M. Vainio vivai...@gmail.com wrote: On Thu, Jun 30, 2011 at 2:41 PM, Thiago Macieira thi...@kde.org 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 MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines -- Glen Gray sla...@slaine.org -- Glen Gray sla...@slaine.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
On Tue, Jul 5, 2011 at 1:28 AM, Zhao, Juan J juan.j.z...@intel.com 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. The way it works in Wayland is indeed that the compositor manages the display planes. Whether it's just a single yuv overlay (like much desktop graphics hardware has) or a more flexible multi-plane pipeline, the compositor is in charge of the display hardware. The clients will pass their surfaces to the compositor (including yuv buffers), and the compositor will be able to use a combination of gpu rendering and display planes to present the final output. For example, it can choose to present a fullscreen yuv surface using a yuv plane and then composite subtitles, on-screen controls and a wheater applet into a fullscreen argb display plane on top. If the applet and controls go away in the next frame, it can switch to just displaying the subtitle surface as an overlay. Kristian - *^_^* BRs, Juan -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Kristian H?gsberg Sent: Thursday, June 30, 2011 10:46 PM To: Ville M. Vainio Cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] which compositer will meego use for wayland? On Thu, Jun 30, 2011 at 10:22 AM, Ville M. Vainio vivai...@gmail.com wrote: On Thu, Jun 30, 2011 at 2:41 PM, Thiago Macieira thi...@kde.org 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 MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
2011/7/5 Kristian Høgsberg k...@bitplanet.net: On Tue, Jul 5, 2011 at 1:28 AM, Zhao, Juan J juan.j.z...@intel.com 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. The way it works in Wayland is indeed that the compositor manages the display planes. Whether it's just a single yuv overlay (like much desktop graphics hardware has) or a more flexible multi-plane pipeline, the compositor is in charge of the display hardware. The clients will pass their surfaces to the compositor (including yuv buffers), and the compositor will be able to use a combination of gpu rendering and display planes to present the final output. For example, it can choose to present a fullscreen yuv surface using a yuv plane and then composite subtitles, on-screen controls and a wheater applet into a fullscreen argb display plane on top. If the applet and controls go away in the next frame, it can switch to just displaying the subtitle surface as an overlay. Wayland can also handle 3D TV display nicely on STB platforms by either rendering the composited output twice in side-by-side or top-bottom modes, or by using display hardware stereo support - for example using two planes on the CE4100 platform. -- Arnaud Vrac ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
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: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Kristian H?gsberg Sent: Thursday, June 30, 2011 10:46 PM To: Ville M. Vainio Cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] which compositer will meego use for wayland? On Thu, Jun 30, 2011 at 10:22 AM, Ville M. Vainio vivai...@gmail.com wrote: On Thu, Jun 30, 2011 at 2:41 PM, Thiago Macieira thi...@kde.org 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 MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
Zhao, Juan J juan.j.z...@intel.com writes: Hi there, Which wayland-compositer will meego use when moving to wayland? I guess the details you need are in here¹? ¹ http://wiki.meego.com/Wayland_in_MeeGo -- Roger WANG Intel Open Source Technology Center ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
On 06/30/2011 09:50 AM, Zhao, Juan J wrote: Hi there, Which wayland-compositer will meego use when moving to wayland? There is some sort of wrapper in wayland-compositor (meego shell) with a specific protocol interface that we have to shape to accommodate the style of windows that MeeGo UX has. We will glue it with the native clients - meego-ux-daemon and meego-qml-launcher basically. Cheers, Tiago ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
Hi, how about qt-compositor? On Thu, 2011-06-30 at 10:56 +0300, Tiago Vignatti wrote: On 06/30/2011 09:50 AM, Zhao, Juan J wrote: Hi there, Which wayland-compositer will meego use when moving to wayland? There is some sort of wrapper in wayland-compositor (meego shell) with a specific protocol interface that we have to shape to accommodate the style of windows that MeeGo UX has. We will glue it with the native clients - meego-ux-daemon and meego-qml-launcher basically. Cheers, Tiago ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines --- Confidentiality Notice: The information contained in this e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and may be confidential and/or privileged of Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of this communication is not the intended recipient, unauthorized use, forwarding, printing, storing, disclosure or copying is strictly prohibited, and may be unlawful.If you have received this communication in error,please immediately notify the sender by return e-mail, and delete the original message and all copies from your system. Thank you. --- ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
On 06/30/2011 12:43 PM, steven wrote: how about qt-compositor? Because we don't need that much. In principle, we are happy with a single compositor that contains only a very thin layer for MeeGo. Besides, pushing the effort of building a compositor Qt-independent would ease the adoption for other toolkits. For instance, why the whole code inside qt-compositor/hardware_integration has to be inside a *qt* module? In other words: why it always has to be Qt centric? :) Tiago ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
Em Thursday, 30 de June de 2011, às 14:08:37, Tiago Vignatti escreveu: On 06/30/2011 12:43 PM, steven wrote: how about qt-compositor? Because we don't need that much. In principle, we are happy with a single compositor that contains only a very thin layer for MeeGo. Besides, pushing the effort of building a compositor Qt-independent would ease the adoption for other toolkits. For instance, why the whole code inside qt-compositor/hardware_integration has to be inside a *qt* module? In other words: why it always has to be Qt centric? :) 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. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
On Thu, Jun 30, 2011 at 2:41 PM, Thiago Macieira thi...@kde.org 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)? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
On Thu, Jun 30, 2011 at 10:22 AM, Ville M. Vainio vivai...@gmail.com wrote: On Thu, Jun 30, 2011 at 2:41 PM, Thiago Macieira thi...@kde.org 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 MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
Em Thursday, 30 de June de 2011, às 17:22:48, Ville M. Vainio escreveu: 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)? This is a question to be asked to the guys who are doing the compositor. If they feel more comfortable with another codebase, they can do that. I'm not sure how much modification of the compositor is expected though. In any case, if you really want to modify, you can use the Qt Compositor in your own product... -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] which compositer will meego use for wayland?
On Thu, Jun 30, 2011 at 5:54 PM, Thiago Macieira thi...@kde.org wrote: Em Thursday, 30 de June de 2011, às 17:22:48, Ville M. Vainio escreveu: 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)? This is a question to be asked to the guys who are doing the compositor. If they feel more comfortable with another codebase, they can do that. Already got a pretty definitive answer from Kristian ;-). I'm not sure how much modification of the compositor is expected though. In any case, if you really want to modify, you can use the Qt Compositor in your own product... Part of the power of wayland is the fact that rolling your own compositor is doable. I'm sure some OEM's will want to add something extra for their products by altering how compositor works. Having something you plan to hack on as the default starting makes getting started easier, but I don't know how significant the effort is in practice, compared to just swithing to all new composer. It may be a non-issue in the end. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
