The Wayland Situation: Facts About X vs. Wayland

[sireangelus]

Regarding point II) The input system in Wayland


What if I want to write an application to use more than one keyboard and mouse?
Games with support for multiplayer on the same machine, split-screen with multiple keyboard+mouse or gamepads. Being able to have slots and being able to pair mouse+keyboard+ other input devices as I wish would be very interesting. (working while runningne reason would be plug and play)

there is a video demonstration of waylang being used with 2 mouses and keyboards.

[daniels]

You see, your crowd is the one trying to replace X. So it should be you covering the use cases. I'm perfectly happy with X, and moving to an inferior system has no appeal to me. So with this in mind, why should I waste my time fixing such a system?

without wanting to sound too snarky, don't? no-one's forcing you to - and, conversely, no-one's forcing us to cripple the system or go down pointless design dead ends just because someone said we should - so if x11 works for you and you're not convinced about wayland's design, then stick to what you think is better.

PS: I noticed you didn't reply to any of the original points. Do I take this as you agree with the premise?

i didn't feel it was necessary to get into a debate about remote rendering on a forum in 2013, given the number of times the entire internet has argued it over. but oh well.

1) yes it is, but it's missing the point to some extent with the scrolling comment. see, e.g., krh's rolling hash implementation.
2) which on the face of it sounds bad, until you think about the last 40-50 years of work on image and media compression.
3) what do you mean, 'such'? do you think x11's is efficient? have you looked at the protocol stream for a remoted x11 application lately?
4) yes
5) i agree, assuming 'remotable protocol' doesn't necessarily preclude sending pre-computed images
6) what's your lowest common denominator then? nowhere in this thread has anyone come up with a meaningful proposal for abstract rendering which works across all toolkits and their various themes, yet also doesn't send images but gets the remote side to calculate it.

not only do i not buy your 'i'm concerned about something so it is literally on you to appease me' line of argument, but from the entire remote-rendering crowd, i've also seen a sum total of zero concrete proposals - handwaving on the internet doesn't count. which might tell you something about its feasibility.

tl;dr: come up with a good prototype and we'll talk?

[daniels]

I'm not here to propose any implementation. I'm here to explain the issue.

it's been explained tens of thousands of times already. we don't need any more explaining, thanks.

[daniels]

Regarding point II) The input system in Wayland


What if I want to write an application to use more than one keyboard and mouse?
Games with support for multiplayer on the same machine, split-screen with multiple keyboard+mouse or gamepads. Being able to have slots and being able to pair mouse+keyboard+ other input devices as I wish would be very interesting. (working while runningne reason would be plug and play)

you can do this already by creating multiple seats - the story about multiseat support in weston required zero protocol changes.

[plonoma]

Concerning the use of the mute button. And the passing of button functionality to applications.
Is it possible to do this with other buttons as well? Is it possible to configure what buttons not be used
(and their function overridden) by any applications or only specific applications?

Using a certain button as an escape button to escape the current window except for screen-saver comes to mind.
(And other application such as anti computeraddiction applications that lock you out of your computer by function, there may be other examples where being able to specify applications is needed.)


Having other buttons such as the print screen, sound louder, sound quieter and other buttons would be nice to have in login screen as well.
(Especially multimedia buttons.)

[Serge]

Thank you for taking the time to put together such an informative article and for taking the time to answer questions, Eric and Daniel. I appreciate that the Wayland team have taken a "root causes" approach rather than trying to fix the symptoms of X's shortcomings. Twice this year already I have had to write a custom Xorg.conf to deal with multi-monitor issues. I was visiting my 58-yo mother for dinner and she plugged her Win7-running laptop into her TV to show us a YouTube video she liked. I guarantee you she did not write any custom configs to get that working. So I am not too eager to defend legacy X. I am just concerned that Wayland's minimalistic approach may create additional problems that do not exist with X. Thus, my questions are:

