On Sat, Oct 03, 2020 at 04:50:28PM +0200, Mark Kettenis wrote:
> The astfb(4) is a little-endian framebuffer on a (for now) big-endian
> architecture. Therefore we need to tell X that the pixels have their
> color components laid out in a non-standard way.
>
> Note that support for this pixel layout in X is weak. Normal stuff
> works but the software rendering in Mesa doesn't seem to work
> properly. So while this is good enough to get a bunch of xterms on
> the screen, glxgears will have the wrong colors.
>
> ok?
yes, ok.
>
> P.S. I don't think basing on the wsdisplay type is the right thing to
> do, but it is what we have done in the past. Maybe we should
> extend wsdisplay_fbinfo with some fields that communicate the
> pixel format and use that?
>
>
> Index: driver/xf86-video-wsfb/src/wsfb_driver.c
> ===================================================================
> RCS file: /cvs/xenocara/driver/xf86-video-wsfb/src/wsfb_driver.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 wsfb_driver.c
> --- driver/xf86-video-wsfb/src/wsfb_driver.c 27 Jul 2019 07:48:19 -0000
> 1.38
> +++ driver/xf86-video-wsfb/src/wsfb_driver.c 3 Oct 2020 14:39:18 -0000
> @@ -632,6 +632,17 @@ WsfbPreInit(ScrnInfoPtr pScrn, int flags
> masks.blue = 0x1f;
> }
> break;
> + case WSDISPLAY_TYPE_ASTFB:
> + if (pScrn->depth > 16) {
> + masks.red = 0x0000ff00;
> + masks.green = 0x00ff0000;
> + masks.blue = 0xff000000;
> + } else {
> + masks.red = 0x1f;
> + masks.green = 0x3f << 5;
> + masks.blue = 0x1f << 11;
> + }
> + break;
> default:
> masks.red = 0;
> masks.green = 0;
--
Matthieu Herrb
