How Important Is The Wayland Display Server?

[lee_b]

Let's clear this up

Guys.. forget wayland. The thing you're all looking for, which has been mentioned a few times, but mostly missed, is this:

Xorg State Tracker: The Last Xorg Driver (previously known as xorg-video-modesetting)

With it, Xorg is just a library of things like low-level window management and input device management. Even the input management is being simplified, with Linux's recent generic event-driven input device support.

The Xorg State Tracker will swap video modes using kernel calls to GEM, so it doesn't know about your graphics card, and will work very smoothly, without crashing.

OpenGL, Xv, VDPAU, and all other rendering will/can be accelerated using Gallium3D, for optimal performance.

The Gallium3D drivers for your card will be much smaller and simpler than the old xorg-video drivers, and the OpenGL drivers, so graphics card vendors or Open Source developers will be able to support Linux much more easily. Moreover, a Gallium3D driver will be very portable to FreeBSD and Haiku and other Operating Systems (if not directly compatible), so there's a bigger market to encourage them to write those drivers, and a bigger pool of open source developers to work on free versions.

For those of you who want a simpler, cleaner X, this Xorg State Tracker is it. And it's coming.

[MostAwesomeDude]

for X.Org. It will die. The sad state today is just that X is the default in nearly every linux distribution and has the graphics drives. Those 2 facts will give X a long time before people finally realize that X isn't the best way to go. Wayland might be better but don't count DirectFB out yet! They are under development and releasing new versions from time to time.

I see only one future fox X other then dying and that is a (near) total rewrite of it. anything else is probably just not going to save it.

O and the massive delays in X releases the last few years is (to me) a clear sign of a dying project. however currently it's to important to die so company's will probably keep it developed till there is a better alternative.

Mark my words. IF there is a X alternative that can either use the X drivers or just has good video drivers equal to X then X is dead.

I'm gonna mark your words. Or mark them up, at least. Maybe practice my marksmanship on them.

I'm gonna count DirectFB out right here and now, unless you guys have decided to give it the ability to sit on top of KMS/GEM drivers and let the kernel drivers manage VRAM.

If you re-wrote the Xorg servers right now, what would you change? Keep in mind that you have to keep the X11 protocol.

Xorg's release schedules keep slipping because of a lack of manpower. You're more than welcome to sit down and help write code, but I feel that you're more likely to keep griping about how much we suck.

Have you considered that the only alternatives to X that have actually gained ground and held it are the ones backed by Microsoft and Apple? And we have X running on their systems, too!

[val-gaav]

I've never, ever seen anyone use Windows remote desktop; it's only available in server versions, isn't it?

Nope It's also included in normal versions fe. Windows XP Professional has it.

Anyway if you have not seen anyone use it then you must have almost no contact with Windows (which makes me kind of envious )

[combuster]

@mostawesomedude

I've just pulled xorg from git and compiled it and it runs great...

[combuster@vostro bin]$ ./Xorg -version

This is a pre-release version of the X server from The X.Org Foundation.
It is not supported in any way.
Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/.
Select the "xorg" product for bugs you find in this release.
Before reporting bugs in pre-release versions please check the
latest version in the X.Org Foundation git repository.
See http://wiki.x.org/wiki/GitPage for git access instructions.

X.Org X Server 1.6.99.901 (1.7.0 RC 1)
Release Date: (unreleased)
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.31-DELL x86_64 
Current Operating System: Linux vostro 2.6.31-DELL #1 SMP PREEMPT Thu Sep 10 09:39:12 CEST 2009 x86_64
Kernel command line: root=/dev/disk/by-uuid/3e92ef55-6568-4851-abd7-449728a2a878 ro
Build Date: 16 September 2009  09:50:10AM
 
Current version of pixman: 0.17.1
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.

So imho Desperate Dodo is not so desperate Only thing is, during compile you have more lines with warnings than lines in your docs but compiling went without any errors... Just keep it up...

[Xheyther]

Xorg's release schedules keep slipping because of a lack of manpower. You're more than welcome to sit down and help write code, but I feel that you're more likely to keep griping about how much we suck.

Have you considered that the only alternatives to X that have actually gained ground and held it are the ones backed by Microsoft and Apple? And we have X running on their systems, too!

Speaking of being involved into the X.org project, can you give some directions for useful resources for understanding the X nebula ? I tried a lot of times to understand how things work, but I can't find a "central" documentation repository.