1) With the clients being responsible for more, is there a danger of increased inconsistency in how everything is drawn? There are already some issues with programs written against Qt running in a mostly-GTK environment and vice-versa. Is there a possibility of a regression in this regard? Also, will requiring the clients to do more work increase the likelihood of replication of effort on the part of developers?

2) We keep hearing about all of X's legacy cruft, and once in a while we are shown examples. But the legacy usage cases that X is required to support, that X can't get rid of because legacy users are stakeholders who get a say in X's development - are these legacy cases compatible with modern usage cases? That is, in other words, do legacy users even benefit from progress made in X targeting modern usage? Is it possible to fork X into legacy use and modern use branches?



I am also very interested in a service managers / init systems comparison. Like Candide, I too am interested in more than just boot-up speed (actually, boot-up speed is not very interesting to me at all).

[garegin]

Daniel. I am a noob in graphics, so please bear with me.
Isn't remote rendering something like MIDI or font equivalent for GUI? By that I mean, instead of sending compressed images down the wire you tell the remote computer the "elements" like window borders or buttons and then the client just retrieves them from a local source.
Makes sense to me if you have a unified GUI like in Windows or OS X. Is this already being done in MS's RDP. Or is such a bad idea that no-one does it.

[GreatEmerald]

Seems you misread me, I'm advocating for sending *text*, not images. Especially not both fonts and images.

You can't not send images. If a program uses canvas and draws things on it, there is no way around it but send the image from the display server's point of view. With widgets it could be a bit more manageable, but everyone is moving away from widgets anyway (QtQuick, Clutter), and there already are many different widget implementations (Cairo, QtWidgets, wxWidgets etc.), with new ones possibly getting created as well. So if you end up sending the window background as an image, everything inside the window might as well be baked into the image as well.

Isn't remote rendering something like MIDI or font equivalent for GUI? By that I mean, instead of sending compressed images down the wire you tell the remote computer the "elements" like window borders or buttons and then the client just retrieves them from a local source.
Makes sense to me if you have a unified GUI like in Windows or OS X. Is this already being done in MS's RDP. Or is such a bad idea that no-one does it.

See above. Plus you have no idea what clients have and what they don't. You cant require every client to have all the different widget libraries in the world installed.

[curaga]

without wanting to sound too snarky, don't? no-one's forcing you to - and, conversely, no-one's forcing us to cripple the system or go down pointless design dead ends just because someone said we should - so if x11 works for you and you're not convinced about wayland's design, then stick to what you think is better.

I will, for the next few years. But as mentioned, the danger is that if Wayland catches on, we may lose the remotability of all apps from then on, as all new apps from then may be wayland-only.

It's like saying "this new system can only be used by right-handed people. We don't care the system it replaces had 5% left-handed users."

3) what do you mean, 'such'? do you think x11's is efficient? have you looked at the protocol stream for a remoted x11 application lately?

Not X, but a protocol that sends text as text, not images.

6) what's your lowest common denominator then? nowhere in this thread has anyone come up with a meaningful proposal for abstract rendering which works across all toolkits and their various themes, yet also doesn't send images but gets the remote side to calculate it.

Sending images where the theme needs it (bitmap theme, corners, etc) is fine. It's only where there is zero sense to send an image, like text or a gradient fill, that an image shouldn't be sent.

tl;dr: come up with a good prototype and we'll talk?

Thanks for clarifying the official position. I get you don't want this repeated, but it's kind of hard to believe you're willingly throwing away a platform advantage, and a set of users with it.

[curaga]

You can't not send images. If a program uses canvas and draws things on it, there is no way around it but send the image from the display server's point of view. With widgets it could be a bit more manageable, but everyone is moving away from widgets anyway (QtQuick, Clutter), and there already are many different widget implementations (Cairo, QtWidgets, wxWidgets etc.), with new ones possibly getting created as well. So if you end up sending the window background as an image, everything inside the window might as well be baked into the image as well.

No, you send the window background once, and then the text is sent as text as the user scrolls. Not a continued image stream, as the background doesn't change.