On Tue, 12 Feb 2019, Geert Uytterhoeven wrote:
On Tue, Feb 12, 2019 at 6:31 AM Finn Thain <fthain@xxxxxxxxxxxxxxxxxxx> wrote:
There's an 'inverse' option in amifb, atafb, imstt, macfb, matroxfb,
pvr2fb and vesafb. However, it's dead code in atafb, macfb, matroxfb
and vesafb. The others use fb_invert_cmaps() but this has no effect on
the framebuffer console. Does anyone know what this option is/was used
for?
To invert the console? ;-)
Calling fb_invert_cmaps() inverts the default colormaps, and is thus
intended to have an effect on the frame buffer console.
Calling fb_invert_cmaps() would affect all (new?) frame buffer consoles,
right? If so, passing the same option to N drivers would defeat that
setting, for even values of N. The effect of those settings would seem to
depend on the driver probe order.
Anything we might do to fix this in matroxfb or vesafb has the potential
to mess up someone's multi-driver setup. Is that why "inverse" is a no-op
there?
If this no longer works (due to some refactoring during the past +20
years?), that's a bug.
Calling fb_invert_cmaps() doesn't seem to have any effect on aranym, qemu
nor (I'm told) centris 650. Maybe the default cmap is never actually sent
to the driver?
--
Gr{oetje,eeting}s,
Geert
