4 ms·

Wayland of course is the present and the future, Xorg receiving only the bare minimum of attention. But I believe that many technologies, protocols, and format

Wayland of course is the present and the future, Xorg receiving only the bare minimum of attention. But I believe that many technologies, protocols, and formats that were commonplace in late 90s/early 2000s are just here to stay forever: X11, BIOS/MBR, FAT32, 32-bit x86 PE, Win32, GTK2, Cocoa... The Linux kernel still runs static binaries built in mid-90s. Judging from the feature list, TinyX hits a very sweet spot for otherwise underpowered or obsolete machines. You can of course spend €50 and get a RasPi that can handle a more complex / demanding stack, but also you can take advantage of the spare power, or just appreciate the architectural simplicity.

johnisgood 2y ago
Wayland still does not for work me for basic stuff though. I will make a list once I try it again but so far I have only experienced issues with it, no issues with Xorg. (And thus, I avoid anything Wayland.)
- rollcat 2y ago
  True, your mileage with Wayland will vary, depending on your HW, distro, compositor, etc. Xorg is more mature (check it), and also this just popped up in my news feed: <https://rubenerd.com/boring-tech-is-mature-not-old/ https://rubenerd.com/boring-tech-is-mature-not-old/> For better or worse, Wayland is where all of the attention is right now, and there already are systems (like Asahi Linux) where Xorg is unsupported. The world will continue moving forward, sticking with Xorg may prove more difficult over time, so TinyX may be of interest even if purely for the sake of continued maintenance.
  - krupan 2y ago
    I like that take on boring tech, and a little like Oracle, I don't think X is boring. Wayland definitely isn't either, but I think it has potential.
    - rollcat 2y ago
      Wayland is both late and early. Late in the sense that OS X has had Quartz from the beginning, and Vista started the move to DWM; meanwhile the Linux community was patting itself on the back because Compiz looked cooler than either of those, and didn't see past the surface. X11 is not only an outdated design, it's also a security nightmare. Early because it's still a mixed bag, and kinda suffers from second system. It's a protocol rather than a library - while it's simpler than X11, it relies heavily on optional extensions for things such as screen capture or even "server" side decorations. Under X11, you could write a spartan-but-functional WM in a 100 lines of C. Under Wayland, a functional compositor needs roughly 50k lines; wlroots can handle most of that, but neither KDE or Gnome uses it, so effectively there's three parallel worlds, with varying level of support for different extensions. Early on, IMHO too much effort went into Weston (the "reference" implementation nobody cares about), and too little into building something like wlroots. It may take a while for the situation to settle.
      - ChocolateGod 2y ago
        > Under X11, you could write a spartan-but-functional WM in a 100 lines of C. Whilst I agree with most your point, you're comparing a window manager and a compositor. I don't think there was any compositor for X that was made with less than 100 lines of C.
        rollcat 2y ago
        Compositors under X11 were about adding drop shadows & translucency to windows, and occasionally inducing motion sickness. A Wayland compositor should be thought of as a display server, like Xorg (plus the WM, minus the legacy cruft). You can still write a pretty compact one with wlroots though. Which is my point. A project like wlroots should have been in the spotlight the same way Xorg was, so that new compositors (or existing X11 WMs) could adopt it easily, and both users and developers could benefit from an emerging-but-stable ecosystem. Instead it took like a decade to standardise and implement screen capture.
        2y ago
- krupan 2y ago
  I detested the idea of Wayland and the way it was marketed for years. Then a few months ago, after some frustration with X that I don't remember, I tried Wayland (with sway, since I was an i3 person) for the first time and have been pleasantly surprised at how well it works. It's not perfect, but neither is X. It does enough things better than X that I've decided to stick with it. To be specific, configuring things like scaling, auto rotation on my laptop/tablet thing (and rotating the touch screen and stylus to match), and automatically using external displays as they are plugged in (with kanshi) has been much easier than with Xorg. Maybe if I was still just sitting at a desktop it would be different, but for these scenarios Wayland is nice.
