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

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

[p.kosyh]

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?

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

[hiro]

> /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?
>
>
>
>

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

[p.kosyh]

Quoth hiro <23hiro@gmail.com>:

> 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...

Nice idea.  Thanks!  Yes, you are right.  I see artefacts in
fullscreen view on linux too.  So, will try another hdmi cable or will
not pay attention to it.

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

I have 1920x1080, but glitches are not so noticeable.

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

[ori]

Quoth p.kosyh@gmail.com:
> 
> Golang does not support plan9/arm64 target.  Because arm64 is
> 9front only :) Is anyone working on it or it is too hard to implement?

Nobody is working on it (as far as I know). It is
likely relatively easy to implement.

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

[hiro]

i have 4k working at 60hz, and without artifacts. should be much
easier for you to find a working hdmi cable.
unless something is just broken in the pi or your display...

On 2/27/21, p.kosyh@gmail.com <p.kosyh@gmail.com> wrote:
> Quoth hiro <23hiro@gmail.com>:
>
>> 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...
>
> Nice idea.  Thanks!  Yes, you are right.  I see artefacts in
> fullscreen view on linux too.  So, will try another hdmi cable or will
> not pay attention to it.
>
>> i have seen crazy shit like that at 4k over shitty hdmi cables. it was
>> subtle.
>
> I have 1920x1080, but glitches are not so noticeable.
>
>
>