DRI3000 (DRI3) Begins To Take Shape Again

[runeks]

^ I think this is correct. The following thread on LWN explains that DRI2 is an X extension that allows application to allocate a buffer in GPU memory while Wayland/Weston just uses DRM to do this.

http://lwn.net/Articles/492670/

[Ericg]

So am I understanding this correctly in that it only applies to Xorg, and not Wayland? Ie. that Wayland has no use for an update to DRI2?

As far as I know, correct. DRI, DRI2 and DRI3(000) are X-protocol extensions. Wayland is not the X-protocol, its the Wayland (or W) Protocol. They may use parts, concepts, maybe even functions from DRI(1-3(000)) but the DRI stack was designed as an X-protocol extensions

[runeks]

So am I understanding this correctly in that it only applies to Xorg, and not Wayland? Ie. that Wayland has no use for an update to DRI2?

[Ericg]

do you think distro can ship xwayland by the end of the year when it gets merged? kde 5 is a long way off.

Hopefully XWayland will get merged into the next Xorg release, hopefully.

[garegin]

XWayland is just a shim-layer that gets created when you have an X Client that cant also be a Wayland Client. It creates an X server the exact size of the window in question and X is tricked into thinking its in charge when in reality Wayland is a puppeteer over head directing things to be how they want and how they SHOULD be in the Wayland world.

Its actually a fairly elegant solution since X clients dont have to change at all and I dont think its in the way of anything in the Wayland world since there's no guarantees that an X Client will be up at any given time. Its basically just an optional code-path that only gets called if an X client somehow appears.


EDIT: Or did you mean "Supporting" as in developer manpower? I doubt it... All the X devs are Wayland devs for the most part, they know Wayland is the future and that updating X is pretty much just a "Here's some work for us to better the community until KDE hits 5.0 and every Qt and KDE program becomes X/Wayland compatible" lol

do you think distro can ship xwayland by the end of the year when it gets merged? kde 5 is a long way off.

[Ericg]

I hope supporting both x and wayland doesn't slow things down. Progress in already at a glacial pace.

XWayland is just a shim-layer that gets created when you have an X Client that cant also be a Wayland Client. It creates an X server the exact size of the window in question and X is tricked into thinking its in charge when in reality Wayland is a puppeteer over head directing things to be how they want and how they SHOULD be in the Wayland world.

Its actually a fairly elegant solution since X clients dont have to change at all and I dont think its in the way of anything in the Wayland world since there's no guarantees that an X Client will be up at any given time. Its basically just an optional code-path that only gets called if an X client somehow appears.


EDIT: Or did you mean "Supporting" as in developer manpower? I doubt it... All the X devs are Wayland devs for the most part, they know Wayland is the future and that updating X is pretty much just a "Here's some work for us to better the community until KDE hits 5.0 and every Qt and KDE program becomes X/Wayland compatible" lol

[garegin]

Kernel-side infrastructure of it, maybe. But not the exact extensions, they can't. The extensions are X specific. Unless you're talking about the XWayland backend, but thats different.

I hope supporting both x and wayland doesn't slow things down. Progress in already at a glacial pace.

[Ericg]

Dri is used with wayland.

Kernel-side infrastructure of it, maybe. But not the exact extensions, they can't. The extensions are X specific. Unless you're talking about the XWayland backend, but thats different.

[garegin]

Dri is used with wayland.

[uid313]

Interesting to see new work being done for X.org even though there is development going on for Wayland.