Jump to content

Display/Troubleshooting

From postmarketOS Wiki
Revision as of 08:55, 31 December 2020 by Grimler (talk | contribs) (Point links to gitlab instead of github where possible)

Generic debugging steps

Look at ~/.xsession-errors and ~/.xsession-errors.old

When lightDM starts your session, it redirects its output in that file. Including if that's a Wayland session!

If both files are empty, you can expect your graphical interface to have started without error. If they aren't created, lightDM may not have been started successfully.

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

Generic troubleshooting (any manufacturer)

Screen does not refresh

Symtoms of this problem may, for instance, be that the desktop environment starts and is displayed with initial content, but is frozen at that moment and never updates. At first it may seem to be a touchscreen problem, but the lack of automatic changes (e.g. clock showing current time) can point of frozen display instead.

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. Despite the name, the tool is not specific to MSM at all.

(If the above command does not refresh your screen, you could try the msm-fb-refresher anyway.)

Note Make sure you zap the device rootfs after enabling the msm refresher, otherwise it will only get installed as a service and not enabled by the postmarketos-base install script (you'll only see a second of splash-screen otherwise and the refresher won't be restarted after exiting the initramfs

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.

CONFIG_MSM_KGSL=n

-> Device Drivers
    -> Graphics support
        -> MSM 3D Graphics driver

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 mdp3_ctrl.c file.

See example patch: [1]

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 /sys/class/graphics/fb0/bits_per_pixel.

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

See also

  • pmaports#211 framebuffer: red and blue are swapped on devices using MSM8974 (resolved)

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

Some programs (e.g. Chromium, GIMP,..) has very messed up colors!

If some of the programs looks like this, then your framebuffer color depth is wrong.

The application probably is showing RGB on a BGR color depth, a patch like this could fix it.

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.

See also

  • pmaports#211: framebuffer: red and blue are swapped on devices using MSM8974
  • pmaports#297: Alternative patch to fix refresh rate for kernel 3.4.113 android_kernel_oppo_msm8974 and similar