Bug 246319

Summary: x11-drivers/xf86-video-scfb X windows fails to start on recent 12.1-STABLE
Product: Ports & Packages Reporter: Brian Scott <bscott>
Component: Individual Port(s)Assignee: freebsd-x11 (Nobody) <x11>
Status: Closed FIXED    
Severity: Affects Only Me CC: bscott, dennis.r.friedrichsen, hsw, jonc, marklmi26-fbsd
Priority: --- Flags: bugzilla: maintainer-feedback? (x11)
Version: Latest   
Hardware: Any   
OS: Any   

Description Brian Scott 2020-05-09 03:02:45 UTC 
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@0,0) 24bpp
fb0: fbswap: 1, pitch 3840, base rx3e83a000, 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@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.
Comment 1 Brian Scott 2020-05-09 14:27:19 UTC 
Additional testing with different versions of packages:

12 release_0 : X works properly
12 release_1 : X works properly
12 quarterly : fails

Downgraded the following packages from quarterly to release_1:

xorg-server
xf86-input-mouse
xf86-input-keyboard
xf86-video-scfb
xf86-input-libinput

I had intended to downgrade only xorg-server but needed to match the version numbers.

X started and appears to be working correctly.

Since very little changed in xf86-video-scfb and xf86-input-* are not likely to be involved, it looks like the issue must be somewhere in xorg-server.
Comment 2 Mark Millard 2020-05-23 07:10:17 UTC 
There is a command line option for starting the x server
from what I've read:

QUOTE
-fbbpp n
Sets the number of framebuffer bits per pixel. You should only set this if you're sure it's necessary; normally the server can deduce the correct value from -depth above. Useful if you want to run a depth 24 configuration with a 24 bpp framebuffer rather than the (possibly default) 32 bpp framebuffer (or vice versa). Legal values are 1, 8, 16, 24, 32. Not all drivers support all values. 
END QUOTE

Trying -fbbpp 32 might allow seeing if there is
such control in a fails-by-default context.

There is Section "Screen" . . . EndSection material:

