From: Mihai Cartoaje (mcartoaj@mat.ulaval.ca)
Date: Wed 30 May 2001 - 20:46:56 IDT
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: listbot@svgalib.org
Body: unsubscribe linux-svgalib
This archive was generated by hypermail 2.1.4 : Wed 21 Jan 2004 - 22:10:24 IST