If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

The design philosphy behind Wayland is quite similar to SurfaceFlinger. Then the best thing to to ditch Wayland, embrace and leverage the work done by Google and extend it to support a traditional desktop window manager and XSurfaceFlinger to support legacy X apps.

Wayland has a chicken egg problem and convincing Nvidia/ATI to provide drivers for SurfaceFlinger would be much easier than for Wayland.

Comment

The design philosphy behind Wayland is quite similar to SurfaceFlinger. Then the best thing to to ditch Wayland, embrace and leverage the work done by Google and extend it to support a traditional desktop window manager and XSurfaceFlinger to support legacy X apps.

Wayland has a chicken egg problem and convincing Nvidia/ATI to provide drivers for SurfaceFlinger would be much easier than for Wayland.

A great thing about wayland is that it's using existing Linux technologies (eg. KMS, DRI/DRM). SurfaceFlinger however does not. So adapting SurfaceFlinger would probably mean redoing most of the graphics stack, a huge job.

If distributions move to wayland Nvidia and AMD will eventually support it. Supporting Linux is very important due to its' use in HPC.

Comment

The design philosphy behind Wayland is quite similar to SurfaceFlinger. Then the best thing to to ditch Wayland, embrace and leverage the work done by Google and extend it to support a traditional desktop window manager and XSurfaceFlinger to support legacy X apps.

Wayland has a chicken egg problem and convincing Nvidia/ATI to provide drivers for SurfaceFlinger would be much easier than for Wayland.

Regardless of the display server used, it does not change the fact that all desktop Linux applications are written for X and must be ported over to the new server eventually.

That will probably be the toughest thing to handle. And this is where enthusiastic end-users like me who prefer to compile their own applications from sources will be hit, since I have a nagging feeling that compiling said software is no longer as simple as just simply performing

- ./configure
- make
- make install

anymore.

On top of that, I don't see QT5 and its wayland-capable backend being made available for even the most bleeding edge distributions, and while GTK3 has a wayland backend, the amount of software that are still tied to GTK2 is staggering, especially when big name applications like Chromium, Firefox, LibreOffice and HexChat are still happily married to GTK2 with little to no progress on GTK3 migration.

Still, at the very least, I dare say Wayland migration with be smoother than a SurfaceFlinger migration simply because it makes use of existing Linux technologies and more importantly, work has already been done to bring some degree of Wayland support to existing toolkits.

Comment

The design philosphy behind Wayland is quite similar to SurfaceFlinger. Then the best thing to to ditch Wayland, embrace and leverage the work done by Google and extend it to support a traditional desktop window manager and XSurfaceFlinger to support legacy X apps.

Wayland has a chicken egg problem and convincing Nvidia/ATI to provide drivers for SurfaceFlinger would be much easier than for Wayland.

Wayland is currently supported by zero blob drivers. Only mesa kinda supports it somehow. SurfaceFlinger is supported by most, if not all of the SoC blobs, including nVidia (tegra).

Requiring GPU makers to support SurfaceFlinger means also supporting android. AMD is probably the only one who doesn't currently offer a driver for SF, obviously GeForce drivers aren't yet supported also, but at least some of the work is already done on nVidia's side.

There are zero apps that currently run on wayland. Some may have been ported, but currently only use X backend, while there are thousends of apps already using SF, regardless of being fart apps.

Finally, by using SF I think it would be even easier to support android apps. I know this is not what canonical is officially promoting, but I guess I would be dead easy for someone to port dalvik to ubuntu and enable all android apps in this platform.

So SF is much more tested, more properly supported, more stable. The choice seems like a no-brainer to me. Maybe someone can enlighten us about the technical merits of each one...

The missing piece of the puzzle seems to be the support legacy X apps. Maybe what canonical meant by it's own display server is a bastard son of SF and X, capable of running X apps. Time will tell, but seems to be at least a 13.10 affair...

Comment

