Same picture is for input devices like keyboard, mouse. What the hell
X is doing here? I can see either kernel drivers or X drivers are out
of adequate architecture. Am i wrong?

This is part 1 - why another hardware abstraction layer. Please,
comment here.
well i think its pretty obvious

Second, we-use-network. Very fine that i don't need to provide an IP
stack, firewall to see movie and browser. It can be done through
sockets and is configured such way by default. Very good. But why
anyway? Why should it be possible to run X server on some other
machine than mine? Anyone is really using it? Isn't it like dead
concept along with mainframes? I have laptop with such an good graphic
card, it can really draw graphic so well. Dedicated X drawing server
is really out of business here. I have a strong opinion that this is a
common situation. I believe it could be like branch of Xorg or config
option that runs faster because it really relies only on local
hardware.

Why X should use network subsystem? Please, comment here.

this is a development thing actually, normally we can switch

Third, how to think different. There is a framebuffer kernel video
driver. What is wrong with it for using it instead of X? I understand
that all apps relay on X. It's a matter of lots code changes, i
understand all. Just theoretically, is there something wrong? Maybe
some performance issues? Like limiting kernel time execution or
something... i believe this could have relatively simple solution.

I'm sorry for my bad English.
Well, part 1 oughta clear this last question. kernel-drivers are basic

I'm not as much into kernel and X internal as i'd like to be, but
here's what i know:

(really basically)
1) there is a kernel, which knows how to put graphic data into
different video cards video memory and it's called "kernel video
driver",

2) there is X video driver, which knows how to call kernel video
driver to draw current X screen layout

3) there is an application of type "window manager" or something like
that, which knows about current running applications' windows and
tells X to draw those windows

Same picture is for input devices like keyboard, mouse. What the hell
X is doing here? I can see either kernel drivers or X drivers are out
of adequate architecture. Am i wrong?

Second, we-use-network. Very fine that i don't need to provide an IP
stack, firewall to see movie and browser. It can be done through
sockets and is configured such way by default. Very good. But why
anyway? Why should it be possible to run X server on some other
machine than mine? Anyone is really using it? Isn't it like dead
concept along with mainframes?

I have laptop with such an good graphic
card, it can really draw graphic so well. Dedicated X drawing server
is really out of business here. I have a strong opinion that this is a
common situation. I believe it could be like branch of Xorg or config
option that runs faster because it really relies only on local
hardware.

Why X should use network subsystem? Please, comment here.

Third, how to think different. There is a framebuffer kernel video
driver. What is wrong with it for using it instead of X? I understand
that all apps relay on X. It's a matter of lots code changes, i
understand all. Just theoretically, is there something wrong? Maybe
some performance issues? Like limiting kernel time execution or
something... i believe this could have relatively simple solution.

Second, we-use-network. Very fine that i don't need to provide an IP
stack, firewall to see movie and browser. It can be done through
sockets and is configured such way by default. Very good. But why
anyway? Why should it be possible to run X server on some other
machine than mine?

Anyone is really using it?

Isn't it like dead
concept along with mainframes? I have laptop with such an good graphic
card, it can really draw graphic so well. Dedicated X drawing server
is really out of business here.

Second, we-use-network. Very fine that i don't need to provide an IP
stack, firewall to see movie and browser. It can be done through
sockets and is configured such way by default. Very good. But why
anyway? Why should it be possible to run X server on some other
machine than mine? Anyone is really using it? Isn't it like dead
concept along with mainframes? I have laptop with such an good graphic
card, it can really draw graphic so well. Dedicated X drawing server
is really out of business here. I have a strong opinion that this is a
common situation. I believe it could be like branch of Xorg or config
option that runs faster because it really relies only on local
hardware.

Why X should use network subsystem? Please, comment here.

Third, how to think different. There is a framebuffer kernel video
driver. What is wrong with it for using it instead of X? I understand
that all apps relay on X. It's a matter of lots code changes, i
understand all. Just theoretically, is there something wrong? Maybe
some performance issues? Like limiting kernel time execution or
something... i believe this could have relatively simple solution.

Temoto <temo... at (no spam) gmail.com> writes:

Second, we-use-network. Very fine that i don't need to provide an IP
stack, firewall to see movie and browser. It can be done through
sockets and is configured such way by default. Very good. But why
anyway? Why should it be possible to run X server on some other
machine than mine? Anyone is really using it? Isn't it like dead
concept along with mainframes? I have laptop with such an good graphic
card, it can really draw graphic so well. Dedicated X drawing server
is really out of business here. I have a strong opinion that this is a
common situation. I believe it could be like branch of Xorg or config
option that runs faster because it really relies only on local
hardware.

