- 1 Generic debugging steps
- 2 Qualcomm framebuffer (mdss, mdp3)
- 3 See also
Generic debugging steps
Changing the panning
Some devices might have a framebuffer virtual size thats twice as big as the panel resolution, this is a common double buffering method. The application renders to one side of the display while the panning is set to the other side. You can try changing the panning with the `panning` file in the sysfs directory.
$ cat /sys/class/graphics/fb0/virtual_size todo: add file contents here $ cat /sys/class/graphics/fb0/pan todo: add file contents here $ echo 0 0 > /sys/class/graphics/fb0/pan
Qualcomm framebuffer (mdss, mdp3)
MSM framebuffer doesn't work
We found out that removing the 3D driver support makes the MSM framebuffer work. See #66.
On devices using the mdss_fb driver, adding
mdss-fb-init-hack to the dependencies of the device package (example) might help.
Screen output flicker and inactivity
If you notice a very brief flicker upon boot, but immediately disappears and screen turns black, you might have a buggy framebuffer Qualcomm MDSS MDP3 driver.
You can try patching the source code by removing the function assigned to the
mdp3_interface->off_fnc in the
See example patch: 05_fix_mdp3_ctrl_off.patch
Screen output messed up
If the output on the screen is not aligned correctly (see picture) it's probably because you have a wrong value in
You can try patching the source code by setting a different video mode (RGB/ARGB/RGBA/YCRYCB/...).
This may also help, when your X11 is segfaulting (see #779).
See example patch: 06_fix_mdss_fb_rgb_mode.patch
My screen is red!
Patch your kernel to report the right framebuffer information, for example with the following patch. If you have successfully patched your kernel that way, please edit this page and link to the merge request below (so we get a few more examples).
diff --git a/drivers/video/msm/mdss/mdss_fb.c b/drivers/video/msm/mdss/mdss_fb.c index 53112ca6..69673017 100644 --- a/drivers/video/msm/mdss/mdss_fb.c +++ b/drivers/video/msm/mdss/mdss_fb.c @@ -569,7 +569,7 @@ static int mdss_fb_probe(struct platform_device *pdev) mfd->bl_level = 0; mfd->bl_scale = 1024; mfd->bl_min_lvl = 30; - mfd->fb_imgType = MDP_RGBA_8888; + mfd->fb_imgType = MDP_RGB_888; mfd->pdev = pdev; if (pdata->next)
Alternative patch: 0001-fix-video-argb-setting.patch (requires
CONFIG_FB_MSM_DEFAULT_DEPTH_ARGB8888=y in the kernel config).
A workaround might be setting the default color depth to 16 bits per pixel (see this comment).
- pmaports#211 framebuffer: red and blue are swapped on devices using MSM8974 (resolved)
Screen doesn't refresh
Check if your screen refreshes when you do the following:
$ cat /sys/class/graphics/fb0/modes > /sys/class/graphics/fb0/mode
If it does, add
msm-fb-refresher to the
depends= of your device-package. It will basically do the same automatically.
(If the above command does not refresh your screen, you could try the
Screen is blank outside of Weston
Something like that should help, see #603:
$ echo 0 > /sys/class/graphics/fb0/blank $ echo 1 > /sys/devices/fd900000.qcom,mdss_mdp/qcom,mdss_fb_primary.134/leds/lcd-backlight/brightness
Debugging the kernel driver
If you have some time to spend on getting your video driver working right, consider adding
printk statements in your kernel to understand what it does and where it fails. After building your kernel and flashing, check
dmesg for your debug output. See #1618 (comment) for a detailed example.
- pmaports#211: framebuffer: red and blue are swapped on devices using MSM8974