Initial XWayland Support Merged For X.Org Server 1.16

[uid313]

Michael describes himself as "not being a journalist", so you can't say it's journalist. He frequently states his opinions in articles and sometimes reports not-worthy news.

See the page title: [Phoronix] Linux Hardware Reviews, Open-Source Benchmarking & Linux Gaming

Nothing talks about news or journalism here...

Well I would expect even a shitty blogger to cite their sources.

[blackout23]

To complete what is said on the mailing list:

. New gbm functions were introduced to Mesa master to export/import a dma-buf fd, so we don't use the ioctl directly (it seems the intel driver doesn't initialize something properly in this case) or use the EGL extension to import dma-buf (which implementation is... not very reliable. A restriction not in the spec is implemented, and a detail in the spec changed recently.). The glamor xwayland backend uses these gbm functions, but then can't be shipped until a Mesa release with the gbm functions. So finally only the software acceleration backend was merged, with a possibility to merge the glamor part before final release if Mesa releases a new version.

. XWayland Present support didn't make it. It needed some rework. Thus when using DRI3, you hit the Present support fallback, which doesn't avoid any copy, thus would not be faster than DRI2. (Note that DRI2 support wasn't added to XWayland by choice). Since Gnome still doesn't bypass scanout for Wayland, benchmarks shouldn't change.

. XWayland is still missing an important feature for games: the ability to restrict the mouse to the window (and still receive relative motion inputs if the mouse is blocked at the border), which makes a lot of games unplayable. This needs an Wayland extension, and even the SDL2 Wayland backend lacks this feature (I think it's the reason the backend isn't enabled by default)

So to what degree is the information here: http://wayland.freedesktop.org/xserver.html

Still relevant? Especially when it comes to building and using Xwayland.

[mannerov]

So to what degree is the information here: http://wayland.freedesktop.org/xserver.html

Still relevant? Especially when it comes to building and using Xwayland.

It's been a long time this link was poorly updated and outdated.

Building xserver master with the xwayland depencies installed (or force --enable-xwayland) will build xwayland with the xserver.
But you need the compositor to have adapted to the recent changes in the way to handle xwayland, so wait the patches for it are merged

[valeriodean]

To complete what is said on the mailing list:

. New gbm functions were introduced to Mesa master to export/import a dma-buf fd, so we don't use the ioctl directly (it seems the intel driver doesn't initialize something properly in this case) or use the EGL extension to import dma-buf (which implementation is... not very reliable. A restriction not in the spec is implemented, and a detail in the spec changed recently.). The glamor xwayland backend uses these gbm functions, but then can't be shipped until a Mesa release with the gbm functions. So finally only the software acceleration backend was merged, with a possibility to merge the glamor part before final release if Mesa releases a new version.

. XWayland Present support didn't make it. It needed some rework. Thus when using DRI3, you hit the Present support fallback, which doesn't avoid any copy, thus would not be faster than DRI2. (Note that DRI2 support wasn't added to XWayland by choice). Since Gnome still doesn't bypass scanout for Wayland, benchmarks shouldn't change.

. XWayland is still missing an important feature for games: the ability to restrict the mouse to the window (and still receive relative motion inputs if the mouse is blocked at the border), which makes a lot of games unplayable. This needs an Wayland extension, and even the SDL2 Wayland backend lacks this feature (I think it's the reason the backend isn't enabled by default)

What about the NVIDIA issue raised after the pubblication of the 1st series?
The recent (even if partially) merged series looks like a rebase + review's comment inclusion than a different approach to sodisfy the NVIDIA needs, or not?

[johnc]

I'm waiting for WaylandX... for running Wayland apps on X.

[rudregues]

I'm waiting for WaylandX... for running Wayland apps on X.

hahhahaha
very funny, indeed!

[MartinN]

I'm waiting for WaylandX... for running Wayland apps on X.

masochist!

[curaga]

I'm waiting for WaylandX... for running Wayland apps on X.

Another way to make infinite loops. Inception.

[pjezek]

Why to comment?

I IMHO do not see any reason to comment this Michael's info. Let developers do their best and let us wait for June news.

[dee.]

while( true )
{

Another way to make infinite loops. Inception.

}