QUOTE
DefaultFbBpp bpp
specifies which framebuffer layout to use by default. The -fbbpp command line option can be used to override this. In most cases the driver will chose the best default value for this. The only case where there is even a choice in this value is for depth 24, where some hardware supports both a packed 24 bit framebuffer layout and a sparse 32 bit framebuffer layout.
END QUOTE
Comment 3 Mark Millard 2020-05-23 07:25:09 UTC 
(In reply to Mark Millard from comment #2)

Hmm. You probably already did what I was suggesting:

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

Sorry for the noise. (Unless -fbbpp 32 on the command line works.)
Comment 4 Mark Millard 2020-05-23 08:40:28 UTC 
(In reply to Brian Scott from comment #0)

I just got a RPi3 HDMI connection to a display
going and I ended up with a working 24 bit
depth, 32 bit frame buffer bits per pixel
environment:

Booting [/boot/kernel/kernel]...               
Using DTB provided by EFI at 0x7ef6000.
EFI framebuffer information:
addr, size     0x3e513000, 0x6d8c00
dimensions     1824 x 984
stride         1824
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
. . .
fb0: <BCM2835 VT framebuffer driver> on simplebus0
fb0: keeping existing fb bpp of 32
fbd0 on fb0
WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 13.0.
VT: Replacing driver "efifb" with new "fb".
fb0: 1824x984(1824x984@0,0) 32bpp
fb0: fbswap: 1, pitch 7296, base rx3e513000, screen_size 7237632
. . .
X.Org X Server 1.20.8
X Protocol Version 11, Revision 0
[  1291.838] Build Operating System: FreeBSD 13.0-CURRENT arm64 
[  1291.838] Current Operating System: FreeBSD Pine64P2G 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r360311M: Sat Apr 25 10:39:37 PDT 2020     markmi@FBSDFHUGE:/usr/obj/cortexA53_clang/arm64.aarch64/usr/src/arm64.aarch64/sys/GENERIC-NODBG arm64
[  1291.840] Build Date: 29 April 2020  03:37:06PM
. . .
[  1291.859] (II) LoadModule: "scfb"
[  1291.859] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so
[  1291.860] (II) Module scfb: vendor="X.Org Foundation"
[  1291.860]    compiled for 1.20.7, module version = 0.0.5
[  1291.860]    ABI class: X.Org Video Driver, version 24.1
[  1291.860] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[  1291.860] (II) scfb: driver for wsdisplay framebuffer: scfb
[  1291.861] (--) Using syscons driver with X support (version 2.0)
[  1291.861] (--) using VT number 9
. . .
[  1291.861] (WW) Falling back to old probe method for modesetting
[  1291.861] (EE) open /dev/dri/card0: No such file or directory
[  1291.862] (WW) Falling back to old probe method for scfb
[  1291.862] scfb trace: probe start
[  1291.862] (II) scfb(0): using default device
[  1291.862] scfb trace: probe done
[  1291.862] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[  1291.862] scfb: PreInit 0
[  1291.862] (II) scfb(0): Using: depth (32),   width (1824),    height (984)
[  1291.862] (II) scfb(0): Creating default Display subsection in Screen section
        "Default Screen Section" for depth/fbbpp 24/32
[  1291.862] (==) scfb(0): Depth 24, (==) framebuffer bpp 32
[  1291.862] (==) scfb(0): RGB weight 888
[  1291.862] (==) scfb(0): Default visual is TrueColor
[  1291.862] (==) scfb(0): Using gamma correction (1.0, 1.0, 1.0)
[  1291.862] (II) scfb(0): Vidmem: 7011k
[  1291.863] (==) scfb(0): DPI set to (96, 96)
[  1291.863] (**) scfb(0): Using "Shadow Framebuffer"
[  1291.863] (II) Loading sub module "shadow"
[  1291.863] (II) LoadModule: "shadow"
[  1291.864] (II) Loading /usr/local/lib/xorg/modules/libshadow.so
[  1291.864] (II) Module shadow: vendor="X.Org Foundation"
[  1291.864]    compiled for 1.20.8, module version = 1.1.0
[  1291.864]    ABI class: X.Org ANSI C Emulation, version 0.4
[  1291.864] (II) Loading sub module "fb"
[  1291.864] (II) LoadModule: "fb"
[  1291.865] (II) Loading /usr/local/lib/xorg/modules/libfb.so
[  1291.867] (II) Module fb: vendor="X.Org Foundation"
[  1291.867]    compiled for 1.20.8, module version = 1.0.0
[  1291.867]    ABI class: X.Org ANSI C Emulation, version 0.4
[  1291.867] scfb: PreInit done
[  1291.867] (II) UnloadModule: "modesetting"
[  1291.867] (II) Unloading modesetting
[  1291.868] scfb: ScfbScreenInit 0
[  1291.868]    bitsPerPixel=32, depth=24, defaultVisual=TrueColor
        mask: ff0000,ff00,ff, offset: 16,8,0
[  1291.868] mmap returns: addr 0x42313000 len 0x6d9000, fd 12, off 0
[  1291.869] scfb: ScfbSave 0
[  1291.869] scfb: ScfbSave done
[  1291.869] (==) scfb(0): Backing store enabled
[  1291.870] scfb: ScfbScreenInit done

This is based on:

x11-drivers/xf86-video-scfb
x11/lumina
x11/xorg-minimal
x11/xterm

built from /usr/ports at -r533162 in and for a
FreeBSD head -r360311 aarch64 context.

Since it is working, it should be an indication of
a valid combination for depth and fbbpp.

But I'll note that scfb's man page reports:

       For this driver it is not required to specify modes in the Screen
       section of the configuration file.  The scfb driver picks up the
       currently used video mode from the framebuffer driver and uses it.
       Video modes specifications in the configuration file are ignored.

So, with that and some of the messages reported above,
it appears that the 32 for fbbpp came from efifb, was
picked up by fb, and finally picked up by scfb.
Comment 5 Mark Millard 2020-05-23 09:16:33 UTC 
(In reply to Brian Scott from comment #0)

I found the RPi3 and related fix in FreeBSD
head's sys/arm/broadcom/bcm2835/bcm2835_fbd.c :

Revision 352028 - (view) (download) (annotate) - [select for diffs] 
Modified Sun Sep 8 09:47:21 2019 UTC (8 months, 2 weeks ago) by gonzo 
File length: 7261 byte(s) 
Diff to previous 331229
[rpi] Inherit framebuffer BPP value from the VideoCore firmware

Instead of using hardcoded bpp of 24, obtain current/configured value
from VideoCore. This solves certain problems with Xorg/Qt apps that
require bpp of 32 to work properly. The mode can be forced by setting
framebuffer_depth value in config.txt

PR:		235363
Submitted by:	Steve Peurifoy <ssw01@mathistry.net>

And MFC to older contexts would be appropriate.
Comment 6 Christopher Hall 2020-06-03 02:08:21 UTC 
Same problem happened to me on 12.1-STABLE

I can confirm that for:

  FreeBSD-13.0-CURRENT-arm-armv7-RPI2-20200528-r361567.img.xz

Although some of the xorg meta ports are missing, installing
the xorg parts separately results in the final image working well.
Comment 7 Brian Scott 2020-06-07 00:37:20 UTC 
Just tested with current:
FreeBSD-13.0-CURRENT-arm64-aarch64-RPI3-20200604-r361779

All installed via packages (including xorg-server-1.20.8_1,1).

Appears to work perfectly.
Comment 8 Jonathan Chen 2020-06-07 03:02:43 UTC 
Mark Millard has correctly identified that this is due to bug 235363. I've tried a kernel with the -STABLE patch, and "startx" now works! Hopefully, it will be MFC against 12.1-STABLE soon.
Comment 9 Brian Scott 2020-06-14 12:46:57 UTC 
Success

FreeBSD-12.1-STABLE-arm64-aarch64-RPI3-20200611-r362026.img.xz

sorg-server: 1.20.8_1,1

From Xorg log:

[    65.721] (II) Module fb: vendor="X.Org Foundation"
[    65.721]    compiled for 1.20.8, module version = 1.0.0
[    65.721]    ABI class: X.Org ANSI C Emulation, version 0.4
[    65.721] scfb: PreInit done
[    65.722] scfb: ScfbScreenInit 0
[    65.722]    bitsPerPixel=32, depth=24, defaultVisual=TrueColor
        mask: ff0000,ff00,ff, offset: 16,8,0
[    65.722] mmap returns: addr 0x420fa000 len 0x500000, fd 13, off 0

Thank you.
Comment 10 Mark Millard 2020-06-14 20:01:31 UTC 
(In reply to Brian Scott from comment #9)

You may want to close this report as fixed.