Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 23 May 2020 18:20:13 -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:  <17328C3E-730A-4199-899F-01D3D8060BC1@yahoo.com>
In-Reply-To: <20200523224611.GA80843@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>

next in thread | previous in thread | raw e-mail | index | archive | help


On 2020-May-23, at 15:46, bob prohaska <fbsd at www.zefox.net> wrote:

> On Fri, May 22, 2020 at 10:51:32PM -0700, Mark Millard wrote:
>>=20
>> They implicitly suggest that fbbpp needs to be set to 32 (for the =
sparse 32 bit
>> framebuffer layout). You may want to try -fbbpp 32 on the command =
that starts
>> the server to find out if it proves dsufficient.
>>=20
>=20
> Apparently something more clever than=20
> X -fbbpp 32=20
> or
> startx -fbbpp 32=20
> is required. Neither seems to make a difference.=20
>=20
> Can the -fbbpp parameter be set in xorg.conf? Right now
> it contains:
> Section "Files"
> EndSection=20
> Section "Module"
>    Load        "dbe"
>    Disable    "dri"
>    Disable    "dri2"
>    Disable    "glx"
>    SubSection  "extmod"
>       Option  "omit xfree86-dga"
>    EndSubSection
> EndSection
>=20
>=20
> Section "ServerFlags"
>    Option    "AIGLX"        "false"
>    Option    "NoAccel"    "True"
>    Option    "NoDRI"        "True"
>    Option    "DRI"        "False"
>    Option    "DRI2"        "False"
> EndSection
>=20
>=20
> Section "InputDevice"
>    Identifier  "Keyboard1"
>    Driver      "kbd"
> EndSection
>=20
>=20
> Section "InputDevice"
>    Identifier  "Mouse1"
>    Driver      "mouse"
>    Option      "Protocol"      "auto"
>    Option      "Device"        "/dev/sysmouse"
> EndSection
>=20
>=20
> Section "Monitor"
>    Identifier  "Monitor"
> EndSection
>=20
>=20
> Section "Device"
>    Identifier  "Generic FB"
>    Driver      "scfb"
>    Option    "NoAccel"    "True"
> EndSection
>=20
>=20
> Section "Screen"
>    Identifier  "Screen"
>    Device      "Generic FB"
>    Monitor     "Monitor"
>    DefaultDepth 16
>    SubSection "Display"
>       Depth           16
>    EndSubsection
> EndSection
>=20
>=20
> Section "ServerLayout"
>    Identifier  "layout"
>    Screen      0 "Screen" 0 0
>    InputDevice "Mouse1" "CorePointer"
>    InputDevice "Keyboard1" "CoreKeyboard"
> EndSection

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]=20
Modified Sun Sep 8 09:47:21 2019 UTC (8 months, 2 weeks ago) by gonzo=20
File length: 7261 byte(s)=20
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.


Even Raspbian has the fbbpp 24 issue:

https://github.com/raspberrypi/firmware/issues/1338


=3D=3D=3D
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?17328C3E-730A-4199-899F-01D3D8060BC1>