Date: Sat, 23 May 2020 18:57:47 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi@yahoo.com> Cc: freebsd-arm@freebsd.org, bob prohaska <fbsd@www.zefox.net> Subject: Re: X trouble on Rpi3, was Re: Missing /dev/io on rpi3 running 12-stable Message-ID: <20200524015747.GA81498@www.zefox.net> In-Reply-To: <17328C3E-730A-4199-899F-01D3D8060BC1@yahoo.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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! bob prohaska
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200524015747.GA81498>