OSDev.org

Is there a minimal display server available that can be used for study.

The main ones seem to be (based on Wikipedia entries):

• X11 (Linux)
• Wayland (Linux)
• Mir (Linux)
• SurfaceFlinger (Android)
• Quartz Compositor (Mac)
• Desktop Window Manager (Windows)

None of these have a small code base. Is there a "tutorial-like" display server out there, that has the barest minimum of what's needed to get the most basic functionality?

As a side note, I would like to point out that X11 is not specific to Linux (or Unix in general), and it isn't strictly a display server in and of itself - it is a protocol for communication between programs and remote display servers. While X11 is usually used as a local display server today, it was originally meant for many-to-many networked program/display interfaces. It was developed from an earlier system called W, and was developed on a few different experimental OSes before being ported to Unix in the late 1980s.

This approach to networked UI has largely been abandoned, but X was already semi-standardized as a Unix display manager when Linux came along, so it was adopted almost immediately by Linux devs.

Why is this relevant? Because X Window System still has a lot of code which has little if anything to do with display. A large part of why Wayland (and Mir, which was specific to Ubuntu and has now been largely abandoned AFAICT) exists is to drop all the part of X which simply aren't necessary for the most common use as a display manager.

The good news about X is that it is mature and well documented. The bad news is that it is immensely complex, and much of that complexity is not relevant to display services.

quadrant wrote:Is there a "tutorial-like" display server out there, that has the barest minimum of what's needed to get the most basic functionality?

As far as I know, no! It's up to you and me to develop such thing on our own. Again: As far as I know.

I try to develop a minimal graphics stack. This means layers from handling the hardware stuff, through handling windows, fonts, pictures up to window managment (overlapping, messaging). I have a design ready for this graphics stuff, but I know that sometimes plans don't work the way they were ..well, planned.

What I'm trying to say: I think you should develop a graphics stack yourself. Okay, that's just my opinion.

Greetings
Peter

quadrant wrote: Is there a "tutorial-like" display server out there, that has the barest minimum of what's needed to get the most basic functionality?

Wayland is probably going to be as minimal as it gets.The design is pretty simple: The server accesses the frame buffer and the input devices directly, and the clients only paint what they display into shared memory. There is little that could be removed from it without destroying functionality that is needed. That said, I have not looked at the source myself, so I don't know how much fluff there is.

PeterX wrote:What I'm trying to say: I think you should develop a graphics stack yourself. Okay, that's just my opinion.

That is one possibility, but then there is no shame in listening to Bismarck and learning from the mistakes of others, since you don't have the time to make them all yourself. My goal is to have the kernel provide access to a frame buffer and input devices, and let userspace actually do something with it. And a program like Wayland, that does just that, will come in very handy, once I am that far along.

@Schol-R-LEA Thank you for the clarification!

PeterX wrote:I think you should develop a graphics stack yourself

The end goal would be to do so. However looking for a little bit of guidance on the communication part. For example, I have a rough understanding of the,

• hardware interface part because of tutorials like James Molloy's Kernel Tutorial
• window and widget rendering part because of tutorials like WSBE and FYSOS

@nullplan The Wayland code is too much for the simple overview I'm seeking.

Thanks everyone for your input. If I come across anything, I'll post it.

I don’t know how helpful it will be for you, but you can take at my compositor.

klange wrote:I don’t know how helpful it will be for you, but you can take at my compositor.

Oh, it's only one file?! Will definitely have a look, thanks for sharing!

quadrant wrote:Oh, it's only one file?! Will definitely have a look, thanks for sharing!

There's also the client library and various headers like the main one describing the protocol. You probably also want to look at a sample client application, or maybe something a bit more complicated. While it uses my kernel's homebrew IPC and shared memory subsystems, it should be portable to something like Unix sockets/shmem (and someone did this once, but it's both very outdated and I can't find the source for the ported version anyway).

The code looks rather clean to me, good job!

A general note: One thing that all modern windowing protocols have in common is that they use shared memory to transfer window buffers to the compositor. Unless you have access to accelerated blitting functions, you should also map the framebuffer (and backbuffer, if it's in video RAM) directly into compositor. Performance-wise, these are the most important optimizations (but do not forget to turn on write combining). Being a network protocol, X11 (without extensions) gets this "wrong".

@klange Thank you for the additional links!

@Korana Thanks, will keep that in mind!