lkubuntu

A listing of random software, tips, tweaks, hacks, and tutorials I made for Ubuntu

Follow up on the non-windowing display server idea

Note: I’m sorry, this post is a bit of a mess.

I wrote a post 2 days ago, outlining an idea for a non-windowing display server — a layer that wayland compositors (or other programs) could be built upon. It got quite a bit more attention than I expected, and there were many responses to the idea.

Before I go on, I wish to address a few things that weren’t clear in the original post:

The first being that I am not an ubuntu developer, and am in no way associated with canonical. I am only an ubuntu member :) Even though I don’t use ubuntu personally, I wish to improve the user experience of those who do.

Second is a point that I did not address clearly in the original post: One of the main reasons for this idea is to enable users to modify the video resolution, gamma ramp, orientation, brightness, etc. DRM provides an API for doing these operations, however, AFAIK, you cannot run modesetting operations on a virtual terminal that is already running an application that has called video modesetting operations. In other words, you cannot run a DRM-based application on an already-running wayland server in order to run a modesetting operation. So, AFAIK, the only way to enable an application to do this is to write a sort of “proxy” server that handles requests, and then runs the video modesetting operations.

Since I am currently confusing myself re-reading this, I’ll try to provide a diagram in order to explain what I mean.

If you want to change the gamma ramp, for example, this is impossible:

drm_client_wayland

So with the display server acting as a proxy of sorts, it becomes possible:

drm_client_display_server

This is also why I believe that having a server over a shared library is crucial. A shared library would allow for abstraction over multiple backends, however, it doesn’t allow communication with more than one application. A wayland compositor can access all of the functions, yes, but wayland clients cannot.

The third clarification is that this is not only meant for wayland. Though this is the main “client” I have in mind for this server, it isn’t restricted to only wayland. The idea is that it could be used by anything, for example, as one response pointed out, xen virtualization. Or, in my case, I actually want to write clients that use this server directly, without even using a windowing server like wayland (yes, I actually have a good reason for wanting this XD ). In other words, though I believe that the group that would use this the most would be wayland users (hence why I wrote the original post tailored towards this), it isn’t only meant for wayland.

There were a few responses saying that wayland intentionally doesn’t support this, not because of the reason I originally suspected (it being “only” a windowing protocol), but because one of wayland’s main goals is to let the compositor to have full control over the display, and make sure that there are no flickers or tearing etc., which changing the video resolution (or some other modesetting operations) would undoubtedly cause. I understand and respect this, however, I still want to be able to change the resolution or gamma ramp (etc.) myself, and suffer the consequences of the momentary flickering or whatever else. Again though, I respect wayland’s decision in this aspect, so my proposal, instead, is this: To make this an optional backend for wayland compositors. Instead of my original proposal, which was to build wayland compositors on top of this (in order to help simplify the stack), instead, have this as an option, so that if users wish to have the video modesetting (etc.) capabilities, they can use this backend instead.

A pretty large concern that many people (including myself) have is performance. Having an extra server on the stack would definitely have an impact on performance, but the question is how much.

So with this being said, going forwards, I am currently working on implementing a proof-of-concept prototype in order to have a better sense of what it entails, especially in regards to performance. The prototype will be anything but production-ready, but hopefully will at least work … maybe XD .

Advertisements

One response to “Follow up on the non-windowing display server idea

  1. oiaohm August 28, 2015 at 9:09 am

    Not sane. Please remember you have more than one TTY that you can open a full environment on under LInux.

    Client calls setgamma Wayland server you have happens to be incompatible with change so decides to crash and someone has it call out to logind to clean up session.
    –however, I still want to be able to change the resolution or gamma ramp (etc.) myself, and suffer the consequences of the momentary flickering or whatever else.–
    I hope the suffer consequences include logged out and data lost.

    Like it or not running side a Wayland compositor means you need Wayland compositor permission to-do things to make sure your change is not Wayland compositor incompatible.

    –This is also why I believe that having a server over a shared library is crucial. A shared library would allow for abstraction over multiple backends, however, it doesn’t allow communication with more than one application.–
    Driver is better than Server. Fuse/Cuse base driver would do it. Its all todo with how time-slices are handled. But its also looking at what servers you have already.

    kdbus that still is not merged into Linux is about allowing time-slice sharing from calling application to processing server part but this will not be on BSD any time soonl.

    Instead you design client application that it can function under wayland or run directly on DRM and libinput.

    –Or, in my case, I actually want to write clients that use this server directly–
    If you are after to interface directly why not just use pure libdrm and libinput and put the application on its own tty. cntrl-alt-f* are all tty slots yes 12+ of them. Each tty can run it own independent x11 or Wayland or Terminal instance.

    There is a multi-seat solution in logind.
    http://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/

    Yes it possible to call out to logind and spawn another seat running a program in its own graphical environment. Of course a program spawned out on its own TTY now can use libdrm how it likes because its no longer under the Wayland server. For copying pasting from Wayland to the spawned out instance you will need to leave a proxy application under Wayland Server.

    The reality is putting a server under wayland compositor messing with libdrm setting without approve of the compositor is just playing with fire when you can just spawn on independent tty and display safely.

    KMSCON https://wiki.tizen.org/wiki/Kmscon_usage for instance are using DRM at the same time as Wayland. TTY spitting is what DRM does.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: