Will Wayland Become A New Desktop Standard?

[deanjo]

-Made it practically imune to rootkits.

Wut? lol, sorry but linux is far from immune to rootkits.

[V!NCENT]

You have raised a lot of points that lead me to one conclusion: you want Windows NT/ReactOS.

Yes Linux has several shortcommings, but you want to create something now and want it to keep working? Bad luck. What is not maintained for Linux gets scrapped. That is how Linux works and allowed it to:
-Run on any kind of device, from a smartphone to a cluster server.
-Make it extremely flexible.
-Made it practically imune to rootkits.

Also you want modularity? Yet no micro-kernel?

[plonoma]

Linux kernel driver module compatibility you mean? Already present and working with HURD. KMS being worked on.

That's nice but there should be a general system for all kinds of hardware physically possible.
I doubt that that is the case today.

A good kernel design and api that allows modularity and all kinds of stuff is key to a good operating system.

Only aplies to proprietary stuff. Linux doesn't work that way. Appearantly it works, so why change it? Also: Linux has kernel modules.

So if I design a small piece of custom hardware and try to make a small driver I have to change all sorts of things in the kernel itself? This is the result of that kind of thinking.

The goal of modularity is to be able to exchange isolated pieces without breaking the whole system. This allows to make a piece of hardware and let it take over certain tasks without adapting=disrupting the whole software stack.

There is a reason why AMD and Nvidia put an own stack in their drivers.
And I explicitly mean display servers such as xserver and wayland. This is resource management done by userspace sort of! It causes a lot of trouble. And the projects provide all sorts of stuff e.g. mpx and XKB that should have been a kernel project itself. Khronos is making a new input interface and maybe that can be used in the future.

And yes there are api's for Linux.
Whether they can do all the stuff that should physically be possible with the hardware or are well constructed is another question.
I see that most of the available api's disapoint me.
Or they aren't general enough for what they do. Or you have to have specific set of distros. Or some other reason. It's mostly lack of functionality.
It's not that your stuff works that someone else his stuff also works. Especially when it's more advanced than just software. (Hint, hint electronics)

Your DRM isn't going to help me with some custom coprocessor.
We need general solutions that work for everything, everyone, always.

Do we have a stable and advanced input api that can do multiple mice, keyboards, stylusses, touchscreens and other custom sensors in a general way?
No we haven't!

What do you mean? There are tons of API's available for Linux... And stable at it.

Also... As long as the kernel hackers and distro's solve the problems, the programmer can focus on stable APIs for programming apps, like OpenGL or whatever....

Yeah but having a lot of software libraries that compile doesn't means you have quality.

Application programmers shouldn't focus on stable api's such as OpenGL. Because opengl is for using graphics cards. It's not just a piece of software. It's a set of functions that deliver the building blocks of graphics cards to you. You need to be able to steer your graphics card. You need the kernel hackers making infrastructure for such advanced features.

The biggest problem I have Is that everybody seems to think that thinking outside and in a large box doesn't matter.
Problem are with all kinds of external projects taking over resource management, thinking they can do it but don't deliver.
The failure of Khronos to realize the use and possibilities of version numbers.
Here's another example. Support for multiple screens? Yes. How much? 2
See what's my problem with this situation?

And DRM has no support for FP and other problems.
Let's see the link at DRM next.
They can't do something because of x server expects it! - Hmm this x server thing might be better a kernel project/in the kernel itself, shouldn't it!
Because it's disrupting the entire kernel infrastructure for low-level things!

[V!NCENT]

In order to do the stuff you mentioned, someone had to make the kernel fit for drivers for such things first (someone had to bother).
(e.g. graphic card, sound card, wifi card)
Or provide extra software outside the kernel and LSB that causes fragmentation.

Linux kernel driver module compatibility you mean? Already present and working with HURD. KMS being worked on.

A good kernel design and api that allows modularity and all kinds of stuff is key to a good operating system.

Only aplies to proprietary stuff. Linux doesn't work that way. Appearantly it works, so why change it? Also: Linux has kernel modules.

As an electronics student, I have seen way to many people who just don't get that you need api's here too. For developing drivers you need a kernel api.

Linux has an API?

OpenGL needs graphics cards, that need stable, advanced and mature kernel api's to make their drivers work reliably and efficient.

Here's your graphics API -> http://en.wikipedia.org/wiki/Direct_Rendering_Manager

An operating system allows the programmer to use the same api for millions of system configurations and electronic parts. The same thing is true from the perspective of that hardware. To make it's api's available for millions of programs.

What do you mean? There are tons of API's available for Linux... And stable at it.

Also... As long as the kernel hackers and distro's solve the problems, the programmer can focus on stable APIs for programming apps, like OpenGL or whatever....

[plonoma]

This has nothing to do with the kind of kernel (monolithic or microkernel or hybrid)

In order to do the stuff you mentioned, someone had to make the kernel fit for drivers for such things first (someone had to bother).
(e.g. graphic card, sound card, wifi card)
Or provide extra software outside the kernel and LSB that causes fragmentation.

A good kernel design and api that allows modularity and all kinds of stuff is key to a good operating system.

As an electronics student, I have seen way to many people who just don't get that you need api's here too. For developing drivers you need a kernel api.

OpenGL needs graphics cards, that need stable, advanced and mature kernel api's to make their drivers work reliably and efficient.

An operating system allows the programmer to use the same api for millions of system configurations and electronic parts. The same thing is true from the perspective of that hardware. To make it's api's available for millions of programs.