Why X should use network subsystem? Please, comment here.

This is actually incredibly useful, and I use it every day -- being
able to run gnumeric on my laptop, with the display appearing on my
desktop, makes life much, much easier for me.  I think this is
definitely one of the differences between somebody who grew up on
Windows and somebody who grew up on Unix:  having to actually be
physically at a computer to work with it seems horribly limiting to an
old Unix person, while working any other way seems useless to an old
Windows person.

Third, how to think different. There is a framebuffer kernel video
driver. What is wrong with it for using it instead of X? I understand
that all apps relay on X. It's a matter of lots code changes, i
understand all. Just theoretically, is there something wrong? Maybe
some performance issues? Like limiting kernel time execution or
something... i believe this could have relatively simple solution.

Does the framebuffer driver support acceleration?

Temoto <temo... at (no spam) gmail.com> wrote:

I'm not as much into kernel and X internal as i'd like to be, but
here's what i know:

(really basically)
1) there is a kernel, which knows how to put graphic data into
different video cards video memory and it's called "kernel video
driver",

2) there is X video driver, which knows how to call kernel video
driver to draw current X screen layout

3) there is an application of type "window manager" or something like
that, which knows about current running applications' windows and
tells X to draw those windows

Same picture is for input devices like keyboard, mouse. What the hell
X is doing here? I can see either kernel drivers or X drivers are out
of adequate architecture. Am i wrong?

You are wrong.  ;)

There are some very good reasons why this "dual layer" architecture still
makes sense.  Typically, a graphics chip vendor has a large number of
devices, but those devices are in families.  All of the devices in a family
will have essentially the same hardware initialization sequences, but
different capabilities in the drawing primitives.

By encapsulating the hardware initialization stuff in one layer, but
putting the drawing support in another, the vendor can introduce new
drawing capabilities by changing just one layer.  For those keeping score
at home, this is also exactly how Windows works: the miniport handles the
hardware initialization and memory management, and the display driver
handles only the drawing.

Further, by putting the hardware initialization in the kernel, it enables
graphical systems other than X to use the hardware.  Most of the non-X
windowing systems don't care all that much about 2D acceleration, so the
division doesn't hurt them.

Second, we-use-network. Very fine that i don't need to provide an IP
stack, firewall to see movie and browser. It can be done through
sockets and is configured such way by default. Very good. But why
anyway? Why should it be possible to run X server on some other
machine than mine? Anyone is really using it? Isn't it like dead
concept along with mainframes?

Just because YOU don't need it doesn't mean it isn't used.  There are still
places where you have a massive central server with inexpensive display
systems around the building.

I have laptop with such an good graphic
card, it can really draw graphic so well. Dedicated X drawing server
is really out of business here. I have a strong opinion that this is a
common situation. I believe it could be like branch of Xorg or config
option that runs faster because it really relies only on local
hardware.

Why X should use network subsystem? Please, comment here.

You might want to scan through some of the X.Org source code.  If the
client and server are on the same machine, it doesn't use a network stack..
There's a direct connection.

Third, how to think different. There is a framebuffer kernel video
driver. What is wrong with it for using it instead of X? I understand
that all apps relay on X. It's a matter of lots code changes, i
understand all. Just theoretically, is there something wrong? Maybe
some performance issues? Like limiting kernel time execution or
something... i believe this could have relatively simple solution.

The kernel video driver is very simple, as kernel code should always be. It
knows how to initialize the hardware, and it knows how do to a few simple
functions.  It doesn't know how to get your graphics chip to draw lines, or
do solid fills, or pattern fills, or screen-to-screen blits, or font-based
text drawing, or solid lines, etc.  All of that knowledge is embedded in
the X server driver.

That stuff is complicated.  If the driver has a bug, it's going to be in
the drawing code.  Better that the drawing bug be in a user-mode component
tht can be killed and restarted, rather than in a kernel driver that
requires a reboot.

--
Tim Roberts, t... at (no spam) probo.com
Providenza & Boekelheide, Inc.

[cut]

Further, by putting the hardware initialization in the kernel, it enables
graphical systems other than X to use the hardware.  Most of the non-X
windowing systems don't care all that much about 2D acceleration, so the
division doesn't hurt them.

What if we go more further and embed second layer into new kernel
drivers?
Not only initialization, but drawing too.
Bad idea as the complicated part is the drawing part. Kernel Code could not

