andy@research.canon.oz.au (Andy Newman) (10/29/90)
I have a rather interesting problem with integrating a piece of hardware with an X-based application and was wondering if any kind soul(s) on the net have any ideas or could at least point me in the right direction (and its not my homework :-)). The application is based on the MOTIF widgets and runs under mwm running on the MIT R4 X server using a memory mapped framebuffer, nothing special here. Now for the fun stuff... 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. How can I ensure that the display (the area of it that the hardware is writing to) is not disturbed while my hardware is operating? I can't stop the hardware doing its stuff (which can take a few seconds) and I don't want a messy looking display with other client's windows being clobbered by my hardware's modifications to the framebuffer. I also don't want to interfere with the normal operations of the system too much (e.g. the second hand on the clock keeps spinning while the hardware works away). Any help would be much appreciated. -- Andrew Newman, Software Engineer. | Net: andy@research.canon.oz.au Canon Information Systems Research Australia | Phone: +1 61 2 805 2914 P.O. Box 313 North Ryde, NSW, Australia 2113 | Fax: +1 61 2 805 2929
klee@wsl.dec.com (Ken Lee) (10/30/90)
In article <1990Oct28.223626.1319@research.canon.oz.au>, andy@research.canon.oz.au (Andy Newman) writes: |> How can I ensure that the display (the area of it that the |> hardware is writing to) is not disturbed while my hardware is |> operating? Some of the hardware-oriented extensions to X have a similar problem. Try looking at VEX, the video extension to X. -- Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
naughton@wind.Eng.Sun.COM (Patrick Naughton) (10/30/90)
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