Troubleshooting:display

= 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. You can also try this: Display_manager.

Changing the panning
Some devices might have a framebuffer virtual size that's 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.

LightDM no longer starts Xorg on device without GPU driver
Set  in.

See also: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/3827, https://github.com/canonical/lightdm/commit/77a7c6b7b8ca896b98ef43826641bdd520650bfb

= Generic troubleshooting (any manufacturer) =

Screen does not refresh
Symptoms 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:

If it does, add  to the   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  anyway.)

Colors are wrong in some way
Different framebuffer modes exist where the order of colors and transparency differ. Typically you have R (red) G (green) B (blue) and A (transparency), and they might be supplied as RGBA, BGRA, ARGB or another variant. If the order is wrong you can have different issues:


 * Everything is red-ish: example
 * Blue and red are swapped: example
 * Screen appears to show nothing (observed by switching from RGBA (which is correct) to ARGB)

To try to find a fix you need to locate the place(s) where the order is defined or set, somewhere in drivers/video. If the suggested patches in the subsections below do not work for you then have a look in the Debugging the kernel driver-section.

Qualcomm MSM devices
On Qualcomm devices the correct file should be  or. Changing the mode can (hopefully) be done in one of the following ways:

imgType could also be  like with motorola-condor and probably some other MSM8210 devices

Alternative patch (requires  in the kernel config):

You might also need to add the mode, as done for linux-xiaomi-santoni:

Another possible workaround might be setting the default color depth to 16 bits per pixel (see this comment).

Exynos devices
On newer exynos devices you typically need to edit a file in.

To fix the problem where red and blue were swapped for dreamlte (exynos8895) the following patch worked:

How this patch was found is described in the Debugging the kernel driver-section.

= 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  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  in the   file.

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

See example patch: 06_fix_mdss_fb_rgb_mode.patch

Screen is blank outside of Weston
Something like that should help, see #603:

= Debugging the kernel driver =

Generally to understand what happens in the kernel you want to print messages to dmesg with information like error codes or the value of some variable.

The quickest way to try different kernel patches is to obtain the kernel source ( or download a source tar archive), add debug messages, build the kernel with envkernel.sh and then flash it. The whole build and flash procedure is described in Compiling kernels with envkernel.sh. Compiling and flashing only the kernel is faster than compiling and re-installing the kernel and rootfs everytime, which is done when you run.

To add debug messages you need to find interesting places where to add those though. If you have a display issue then  should be where to look.

Example: error in Xorg.0.log
In the screen just showed noise, and /var/log/Xorg.0.log contained lots of these errors:. It was desired to get more information about the error (what exactly is the invalid argument?).

ing for FBIOPUTCMAP in the kernel source showed that the error comes from drivers/video/fbmem.c, and so some suitable debug messages could be:

Example: red and blue colors are swapped
In red and blue were switched on the display. As described in Colors are wrong in some way this most likely meant that that the framebuffer mode had to be changed somewhere. ing for,   and   in drivers/video/ showed quite a lot of places to investigate. Since this was on an exynos device files in  seemed especially interesting.

Since for many Qualcomm devices it was possible to simply change the mode from BGRA to RGBA or vice-versa, the first thing tried was this patch:

After compiling, flashing and booting the kernel, the colors were still wrong, and none of the messages showed up in dmesg, so this not the right places to set the mode. Next focus was therefore on the grep results of  in. was being set in,   and   so this patch was added:

After compiling, flashing and booting the kernel only the message from  appeared in dmesg, and bits_per_pixel was 32.

In the same file we have

Each pixel is 32 bit, and they are unpacked in the order BGRA, since blue.offset=0, green.offset=8, red.offset=16 and transp.offset=24. Since we want to swap blue<->red we change those offsets:

And after compiling, flashing and booting the kernel the problem is solved!

= See also =


 * : framebuffer: red and blue are swapped on devices using MSM8974
 * : alternative patch to fix refresh rate for kernel 3.4.113 android_kernel_oppo_msm8974 and similar
 * : red and blue are swapped on dreamlte (exynos8895)
 * Kernel documentation on the framebuffer api
 * Red screen issue on HTC-One XL