So SF is much more tested, more properly supported, more stable. The choice seems like a no-brainer to me. Maybe someone can enlighten us about the technical merits of each one...

I'm going to hazard a guess that SF won't be adopted for the following reasons:

- the 'not invented here' syndrome
- the need to redo the entire Linux graphics stack
- the amount of work already done to bring Wayland and Weston up to a major recent public release
- the amount of work put into QT and GTK3 into supporting a Wayland backend.

That said, Im no dev, so i'll just reiterate my point: whatever display server the devs choose to bless as the de facto, just make sure it works (applications, OSS drivers, blob drivers, toolkits, compilers, etc), get EVERYBODY to adopt it and stop flirting around toying with alternatives once a decision is made.

Comment

Disappointing, since it means they won't put any effort in advancing Wayland on mobile.

The problem is Linux was getting no where on mobile device due to the lack of driver support. Most support Android and are restrictive if approached for datasheets or what ever. Canonical had to bite a bullet and adopt some of Android's core so as to access the drivers and support chain. These areas will continue to be improved and updated.

Consider the amount of different devices out there from China and mainstream that would need dedicated works just to get ported. Canonical wants success now. The problem is how to get existing software to work that maybe looking for a different windowing method. Solutions...Containers? Library distinctions?

I'm planning to give the development thingy a go but QTCreator isn't working so well with the addins for device app building.

What I'm surprised at is that on day 1 there has been zero patches or updates. You'd think there would be tons of activity for the release. Maybe I'll see what happens tomorrow. Maybe they were all on IRC channel helping people install.

Comment

I'm going to hazard a guess that SF won't be adopted for the following reasons:

- the 'not invented here' syndrome
- the need to redo the entire Linux graphics stack
- the amount of work already done to bring Wayland and Weston up to a major recent public release
- the amount of work put into QT and GTK3 into supporting a Wayland backend.

That said, Im no dev, so i'll just reiterate my point: whatever display server the devs choose to bless as the de facto, just make sure it works (applications, OSS drivers, blob drivers, toolkits, compilers, etc), get EVERYBODY to adopt it and stop flirting around toying with alternatives once a decision is made.

Too easy, and too quick.

Pains of birth are ahead of us. Our wishes will not shorten it

In practical terms:
X11 protocol IS BAD.
X server IS BAD BAD BAD.

Getting rid of its is CERTAIN.

Now we need to make sure that we do not choose BAD over BAD. And that take time (and prototypes, and trails, and experiments, and imput from various stakeholders, and ...)
So time it will take.

(On a good note, every Xserver dev is quite motivated to make a switch! Working on Xorg code have something to do with it )

Comment

X11 has had how long to be lean mean graphics machine? SurfaceFlinger and QT's mobile graphics server have little amount of time out there and are on many phones and set top boxes. X11? nothing, it's developers missed to the train a long time ago to make a friendly graphics layer. I cringe everytime I have to delve into the X11 config directories and swim past prehistoric files for xcalc or something. Give us blob and OSS drivers to throw at the kernel, and load <your favorite graphics server here> that writes to it, whether on my phone, laptop, server, or SoC.

Comment

X11 has had how long to be lean mean graphics machine? SurfaceFlinger and QT's mobile graphics server have little amount of time out there and are on many phones and set top boxes. X11? nothing, it's developers missed to the train a long time ago to make a friendly graphics layer. I cringe everytime I have to delve into the X11 config directories and swim past prehistoric files for xcalc or something. Give us blob and OSS drivers to throw at the kernel, and load <your favorite graphics server here> that writes to it, whether on my phone, laptop, server, or SoC.

Are you running a prehistoric version of X11 too? Xorg has been autoconfiguring for some time so there is usually no need to edit config-files. Unless you manually have to apply some quirks to get things working, but another graphics system could have such issues too.

Btw, meego used X11 and the Nokia N9 is very smooth and responsive. Tizen 1.0 uses X11 (I don't know about later versions) and so does Sailfish OS.