I guess. Maybe. At any rate, my latest secret project, is no longer secret: Phoronix ran an article about Wayland and slashdot in turn picked it up. They got the headline wrong, though, it's not a new X server, it's a tiny display server + compositing manager. And it's a very young project with a lot of FIXMEs and hand waving.
The core idea is that all windows are redirected, we can do all rendering client side and pass a buffer handle to the server and the compositing manager runs in the display server. One of the goals is to get an X server running on Wayland, first in a full screen window (like Xnest), then rootless, since X just isn't going aways anytime soon. Many more details in the NOTES file of the project.
11 comments:
Will there be a project called Yutani as well?
Look at Syllable graphical server. I think it's what you need.
This is one of the most signifcant developments in the opensource world of the last 15 years.
FOR THE LOVE OF GOD, DON'T STOP.
besides quoting zolaenola ;)
and whishing you the best for this project,
i'd just ask, please...PLEASE... use common APIs wherever possible (like khronos' EGL for graphic context management)
Look at Syllable graphical server. I think it's what you need.
uhm, maybe not - AFAIK the desktop in not opengl - composited on Syllable, and the system provides for server side widgets
that's not the same thing ;)
Well, extending X protocol forever kinda sucks. You have to rewrite toolkits to use additions (like client window management).
So a rework can make sense, especially if you are moving to object oriented protocol which doesn't fit very nicely as extension. Of course it _has_ to be able to work in parallel with X11 (or nest it), that is clear.
For the future, please think hard if it makes sense to design for things like disconnects/reconnects (discoverability, migration?). Probably nice way to do this is through client side library which hides connection state from application, asks for redraws when necessary, and allows the app to run when disconnected (async API).
This approach probably allows also transparent compression (images?), maybe some sort of round-trip caching (like NX), proxying of multiple clients (again NX), encryption and all the auth/security stuff (though ssh does this well).
And a few more brainstormed ideas :)
-broadcasting to multiple servers (maybe with possible "live" migration of input)
-sharing/publishing object ID's with other userspace services like PulseAudio (for migration)
-providing networked clients like media players with latency information (no idea how this is in X though).
Good work!
Will there be a project called Yutani as well?
It would have to be renamed to Weyland first.
Good luck with the project, though.
as i said before, i find this project utterly promising, and a revolution in the making, and i care about it even more since i've been planning a project of mine centered on merging the graphic context manager and the window manager, too
i'd really like to see it become a lightweight replacement for both Compiz AND X.org, but some details from the NOTES i find a bit odd...
The actual compositor will define a fair bit of desktop policy and it is expected that different use cases (desktop environments, devices, appliances) will provide their own custom compositor.
since you also mention that the compositor will be built in or integrated with the graphic manager, does this mean that the compositor will actually roll their own compositors as wayland plugins instead of separate programs ? :-)
Include panel and desktop background in wayland?
personally, i see wayland more fit for compiz style features (starting with the more useful ones, like Expo or Scale) or *optional* server side window decoration ( yes, it would add some complexity to the project, but it would ease the process of fitting it into the current ecosystem and give more flexibility to developers and users)
if you're ready to integrate the panel, which typically resides on another process (even on windows), why not replace the current "unix" derived architecture, and embed the graphical login manager or the loading screen ("Plymouth") first? ;-)
( not ironical, i'm truly all for streamlining and consolidation)
How does clients move their surfaces? set a full tri-mesh every time?
i beg your pardon, but... wasnt getting a smooth window move() exploting the (much faster than blit, especially with textured video) GPU's TL (polygon transformation) pipeline, the point of migrating to opengl in the first place?
How does the server apply transformations to a surface behind the clients back? (wobbly, minimize, zoom) Maybe wobble is client side?
imho, the wobble thing must be as transparent to client applications, as possible - same for any other transformation, AND last but not least, the decoupling between application and screen resolution
How do apps share the glyph cache?
at HW level maybe, via a glyph descripting texture or shader?
Drawing cursors, moving them, cursor themes, attaching surfaces to cursors.
isnt this done with texture mapping (i.e changing the u,v coordinates of the cursor's sprite on a full screen quad) today? can't it continue to be done that way?
... if you don't have subwindows?
this aspect i haven't understood - what do you mean by not having subwindows?
that you dont have a scene graph of onscreen application windows?
in this case, i find the decision a bit odd, since a scene graph is most likely to be needed in a compositing window manager, and pretty much useful for pick correlation (since afaik, doing pick correlation on an opengl scene is quite expensive)
Input handling - keyboard focus
again, with pick correlation fixed, that would be a breeze ;-)
moreover, i suspect that some remnant of the X protocol or the ICCCP will find its way in Wayland... if nothing else, how would you do Drag and Drop ? ;-)
That it's not an X is excellent, I think. That's more or less what I thought should be done for a while: something not X11, optimized for the local case, and a rootless X server for it (or, worst case, a windowed X server, but that's much "easier", for some value of "easy").
I won't claim much originality for it, it's mainly Mark Kilgard's D11, and the Display Server on Mac OS X seems to work along similar principles (with the X server a pure client, which isn't a horrible idea, per se, although it could probably be done better). What mostly stopped me is that my expertise in graphics is quite dated (it's all 2D blit type stuff), but someone like you, with knowledge of what's going on in the guts of DRM, seem like just the right person.
Good luck!
Oh, and I haven't looked at exactly the mechanisms you're using, and I figure it's possible you already know all of this, but just to make sure... :-)
If your protocol is local only, you don't need complicated authentication, just use the Unix domain socket LOCAL_PEERCRED.
Also remember you can pass file descriptors over Unix domain sockets as well. Coupled with mmapping the same known offsets on the same instance of a /dev/zero file, you've got relatively straightforward shared memory (none of that horrible SysV shmem junk!). ou can probably only use that for the client to share with the server (sending the fd of some hardcore DRM device would probably not be safe, but I'm guessing DRM has its own ways, for direct rendering is pretty much this).
As much as this pains me, whatever they call the lowest level graphic API for Mac OS X (Quartz Extreme? CoreGraphics? CocoaPuffs?) has some good ideas to pick out, but are not to be lifted wholesale either. As a (2D) game developer, I liked the programmed blits ("copy this when the beam is past this scanline"), but your API sounds like it could optimize all this internally when the commit is issued, which would be even better.
Make it so we can select() on the input events, for the love of all that is good. It's possible with X11, but it kind of a horrible hack that doesn't look like it's guaranteed to work. Make it clear. You could actually take advantage of epoll and timerfd to bundle up everything that the client deals with as a single fd, and tell the client "here, when this becomes readable, call this function". You provide a callback-driven API, and the callbacks get called as needed when you call the function. Async without a pile of hacks!
I created a google group for wayland discussions over here:
http://groups.google.com/group/wayland-display-server
It's a better forum for discussion than these comments, so if you have input or suggestions, please join the group!
Oh, and no, it wasn't named after the evil mega-corp from the Alien movies :)
It will be GPLed?
I think the most slowdown on the X.Org project is the license.
Put Wayland under GPL and it will fly like a rocket!
Post a Comment