Hi,
On 22.03.24 16:06, Huacai Chen wrote:
On Thu, Mar 21, 2024 at 4:55 AM Jaak Ristioja <jaak@xxxxxxxxxxx> wrote:
Hi Huacai,
On 19.03.24 16:16, Huacai Chen wrote:
Hi, Jaak,
On Mon, Mar 18, 2024 at 11:42 PM Jaak Ristioja <jaak@xxxxxxxxxxx> wrote:
Hi Huacai,
Uh, no, sorry, I did not get to test such changes. From what Thomas
wrote I presumed that this got fixed and no further action would be
required.
To speed things up I would appreciate it if you provided a patch. As I
worked around the problem for the end user by changing the kernel
configuration, I have long forgotten the exact details. It would
otherwise probably take me a while to understand what and where you
propose to change exactly.
Also, do you want me to test it on some newer kernel or should I
re-download the 6.5.# version sources?
Yes, it is better to use 6.5, you can simply change the last line of
drivers/firmware/sysfb.c to fs_initcall(sysfb_init), So no patch
needed.
And to Thomas,
I'm sorry that reverting 60aebc95594 solve Jaak's problem, but my
original problem exist (at least in 6.5), and I want to know the
result of the above experiment to understand what happens.
Using the sources for 6.5.9 and fs_initcall(sysfb_init) instead of
subsys_initcall_sync(sysfb_init) in drivers/firmware/sysfb.c did not
help. The screen still went black during the boot and stayed black until
SDDM started.
OK, then can you try rootfs_initcall(sysfb_init)?
Unfortunately, this did not help, I still get the black screen until
SDDM starts.
Jaak
