On Mon, 18 Feb 2019, Geert Uytterhoeven wrote:
> >
> > I did some more investigation. When I tested macfb in qemu, I found
> > that dafb_setpalette() is actually being called.
> >
> > And with this patch to add the missing call to fb_invert_cmaps(), the
> > dafb_setpalette() parameters change accordingly. So I'll submit this
> > patch again with signed-off-by.
> >
> > (The problem remains that dafb_setpalette() doesn't seem to have the
> > desired effect on the hardware, but that's a separate issue.)
>
> Could it be the hardware CLUT pointer is out of sync? Given lastreg is
> initialized to -1, if the first write is to regno 0, the code will
> assume the CLUT pointer is pointing to the right register.
>
> Initializing lastreg to e.g. -2 would fix that.
>
Well, Stan found that the 'inverse' option didn't work on his LC III,
which involves v8_brazil_setpalette() and not dafb_setpalette(). The bug
you found only affects the latter function. I will send a patch for the
bug though it doesn't seem to help on qemu (quadra 800). On qemu I was
able to get 'inverse' to work by switching to 2 bpp. So there seems to be
some other driver issue at work here that I'll have to look into.
> > On some powerbooks with greyscale LCD panels, the the black background
> > is actually white, due to the backlight, and the white text is opaque
> > black. This may or may not be optimal, depending on conditions etc. so
> > I prefer not to remove macfb's 'inverse' option.
>
> You can always use a higher layer to configure that, e.g. "setterm
> --inversescreen on". Won't help for the initial kernel log, though.
>
> Originally (before git history), the inverse parameter also affected
> display.inverse. While this field still exists (see fbcon.h), there is
> no code left that uses it.
>
> The last user was removed in full-history-linux commit 25e5e3c795bcf408
> ("[PATCH] fbdev: support for bold attribute for monochrome
> framebuffers").
>
> Probably reviving that, and getting rid of the fb_invert_cmaps() calls,
> is the best solution, as display.inverse does not affect other frame
> buffers.
>
Maybe. It seems like an enhancement, or at best a theoretical bug. Can I
leave that one in your hands?
--
> Gr{oetje,eeting}s,
>
> Geert
>
>
