My Opera
X on sgimips
Thursday, February 19, 2009 10:35:31 PM
I got a new toy - an R5k Indy with 24bit Newport graphics. That of course meant I had to get X going. Porting the NetBSD-specific code from the XFree86-driver to Xorg was trivial, the one remaining issue is that colours look right only when X is started right after a cold boot. Restarting X or rebooting the machine ( wether or not X was running ) results in messed up colours. Must be missing something in the DAC setup.
The kernel driver needed ( and still needs ) some work as well - I added support for virtual consoles and all the related goodies, got rid of the hardware sprite cursor ( which doesn't support background inversion anyway so you can't see what's under the cursor ) mostly because it needs an ugly workaround for a hardware bug in some Newport boards - different board revisions need different offsets added to the cursor's X coordinate. So all it did was cause trouble with no benefit. There's still some work to do, like redrawing the screen when X exits, picking the right screen geometry for additional consoles and so on. Nothing complicated.
Now Newport and CRIME ( and probably other SGI graphis hardware as well ) have one thing in common - you can't really access the framebuffer directly. On CRIME you can, in a way, but it's organized in 128x128 tiles, not linear as X would like it, and they can be scattered all over main memory. Also, CRIME uses a rather unusual pixel format - it puts the alpha channel into the lowest byte instead of the highest as pretty much all mainstream graphics hardware does. These things make it mostly useless for XFree86 or Xorg.
Using the newport driver as a reference I was finally able to find out what caused the glitches I got on CRIME. A bug in XAA ( it wouldn't use scanline image uploads even if they are available, only block uploads ) and some bugs in my fix. Now Xorg on CRIME looks right, the Xserver thinks it's running an ARGB framebuffer and we have some off-screen memory.
With this we have accelerated X support on O2 and on most Indys - time to switch sgimips to native Xorg.
The kernel driver needed ( and still needs ) some work as well - I added support for virtual consoles and all the related goodies, got rid of the hardware sprite cursor ( which doesn't support background inversion anyway so you can't see what's under the cursor ) mostly because it needs an ugly workaround for a hardware bug in some Newport boards - different board revisions need different offsets added to the cursor's X coordinate. So all it did was cause trouble with no benefit. There's still some work to do, like redrawing the screen when X exits, picking the right screen geometry for additional consoles and so on. Nothing complicated.
Now Newport and CRIME ( and probably other SGI graphis hardware as well ) have one thing in common - you can't really access the framebuffer directly. On CRIME you can, in a way, but it's organized in 128x128 tiles, not linear as X would like it, and they can be scattered all over main memory. Also, CRIME uses a rather unusual pixel format - it puts the alpha channel into the lowest byte instead of the highest as pretty much all mainstream graphics hardware does. These things make it mostly useless for XFree86 or Xorg.
Using the newport driver as a reference I was finally able to find out what caused the glitches I got on CRIME. A bug in XAA ( it wouldn't use scanline image uploads even if they are available, only block uploads ) and some bugs in my fix. Now Xorg on CRIME looks right, the Xserver thinks it's running an ARGB framebuffer and we have some off-screen memory.
With this we have accelerated X support on O2 and on most Indys - time to switch sgimips to native Xorg.