Just because YOU don't need it doesn't mean it isn't used.  There are
still places where you have a massive central server with inexpensive
display systems around the building.

Remote desktop can handle those.
Not always in the way you want. Think of a big multi user system. VNC is a

This could be like separate process 'graphic driver'. Like on
microkernels.
And it could be even proprietary, supplied by videocard vendor. But
only a tiny driver, UNIX way. Not a all-in-one bloatware.
Better they open their source code, and or open their documentation. Both

On Aug 18, 6:50=A0pm, Joe Pfeiffer <pfeif... at (no spam) cs.nmsu.edu> wrote:
Temoto <temo... at (no spam) gmail.com> writes:
Why X should use network subsystem? Please, comment here.
....
There is crossplatform VNC. I've heard that its protocol is much more
network friendly than one of X.

Anyway, you're limited to screen and keyboard/mouse. There is no
remote sound and printers in X. Those are equally part of user
interface along with screen and keyboard.

On Aug 18, 6:50 pm, Joe Pfeiffer <pfeif... at (no spam) cs.nmsu.edu> wrote:
Temoto <temo... at (no spam) gmail.com> writes:

Second, we-use-network. Very fine that i don't need to provide an IP
stack, firewall to see movie and browser. It can be done through
sockets and is configured such way by default. Very good. But why
anyway? Why should it be possible to run X server on some other
machine than mine? Anyone is really using it? Isn't it like dead
concept along with mainframes? I have laptop with such an good graphic
card, it can really draw graphic so well. Dedicated X drawing server
is really out of business here. I have a strong opinion that this is a
common situation. I believe it could be like branch of Xorg or config
option that runs faster because it really relies only on local
hardware.

Why X should use network subsystem? Please, comment here.

This is actually incredibly useful, and I use it every day -- being
able to run gnumeric on my laptop, with the display appearing on my
desktop, makes life much, much easier for me.  I think this is
definitely one of the differences between somebody who grew up on
Windows and somebody who grew up on Unix:  having to actually be
physically at a computer to work with it seems horribly limiting to an
old Unix person, while working any other way seems useless to an old
Windows person.

There is crossplatform VNC. I've heard that its protocol is much more
network friendly than one of X.

Anyway, you're limited to screen and keyboard/mouse. There is no
remote sound and printers in X. Those are equally part of user
interface along with screen and keyboard.

Temoto <temotor at (no spam) gmail.com> writes:
On Aug 18, 6:50=A0pm, Joe Pfeiffer <pfeif... at (no spam) cs.nmsu.edu> wrote:
Temoto <temo... at (no spam) gmail.com> writes:
Why X should use network subsystem? Please, comment here.
...
There is crossplatform VNC. I've heard that its protocol is much more
network friendly than one of X.

What do you mean with "network friendly"? That I have to buy a
higher-bandwidth network connection for more money from my network
provider?

So you are proposing to extend the X protocol with sound and printing?
Good idea. Another thing that's close to the user that would be nice
to have would be support for removable storage (nowadays mostly USB
sticks).

Printing is very different, and it's perfectly reasonable in a
networked enviroment that the printers be on different machines from
either my compute server or my workstation.

anton at (no spam) mips.complang.tuwien.ac.at (Anton Ertl) writes:
Another thing that's close to the user that would be nice
to have would be support for removable storage (nowadays mostly USB
sticks).

USB sticks are something else different enough from the gui that I
don't see why it should be integrated.

Joe Pfeiffer <pfeiffer at (no spam) cs.nmsu.edu> writes:
Printing is very different, and it's perfectly reasonable in a
networked enviroment that the printers be on different machines from
either my compute server or my workstation.

Yes. But the printer I want to use at the moment is usually
relatively close to my workstation/X-terminal, whereas the compute
server might be very far away, and may not even know about the printer
I want to use. E.g., if I'm at home, and I use a client running on
one of the machines in the office, the printer I typically want to use
is my home printer, but the machine at the office does not know about
it.

It's even more extreme if I run programs on servers of other
organizations, which may be physically very far away, and where we
don't want everyone on that server to be able to print on our local
printers, nor do I want to bother the server's admin with configuring
our local printer on that server.

So it would be a good idea to piggyback printing onto one of the
typical connections between the user and the compute server, i.e.,
either X or ssh.

AFAIK there was some work on printing in some X Consortion version of
X; googling for it, I find mentions of:

|X Print Extension Protocol
|X Version 11, Release 6.4
|
|X Print Extension Library
|X Version 11, Release 6.4

However, according to <http://en.wikipedia.org/wiki/Xprint> this
extension is deprecated.