X trouble on Rpi3, was Re: Missing /dev/io on rpi3 running 12-stable
Mark Millard
marklmi at yahoo.com
Sun May 24 03:18:16 UTC 2020
On 2020-May-23, at 18:57, bob prohaska <fbsd at www.zefox.net> wrote:
> On Sat, May 23, 2020 at 06:20:13PM -0700, Mark Millard wrote:
>>
>> Unfortunately (until there is an MFC of the relevant
>> change from head that makes things work), man scfb
>> reports that you have no control because the
>> information is ignored:
>>
>> 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.
>>
>> The fix that is in FreeBSD's head is in
>> sys/arm/broadcom/bcm2835/bcm2835_fbd.c :
>>
>> QUOTE
>> 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 at mathistry.net>
>> END QUOTE
>>
>> Any version prior to being based on that sort of change needs
>> code changes for scfb to work. (It is too late for any
>> already-made final-releases to work.)
>>
>> The reason that it used to work was a bug/defect in the
>> RPi* firmware that did not actually use 24 bits for the
>> frame buffer bits per pixel when it was specified: it
>> implicitly used 32 instead.
>>
>> The one place that 24 does work for the RPi*'s is for the
>> console display. That is why they have not simply
>> disallowed 24 frame buffer bits per pixel in general.
>>
>
> It looks as if the required bug report already exists:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246319
>
> Would any further noisemaking be constructive? Squeaky wheels
> and all that 8-)
>
> Thanks for reading and taking the time to explain what's happened!
I do not know if it would help but it looks like
gonzo (Oleksandr Tymoshenko) is the one that
checked-in a variant of Steve Peurifoy's
( ssw01 at mathistry.net ) changes to:
sys/arm/broadcom/bcm2835/bcm2835_mbox_prop.h
sys/arm/broadcom/bcm2835/bcm2835_mbox.c
sys/arm/broadcom/bcm2835/bcm2835_fbd.c
This was as a fix for:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235363
(which has the original and Florian Markl's updated
patch as attachments).
Unlike that defect report's more limited notes, the issue
is not limited or specific to Qt or QImage: it is far more
general. (Frame buffer bits per pixel being 24 does not
maintain memory alignment and so would be a problem for
performance except in basic contexts, or that is what I
think I understand.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-arm
mailing list