Should a display server contain a drawing API ?

chomwitt · 2023-12-22 13:47:31

Trying to make better sense of Wayland vs X11server comparison the more i read the more confused i feel.
So i figured to try to approach that as general as possible.

What is a display server? Wikipedia says:

A display server or window server is a program whose primary task is to coordinate the input and output of its clients to and from the rest of the operating system, the hardware, and each other.

So when a resource (graphics memory GM) is shared ,then not having a process to coordinate the GMRequests coming from different user apps would mean basically that there is not rules imposed and each program could draw everywhere and anytime. So i guess that is the most fundamental restriction that somehow it must be imposed .

A user program should not be allowed to draw anywhere it wants!..

So the most rudimentary display server should accept requests from GM-clients and have a fixed partition of its GM. That elementary GM would accept only lets say 4 apps. Also the GM would need to impose a certain data format to the incoming GMRs and being able to send the appropriate formatted-typed request to the OutputGraphicsDevice Drivers (OGDD).

Lets say someone wants to implement that rudimentary DS ..lets call it :Nucleus Harmony Display Server (NHDS) .
Assuming also the simplest b/w OGD supporting one resolution how difficult would be to implement it ?

Should NHDS support also a drawing API ? If not should it support drawing API's as extensions or leave a user app draw whatever it likes directly to the portion of the GM thats was handed to it ?

Also what is the relation of NHDS to the kernel ?

Sure NHDS must access OGDDs . But does it need something more? Access to memory ? To filesystem ? But if kernel controls access to memory how GM is different ? Isnt it memory ? Isnt that strange ? Kernel mediates and supervise access to memory to hundrers of processes and GM supervision could be NOT part of the kernel ?

Last edited by chomwitt (2023-12-22 14:18:13)

siva · 2023-12-22 16:49:02

Assuming also the simplest b/w OGD supporting one resolution how difficult would be to implement it ?

It may take some elbow grease.

Should NHDS support also a drawing API ?

yes.

should it ... leave a user app draw whatever it likes directly to the portion of the GM thats was handed to it

no.

Also what is the relation of NHDS to the kernel ?

Minimally, it should only provide the bare-minimum interaction with the kernel (only if/when absolutely needed) on behalf of the clients. The end result should enforce the least-privilege principle for any client that interacts with the display server. See the architecture diagrams here: https://wayland.freedesktop.org/architecture.html

Sure NHDS must access OGDDs . But does it need something more? Access to memory ? To filesystem ? But if kernel controls access to memory how GM is different ? Isnt it memory ? Isnt that strange ? Kernel mediates and supervise access to memory to hundrers of processes and GM supervision could be NOT part of the kernel ?

I would look into the X11 and Wayland source code in order to answer these questions.

You may also want to research how the Android API exposes some bare-metal GPU functionalities in C++, keeping an eye on how this approach enforces a least-privilege principle with respect to the Android API and kernel relationships. https://developer.android.com/games/agd … e-graphics

chomwitt · 2023-12-22 20:06:02

siva wrote:

Assuming also the simplest b/w OGD supporting one resolution how difficult would be to implement it ?
It may take some elbow grease.
Should NHDS support also a drawing API ?
yes.
should it ... leave a user app draw whatever it likes directly to the portion of the GM thats was handed to it
no.

But why should it have a drawing api ?

quickfur · 2023-12-22 20:30:59

Depends on what you include in said drawing API.

siva · 2023-12-22 20:51:39

chomwitt wrote:

But why should it have a drawing api ?

I misunderstood your intention. I think what you're asking about is closer to Cairo or DRM. If so, have a look at how X11/Wayland approach them to get a better idea of whether it makes sense for your (hypothetical?) use case.

Have a look at these articles:

- https://en.wikipedia.org/wiki/Direct_Rendering_Manager
- https://www.uninformativ.de/blog/postin … NG-en.html
- https://unix.stackexchange.com/a/596895
- https://news.ycombinator.com/item?id=20379336

Last edited by siva (2023-12-22 21:05:56)

chomwitt · 2023-12-23 08:53:23

quickfur wrote:

Depends on what you include in said drawing API.

By drawing API i had in mind primitives shapes like drawline , drarcircle , printtext , etc .

I've read that wayland protocol doesnt include such drawingAPI and i wonder if we're playing with words and boundaries.

I mean, lets say in a wayland based compositor i create a drawing API library for the wayland clients with the same primitives as X11 . So we can say then that wayland is more minimal protocol and more flexible and maybe more modular since it could accomodate more drawing APIs than X11 ?.Or we can say that there is no big difference , and that even X11 can by extensions accomodate thirdparty drawing APIs but it has a default one?

Last edited by chomwitt (2023-12-23 10:56:46)

chomwitt · 2023-12-23 11:30:25

siva wrote:

chomwitt wrote:
But why should it have a drawing api ?
I misunderstood your intention. I think what you're asking about is closer to Cairo or DRM. ....

Thank you very much for the links!
My intention is to find a more coherent way perhaps to make sense of display servers and the pros and cons. Now , i read about wayland vs x and my head aches.

I found thought that quote from LPC: Life after X by Jonathan Corbet (05/11/2010):

