FOSDEM 2013: The future of X.org on non-Linux systems

[jrm@]

The future of X.org on non-Linux systems

I hope there will be videos.

 

[jrm@]

Slides are up.

 

[YZMSQ]

Are we lagging behind the Linux guys so much when it comes to X?

 

[Crivens]

Are we lagging behind the Linux guys so much when it comes to X?

That depends on the one doing the viewing.

"You are lagging behind!" shouts the guy running into the mine field/off the cliff.

And yes, I consider pushing code which is perfectly at home in user space into the kernel doing the first, and binding the GFX stack to one kernel on purpose to be the second.

 

[wblock@]

Are we lagging behind the Linux guys so much when it comes to X?

Whether intentional or not, the KMS stuff is written for the Linux kernel. FreeBSD is emphatically not a Linux kernel, and so it must all be ported. There are not a lot of people capable of doing that. We've been fortunate that the Foundation funded porting of the Intel KMS drivers by kib@.

 

[Crivens]

Whether intentional or not, the KMS stuff is written for the Linux kernel. FreeBSD is emphatically not a Linux kernel, and so it must all be ported. There are not a lot of people capable of doing that. We've been fortunate that the Foundation funded porting of the Intel KMS drivers by kib@.

Is the KMS code really portable at all? Apart from the differences in the kernel architecture/implementation, there is the licence issue which would make reusing even some header files a problem, right?

 

[wblock@]

Sorry, I have not heard about license issues. As far as portable... well, no, it's kind of written for Linux.

 

[Crivens]

What I meant is, the implementation inside the Linux kernel will be GPL2. Trying to put code that is derived from that into the FreeBSD kernel source tree would, I suppose and hope, draw some attention. Or am I completely not getting something here?

 

[kpa]

You're missing the simple fact that the internals of Linux kernel and FreeBSD kernel have almost nothing in common. The code that implements the KMS system in Linux is 100% Linux specific because it does not have to be portable to other systems. It only needs to implement an agreed API for the X windowing system. Therefor it would be useless as it is for the FreeBSD implementation of KMS.

 

[Crivens]

I don't miss these simple facts, I think.
The code is unportable, but what I was aiming at is that even interface header files are a no-no to base your work on. That's what happens when I try to shorten messages before posting :stud

Clean room implementation, for all and everything. And BTW, what will happen to those who do not use intel based GFX hardware once mode setting is dropped from XOrg?

 

[Anonymous]

Obviously nothing changed since 1997. Here comes a quote of a post on comp.sys.next.advocacy from Mike Paquette.

From: mpa...@wco.com (Mike Paquette)
Subject: Re: X11 Support in Rhapsody (X. No hardware is safe.)
Date: 1997/04/02
Message-ID: <5hua4p$20e@mpaque.mpaque>#1/1
X-Deja-AN: 230188378
Distribution: world
Sender: mpaque@mpaque
References: <YnELm6u00iWQABK1k=@andrew.cmu.edu>
Organization: Electronics Service Unit No. 16
Keywords: humor
Reply-To: mpa...@wco.com
Newsgroups: comp.sys.next.advocacy


For your amusement...

