Subject: Linux/SGI Xsgi server: /dev/opengl ioctl NG1_SETDISPLAYMODE

From: Miguel de Icaza <[email-masked]>
Date: Wed, 17 Sep 1997 20:34:42 -0500

Hello guys,

   IRIX Xsgi server is now clearing the screen -and crashing since I
do not have a mouse driver yet, I am quickly coding the iDev mouse
driver now-.

   But while I am doing this, I would like to ask the list about
another ioctl that the X server is issuing: the NG1_SETDISPLAYMODE, it
is being called like this:

	ioctl (/dev/opengl, NG1_SETDISPLAYMODE, { 0, 0xda0080 });
	ioctl (/dev/opengl, NG1_SETDISPLAYMODE, { 1, 0xda0100 });
	ioctl (/dev/opengl, NG1_SETDISPLAYMODE, { 2, 0xda0488 });
	ioctl (/dev/opengl, NG1_SETDISPLAYMODE, { 3, 0xda0490 });
	ioctl (/dev/opengl, NG1_SETDISPLAYMODE, { 4, 0xda0498 });
	ioctl (/dev/opengl, NG1_SETDISPLAYMODE, { 5, 0xda04a0 });
	ioctl (/dev/opengl, NG1_SETDISPLAYMODE, { 6, 0xda0500 });
	ioctl (/dev/opengl, NG1_SETDISPLAYMODE, { 7, 0xda0800 });
	ioctl (/dev/opengl, NG1_SETDISPLAYMODE, { 8, 0xda0900 });
	ioctl (/dev/opengl, NG1_SETDISPLAYMODE, { 9, 0xda0d00 });
	ioctl (/dev/opengl, NG1_SETDISPLAYMODE, { 0xa, 0xda0e00 });
	ioctl (/dev/opengl, NG1_SETDISPLAYMODE, { 0xb, 0x4ac });

    Where the structure is { int wid;  unsigned int mode }.

    Can someone tell me what the newport driver on the IRIX kernel is
doing with these calls?

    There is also another intersesting ioctl done later:
NG1_SETGAMMARAMP0, this one takes 256 reds, 256 greens and 256 blues
that I assume I have to load, do they go directly to the xmap9 lookup
table?

Thanks in advance,
Miguel.

---

From: "William J. Earl" <[email-masked]>
Date: Wed, 17 Sep 1997 19:03:28 -0700

>     Can someone tell me what the newport driver on the IRIX kernel is

     After waiting for the rex3 FIFO to drain, and the the xmap9 FIFO
to not be full, it sets the xmap9 mode register for the given "wid":

 	xmap9SetModeReg( rex3, wid, displaymode, ng1_video_timing[bd->boardnum]->cfreq ); 
where

#define xmap9SetModeReg(rex,modereg,data24,cfreq) 			\
	if (cfreq > 119 )						\
	    rex->set.dcbmode =  DCB_XMAP_ALL |  XM9_CRS_MODE_REG_DATA | \
                        DCB_DATAWIDTH_4 | W_DCB_XMAP9_PROTOCOL;	    	\
	else if (cfreq > 59) \
	    rex->set.dcbmode =  DCB_XMAP_ALL |  XM9_CRS_MODE_REG_DATA | \
                        DCB_DATAWIDTH_4 | WSLOW_DCB_XMAP9_PROTOCOL;    	\
	else \
	    rex->set.dcbmode =  DCB_XMAP_ALL |  XM9_CRS_MODE_REG_DATA | \
                        DCB_DATAWIDTH_4 | WAYSLOW_DCB_XMAP9_PROTOCOL;  	\
        rex->set.dcbdata0.byword = ((modereg) << 24) | (data24 & 0xffffff)

 > that I assume I have to load, do they go directly to the xmap9 lookup

       It sets the address register for the BT445 RAMDAC to 0, and then
then, for each RGB triple, does 

#define Bt445SetRGB( rex3, r, g, b ) \
	rex3->set.dcbdata0.byword = ( (r) << 24 ) | ( (g) << 16 ) | ( (b) << 8 )

Before setting the address and before storing each RGB triple, it does

#define BFIFOWAIT(rex) 	while ((rex)->p1.set.configmode & BFIFO);

to avoid getting a FIFO overrun.

---

From: Miguel de Icaza <[email-masked]>
Date: Wed, 17 Sep 1997 22:23:30 -0500

> 	  xmap9SetModeReg( rex3, wid, displaymode, ng1_video_timing[bd->boardnum]->cfreq ); 

If the newport registers are available to the userland application,
why the X server does not directly call those routines instead of
relying on the kernel to perform them?  Is it a convention that
applications should only touch the rex3 registers and not attempt to
program any of the other chips on the dcb?

It would make sense since the graphics context switching would not
involve the kernel peeking at the chips on the dcb what their context
is and then the pain of restoring this.  

Miguel.

---

From: "William J. Earl" <[email-masked]>
Date: Thu, 18 Sep 1997 09:19:03 -0700

> is and then the pain of restoring this.  

      I believe that making this work reasonably would require some way
of making a given user-mode primitive atomic.  This can be hacked by via various
schemes, but the current IRIX implementation does all sequences which must
be atomic in the kernel.  (For example, if I must BFIFOWAIT and then do
some stores, but I context switch after the BFIFOWAIT, there is no guarantee
that the FIFO is not full when I regain control.)