Date: Sat, 23 May 2020 20:18:08 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: X trouble on Rpi3, was Re: Missing /dev/io on rpi3 running 12-stable Message-ID: <EE6335D3-E53E-47E4-A6A6-C63593E6F4A5@yahoo.com> In-Reply-To: <20200524015747.GA81498@www.zefox.net> References: <20200520164642.GA70838@www.zefox.net> <f5c8af7693b90f1aaa8394d7a13f8ac38ee4e6b6.camel@freebsd.org> <20200521022517.GA71947@www.zefox.net> <9E006FD6-493A-43CD-B242-47E00BBDFF6A@yahoo.com> <20200523052439.GB78879@www.zefox.net> <E1F49E99-592C-4A65-8981-5CA7BC9083CB@yahoo.com> <20200523224611.GA80843@www.zefox.net> <17328C3E-730A-4199-899F-01D3D8060BC1@yahoo.com> <20200524015747.GA81498@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EE6335D3-E53E-47E4-A6A6-C63593E6F4A5>