also sprach Nick Ray,
> Many applications require multi process or multi thread access to screen drawing yet
>do not have to be concerned about the initialisation of the device. Splitting the
>initialisation and configuration of the device and the memory mapped access is
>significant. Most applications only need to work in one mode. The initialisation and
>configuration is a system aspect and should be performed at system boot. The use of
>the drawing surfaces is an application aspect upon which the user API should
>concentrate.
Until now I didn't consider a process doing a fork or a pthread_create, but I don't
see why it wouldn't work.
> I am wondering what will happen in the future. There are certain aspects such as
>clear screen, windowing and clipping as well as text display that potentially also
>require synchronised acess to the device register set. Any ideas.
The way it functions now is that the client (master?) and server are communicating
through a pipe. The client sends the server a VGA_START_COMMAND token, an index for
the svgalib function which should be called, as well as the arguments, and the server
calls the function and sends back the return value, if any. The server can read and
write the registers, of course.
So if svgalib had a function for drawing text using the graphics co-processor, then it
would be accessible through this scheme for any process that writes on the pipe,
assuming that the kernel does not mix multiple writes.
Alternatives are packing requests together (which would not be compatible with
previous svgalib syntax), and using shared memory.
Mihai
------------------------------------------------------------------
Unsubscribe: To: [EMAIL PROTECTED]
Body: unsubscribe linux-svgalib
