Most visited posts/pages in the last 24 hours
A listing of random software, tips, tweaks, hacks, and tutorials I made for Ubuntu
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:
So with the display server acting as a proxy of sorts, it becomes possible:
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 .
A rather long time ago (around a year and a half), I wrote a post about a system I was making which was supposed to be a cloud-based OS, named CosmOS. I didn’t really develop it that much, as I had a rather vague sense of what I wanted to do with it, and I immediately had problems with implementing the most basic concepts. Most of the idea was actually quite boring, and had already been developed by others. But since I had gone through all the trouble of making a tool for creating it (relinux), I decided to try it anyways, and just radically changed the whole design. And I did. I also found that I couldn’t have used the same name, as CosmOS was already the name of at least two different OS’s, and it was also the name of a directory of linux OSs (among other unrelated usages), so I kind of got that I had to change the name.
The name is actually based on two words, Synergy and Lithosphere (I was going to call it LithOS, but it sounded like some kind of boring scientific and/or business-oriented OS, if you know what I mean). I know, kind of an odd combination, and the reasoning for it is a quite far-fetched, but heck, it’s an unused name, and it sounds cool! Lithosphere was used as a creative way to say “ground”, because it’s not cloud-based (unlike CosmOS, in fact), and it’s also designed to be “down to the ground” with you. Instead of you adapting to the OS, the OS adapts to you (will explain how this works later). Also, the Synergy part is because since it’s completely with you, it allows nearly everything to be done much easier and simpler, reducing the amount of time both the users AND the developers need to do nearly everything (except for the engine… :-/).
The OS itself is principally designed under the following goals:
There is only one software that I’m aware of that does this well: Minecraft (creative mode). Okay, forget the productive element, but still, anyone can pick up the pace on how to use minecraft extremely quickly. Also, if you’ve ever played it, you’ll know how easy it is to collaborate on building something. You don’t need to use a VCS like git or mercurial to build something. Just get someone else on your server, and build together!
That’s kind of my idea with SythOS. You are inside a 3D environment, windows are mapped to 3D surfaces (I had this idea from Wolfenstein Qt, but it appears to already have been implemented: http://www.youtube.com/watch?v=_FjuPn7MXMs), and the environment is modifiable, using a minecraft-like in-game “level editor”. Other people can connect to your computer (if you allow them, of course), and then you can work together on projects (such as coding, audio, video, or even games) at the same time! Of course, for this to be effective, you have to have somewhat compatible software (you can’t both work on the same window for rather obvious reasons), but even if the software you use isn’t “compatible”, taking turns, and being able to see what the other is doing real-time is still way easier than using some kind of VCS or worse, emailing files back and forth, right? Also, with the chat and mic/audio features that are planned, you can also make meetings and/or “calls” (kind of like skype does, except without the video) within it.
Here’s a list of features that are definite:
Other features that are planned, but not definite would be:
Now for the point of this post (the reason why I’m writing it): Would you use something like this? If so, or if not, why? Any ideas and/or comments on this?
About the possibility of it being implemented, I know that it is possible, but I’m not sure how much time it’ll take me to do all of this (and I’m not sure if I’ll have the stamina needed to do this). I’m planning on releasing a prototype by the end of this summer (2013) though.