pik33
Posts: 167
Joined: Thu Sep 10, 2015 4:26 pm

A framebuffer test result on a Pi4: compatibility broken

Tue Jul 02, 2019 9:53 am

I tried this program.

https://github.com/rst-/raspberry-compo ... testXIVb.c

To do this, I switched the RPi4 to start without X.

The results:
- with fkms switched off the program works, but the picture flickers.
- with fkms switched on, the program cannot work. It prints the text "Error setting variable information' and then the RPi stops responding to anything but the power off.

Code: Select all

    vinfo.bits_per_pixel = 8;
    vinfo.xres = 960;
    vinfo.yres = 540;
    vinfo.xres_virtual = vinfo.xres;
    vinfo.yres_virtual = vinfo.yres * 2;
    if (ioctl(fbfd, FBIOPUT_VSCREENINFO, &vinfo)) {
      printf("Error setting variable information.\n");

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23052
Joined: Sat Jul 30, 2011 7:41 pm

Re: A framebuffer test result on a Pi4: compatibility broken

Tue Jul 02, 2019 10:22 am

The whole area of framebuffers has been completely revamped to support multiple displays and FKMS. Whilst we tried very hard to maintain backwards compatibility, it may not be possible in every case.

I'm not going to have the chance to look at this. Might be worth approaching the original author to see if s/he can help.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

pik33
Posts: 167
Joined: Thu Sep 10, 2015 4:26 pm

Re: A framebuffer test result on a Pi4: compatibility broken

Tue Jul 02, 2019 10:30 am

Update:

The flickering problem was solved by changing the order of two lines in the code:. Instead of this (which was good in earlier RPis)

Code: Select all

        ioctl(fbfd, FBIO_WAITFORVSYNC, &dummy);
        // would expect this order to work but tearing occurs...
        ioctl(fbfd, FBIOPAN_DISPLAY, &vinfo);
        
now we need this:

Code: Select all

        
                ioctl(fbfd, FBIOPAN_DISPLAY, &vinfo);
                ioctl(fbfd, FBIO_WAITFORVSYNC, &dummy);
        // would expect this order to work but tearing occurs...

        
The fkms driver has to be switched OFF or the programs hangs up trying to set the new framebuffer parameters.

This is good as I can go further with moving my old stuff to RPi4 as all I need is a working framebuffer with vsync :)

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23052
Joined: Sat Jul 30, 2011 7:41 pm

Re: A framebuffer test result on a Pi4: compatibility broken

Tue Jul 02, 2019 10:36 am

pik33 wrote:
Tue Jul 02, 2019 10:30 am
Update:

The flickering problem was solved by changing the order of two lines in the code:. Instead of this (which was good in earlier RPis)

Code: Select all

        ioctl(fbfd, FBIO_WAITFORVSYNC, &dummy);
        // would expect this order to work but tearing occurs...
        ioctl(fbfd, FBIOPAN_DISPLAY, &vinfo);
        
now we need this:

Code: Select all

        
                ioctl(fbfd, FBIOPAN_DISPLAY, &vinfo);
                ioctl(fbfd, FBIO_WAITFORVSYNC, &dummy);
        // would expect this order to work but tearing occurs...

        
The fkms driver has to be switched OFF or the programs hangs up trying to set the new framebuffer parameters.

This is good as I can go further with moving my old stuff to RPi4 as all I need is a working framebuffer with vsync :)
I suspect FKMS holds the framebuffer open exclusively bearing in mind it is the device that creates the framebuffer in the first place, the standard framebuffer code is not used.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

User avatar
Gavinmc42
Posts: 3407
Joined: Wed Aug 28, 2013 3:31 am

Re: A framebuffer test result on a Pi4: compatibility broken

Tue Jul 02, 2019 11:04 am

pik33, are you saying you got framebuffer working on baremetal on a Pi4?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

pik33
Posts: 167
Joined: Thu Sep 10, 2015 4:26 pm

Re: A framebuffer test result on a Pi4: compatibility broken

Tue Jul 02, 2019 11:29 am

No, I have it working on console linux (without X). Moving the basic code from C to Pascal now so the Retromachine project can work on RPi4. under Linux, until Ultibo can run on RPi4, which I expect no earlier than in the next year, because as far as I know the hardware differences are HUGE. New MMU, new DMA, new GPIO stuff, new VC...

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6995
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: A framebuffer test result on a Pi4: compatibility broken

Tue Jul 02, 2019 11:59 am

