Re: [9front] rpi4 RGB24 vs BGR24, glitches and golang status

[hiro <23hiro@gmail.com>]

> /dev/screen does not contain those data.
then i think it's not our doing. probably nothing we can do about it... :(
are you using high resolutions, 4k?

try to save /dev/screen via topng, and display it in fullscreen on
both 9front and linux to make sure it's not just those combination of
pixels at those exact positions...

i have seen crazy shit like that at 4k over shitty hdmi cables. it was subtle.

try to also change refresh rate. if that changes the effect it's even
more sure that it's not our fault.
the lower the pixel clock the less we are affected by noise on the HDMI cable.

On 2/27/21, p.kosyh@gmail.com <p.kosyh@gmail.com> wrote:
> Hello!  I finally bought rpi4 4Gb specially for 9front. It seems,
> that default bpp of framebuffer is 16.  I changed it to 24 (via
> cmdline.txt and config.txt) and found, that rendering is much faster!
> (May be due removing overheads in 16->24 conversions?)
>
> But on rpi4 r and b channels are swapped.  So, i changed BGR24 to
> RGB24 in bcm/screen.c and now it works fine!  I am not sure, if this
> patch will work on rpi3/2/1, so i just wrote this message if it will useful
> for someone.
>
> The next problem.  Sometimes i see strange artefacts on screen.  If i
> run acme with lot of text i see pale character places (like vertical
> bars) in other parts of the screen.  /dev/screen does not contain
> those data.  I checked hdmi cable and monitor with Linux.  No problem.
> Can it be something with alpha blending calculations or something like
> this?  Is there an experiment i could do?  Btw i remember that i saw
> such artefacts in 9front running in amd64 qemu on AMD (non Intel)
> host.
>
> Golang does not support plan9/arm64 target.  Because arm64 is
> 9front only :) Is anyone working on it or it is too hard to implement?
>
>
>
>