X. The defacto substandard.
X. Flawed beyond belief.
X. Accept any substitute.
X. The Cutting Edge of Obsolescence.
X. The trailing edge of software technology.
One thousand monkeys. One thousand MicroVAXes. One thousand years. X.
X. Japan's secret weapon.
If it works, it isn't X.
X. You'll envy the dead.
Incompatibility. Shoddiness. Uselessness. X.
X. Let it get in YOUR way.
X. The problem for your problem.
X. If it starts working, we'll fix it. Pronto.
X. It could be worse, but it'll take time.
X. Simplicity made complex.
X. Flakey and built to stay that way.
X. Complex nonsolutions to simple nonproblems.
The environment of today... tomorrow! X.
X. A bad idea whose time has come. And gone.
X. It didn't even look good on paper.
X. You laugh now, but you'll be laughing harder later!
X. A new concept in abuser interfaces.
X. How can something get so bad, so quickly?
X. It could happen to you.
X. The art of incompetence.
X. You have nothing to lose but your lunch.
X. When uselessness just isn't enough.
X. More than a mere hindrance. It's a whole new barrier!
X. Built to fall apart.
X. Nullifying centuries of progress.
X. Don't laugh. It could be YOUR thesis project.
X. Why do it right when you can do it wrong?
X. Live the nightmare.
X. You'll wish we were kidding.
X. Everything you never wanted in a window system. And more.
X. Dissatisfaction guaranteed.
X. There's got to be a better way.
X. Even your dog won't like it.
X. More than enough rope.
X. Garbage at your fingertips.
X. The last thing you need.
X. Something you can be ashamed of.
X. Warn your friends about it.
Hindenburg. Titanic. Edsel. X.
X. An accident that couldn't wait to happen.
X. Don't wait for the movie.
X. Never use it after a big meal.
X. Need we say less?
X. Power tools for power losers.
X. A software disaster of Biblical proportions.
X. Never had it. Never will.
X. More than just a generation behind.
X. The ultimate bottleneck.
X. It's not how slow you make it. It's how you make it slow.
X. The windowing system preferred by masochists 3 to 1.
X. Built to take on the world... and lose!
X. Don't try it 'til you've knocked it.
X. Power tools for Power Fools.
X. Putting new limits on productivity.
X. The closer you look, the cruftier we look.
X. Design by counterexample.
X. No hardware is safe.
X. Old-world software cruftsmanship at its finest.
X. Gratuitous incompatibility.
X. THE user interference management system.
X. You can't argue with failure.
X. You haven't died 'til you've used it.
X. The only thing you have to fear.
X. Somewhere between chaos and insanity.
X. The joke that kills.

--
I don't speak for my employer, whoever it is, and they don't speak for me.
mpa...@next.com Official business only NeXT Mail OK
mpa...@wco.com Non-business or personal mail NeXT mail OK

There is another post on Slashdot in 2003, that seems to come from him, explaining "Why Apple didn't use X for the window system", and it seems that Mike Paquette designed/wrote a good part of Quartz, i.e. the X replacement on Mac OS X.

And another 10 years later, "The future of X ...". This is a joke, isn't it? Let's add it to Mike's list. Wait, I have another one to add, "X. Back to the past".

Seriously, are there any good reasons, why the *BSD should spend more money on keeping on track with this brain dead technology? Freeze it at a usable stage. Start fund raising and allocate resources on development of a replacement - perhaps along a somewhat modernized path of Quartz - Z Project?

A rhyme in German (from Erich Kästner): "Es gibt nichts Gutes, außer man tut es." in english more or less: "There is no good, unless you do it."

 

[YZMSQ]

Obviously nothing changed since 1997. Here come a quote of a post on comp.sys.next.advocacy from Mike Paquette.




There is another post on Slashdot in 2003, that seems to come from him, explaining "Why Apple didn't use X for the window system", and it seems that Mike Paquette designed/wrote a good part of Quartz, i.e. the X replacement on Mac OS X.

And another 10 years later, "The future of X ...". This is a joke, isn't it? Let's add it to Mike's list. Wait, I have another one to add, "X. Back to the past".

Seriously, are there any good reasons, why the *BSD should spend more money on keeping on track with this brain dead technology? Freeze it at a usable stage. Start fund raising and allocate resources on development of a replacement - perhaps along a somewhat modernized path of Quartz - Z Project?

A rhyme in German (from Erich Kästner): "Es gibt nichts Gutes, außer man tut es." in english more or less: "There is no good, unless you do it."

Well, I think you're almost right. However, as wblock@ figured out, "There are not a lot of people capable of doing that", when compared with Linux, our community is rather smaller. Second, if we really implement a very-perfect alternative to your called "brain dead technology", then afterwards we should port all the applications around the world which are only designed for X to our "replacement", that's, I've got to admit, a task requires much time and effort.

 

[j_m]

I think using X is not bad.

 

[throAU]

Now I am not a graphics developer, but surely the way X "works" is just wrong?

Surely the "proper" way to do this would be to pull GPU drivers into the kernel proper (like every other driver on the system - be it a module or whatever) and provide a standard API (like OpenGL) for whatever Windowing system (or app) to use? Ditto for found, input devices, etc. Sort of like (shudder) DirectX? Or Quartz.

Provide an X compatibility layer, sure (like any of the myriad of X11 servers for Windows or OS X) - but installing a full windowing system to get a GPU driver just seems broken to me. All the low level driver skullduggery should not be done by an application.

Yes, I'm aware this would require wholesale changes to the way free desktops and the OS work.... and require a committment by kernel people to provide a well defined, stable API. This is a utopia type thing