For me, you actually have to deserve the X.org's documentation.

(And I think that the X.org foundation website is truly awful.)

(yes my english is poor.)

[bridgman]

Again, one of the big challenges here is that a lot of the current "X development work" (kernel modesetting, GEM/TTM, Gallium3D etc..) is not actually part of X and so is not formally documented as part of X. The work is being done by Xorg developers, however, and the X drivers need to change to take advantage of this work, so I can see how that could be confusing. There has been some attempt to document "the entire stack" as opposed to just X, but there has not been a lot of effort to distinguish between the two.

X itself is pretty mature; new features are still being added, of course, but anyone who thinks that delays in X releases are "holding up the industry" may be missing the point.

I'm not sure what will happen first - whether users will realize that most of the "graphics problems" are outside X, or the definition of X will expand to include the rest of the graphics stack, or once the core graphics problems are fixed everyone will decide that X wasn't the problem after all and go find something else to beat on.

One thing that would probably help to minimize X-bashing is getting people used to talking about the Linux/Unix graphics stack as a separate entity which includes X, but the same people ("Xorg developers") are are doing all the work on both parts there's not a lot of motivation to change anything.

The big picture here is that the Xorg developers have been working for a couple of years to move the driver stack out of X and allow the same driver stack to be shared between multiple APIs, including consoles, boot managers, X, Wayland, DirectFB, EGL, OpenVG, OpenCL, Windows on a VM, and anything else I might missed. Once that work is done then a lot of code can be removed from the upper level APIs (including X) but until then it's going to look like everything is just getting more complex with no end in sight.

[markg85]

And those toolkits render to X; yes, every single toolkit can be rewritten to write to some new 'X alternative', but that's not going to happen any time soon, particularly as most of the people maintaining and developing those toolkits probably have better things to do with adding high-level functionality than add yet another low-level interface.
...

You obviously don't know what you're talking about here.
Do you know that both GTK and QT have bindings to DirectFB! So, simply speaking, any GTK and QT app can in theory be used in DirectFB.

And Galium (or was it mesa?) has a directfb compiling option as well. So the time to switch to a real alternative (again DirectFB) is really close! the only thing we need more now is more galium support (if it was galium that had directfb support) or better vga drivers in the kernel with hardware acceleration.

[energyman]

in theory. That is a big point. Also - do you really want to use completly unaccelerated framebuffer? Backt o 1985?

[markg85]

I'm gonna mark your words. Or mark them up, at least. Maybe practice my marksmanship on them.

I'm gonna count DirectFB out right here and now, unless you guys have decided to give it the ability to sit on top of KMS/GEM drivers and let the kernel drivers manage VRAM.

If you re-wrote the Xorg servers right now, what would you change? Keep in mind that you have to keep the X11 protocol.

Xorg's release schedules keep slipping because of a lack of manpower. You're more than welcome to sit down and help write code, but I feel that you're more likely to keep griping about how much we suck.

Have you considered that the only alternatives to X that have actually gained ground and held it are the ones backed by Microsoft and Apple? And we have X running on their systems, too!

You seem to think i'm a DirectFB dev. not true. i just like the project and tried a few things with it.

as for rewriting X. then perhaps the X11 protocol is to bloated? i don't know, i didn't read it. What i do know is that X is heavy as hell and a less heavy version should be made or a alternative should be made/used. Like for example remove out the things that are nice for servers but not used much on desktops like remote x stuff. It's nice that it's possible but if you only remove that single part you will:
- get a much faster X
- way more memory friendly X
and perhaps more devs that are willing to maintain it.

O and removing out the default CTRL + ALT + BCKSP is really something to scare of new devs to help.

I'm not going to help X simply because i don't have that much c knowledge to be able to help.

in theory. That is a big point. Also - do you really want to use completly unaccelerated framebuffer? Backt o 1985?

It's not obvious if you quote me or someone else but if you mean me with DirectFB then no. DirectFB is still a layer between the application and the kernel framebuffer device. A normal user should not even use directfb to develop on. they should use a toolkit that works on top of it (GTK and QT do.)

And for the drivers. If galium gets accepted by all card manufacturers then you don't need to go back to "1985".. (2000 would be a better year)

[marek]

Rewriting X is bad and very costly. Refactoring is the way to go, which is happening right now.