The core kernel DRM code emulates the legacy framebuffer calls and converts them into DRM plane operations. Yes, it would appear not to support FBIOPUT_VSCREENINFO - I'm not overly surprised by that as that would require changing display mode which is non-trivial as DRM can handle multiple planes per display, and how do those map across?
Your application is continuing on blindly after the error, and making changes to the current /dev/tty, so I'm not that surprised it does odd things.

DRM/KMS is the current mainline API for graphics composition. Generally they are very good at backwards compatibility, but I think in this case that is just not possible.


With regard vblanks, there has been a tweak to the display pipeline setup code. It'd be worth trying the rpi-update firmware to see if it helps in your case. Normal warnings about the potential for regression with rpi-update.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

pik33
Posts: 167
Joined: Thu Sep 10, 2015 4:26 pm

Re: A framebuffer test result on a Pi4: compatibility broken

Tue Jul 02, 2019 12:33 pm

"Your firmware is already up to date" :)

The framebuffer works, the problem is now worked around

Is it possible to have similar result (not flickering fb by switching two buffers in vblk) using the new driver even if the resolution can not be changed?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6995
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: A framebuffer test result on a Pi4: compatibility broken

Tue Jul 02, 2019 5:36 pm

I'm wrong, it looks like FBIOPUT_VSCREENINFO is supported (somehow), but 8bpp is not.
Your call is equivalent to

Code: Select all

fbset -g 960 540 960 1080 8
which doesn't work.

Code: Select all

fbset -g 960 540 960 1080 32
does.

Note that DRM emulates a framebuffer device within the underlying plane, so in my case it creates a 960x540 object in the top left of my 1080p screen.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6995
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: A framebuffer test result on a Pi4: compatibility broken

Tue Jul 02, 2019 5:39 pm

pik33 wrote:
Tue Jul 02, 2019 12:33 pm
"Your firmware is already up to date" :)

The framebuffer works, the problem is now worked around

Is it possible to have similar result (not flickering fb by switching two buffers in vblk) using the new driver even if the resolution can not be changed?
AFAIK the frame buffer is never double buffered. Look at libDRMif you want to double buffering and controlling planes. drm_mmal is doing a basic use case, but isn't waiting on vsyncs (just playing as fast as possible).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

pik33
Posts: 167
Joined: Thu Sep 10, 2015 4:26 pm

Re: A framebuffer test result on a Pi4: compatibility broken

Tue Jul 02, 2019 5:51 pm

The code I run simulates double buffering using FBIOPAN_DISPLAY. It declares a framebuffer 2x higher than physical one and displays one half of it, while drawing on another, giving tear-free display.

If it works, I will also try this on KMS driver using 32bpp,

---------------
Update: KMS driver doesn't allow to set vitrual size>physical size, so the old double height framebuffer trick doesn't work with it.

pik33
Posts: 167
Joined: Thu Sep 10, 2015 4:26 pm

Re: A framebuffer test result on a Pi4: compatibility broken

Wed Jul 17, 2019 4:20 pm

I did some experimenting with the code from here: http://betteros.org/tut/graphics1.php
It needs some changes (64->32) to work on RPi but then it works.

It seems that using new drivers and KMS it is possible to change a framebuffer resolution/framerate (I experimented with this). Then it is possible to declare a dumb buffer, and then set a CRTC at it with x,y !=0 (= old style PAN_DISPLAY)

User avatar
Gavinmc42
Posts: 3407
Joined: Wed Aug 28, 2013 3:31 am

Re: A framebuffer test result on a Pi4: compatibility broken

Thu Jul 18, 2019 11:46 am

Thanks pik33. nice link.
Finally some DRM stuff that I nearly understand.

Code: Select all

int dri_fd  = open("/dev/dri/card0",O_RDWR);
I see /dev/dri/card0 and card1, that's for the two HDMI outputs?
Please note that there is a lot of room for optimization in this code. On systems with SIMD instructions, such x86_64 (SSE, SSE2, SSE3, SSE4.1, etc..) multiple bytes of the buffer can be copied at once. Writing this routine in assembly language might be helpful.
Indeed ;)

Lots of good basic code examples, bookmarked.
No need for X11 :D
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

pik33
Posts: 167
Joined: Thu Sep 10, 2015 4:26 pm

Re: A framebuffer test result on a Pi4: compatibility broken

Thu Jul 18, 2019 3:49 pm

In RPi4 you have to use

int dri_fd = open("/dev/dri/card1",O_RDWR);

There is also x11 example there but I didn't get it to work on RPi4: I got a purple window, but the graphics data from the for-loop at the end doesn't appear in the window.

Return to “Graphics programming”