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)? Huacai > > Jaak
