Project

General

Profile

Actions

Action Item #1037

closed

Investigate psplash-drm as replacement for psplash

Added by Hammel 7 months ago. Updated 7 months ago.

Status:
Closed
Priority:
Immediate
Assignee:
Target version:
Start date:
15 Sep 2023
Due date:
% Done:

100%

Estimated time:
Severity:
02 - High

Description

psplash has problems working with the vc4/v3d overlays, but those are required to identify some display hardware.

There is a possible alternative to this in psplash-drm.

Investigate it's use as a replacement for the original psplash.

If this works then the code that strips out the overlay from the board file in etc/init/functions can be removed (but it must be left in the lcdshow postinst until a fix for display size calculations is found).

References
  1. https://github.com/r1mikey/psplash-drm
  2. https://community.st.com/t5/stm32-mpus-products/modify-kernel-splash-screen-image-psplash-drm/td-p/72473
Actions #1

Updated by Hammel 7 months ago

  • Description updated (diff)
Actions #2

Updated by Hammel 7 months ago

  • Description updated (diff)
Actions #3

Updated by Hammel 7 months ago

  • Severity changed from 03 - Medium to 02 - High
Actions #4

Updated by Hammel 7 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 30

Port was simple enough and it works well enough on the Elecrow 5", where it wasn't working previously. However, I had to move init scripts around a bit. I played with it so much I'm not even sure which ones I moved. So I'll need to start again.

I believe that putting udev in front of psplash is the trick, and that's all that might need to be done. The one drawback is that the init scripts start so fast now that by the time psplash is displayed we're already waiting on network startup, about 1/2 through init processing. So psplash looks like it starts half way through. I thought this might be because the drm driver isn't loaded fast enough.

I'm wondering if I revert to the old psplash and move udev, does that work and do we get psplash displayed earlier?

Actions #5

Updated by Hammel 7 months ago

Moving udev startup before psplash startup works with the original psplash (re: not the drm psplash).

But like the last test, psplash looks like it starts half way through the init process. It's likely because the frame buffer is not ready.

Moving mdev startup in front of psplash did not help.

Logging the bumps shows that all bumps are logged for each init script as they should be. So the problem is likely that the display simply isn't enabled fast enough. I should try to load the drivers in the initramfs. Or compile them into the kernel itself.

Actions #6

Updated by Hammel 7 months ago

  • % Done changed from 30 to 60

Moving udev from S09 to S00 allows psplash to work, but also allows text to show up on the display before psplash and between psplash exiting an X.org starting. This is true on the known EDID displays as well as unknown EDID displays (wrt optimizeDisplay() in functions).

I can fix this by adding a chvt to the init scripts but that doesn't completely clear it between psplash and X.org - nearly, but there is a flash of text displayed. The flash of text is visible on any system where I move udev, which means those systems that used to work properly won't anymore.

I'm thinking this isn't worth fixing that way. I can simply install psplash's init script after udev on select systems, via the postinst script, and enable the chvt commands (which would be new but disabled by default) in the init script too. Then everything else stays the same. Much simpler. Also, I tried this on the Elecrow 5" and psplash behaved much better anyway (status bar didn't start half way through).

I should note that migrating to psplash-drm is not necessary for these changes.

Actions #7

Updated by Hammel 7 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 60 to 100

This works for the GeeekPi display (which is also an Elecrow) but does not work as well on the Elecrow. On the latter the status bar still starts 1/2 way through.

But that's good enough.

It also works on a standard HDMI display. So this is good enough for this issue.

Code tested on hardware, committed and pushed.
Closing issue.

Actions

Also available in: Atom PDF