Will Wayland Become A New Desktop Standard?

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.

Quote:

---

Originally Posted by plonoma

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.

Quote:

---

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.

Quote:

---

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?

Quote:

---

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

Quote:

---

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....

Quote:

---

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.

Quote:

---

Quote:

---

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!

Quote:

---

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!

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?

Quote:

---

Originally Posted by V!NCENT

-Made it practically imune to rootkits.

---

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

Quote:

---

Originally Posted by plonoma

That's nice but there should be a general system for all kinds of hardware physically possible.

---

Isn't the point that APIs are hard to design, and good APIs are extremely hard to design?

Someone could sit down and design an API, and then at a later point, some hardware would come along that requires things that this API doesn't make possible. Then the API needs to be redesigned, or a new version created, and we have the same compatibility issues that we had when we had no API.

I mean, this could probably work if Linux had 10-100 times the number of full time developers working on it.

Another thing, as I see it, is that, yes, APIs make it easier for user-space and outside kernel driver developers, but they make it harder for kernel developers who constrain themselves with these APIs. And since Linux is, in part at least, made for developers by developers, I think a lot of people would not be happy with these constraints.

But sometimes you need an API, to be able to use external modules like binary drivers. :p

Via Greg K-H with the comment, "See, no stable api for Linux was the right thing to do" :
http://www.h-online.com/open/feature...f-1232036.html

I'm sort of amazed that after all this time people are still arguing for a stable kernel API.

Quote:

---

X definitely needs some work as far as compositing goes, but mend it, don't end it please!

---

Yahhh IBM, Intel, AMD, Google, Novell, RedHat, Oracle, Plus the countless others have been trying to
do that for years. The flaw is in its design. Wayland was created because it was faster to just start over than to try and fix X. Besides Wayland is almost complete.

Quote:

---

I wouldn't mind betting that the big distros will be shipping X for many many years to come on their default install.

---

Wrong the big guys already have plans to jump the X ship as soon as the Gtk and Qt compositors are considered stable. Qt's compositor will be shipping with Qt5 and Lighthouse. And both Gtk and Qt's compositors are almost complete.

Quote:

---

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

---

The Linux Standard Base is garbage.

Quote:

---

Even if the only benefit of wayland was a "cleaner" codebase the benefits would be big

---

If your saying that the Wayland code base is messy then you haven't even looked at it. The only problem I see is the lack of proper documentation.

Quote:

---

So basically they will be totaly and completely bundled.

---

Nope they only applications that are going to have to be ported are the ones that are
using xlib or it's friends directly.

Quote:

---

I wonder, can DBUS be used for Wayland instead of a custom socket protocol?

---

Someone should pimp slap you for that dumb a*& comment, why the hell would you wan't to do that??? Wayland was designed to be as abstract as possible. Besides Dbus is crap, the future is BEEP: Blocks Extensible Exchange Protocol for IPC

Quote:

---

It served its purpose well for many years, but now it's just preventing us from going further.

---

That and not having proper opensource hardware accelerated Ati/Nvidia/PowerVR drivers.

Quote:

---

"Each Wayland Server implementation can provide its own distinct set of interfaces..." This is a joke, right? We're doomed.

---

Lol he doesn't even know what that means

Quote:

---

Oh, and adding another layer of indirection seems like a stupid idea.

---

Layer of indirection it works directly with the FBO!!!

Quote:

---

Because the graphics developers are not amateurs and realize that reinventing the wheel is a *lot* harder than just adding bells and whistles to an already-working wheel.

---

Dude it's GL that works on the Frame Buffer. The protocol is almost complete, Gtk and Qt4 already
work on it. And if you have even looked at Wayland source you would see that its only a couple thousand lines of code.

Quote:

---

So Wayland will be bundled with both compositor and window manager..

---

No each toolkit builds there own client compositors and anyone can build a window manager with it.
Everyone and there mother will have there own Wayland window manager that they wrote. Qt5 will
have classes just to build a window manager.

Quote:

---

They are specifically X11 window managers and won't work. Actually, window management is done by wayland and window decoration by the clients

---

Your kinda right. I like to think of it as a scenemanager.

And one last one.

Quote:

---

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

---

My core system is on it's own primary partition that is read only and only accessible locally. And if that isn't enough I have a 12 gauge and a Rottweiler and I live in Pennsylvania. There isn't a hacker on this planet that is going to root my box. So yahh linux can be immune to root kits.

Quote:

---

Originally Posted by zester

Someone should pimp slap you for that dumb a*& comment, why the hell would you wan't to do that??? Wayland was designed to be as abstract as possible. Besides Dbus is crap, the future is BEEP: Blocks Extensible Exchange Protocol for IPC

---

I'd do this to have only one IPC protocol, which already has nice features for access control.

BEEP looks nice, but as far as I understand it doesn't specify marshaling formats.

Quote:

---

My core system is on it's own primary partition that is read only and only accessible locally. And if that isn't enough I have a 12 gauge and a Rottweiler and I live in Pennsylvania. There isn't a hacker on this planet that is going to root my box. So yahh linux can be immune to root kits.

---

If your system is available over the network then it can be rooted (even if in theory).