On Fri, 10 May 2024 11:11:54 -0500, Zach Metzinger wrote:
On 5/7/24 23:55, Lawrence D'Oliveiro wrote:
So, X11 development has been moribund for years. All the major GUI
environments are adding Wayland support now.
X11 is full of legacy cruft, like that graphics API (at least the font
server API went away years ago).
.. but does it work "well enough"? Yes.
So many promises over the years of something better, but none have
displaced X11.
Remember this one?
https://github.com/graydon/berlin
Oh. My. Gosh. I remember this, and have been looking for an archive for
the last decade. Was unfortunate on the license choice tho. Ta very much
for sharing.
I was more interested in another project that started as General Graphics
Interface (GGI)[1], a project to correct video terminal (UI/UX)
integration with Linux, later FreeBSD, and other platforms. Think of a
limited gstreamer for display/rendering engines. It evolved into two
separate projects, the next being Kernel Graphics Interface (KGI)[2]. KGI
was truly an amazing engineering feat like Fresco, both examples of
engineering, and technical advancements not able to destabilise the
clapped out bandwagons at the time.
KGI aimed to finally fix the video terminal integration with kernel mode
setting, and a portable modular driver framework (KGIM) for writing
drivers, similar to the Uniform Driver Interface (UDI)[3], it was
engineered for monolithic or microkernel systems. No more problems
switching between X, or a vty. There was a X server XGGI that used this
system. It was light years ahead of it's time, and today we are still far
off reaching the aims of those projects, tho, it is obvious that
portability, and diversity is not a goal anymore.
I would love to know why Wayland, or how it came to be, to push the
complexity of compositing further out from the Display Server into the
client, like the window manager. Why is the complexity moved up the
software stack, instead of down, into the core. The clients of a software
system should be simpler. Personally, I think the WM should be part of the
Display Server, to facilitate tighter syncing with the scanout. But then
you probably lose the diversity of window managers.
As was mentioned elsewhere, X should not be muxing the display hardware,
the OS should be muxing display and events, X should be getting a generic
framebuffer provided by the OS, for example by KGI.
On FreeBSD, none of my AMD, or Intel GPUs can handle switching to the vty
from X, or even display suspension, the graphics become fucked, input
still works, but who knows what chat or Usenet group I am posting my
financial institutions login details to.
1:
http://www.ibiblio.org/ggicore/index.html2:
http://kgi-project.org/3:
http://www.projectudi.org/-- To health and anarchy