Path: utzoo!attcan!uunet!wuarchive!swbatl!texbell!moxie!texsun!exodus!wind.Eng.Sun.COM
From: naughton@wind.Eng.Sun.COM (Patrick Naughton)
Newsgroups: comp.windows.x
Subject: Re: Locking Areas of the (physical) Display.
Message-ID: <1990Oct29.093341@wind.Eng.Sun.COM>
Date: 29 Oct 90 17:33:41 GMT
References: <1990Oct28.223626.1319@research.canon.oz.au>
Sender: news@exodus.Eng.Sun.COM
Reply-To: naughton@wind.Eng.Sun.COM (Patrick Naughton)
Organization: Sun Microsystems, Inc. - Mountain View, CA
Lines: 43

In article <1990Oct28.223626.1319@research.canon.oz.au>,
andy@research.canon.oz.au (Andy Newman) writes:
	...
|> 
|> I have some hardware that writes directly to the framebuffer
|> memory, this hardware is controlled from the application. The
|> hardware can write anywhere on the display so directing it to
|> the area of the screen containing the application's window is
|> not a problem.
|> 
|> The problem arises from having the user move the window while
|> my hardware is writing to display memory or having another
|> client map a window over the area being written, or any other
|> modifications to the display area in which the hardware is
|> writing.
|> 
	...

You would need to extend your X11 server to create a "synchronous
per-window shared clip information area" between the client and the
server.  When the client which controls your hardware starts up, it
should use this (hypothetical) extension to mark a window as "special"
and then the server could create the shared clip information and tell
the client where to find it.  When the server updates your window's
clip information when the window is obscured or moved, it will keep the
shared area up to date.  At this point all that is left is the
syncronized locking to arbitrate who can write to the display and when
the clip information is updated.  This could be done in many ways, but
most likely would require some kernel support.  There also must be
special consideration paid to software cursors.

This is "more or less" what we call DGA (Direct Graphics Access), and
it is how our products like XGL get direct access to framebuffer
hardware.

Hope this helps.

-Patrick
--
    ______________________________________________________________________
    Patrick J. Naughton				    ARPA: naughton@sun.com
    Windows and Graphics Group			    UUCP: ...!sun!naughton
    Sun Microsystems, Inc.			    AT&T: (415) 336 - 1080