Two Features Wayland Will Have That X Doesn't

[movieman]

X.org is only still useful for the internet. An AMD 6800 has a 1GB framebuffer, for which you won't use all of it (not even 1/30) and with a GB LAN port and cables, this is totally neglect-able. You can simply transfer the raw framebuffer image over a gigabyte ethernet cable.

You do realise that:

a) not everyone has gigabit Ethernet?
b) people routinely want to forward GUI apps over broadband which isn't even as fast as 10MB Ethernet?

I was trying xpra last night, which does per-window X-forwarding by running its own X-server on the remote host sending bitmaps over the network, and the difference in latency between that and direct X-forwarding via SSH was very noticeable. Sending big bitmaps around networks is just crazy.

In addition, this all assumes that the server you're running a GUI app from has a video card which can do the rendering; I've been working on a server which only supports the VESA driver and X-forwarding to a workstation which has a decent GPU and a decent driver. It would be even worse if it was a virtualised server with no GPU at all.

Basing your display system on having local rendering hardware to render bitmaps that you'll then send around the network is just crazy.

[Plombo]

The Nvidia employee's comment is misleading

this

anybody know what the Nvidia guy means???

By looking at the contents of that document, he means that window managers shouldn't be forced to use OpenGL for compositing. He seems to be criticizing the design of the Wayland reference implementation (which uses KMS/DRM/EGL/OpenGL).

What he doesn't seem to acknowledge is that Wayland is actually a protocol for display servers to communicate with their clients, and is independent of any specific implementation. In other words, Nvidia wouldn't have to use the Wayland reference implementation - the entire point of defining a formal protocol is to allow others to create compliant implementations that fit their own needs. This means Nvidia could create their own Wayland implementation and composite windows however they want, with or without OpenGL. In fact, the Wayland protocol, by the very nature of a protocol, imposes no restrictions at all on how software implementing it should be designed.

[Nobu]

Isn't it Gb anyway, not GB? I have a hard time imagining whole GB's of information traveling through an Ethernet cable in a second or less. Then again, I haven't sent information through an Ethernet cable that wasn't coming from and/or going to a hard drive, so I may be biased.

[Ragas]

I don't like the idea of any application controlling the screen resolution at all under any circumstances. If the dumb game wants a different resolution, it should either be scaled or bordered. NEVER let a dumb game change the resolution.

Note: hack to prevent dumb game from changing the resolution: xrandr to delete all non-native modes.

The application wouldn't change resolution. It would request the windowmanager to change resolution.

[Ragas]

It's early days. If it looks like there is going to be a massive shift from X to Wayland across Linux distros then Nvidia will develop drivers for it.

No they won't because it basically means open sourcing their drivers. KMS is a part of the Kernel and to have a KMS driver go into the Kernel you need to opensource it kernel developers wont allow an open KMS driver which only works for a closed driver (as with those infamous Intel cards) so nvidia is either stuck with X, opens their driver (which they won't do) or the nice Kernel Programmers make a third special way for the blobs.

[Plombo]

You do realise that:

a) not everyone has gigabit Ethernet?
b) people routinely want to forward GUI apps over broadband which isn't even as fast as 10MB Ethernet?

I was trying xpra last night, which does per-window X-forwarding by running its own X-server on the remote host sending bitmaps over the network, and the difference in latency between that and direct X-forwarding via SSH was very noticeable. Sending big bitmaps around networks is just crazy.

In addition, this all assumes that the server you're running a GUI app from has a video card which can do the rendering; I've been working on a server which only supports the VESA driver and X-forwarding to a workstation which has a decent GPU and a decent driver. It would be even worse if it was a virtualised server with no GPU at all.

Basing your display system on having local rendering hardware to render bitmaps that you'll then send around the network is just crazy.

Contrary to what you seem to think, Wayland is not based on sending bitmaps over a network. It's not a network-based protocol. The Wayland developers have stated their opinion that networking functionality belongs in toolkits, not in the display server. They have a point, too, because toolkits know a lot more about what they're trying to do - and can thus more efficiently store the information whatever information the client needs in order to render - than any display server ever can.

[smitty3268]

No they won't because it basically means open sourcing their drivers. KMS is a part of the Kernel and to have a KMS driver go into the Kernel you need to opensource it kernel developers wont allow an open KMS driver which only works for a closed driver (as with those infamous Intel cards) so nvidia is either stuck with X, opens their driver (which they won't do) or the nice Kernel Programmers make a third special way for the blobs.

As has been mentioned several times now, Wayland only needs very minor modifications to use modesetting through the kernel blobs. It's really very similar to the KMS API that the OSS drivers use. The Wayland devs are not opposed to doing this, and Nvidia could do it quite easily. So there is no problem.

[V!NCENT]

Let me put it this way; 8mp jpeg is 2.5MB...

[makomk]

There is a misunderstanding here, wayland doesn't strictly need KMS/GEM. Wayland can easily use some others interface to setup video mode and to share buffer. What wayland needs is an EGL driver and modesetting capabilities without X, then if the EGL implementation has the EGL image extension it all should work properly ie all you need is to change bit of wayland that is not exposed to its client to work on somethings else than KMS.

It might get modified to allow this at some point, but currently Wayland is hard-coded to use KMS and DRI2 directly. Since the developers seem to prioritize code size and simplicity, I'm not sure this is ever likely to change.

What he doesn't seem to acknowledge is that Wayland is actually a protocol for display servers to communicate with their clients, and is independent of any specific implementation. In other words, Nvidia wouldn't have to use the Wayland reference implementation - the entire point of defining a formal protocol is to allow others to create compliant implementations that fit their own needs.

So we can go back to the good old days of multiple competing display server implementations, each with their own bugs and quirks that had to be worked around? Yay.

[glisse]

It might get modified to allow this at some point, but currently Wayland is hard-coded to use KMS and DRI2 directly. Since the developers seem to prioritize code size and simplicity, I'm not sure this is ever likely to change.

This can be changed more easily than you think.

So we can go back to the good old days of multiple competing display server implementations, each with their own bugs and quirks that had to be worked around? Yay.

wayland protocol is small there isn't thousands of combination, it's really all boils down to: "hello here is a buffer please show it and send me input"

No a monster protocol like X with several extensions and several weird behavior.