|Summary:||Hard coded bcm2835 framebuffer bpp breaks Qt QImage|
|Product:||Base System||Reporter:||Steve Peurifoy <ssw01>|
|Component:||arm||Assignee:||Oleksandr Tymoshenko <gonzo>|
|Severity:||Affects Only Me||CC:||dennis.r.friedrichsen, freebsd, gonzo, jonc, marklmi26-fbsd, nakaji|
Description Steve Peurifoy 2019-01-31 23:21:51 UTC
Comment 1 Oleksandr Tymoshenko 2019-01-31 23:34:28 UTC
Could you provide more information? - What are the steps to reproduce the problem? - What is expected outcome? - What is actual outcome?
Comment 2 Steve Peurifoy 2019-01-31 23:35:42 UTC
Created attachment 201574 [details] Patches to three files in sys/arm/broadcom/bcm2835
Comment 3 Steve Peurifoy 2019-01-31 23:48:47 UTC
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".
Comment 4 Steve Peurifoy 2019-02-01 01:00:24 UTC
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
Comment 5 Florian Märkl 2019-08-24 20:04:46 UTC
Created attachment 206862 [details] Same patch as the previous, but with fixed formatting
Comment 6 Florian Märkl 2019-08-24 20:25:57 UTC
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.
Comment 7 commit-hook 2019-09-08 09:48:19 UTC
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 <email@example.com> 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
Comment 8 Oleksandr Tymoshenko 2019-09-08 09:49:48 UTC
Committed. Sorry it took so long. Thanks for reporting and cleaning-up the patch.
Comment 9 Mark Millard 2020-05-24 03:23:58 UTC
(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.
Comment 10 Jonathan Chen 2020-06-03 23:51:12 UTC
Any chance of this patch making it to 12-STABLE?
Comment 11 Oleksandr Tymoshenko 2020-06-04 00:00:51 UTC
I'll take a look if it's MFC-able.
Comment 12 Oleksandr Tymoshenko 2020-06-04 04:01:05 UTC
Created attachment 215211 [details] rpi12-fb-inherit.patch MFC patch
Comment 13 Oleksandr Tymoshenko 2020-06-04 04:04:46 UTC
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.
Comment 14 Jonathan Chen 2020-06-07 02:56:37 UTC
I've applied the patch and tested against 12-STABLE (r361657), and can confirm that it fixes bug 246319.
Comment 15 commit-hook 2020-06-08 00:20:58 UTC
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 <firstname.lastname@example.org> Tested by: Johnathan Chen <email@example.com> (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
Comment 16 Oleksandr Tymoshenko 2020-06-08 01:51:00 UTC
Thanks for testing Jonathan. I committed the patch. Sorry for the mistake in your name in the commit message :(
Comment 17 NAKAJI Hiroyuki 2020-06-30 08:12:08 UTC
I tested the patch against 12.1-RELEASE-p6 on my rpi2. It works great.