RPi4 Status and xorg behavior

[Klaus Küchemann]

> Am 08.03.2021 um 09:14 schrieb Mark Millard via freebsd-arm <freebsd-arm at freebsd.org>:
> You may want to be explicit about the build version
involved (last commit involved on what branch).

 it would also help to be explicit about the firmware-version.
I would suggest to base tests on - 1.20210303. - , as it should then be the
latest in the next build , IIRC.

> 8.03.2021 um 09:14 schrieb Mark Millard via freebsd-arm <freebsd-arm at freebsd.org>:
> EFI framebuffer information:
> addr, size     0x3e2fe000, 0x7e9000
> dimensions     1920 x 1080
> stride         1920
> masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000

Yes, frame buffer supports up to 1920 x 1080( so no 4k for now 
 because of missing vc4 graphics accelerator driver),
I didn`t recall problems with any window server in  X , so should work out of the box.
in short: no acceleration means nou seful  adjustment-options with tools because the resolution 
is scanned at boot-time by fb-driver. So: it HAS TO work out of the box.

> On 2021-Mar-7, at 17:10, bob prohaska <fbsd at www.zefox.net> wrote:
> Boot seems to stall until enter is hit at a couple of points, thefirst I think was after displaying EFI console

Since you’re the 2nd person who reports this, seems to be a known (new) bug now , 
belongs to u-boot(&perhaps firmware) :
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253981#c29
If the attachment in comment 29 doesn’t help:
it`s a firmware problem(provided there were no major related changes in src).
So we have to know the exact release &fw- version to fix this.

> Am 08.03.2021 um 09:14 schrieb Mark Millard via freebsd-arm <freebsd-arm at freebsd.org>:
> but the context is a 2560 x 1440 display 

thanks for laboriously dragging your TV around the house in order to fix the Geekworm bug,
Ha Ha :-)

K.