Recent Update Has Changed Framebuffer Parameters - Solved

[g8gkq]

I am using the official foundation touchscreen with an RPi 4 (2GB) and Raspios 32 bit Buster Lite 2020-05-27 and maintain a build on GitHub for an Amateur Television transmitter based on the RPi 4 and a LimeSDR https://github.com/davecrump/portsdown-a27. My initial build worked well, but a recent update (dist-upgrade) appears to have broken 2 things:

I grep dmesg to look for ft5406 to check that the 7 inch display is connected. This device no longer seems to exist. I can get round this.

The big problem is that I write directly to the framebuffer to display on the screen and all the parameters seem to have changed. This is what I do:

Code: Select all

int initScreen(void)
{
  struct fb_var_screeninfo vinfo;
  struct fb_fix_screeninfo finfo;
 
  fbfd = open("/dev/fb0", O_RDWR);
  if (!fbfd) 
  {
    printf("Error: cannot open framebuffer device.\n");
    return(0);
  }

  if (ioctl(fbfd, FBIOGET_FSCREENINFO, &finfo)) 
  {
    printf("Error reading fixed information.\n");
    return(0);
  }

  if (ioctl(fbfd, FBIOGET_VSCREENINFO, &vinfo)) 
  {
    printf("Error reading variable information.\n");
    return(0);
  }
  
  screenXsize=vinfo.xres;
  screenYsize=vinfo.yres;
  
  screenSize = finfo.smem_len;
  fbp = (char*)mmap(0, screenSize, PROT_READ | PROT_WRITE, MAP_SHARED, fbfd, 0);
                    
  if ((int)fbp == -1) 
  {
    return 0;
  }
  else 
  {
    return 1;
  }
}

Then based on this offset (fbp) I write to each pixel:

Code: Select all

void setPixel(int x, int y, int R, int G, int B)
{
  int p;  // Pixel Memory offset
  if ((x < 800) && (y < 480))
  {
    p=(x + screenXsize * y) * 4;

    memset(fbp + p, B, 1);         // Blue
    memset(fbp + p + 1, G, 1);     // Green
    memset(fbp + p + 2, R, 1);     // Red
    memset(fbp + p + 3, 0x80, 1);  // A
  }
  else
  {
    printf("Error: Trying to write pixel outside screen bounds.\n");
  }
}

Is there some new documentation of the structure of the framebuffer?

Thanks

Dave

[jamesh]

I am not sure how the FKMS emulated frame buffer works with that sort of access. But presumably you have always used FKMS, so I am not sure might have changed. There have been major upgrades to a large parts of the graphics stack on the move to 5.4, could be anywhere...

[g8gkq]

Thanks. Looks like I may have to use trial and error then.

I’ve only used FKMS on the RPi 4 because It does not support OpenVG, which I still use in the RPi 3 builds.

Dave

[6by9]

rpi_ft5406 was upstreamed and became raspberrypi-ts https://github.com/raspberrypi/linux/bl ... rrypi-ts.c

[g8gkq]

Thanks to @jamesh and @6by9 for the replies.

1. I have changed my reference to 'ft5406' to 'raspberrypi-ts' in the dmesg grep and that has solved the first problem.

2. The update changed the default framebuffer depth from 32 bit to 16 bit (found by running fbset). I was able to change it back to 32 bit by commenting out (both) 'dtoverlay=vc4-fkms-v3d' lines in /boot/config.txt, and now my direct pixel write works again. In due course I may modify the routine to work with 16 bit framebuffer depth, so that my application is compatible with the default configuration.

My final problem is off-topic, in that I can't get the Waveshare 3.5 inch touchscreen to work. One for another day and another topic!

Thanks again

Dave, G8GKQ

[techrep]

All, I can confirm Dave's experience and his method of resolving same. I was building HamClock (https://www.clearskyinstitute.com/ham/HamClock/) for the RPi model 4 and ran into this same issue.

I exchanged several emails with the dev who was helpful but unable to resolve. I've since reported back to him what was done to resolve the issue.

73,
Chris, KD6OUB

[trejan]

2. The update changed the default framebuffer depth from 32 bit to 16 bit (found by running fbset). I was able to change it back to 32 bit by commenting out (both) 'dtoverlay=vc4-fkms-v3d' lines in /boot/config.txt, and now my direct pixel write works again. In due course I may modify the routine to work with 16 bit framebuffer depth, so that my application is compatible with the default configuration.

Does adding framebuffer_depth=32 to the end of /boot/config.txt fix it?

My final problem is off-topic, in that I can't get the Waveshare 3.5 inch touchscreen to work. One for another day and another topic!

It was probably using fbtft_device which was removed in 5.4. The new 5.4 approved method is to have a DT overlay for it that configures fbtft. Try https://github.com/swkim01/waveshare-dtoverlays

[g8gkq]

Hi @trejan

No, adding framebuffer_depth=32 at the end of /boot/config.txt does not fix it without commenting out dtoverlay=vc4-fkms-v3d and then the framebuffer_depth command is not required.

It was an outdated DT overlay (dating from the days of Jessie) that was the problem with the Waveshare touchscreen. I replaced it with one from swkim01 and it sorted the problem.

Thanks!

Dave, G8GKQ

[6by9]

The frame buffer depth was updated by upstream as the buffer otherwise became wasted memory once the DRM/KMS driver took over, so wasting 50% of the memory by using RGB565 instead of RGBX8888 was seen as a good thing.

Now the only thing I can't recall is where that change was! I would have thought device tree, but I don't immediately see it there.

[g8gkq]

Thanks @6by9. So for future compatibility (assuming that I'm going to continue writing to the framebuffer for my graphics) would you recommend that I amend my code to write RGB565 instead of changing the framebuffer depth and writing RGBX8888?

Dave