XLIB is a graphics library. Xm is a toolkit etc. While xlib does
have windows, so does most high end graphics hardware. The X Window
system does not provide menus, high level display managment
primitives, etc. These are provided by X client applications,
typically with the help of one of the many X toolkits that is
available.
Get your facts straight.
Linus is right about this. There is an interesting X project (called
direct X I think) that was done at SGI that would take all the
overhead of the X protocol out of the loop with some special kernel
magic. However, that magic was to implement a light weight system
call-like thing where you basically map the X server and its data into
your process as part of this system call. You could then do things
like direct DMA to the device. It also turns out that X has a huge
protocol overhead, as a percentage of graphics speed, when your
graphics hardware gets fast enough. The folks at SGI did some
profiling and found that this time was 90% of the processing time. If
they made hardware that was 2x as fast, it would only give them a 5%
improvement due to other system factors. That's why they went off and
at least investigated direct X, a protocol optional, transport
optional extension to X. There is a good paper about it in the
proceedings of 1995's X Technical conference. The other reason they
wanted it to be a system call was to allow the server to verify memory
addresses and such before writing to them with its elevated privs.
Sorry to go off on this tangent, but I think Linus has a good head on
his shoulders for this. There may be somethings the kernel can do
that is desirable that it doesn't do right now wrt video, however
putting the X server into the kernel, effectively, isn't one of them.
Warner Losh
imp@village.org
in a former life I did X toolkit development for a living...