Similarly, display of framebuffer contents on a monitor or LCD panel (including the transformation of individual framebuffer values by such techniques as gamma correction) is not addressed by the GL
EGL itself does not distinguish multiple colorspace models
BTW, this is the first time I have heard it called gamma space.
I like to think of it as compressed or non-linear space.
Values written to gl_FragColor, OpenGL ES 2 and WebGL 1, or user-defined color outputs, OpenGL ES 3 and WebGL 2, are in linear space.
If the the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is SRGB then the values will be compressed to non-linear before being written to the framebuffer.
Otherwise they are written as is.
WebGL 1 & OpenGl ES 2 do not support sRGB rendering so the values are written as is.
If the currently bound texture's internal format is one of SRGB_EXT or
SRGB_ALPHA_EXT the red, green, and blue components are converted from an
sRGB color space to a linear color space as part of filtering described in
sections 3.7.7 and 3.7.8. Any alpha component is left unchanged. Ideally,
implementations should perform this color conversion on each sample prior
to filtering but implementations are allowed to perform this conversion
after filtering (though this post-filtering approach is inferior toconverting from sRGB prior to filtering).
The framebuffer is therefore considered to hold linear data and its values should be compressed to non-linear (a.k.a. gamma corrected) by the browser or window/operating system before being sent to the display,
assuming a non-linear display.
Unfortunately browsers differ in how they handle this
and, especially on mobile devices,
it is unclear which if any OSes apply gamma correction.
Only in cases where no gamma correction is applied can the values written to gl_FragColor be considered to be in non-linear space.
The canvas color space proposal together with sRGB rendering support is intended to resolve these and other color space issues.