- sprash 2y ago
  I find it very surprising how well Xorg still works considering it receives essentially zero funding. To me this is a sing of a very robust design. I'm also not surprised at all how bad Wayland is. The protocol makes wrong abstractions at the lowest level which causes problems everywhere else. The worst being massive fragmentation. It wont ever be good despite receiving big amounts of funding. But this is obviously by design.
  - rollcat 2y ago
    > The protocol makes wrong abstractions at the lowest level which causes problems everywhere else. Can you point out any specifics? I think both the low-level operations (allocate some shared memory for a surface, agree on a pixel format, etc) and the high-level features (scaling!) are solid, the holes are mostly in the ecosystem fragmentation/extension support ("can you please draw some window borders for me, thanks?"). If you were designing a modern windowing system from scratch, what would you do differently?
    - sprash 2y ago
      > Can you point out any specifics? How much time do you have? First of all it needs to be much simpler to do simple things. You are right that you need to "allocate some shared memory for a surface, agree on a pixel format, etc" but it shouldn't take 250 LOC just to put a simple window on the screen (look at https://wayland.app/protocols/wayland https://wayland.app/protocols/wayland there is no reason to make bare essential things that complicated). A proper standardized client library should need 1 LOC for that. The whole polling/ping mechanism is completely flawed. Since you don't know how to solve the halting problem please let the user decide if an application is unresponsive or not and reliably kill the pid of the window when the user presses that "x". Until then assume the process to be working. This also means a hard requirement for server side window decorations since they need to be rendered by another process with higher priority (also because temporarily unresponsive windows might occasionally be moved or resized). Windows should also be able to obtain where they are on the screen in relation to other windows from other processes. There should also be processes that are allowed to read out and modify all window positions (e.g. for window managing and automation). Also processes should be able to read image data from screen or other windows (e.g. for screen sharing). Standardized interfaces and proper access control for all latter things should be baked into the protocol from day one and not rely on non-standardized external infrastructure (like dbus/portals). And those interfaces should be as simple as possible. Latency is generally bad on Wayland. The mouse pointer should be rendered by a separate thread on its own hardware layer which requires no vsync. Keyboard input events should be able to immediately update dirty rectangles disregarding vsync for those pixels to make typing as smooth as possible. Generally allow tearing for windows by choice of the user/program and be able to have windows that don't allow tearing next to tearing windows at the same time. (I have more but nobody reads that shit anyways.) > If you were designing a modern windowing system from scratch, what would you do differently? Personally I would recreate something like MGR with a modern spin. But this is obviously a very opinionated design.

johnisgood 2y ago

Wayland still does not for work me for basic stuff though. I will make a list once I try it again but so far I have only experienced issues with it, no issues with Xorg. (And thus, I avoid anything Wayland.)

rollcat 2y ago
True, your mileage with Wayland will vary, depending on your HW, distro, compositor, etc. Xorg is more mature (check it), and also this just popped up in my news feed: <https://rubenerd.com/boring-tech-is-mature-not-old/ https://rubenerd.com/boring-tech-is-mature-not-old/> For better or worse, Wayland is where all of the attention is right now, and there already are systems (like Asahi Linux) where Xorg is unsupported. The world will continue moving forward, sticking with Xorg may prove more difficult over time, so TinyX may be of interest even if purely for the sake of continued maintenance.
- krupan 2y ago
  I like that take on boring tech, and a little like Oracle, I don't think X is boring. Wayland definitely isn't either, but I think it has potential.
  - rollcat 2y ago
    Wayland is both late and early. Late in the sense that OS X has had Quartz from the beginning, and Vista started the move to DWM; meanwhile the Linux community was patting itself on the back because Compiz looked cooler than either of those, and didn't see past the surface. X11 is not only an outdated design, it's also a security nightmare. Early because it's still a mixed bag, and kinda suffers from second system. It's a protocol rather than a library - while it's simpler than X11, it relies heavily on optional extensions for things such as screen capture or even "server" side decorations. Under X11, you could write a spartan-but-functional WM in a 100 lines of C. Under Wayland, a functional compositor needs roughly 50k lines; wlroots can handle most of that, but neither KDE or Gnome uses it, so effectively there's three parallel worlds, with varying level of support for different extensions. Early on, IMHO too much effort went into Weston (the "reference" implementation nobody cares about), and too little into building something like wlroots. It may take a while for the situation to settle.
    - ChocolateGod 2y ago
      > Under X11, you could write a spartan-but-functional WM in a 100 lines of C. Whilst I agree with most your point, you're comparing a window manager and a compositor. I don't think there was any compositor for X that was made with less than 100 lines of C.
      - rollcat 2y ago
        Compositors under X11 were about adding drop shadows & translucency to windows, and occasionally inducing motion sickness. A Wayland compositor should be thought of as a display server, like Xorg (plus the WM, minus the legacy cruft). You can still write a pretty compact one with wlroots though. Which is my point. A project like wlroots should have been in the spotlight the same way Xorg was, so that new compositors (or existing X11 WMs) could adopt it easily, and both users and developers could benefit from an emerging-but-stable ecosystem. Instead it took like a decade to standardise and implement screen capture.
        2y ago
