Subject: Re: Maxapplezoom
To: Henry B. Hotz <henry.b.hotz@jpl.nasa.gov>
From: Ken Nakata <kenn@eden.rutgers.edu>
List: port-mac68k
Date: 10/09/1996 10:48:22
Henry B. Hotz wrote:
>[Brad Salai said]
>>Have you gotten it [MaxApplZoom] to work with X? The kernel still shows
>>640x480
>>when it startsup, but the console and dt both find the extra space. I do see
>>some about 1.2 inch horizontal lines on the right edge of the screen, but the
>>console writes over them.
>>
>>When I start X however, it only paints a 640x480 area of the screen, and acts
>>like the rest of it isn't there.
>>
>>Did you have to set X up to find the bigger area?

I would expect X not to work... at least under its current model of graphic 
device driver: the grf driver scans the video card's NuBus slot space for a 
declaration ROM and tells user-land apps such as the X server whatever the 
screen size it finds in the ROM.  I suspect MaxApplZoom fakes a decl. ROM to 
fool MacOS, and since the fake decl. ROM is gone when NetBSD/mac68k takes 
over the box, there's no way for the grf driver to tell X that the TFB card 
is actually running at a higher resolution.

>I never tried X with it.  I suspect that the problem is that everybody is
>figuring out how to get directly into the card ROM's in order to support
>non-Apple displays.  MaxApplZoom works by modifying all the OS tables after
>boot is underway.  The booter and DT work by looking at MacOS, while X
>looks directly at the card.  Or so it would appear.

No, the X server runs at whatever resolution the grf driver tells it.  It 
doesn't even try to take a peek at the card's ROM by itself.  I thought that 
dt worked the same way.  I don't know why it should work at that higher 
resolution at all, but then, it was a long time ago when I actually read the 
source...  As for the console, it's an entirely different story since it 
gets the screen size from the Booter which gets the information from MacOS 
before it falls out of the picture.

>Since MaxApplZoom modifies the hardware timing, and nothing else changes it
>back, it seems like it wouldn't take much to make X use the extra space.
>Don't ask me how though.

The only way I can think of is a dirty hack at best: add a few extra server 
options so that you can override its default behavior.  I've been thinking 
to add such an Just-do-what-I-say-'cause-I-know-what-I'm-doing kind of 
option anyway, albeit not precisely for this purpose; I want to be able to 
tell the server not to use some of the grf devices on my box so that it 
won't choke on a video device that doesn't work quite well yet on NetBSD.  
This feature would also be useful for, say, those SE/30 users with a dead 
internal monitor and a working external one, etc (my SE/30's internal 
monitor sometimes goes berzerk, too ;-).  I think I could add something else 
to override the screen size as well.  The question is how do I do it, and I 
haven't decided it yet.
That is, whether I should implement a mechanism with which the server reads 
a configuration file (a la XFree86), or I should just add command line 
options to the server.

I'm open to any suggestion on this matter, so I'd appreciate if anyone could 
give me one.

ken