Recent Features
| |||||||||||||
Wayland and Weston 1.0 releasedWayland and Weston 1.0 releasedPosted Oct 24, 2012 3:56 UTC (Wed) by dlang (✭ supporter ✭, #313)In reply to: Wayland and Weston 1.0 released by rahvin Parent article: Wayland and Weston 1.0 released
They already have the ability to run X programs and have them talk to a shim that displays the results in Wayland.
That's not the problem, the problem is having Wayland programs talk to an X server and having a way (other than just VNC style shipping full-screen bitmaps around for every app) to send the results to a remote display.
The Wayland answer is "nobody wants to do that, and anyone who says they do doesn't know what they are talking about", which doesn't do much to satisfy people's concerns who are using the features that they are so dimissive of.
(Log in to post comments)
Wayland and Weston 1.0 released Posted Oct 24, 2012 4:13 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
xpra has demonstrated that this approach works perfectly well.
Wayland and Weston 1.0 released Posted Oct 24, 2012 4:20 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
It works so well that my co-workers used it as an example that pure X can be perfectly usable over WANs :)
Wayland and Weston 1.0 released Posted Oct 24, 2012 4:35 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
I think I'd be looking for new co-workers…
Wayland and Weston 1.0 released Posted Oct 24, 2012 5:03 UTC (Wed) by daniels (subscriber, #16193) [Link]
It kind of disproves the point though, and validates the Wayland approach; it shows that you need a proxy compositor to make the latency less biting on all the round-trips you need to do. Which is heaps.
Wayland and Weston 1.0 released Posted Oct 24, 2012 5:17 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
It disproves the point rather more strongly than that - xpra only sends bitmaps (optionally compressed via a range of codecs), not X.
Wayland and Weston 1.0 released Posted Oct 24, 2012 12:39 UTC (Wed) by VITTUIX-MAN (guest, #82895) [Link]
Xpra is awesome, even if still rather beta in some places. It allows me to run graphical stuff under a bare shell account, using Xvfb as back end.
One thing that is often overlooked with Xpra is that it also works locally, meaning ´xpra attach´ can be ran in the remote end of the tunnel, and Xpra will use mmap'ed memory in that case. In other words, Xpra is not needed in local end, bare tunneled X will suffice but then of course the advantages of compression are lost.
Just wondering when the Wayland-stack can do the same; as lousy X is sometimes, it also is extremely hackworthy.
Wayland and Weston 1.0 released Posted Oct 24, 2012 16:08 UTC (Wed) by nix (subscriber, #2304) [Link]
Only if its keyboard support has improved. Last time I tried it I couldn't even type £, let alone use my meta keys. (More generally, keyboard support in any sort of virtualization with X underneath it is very hard -- I don't know if Weston allows this sort of thing to be truly virtualized, but X's keycode->keysym mapping, while praiseworthy in other ways, makes it damn hard by design to get back from a keysym to a keycode of any sort so you can feed it to a remote X server.)
Wayland and Weston 1.0 released Posted Oct 24, 2012 16:30 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
> Only if its keyboard support has improved
How is that relevant to whether or not sending pixmaps over the wire is an acceptable remoting approach?
Wayland and Weston 1.0 released Posted Oct 24, 2012 17:37 UTC (Wed) by daniels (subscriber, #16193) [Link]
Huh? X only ever sends keycodes to clients, which are solely and 100% responsible for performing the translation to keysyms. It's possible to get a perfectly lossless translation with infinitely nested X servers, by just copying the keymaps and passing the keycodes straight through.
Wayland and Weston 1.0 released Posted Oct 24, 2012 19:26 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
> Huh? X only ever sends keycodes to clients, which are solely and 100% responsible for performing the translation to keysyms. It's possible to get a perfectly lossless translation with infinitely nested X servers, by just copying the keymaps and passing the keycodes straight through.
It can be slightly more complicated than that, given that the client system may not have the same mapping of key codes to physical keys (it may well not be running X at all), and that you are wanting to send the server key codes not symbols. On an X server with XKB and a reasonably PC-like keyboard you can get a pretty good idea of how the key codes and physical keys correspond, but that doesn't cover all systems by any means.
Wayland and Weston 1.0 released Posted Oct 25, 2012 0:32 UTC (Thu) by daniels (subscriber, #16193) [Link]
Right, hence why you also need to copy the keymap. If you can't do that, then you're on your own.
Wayland and Weston 1.0 released Posted Oct 25, 2012 4:20 UTC (Thu) by amtota (guest, #4012) [Link]
> Right, hence why you also need to copy the keymap. If you can't do that, then you're on your own.
Right. With xpra on posix platforms we try (...) to copy the keymap across, with win32 and osx clients it gets a little bit more complicated.
Going forward, what we need to do is to use the Xkb x11 api rather than the core keyboard api to get a full and exact keymap copy.
Wayland and Weston 1.0 released Posted Oct 25, 2012 7:41 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
>> Right, hence why you also need to copy the keymap. If you can't do that, then you're on your own.
The key map doesn't help when you are trying to translate a client's notion of physical key codes to a server's notion, since the key map is orthogonal to the physical keyboard layout. (Well actually it can help with some knowledge of common keyboard mappings, but that isn't nice.)
> Right. With xpra on posix platforms we try (...) to copy the keymap across, with win32 and osx clients it gets a little bit more complicated.
> Going forward, what we need to do is to use the Xkb x11 api rather than the core keyboard api to get a full and exact keymap copy.
[1] https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Fr...
Wayland and Weston 1.0 released Posted Oct 25, 2012 9:53 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
> The key map doesn't help when you are trying to translate a client's notion of physical key codes to a server's notion, since the key map is orthogonal to the physical keyboard layout.
That is, unless there is some way I am unaware of of finding out the mapping for a well known keyboard layout (e.g. US) for the current system via the X protocol - preferably a method which doesn't depend on XKB.
Wayland and Weston 1.0 released Posted Oct 26, 2012 11:36 UTC (Fri) by daniels (subscriber, #16193) [Link]
> That is, unless there is some way I am unaware of of finding out the mapping for a well known keyboard layout (e.g. US) for the current system via the X protocol - preferably a method which doesn't depend on XKB.
Such a mapping doesn't necessarily exist: what if you're not using a PC keyboard at all, but have a weird phone-style keyboard? Or if your backend is, say, OS X, which has a slightly different approach to handling keycodes?
The best you can do right now is take the rules and model of the mapping you want to compare to, and compile a keymap with the same rules and model, but with the layout set to 'us'. And that might work, in the most case.
In any case, XKB, painful though it is, is _the_ keyboard mapping for X11, and that's never going to change. Not least because it's exposed at all levels through the totally immutable Xlib ABI.
Wayland and Weston 1.0 released Posted Oct 26, 2012 11:51 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
> In any case, XKB, painful though it is, is _the_ keyboard mapping for X11, and that's never going to change. Not least because it's exposed at all levels through the totally immutable Xlib ABI.
For my purposes XKB is not particularly painful - dealing with Windows oddities is much worse. The only reason that XKB-less methods interest me is for dealing with servers which don't have it. Not sure how many that is these days, but I am sure that some VNC-like servers will fall into that category - and tend to be rather interesting from a keyboard handling point of view.
Wayland and Weston 1.0 released Posted Oct 25, 2012 0:09 UTC (Thu) by nix (subscriber, #2304) [Link]
Gah. True. Sorry, I misspoke, I forgot at what side of the server/client boundary the translation happened (it's been a long time since I did much with this and the relevant neurons obviously got trauma-erased).
Wayland and Weston 1.0 released Posted Oct 24, 2012 4:33 UTC (Wed) by daniels (subscriber, #16193) [Link] The Wayland answer is "nobody wants to do that, and anyone who says they do doesn't know what they are talking about", which doesn't do much to satisfy people's concerns who are using the features that they are so dimissive of. Oh, for christ's sake. Where has anyone said that? Who? Wayland already has working network transparency. It's not in a release, but you can see Kristian demoing it in the presentation he gave at XDC. I've seen it with my own eyes; it's pretty cool. It's a slightly different approach to the way X does it; X forces it in the protocol, and then clients have to go to entertaining lengths to figure out if they can or can't use SHM/GEM/DRI2/etc. Wayland's (to be more accurate, Weston's) remoting support instead implements a proxy compositor and then pipes things over the network making full usage of compression for images, etc. So we've pulled the latency for clients right down to the bare minimum, and we can do world-class video compression without them having to care about it. So, it's a much much better remoting protocol than X, which is pretty much the worst remote window system protocol anyone's ever seen. No image compression, all the images forced into the same stream as the control messages, which are extremely chatty and round-trip heavy - so it's incredibly sensitive to both latency and throughput. And if you have high/variable latency and low/variable throughput, it's going to be totally, totally unusable. Please do me a favour in future and do a little background research - even a quick browse through the comments on any other LWN article about Wayland ever would've helped - before you start slagging off free software projects. Thanks.
Wayland and Weston 1.0 released Posted Oct 24, 2012 6:03 UTC (Wed) by rsidd (subscriber, #2582) [Link]
Indeed, X's remoting is really bad. It was only ever usable on the sort of high-speed low-latency university LAN where it was developed. It was never intended for use over the internet. And today, even on LANs, X's performance is significantly worse than alternatives.
Wayland and Weston 1.0 released Posted Oct 24, 2012 12:44 UTC (Wed) by sce (subscriber, #65433) [Link]
> Wayland already has working network transparency. It's not in a release, but you can see Kristian demoing it in the presentation he gave at XDC. I've seen it with my own eyes; it's pretty cool.
Wayland and Weston 1.0 released Posted Oct 24, 2012 16:18 UTC (Wed) by nix (subscriber, #2304) [Link]
The comment thread in <https://lwn.net/Articles/481138/> has several instances of Wayland boosters doing down network-transparency as useless.
I pointed out in that thread that sending giant bitmaps would be devastating for a major use case: scrolling windows full of lots and lots of client-side-rendered text. X has those glyphs in GlyphSets, so doesn't need to send all the giant images over again: things like VNC or SPICE do not, so a single one-line scroll of a full-screen xterm can take half a second or so under such remoting technologies, while under remote X it is nearly instantaneous (you can easily scroll the whole screen line-by-line under remote X in the time it takes VNC et al to scroll a single line).
I asked what Wayland has that provides the same speed boost over giant image lump transfer.
Answer came there none.
Apparently terminal emulators and text editors are not an important use case anymore. (A killer for me, since my Emacs, with huge windows full of lots of text, is *always* run network-remote. It's as fast remotely under X as it would be locally. Obviously it is intolerably slow over a slow remote link, but I'm not using it that way. Oh, and while Emacs supports Gtk and thus would be able to pick up any Gtk-side Wayland remoting support, I note that horrible problems in Gtk's existing support for remote X -- including coredumping whenever a display goes away -- have gone unfixed since 2002, so I am not confident that Gtk Wayland remoting would be in any better shape any time soon.)
Wayland and Weston 1.0 released Posted Oct 24, 2012 16:31 UTC (Wed) by wmf (guest, #33791) [Link] sending giant bitmaps would be devastating for a major use case: scrolling windows full of lots and lots of client-side-rendered textIt's possible to compress this down to nothing using motion estimation; whether Wayland can actually implement that remains to be seen but it's not impossible.
Wayland and Weston 1.0 released Posted Oct 24, 2012 16:42 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
That is EASILY fixed by a good compression protocol.
motion detection is not as easy as it should be Posted Oct 25, 2012 4:25 UTC (Thu) by amtota (guest, #4012) [Link]
Unfortunately that is not the case.
xpra.org uses x264 and vpx codecs to achieve great compression ratios (whilst still maintaining almost pixel perfect quality for our xterms), but even these codecs fail to detect scrolling when more than a few lines move at a time.
Now, we don't want to start writing our own motion detection code, and since the x11 server already knows about the motion, it would be nice if it could expose this information to us... sadly it does not.
motion detection is not as easy as it should be Posted Oct 25, 2012 11:24 UTC (Thu) by njs (guest, #40338) [Link]
The X server may or may not know about scrolling (it depends on which APIs the client is using), and the interface to expose this would be a nightmare... plus scrolling is an extremely trivial sort of motion to detect (integer number of pixels with absolutely unchanged contents). Why not just write some motion detection code?
Both sides of the connection have the old window contents available (though the server may not keep it in memory right now). A cheap-but-effective algorithm would be: Break this into fixed size chunks (say 16x16 pixels), discard solid-color ones, and hash the remaining with a rolling hash. When you get a new region to send, first run the rolling hash over this region to see if there are any matches. If so, align the new data with the matching old data, subtract, and send the offset + the difference (which will be highly compressible). Then the client inverts this to reconstruct. This will be effective even if some parts of the region are changing at the same time they scroll, new bits of the window are scrolling onto screen, etc., and the computational overhead would still be absolutely swamped by gzip, never mind vpx/x264.
motion detection is not as easy as it should be Posted Oct 25, 2012 15:34 UTC (Thu) by renox (subscriber, #23785) [Link]
>Why not just write some motion detection code?
Because the more complex compression you do, the more latency you add..
motion detection is not as easy as it should be Posted Oct 25, 2012 19:33 UTC (Thu) by njs (guest, #40338) [Link]
Yes, that's why I made a point of describing an algorithm that should only add a tiny amount of overhead on top of the existing gzip cost, and less than the super-fancy video encoders that are already used? Detecting simple scrolling is really not complicated.
motion detection is not as easy as it should be Posted Oct 25, 2012 19:51 UTC (Thu) by hoegsberg (guest, #57768) [Link]
Yeah, and we're working on more or less the exact rolling hash idea you described. It was kinda weird to see you describe the same approach here... It's still work in progress, but there's a few PNGs here that shows the current status: http://people.freedesktop.org/~krh/rolling-hash/
With just a few MULs per pixel, we can detect if a 32x32 blocks starting at that pixel appears in the previous frame. This should basically be as good as any scrolling/copyarea hint we could've gotten from X or a toolkit, and it detects duplicate blocks in may cases where applications don't scroll but just re-render (like resizing). And of course this technique applies to both fullscreen remote display or per-window remote display.
motion detection is not as easy as it should be Posted Oct 25, 2012 21:07 UTC (Thu) by njs (guest, #40338) [Link]
Hah, awesome. Well, I guess it's the obvious thing to try...
Wayland and Weston 1.0 released Posted Oct 24, 2012 17:40 UTC (Wed) by daniels (subscriber, #16193) [Link] The comment thread in https://lwn.net/Articles/481138/ has several instances of Wayland boosters doing down network-transparency as useless. Yeah, unfortunately I can't do anything about the armchair software developers. Everyone who's actually contributed to Wayland has always had the same answer: remoting's going to come, it'll be better than X, but it won't be part of the core protocol because we don't think that's the right approach. The FAQ is badly worded, but that'll get fixed.
Wayland and Weston 1.0 released Posted Oct 25, 2012 0:12 UTC (Thu) by nix (subscriber, #2304) [Link]
Agreed. I said 'boosters' not 'developers' for a reason :)
I suppose client-side remoting can fix this just as well as X can: the toolkit knows when you asked to print text, so can send just that over the wire perfectly well.
(It is disturbing to realise that in future different applications will have different degrees of support for remoting depending on what toolkit they're using, but I can't really claim that this differs from the current situation where they have different degrees of support for remoting depending on whether their developers ever tried to minimize roundtrips or whether they are using DRI. It's not as if 'it takes an hour for this program to map a window' is appreciably better than 'not working at all' -- and at least a 'just hurl giant bitmaps' fallback remoting program will work with everything, even if inefficiently.
I am slowly starting to be won over. Dammit. Can't you leave me *any* pointless irrational positions?
Wayland and Weston 1.0 released Posted Oct 25, 2012 4:00 UTC (Thu) by raven667 (subscriber, #5198) [Link]
> I am slowly starting to be won over. Dammit. Can't you leave me *any* pointless irrational positions?
It's a pleasure to converse with someone who is at least willing to consider another persons position. There are plenty if people here that only seem interested in complaining but not listening, they are not much fun to talk to.
Wayland and Weston 1.0 released Posted Oct 31, 2012 15:40 UTC (Wed) by daglwn (subscriber, #65432) [Link]
I too have started to come around on this now that it's been made clear that remote display will be possible.
I didn't understand the distinction between "remote display" and "remote transparency" until you clarified that earlier and stated that remote display is indeed a needed feature. Thank you for clearing that up for me.
Wayland and Weston 1.0 released Posted Oct 25, 2012 15:36 UTC (Thu) by gidoca (subscriber, #62438) [Link]
As far as I understand from the XDC presentation video, it wouldn't be implemented in the toolkit, but as a special wayland compositor. On the computer you want to display the window, you would run the regular weston compositor, plus some client software. On the machine the application runs on, you would instead run some special compositor that speaks the wayland protocol, but sends the buffer over the wire instead of displaying it on the local display. Therefore, you wouldn't need anything special in the toolkit. Note that I don't know any more than what I learned from the talk, so take this with a grain of salt.
Wayland and Weston 1.0 released Posted Oct 28, 2012 15:58 UTC (Sun) by nix (subscriber, #2304) [Link]
That's the fallback remoter, I think. The *real* remoting would be done in the toolkits, which know exactly what the application has done and can transmit data over the wire with correspondingly high efficiency, just as X does now only actually efficiently. (I hope there'll be a library of some sort implementing authentication and such things, so that the different toolkits don't end up with divergent ways of authenticating the remote connection with different user interfaces. xauth-plus-ssh is bad enough as it is...)
Wayland and Weston 1.0 released Posted Nov 1, 2012 19:22 UTC (Thu) by wmf (guest, #33791) [Link]
I think toolkit remoting is going to be much more complex (especially when you have to implement it N times) and not necessarily faster than bitmap remoting (cf. the Sun Labs SLIM project). Also, it creates more bad PR because it makes it look like Wayland remoting is five years away.
Wayland and Weston 1.0 released Posted Oct 30, 2012 21:09 UTC (Tue) by daglwn (subscriber, #65432) [Link]
> A killer for me, since my Emacs, with huge windows full of lots of text,
> is *always* run network-remote.\
I totally agree that remote display is an absolute must.
But have you tried Emacs with TRAMP? It's a pain to set up but once working I've found that it really does what I need to do: compile, debug, shell, etc.
There are some things TRAMP can't do so it's not a complete replacement for remote display but I've found I don't need remote display for Emacs anymore. Other things, sure, but not Emacs.
Wayland and Weston 1.0 released Posted Oct 31, 2012 0:38 UTC (Wed) by nix (subscriber, #2304) [Link]
I need it for Emacs simply because my remote always-on server is, well, always on, and I fairly often access my Emacs from remote sites via emacsclient while the desktop is off. (The desktop is a power sucker, so it goes off when I'm not using it.)
TRAMP is very nice, but without remote display I'd be left running my Emacs on a machine that was turned off, and not even Wayland can do that. :}
Wayland and Weston 1.0 released Posted Oct 31, 2012 15:43 UTC (Wed) by daglwn (subscriber, #65432) [Link]
Makes total sense to me. Our company has not yet seen always-on desktop systems as a power problem. Perhaps they will soon. :)
Wayland and Weston 1.0 released Posted Oct 24, 2012 16:31 UTC (Wed) by gurulabs (guest, #10753) [Link]
"Please do me a favour in future and do a little background research"
One problem is that the official Wayland FAQ still (today) says:
Q: Is Wayland network transparent / does it support remote rendering?
A: No, that is outside the scope of Wayland....
So it is no wonder people are still confused on this point.
Wayland and Weston 1.0 released Posted Oct 24, 2012 16:42 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Wayland is a local display server. It's like asking whether the Linux kernel supports ssh. Sure, if someone writes it, but it's not in the scope of kernel development.
Wayland and Weston 1.0 released Posted Oct 24, 2012 17:03 UTC (Wed) by wmf (guest, #33791) [Link]
Writing a pedantically-correct FAQ that encourages misunderstandings is a good way to FUD your own project. It should say something like "Remoting is out of scope for the Wayland protocol or Weston compositor, but this will be solved with a proxy that will be bundled with your distro and will Just Work™".
Wayland and Weston 1.0 released Posted Oct 24, 2012 17:07 UTC (Wed) by wmf (guest, #33791) [Link]
I hate to respond to myself, but I looked at the actual Wayland FAQ and it's not as bad as the quote above implies, but it's still pretty confusing.
FAQ could be more helpful Posted Oct 25, 2012 4:28 UTC (Thu) by amtota (guest, #4012) [Link]
I agree, although I am biased as I maintain xpra.org, I would have expected the Wayland devs to get in touch with us or at least provide a link for those who do want to keep network transparency. Oh well.
Wayland and Weston 1.0 released Posted Oct 26, 2012 0:17 UTC (Fri) by jschrod (subscriber, #1646) [Link]
Ah, the systemd argument.
We're replacing "XYZ" that does "ABC", calling it "xyzzy". Believe us, we're doing best work ever, you won't notice anything, and we'll all live happily ever after.
But, "XYZ" does "DEF" as well. How shall we do it in the future?
Well, "DEF" is not the scope of our replacement. It doesn't belong to "xyzzy".
But... "XYZ" did it...
You don't understand: We define the scope. And we're in the position to tell you that while "ABC" might be of interest to you, all the rest of the world doesn't care. So we define that "ABC" wasn't part of "XYZ" and we don't have to replace it.
But... "XYZ" did "ABC"...
As we said, we don't care. We define, you don't need "ABC".
But then... "XYZ" is not a replacement if it doesn't deliver the same functionality.
You're wrong. You're not in the position to define that. We have the power to define what is a replacement and what is not. And we tell you: "xyzzy" is a full replacement for "XYZ", for all relevant functionality. A maze of twisty little passages, all alike.
The story of the Linux desktop,
PS: Chosing the name "xyzzy" as illustration is clearly not correct, as it doesn't support remoting to "Y2", even though it should. But, maybe, sometime in the future we'll be able to kill the dragon (aka we'll be able to really replace X) with our bare hands.
Wayland and Weston 1.0 released Posted Oct 26, 2012 8:17 UTC (Fri) by dgm (subscriber, #49227) [Link]
> We're replacing "XYZ" that does "ABC", calling it "xyzzy".
Strawman. Wayland does not replace X11. X11 can be run on top of Wayland, just like it does on Windows or OSX. The rest of the argument does not make sense.
Wayland and Weston 1.0 released Posted Oct 26, 2012 8:25 UTC (Fri) by jschrod (subscriber, #1646) [Link]
> Wayland does not replace X11.
When Qt und GTK focus on Wayland, these DEs will have native Wayland applications, and X will not be a first class citizen any more. It will only be supported as an legacy interface. As long as we don't want to be stuck using current software versions, that means that de-facto Wayland *will* replace X11 in the medium-to-long term.
Besides, the experience of running X11 on Windows or OS X is no good advertisement, either. I've done both, and good integrated support is something different.
Wayland and Weston 1.0 released Posted Oct 26, 2012 9:32 UTC (Fri) by paulj (subscriber, #341) [Link]
This is rubbish. Qt and GTK are not DEs, but toolkits. Further, these toolkits *both* have long supported rendering outputs *other* than X11 for a long time (from Windows GDI to direct framebuffers, even HTML). So there's just no basis to say that the addition of another rendering context, Wayland, is going to change the quality of X11 support.
The only thing that could change that is if X11 becomes so little used that no one cares to support it anymore.
Wayland and Weston 1.0 released Posted Oct 24, 2012 17:41 UTC (Wed) by daniels (subscriber, #16193) [Link]
Yeah, it does read quite badly. If you keep on reading, you see it arrive at the real answer of 'yes, it's coming, we just don't think it belongs in core protocol', but unfortunately it starts from a pretty literal interpretation of the question.
Sorry about that. :)
Wayland and Weston 1.0 released Posted Oct 24, 2012 18:02 UTC (Wed) by apoelstra (subscriber, #75205) [Link]
> Yeah, it does read quite badly. If you keep on reading, you see it arrive at the real answer of 'yes, it's coming, we just don't think it belongs in core protocol', but unfortunately it starts from a pretty literal interpretation of the question.
> Sorry about that. :)
Thanks for your polite replies in this thread. Myself, and I suspect many others, don't take the time to read up on this stuff, and only encounter Wayland discussions on LWN. And as you say, there are many armchair software developers slinging crap around, and the communication from the Wayland devs thus far leaves something to be desired.
So, it's nice to see people rising above the fray and clearing up misconceptions, rather than getting caught up in flamewars (or completely ignoring the thread).
Wayland and Weston 1.0 released Posted Oct 24, 2012 22:31 UTC (Wed) by rahvin (subscriber, #16953) [Link]
As one of the armchair idiots let me just say I was right along with everyone else's negativity until I read the excellent LWN articles and subsequent wayland developer comments that were in replay to the article. Wayland appears to me that it's going to solve some real problems, remove some serious legacy cruft (almost 90% of X isn't even used) and bring the Linux desktop back to the Unix approach which is a simple tool for each task and X is not a simple tool.
The worst part is the misunderstanding about what Wayland is and what it's trying to do as can be seen in the slashdot article and unfortunately in the posts here as well. (as noted, it doesn't help that the FAQ is badly worded in some cases).
Wayland and Weston 1.0 released Posted Oct 25, 2012 0:14 UTC (Thu) by nix (subscriber, #2304) [Link]
Agreed. I'll only be unhappy with Wayland if major toolkits don't bother to implement remoting -- but if they do (which seems likely, or Wayland will never take off), it's probably going to become as capable as X already is, with more scope for expansion.
Wayland and Weston 1.0 released Posted Oct 25, 2012 15:08 UTC (Thu) by renox (subscriber, #23785) [Link]
> Agreed. I'll only be unhappy with Wayland if major toolkits don't bother to implement remoting
I think that "a proxy pushing giant bitmap" remoting will be eventually available whatever the toolkit used, of course in some case (text) it's quite inefficient compared to XRender glyph cache's remoting..
Wayland and Weston 1.0 released Posted Oct 25, 2012 22:52 UTC (Thu) by rahvin (subscriber, #16953) [Link]
The only thing I can do is point to the comments in the previous articles that even if you are running Wayland you can still run X on top even if someone doesn't do a connector or other tool that only runs the parts of X that are needed.
Wayland and Weston 1.0 released Posted Oct 27, 2012 8:22 UTC (Sat) by paulj (subscriber, #341) [Link]
The major toolkits already implement remoting that works with Wayland: X11. Hopefully there'll be better remoting protocols in time.
Wayland and Weston 1.0 released Posted Oct 28, 2012 16:01 UTC (Sun) by nix (subscriber, #2304) [Link]
True! So we *already* have nothing worse than before, as long as someone keeps the X11->Wayland stuff maintained (and I suspect, given the installed base of X applications, that it's not going to fall unmaintained for a long, long time).
|
|||||||||||||