krupan 2y ago
I detested the idea of Wayland and the way it was marketed for years. Then a few months ago, after some frustration with X that I don't remember, I tried Wayland (with sway, since I was an i3 person) for the first time and have been pleasantly surprised at how well it works. It's not perfect, but neither is X. It does enough things better than X that I've decided to stick with it. To be specific, configuring things like scaling, auto rotation on my laptop/tablet thing (and rotating the touch screen and stylus to match), and automatically using external displays as they are plugged in (with kanshi) has been much easier than with Xorg. Maybe if I was still just sitting at a desktop it would be different, but for these scenarios Wayland is nice.
sprash 2y ago
I find it very surprising how well Xorg still works considering it receives essentially zero funding. To me this is a sing of a very robust design. I'm also not surprised at all how bad Wayland is. The protocol makes wrong abstractions at the lowest level which causes problems everywhere else. The worst being massive fragmentation. It wont ever be good despite receiving big amounts of funding. But this is obviously by design.
- rollcat 2y ago
  > The protocol makes wrong abstractions at the lowest level which causes problems everywhere else. Can you point out any specifics? I think both the low-level operations (allocate some shared memory for a surface, agree on a pixel format, etc) and the high-level features (scaling!) are solid, the holes are mostly in the ecosystem fragmentation/extension support ("can you please draw some window borders for me, thanks?"). If you were designing a modern windowing system from scratch, what would you do differently?
  - sprash 2y ago
    > Can you point out any specifics? How much time do you have? First of all it needs to be much simpler to do simple things. You are right that you need to "allocate some shared memory for a surface, agree on a pixel format, etc" but it shouldn't take 250 LOC just to put a simple window on the screen (look at https://wayland.app/protocols/wayland https://wayland.app/protocols/wayland there is no reason to make bare essential things that complicated). A proper standardized client library should need 1 LOC for that. The whole polling/ping mechanism is completely flawed. Since you don't know how to solve the halting problem please let the user decide if an application is unresponsive or not and reliably kill the pid of the window when the user presses that "x". Until then assume the process to be working. This also means a hard requirement for server side window decorations since they need to be rendered by another process with higher priority (also because temporarily unresponsive windows might occasionally be moved or resized). Windows should also be able to obtain where they are on the screen in relation to other windows from other processes. There should also be processes that are allowed to read out and modify all window positions (e.g. for window managing and automation). Also processes should be able to read image data from screen or other windows (e.g. for screen sharing). Standardized interfaces and proper access control for all latter things should be baked into the protocol from day one and not rely on non-standardized external infrastructure (like dbus/portals). And those interfaces should be as simple as possible. Latency is generally bad on Wayland. The mouse pointer should be rendered by a separate thread on its own hardware layer which requires no vsync. Keyboard input events should be able to immediately update dirty rectangles disregarding vsync for those pixels to make typing as smooth as possible. Generally allow tearing for windows by choice of the user/program and be able to have windows that don't allow tearing next to tearing windows at the same time. (I have more but nobody reads that shit anyways.) > If you were designing a modern windowing system from scratch, what would you do differently? Personally I would recreate something like MGR with a modern spin. But this is obviously a very opinionated design.