[V!NCENT]

Operating Systems do not define certain rules. Its sole purpose is to make application development easyer for the programmer in the sence that it indeed makes the apps runnable on any computer. The second purpose is to make them all run at the same time in order to ensure maximum resource utilisation efficiency over time.

Well now, if a programmer can use a widget toolkit, OpenGL, bash commands, a language, etc., then why bother with the kernel API?

Maybe you'd be interested in Minix 3 (microkernel)? Or experiment with the less stable Mach/HURD (Debian has a distro version of it).

[plonoma]

To make this easy to visualize what I've said in my earlier post.
Here's an image:
http://www.khronos.org/openwf/images/openwf-api-4.png

[plonoma]

Keep it simple is nice and I'm doing just that. On a global level.

The X server and some things make it very hard for the distinction between userspace libraries and kernel stuff as you describe.

I'm for this distinction and think you're right about it.
Just not about what belongs to which one of the two.

I mean these servers do the window and other resource management! That is a resource management for programs! This stuff needs a standardized api set in the kernel! This is core operating system stuff!

According to your model, the X server and some other stuff should be in the kernel.
Because they make sure programs don't mess with each others window!


For application developers you need to standardize some official userspace libraries.
And that's why I'm talking about the LSB. You need to think about both sides here. Be complete you know! (I was only mentioning this to be complete.)



EGL is for sharing buffers between applications.
Okay it's better explained this way:

EGL? is an interface between Khronos rendering APIs such as OpenGL ES or OpenVG and the underlying native platform window system. It handles graphics context management, surface/buffer binding, and rendering synchronization and enables high-performance, accelerated, mixed-mode 2D and 3D rendering using other Khronos APIs.

...the underlying native platform window system.

This is something you want in the kernel. Because it handles the different windows. This is for managing and sharing contex and data between applications. Making sure they don't screw up each others data. And you want drivers to implement this core operating system functionality. That's another very solid reason to add it in the kernel.



Now let's take a look at OpenWF.

OpenWF? is a royalty-free, cross-platform API that provides a low-level hardware abstraction interface for composited windowing systems to make use of composition and display hardware. OpenWF is targeted primarily at handheld devices that require portable acceleration of composition whilst minimizing memory bandwidth usage and power levels.

This is an api that again is about resources and organizing the computers resources and hardware for applications. This is pretty deep level stuff and actually needs to be in the kernel. Also a standardized api like this enables kernel optimization and drivers that do hardware accelerated compositing on graphics cards. And the api for this is again about organizing resources for programs. Thus validating it's reason for being in the kernel.

Now to close this post.
EGL is coming, it's being implemented in mesa and used in Google Android!
And someone is implementing OpenWF over KMS.

--------------------------------------------------------------------

Linux has failed because it has some:
- bad design, it's improving
- is a moving target.
Having independent projects like X.server doing core operating system functions such as resource management only makes this worse.

- stability problems because of lack of maturity.
- stability and compatibility problems because of lack of solid userspace api's.

EGL and OpenWF help to solve these problems.

[?John?]

Remember the "keep it simple" principle?

The EGL and compositing sounds something that should be done in the Linux Kernel itself to be most efficient and integrated. Some kind of Linux EGL + OpenWF for compositing would greatly enhance compatibility and stability of applications.

Same for opengl (+es). The Linux Kernel should have a official reference software library (+version) for that API. Windows has that. Now mesa is an unofficial software implementation.

The LSB should ask for some improvements on the graphics side through use of EGL+OpenWF.

Oh please no. The Linux kernel is big and complicated already without all of the things you would like to see implemented.

Exactly - absolutely no! Every reasonable person must understand that the only thing that makes sense to be implemented in the kernel is the low level mechanisms that abstract the hardware and facilitate multitasking, which is the very purpose of the operating system! Notice that WDDM is basically a copycat of DRI2. Wonder why? Because it's probably the most reasonable way to implement GPU multitasking.

Lets have a look at multitasking in general:
The idea is that running programs must not screw (neither accidentally or deliberately) each other - that means no messing with other than their own data or grabbing the hardware and doing whatever they want. That's where the "if I want to do something other than messing with my own stuff, I have to politely ask the OS to do that for me" mechanism (also known as "syscall") comes from.
The graphics hardware is basically a computer on it's own (processor with integrated memory controller, memory and display controllers), so there needs to be a mechanism to manage the memory, submit commands and data (after checking it for correctness for the sake of security and robustness) and then get the results. Everything else (translating high-level API constructs to GPU's native machine language) belongs in user space libraries that the user programs link to, so that they properly use this low-level functionality on their behalf.

[Nobu]

I don't see why so many people are up in arms about Wayland "replacing" Xorg, anyway....

Correct me if I'm wrong, but:

• Xorg is an implementation of the X11 protocol
  • The X11 protocol is for remote window management
• Wayland is a compositing manager/protocol
  • It is for local compositing, programs manage their own windows (or allow an external lib/program to do so)

Therefore, Xorg can be slimmed down to just the networking components and used for its original purpose, while Wayland can composite windows locally. Both handling one thing, and handling it well.

Well, there are still a few loose ends (keyboard, mouse, etc. input management) which still need to be handled by whatever implements Wayland (unless they've already addressed that; I haven't been keeping up with the mailing list discussions), but if you can abstract that (and even if you can't), it still leads to a more streamlined implementation (and fewer bugs in Xorg--and Wayland compositors, eventually).