>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

I'd suggest a command line option as less likely to incur the wrath of
purists. Making X look in a file would be convenient, but not normal X
behavior, and would undoubtedly irk some people. Having a command line
option the could itself resid in the X startup file would be nearly as
convenient and wouldn't even manifest itself to those who didn't use it.

_disclaimer-
I am not a programmer and don't even play one on TV


Brad

Stephen B. Salai                            Phone (716) 325-5553
Cumpston & Shaw                          Fax    (716) 262-3906
Two State Street                          email bsalai@servtech.com
Rochester, NY 14614