Canonical Posts X.Org, Driver Patches For XMir

[synaptix]

Why shouldn't they? They accepted patches for Wayland so the only excuse for not accepting this (when they are fully done and polished) would be that they are dickheads but I don't think so.

Wayland is for the entire Linux community, 100% progression for Linux. Almost all of the major distros (except Ubuntu) and DE's support Wayland.

Mir is for Ubuntu/Unity, fragmentation and reverse progression for Linux. The only ones supporting Mir is Canonical.

[LinuxGamer]

Wayland is for the entire Linux community, 100% progression for Linux. Almost all of the major distros (except Ubuntu) and DE's support Wayland.

Mir is for Ubuntu/Unity, fragmentation and reverse progression for Linux. The only ones supporting Mir is Canonical.

i say we port Unity to Wayland

[mrugiero]

I don't get why they need XMir support in individual drivers in the first place. If Xmir is a layer on top of Mir, isn't Mir supposed to do all the hardware stuff? Or is there some kind of handover between Mir's drivers and the corresponding traditional X drivers? And if so, what on earth is Mir actually doing when the desktop is running under Xmir? I'd assumed they were at least exercising some of the hardware-management code paths, but this looks like Xmir is doing most of that stuff still...

DDX drivers are very specific to X.org, IIRC, and the other option would be writing drivers from scratch, something I don't think they are capable of right now.
That's a concern I have in general with both Wayland and Mir, how will they get 2D acceleration. I don't think glamor is the best approach (this would be the obvious guess, since it uses OpenGL which is exposed by mesa/closed source drivers), since it actually uses 3D operations to emulate 2D, thus wasting 2D capabilities on cards and is actually slower than real 2D in some cases, as when it's compared to SNA for Intel.

i say we port Unity to Wayland

I thought about that, but since I don't use it I don't have too much incentive to do so, specially since this implies learning a lot of things I currently know near to nothing about. Maybe the same archers that maintain Unity on Arch will eventually port it to Wayland.

[dee.]

I thought about that, but since I don't use it I don't have too much incentive to do so, specially since this implies learning a lot of things I currently know near to nothing about. Maybe the same archers that maintain Unity on Arch will eventually port it to Wayland.

That would very likely require a complete fork of Unity, diverging from the original - you could be sure that if such a port were to appear, Canonical would break any compatibility between the two just out of spite, and then you'd have to play catch-up to Canonical's upstream changes if you wanted to maintain compatibility - it's the same problem other DE's would face if they'd decide to support Mir.

For that matter, I don't know why anyone would want to run Unity - it offers nothing special really, there are no applications that only work on Unity that I know of... and you can pretty much emulate the UI by adding a dock and a custom application launcher to your DE of choice. The only possible reason to want to use Unity would be if you wanted to use the "scopes" - but I don't really see why anyone would want that feature enough to go through all that trouble, as it's not really all that popular feature in the first place.

[LinuxGamer]

I thought about that, but since I don't use it I don't have too much incentive to do so, specially since this implies learning a lot of things I currently know near to nothing about. Maybe the same archers that maintain Unity on Arch will eventually port it to Wayland.

its just a recode of Gnome its not that hard to make "Unity" do to 98% of it being Gnome look at what Linux Mint has done using Gnome + we have most of the code base we just need to wait for Gnome to be fully ported to Wayland you don't even need compiz using wayland

[dee.]

its just a recode of Gnome its not that hard to make "Unity" do to 98% of it being Gnome look at what Linux Mint has done using Gnome + we have most of the code base we just need to wait for Gnome to be fully ported to Wayland you don't even need compiz using wayland

Not that easy - Unity 8 (the one that runs natively on Mir) will be rewritten to use Qt instead of GTK and will no longer be GNOME-based. Even the current Unity 7, while it's indeed based on GNOME, the actual UI is dependent of Compiz, which is pretty much a dead project insofar that it no longer has any plans of being ported to Wayland.

Thus, you'd either need to fork Compiz + current Unity and implement Wayland support for Compiz, then rebase the whole thing to GNOME+Wayland (not an easy task either, as GNOME has a bad habit of breaking stuff between point releases) and since the current version of Unity will be end-of-line once Canonical moves to Mir, you'd have to maintain the codebase all by yourself. Or you'd need to rebase the current Unity 7 to use some other compositor, other than Compiz, which supports Wayland. Or, you'd need to take the newer Unity 8 and port it to Wayland, somehow.

