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 <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
<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 <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 <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 <https://github.com/SolraBizna/mac_qfb_driver/blob/
e78ba4ccd08d254a10bad7c13d90810b17dbfd87/src/control.cc#L48-L62>