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.
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.
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
(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.)
(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.
(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.
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.
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.
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.
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.
(In reply to Brian Scott from comment #9) You may want to close this report as fixed.