Incidentally, Mint/Cinnamon is also moving away from GNOME - Cinnamon 2.0 is supposed to be entirely independent from a GNOME base.

[LinuxGamer]

Not that easy - Unity 8 (the one that runs natively on Mir) will be rewritten to use Qt instead of GTK and will no longer be GNOME-based. Even the current Unity 7, while it's indeed based on GNOME, the actual UI is dependent of Compiz, which is pretty much a dead project insofar that it no longer has any plans of being ported to Wayland.

Thus, you'd either need to fork Compiz + current Unity and implement Wayland support for Compiz, then rebase the whole thing to GNOME+Wayland (not an easy task either, as GNOME has a bad habit of breaking stuff between point releases) and since the current version of Unity will be end-of-line once Canonical moves to Mir, you'd have to maintain the codebase all by yourself. Or you'd need to rebase the current Unity 7 to use some other compositor, other than Compiz, which supports Wayland. Or, you'd need to take the newer Unity 8 and port it to Wayland, somehow.

Incidentally, Mint/Cinnamon is also moving away from GNOME - Cinnamon 2.0 is supposed to be entirely independent from a GNOME base.

i have done a lot of DE work in the pasted given you dont have to use Compiz to make a DE look use like Unity and QT has full support for Wayland so if needed you can change maybe 300 to 2k lines of code to make it work on Wayland i forgot who did it but some one taken Gnome 3 and made a Unity looking DE out of it and just a few days

[jrch2k8]

DDX drivers are very specific to X.org, IIRC, and the other option would be writing drivers from scratch, something I don't think they are capable of right now.
That's a concern I have in general with both Wayland and Mir, how will they get 2D acceleration. I don't think glamor is the best approach (this would be the obvious guess, since it uses OpenGL which is exposed by mesa/closed source drivers), since it actually uses 3D operations to emulate 2D, thus wasting 2D capabilities on cards and is actually slower than real 2D in some cases, as when it's compared to SNA for Intel.

well just a little fix here, no modern GPU have dedicated 2D silicon anymore including intel and they all use 3D silicon to emulate the old 2D silicon.

Exa, Uxa, SNA are just specific acceleration architectures for X.org specific operations done in the 3D engine using specific GPU code while Glamor do the same with a higher level GPU agnostic language aka OpenGL but they all basically uses the 3D engine one way or the other

[mrugiero]

well just a little fix here, no modern GPU have dedicated 2D silicon anymore including intel and they all use 3D silicon to emulate the old 2D silicon.

Exa, Uxa, SNA are just specific acceleration architectures for X.org specific operations done in the 3D engine using specific GPU code while Glamor do the same with a higher level GPU agnostic language aka OpenGL but they all basically uses the 3D engine one way or the other

Well, this releases most of the concern. However, could an API be made for doing such operations more direct for Wayland (and not *in* Wayland, since doing so kind of beats the purpose of Wayland not doing things it shouldn't) and Mir? Something like a 2D aimed OpenGL? Does OpenVG suit this idea?

EDIT: I wanted to add to my previous post that in XMir (or XWayland), since X is the one drawing to the buffer, we need to adapt the drivers to work with the GPU even when running inside of another display server, so you are not crippled to only use software drawing. Kind of forgot the whole point of why to modify the drivers after all, in my previous post.

[jrch2k8]

Well, this releases most of the concern. However, could an API be made for doing such operations more direct for Wayland (and not *in* Wayland, since doing so kind of beats the purpose of Wayland not doing things it shouldn't) and Mir? Something like a 2D aimed OpenGL? Does OpenVG suit this idea?

well wayland is a close to the hardware as you can get without using TGSI or GPU ASM so basically there is no need at all and in the case of XWayland you can probably still use existing methods with a simpleish bypass or simply use your favorite languages like OpenVG, OpenGL, OpenGL ES 1,2,3, Pixman, Cairo, etc.

the point is Wayland is not a Process/Server like Mir is a simple protocol library that actually do nothing except give you a language to initialize the GPU to a workable state after that you can basically manipulate the GPU as you wish with no middleman, so in theory intel could use SNA with XWayland directly like with Xorg.

my only doubt is if Xorg itself allows so and if both Xorg and Wayland can access the GPU in parallel without sync issue, it shouldn't be a problem in theory since XWayland will be rootless but still maybe someone closer to XWayland and Xorg can provide a more deep insight