[Bug 246319] x11-drivers/xf86-video-scfb X windows fails to start on recent 12.1-STABLE

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246319

            Bug ID: 246319
           Summary: x11-drivers/xf86-video-scfb X windows fails to start
                    on recent 12.1-STABLE
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: x11 at FreeBSD.org
          Reporter: bscott at bunyatech.com.au
             Flags: maintainer-feedback?(x11 at FreeBSD.org)
          Assignee: x11 at FreeBSD.org

The problem appears to come down to (extract from Xorg.0.log):

[ 52819.563] scfb: PreInit 0
[ 52819.563] (II) scfb(0): Using: depth (24),   width (1280),    height (1024)
[ 52819.563] (EE) scfb(0): Specified fbbpp (24) is not a permitted value
[ 52819.563] (II) UnloadModule: "scfb"
[ 52819.563] (EE) Screen(s) found, but none have a usable configuration.

I've experimented with different values for Depth and FbBpp (and Default...) in
xorg.conf with very little changing.

I have seen recent reference[1] to the same error (except for FBTURBO) on linux
recently due to changed firmware where the problem would seem to be including
an incorrect parameter framebuffer_depth=24 in their config.txt file and the
fix was to remove the offending line. Unfortunately I didn't have a
framebuffer_depth= parameter in mine so I tried adding one with a value of 32.
This didn't have any effect. In both cases the boot messages for the
framebuffer show the messages:

fb0: <BCM2835 VT framebuffer driver> on simplebus0
fbd0 on fb0
VT: Replacing driver "efifb" with new "fb".
fb0: 1280x1024(1280x1024 at 0,0) 24bpp
fb0: fbswap: 1, pitch 3840, base 0x3e83a000, screen_size 3932160

The fdt doesn't appear to have much of an opinion on the matter other than the
format looks like 32 bits (8 alpha(ignored), 8 red, 8 green, and 8 blue):

        framebuffer at 3e6fa000 {
                format = "a8r8g8b8";
                stride = <0x1400>;
                height = <0x400>;
                width = <0x500>;
                reg = <0x3e6fa000 0x500000>;
                compatible = "simple-framebuffer";
                status = "okay";
        };

I've had a little dig around in the code and can't see any recent changes, much
less any smoking guns of work in this sort of area. I should qualify that by
saying that I'm definitely no expert and won't have hit the whole chain by any
stretch.

xf86-video-scfb hasn't changed significantly for a while. It seems to take what
it is given by the underlying framebuffer and passes it back to X. The error
message: "Specified fbbpp (24) is not a permitted value" isn't generated by
this driver but I'm guessing by X when the 24bpp is passed back.

sys/arm/broadcom/bcm2835/bcm2835_fb.c on stable/12 hasn't changed in any
relevant way recently but does include some interesting things:

#define FB_DEPTH                24

and later on:


        fb.bpp = FB_DEPTH;

between calls to bcm2835_mbox_fb_get_w_h and bcm2835_mbox_fb_init.

This is followed shortly after by sc->depth = fb.bpp; setting up what is then
retrieved by the X driver.

Neither bcm2835_mbox_fb_get_w_h or bcm2835_mbox_fb_init change the bpp value
but _fb_init uses it in a request to the firmware:


msg.depth.body.req.bpp = fb->bpp;

I haven't tinkered around with this at all because I'm comprehensively out my
depth at this point and building new kernels is a very slow way to experiment.

The snapshots that I've tried are
FreeBSD-12.1-STABLE-arm64-aarch64-RPI3-20200326-r359308.img.xz,
FreeBSD-12.1-STABLE-arm64-aarch64-RPI3-20200409-r359721.img.xz and
FreeBSD-12.1-STABLE-arm64-aarch64-RPI3-20200430-r360472.img.xz.

The system I had been running before I trashed it was
FreeBSD-12.1-RELEASE-arm64-aarch64-RPI3.img.xz. I have an older system laying
about (12.0 RELEASE) that I have tried and have verified that the fdt for the
framebuffer hasn't changed. The fb messages at startup were also identical
(i.e.indicating 24bpp because that's all the code can show).

As an experiment, I tried doing some mix and match with kernels. My setup has
the boot and kernel on the SD card and everything else on a USBconnected drive.
So...

12.0 RELEASE kernel + 12.1 STABLE world + packages etc - Same result. Invalid
bpp in X.

12.1 STABLE kernel + 12.0 RELEASE + a bunch of very outdated packages - Works
perfectly. Nice looking X display.

Various hacks in xf86-video-scfb such as forcing a FbBpp value of 32
irrespective of the returned value creates junk video (i.e. removed the effect
of the error checking) that may indicate that the underlying frame buffer truly
is 24bpp but X is refusing to support it.

-- 
You are receiving this mail because:
You are the assignee for the bug.