Announcement
Collapse
No announcement yet.
X.Org's GLAMOR Adds Support For OpenGL ES 3.0 Shaders
Collapse
X
-
Well, what do you know? The old girl got a touch-up. It's good that at least someone I too wonder if the X devs will do a massive update toward the end of the year like they did a couple years back. I think quite a few hundred fixes, patches, etc. have accrued since 21.x.x was released, no?
For what it's worth, X will still be around for a while even if it's not getting any more dedicated love. It's long in the tooth but some companies developing on Linux are sticking with X for this, that and the other use cases or for app-specific requirements not yet able to be met by the current state of Wayland. Wayland is certainly the focus of much of the development but let's have this "X Sucks" or "Wayland sucks" argument once Wayland has been around for as many years as X has been. If a couple decades pass and the Wayland development needle hasn't moved all that much, THEN you can start flinging the "I told you so's."
Just cuz you're adept and working on that muscle car with the carbureted engine doesn't mean fuel/direct injection or electric isn't staring you down. If X works for you, rock on. If Wayland works for you, rock on.
- Likes 1
Comment
-
I think I actually wrote to him once but he ghosted me. I was tracking some github page where they were tracking bugs, fixes, etc. but I can't find that damn page to save my life.
- Likes 1
Comment
-
Originally posted by ezst036 View PostMichael should write up a new News article for Phoronix.com about how Konstantin Pugin as stepped up to be the new interim maintainer for X.org. /sarc
- Likes 3
Comment
-
Originally posted by kpedersen View Post
*Development* on Xorg is pretty much complete because frankly displaying pictures on a screen was a solved problem back in the 80s.
Wayland is basically yet another Marvel superhero film reboot that no-one needs, yet keeps the public amused
- Likes 4
Comment
-
Originally posted by kylew77 View PostCouldn't agree more. I find a lot I agree with you on kpedersen.
- Likes 9
Comment
-
Originally posted by Hibbelharry View Post
Never got the feeling your Commodore C64 is getting a bit slow surfing the web? Computers was a solved problem back in the 80s, nothing changed in that few years so I guess you didn't adapt.Last edited by kpedersen; 18 October 2023, 02:53 PM.
- Likes 3
Comment
-
Originally posted by RejectModernity View Post
Low IQ puts people off Wayland, not bants on the Internet.
- Choice: You only got three choices. KDE (which is good but they have a reputation for instability, and KWin's been getting slower), GNOME (which may be the forefront of Wayland development, but has questionable UI design decisions... some people manage to accustom though) and do-it-yourself (Sway, Hyprland, Wayfire, Weston, Mir, Liri, Labwc, and others in where you bring in all components but the majority of them feel very technical and configuration involves editing a bunch of files.... oh, and the endless stream of tiling window managers, which are anything but Average Joe-friendly). Each of these have advantages and disadvantage, such as lack of server-side decoration support (GNOME), no HiDPI XWayland without patches (do-it-yourself), lack of protocols for advanced features (GNOME) and so on.
- Protocol fragmentation: Things which were missing (for "security" reasons) are now (mostly) fulfilled by several other protocols or means, but many of these are implementation-specific and do not work on all compositors.
- For example: (screenshot)- wlr-screencopy is wlroots-exclusive.
- weston-screenshooter only works on Weston
- PipeWire works on GNOME and KDE, but may not work in other compositors
- DRM/KMS and DMA-BUF work on all compositors, but not on NVIDIA. It also doesn't work if a compositor is running nested (on X11 or Wayland for example). Capturing the cursor is also difficult since there's no API to get the cursor position at a DRM level.
- Another example: (data query, window management and all)- wlroots provides an API, and wlr-foreign-toplevel-management, but again, exclusive to wlroots.
- GNOME provides AT-SPI2 but it's very limited.
- I am not sure what does KDE provide...
- Aaaaand a final example: display configuration. X.Org implements RandR (which can be accessed through xrandr), which works on all desktop environments and window managers. Now look at Wayland:- GNOME: Mutter provides a D-Bus interface for it.
- KDE: There's KScreen, but Plasma 6 will deprecate it in favor of KWin's D-Bus interface.
- wlroots: wlr-output-management. It works.... only on wlroots.
- Weston doesn't even
- NVIDIA: I don't think this one needs explanation. All I can say is that it partially was NVIDIA's fault.
- Implementation bugs: crashes, HiDPI scaling (particularly XWayland), input getting stuck (reproduced on Wayfire), mouse click treated as a key and invoking key repeat (on Wayfire again), and so on...
- No standard solution for color management - see Protocol fragmentation
- tearing-control still not supported by wlroots, the only amazing Wayland implementation library
It is now possible to use a Wayland session as daily driver, but it's still lacking...Last edited by tildearrow; 18 October 2023, 08:32 PM.
- Likes 11
Comment
Comment