flynn@pixel.cps.msu.edu (Patrick J. Flynn) (01/10/90)
WARNING: fooling around with the system can cause serious problems.
Now that the faint-hearted are scared away...
Here's some code which allows one to abuse the screen pixels directly.
As written, it saves the screen in a buffer, fills it with random
texture, and then restores the contents of the screen from the buffer.
See <nextdev/video.h> for the ioctl codes and cAPitAliZeD constants.
Note that the NeXT screen is advertised as 1120x832, but seems to be
laid out in memory as 1152x910. Hmm, I wonder where the 1152 came
from... :-).
Disclaimer: this was a ten-minute hack. Any or all of the info in
the preceding paragraph could be wrong. Don't blame me if your
cube's magnesium case catches on fire when you try this.
Also, don't laugh too hard at my C coding style.
--------------------------------------------------
#include <sys/file.h>
#include <sys/ioctl.h>
#include <nextdev/video.h>
#define NPIX VIDEO_MW*VIDEO_H
main()
{
char *addr; /* base addr of video RAM */
char buf[NPIX/4];
int fd,i;
fd=open("/dev/vid0",O_RDWR,0);
/* get video ram base addr. */
if (ioctl(fd, DKIOCGADDR, &addr) == -1) perror("ioctl:DKIOCGADDR");
/* save the screen */
bcopy(addr,buf,NPIX/4);
/* stomp all over the screen */
for(i=0;i<NPIX/4;i++) addr[i]=random();
/* let the user see what he hath wrought */
sleep(1);
/* restore the screen */
bcopy(buf,addr,NPIX/4);
close(fd);
}
--------------------------------------------------
See ya -- Pat
--
Patrick Flynn, CS, Mich. State U., flynn@cps.msu.edudayglow@csli.Stanford.EDU (Eric T. Ly) (01/10/90)
In article <5963@cps3xx.UUCP> flynn@pixel.cps.msu.edu (Patrick J. Flynn) writes: >Note that the NeXT screen is advertised as 1120x832, but seems to be >laid out in memory as 1152x910. Hmm, I wonder where the 1152 came >from... :-). Probably to align the pixels on byte and page boundaries. 1152 pixels wide / 4 pixels/byte = 288, and 288 x 910 pixels high = 262080 + 64 = 256 x 1024 bytes. Seems pretty likely, don't you think? Eric Ly CSLI, Stanford University
eps@toaster.SFSU.EDU (Eric P. Scott) (01/10/90)
In article <5963@cps3xx.UUCP> flynn@pixel.cps.msu.edu (Patrick J. Flynn) writes: >Now that the faint-hearted are scared away... Eek. I'm surprised you can do this at all--I wouldn't expect screen pixels to be writeable by a user process unless they were explicitly mapped into a task's address space via an ioctl that insisted on w access to its device--or is this a side-effect of DKIOCGADDR? "So much for turning off PublicWindowServer" While we're on the subject, has anyone figured out exactly what /usr/bin/blit does, and why it doesn't seem to work once the system is up and running? (Which is arguably a good thing.) -=EPS=-