Re: [MeeGo-dev] which compositer will meego use for wayland?
On Tue, Jul 5, 2011 at 1:28 AM, 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. 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 >> wrote: >> > On Thu, Jun 30, 2011 at 2:41 PM, Thiago Macieira 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] GLES v1/v2 -- compliance
On Wed, Jun 29, 2011 at 11:17 AM, Wichmann, Mats D wrote: > > For the purposes of compliance is only GLESv2 required, or is v1 also > required? > If the latter, we have an issue to figure out in that there seems to be some > variance in library names (the Mesa version is /usr/lib/libGLESv1_CM.so.1 > and the EMGD version is /usr/lib/libGLES_CM.so.1) As per http://www.khronos.org/registry/implementers_guide.html GLES_CM is the GLES1 and EGL entrypoints in on .so, while GLESv1_CM is just the GLES1 API entry points. The GLES_CM library is deprecated for 1.1, and mesa only provides libGLESv1_CM.so. Having said all that, I'm pretty sure that MeeGo compliance only requires GLESv2. 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?
On Thu, Jun 30, 2011 at 10:22 AM, Ville M. Vainio wrote: > On Thu, Jun 30, 2011 at 2:41 PM, Thiago Macieira 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] Added wayland packages to MeeGo
On Sat, Apr 2, 2011 at 1:39 AM, Carsten Munk wrote: > 2011/4/1 Liu, Xinyun : >> Hello, April fools' day. You can try wayland with MeeGo in console mode now. >> >> After login in via console, just type "wayland-test", then you can try other >> wayland apps from wayland-terminal. (/usr/bin/wayland-*) >> >> Q: Any preparation? >> A: Yes. Change to console mode. >> sed -i "s#id:5:initdefault#id:3:initdefault#" /etc/inittab >> >> Q: How to install/run it? >> A: >> a. Install MeeGo[1] with a Intel gfx card. (GenX) >> b. Add the package repo[2] to /etc/zypp/repos.d/wayland.repo >> c. Install related packages: >> zypper in libxkbcommon mesa-libwayland-egl wayland wayland-demos cairo >> libdrm libX11 mesa-dri-i915-driver mesa-libEGL mesa-libGLESv2 pixman >> d. Run wayland-test >> >> Q: Can it use X as the backend? >> A: No. It can do so but there is some bug in my rpm packages. >> >> Q: Any more reference? >> A: http://wayland.freedesktop.org/ >> >> Q: Anything else? >> A: Yes. More packages need to be added, bugs to be fixed, X related packages >> to be cleaned up. The most important is to add devel packages to it. >> But no plan. >> >> [1] MeeGo Image >> http://repo.meego.com/MeeGo/builds/trunk/1.1.99.0.20110330.3/images/meego-netbook-ia32/meego-netbook-ia32-1.1.99.0.20110330.3.img >> >> In fact, I used a smaller image to test wayland, I added zypper, vim and >> created the image with this .ks file >> >> http://repo.meego.com/MeeGo/builds/trunk/1.1.99.0.20110330.3/images/meego-core-ia32-base-nodoc/meego-core-ia32-base-nodoc-1.1.99.0.20110330.3.ks >> >> [2] wayland rpm repo for MeeGo >> http://download.meego.com/live/home:/xyl:/wayland/Trunk/home:xyl:wayland.repo > Hi, > > Thank you for kicking off a good initiative. I think there's many > people and companies interested in this area - maybe we should propose > a devel:wayland project in the MeeGo OBS? It is after all one of the > important directions for MeeGo. > > I guess one of the steps would also be to have Qt Lighthouse packages > there, enabled for Wayland? > > I'd be interested in ARM builds of the packages as well, to experiment > early on on those platforms (probably similar challenges as with PVR > in Intel devices). Hardware enabling is something that has recently come together pretty well. I just post a bit of documentation about the couple of things that Wayland needs here (scroll to the end): http://wayland.freedesktop.org/architecture.html It's still a bit open-ended with respect to how to bring up the compositor on the hardware, but that's technically not Wayland specific, it's something that each EGL stack solves in different, vendor specific ways. 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] Added wayland packages to MeeGo
On Fri, Apr 1, 2011 at 3:38 AM, Liu, Xinyun wrote: > Hello, April fools' day. You can try wayland with MeeGo in console mode now. > > After login in via console, just type "wayland-test", then you can try other > wayland apps from wayland-terminal. (/usr/bin/wayland-*) > > Q: Any preparation? > A: Yes. Change to console mode. > sed -i "s#id:5:initdefault#id:3:initdefault#" /etc/inittab > > Q: How to install/run it? > A: > a. Install MeeGo[1] with a Intel gfx card. (GenX) > b. Add the package repo[2] to /etc/zypp/repos.d/wayland.repo > c. Install related packages: > zypper in libxkbcommon mesa-libwayland-egl wayland wayland-demos cairo libdrm > libX11 mesa-dri-i915-driver mesa-libEGL mesa-libGLESv2 pixman > d. Run wayland-test > > Q: Can it use X as the backend? > A: No. It can do so but there is some bug in my rpm packages. > > Q: Any more reference? > A: http://wayland.freedesktop.org/ > > Q: Anything else? > A: Yes. More packages need to be added, bugs to be fixed, X related packages > to be cleaned up. The most important is to add devel packages to it. > But no plan. This is fantastic, thanks for setting it up. What I'm working on now is to try to move over the tablet UX, bit by bit. I've just started, but the plan is use Qt lighthouse and the QML scenegraph. I'm using the qtquick2-integration branch of the Qt lighthouse repo: git://gitorious.org/+qt-developers/qt/lighthouse.git and the plan is to make meego-ux-daemon the compositor and display server, so the idea is that we can drop X and mcompositor and just fold the compositing functionality into meego-ux-daemon. meego-ux-daemon will use something like the EGL fullscreen lighthouse plugin and evdev input to run directly on KMS. For the clients, we'll have to port meego-qml-launcher to Qt lighthouse and QML scenegraph as well, but the launcher will use the Wayland lighthouse plugin to run as a Wayland client. We'll have to define a MeeGo Tablet UX specific Wayland extension, to replace the ad-hoc use of EWMH in mcompositor and clients. Later on we can look into how to handle classic (non-QML) Qt applications and eventually legacy X clients. Anyway, that's the hand-wavey plan. I expect I'll fork the meego tablet ux repos in question on gitorious once I have something that kinda works. But from a packaging point of view the next step is to figure out how we can package the qtquick2-integration branch of Qt and add it to the Wayland repo. 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] Freedesktop.org specifications and compliance
On Tue, Feb 8, 2011 at 10:55 AM, Thiago Macieira wrote: > Em terça-feira, 8 de fevereiro de 2011, às 07:21:55, Wichmann, Mats D > escreveu: >> meego-dev-boun...@meego.com wrote: >> > Freedesktop.org has some specifications that are relevant to >> > developers: >> > >> > http://www.freedesktop.org/wiki/Specifications >> > >> > Does being MeeGo include a promise to follow some of these >> > specifications, or is it left entirely up to the vendor to implement >> > whatever they deem fit? >> > >> > My primary interest at this point is the autostart spec: >> > http://www.freedesktop.org/wiki/Specifications/autostart-spec >> >> I've been assuming that the ones mentioned in LSB can be >> considered a given (Base Directory, Desktop Entry, Desktop >> Menu, Icon Theme) although it's possible nothing says so >> explicitly. The rest... it sure seems like Autostart >> is being followed, should this and others be added to the >> compliance spec? > > Then we should list the ones that implementations are required to obey, even > if "by reference" and included anyway by the requirement of the packages. > > For example, the Icon Naming Convention, which I'm not sure we're following, > we should be. > > By the way, has XDG fixed the problem of discovering the active icon theme? > > Which in turn reminds me: some of the X-based specs will require a replacement > once we move to Wayland, like XSETTINGS or XDND, whereas others won't make > sense, like NETWM. Wayland has a drag and drop protocol, and I've been thinking that an XSETTINGS-type protocol may make sense. It would be a pretty simple mechanism, but I've been debating whether the functionality needs to be in the display server. There is a considerable overlap with native configuration systems such as gconf or dconf and toolkit themes. Parts of ICCCM/EWMH/NETWM still makes sense - clients still need to communicate window titles, icons, window types and such to the compositor, but we'll only need a subset. Kristian Kristian ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] wayland display server in MeeGo?
On Fri, Nov 5, 2010 at 2:59 PM, Thiago Macieira wrote: > On Thursday, 4 de November de 2010 23:20:28 Arjan van de Ven wrote: >> On 11/4/2010 9:58 PM, Nishanth Menon wrote: >> > Arjan van de Ven wrote, on 11/04/2010 09:39 PM: >> >> On 11/4/2010 9:00 PM, Nishanth Menon wrote: >> >>> Hi Folks, >> >>> Wondering in what way we use Wayland in MeeGo - is this part of the >> >>> plan of MeeGo 1.2? As per [1] we'd potentially be using this? Checking >> >>> google, I came across [3] discussed some time back, but I guess "in >> >>> development" does'nt mean we are planning on using it yet - or did I >> >>> get it wrong? >> >> >> >> Wayland is not on the list for 1.2.. it's not ready enough for that yet. >> >> >> >> It is an interesting technology that we want to adopt when it's ready... >> >> and help mature it as well, but right now it's just not ready yet. >> > >> > Thanks for the clarification. I guess you might have already seen some >> > views such as [1]. >> > >> > [1] http://www.markshuttleworth.com/archives/551 >> >> currently Wayland is mostly done by Intel ... if Mark wants to do a >> serious investment in it as well he's more than welcome... > > I think Wayland and the future of display server on MeeGo is something we > should be discussing on the Unconference Day for the MeeGo Conference in two > weeks. > > I'm not sure the session has been submitted, but count it in already. I'll be there, looking forward to it. Kristian ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
