Bug 235363 - Hard coded bcm2835 framebuffer bpp breaks Qt QImage
Summary: Hard coded bcm2835 framebuffer bpp breaks Qt QImage
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: 12.0-RELEASE
Hardware: arm64 Any
: --- Affects Only Me
Assignee: Oleksandr Tymoshenko
Depends on:
Reported: 2019-01-31 23:21 UTC by Steve Peurifoy
Modified: 2019-09-08 10:16 UTC (History)
2 users (show)

See Also:

Patches to three files in sys/arm/broadcom/bcm2835 (3.96 KB, patch)
2019-01-31 23:35 UTC, Steve Peurifoy
no flags Details | Diff
Same patch as the previous, but with fixed formatting (1.81 KB, patch)
2019-08-24 20:04 UTC, Florian Märkl
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Peurifoy 2019-01-31 23:21:51 UTC

Comment 1 Oleksandr Tymoshenko freebsd_committer freebsd_triage 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

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 freebsd_committer 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

  [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>

Comment 8 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2019-09-08 09:49:48 UTC
Committed. Sorry it took so long. Thanks for reporting and cleaning-up the patch.