The longer we persist with X, IMHO, the further behind the free operating systems will lag.


Sure X11 can be hacked to do what most people want. But fixing X without providing some sort of stable foundation underneath it, where much of it's functionality should actually be is IMHO traveling further down the wrong path.

then afterwards we should port all the applications around the world which are only designed for X to our "replacement", that's, I've got to admit, a task requires much time and effort.

No, you simply write an X11 compatibility shim (or hell, even port one of the many free X11 servers for Windows or OS X) to run X11 apps on top of the replacement platform.


I'm sure the core devs will shudder at the thought of pulling OpenGL into the base system (should bring in OpenCL and OpenAL too for that matter if possible), and having GPU drivers in the kernel either directly or via a stable ABI.

But, this is 2013, not 1993. Graphics support is kind of a big thing these days.

 

[Crivens]

Uh oh. You are wearing asbestos underwear, right? Because some kernel devs will likely want to toast some part of your anatomy.

Surely the "proper" way to do this would be to pull GPU drivers into the kernel proper (like every oher driver on the system - be it a module or whatever) and provide a standard API (like OpenGL) for whatever Windowing system (or app) to use? Ditto for found, input devices, etc. Sort of like (shudder) DirectX? Or Quartz.

The proper way would be to add these drivers to the kernel/system source tree but keep them out of kernel address space at runtime at any cost.
Check out Minix3 for examples of that, really awesome what can be done these days. Crash your ethernet driver ten times a second? No problem, the downloads get a bit slower, but you would not notice it. Tanenbaum stated that he would gladly sacrifice half the performance of modern hardware only to be sure the thing cannot curl up and core dump on him.

Provide an X compatibility layer, sure (like any of the myriad of X11 servers for Windows or OS X) - but installing a full windowing system to get a GPU driver just seems broken to me. All the low level driver skullduggery should not be done by an application.

This is right, X11 should not bother with it. That should be part of other parts, link libs or shared libs, device drivers, whatever. But keep it out of the kernel space, please.
And no, performance does not provide the silver bullet argument.

Yes, I'm aware this would require wholesale changes to the way free desktops and the OS work.... and require a committment by kernel people to provide a well defined, stable API. This is a utopia type thing

The kernel provides mmap of the system address space, any user mode driver may (sufficient credentials provided) map the hardware into his space and do what it wants.

No, you simply write an X11 compatibility shim (or hell, even port one of the many free X11 servers for Windows or OS X) to run X11 apps on top of the replacement platform.

Now we only need to specify that platform, some layer between kernel and X.
I once thought about porting f.e. the Haiku desktop to *BSD, maybe that would work out as expected?

I'm sure the core devs will shudder at the thought of pulling OpenGL into the base system (should bring in OpenCL and OpenAL too for that matter if possible), and having GPU drivers in the kernel either directly or via a stable ABI.

Do not bring things into the kernel which do not belong there. IMHO file systems also do not really belong there.

But, this is 2013, not 1993. Graphics support is kind of a big thing these days.

Stable systems are also a big thing, yes? The more stuff you push into the kernel the more bugs will end up where they surely do not belong.

I'm all in for a replacement of X11, or better to cut it into layers and keep the "old" X11 as the topmost but optional layer. Pushing mode setting and whatnot into kernel space makes my toenails curl up, but X11 is getting a bit bloated for sure. Pushing that bloat into kernel space is not going to solve it. There need to be other ways.

 

[Anonymous]

...
Now we only need to specify that platform, some layer between kernel and X. I once thought about porting f.e. the Haiku desktop to *BSD, maybe that would work out as expected?

