Could you provide more information? - What are the steps to reproduce the problem? - What is expected outcome? - What is actual outcome?
Created attachment 201574 [details] Patches to three files in sys/arm/broadcom/bcm2835
Sorry, my first bug report here so I'm still getting the hang of it. To reproduce: Install 12.0-RELEASE on SD card and insert into RPi 3B+ Install xorg and friends (using scfb) and vlc from FreeBSD package repo Try to run vlc Expected outcome: A normal vlc main window Actual outcome: A window briefly appears then disappears. In the terminal window from which vlc was invoked, a stream of messages shows up indicating that QImage was not happy with the framebuffer format. Tracing through the code reveals that QImage only supports 16 and 32 bit values for framebuffer bits per pixel. The provided patch may or may not be the proper solution to this but does allow the config.txt bpp setting of 32 to "stick".
One other item I forgot to explicitly note: all this is with the following two lines added to config.txt framebuffer_depth=32 framebuffer_ignore_alpha=1
Created attachment 206862 [details] Same patch as the previous, but with fixed formatting
I can confirm the bpp issue and that Qt does not work with that. In my case, if I set DefaultDepth 24 in my xorg.conf, X would fail to start with the following error: [ 49.309] (II) scfb(0): Using: depth (24), width (1920), height (1080) [ 49.309] (EE) scfb(0): specified depth (24) or bpp (32) doesn't match framebuffer depth (24) [ 49.310] (II) UnloadModule: "scfb" [ 49.310] (EE) Screen(s) found, but none have a usable configuration. Without the DefaultDepth option, X would start, but Qt applications show as "empty" windows without content and print the following many times to stderr: Unsupported screen format: depth: 24, bits_per_pixel: 24, red_mask: ff0000, blue_mask: ff The attached patch fixes the issue, however it seems like the formatting of it was broken, so I attached a fixed patch.
A commit references this bug: Author: gonzo Date: Sun Sep 8 09:47:22 UTC 2019 New revision: 352028 URL: https://svnweb.freebsd.org/changeset/base/352028 Log: [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> Changes: head/sys/arm/broadcom/bcm2835/bcm2835_fbd.c head/sys/arm/broadcom/bcm2835/bcm2835_mbox.c head/sys/arm/broadcom/bcm2835/bcm2835_mbox_prop.h
Committed. Sorry it took so long. Thanks for reporting and cleaning-up the patch.
(In reply to Oleksandr Tymoshenko from comment #8) Should this have been (be) MFC'd? There is the likes of bugzilla 246319 and various list submittals about the problem on older contexts than head. Folks keep having to independently figure out what is going on and notice that scfb disallows setting the figure separately --by ignoring the information in the configuration file (or command line). From the scfb man page: 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.
Any chance of this patch making it to 12-STABLE?
I'll take a look if it's MFC-able.
Created attachment 215211 [details] rpi12-fb-inherit.patch MFC patch
I won't be able to get my setup back up in the next few days so if anybody has a device to test the patch - I'd really appreciate it. I just checked that it builds but didn't verify if it breaks anything.
I've applied the patch and tested against 12-STABLE (r361657), and can confirm that it fixes bug 246319.
A commit references this bug: Author: gonzo Date: Mon Jun 8 00:20:16 UTC 2020 New revision: 361899 URL: https://svnweb.freebsd.org/changeset/base/361899 Log: MFC r352028: [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> Tested by: Johnathan Chen <jonc@chen.org.nz> (stabe/12 patch) Changes: _U stable/12/ stable/12/sys/arm/broadcom/bcm2835/bcm2835_fbd.c stable/12/sys/arm/broadcom/bcm2835/bcm2835_mbox.c stable/12/sys/arm/broadcom/bcm2835/bcm2835_mbox_prop.h
Thanks for testing Jonathan. I committed the patch. Sorry for the mistake in your name in the commit message :(
I tested the patch against 12.1-RELEASE-p6 on my rpi2. It works great.