I remembered this having gamma support, at least Basilisk II, at least at one point on some platform or other, probably X11.
What I found is:
In both B2 and SS the video driver exposed to the Mac environment handles the command to set a gamma ramp, and the Mac environment is providing them, both during the boot process and when the gamma choice is changed in the monitors control panel (which in later Mac OS versions is part of a calibration process)
When B2 gets the command to set a gamma ramp, it calls its load_ramp_palette, which puts the gamma table through to the monitor_desc's set_palette call
When SS gets the command to set a gamma ramp, it doesn't do anything besides updating the in-memory gamma table.
For a set_palette call in direct color mode (i.e. where the set_palette call is a gamma table change) the B2 and SS video_xmonitor_desc implementations put it through to X11.
In the SDL and SDL2 monitor_desc implementations, set_palette is a no-op for depth > VIDEO_DEPTH_8BIT (i.e. in direct color modes, when the call is actually a gamma change)
In regard to what interfaces the backends could use for setting this are working or not working:
SDL 1's SDL_SetGammaRamp and SDL 2's SDL_SetWindowGammaRamp work, provided you are using an SDL driver that implements it and if relevant, whatever display API the driver uses actually does something with it, for instance it works on Windows and Mac OS X. Note that Windows applies some validation to the gamma table values to avoid leaving the UI in an unusable state -- see the helpful note in the Quake 3 source https://github.com/ioquake/ioq3/blob/2003a054f9c8412ad0028b7d662d2affd169ced9/code/sdl/sdl_gamma.c#L57
On Debian 10, on a haswell/nv118 laptop, gamma changes with SDL2 in either X11 or Wayland have no effect (though note that actually running with SDL_VIDEODRIVER=wayland crashes on launch). There are many reports of gamma changes not working in recent X11 in various software. This may be down to particular video drivers, and I will try to test on some other hardware
Under Windows and Mac OS X, the SDL/SDL2 backends actually set the entire display gamma, but they cooperate with the platform's support for changing the current display gamma to follow the gamma preference of the currently focused window's application as the focus changes, and so nominally the previous gamma is restored properly when the SDL application exits.
https://twitter.com/ticky/status/1295213501250564096
I remembered this having gamma support, at least Basilisk II, at least at one point on some platform or other, probably X11.
What I found is:
load_ramp_palette
, which puts the gamma table through to themonitor_desc
'sset_palette
callset_palette
call in direct color mode (i.e. where theset_palette
call is a gamma table change) the B2 and SSvideo_x
monitor_desc
implementations put it through to X11.monitor_desc
implementations,set_palette
is a no-op for depth> VIDEO_DEPTH_8BIT
(i.e. in direct color modes, when the call is actually a gamma change)In regard to what interfaces the backends could use for setting this are working or not working:
SDL_SetGammaRamp
and SDL 2'sSDL_SetWindowGammaRamp
work, provided you are using an SDL driver that implements it and if relevant, whatever display API the driver uses actually does something with it, for instance it works on Windows and Mac OS X. Note that Windows applies some validation to the gamma table values to avoid leaving the UI in an unusable state -- see the helpful note in the Quake 3 source https://github.com/ioquake/ioq3/blob/2003a054f9c8412ad0028b7d662d2affd169ced9/code/sdl/sdl_gamma.c#L57SDL_VIDEODRIVER=wayland
crashes on launch). There are many reports of gamma changes not working in recent X11 in various software. This may be down to particular video drivers, and I will try to test on some other hardware