IMHO, the Simple DirectMedia Layer - SDL, got 90% of what is needed. People are discarding this option only because it does not support multi-windows. IMHO, at this level (equivalent of Apple's CoreGraphics/Quartz) this is not needed. Windows come at the layer above, and in order to have a decent one, it is anyway best to newly implement the Window Manager

FYI, there was a Y project using SDL at the graphics and user-IO layer. This must not be confused with "an April Fools' Day spoof submitted to the LaTeX-L mailing list on April 1, 1992; a copy of the article appears as the fourth message in an archive".

 

[Crivens]

Ok, here some sublimal part of me did some typing, it needs to be translated as well.

"Now we only need to specify that platform, some layer between kernel and X."

Since I am not a native speaker, you need to be familiar with "einfach mal eben schnell" in german.
This would mean that "you simply, with a flick of your hand, do this" (closest translation coming to mind) do something that seems so easy but where not only the devil is in the details but he brought all kinds of friends to that party.

SDL seems to be a good start for a layering, indeed. It makes much more sense to me, compared to push it all into kernel space. But time will tell...

 

[Uniballer]

"einfach mal eben schnell"

In this context I would translate it as SMOP (Simple matter of Programming).

Believe me, your English is way better than my German.

 

[throAU]

Uh oh. You are wearing asbestos underwear, right? Because some kernel devs will likely want to toast some part of your anatomy.

As I said, I'm not a developer - so if I'm wrong, I'm not going to take it personally. I am an end user.

The proper way would be to add these drivers to the kernel/system source tree but keep them out of kernel address space at runtime at any cost.

Sure. I agree. but currently, we have drivers for NICs, USB, sound, etc, etc all in the kernel. What makes GPUs so different? If we're doing user space drivers, surely they should be done for pretty much nearly everything?

I agree if you can do it in userspace, do it in userspace. Windows vista onwards does this, and yes a crashed GPU does not crash the box. Perhaps I mis-spoke with my comments to put it in the kernel - but if it's going to be in userspace it would certainly need some stable driver ABI?

Perhaps what I MEAN is more tightly integrated into the base system and treated as a first class citizen. Not some non-standard afterthought that is reimplemented in different ways for everyone who decides to do anything graphics related.

At the moment the practice seems to be to dump every other driver into the kernel, but GPUs - well they're left to their own devices.

This is right, X11 should not bother with it. That should be part of other parts, link libs or shared libs, device drivers, whatever. But keep it out of the kernel space, please.
And no, performance does not provide the silver bullet argument.

Yeah, my point was not to do with performance so again perhaps I mis-spoke. My concern is more to do with having first-class OS support for GPU hardware and drawing operations, like we do with network adapters and their use of IP, etc. X is a bit of a hack and doesn't really do what anyone wants it to do these days. IMHO, in 2013, support for drawing operations of some kind really should be an operating system level feature.

I'm all in for a replacement of X11, or better to cut it into layers and keep the "old" X11 as the topmost but optional layer.

Yeah this is what I mean. X11 should live on top of some standard library which handles the GPU at the OS level.

IMHO, the Simple DirectMedia Layer - SDL, got 90% of what is needed. People are discarding this option only because it does not support multi-windows. IMHO, at this level (equivalent of Apple's CoreGraphics/Quartz) this is not needed. Windows come at the layer above, and in order to have a decent one, it is anyway best to newly implement the Window Manager

Makes sense to me. Also, there's heap of stuff already written for SDL, which would continue to work if it was installed as a lower level component below X11 or whatever other windowing system succeeds it.


Anwyay, this is all pie on the sky stuff. It's how I wish things were. No system I've ever used prior to Unix had such a mess for a graphics subsystem.

Every X11 window (hell, even the desktop itself) should just be an (accelerated, if appropriate driver is present) OpenGL surface that can be scaled, rendered transparent, rotated off screen, etc. by the OS as required. How do we get there?

 

[Crivens]

Sure. I agree. but currently, we have drivers for NICs, USB, sound, etc, etc all in the kernel. What makes GPUs so different? If we're doing user space drivers, surely they should be done for pretty much nearly everything?

They should. Drivers in user space may produce a speed penalty, but the increase in stability is IMHO worth the cost. Each system is slowest when it has crashed.

GPUs can do some DMA on their own, texture buffers and such. These can be programmed from the user space by GL commands, OpenCL and what not. Other devices can do DMA as well, but they are programmed from kernel space only, it is not so easy to redirect the DMA from the SCSI subsystem, f.e., to overwrite the kernel memory. By accident or by intent, this is not to be allowed. That is why there are dedicated MMUs for these kind of hardware, which needs also to be handled by OS. That, and the update frequency of graphics drivers (a new chip each week, or what is it?) would flood kernel space with hastly hacked drivers.

I agree if you can do it in userspace, do it in userspace. Windows vista onwards does this, and yes a crashed GPU does not crash the box. Perhaps I mis-spoke with my comments to put it in the kernel - but if it's going to be in userspace it would certainly need some stable driver ABI?

Microsoft started the NT line with graphics drivers in user space and moved them into kernel space to enhance the user experience. That they moved it back should speak volumes.

What I had in mind with the drivers being in user space is this - you need to have the source in the same place. The ABI between kernel and drivers can change at any time, but the interface from the driver to app needs to be stable. On that level you need no stable ABI, but the driver code should not run in kernel context. But with KMS et al, the amount of code running in kernel space, and thus code which needs to be trustworthy is growing.

Perhaps what I MEAN is more tightly integrated into the base system and treated as a first class citizen. Not some non-standard afterthought that is reimplemented in different ways for everyone who decides to do anything graphics related.

Full Ack.

Yeah, my point was not to do with performance so again perhaps I mis-spoke. My concern is more to do with having first-class OS support for GPU hardware and drawing operations, like we do with network adapters and their use of IP, etc. X is a bit of a hack and doesn't really do what anyone wants it to do these days. IMHO, in 2013, support for drawing operations of some kind really should be an operating system level feature.

The problem is, there are new chips each monday (so to speak). You do not have the manpower to cover it all, and thus you need some kind of graphics driver framework which is not chained into one kind of kernel. And once some part of that kernel changes where the driver is interfacing directly for some reason, you need to adapt the drivers. Early versions of X had one server for each hardware and gained access to that hardware by mmap()ing the system address space. Clean interface, worked on *BSD, Solaris, Linux, ...
Now with KMS you have to cater for different manufacturers and each new chip generation which behaves differently, this is going to absorb tons of manpower, but what is gained by this? We now have the state that you can not change resolution when running AMD/ATI hardware because KMS in FreeBSD is Intel-only.

Anwyay, this is all pie on the sky stuff. It's how I wish things were. No system I've ever used prior to Unix had such a mess for a graphics subsystem.

Like DOS?
But I have to agree, X11 is kind of the saber-tooth rabbit here.

Every X11 window (hell, even the desktop itself) should just be an (accelerated, if appropriate driver is present) OpenGL surface that can be scaled, rendered transparent, rotated off screen, etc. by the OS as required. How do we get there?

IMHO not by requiring the system to support each kind of possible hardware on it's own, that's what got us where we are. Using SDL is a good idea, I think. Enlightment may be a good start for what we want. But in the end, it comes down to Applications Applications Applications (ducks head due to thrown bikeshed).

 

[adamk]

Every X11 window (hell, even the desktop itself) should just be an (accelerated, if appropriate driver is present) OpenGL surface that can be scaled, rendered transparent, rotated off screen, etc. by the OS as required. How do we get there?

This is where the developers are heading with Wayland.

Unfortunately, this switch doesn't improve things for non-Linux systems as the driver requirements are only available on Linux (well, perhaps, the KMS-enabled intel drivers on FreeBSD could support Wayland... Not really sure about that).

ADam

 

[throAU]

Like DOS?
But I have to agree, X11 is kind of the saber-tooth rabbit here.

Having written my own graphics library for DOS back in the day (inline ASM in Pascal ), at least DOS wasn't a mess because you were on your own.

Any mess was your own making

This is where the developers are heading with Wayland.

Unfortunately, this switch doesn't improve things for non-Linux systems as the driver requirements are only available on Linux (well, perhaps, the KMS-enabled intel drivers on FreeBSD could support Wayland... Not really sure about that).

ADam

Yup.

I've been semi-following wayland and believe it is the way forward.

Whether FreeBSD supports it or not will determine if it gets left behind on the desktop, IMHO.

If it does - so be it. Every OS doesn't have to be all things to all people. But I hope it isn't.


However, Wayland looks like it is MIT license, so it's just a matter of implementing the driver support or porting it? (i.e., it's a technical/resource problem rather than a legal problem?).

In any case, I suspect GPU and GP-GPU support is going to be a "requirement" at some point in the near future for any proper server OS anyway. Both to do stuff like provide an accelerated VDI platform, and use the GPU for number crunching for other workloads.

 

[taz]

It would seem something is starting to happen regarding FreeBSD and Wayland.

http://www.phoronix.com/scan.php?page=news_item&px=MTMwMzE

 

[throAU]

Good to hear. Article is biased as hell though - typical moronix...

 

[taz]

Yeah it's good news but I have been wondering something. It's obvious that Xorg is a mess and needs replacement: Windows, Apple (Quartz) and now Linux (with Wayland) are all implementing their own display servers. Why wouldn't FreeBSD do the same and instead of porting Wayland use it as a reference. Hypothetically, what would be necessary to get such a project started.