X trouble on Rpi3, was Re: Missing /dev/io on rpi3 running 12-stable

[Mark Millard]

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)