Re: [RFC] video/macfb: Wire up inverse option
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: 2019-02-13 07:50:05
Hi Finn, CC linux-fbdev On Wed, Feb 13, 2019 at 1:14 AM Finn Thain [off-list ref] wrote:
On Tue, 12 Feb 2019, Geert Uytterhoeven wrote:quoted
On Tue, Feb 12, 2019 at 6:31 AM Finn Thain [off-list ref] wrote:quoted
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.
quoted
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@linux-m68k.org 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