But things have changed in the 25 years or so since work began on X. Back in 1985, Unix systems did not support shared libraries; if the user ran two applications linked to the same library, there would be two copies of that library in memory, which was a scarce resource in those days. So it made a lot of sense to put graphics code into a central server (X), where it could be shared among applications. We no longer need to do things that way; our systems have gotten much better at sharing code which appears in different address spaces.

So that it's interesting. X server's drawing functionality being part of the display server because the other option (each client having the drawing api as a staticaly linked lib) would put pressure on memory usage.

So we have architectural choice (on display server) based on a resource constraint. A resource constraint leads to simpler designs with less choices (less drawing apis).
We dont want each app to have each own drawing api. Choices and variety is not inherently bad but need memory.

In that light we could say that the choice to leave a drawing API outside a DS protocol makes the protocol compatible with a computational enviroment that can support and-or want more choices. Interestingly focusing only on the drawing api it seem that the wayland protocol is more unix-like .

The fun part is that X didnt include UI toolkits (in contrast to other window systems of the 80s like SunView 'selling' that as a feature of the 'mechanism not policy' mantra !

Wait a minute! .. We have a memory restricted enviroment and we say lets dont put drawing APIs in the clients (in contrary to the 'mechanism not policy' mantra ) BUT lets allow clients to have UI toolkits because we promote the ''mechanism not policy' mantra ! ...

Last edited by chomwitt (2023-12-23 16:21:04)

chomwitt · 2023-12-24 14:13:40

Thinking it a little more i think i can try a first answer to one of my questions:

Also what is the relation of NHDS to the kernel ?
Sure NHDS must access OGDDs . But does it need something more? Access to memory ? To filesystem ? But if kernel controls access to memory how GM is different ? Isn't it memory ? Isn't that strange ? Kernel mediates and supervise access to memory to hundreds of processes and GM supervision could be NOT part of the kernel ?

If we assume that each user has his own graphical workstation with certain resources then we could say that the X server is a part of distributed OS . Lets call it Z !

The reason X wasn't part of an OS at the start and afterwards could be that it was running closer to the resources that it was meant to supervise.
But we could draw new imaginary user-kernel boundaries and imagine that a user program calls a distributed OS's (Z) services to access an Xtty . And Z would initiate calls to its X part running at a remote workstation . Like drawpolyarc(x,z..,IDwindow,IPworkstation).

Also in project Athena they wanted that part (X server) to be independent of the OS of the available IBM and DEC workstations. So there lies the second part of my answer:

The weak to non-existent organization-integration coupling of two OS is manifested in the weak integration (towards either or those OSes) of a new software component that must work with both of these OSes.

So my guess is that all those 'merits' that were advertised back then for X (device independence, minimal dependence of server,network transparency) cant be part of Wayland not because of technology efforts but because of organizational issues .

All that effort that was put in Project Athena , ( ref2 , ref3 ) to coordinate MIT,DEC,IBM and infuse in the project a future flexibility in integration with various third party systems can not be found in the efforts and motives that initiated the Wayland project.

One the one hand i feel an aura or coolness towards X and its "environment" that gave rise to it. But i see that even MIT Athena has move to other Virtual Desktop solutions instead of trying an X12 or Z solution.

So i guess that the libre community must try to maintain X and keep it's culture alive. Wayland is a solution that maybe needed for a desktop centric view of personal computing but it maybe not the road that must be taken for a networked-interconnencted approach . Maybe X can find a better home inside a push for distributed-micro-kernel OSes.

GM: Graphics Memory
NH-DS : NucleusHarmonyDisplayServer
OGDD: Output Graphics Device Driver

Last edited by chomwitt (2023-12-24 15:03:45)

chomwitt · 2023-12-30 20:39:43

Regarding the relation of a display server and a kernel i found some interesting ideas in a design article
about Whitechapel MG-1 's windowing system:

One of the major problems in the design of a window management system for a Unix operating system is that of determining the degree of functionality to embed in the kernel. Ideally, very little of the window management system would be represented in the operating system kernel; but because of the inadequate inter process communication mechanisms and susceptibility to scheduling delays under heavy load such a system would not offer fast enough feedback for a good user interface.

ref

Now compare that thinking with the VS100 -thin- workstation leaflet :

You already own the best possible foundation for a technical workstation - a VAX computer. The VAXstation 100 workstation terminal is a subsystem you can add to your VAX system as a low-cost practical alternative to a stand-alone workstation.

Last edited by chomwitt (2023-12-30 20:51:32)

The officially official Devuan Forum!

#1 2023-12-22 13:47:31

Should a display server contain a drawing API ?

#2 2023-12-22 16:49:02

Re: Should a display server contain a drawing API ?

#3 2023-12-22 20:06:02

Re: Should a display server contain a drawing API ?

#4 2023-12-22 20:30:59

Re: Should a display server contain a drawing API ?

#5 2023-12-22 20:51:39

Re: Should a display server contain a drawing API ?

#6 2023-12-23 08:53:23

Re: Should a display server contain a drawing API ?

#7 2023-12-23 11:30:25

Re: Should a display server contain a drawing API ?

#8 2023-12-24 14:13:40

Re: Should a display server contain a drawing API ?

#9 2023-12-30 20:39:43

Re: Should a display server contain a drawing API ?

Board footer