Hi Finn, CC linux-fbdev On Wed, Feb 13, 2019 at 1:14 AM Finn Thain <fthain@xxxxxxxxxxxxxxxxxxx> wrote: > 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. True. This option dates back to the days only a single frame buffer device could exist on the system. > 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? No idea. > > 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? Probably. Needs more investigation. Or just remove the feature. Apparently no one used it during the last +20 years, as no one complained. (Start of thread at https://www.spinics.net/lists/linux-m68k/msg13292.html) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
