What are the effect of parameters in /sys/class/graphics/fb0/ ?

jdmulloy

New member
On our CFA 910 the script that runs the demo slideshow changes some parameters in /sys/class/graphics/fb0. Can anyone explain what these parameters do? What sort of effect do they have on the eInk display? What are valid values?

Also is there any way to get the screen to flash black then white? I'm writing an application in GTK using Cairo and it looks pretty good but there is some slight ghosting. I also see an outline of the charachters before they are filled in, but I might be able to find a way to fix that with GTK. I thought my code wasn't repainting the screen mulitple times, but it looks like it might be.

This is the contens of slideshow.sh
Code:
echo 0 >> /sys/class/graphics/fb0/update_mode
echo 100 >> /sys/class/graphics/fb0/defio_delay
eog -s /home/root/slides
echo 1 >> /sys/class/graphics/fb0/update_mode
echo 25 >> /sys/class/graphics/fb0/defio_delay
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 

CF Mark

Administrator
Unfortunately the only person that can answer this (CF_rje) is currently on holiday.
He will reply in here as soon as he is able to do so, but it may be some time :(
 

jdmulloy

New member
Unfortunately the only person that can answer this (CF_rje) is currently on holiday.
He will reply in here as soon as he is able to do so, but it may be some time :(
It's not terribly urgent as the display is working pretty well for us at the moment. We have to present our project on April 15th but this isn't blocking us in any way.
 

CF Support

Administrator
This gets into the intricacies of E Ink displays, the Linux frame buffer, and X Windows. I will try to explain the interactions. Their interactions are written into /drivers/video/broadsheetfb.c.

The E Ink display has different waveforms and update modes. The waveforms detail how the screen is changed and the update mode defines the part of the screen that is changed.

Code:
echo 0 >> /sys/class/graphics/fb0/update_mode
That changes the update mode to full updates. This means that the whole screen will be changed on every update. Using a 1 enables a partial update that will only change the part of screen that needs modifying. Partial updates are better for small changes across the screen, where a full update is best for large updates. A partial update will incur more ghosting.
Code:
echo 100 >> /sys/class/graphics/fb0/defio_delay
This frame buffer has a deferred i/o feature. This is useful for a slow changing display like the E Ink so that multiple changes can be batched. This will cause the screen to be changed less often and batch up many updates. While running a slideshow with full updates, this will make the screen flash less as the slideshow and X Windows passes various changes to the frame buffer.

That script sets parameters into the framebuffer that optimize the framebuffer for a slideshow, runs the slideshow, and then puts back the original values.

The way the screen flashes is defined by the waveforms. The waveforms are provided by the panel manufacturer and interpreted by the Broadsheet controller. There is no user way to change the flash pattern. There are 4 waveform modes for the panels we have: init, black-white direct update, grayscale/clear update (3 bit), and grayscale/clear update (4 bit). Other panels have different modes such as the older panels where they replace the 4 bit mode with a grayscale update that doesn't have a clear (this may sound nice but has increased ghosting.) You can play with the modes for your needs using the runtime settings in the sysfs. You have seen the settings that we use with one set, best for general operations and the other for fullscreen updates with reduced ghosting.

I hope this helps you with your project.
 

jayakumar

New member
Hi CF_rje, jdmulloy,

Yup, that's right. The broadsheetfb.c that was pointed to exposes 2 types of update modes. UPD_PART (1) and UPD_FULL (0). UPD_PART is a partial update so only pixels that have actually changed in value will be driven to their new value. You'd use this if you're doing something where you're not that fussed about a bit of ghosting. UPD_FULL is a full update so it will update all pixels and minimizes ghosting.

defio_delay is the amount of time for which the driver permits deferring an update. So if you set it to 1s, it will deferr 1s after the initial change to the framebuffer before causing the display panel to update. So this lets it collect any changes that happened within that 1s.

Hope that helps,
jaya
 
Top