> What about a simple example where you set write a bit plane mask
> into a graphics register, then write some data to the framebuffer?
> You can't have two programs doing that at the same time!
So use locking. Or ressource allocation. If the user decides to do a
stupid thing which is not possible with the hardware, it's his own
fault.
> This could easily occur if an X client were directly manipulating
> the framebuffer at the same time the X server was doing the same, or
> if you switch away from X (with the server still running...) and try
> to play a graphics game on the framebuffer console while your kernel
> compiles!
>Ben
>Please CC: bennyb@ntplx.net
This is the same "singing, dancing, we must do everything at the same
time" discussion that we had with the Amiga about 100 years ago
[1]. Look where it led us. [5]
The acceleration engine on a gfx board is a ressource. Some ressources
you can share between processes, then you can use it from more than
one process at a time. Some others you can't so you can either run a
high-speed accelerated game on an fb-console or run a high-speed
accelerated 3d application under X. If your device supports seamless
state-saving and restoring, fine. If it doesn't, you must use
exclusive access. But I'm not interested in slowing down my high-end
state of the stuff board just because there are some twenty years old
graphics boards on no longer used architectures which may _not_
support a feature which my board does. [3]
I'm fscking tired of these "we must build one generic solution to end
all other solutions". Neither X nor anything else is the silver bullet
in every possible scenario. Yes, there _will_ be people who want to
run twenty Quake sessions [2] on twenty virtual consoles at
the same time. Why must we satisfy the needs of _these_ people? We
must satisfy the needs of _most_ people. And they either work _or_
play. No need to build a solution which puts a penalty on those.
Kind regards
Henning
[1] those "we can format two floppies at the same time, look, we're
better than crappy Windows" discussion, if anyone around here is old
enough to remember.
[2] or whatever the current famous state of the art 3d
kill-some-monsters shooter is.
[3] Along the road lies DirectX [4]
[4] Or Direct3D. Or ActiveX. Or whatever the current MS marketing
decided to call their game API.
[5] Thank godness.
-- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- hps@tanstaafl.de TANSTAAFL! Consulting - Unix, Internet, SecurityHutweide 15 Fon.: 09131 / 50654-0 "There ain't no such D-91054 Buckenhof Fax.: 09131 / 50654-20 thing as a free Linux"
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/