71–80 of 131 posts
Can anyone clarify please, how is full OpenGL stack supported in Wayland cases? In X there is libglx, while Wayland relies on OpenGL ES. So how for example would some games which need full OpenGL work on Wayland?
Earlier quoted context omitted.
This is a good question. Is there documentation that really explains the Quartz architecture somewhere?
The Apple documentation on Quartz 2d is pretty good (although depending on how familiar you are with the rest of the system, you might need to follow some of the links to read about the other parts): https://developer.apple.com/library/mac/#documentation/Graph...
Wayland is a critical technology for Linux desktop community. X11 has been a reliable workhorse, but its time is up - simply too much cruft accumulated over the years that's not even used anymore. Yet all of it needs to be continually supported, adding to complexity. No one uses X11 primitives for drawing apart from bitmap functionality - even repainting dirty regions (expose events) often involves sending over a new…
Uhh, isn't the entire point of GLX/AIGLX network transparency? http://en.wikipedia.org/wiki/AIGLX
> Versioning is handled per client, not per bind. So if your app supports one version of a given extension but your toolkit supports another, you can't predict which version of that extension you will get.
Easy solution: open multiple connections. Resources can be shared between connections. (You missed the actual problem with X11 here, which is its current limit of 256 clients. But that's easily fixed with an "X12".)
> III) Many years ago, someone had an idea “Mechanism, not policy.” What did that mean? It means that X has its own X-Specific drawing API,
That's not at all what that means. "Mechanism, not policy" means the X11 core protocol leaves things like window managers and clipboard selection unspecified. (The ICCCM spec takes care of this.) This is sound design.
> it is its own toolkit like GTK+ or Qt.
Wow, not at all. What do toolkits have to do with drawing primitives?
> It defined the low-level things, such as lines, wide-lines, arcs, circles, rudimentary fonts and other 'building block' pieces that are completely useless on their own.
Don't like it? Ignore it and use GLX. X11 is extensible for a reason.
> Media Coherence. Whats Media Coherence? In its simplest terms... Your browser window? That's a window. Your flash player window on youtube? The flash player itself, displaying the video, is a sub-window. What keeps them in sync? Absolutely nothing. The events are handled separately and right now you just pray that they don't get processed too far apart.
WTF? This is exactly what the Sync extension is for.
> “Please generate me a config file........Please actually USE this config file.” Why?? Eventually fixed by making the X-server only use a config file for overrides and making it know and have SANE defaults / auto-detection.
This is an argument against XFree86, not X11. Nothing about X11 dictates XFree86's strange configuration mechanism.
> Who's ever had problems with multiple monitors under Linux? OR ever had to re-setup all of your monitors after a reboot? All X's fault unless you store it in /etc/X11/xorg.conf.d/50-monitors.conf, then it DOES remember it...but you probably had to write that by hand.
Again, WTF does this have to do with X? If your distro is broken and doesn't ship with a decent configuration tool, that will be a problem with Wayland too.
> The window tree is a complete mess. Under X every input and text box was its own window which was parented by the window above it.
Why? Nothing about X11 dictates you must design programs or toolkits like this. Methinks you're confusing "X" with "Athena toolkit".
> Its a nitpick, but its also a valid concern... Under X11, the global pixel counter is 15bits. Which means, between all of your displays you can only have 32,768 pixels.
Shit, no way to fix that without designing a new windowing system from scratch.
> Everything is a window to X, there's no different window types, its just “A window.”
THIS is what "mechanism, not policy" means. X11 doesn't care about window types by design. The ICCCM and EWMH specs are where these things are – by design! – defined! There are different window types, and your window manager is aware of them, without adding needless complexity to the core protocol.
FINALLY: don't get me wrong, there are things wrong with X. However most of the things mentioned in this article are not in that set.
Earlier quoted context omitted.
...but why? In my experience, using H.264 to encode screen captures gives you extremely high quality video for reasonable CPU and network expenditures. Is the last 1% of video quality really worth it? For a demo, you can try using FFmpeg + x264 using the x11grab input. It's very easy to adjust the amount of CPU used (by changing the preset) and the bandwidth (by changing the CRF, or by setting the bit rate).
Lossless encoding is important for text, especially sub-pixel antialiased test.
Keep in mind that H.264 does not have to be 4:2:0, it can easily be 4:4:4.
Earlier quoted context omitted.
Sure, but I assume this would mean Haskell bindings for Wayland first, which as far as I know don't exist yet.
In Wayland architecture, the window manager is the display server. To provide wayland-XMonad, you don't need Haskell bindings, you need an implementation of the protocol in Haskell. This isn't as horrible as it sounds, because unlike X, the display server in Wayland is pretty tiny. The current implementation is like ~10k lines. I expect it to fit in sub 3k lines of Haskell. :)
This hearkens back to the days of DOS video games – what fun it was to implement support for everyone's sound card! Instead now we'll get to support KMS, Quartz, whatever-the-heck *BSD uses, etc.
One key feature of X that Wayland refuses to implement is the concept of remote access. Everything is intended to be local only. For those "strange" users out there who want remote access, the developers replies has so far been to use VNC. Its kind of odd that remote access has been shoved to the side in this age of cloudiness and always connectedness. One would think that there existed better methods to remote acces…
From what I understand, modern X applications run remotely are just painting a region of bytes to be shot over the wire anyway. I'll borrow X terminology for a second here, what functional difference is there between these two approaches: X client -> (network) -> X server Wayland "client" -> wayland intermediary "server" -> (network) -> wayland intermediary "client" - wayland server I get the feeling that the pushbac…
User -> Interface -> X Server -> Network -> X Client
The huge functional difference (in terms of what you describe - no idea if that's how Wayland intermediary whatever will actually work) is that with X you do not need an X server running or even configured or even installed on the system the client application is running on - only on the system it is displaying to. This may or may not be significant, depending on how lightweight and portable and easily (and flexibly) configurable the Wayland server winds up being.
Earlier quoted context omitted.
In Wayland architecture, the window manager is the display server. To provide wayland-XMonad, you don't need Haskell bindings, you need an implementation of the protocol in Haskell. This isn't as horrible as it sounds, because unlike X, the display server in Wayland is pretty tiny. The current implementation is like ~10k lines. I expect it to fit in sub 3k lines of Haskell. :)
And this is my primary issue with Wayland. I cannot fathom why anyone would think it's a sound design decision to bundle a hardware-independent component (the window manager) with a hardware-dependent component (the compositor). This hearkens back to the days of DOS video games – what fun it was to implement support for everyone's sound card! Instead now we'll get to support KMS, Quartz, whatever-the-heck *BSD uses,…
I was sold on Wayland in terms of technology a while ago. Where Wayland is losing people is when is it going to be ready to use? Sure, you can install Wayland now, but there are no applications that target it. Yes, XWayland is meant to solve this problem. But, XWayland is not ready yet (or is it?) and Wayland is still "just around the corner." That may be for legitimate reasons, but it's what the article really shoul…
Wayland is a critical technology for Linux desktop community. X11 has been a reliable workhorse, but its time is up - simply too much cruft accumulated over the years that's not even used anymore. Yet all of it needs to be continually supported, adding to complexity. No one uses X11 primitives for drawing apart from bitmap functionality - even repainting dirty regions (expose events) often involves sending over a new…
The bad point is that not support OpenGL, so 3d software can be used via NX.