> > That driver is for a VGA device which I think does not support gamma in > hardware. QEMU emulates the hardware so if it does not support gamma then > there's no place to add it in QEMU. Therefore if you want to emulate gamma > on VGA this should be done within the guest driver but that may be slower. > How does this work on real hardware? What graphics device is used there > and does that support gamma in hardware? Maybe that graphics device needs > to be emulated instead?
For understanding the MacOS side of things, I have been consulting https://developer.apple.com/library/archive/documentation/Hardware/DeviceManagers/pci_srvcs/pci_cards_drivers/Designing_PCI_Cards_Drivers.pdf To reduce visible flashes resulting from color table changes, the SetGamma > routine works in conjunction with the SetEntries control routine on indexed > devices. The SetGamma routine first loads new gamma correction data into > the > driver’s private storage; the next SetEntries control call applies the > gamma > correction as it changes the CLUT. SetGamma calls are always followed by > SetEntries control calls on indexed devices. > For direct devices, the SetGamma routine first sets up the gamma correction > data > table. Next, it synthesizes a black-to-white linear ramp color table. > Finally, it > applies the new gamma correction to the color table and sets the data > directly in > the hardware. As far as I can tell, the documentation is implying that somewhere between the driver and the physical hardware, *something* must keep track of the gamma table (even if indirectly by subsequently applying it to the palette table) to map the raw framebuffer data to gamma-corrected colors. > Perhaps this is also of interest: > https://github.com/SolraBizna/mac_qfb_driver > The nubus declaration rom supports gamma correction. This is very much of interest! Thank you. I am hoping to continue to use the mac99 machine type, but this code is a useful reference. The most basic support requires cscGetGamma and cscSetGamma to at least return success: https://github.com/cebix/macemu/commit/2676e1bd134703d888788c682fb56e07b5cf56a9 The patch to SheepShaver was small because most of the functionality was already present, albeit dead code. Surprisingly, github can't deal with CR line endings, so I can't (easily) link to some of the code to cite it: https://github.com/ozbenh/QemuMacDrivers/blob/master/shared/MacDriverUtils.c Once the gamma table is saved, it's "applied" by cscSetEntries to combine a color palette and gamma table into the "real" color. QemuMacDrivers does not seem to keep track of the palette at all, sending it upstream to the driver by calling this function in a loop: OSStatus QemuVga_SetColorEntry(UInt32 index, RGBColor *color) { VgaWriteB(0x3c8, index); VgaWriteB(0x3c9, color->red >> 8); VgaWriteB(0x3c9, color->green >> 8); VgaWriteB(0x3c9, color->blue >> 8); return noErr; } VgaWriteB seems to be doing MMIO to write those values upstream. Similarly, mac_qfb_driver seems to use MMIO to write back both the palette table and the gamma table to the driver, saving neither one in emulated driver state: https://github.com/SolraBizna/mac_qfb_driver/blob/e78ba4ccd08d254a10bad7c13d90810b17dbfd87/src/control.cc#L48-L62 I'm not sure where either driver's MMIO is received on the qemu end. At least in SheepShaver, that gamma table is indeed used in the cscSetEntries handler to create the true color mapping handed to its video driver: https://github.com/cebix/macemu/blob/96e512bd6376e78a2869f16dcc8a9028bce5ee72/SheepShaver/src/video.cpp#L299-L320 If mac_qfb_driver is, as indicated in its README, able to interoperate with an unpatched qemu, that makes me think that *potentially* qemu itself doesn't need to be patched, depending on what qemu-side code any driver is sending its MMIO to. I have an article on AmigaOS gfx here: > https://codeberg.org/qmiga/pages/wiki/AmigaOSGfx > that discusses similar issue and most of it may be applicable to MacOS > too. There's also a DeveloperTips link with some QEMU getting started > links that may help you. I have started an ati-vga emulation that could do > all this and more but it's quite complex and I could take some help with > it. Maybe that could be interesting to you as well as these ATI chips were > used on real Macs so MacOS has support for it. I also have an article > linked from the above about that. I'm continuing to read this now. Thanks already, y'all.
