Announcement

Collapse
No announcement yet.

Years After Wayland 1.0, Will 2016 Be The Year Of The Wayland Desktop?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Fegr
    replied
    Years After Wayland 1.0.... Seriously! Wayland 1.0 mark only the stable API for client! The protocol itself was still in development. 1.2: stable Server API and 1.4 more features! Bryce Harrington mark Wayland 1.7-1.8.1 (June 2015) as "done". I think next year will be beginning of stable wayland-compositors! I'm impressed how stable Fedora 23 work with Wayland!

    Leave a comment:


  • ua=42
    replied
    Originally posted by pq1930562 View Post

    I thought one big advantage which Wayland would bring would be a perfectly V-synced desktop with no tearing whatsoever.

    Just like when Microsoft introduced DWM and the Aero Desktop with Windows Vista. Previous versions of Windows used to show glitches/artifacts/tearing when moving things around on the desktop. Since Windows Vista everything is smooth and tearfree.

    I thought Wayland would be the same for Linux, which would be a pretty big advantage if you ask me.

    Is this assumption incorrect?

    Regards
    You are correct. One of the goals is every frame is perfect.
    Not to mention it is secure, has a maintainable codebase, and faster.

    Leave a comment:


  • ThrowAway3000
    replied
    I just recently started using Xmonad WM and like it very much, I guess i'm not switching to Wayland anytime soon, or until someone makes WaylandMonad.

    Leave a comment:


  • kaprikawn
    replied
    Originally posted by bug77 View Post

    If only gedit has that problem, I highly doubt this is "indicative of how crappy X is".
    He was using Gedit as an example.

    Leave a comment:


  • bug77
    replied
    Originally posted by kaprikawn View Post
    I seem to remember a talk by Daniel Stone, probably getting on for about two years ago now, where he said opening Gedit caused over a hundred round trips to the X server for no real reason, other than, you know, X. It blocked Gedit from opening for at least a second, if not longer IIRC. You might not think that a second is a big deal (I'd disagree), but remember that that second was wasted doing absolutely nothing useful. I think that this is indicative of how crappy X is.

    If I didn't care about saving seconds opening stuff, I'd have my OS on a cost-efficient HDD. But I don't, I have it on an SSD which costs a lot more ?/gb. That's because when I open something I want it to open asap.
    If only gedit has that problem, I highly doubt this is "indicative of how crappy X is".

    Leave a comment:


  • ileonte
    replied
    Originally posted by Delgarde View Post

    What makes you think those things aren't solveable under Wayland? Apps don't need to speak directly to every single unique compositor - they need to invoke some standard interface that all compositors can implement. Such an interface may not exist today, but no doubt it will be created in time - secure ways to hook in screen capture tools, secure ways to register global key bindings, etc.
    I didn't say they weren't solvable, I said I don't think 2016 will be the year when these are solved. This is the topic of this whole thread: "will 2016 be the year of the Wayland desktop". As I said in my initial post: hopefully not. If distributions start pushing Wayland any time soon it's going to be a disaster of KDE4-pushed-out-too-early proportions.

    Leave a comment:


  • kaprikawn
    replied
    I seem to remember a talk by Daniel Stone, probably getting on for about two years ago now, where he said opening Gedit caused over a hundred round trips to the X server for no real reason, other than, you know, X. It blocked Gedit from opening for at least a second, if not longer IIRC. You might not think that a second is a big deal (I'd disagree), but remember that that second was wasted doing absolutely nothing useful. I think that this is indicative of how crappy X is.

    If I didn't care about saving seconds opening stuff, I'd have my OS on a cost-efficient HDD. But I don't, I have it on an SSD which costs a lot more ?/gb. That's because when I open something I want it to open asap.

    Leave a comment:


  • Azrael5
    replied
    Benefits about wayland are the following: more efficient; more responsivity; less complexity.

    Leave a comment:


  • Delgarde
    replied
    Originally posted by ileonte View Post
    You can't do that anymore on Wayland since the compositor is the only one that has the full picture - unless the app knows how to speak DIRECTLY to whichever compositor you're using it won't work.
    What makes you think those things aren't solveable under Wayland? Apps don't need to speak directly to every single unique compositor - they need to invoke some standard interface that all compositors can implement. Such an interface may not exist today, but no doubt it will be created in time - secure ways to hook in screen capture tools, secure ways to register global key bindings, etc.

    Originally posted by ileonte View Post
    Is the X11 implementation of this basically a global keylogger ? Yes. Could this be fixed while keeping the functionality ? Absolutely.
    No, it could not be fixed. That's why the X11 developers have given up on it - because there are so many problems like that that cannot be fixed because they're fundamental flaws in the X design. You can't support screenshot apps in a way that malicious software can't exploit. You can't support keybindings without supporting keyloggers. Why? Because as far as X11 goes, there's no difference, and if a program can access the display at all, it can do anything.

    Leave a comment:


  • TheBlackCat
    replied
    Originally posted by zanny View Post
    Because application developers do not develop for Wayland. They use GTK or Qt and those toolkits have implemented Wayland backends. But for whats "hard / impossible to do with X" try tearfree input redirection. Its X11 its impossible for xrandr provideroffloadsink or provideroutputsource without tearing or repainting issues.
    In theory. In practice, no toolkit covers all use-cases. So many application developers do have to develop for the underlying window system.

    Leave a comment:

Working...
X