Wayland, a New X Server For Linux 487
An anonymous reader writes "Phoronix has a new article out on Wayland: A New X Server For Linux. One of Red Hat's engineers has started writing a new X11 server around today's needs and to eliminate the cruft that has been in this critical piece of free software for more than a decade. This new server is called Wayland and it is designed with newer hardware features like kernel mode-setting and a kernel memory manager for graphics. Wayland is also dramatically simpler to target for in development. A compositing manager is embedded into the Wayland server and ensures 'every frame is perfect' according to the project's leader."
Does this... (Score:5, Interesting)
...spell the death-knell of X-based graphics drivers? Does this mean that such drivers will finally be folded into pure kernel modules with no fancy wrappers required? Does that also mean that we can eliminate X as a dependency for playing video games, and using Linux in multimedia or kiosk environments?
Re:Does this... (Score:5, Funny)
Re:Does this... (Score:5, Funny)
...year of Linux at last?
This sentence no verb and no desktop.
Re:Does this... (Score:5, Funny)
Context (Score:4, Informative)
Context for those who need it [fohguild.org]
Re:Does this... (Score:4, Funny)
And that a better X server isn't going to a lot of people to Linux.
There, fixed that for ya.
Re:Does this... (Score:4, Funny)
There, that for ya.
ugh! ug!
Re:Does this... (Score:4, Funny)
u!
!
Re:Does this... (Score:5, Insightful)
Man, we really need OSS drivers.
Re:Does this... (Score:5, Interesting)
Re:Does this... (Score:5, Informative)
I don't understand why you were modded down, when you are technically correct: nVidia's driver stack simply doesn't use most of X.org's API/ABI. There are actually bits and pieces of X that we'd like to deprecate, but we can't because the nVidia blobs need them in order to do their thing.
Re: (Score:3)
Fuck NVidia. Let them fix their binary blob when it breaks. There's a reason it's open source... so people can have the freedom to do the right thing, rather than half-ass backwards compatibility (I'm look at you, win32, and WoW-64 [wikipedia.org]).
Re:Does this... (Score:4, Interesting)
this has stumped me for years (Score:5, Interesting)
We went through the same thing when switching to X.org from XFree86. When will nVidia support it? When will ATi support it? When will my driver be ported?
Why is X dealing directly with the drivers anyway? Why isn't there a thin graphics layer in Linux, like a framebuffer that supports acceleration? Write X to that. Then you can switch your X or use whatever GUI you want and you hardware still works. Freedom to choose, right? The mantra of Open Source?
I remember a bunch of very promising GUIs coming up in the early 2000s that really struggled without enough drivers. "The source is open, just port the thousands of drivers!" yeah sure.
Re:this has stumped me for years (Score:4, Insightful)
Why isn't there a thin graphics layer in Linux, like a framebuffer that supports acceleration?
This is not the reason why it's not done in Linux, but modern graphics cards accelerate some pretty high-level functionality, so your "thin graphics layer" would not stay very thin for long.
Re:this has stumped me for years (Score:5, Informative)
``Why is X dealing directly with the drivers anyway? Why isn't there a thin graphics layer in Linux''
Don't forget that Linux is not the only game in town. X.org suppors Linux, but it also supports FreeBSD, NetBSD, OpenBSD, Solaris, UnixWare, LynxOS and HURD. I think there are actually more, but those are the ones listed in the manpage.
If we do as you propose and make the operating system kernel supply the drivers, drivers would have to be written for all those 7 kernels, instead of just once for X.org. What we have now is exactly how I like things to be: a common driver API across operating systems, so that drivers need be written only once.
Re:Does this... (Score:5, Insightful)
get bent (Score:5, Interesting)
a single distro gaining popularity will be instrumental for standardizing what is expected of Linux for introduction into a larger market
the flaws in your biased & self interested statement are manifest. manifest and hilarious.
first off, i dont see what advantage linux has by gaining a larger market. will these corporate interest invest time and code into linux? will they provide free support to end users? will the people joining your standardized Linux gain anything from the homogenized OS they've switched to?
second, how will standardization improve linux's marketability? to what extend to we enforce homogenization? do we enforce a single wm on all users? do we enforce a single office suite? a single programming language?
third, how do you plan to tell everyone they must work on the same thing? do you think everyone will willingly conform to the standard patterns you wish to impose and stop working on the things they think are cool?
Linux's only strength is that it grants developers an open environment to develop novel new things. all I see in your desire is a self interested bid to crush out the free spirited developer spirit and to replace it with something tooled to replace commercial operating systems with something free, for your own good. honestly I dont think you or your desires contribute anything useful to the linux community, in fact I think the desire to make Linux conform to the expectations of the "typical" desktop has been the worst mistake the Linux movement.
Re: (Score:3, Interesting)
There already is one API to program against if you're a hardware developer who wishes to support Linux. It's called Linux, and it's used by all Linux distributions.
If you are software developer, there are a number of APIs you can choose from that will work across all reasonable Linux distributions.
Really, doing cross-distro work isn't that hard.
What is hard is making your software work on any Linux distro at all if you're going about it the wrong way. Linux isn't about ABI stability, and, with the plethora
Re:Does this... (Score:4, Insightful)
--
</sarcasm>
Re:Does this... (Score:5, Funny)
Getting it into the Ubuntu repos probably wouldn't hurt, either. (Sad that a single distro can have that much influence)
Wow. The Economy must be bad! People are getting their Ubuntus repossessed!
Re:Does this... (Score:5, Insightful)
Re: (Score:3, Informative)
All the really big players keep them in a separate repository. The "biggest" distro that I know that includes them normally would be Gentoo as you mentioned, and Sabayon, a Gentoo off-shoot.
Seems to be in very early development (Score:4, Informative)
Though before you think this will replace the current X.Org Server, Kristian explains "at this point wayland is just a prototype/playground for some ideas I've been toying with."
Re:Does this... (Score:5, Interesting)
But if you're going to "get rid of the cruft", doesn't that suggest that you'd want to move to an architecture that depends on the kernel's graphics subsystem rather than maintaining a zoo of obsolete usermode drivers?
Hardware is the purview of the kernel. Or at least the Hardware Abstraction Layer. (Depending upon your OS's architecture.) Today's X servers still support all kinds of usermode drivers, just so that 95% of configurations can thunk it all to the kernel. Thus there doesn't seem to be much point in providing the graphics drivers in the X server. Better to let the kernel do its job while the X server does its job of drawing the GUI through interpreting a series of abstract commands.
As a bonus, the graphical system becomes available to a variety of programs that desire low-level access to the graphics card rather than running an X server.
Perhaps I'm being naive, but why wouldn't a clean separation between the graphics system and the kernel drivers be an advantageous goal?
Re: (Score:3, Interesting)
Didn't Microsoft do this in NT4, and wasn't it a very bad move for security and stability?
Re:Does this... (Score:5, Interesting)
Microsoft moved the ENTIRE graphical subsystem to the kernel. Which made things faster, but did make them less stable and less secure. (Sun also had an option to take this route in Solaris.) This would be like taking the entire X server and cramming it down into the kernel.
I'm not suggesting anything quite so extreme. Rather, I'm talking about leaving device control in the hands of the device manager (i.e. the kernel or the HAL) and having the X server access the device through a standard driver interface. Much like audio, mouse, keyboard, networking, and storage are all handled by the kernel.
FWIW, Microsoft left the graphics in the kernel. They did add some extra checks to stabilize it, but we're all living with those kernel graphics today.
Re: (Score:3, Interesting)
Doesn't Vista finally move the graphics into userland?
And, the funny thing is, Microsoft's been screwing this up for years now, starting with OS/2 1.1. It was IBM's turn to work with OS/2 1.3, and they quickly moved it out of the kernel. But, Windows NT was a fork of OS/2 1.2, not 1.3.
Re:Does this... (Score:4, Interesting)
Not that I'm aware of. Even the server 2008 kernel (which allows you to boot into a console) has the graphics in the kernel.
Re:Does this... (Score:5, Informative)
No, Vista removed the most complex bits of drivers from the kernel space. In essence, Vista kernel now controls modesetting, command submission, memory allocation and GPU scheduling. Also, some legacy graphics functions and some parts of USER subsystem remain in the kernel, but by now they are very well debugged and stable.
The rest (like compiling shaders and window compositing) is done in user-space.
X.org actually slowly moves to this model.
Re: (Score:3, Informative)
Re:Does this... (Score:5, Informative)
Kernel modesetting is a good thing, but there is no need to put the drivers into the kernel. KMS gets you lots of good things: BSoD (much better than the display freezing with no error message), flicker-free boot, and X could be moved away from needing to run as root.
As far as the drivers themselves, the best thing for them will be the move to the Gallium3D driver model, which will greatly reduce the amount and complexity of code needed to write a new driver. [1][2][3]
Keith Packard talks in his blog [4] about kernel mode drivers, but this seems to be KMS + memory management (GEM or TTM), not having, say, the entire Radeon driver in kernel. I guess it depends on how you define drivers. or maybe the difference between classic 2d drivers and DRM drivers (I have never figured out the details of that)?
>Today's X servers still support all kinds of usermode drivers, just so that 95% of configurations can thunk it all to the kernel.
All X drivers are usermode. There are graphics drivers that are in the kernel (fbdev), but these are unrelated to X.
Note: I am not a X dev or even a real programmer, but I follow X blogs, mailing lists, etc, and I try to learn as much as possible about X. If I am wrong about anything here, please correct me!
[1] http://www.tungstengraphics.com/wiki/index.php/Gallium3D [tungstengraphics.com]
[2] http://akademy.kde.org/conference/presentation/9.php [kde.org]
[3] http://zrusin.blogspot.com/search/label/Gallium3D [blogspot.com]
[4] http://keithp.com/blogs/kernel-mode-drivers/ [keithp.com]
Its good to see Red Hat developers doing this (Score:5, Interesting)
While I'm a firm believer in "If it ain't broke, don't fix it", I think it is good to see Red Hat developers (or any developers) looking to future needs and being allowed to devote development time towards those needs.
Xorg isn't broken for most users right now, but planning and creating alternatives is a good idea.
Re: (Score:3, Insightful)
I'm pretty sure Xorg has (or had) the same goals as this Wayland project. Xorg was meant to add all the modern features not in XFree. In fact, the synopsis of Wayland reads just like the synopsis of Xorg. What the hell are they doing?
The big question is: Will vendors port to it? (nVidia, ATI, Intel, etc)... and by that I mainly mean nVidia.
What's wrong with X... (Score:5, Interesting)
Xorg isn't broken for most users right now, but planning and creating alternatives is a good idea.
In a sense I think it really is... Admittedly, not necessarily in a way that everybody would notice, as you said - but still...
What X is good at, basically, is putting simple UIs over a network. For instance, I can run XEmacs remotely over the internet, and performance is decent.
Presently, this feature of X is being under-utilized. We're using a network-transparent protocol for the display server, but most people aren't running apps from remote hosts, and applications aren't being written with this in mind.
Basically, for all the overhead associated with something like X to be worthwhile then one of a few possible conditions must be satisfied. Either applications must be designed such that they work efficiently over the network with the present limitations in the display protocol, or the display protocol must be enhanced or altered such that today's applications can run reasonably well over a network link.
Running X apps over an internet link versus a LAN is an extreme case, admittedly - but nevertheless, an old Athena app can do it, while the simplest of GTK or QT apps can have a real problem with it...
Re: (Score:3, Interesting)
Hell, I run MythTV over the Internet. By that I mean I run mythfrontend on the server via X11 to my non-Linux work computer.
Works pretty well.
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
Re:Its good to see Red Hat developers doing this (Score:5, Funny)
We're talking about X. You seem to have wandered onto some other topic. ;)
Re:Its good to see Red Hat developers doing this (Score:5, Funny)
Poor analogy, you can still use your buggy whip on your bicycle (especially tandem bicycles).
Re: (Score:3, Funny)
Umm, did someone try to fix the buggy whip? Or did you mean Wayland is a buggy WIP?
The buggy whip example is to illustrate the attempt to mandate halting progress by hindering it with government intervention. It therefore doesn't really apply here.
Re:Its good to see Red Hat developers doing this (Score:4, Insightful)
You'll note that modern wheels do not have stone hubs. The wheel was not simply built on (or around). The person who decided that wood would be better scrapped the whole thing and started again. It's round, just like the stone wheel, but lighter, easier to work with, and apart from the idea, completely new.
The modern wheel, while built on the same principles, is a completely new thing, compared to the stone wheel. Sure, you could build on the stone wheel, but you'd end up with a rubber tyre on 200kg of stone. Not a huge improvement.
There is nothing wrong with reinventing the wheel every so often. It seems like a lot of work at the time, but sometimes the result is worth it.
There is alreeady a brainstorm... (Score:5, Interesting)
For including Wayland in Ubuntu:
http://brainstorm.ubuntu.com/idea/15205/ [ubuntu.com]
Re:There is alreeady a brainstorm... (Score:4, Funny)
Re: (Score:3, Insightful)
HELL yes. (Score:5, Interesting)
eliminate the cruft
ABOUT F'ING TIME.
X has been a case study in How Not to Write Software for twenty years now. Once upon a time, it was a pretty cool experimental software project. But for twenty years now, there have been exactly two kinds of X development:
A) Throw a layer on top of it to make it useable for normal people
B) Throw another driver underneath it to make it just barely work on your particular hardware.
Project A is fine until someone has to get beyond your little layer, in which case it's .xinitrc hell. Project B is just treading water, postponing the day that we all realize this indispensable software tool is a gigantic house of cards headed for collapse.
Probably some XFree86 dudes are reading this. Let me just tell you I appreciate your diligence in the nightmare of a job you've set yourself to, but the time has come. Take off and nuke the site from orbit. It's the only way to be sure.
Re:HELL yes. (Score:5, Insightful)
What in the world does the X11 rendering engine have to do with "useable for normal people" or the "xinitrc"?
X11, and by extension, the X server, is a layer whose job is to put stuff on screen. That means dealing with the wibbly bits (mice, keyboards, displays, video cards, tablets, pedals, etc.) that cause the stuff on screen to be displayed or interact with the stuff on screen.
Furthermore, it's not like people haven't been modifying how the bits in between your "Project A" and "Project B" work, either. See xrandr 1.2 and 1.3, for example, as well as the countless other projects working on this very part of X11.
That's not to say there aren't problems with X11 and the various implementations of the X server, but it'd help to at least have studied what's actually going on before attacking the work of those who are actually doing the work.
Re:HELL yes. (Score:5, Interesting)
Fun fact: Every single bit of development put into X.org since the big fork has been undoing the mistakes committed during the XFree86 years. Making X modular, reworking font handling, introducing EXA, crafting AIGLX, even kernel mode-setting, all of these are undoing bad things from the past.
KRH, who's been writing Wayland, also is responsible for parts of GEM, RGBA OpenGL visuals, and other GLX improvements. Neither he, nor any of us, are planning to just abandon code that's still viable. Tender love and care goes a long way with bit-rotted code.
Re: (Score:3, Informative)
Replyin' to my own comment, since it's drawing some attention...
A little background: I've been only dabbling in the free Unix game since I switched to Mac a few years back -- partly *because* of my frustrations with X11 -- so some of my impressions are out of date, There's no question the UI layers on top of X have improved by leaps and bounds since then. And I'm by no means an X developer.
Yes, I understand that X is intended to be a rendering engine, and that user interaction isn't its main job. Yet some
But does it run... (Score:3, Funny)
xclock? xeyes?
Re:But does it run... (Score:5, Funny)
http://maemo.org/maemo_training_material/maemo4.x/html/maemo_Getting_Started/images/captures/xephyr_empty.png [maemo.org]
Wayland-Yutani (Score:5, Funny)
Y windows; drivers (Score:5, Insightful)
There's another project called Y Windows [y-windows.org], which also aims to replace X with something that has less historical cruft.
The real question in my mind is whether this kind of thing does anything to address the big problems users are really encountering. Of course, not every open source project has to make large numbers of users happier. But the author of Y Windows says, for example, "I've got tired with the state of desktop GNU/Linux. Most of the problems that I see with it can be traced back to the underlying window system, X. So I decided to write its successor... "
For me as an end-user, the big issues are simply hassles with xorg not correctly recognizing LCD screens, so that it sets them to an inappropriate resolution, or the image appears offset. I have close to zero interest in gaming, so personally I just use the onboard video of my mobo, with only 2-d driver features, but the impression I get from people who do care about gaming (or fancy WMs) is that the big issue is drivers, not the internal structure of X.
As far as programming, the structure of X also seems like kind of a non-issue. Sure, X's APIs are heinously ugly, but almost nobody uses them directly.
The advantages listed by the article are things like a more manageable code base, a smaller memory footprint, and elimination of rendering artifacts. To me, none of those seem like major issues that I was all that worried about.
Re:Y windows; drivers (Score:5, Informative)
I remember when Y windows was slashdotted in Feb 2004. It sounded pretty interesting. Unfortunately, it also looks like there hasn't been a single news item on their web site since Feb 2004, and their "community wiki" link points to a domain-squatter-ad-site. Also, the downloads match the version announced in 2004.
It's dead, Jim.
Article misunderstands concept? (Score:5, Interesting)
The article describes this as a "new X server". However it quotes the author of said program pretty much implying this is some kind of a new, non-X video interface. He talks about "porting" GTK+ from X, and about writing native applications for it and a "new, rootless X server" in order to be able to run X apps. All things that would not be necessary if this were an X server.
In other words, this is not an X server.
Canonical (Score:5, Interesting)
Shuttleworth said he is going to pay devs to work on major upstream projects. He should focus on this. For one, it would affect both KDE and Gnome users, and it would solve a major problem with Linux. If he really wants Linux to compete with OS X in terms of interface, he should focus on the X Server first.
That being said, I hope Novell chips in some dev support, and that the KDE, Gnome, QT and GTK+ devs all chime on what they'd like to see changed.
Re: (Score:3, Informative)
If he really wants Linux to compete with OS X in terms of interface, he should focus on the X Server first.
Why? What do you personally dislike about X in general (or X.org in particular)? I installed Ubuntu 8.10 on my work Dell and it correctly autoconfigured everything from my subpixel antialiasing on my LCD to my 7-button Microsoft trackball to my Model M keyboard, using the open source accelerated Radeon drivers for my ATI card. I have a nice, composited desktop with no tweaking necessary. What more should I be expecting from my graphics layer?
Re:Canonical (Score:4, Insightful)
And yet for many users they must manually edit and configure xorg.conf to get anything to work, and sometimes they never get it to work.
There are tons of API calls that haven't been used in years, but no one wants to cut cruft or deprecate.
Xorg is painfully slow, and we're still working around ancient legacy code rather than designing for modern systems.
As for all that auto-configuring, honestly you can credit Ubuntu with plenty of that. Try a major distro like Ubuntu or openSUSE and you'll see the installer configure most of the hardware. Now try Gentoo which doesn't autoconfigure X and see how X performs with your hardware.
X11 - The X Windowing System (Score:5, Insightful)
I hear a lot of (I bet) young people clamoring for X to die, and that would somehow improve Linux or Unix.
X does not need and should not be allowed to die. Sadly X11 is probably one of the coolest pieces of misunderstood software on the planet. It is a bit dated and it does need a code cleanup/refactor, but because of proper design, that can happen without breaking the system.
To those who have *no* understanding of X, they should try this:
ssh -XC some_linux_machine
eyes
What happens is that the "display" is a network device. Windows terminal server and citrix, even today, can't easily separate application from display. X has had it for years. It isn't an afterthought requiring drivers to probe and figure out what got changed on the display surface and send a block over the network (like citrix and VNC), no the display is rendered over the network.
X11, IMHO, is one of those hidden jewels in Unix that don't quite get. They focus on trying to make it like Windows or be a gaming platform, but UNIX is a "productivity" platform.
Like I said, I'm all for refactoring, cleanup, cruft-removal, etc. to the codebase, but keep X11.
Great point! (Score:3, Interesting)
That's actually a great point.
It's particularly annoying if you have some intermittent problems with, say, the mouse disappearing and the only way to recover is to restart X. Being able to restart X without killing all the clients would change such a problem from "completely ruins my entire user experience" to "mildly annoying".
Re:X11 - The X Windowing System (Score:5, Insightful)
Re: (Score:3, Informative)
And why modded _you_ insightful? The X11 protocol most definitely does NOT "blit the entire damn window over the network". That's how things like VNC and MS' Remote Desktop work (although with a lot of compression to make it workable).
But it is true that the protocol was made to work over relatively fast local network connections so not much thought was put into limiting the amount of traffic.
But if you want X over a slow connection you could try NX (http://en.wikipedia.org/wiki/NX_technology).
that's not how X works (Score:3, Informative)
Sorry, you are totally wrong, that's not how X11 works at all.
The client queues up a set of drawing commands (not bitmaps), at some point the queue gets flushed, and for a local display there's a context switch and the server updates the screen. This is exactly how Windows and OS X work as well. The only difference is that the X11 protocol was carefully designed to be asynchronous, so that when you run over a network connection rather than locally, you don't get killed by latency on round trips.
Browser
Re: (Score:3)
Not only are you rude and arrogant, you are almost entirely wrong in every important respect.
Re:X11 - The X Windowing System (Score:4, Insightful)
And X has probably given unix wankers the most wet dreams of any software project on the planet.
Ah, insult the people. A sure sign of a strong technical argument.
Give me a break. Atoms stay around in memory forever, by design.
My god. The horror. My xserver has been running for a few weeks and:
xlsatoms | wc -c
gives 14746. That's a whole 14KILO bytes permenantly taken up by atoms. This includes the lavishly large number of atoms created by GTK and QT based programs. I have not one machine (including my Zaurus) where 14kB is a problem.
There's no audio.
Er, it's a graphics system.
It has the overhead of packing/unpacking data into structs.
Huh? Doesn't any API have this problem?
You can use shared memory, but it's no panacea.
It's also unnecessary and doesn't give much of a speed increase.
Lots of complicated stuff like ICCCM
ICCCM is complex and not that great. On the other hand, with the years of hindsight, large sections (some quite interesting) have dropped completely out of use and are essentially unimplemented. Commonly used sections like copy/paste work very well and are not complex.
and Visuals and xauth. Ad hoc things like cut and paste via shared secrets.
Copy/paste works very well and is elegant. I like the dual clipboard system, and the way that XDnD is/was a very small add on, using the same mechanism.
Can't disconnect/reconnect the same client.
That depends on the client.
Lots of unused (even at the time) primitives like jaggy lines and circles designed for 1-bit displays.
I don't consider myself old, but I've used X11 running on 1 bit displays. They were cheap and so some universities ahd them in significant quantities. I'm pretty sure it's not possible to draw a smooth line or circle on a 1 bit display, but if you know how, feel free to revolutionise display technology.
The list goes on and on. Seriously I could fill pages of just mentions of the problems, assuming you to know the details.
Your list is, so far rather uninformed. Have you ever programmed with XLib or examined the X protocol? Are you just regurgitating one of the more peculiar slashdot memes?
Maybe too late. (Score:3, Informative)
Jon Smirl [googlepages.com] and David Reveman [freedesktop.org] lobbied for a new xorg server built on OpenGL. It got little support from the community especially from Red Hat and Novell. Personally I think this was one of the greatest missed opportunities in the history of OSS. We could have had a modern xorg server replacement which rivaled Apple and Microsoft. Now we have the main xorg branch floundering from lack of interest and developers. Not to say there hasn't been progress made but no one can argue that xorg has the resources available to compete.
Ironically someone who argued against X on OpenGL now is working on his own xorg server replacement. Good luck to him and I hope he has better support.
Syncing to vblank? (Score:5, Insightful)
At the same time, I'm trying to fix some of the problems with composite that we still have in the X server; input redirection, window resizing, syncing to vblank, throttling of animations and atomic, consistent redrawing.
That feature alone would make this rewrite worthwhile. This has been missing from our desktops for far too long.
Catch up to OS X circa 2001. (Score:3, Interesting)
Re:Been done (and failed) like a million times? (Score:4, Informative)
Uh, what else? None of these have replaced the X11 standard.
True, but this isn't aiming to replace the X11 standard for all purposes, at least not for the moment. The article/interview seems to make it clear that the goal is to do lightweight sorts of things - login managers and screen savers first, remote desktop access later - that don't have necessarily complicated needs beyond being able to fire up quickly, not take up that much space, and hopefully look nice in the process.
This isn't the New Linux Desktop. (unless it is.)
Re:Been done (and failed) like a million times? (Score:5, Informative)
If I understand the article correctly, this is a new X server, not a new API or protocol. Programs would still compile against XLib and still access the server through TCP/IP or unix sockets. The only difference is that the rendering engine that interprets those commands has been swapped out.
OS X *is* NeXT. So I'd say that "that stuff" went to good use.
Not sure what you're referring to. But BeOS was awesome. Especially when it came to multimedia.
LFB is a pretty standard module in Linux these days. It's why Linux can boot with fancy graphical screens rather than staring at boring off-white text.
OpenGL is a standard part of modern X servers. Are you perhaps thinking of Project Looking Glass? That was an attempt at creating a new window manager rather than a new API. It's still under development, but it's coming along at Enlightenment speeds. Its development should not be impacted by a new X server.
I don't think that most of them were trying to.
Re:Been done (and failed) like a million times? (Score:5, Insightful)
X11 has replaced the X11 standard... (Score:4, Informative)
None of these have replaced the X11 standard.
X11 in 2008 is a lot different from X11 in 1998. Much of the X11 API is never used, and therefore you can get away with making a much simpler X-server which only supports the new calls. It won't run very old programs without some sort of compatibility box, but those are fairly rare.
Re:Thank you! (Score:5, Insightful)
Thank you sweet Jesus! Finally somebody is doing something that should have been done looooong time ago!
People have been doing bits and pieces of it for a long time. Client-side font handling, client-side rendering in general, kernel mode setting... Without those things, this project would be a lot larger.
This is quite typical of free software by the way: A lot of things are quietly replaced and enhanced without anyone noticing, and suddenly someone uses all the changed bits to create something radically new.
Re:Thank you! (Score:4, Informative)
And client side (font) rendering is good exactly _how_?
It means innovation can happen in the client libraries and not have to wait for all the servers to catch up. It can lead to fewer roundtrips between clients and servers.
You should never enshrine complex things in protocol specifications; protocols change way too slowly. Font rendering used to be a simple thing, but the demands of modern applications force it to be complex, and the X11 protocol simply can't keep up. Nor should it.
I don't have client-side rendering problems with ssh transparency. If anything, it helps that you don't have to install all the fonts an application needs on all the X-servers it might end up running on.
Re:Thank you! (Score:4, Interesting)
It was [y-windows.org] done long ago.
Re:Thank you! (Score:4, Insightful)
What was the adoption rate of Y? Was it really done? Was it little more that a proof of concept?
Well, don't let reason get in the way of a seemingly cool reference, though.
Re:Thank you! (Score:4, Informative)
The demo apps that came with it worked pretty well. It was a lot smoother than X's compositing window managers at the time at any rate, but that's mostly because nvidia can't write a 2D driver worth shit and Y was software-rendered.
But like everyone else has said in these comments how is this attempt going to be any different to Y/DFB/GGI/etc?
Re:Thank you! (Score:4, Interesting)
IIRC, Y was not based on a composited architecture, so by today's standards it sucks. It might have made a nice successor to X back in the BeOS days, though.
Re: (Score:3, Interesting)
No, what should have been done a long time ago is to scrap X and use Sun's NeWS. They demo'd it in the 80s and it fixes a lot of problems in any X(/Y).
Oh well.
NeWS was good and bad (Score:5, Interesting)
When it was good, it was very very good, but when it was bad, well, it was a windowing system written in Postscript that let you pass pieces of Postscript code back and forth between client and server to get things done, which could be appallingly insecure and buggy. (The fix for this was that Gosling later wrote Java with things he'd learned from NeWS.) (Postscript is essentially FORTH souped up with font knowledge, but it's good enough to handle objects in.)
Postscript means that WYSIWYG, really, rendered however you'd like. The terminal emulator, for instance, used Postscript, rendered at screen resolutions, and if you needed to print it, it rendered them at printer resolutions, or if you iconized a terminal window, that just set to font size to 1 point / 1 pixel, and you could still see any interactions happening in the icon. My boss was around 60, and constantly switching pairs of glasses if he needed to talk to somebody and also read his computer screen. We set his psterm default to 24-point font, and everything was Just Bigger, and he could just read it without messing around. Mouse tracking worked well, because you could make the tracking happen down in the server without the extra round-trip to the client, so if you had a slow network connection it was ok - you were passing data across the link, not pictures of the mouse, etc.
Re:Thank you! (Score:5, Insightful)
Re:Thank you! (Score:5, Insightful)
X is an application. *And* a server. On OS X as well. And under *nix, and even under Windows (when you add an X server to it.)
X's architecture works pretty well for what it was written to do. It was written in a time when lots of people used wimpy X terminals and did their work on a shared beefy central server.
VNC might be more of the architecture you're referring to?
Re:Thank you! (Score:5, Informative)
Re:Thank you! (Score:5, Insightful)
Re:Thank you! (Score:5, Informative)
X does not *have* to run the graphics ... just because Xorg/Xfree86 and just X before that (usually?) worked that way, that doesn't mean it's the only way it can be done. Counter-examples include X on OS X (yes, I know, it was mentioned), X on Windows, and even things like Xvnc, Xvfb and Xnest.
Just because YOUR X server also manages the graphics hardware, that doesn't mean that's an X thing -- it just means it's something else that YOUR X server does. Others may not.
FishWithAHammer was just not very clear.
Re:Thank you! (Score:4, Insightful)
"just means it's something else that YOUR X server does. Others may not"
And you took it the other way...
Yes X doesn't have to use a hardware framebuffer, yes you can have X on various other virtual framebuffers, but that's going a step in the oposite direction of what people are talking about here. That would be keeping the X server/protocol and throwing out its ability to write to and manage the hardware. What people are talking about is throwing out the X serrver/protocol, and allowing stuff to write more directly to the screen, have more stuff in the kernel, and reduce the number of abstractions and context switches required between the app and the pixels landing on the screen.
Re:Thank you! (Score:5, Insightful)
I use X on 32 and 64 bit versions of both OpenBSD and Ubuntu Linux and can't recall it crashing on my anytime in the recent past. Certainly not "all the time" in my experience.
Re: (Score:3, Informative)
Re:Thank you! (Score:4, Informative)
I have to say, running on 512K ram and it seems to be fine. The only time I've had a real problem with X is when I start fiddling with Nvidia drivers and 3D acceleration. I've always put that down to the drivers not playing nicely though.
Re:Thank you! (Score:4, Insightful)
Window management is largely pushed to the clients, they draw their own decorations and move and resize themselves, typically implemented in a toolkit library. More of the core desktop could be pushed into wayland, for example, stock desktop components such as the panel or the desktop background.
Wonderful. Microsoft Windows works that way, and it sucks - whenever an application locks up, it becomes impossible to move or resize its window (and in older versions of Windows without the appropriate hacks, impossible to minimise it either).
Re:Notes for the Uninformed (Score:5, Insightful)
It's rarely discussed because it's extremely slow. Even on low resolutions it takes an absurd amount of CPU power and latency. On high resolutions it's like a slide show with an awkward guest speaker. There's a reason we have hardware acceleration even for 2D.
Re:Two decades is more like it (Score:4, Funny)
Yes, network transparency (Score:3, Insightful)
The project implements a new X server. Clients (i.e. your applications) link against the gnome library which links against ... which links against the X library, which talks to the X server via tcp.
The X forwarding in ssh works like any other port forwarding: listen on the port, grab the data, send it through the ssh tunnel, dump it at the target port on the other side.
That's the simple version. Add to ssh some special-casing for X, and add to xorg and xlib a speed hack that lets it use unix sockets or sh
Re:Network Transparency? (Score:5, Informative)
1) NO ONE programs with xlib.
2) X doesn't "suffer" from being network transparent from the point of view of the user.
I don't even want to think about setting up some kludge like VNC to deal with a future Unix GUI subsystem that isn't network aware.
With X, I can just treat a network of machines like one big hive mind. Just make sure to set $DISPLAY.
Let's face it (Score:3, Insightful)
Networks really aren't fundamental to windowing environments. X was designed around the limitations of most Unix configurations of the time (a single server with clients running on fairly dumb terminals). When real workstations became available, network transparency became a nice feature that wasn't really needed in most cases. The question is whether the added complexity is justified by the importance of the feature.
Re: (Score:3, Interesting)
Boy are you wrong, NoMachine _is_ X! They just use very clever compression schemes to make it usable over slow connections. http://en.wikipedia.org/wiki/NX_technology [wikipedia.org]
VNC, Remote Desktop, Citrix etc are just kludgey ways to get X-like remoteness for systems that were never meant for it and it's noticeable because they come with severe limitations.
And for Gnome and KDE being "monstrosities" I don't know where you got that idea from, their respective developers seem to be pretty pleased with them. And Qt, whic
Re:Network Transparency? (Score:4, Insightful)
NX does two things that really should be added in to the server. First, it caches pixmaps. X11 was designed for cheap servers which might be memory constrained. These days, you are likely to have a huge amount of RAM close to the display. Being able to store a pixmap on the server would eliminate a lot of round trips. You can actually do this with the XRender extension, but it needs better toolkit support.
The second is that it is stateless. This is the biggest thing limiting the usefulness of network-transparent X. There is no way of disconnecting a X window hierarchy from one server and reconnecting it to another (or the same one, at a different time).
Re:Finally? (Score:5, Informative)
You don't know what you're talking about. When not using network transparency, X.org uses unix domain sockets which are very fast. Given that you've got to do IPC somehow, and a well designed protocol will work just as well over TCP sockets as unix sockets, you basically get network transparency for free.
Re:Finally? (Score:5, Informative)
All folks who claim that X's problems lay in it's *ability* to use clients over a network are 17 years late. I.e., they have no clue at all. There are problems with X, but they are elsewhere.
Re:Finally? (Score:4, Informative)