drm_log is a simple logger that uses the drm_client API to print the kmsg boot log on the screen.
This is not a full replacement to fbcon, as it will only print the kmsg.
It will never handle user input, or a terminal because this is better done in userspace.

If you're curious on how it looks like, I've put a small demo here:
https://people.redhat.com/jfalempe/drm_log/drm_log_draft_boot_v2.mp4

Design decisions:
  * It uses the drm_client API, so it should work on all drm drivers from the start.
  * It doesn't scroll the message, that way it doesn't need to redraw the whole screen for each new message.
    It also means it doesn't have to keep drawn messages in memory, to redraw them when scrolling.
  * It uses the new non-blocking console API, so it should work well with PREEMPT_RT
 
v2:
 * Use vmap_local() api, with that change, I've tested it successfully on simpledrm, virtio-gpu, amdgpu, and nouveau.
 * Stop drawing when the drm_master is taken. This avoid wasting CPU cycle if the buffer is not visible.
 * Use deferred probe. Only do the probe the first time there is a log to draw. With this, if you boot with quiet, drm_log won't do any modeset.
 * Add color support for the timestamp prefix, like what dmesg does.
 * Add build dependency on  disabling the fbdev emulation, as they are both drm_client, and there is no way to choose which one gets the focus.

v3:
 * Remove the work thread and circular buffer, and use the new write_thread() console API.
 * Register a console for each drm driver.

v4:
 * Can be built as a module, even if that's not really useful.
 * Rebased on top of "drm: Introduce DRM client library" series from Thomas Zimmermann.
 * Add a Kconfig menu to choose between drm client.
 * Add suspend/resume callbacks.
 * Add integer scaling support.
 
v5:
 * Build drm_log in drm_client_lib module, to avoid circular dependency.
 * Export drm_draw symbols, so they can be used if drm_client_lib is built as module.
 * Change scale parameter to unsigned int (Jani Nikula)

v6:
 * Use console_stop() and console_start() in the suspend/resume callback (Petr Mladek).
 * rebase and solve conflict with "drm/panic: Add ABGR2101010 support"

v7:
 * Add a patch fix a build issue due to missing DRM_CLIENT_LIB, reported by kernel test bot.

v8:
 * Rebased after drm client moved to drivers/gpu/drm/clients/
 * Rename DRM_LOG to DRM_CLIENT_LOG (Thomas Zimmermann)
 * Drop "Always select DRM_CLIENT_LIB", and select only if DRM_CLIENT_LOG is set
 * Add an info message if no clients are initialized in drm_client_setup()

v9:
 * Rename drm_draw.h to drm_draw_internal.h (Jani Nikula)
 * Add cflags to remove the "../" when including drm internal headers (Jani Nikula)
 * Order select alphabetically in KConfig (Thomas Zimmermann)
 * Replace drm_info with drm_dbg, to be less verbose (Thomas Zimmermann)
 * Rename module parameter to drm_client_lib.active (Thomas Zimmermann)
 * Warn if drm_client_lib.active is malformated (Thomas Zimmermann)
 
Jocelyn Falempe (6):
  drm/panic: Move drawing functions to drm_draw
  drm/log: Introduce a new boot logger to draw the kmsg on the screen
  drm/log: Do not draw if drm_master is taken
  drm/log: Color the timestamp, to improve readability
  drm/log: Implement suspend/resume
  drm/log: Add integer scaling support

 drivers/gpu/drm/Kconfig                       |   5 +
 drivers/gpu/drm/Makefile                      |   1 +
 drivers/gpu/drm/clients/Kconfig               |  48 ++
 drivers/gpu/drm/clients/Makefile              |   3 +
 drivers/gpu/drm/clients/drm_client_internal.h |   6 +
 drivers/gpu/drm/clients/drm_client_setup.c    |  29 +-
 drivers/gpu/drm/clients/drm_log.c             | 420 ++++++++++++++++++
 drivers/gpu/drm/drm_draw.c                    | 233 ++++++++++
 drivers/gpu/drm/drm_draw_internal.h           |  56 +++
 drivers/gpu/drm/drm_panic.c                   | 257 +----------
 10 files changed, 820 insertions(+), 238 deletions(-)
 create mode 100644 drivers/gpu/drm/clients/drm_log.c
 create mode 100644 drivers/gpu/drm/drm_draw.c
 create mode 100644 drivers/gpu/drm/drm_draw_internal.h


base-commit: c6eabbab359c156669e10d5dec3e71e80ff09bd2
-- 
2.47.1

On 04/12/2024 16:44, Jocelyn Falempe wrote:
> drm_log is a simple logger that uses the drm_client API to print the kmsg boot log on the screen.
> This is not a full replacement to fbcon, as it will only print the kmsg.
> It will never handle user input, or a terminal because this is better done in userspace.
> 
> If you're curious on how it looks like, I've put a small demo here:
> https://people.redhat.com/jfalempe/drm_log/drm_log_draft_boot_v2.mp4

I just pushed it to drm-misc-next.

Thanks all for your reviews and comments.

Best regards,

-- 

Jocelyn
> 
> Design decisions:
>    * It uses the drm_client API, so it should work on all drm drivers from the start.
>    * It doesn't scroll the message, that way it doesn't need to redraw the whole screen for each new message.
>      It also means it doesn't have to keep drawn messages in memory, to redraw them when scrolling.
>    * It uses the new non-blocking console API, so it should work well with PREEMPT_RT
>   
> v2:
>   * Use vmap_local() api, with that change, I've tested it successfully on simpledrm, virtio-gpu, amdgpu, and nouveau.
>   * Stop drawing when the drm_master is taken. This avoid wasting CPU cycle if the buffer is not visible.
>   * Use deferred probe. Only do the probe the first time there is a log to draw. With this, if you boot with quiet, drm_log won't do any modeset.
>   * Add color support for the timestamp prefix, like what dmesg does.
>   * Add build dependency on  disabling the fbdev emulation, as they are both drm_client, and there is no way to choose which one gets the focus.
> 
> v3:
>   * Remove the work thread and circular buffer, and use the new write_thread() console API.
>   * Register a console for each drm driver.
> 
> v4:
>   * Can be built as a module, even if that's not really useful.
>   * Rebased on top of "drm: Introduce DRM client library" series from Thomas Zimmermann.
>   * Add a Kconfig menu to choose between drm client.
>   * Add suspend/resume callbacks.
>   * Add integer scaling support.
>   
> v5:
>   * Build drm_log in drm_client_lib module, to avoid circular dependency.
>   * Export drm_draw symbols, so they can be used if drm_client_lib is built as module.
>   * Change scale parameter to unsigned int (Jani Nikula)
> 
> v6:
>   * Use console_stop() and console_start() in the suspend/resume callback (Petr Mladek).
>   * rebase and solve conflict with "drm/panic: Add ABGR2101010 support"
> 
> v7:
>   * Add a patch fix a build issue due to missing DRM_CLIENT_LIB, reported by kernel test bot.
> 
> v8:
>   * Rebased after drm client moved to drivers/gpu/drm/clients/
>   * Rename DRM_LOG to DRM_CLIENT_LOG (Thomas Zimmermann)
>   * Drop "Always select DRM_CLIENT_LIB", and select only if DRM_CLIENT_LOG is set
>   * Add an info message if no clients are initialized in drm_client_setup()
> 
> v9:
>   * Rename drm_draw.h to drm_draw_internal.h (Jani Nikula)
>   * Add cflags to remove the "../" when including drm internal headers (Jani Nikula)
>   * Order select alphabetically in KConfig (Thomas Zimmermann)
>   * Replace drm_info with drm_dbg, to be less verbose (Thomas Zimmermann)
>   * Rename module parameter to drm_client_lib.active (Thomas Zimmermann)
>   * Warn if drm_client_lib.active is malformated (Thomas Zimmermann)
>   
> Jocelyn Falempe (6):
>    drm/panic: Move drawing functions to drm_draw
>    drm/log: Introduce a new boot logger to draw the kmsg on the screen
>    drm/log: Do not draw if drm_master is taken
>    drm/log: Color the timestamp, to improve readability
>    drm/log: Implement suspend/resume
>    drm/log: Add integer scaling support
> 
>   drivers/gpu/drm/Kconfig                       |   5 +
>   drivers/gpu/drm/Makefile                      |   1 +
>   drivers/gpu/drm/clients/Kconfig               |  48 ++
>   drivers/gpu/drm/clients/Makefile              |   3 +
>   drivers/gpu/drm/clients/drm_client_internal.h |   6 +
>   drivers/gpu/drm/clients/drm_client_setup.c    |  29 +-
>   drivers/gpu/drm/clients/drm_log.c             | 420 ++++++++++++++++++
>   drivers/gpu/drm/drm_draw.c                    | 233 ++++++++++
>   drivers/gpu/drm/drm_draw_internal.h           |  56 +++
>   drivers/gpu/drm/drm_panic.c                   | 257 +----------
>   10 files changed, 820 insertions(+), 238 deletions(-)
>   create mode 100644 drivers/gpu/drm/clients/drm_log.c
>   create mode 100644 drivers/gpu/drm/drm_draw.c
>   create mode 100644 drivers/gpu/drm/drm_draw_internal.h
> 
> 
> base-commit: c6eabbab359c156669e10d5dec3e71e80ff09bd2

Hi Jocelyn,

On Wed, Dec 4, 2024 at 6:41 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> drm_log is a simple logger that uses the drm_client API to print the kmsg boot log on the screen.
> This is not a full replacement to fbcon, as it will only print the kmsg.
> It will never handle user input, or a terminal because this is better done in userspace.
>
> If you're curious on how it looks like, I've put a small demo here:
> https://people.redhat.com/jfalempe/drm_log/drm_log_draft_boot_v2.mp4
>
> Design decisions:
>   * It uses the drm_client API, so it should work on all drm drivers from the start.
>   * It doesn't scroll the message, that way it doesn't need to redraw the whole screen for each new message.
>     It also means it doesn't have to keep drawn messages in memory, to redraw them when scrolling.
>   * It uses the new non-blocking console API, so it should work well with PREEMPT_RT

I gave this a try on Koelsch (R-Car M2-W), using rcar-du.
Unfortunately I don't see any kernel messages, and my monitor complains
about no signal. Does this require special support from the driver?

    CONFIG_DRM_CLIENT=y
    CONFIG_DRM_CLIENT_LIB=y
    CONFIG_DRM_CLIENT_SELECTION=y
    CONFIG_DRM_CLIENT_SETUP=y
    CONFIG_DRM_CLIENT_LOG=y
    # CONFIG_DRM_CLIENT_DEFAULT_FBDEV is not set
    CONFIG_DRM_CLIENT_DEFAULT_LOG=y
    CONFIG_DRM_CLIENT_DEFAULT="log"

Switching to fbdev gives a working display, as before:

    CONFIG_DRM_CLIENT_DEFAULT_FBDEV=y
    # CONFIG_DRM_CLIENT_DEFAULT_LOG is not set
    CONFIG_DRM_CLIENT_DEFAULT="fbdev"

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On 17/12/2024 15:19, Geert Uytterhoeven wrote:
> Hi Jocelyn,
> 
> On Wed, Dec 4, 2024 at 6:41 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
>> drm_log is a simple logger that uses the drm_client API to print the kmsg boot log on the screen.
>> This is not a full replacement to fbcon, as it will only print the kmsg.
>> It will never handle user input, or a terminal because this is better done in userspace.
>>
>> If you're curious on how it looks like, I've put a small demo here:
>> https://people.redhat.com/jfalempe/drm_log/drm_log_draft_boot_v2.mp4
>>
>> Design decisions:
>>    * It uses the drm_client API, so it should work on all drm drivers from the start.
>>    * It doesn't scroll the message, that way it doesn't need to redraw the whole screen for each new message.
>>      It also means it doesn't have to keep drawn messages in memory, to redraw them when scrolling.
>>    * It uses the new non-blocking console API, so it should work well with PREEMPT_RT
> 
> I gave this a try on Koelsch (R-Car M2-W), using rcar-du.
> Unfortunately I don't see any kernel messages, and my monitor complains
> about no signal. Does this require special support from the driver?

It doesn't require a special support from the driver. But as it is the 
first drm client other than fbdev emulation, I'm not surprised it's 
broken on some driver.
I know it works on virtio-gpu, nouveau, amdgpu, and even on a OnePlus 6 
(Qualcomm SDM845/freedreno), without requiring driver changes.

Do you have a serial console on this device, to check if there is 
something in kmsg?

Best regards,

-- 

Jocelyn

> 
>      CONFIG_DRM_CLIENT=y
>      CONFIG_DRM_CLIENT_LIB=y
>      CONFIG_DRM_CLIENT_SELECTION=y
>      CONFIG_DRM_CLIENT_SETUP=y
>      CONFIG_DRM_CLIENT_LOG=y
>      # CONFIG_DRM_CLIENT_DEFAULT_FBDEV is not set
>      CONFIG_DRM_CLIENT_DEFAULT_LOG=y
>      CONFIG_DRM_CLIENT_DEFAULT="log"
> 
> Switching to fbdev gives a working display, as before:
> 
>      CONFIG_DRM_CLIENT_DEFAULT_FBDEV=y
>      # CONFIG_DRM_CLIENT_DEFAULT_LOG is not set
>      CONFIG_DRM_CLIENT_DEFAULT="fbdev"
> 
> Thanks!
> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 

Hi Jocelyn.

On Tue, Dec 17, 2024 at 3:46 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> On 17/12/2024 15:19, Geert Uytterhoeven wrote:
> > On Wed, Dec 4, 2024 at 6:41 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> >> drm_log is a simple logger that uses the drm_client API to print the kmsg boot log on the screen.
> >> This is not a full replacement to fbcon, as it will only print the kmsg.
> >> It will never handle user input, or a terminal because this is better done in userspace.
> >>
> >> If you're curious on how it looks like, I've put a small demo here:
> >> https://people.redhat.com/jfalempe/drm_log/drm_log_draft_boot_v2.mp4
> >>
> >> Design decisions:
> >>    * It uses the drm_client API, so it should work on all drm drivers from the start.
> >>    * It doesn't scroll the message, that way it doesn't need to redraw the whole screen for each new message.
> >>      It also means it doesn't have to keep drawn messages in memory, to redraw them when scrolling.
> >>    * It uses the new non-blocking console API, so it should work well with PREEMPT_RT
> >
> > I gave this a try on Koelsch (R-Car M2-W), using rcar-du.
> > Unfortunately I don't see any kernel messages, and my monitor complains
> > about no signal. Does this require special support from the driver?
>
> It doesn't require a special support from the driver. But as it is the
> first drm client other than fbdev emulation, I'm not surprised it's
> broken on some driver.
> I know it works on virtio-gpu, nouveau, amdgpu, and even on a OnePlus 6
> (Qualcomm SDM845/freedreno), without requiring driver changes.
>
> Do you have a serial console on this device, to check if there is
> something in kmsg?

Nothing interesting to see. Compared to the fbdev client:

     rcar-du feb00000.display: [drm] Registered 2 planes with drm panic
     [drm] Initialized rcar-du 1.0.0 for feb00000.display on minor 0
     rcar-du feb00000.display: [drm] Device feb00000.display probed
    -Console: switching to colour frame buffer device 240x67
    -rcar-du feb00000.display: [drm] fb0: rcar-dudrmfb frame buffer device

I did verify (by adding my own debug prints) that the code does
get to the success case in drm_log_register().
Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On 17/12/2024 15:54, Geert Uytterhoeven wrote:
> Hi Jocelyn.
> 
> On Tue, Dec 17, 2024 at 3:46 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
>> On 17/12/2024 15:19, Geert Uytterhoeven wrote:
>>> On Wed, Dec 4, 2024 at 6:41 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
>>>> drm_log is a simple logger that uses the drm_client API to print the kmsg boot log on the screen.
>>>> This is not a full replacement to fbcon, as it will only print the kmsg.
>>>> It will never handle user input, or a terminal because this is better done in userspace.
>>>>
>>>> If you're curious on how it looks like, I've put a small demo here:
>>>> https://people.redhat.com/jfalempe/drm_log/drm_log_draft_boot_v2.mp4
>>>>
>>>> Design decisions:
>>>>     * It uses the drm_client API, so it should work on all drm drivers from the start.
>>>>     * It doesn't scroll the message, that way it doesn't need to redraw the whole screen for each new message.
>>>>       It also means it doesn't have to keep drawn messages in memory, to redraw them when scrolling.
>>>>     * It uses the new non-blocking console API, so it should work well with PREEMPT_RT
>>>
>>> I gave this a try on Koelsch (R-Car M2-W), using rcar-du.
>>> Unfortunately I don't see any kernel messages, and my monitor complains
>>> about no signal. Does this require special support from the driver?
>>
>> It doesn't require a special support from the driver. But as it is the
>> first drm client other than fbdev emulation, I'm not surprised it's
>> broken on some driver.
>> I know it works on virtio-gpu, nouveau, amdgpu, and even on a OnePlus 6
>> (Qualcomm SDM845/freedreno), without requiring driver changes.
>>
>> Do you have a serial console on this device, to check if there is
>> something in kmsg?
> 
> Nothing interesting to see. Compared to the fbdev client:
> 
>       rcar-du feb00000.display: [drm] Registered 2 planes with drm panic
>       [drm] Initialized rcar-du 1.0.0 for feb00000.display on minor 0
>       rcar-du feb00000.display: [drm] Device feb00000.display probed
>      -Console: switching to colour frame buffer device 240x67
>      -rcar-du feb00000.display: [drm] fb0: rcar-dudrmfb frame buffer device
> 
> I did verify (by adding my own debug prints) that the code does
> get to the success case in drm_log_register().
> Thanks!

Maybe you need to add console=drm_log to your kernel command line, so 
the kernel will actually use this console.

> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 

Hi Jocelyn,

On Wed, Dec 18, 2024 at 11:14 AM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> On 17/12/2024 15:54, Geert Uytterhoeven wrote:
> > On Tue, Dec 17, 2024 at 3:46 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> >> On 17/12/2024 15:19, Geert Uytterhoeven wrote:
> >>> On Wed, Dec 4, 2024 at 6:41 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> >>>> drm_log is a simple logger that uses the drm_client API to print the kmsg boot log on the screen.
> >>>> This is not a full replacement to fbcon, as it will only print the kmsg.
> >>>> It will never handle user input, or a terminal because this is better done in userspace.
> >>>>
> >>>> If you're curious on how it looks like, I've put a small demo here:
> >>>> https://people.redhat.com/jfalempe/drm_log/drm_log_draft_boot_v2.mp4
> >>>>
> >>>> Design decisions:
> >>>>     * It uses the drm_client API, so it should work on all drm drivers from the start.
> >>>>     * It doesn't scroll the message, that way it doesn't need to redraw the whole screen for each new message.
> >>>>       It also means it doesn't have to keep drawn messages in memory, to redraw them when scrolling.
> >>>>     * It uses the new non-blocking console API, so it should work well with PREEMPT_RT
> >>>
> >>> I gave this a try on Koelsch (R-Car M2-W), using rcar-du.
> >>> Unfortunately I don't see any kernel messages, and my monitor complains
> >>> about no signal. Does this require special support from the driver?
> >>
> >> It doesn't require a special support from the driver. But as it is the
> >> first drm client other than fbdev emulation, I'm not surprised it's
> >> broken on some driver.
> >> I know it works on virtio-gpu, nouveau, amdgpu, and even on a OnePlus 6
> >> (Qualcomm SDM845/freedreno), without requiring driver changes.
> >>
> >> Do you have a serial console on this device, to check if there is
> >> something in kmsg?
> >
> > Nothing interesting to see. Compared to the fbdev client:
> >
> >       rcar-du feb00000.display: [drm] Registered 2 planes with drm panic
> >       [drm] Initialized rcar-du 1.0.0 for feb00000.display on minor 0
> >       rcar-du feb00000.display: [drm] Device feb00000.display probed
> >      -Console: switching to colour frame buffer device 240x67
> >      -rcar-du feb00000.display: [drm] fb0: rcar-dudrmfb frame buffer device
> >
> > I did verify (by adding my own debug prints) that the code does
> > get to the success case in drm_log_register().
> > Thanks!
>
> Maybe you need to add console=drm_log to your kernel command line, so
> the kernel will actually use this console.

Thanks, that does the trick!

Note that I do not need to specify any console= kernel command line
parameter for the fbdev console.

With

    CONFIG_VT_CONSOLE=y
    CONFIG_DRM_CLIENT_DEFAULT_FBDEV=y

I see all console messages on both the emulated fbdev console and on
the serial console by default.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On 18/12/2024 12:00, Geert Uytterhoeven wrote:
> Hi Jocelyn,
> 
> On Wed, Dec 18, 2024 at 11:14 AM Jocelyn Falempe <jfalempe@redhat.com> wrote:
>> On 17/12/2024 15:54, Geert Uytterhoeven wrote:
>>> On Tue, Dec 17, 2024 at 3:46 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
>>>> On 17/12/2024 15:19, Geert Uytterhoeven wrote:
>>>>> On Wed, Dec 4, 2024 at 6:41 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
>>>>>> drm_log is a simple logger that uses the drm_client API to print the kmsg boot log on the screen.
>>>>>> This is not a full replacement to fbcon, as it will only print the kmsg.
>>>>>> It will never handle user input, or a terminal because this is better done in userspace.
>>>>>>
>>>>>> If you're curious on how it looks like, I've put a small demo here:
>>>>>> https://people.redhat.com/jfalempe/drm_log/drm_log_draft_boot_v2.mp4
>>>>>>
>>>>>> Design decisions:
>>>>>>      * It uses the drm_client API, so it should work on all drm drivers from the start.
>>>>>>      * It doesn't scroll the message, that way it doesn't need to redraw the whole screen for each new message.
>>>>>>        It also means it doesn't have to keep drawn messages in memory, to redraw them when scrolling.
>>>>>>      * It uses the new non-blocking console API, so it should work well with PREEMPT_RT
>>>>>
>>>>> I gave this a try on Koelsch (R-Car M2-W), using rcar-du.
>>>>> Unfortunately I don't see any kernel messages, and my monitor complains
>>>>> about no signal. Does this require special support from the driver?
>>>>
>>>> It doesn't require a special support from the driver. But as it is the
>>>> first drm client other than fbdev emulation, I'm not surprised it's
>>>> broken on some driver.
>>>> I know it works on virtio-gpu, nouveau, amdgpu, and even on a OnePlus 6
>>>> (Qualcomm SDM845/freedreno), without requiring driver changes.
>>>>
>>>> Do you have a serial console on this device, to check if there is
>>>> something in kmsg?
>>>
>>> Nothing interesting to see. Compared to the fbdev client:
>>>
>>>        rcar-du feb00000.display: [drm] Registered 2 planes with drm panic
>>>        [drm] Initialized rcar-du 1.0.0 for feb00000.display on minor 0
>>>        rcar-du feb00000.display: [drm] Device feb00000.display probed
>>>       -Console: switching to colour frame buffer device 240x67
>>>       -rcar-du feb00000.display: [drm] fb0: rcar-dudrmfb frame buffer device
>>>
>>> I did verify (by adding my own debug prints) that the code does
>>> get to the success case in drm_log_register().
>>> Thanks!
>>
>> Maybe you need to add console=drm_log to your kernel command line, so
>> the kernel will actually use this console.
> 
> Thanks, that does the trick!
> 
> Note that I do not need to specify any console= kernel command line
> parameter for the fbdev console.

Yes, the fbcon console is tty0, which is hardcoded for historical reason.
Some architectures use add_preferred_console() to enable specific 
consoles, I'm not sure it's allowed to use that from the 
drm_log_register() code.

I will still send a patch to add update the Kconfig help for drm_log, as 
this command line argument is required to have it working.

Best regards,

-- 

Jocelyn

> 
> With
> 
>      CONFIG_VT_CONSOLE=y
>      CONFIG_DRM_CLIENT_DEFAULT_FBDEV=y
> 
> I see all console messages on both the emulated fbdev console and on
> the serial console by default.
> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 

On Wed 2024-12-18 12:41:39, Jocelyn Falempe wrote:
> On 18/12/2024 12:00, Geert Uytterhoeven wrote:
> > Hi Jocelyn,
> > 
> > On Wed, Dec 18, 2024 at 11:14 AM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> > > On 17/12/2024 15:54, Geert Uytterhoeven wrote:
> > > > On Tue, Dec 17, 2024 at 3:46 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> > > > > On 17/12/2024 15:19, Geert Uytterhoeven wrote:
> > > > > > On Wed, Dec 4, 2024 at 6:41 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> > > > > > > drm_log is a simple logger that uses the drm_client API to print the kmsg boot log on the screen.
> > > > > > > This is not a full replacement to fbcon, as it will only print the kmsg.
> > > > > > > It will never handle user input, or a terminal because this is better done in userspace.
> > > > > > > 
> > > > > > > If you're curious on how it looks like, I've put a small demo here:
> > > > > > > https://people.redhat.com/jfalempe/drm_log/drm_log_draft_boot_v2.mp4
> > > > > > > 
> > > > > > > Design decisions:
> > > > > > >      * It uses the drm_client API, so it should work on all drm drivers from the start.
> > > > > > >      * It doesn't scroll the message, that way it doesn't need to redraw the whole screen for each new message.
> > > > > > >        It also means it doesn't have to keep drawn messages in memory, to redraw them when scrolling.
> > > > > > >      * It uses the new non-blocking console API, so it should work well with PREEMPT_RT
> > > > > > 
> > > > > > I gave this a try on Koelsch (R-Car M2-W), using rcar-du.
> > > > > > Unfortunately I don't see any kernel messages, and my monitor complains
> > > > > > about no signal. Does this require special support from the driver?
> > > > > 
> > > > > It doesn't require a special support from the driver. But as it is the
> > > > > first drm client other than fbdev emulation, I'm not surprised it's
> > > > > broken on some driver.
> > > > > I know it works on virtio-gpu, nouveau, amdgpu, and even on a OnePlus 6
> > > > > (Qualcomm SDM845/freedreno), without requiring driver changes.
> > > > > 
> > > > > Do you have a serial console on this device, to check if there is
> > > > > something in kmsg?
> > > > 
> > > > Nothing interesting to see. Compared to the fbdev client:
> > > > 
> > > >        rcar-du feb00000.display: [drm] Registered 2 planes with drm panic
> > > >        [drm] Initialized rcar-du 1.0.0 for feb00000.display on minor 0
> > > >        rcar-du feb00000.display: [drm] Device feb00000.display probed
> > > >       -Console: switching to colour frame buffer device 240x67
> > > >       -rcar-du feb00000.display: [drm] fb0: rcar-dudrmfb frame buffer device
> > > > 
> > > > I did verify (by adding my own debug prints) that the code does
> > > > get to the success case in drm_log_register().
> > > > Thanks!
> > > 
> > > Maybe you need to add console=drm_log to your kernel command line, so
> > > the kernel will actually use this console.
> > 
> > Thanks, that does the trick!
> > 
> > Note that I do not need to specify any console= kernel command line
> > parameter for the fbdev console.
> 
> Yes, the fbcon console is tty0, which is hardcoded for historical reason.
> Some architectures use add_preferred_console() to enable specific consoles,
> I'm not sure it's allowed to use that from the drm_log_register() code.

add_preferred_console() is used when the console should get enabled
intentionally. I would split the intentions into two categories:

  + requested by the end-user on the command line, see
       __add_preferred_console(..., true) in console_setup()

  + enabled by default by a hardware definition (manufacture), see
       add_preferred_console() in:

	+ of_console_check(): generic solution via device tree
	+ acpi_parse_spcr(): generic solution via SPCR table
	+ *: hardcoded in few more HW-specific drivers

add_preferred_console() causes the console will always get enabled
when it is successfully initialized.

So, should the "drm_log" console get always enabled?


> I will still send a patch to add update the Kconfig help for drm_log, as
> this command line argument is required to have it working.

I guess that the drm_log consoles should get enabled only when
requested by the user => documenting the command line parameter
is the right solution here.

Best Regards,
Petr

On 18/12/2024 15:18, Petr Mladek wrote:
> On Wed 2024-12-18 12:41:39, Jocelyn Falempe wrote:
>> On 18/12/2024 12:00, Geert Uytterhoeven wrote:
>>> Hi Jocelyn,
>>>
>>> On Wed, Dec 18, 2024 at 11:14 AM Jocelyn Falempe <jfalempe@redhat.com> wrote:
>>>> On 17/12/2024 15:54, Geert Uytterhoeven wrote:
>>>>> On Tue, Dec 17, 2024 at 3:46 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
>>>>>> On 17/12/2024 15:19, Geert Uytterhoeven wrote:
>>>>>>> On Wed, Dec 4, 2024 at 6:41 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
>>>>>>>> drm_log is a simple logger that uses the drm_client API to print the kmsg boot log on the screen.
>>>>>>>> This is not a full replacement to fbcon, as it will only print the kmsg.
>>>>>>>> It will never handle user input, or a terminal because this is better done in userspace.
>>>>>>>>
>>>>>>>> If you're curious on how it looks like, I've put a small demo here:
>>>>>>>> https://people.redhat.com/jfalempe/drm_log/drm_log_draft_boot_v2.mp4
>>>>>>>>
>>>>>>>> Design decisions:
>>>>>>>>       * It uses the drm_client API, so it should work on all drm drivers from the start.
>>>>>>>>       * It doesn't scroll the message, that way it doesn't need to redraw the whole screen for each new message.
>>>>>>>>         It also means it doesn't have to keep drawn messages in memory, to redraw them when scrolling.
>>>>>>>>       * It uses the new non-blocking console API, so it should work well with PREEMPT_RT
>>>>>>>
>>>>>>> I gave this a try on Koelsch (R-Car M2-W), using rcar-du.
>>>>>>> Unfortunately I don't see any kernel messages, and my monitor complains
>>>>>>> about no signal. Does this require special support from the driver?
>>>>>>
>>>>>> It doesn't require a special support from the driver. But as it is the
>>>>>> first drm client other than fbdev emulation, I'm not surprised it's
>>>>>> broken on some driver.
>>>>>> I know it works on virtio-gpu, nouveau, amdgpu, and even on a OnePlus 6
>>>>>> (Qualcomm SDM845/freedreno), without requiring driver changes.
>>>>>>
>>>>>> Do you have a serial console on this device, to check if there is
>>>>>> something in kmsg?
>>>>>
>>>>> Nothing interesting to see. Compared to the fbdev client:
>>>>>
>>>>>         rcar-du feb00000.display: [drm] Registered 2 planes with drm panic
>>>>>         [drm] Initialized rcar-du 1.0.0 for feb00000.display on minor 0
>>>>>         rcar-du feb00000.display: [drm] Device feb00000.display probed
>>>>>        -Console: switching to colour frame buffer device 240x67
>>>>>        -rcar-du feb00000.display: [drm] fb0: rcar-dudrmfb frame buffer device
>>>>>
>>>>> I did verify (by adding my own debug prints) that the code does
>>>>> get to the success case in drm_log_register().
>>>>> Thanks!
>>>>
>>>> Maybe you need to add console=drm_log to your kernel command line, so
>>>> the kernel will actually use this console.
>>>
>>> Thanks, that does the trick!
>>>
>>> Note that I do not need to specify any console= kernel command line
>>> parameter for the fbdev console.
>>
>> Yes, the fbcon console is tty0, which is hardcoded for historical reason.
>> Some architectures use add_preferred_console() to enable specific consoles,
>> I'm not sure it's allowed to use that from the drm_log_register() code.
> 
> add_preferred_console() is used when the console should get enabled
> intentionally. I would split the intentions into two categories:
> 
>    + requested by the end-user on the command line, see
>         __add_preferred_console(..., true) in console_setup()
> 
>    + enabled by default by a hardware definition (manufacture), see
>         add_preferred_console() in:
> 
> 	+ of_console_check(): generic solution via device tree
> 	+ acpi_parse_spcr(): generic solution via SPCR table
> 	+ *: hardcoded in few more HW-specific drivers
> 
> add_preferred_console() causes the console will always get enabled
> when it is successfully initialized.
> 
> So, should the "drm_log" console get always enabled?

drm_log is a replacement for fbcon, which is always enabled, so I think 
it should also be always enabled. Otherwise you won't get any console as 
fbcon is no more available.
drm_log doesn't really fit in the architecture/hardware model, because 
drm drivers are available for a wide range of architecture, and a GPU 
can do either fbdev/fbcon or drm_log.

> 
> 
>> I will still send a patch to add update the Kconfig help for drm_log, as
>> this command line argument is required to have it working.
> 
> I guess that the drm_log consoles should get enabled only when
> requested by the user => documenting the command line parameter
> is the right solution here.

Most embedded linux specify the console on the command line, but for 
laptop/desktop distributions, it's not the case as fbcon is the default 
since the beginning.

I see a few options here:
1) Use add_preferred_console("drm_log") if DRM_CLIENT_LOG is enabled for 
x86_64 and maybe arm64, so at least the main users are covered.
2) Have a DRM_CLIENT_LOG_PREFERRED_CONSOLE config, so that it's easier 
to setup than changing the kernel command line.
3) Use the kernel command line.

Best Regards,

-- 

Jocelyn

> 
> Best Regards,
> Petr
> 

On Wed 2024-12-18 15:58:46, Jocelyn Falempe wrote:
> On 18/12/2024 15:18, Petr Mladek wrote:
> > On Wed 2024-12-18 12:41:39, Jocelyn Falempe wrote:
> > > On 18/12/2024 12:00, Geert Uytterhoeven wrote:
> > > > Hi Jocelyn,
> > > > 
> > > > On Wed, Dec 18, 2024 at 11:14 AM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> > > > > On 17/12/2024 15:54, Geert Uytterhoeven wrote:
> > > > > > On Tue, Dec 17, 2024 at 3:46 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> > > > > > > On 17/12/2024 15:19, Geert Uytterhoeven wrote:
> > > > > > > > On Wed, Dec 4, 2024 at 6:41 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> > > > > > > > > drm_log is a simple logger that uses the drm_client API to print the kmsg boot log on the screen.
> > > > > > > > > This is not a full replacement to fbcon, as it will only print the kmsg.
> > > > > > > > > It will never handle user input, or a terminal because this is better done in userspace.
> > > > > > > > > 
> > > > > > > > > If you're curious on how it looks like, I've put a small demo here:
> > > > > > > > > https://people.redhat.com/jfalempe/drm_log/drm_log_draft_boot_v2.mp4
> > > > > > > > > 
> > > > > > > > > Design decisions:
> > > > > > > > >       * It uses the drm_client API, so it should work on all drm drivers from the start.
> > > > > > > > >       * It doesn't scroll the message, that way it doesn't need to redraw the whole screen for each new message.
> > > > > > > > >         It also means it doesn't have to keep drawn messages in memory, to redraw them when scrolling.
> > > > > > > > >       * It uses the new non-blocking console API, so it should work well with PREEMPT_RT
> > > > > > > > 
> > > > > > > > I gave this a try on Koelsch (R-Car M2-W), using rcar-du.
> > > > > > > > Unfortunately I don't see any kernel messages, and my monitor complains
> > > > > > > > about no signal. Does this require special support from the driver?
> > > > > > > 
> > > > > > > It doesn't require a special support from the driver. But as it is the
> > > > > > > first drm client other than fbdev emulation, I'm not surprised it's
> > > > > > > broken on some driver.
> > > > > > > I know it works on virtio-gpu, nouveau, amdgpu, and even on a OnePlus 6
> > > > > > > (Qualcomm SDM845/freedreno), without requiring driver changes.
> > > > > > > 
> > > > > > > Do you have a serial console on this device, to check if there is
> > > > > > > something in kmsg?
> > > > > > 
> > > > > > Nothing interesting to see. Compared to the fbdev client:
> > > > > > 
> > > > > >         rcar-du feb00000.display: [drm] Registered 2 planes with drm panic
> > > > > >         [drm] Initialized rcar-du 1.0.0 for feb00000.display on minor 0
> > > > > >         rcar-du feb00000.display: [drm] Device feb00000.display probed
> > > > > >        -Console: switching to colour frame buffer device 240x67
> > > > > >        -rcar-du feb00000.display: [drm] fb0: rcar-dudrmfb frame buffer device
> > > > > > 
> > > > > > I did verify (by adding my own debug prints) that the code does
> > > > > > get to the success case in drm_log_register().
> > > > > > Thanks!
> > > > > 
> > > > > Maybe you need to add console=drm_log to your kernel command line, so
> > > > > the kernel will actually use this console.
> > > > 
> > > > Thanks, that does the trick!
> > > > 
> > > > Note that I do not need to specify any console= kernel command line
> > > > parameter for the fbdev console.
> > > 
> > > Yes, the fbcon console is tty0, which is hardcoded for historical reason.
> > > Some architectures use add_preferred_console() to enable specific consoles,
> > > I'm not sure it's allowed to use that from the drm_log_register() code.
> > 
> > add_preferred_console() is used when the console should get enabled
> > intentionally. I would split the intentions into two categories:
> > 
> >    + requested by the end-user on the command line, see
> >         __add_preferred_console(..., true) in console_setup()
> > 
> >    + enabled by default by a hardware definition (manufacture), see
> >         add_preferred_console() in:
> > 
> > 	+ of_console_check(): generic solution via device tree
> > 	+ acpi_parse_spcr(): generic solution via SPCR table
> > 	+ *: hardcoded in few more HW-specific drivers
> > 
> > add_preferred_console() causes the console will always get enabled
> > when it is successfully initialized.
> > 
> > So, should the "drm_log" console get always enabled?
> 
> drm_log is a replacement for fbcon, which is always enabled, so I think it
> should also be always enabled. Otherwise you won't get any console as fbcon
> is no more available.

IMHO, it is not true that "fbcon" is always enabled. For example,
if you mention "console=ttyS0,115200" on the command line then only
the serial console is enabled.

Honestly, I do not understand completely the connection between the
drm drivers and the console subsystem.

My understanding is that fbcon is registered via the very old and
generic VT (Virtual Terminal) layer, see do_fbcon_takeover().

As a result, it gets registered/enabled by default when there is
no other console defined on the command line or an
add_preferred_console() call.

It is this code:

void register_console(struct console *newcon)
{
[...]
	/*
	 * See if we want to enable this console driver by default.
	 *
	 * Nope when a console is preferred by the command line, device
	 * tree, or SPCR.
	 *
	 * The first real console with tty binding (driver) wins. More
	 * consoles might get enabled before the right one is found.
	 *
	 * Note that a console with tty binding will have CON_CONSDEV
	 * flag set and will be first in the list.
	 */
	if (preferred_console < 0) {
		if (hlist_empty(&console_list) || !console_first()->device ||
		    console_first()->flags & CON_BOOT) {
			try_enable_default_console(newcon);
		}
	}
[...]
}

Note that try_enable_default_console(newcon) fails only when
newcon->setup() fails. It means that the given console is almost
always enabled when this function is called.

The important thing here might be the check of "!console_first()->device".
It causes, that register_console() stop calling
try_enable_default_console(newcon) when there is at least one console
with the tty binding registered.

IMHO, this is the reason why "fbcon" is enabled by default. It is
the first registered driver with the tty binding.

Also this might be the reason why "drm_log" is _not_ enabled by
default. I guess that drm_log_register() is called too late.
I guess that there already is enabled another console driver with
tty binding at that time, most likely the serial console.

Could you please confirm this?
What console is enabled when console=drm_log is not used, please?


> drm_log doesn't really fit in the architecture/hardware model, because drm
> drivers are available for a wide range of architecture, and a GPU can do
> either fbdev/fbcon or drm_log.
> > 
> > > I will still send a patch to add update the Kconfig help for drm_log, as
> > > this command line argument is required to have it working.
> > 
> > I guess that the drm_log consoles should get enabled only when
> > requested by the user => documenting the command line parameter
> > is the right solution here.
> 
> Most embedded linux specify the console on the command line, but for
> laptop/desktop distributions, it's not the case as fbcon is the default
> since the beginning.
> 
> I see a few options here:
> 1) Use add_preferred_console("drm_log") if DRM_CLIENT_LOG is enabled for
> x86_64 and maybe arm64, so at least the main users are covered.
> 2) Have a DRM_CLIENT_LOG_PREFERRED_CONSOLE config, so that it's easier to
> setup than changing the kernel command line.

I guess that you plan to call add_preferred_console() in this case.
It is not the same as "fbcon" now:

1. It would cause that "drm_log" will always be enabled. It won't be
   possible to override it on the command line.

2. It will set "preferred_console". As a result,
   try_enable_default_console(newcon) will never be called.
   => there won't be any console when "drm_log" initialization
   fails and drm_log_register() is not called from some reason.

> 3) Use the kernel command line.


An ideal solution would be to allow calling drm_log_register() so
that it can be registered as the first console driver by
try_enable_default_console().

If this is not possible than we should think hard about it.
The console registration rules are already very complicated.
And we should think twice before adding any other twist
in the logic.

Best Regards,
Petr

On 18/12/2024 17:18, Petr Mladek wrote:
> On Wed 2024-12-18 15:58:46, Jocelyn Falempe wrote:
>> On 18/12/2024 15:18, Petr Mladek wrote:
>>> On Wed 2024-12-18 12:41:39, Jocelyn Falempe wrote:
>>>> On 18/12/2024 12:00, Geert Uytterhoeven wrote:
>>>>> Hi Jocelyn,
>>>>>
>>>>> On Wed, Dec 18, 2024 at 11:14 AM Jocelyn Falempe <jfalempe@redhat.com> wrote:
>>>>>> On 17/12/2024 15:54, Geert Uytterhoeven wrote:
>>>>>>> On Tue, Dec 17, 2024 at 3:46 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
>>>>>>>> On 17/12/2024 15:19, Geert Uytterhoeven wrote:
>>>>>>>>> On Wed, Dec 4, 2024 at 6:41 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
>>>>>>>>>> drm_log is a simple logger that uses the drm_client API to print the kmsg boot log on the screen.
>>>>>>>>>> This is not a full replacement to fbcon, as it will only print the kmsg.
>>>>>>>>>> It will never handle user input, or a terminal because this is better done in userspace.
>>>>>>>>>>
>>>>>>>>>> If you're curious on how it looks like, I've put a small demo here:
>>>>>>>>>> https://people.redhat.com/jfalempe/drm_log/drm_log_draft_boot_v2.mp4
>>>>>>>>>>
>>>>>>>>>> Design decisions:
>>>>>>>>>>        * It uses the drm_client API, so it should work on all drm drivers from the start.
>>>>>>>>>>        * It doesn't scroll the message, that way it doesn't need to redraw the whole screen for each new message.
>>>>>>>>>>          It also means it doesn't have to keep drawn messages in memory, to redraw them when scrolling.
>>>>>>>>>>        * It uses the new non-blocking console API, so it should work well with PREEMPT_RT
>>>>>>>>>
>>>>>>>>> I gave this a try on Koelsch (R-Car M2-W), using rcar-du.
>>>>>>>>> Unfortunately I don't see any kernel messages, and my monitor complains
>>>>>>>>> about no signal. Does this require special support from the driver?
>>>>>>>>
>>>>>>>> It doesn't require a special support from the driver. But as it is the
>>>>>>>> first drm client other than fbdev emulation, I'm not surprised it's
>>>>>>>> broken on some driver.
>>>>>>>> I know it works on virtio-gpu, nouveau, amdgpu, and even on a OnePlus 6
>>>>>>>> (Qualcomm SDM845/freedreno), without requiring driver changes.
>>>>>>>>
>>>>>>>> Do you have a serial console on this device, to check if there is
>>>>>>>> something in kmsg?
>>>>>>>
>>>>>>> Nothing interesting to see. Compared to the fbdev client:
>>>>>>>
>>>>>>>          rcar-du feb00000.display: [drm] Registered 2 planes with drm panic
>>>>>>>          [drm] Initialized rcar-du 1.0.0 for feb00000.display on minor 0
>>>>>>>          rcar-du feb00000.display: [drm] Device feb00000.display probed
>>>>>>>         -Console: switching to colour frame buffer device 240x67
>>>>>>>         -rcar-du feb00000.display: [drm] fb0: rcar-dudrmfb frame buffer device
>>>>>>>
>>>>>>> I did verify (by adding my own debug prints) that the code does
>>>>>>> get to the success case in drm_log_register().
>>>>>>> Thanks!
>>>>>>
>>>>>> Maybe you need to add console=drm_log to your kernel command line, so
>>>>>> the kernel will actually use this console.
>>>>>
>>>>> Thanks, that does the trick!
>>>>>
>>>>> Note that I do not need to specify any console= kernel command line
>>>>> parameter for the fbdev console.
>>>>
>>>> Yes, the fbcon console is tty0, which is hardcoded for historical reason.
>>>> Some architectures use add_preferred_console() to enable specific consoles,
>>>> I'm not sure it's allowed to use that from the drm_log_register() code.
>>>
>>> add_preferred_console() is used when the console should get enabled
>>> intentionally. I would split the intentions into two categories:
>>>
>>>     + requested by the end-user on the command line, see
>>>          __add_preferred_console(..., true) in console_setup()
>>>
>>>     + enabled by default by a hardware definition (manufacture), see
>>>          add_preferred_console() in:
>>>
>>> 	+ of_console_check(): generic solution via device tree
>>> 	+ acpi_parse_spcr(): generic solution via SPCR table
>>> 	+ *: hardcoded in few more HW-specific drivers
>>>
>>> add_preferred_console() causes the console will always get enabled
>>> when it is successfully initialized.
>>>
>>> So, should the "drm_log" console get always enabled?
>>
>> drm_log is a replacement for fbcon, which is always enabled, so I think it
>> should also be always enabled. Otherwise you won't get any console as fbcon
>> is no more available.
> 
> IMHO, it is not true that "fbcon" is always enabled. For example,
> if you mention "console=ttyS0,115200" on the command line then only
> the serial console is enabled.
> 
> Honestly, I do not understand completely the connection between the
> drm drivers and the console subsystem.
> 
> My understanding is that fbcon is registered via the very old and
> generic VT (Virtual Terminal) layer, see do_fbcon_takeover().
> 
> As a result, it gets registered/enabled by default when there is
> no other console defined on the command line or an
> add_preferred_console() call.
> 
> It is this code:
> 
> void register_console(struct console *newcon)
> {
> [...]
> 	/*
> 	 * See if we want to enable this console driver by default.
> 	 *
> 	 * Nope when a console is preferred by the command line, device
> 	 * tree, or SPCR.
> 	 *
> 	 * The first real console with tty binding (driver) wins. More
> 	 * consoles might get enabled before the right one is found.
> 	 *
> 	 * Note that a console with tty binding will have CON_CONSDEV
> 	 * flag set and will be first in the list.
> 	 */
> 	if (preferred_console < 0) {
> 		if (hlist_empty(&console_list) || !console_first()->device ||
> 		    console_first()->flags & CON_BOOT) {
> 			try_enable_default_console(newcon);
> 		}
> 	}
> [...]
> }
> 
> Note that try_enable_default_console(newcon) fails only when
> newcon->setup() fails. It means that the given console is almost
> always enabled when this function is called.
> 
> The important thing here might be the check of "!console_first()->device".
> It causes, that register_console() stop calling
> try_enable_default_console(newcon) when there is at least one console
> with the tty binding registered.
> 
> IMHO, this is the reason why "fbcon" is enabled by default. It is
> the first registered driver with the tty binding.
> 
> Also this might be the reason why "drm_log" is _not_ enabled by
> default. I guess that drm_log_register() is called too late.
> I guess that there already is enabled another console driver with
> tty binding at that time, most likely the serial console.
> 
> Could you please confirm this?
> What console is enabled when console=drm_log is not used, please?

For fbcon, it's the VT_CONSOLE config option that enable the console.
It is run very early in the boot, and the console is registered even if 
there are no framebuffer device or fbdev emulation.

so if I have VT_CONSOLE=y, then tty0 is the default console, even if 
there are no drivers to write the content somewhere.

[    0.103324] Console: colour dummy device 80x25

If I disable VT_CONSOLE, then the default console is ttyS0, even if in 
most laptop/desktop, the serial line is no more accessible.

So in order to mimic the fbcon behavior, drm_log should register a dummy 
console very early, without knowing if some hardware would be able to 
actually display something later.


> 
> 
>> drm_log doesn't really fit in the architecture/hardware model, because drm
>> drivers are available for a wide range of architecture, and a GPU can do
>> either fbdev/fbcon or drm_log.
>>>
>>>> I will still send a patch to add update the Kconfig help for drm_log, as
>>>> this command line argument is required to have it working.
>>>
>>> I guess that the drm_log consoles should get enabled only when
>>> requested by the user => documenting the command line parameter
>>> is the right solution here.
>>
>> Most embedded linux specify the console on the command line, but for
>> laptop/desktop distributions, it's not the case as fbcon is the default
>> since the beginning.
>>
>> I see a few options here:
>> 1) Use add_preferred_console("drm_log") if DRM_CLIENT_LOG is enabled for
>> x86_64 and maybe arm64, so at least the main users are covered.
>> 2) Have a DRM_CLIENT_LOG_PREFERRED_CONSOLE config, so that it's easier to
>> setup than changing the kernel command line.
> 
> I guess that you plan to call add_preferred_console() in this case.
> It is not the same as "fbcon" now:
> 
> 1. It would cause that "drm_log" will always be enabled. It won't be
>     possible to override it on the command line.

You can disable drm_log from the command line, by passing 
"drm_client.active=", in this case no drm_log console would be registered.
> 
> 2. It will set "preferred_console". As a result,
>     try_enable_default_console(newcon) will never be called.
>     => there won't be any console when "drm_log" initialization
>     fails and drm_log_register() is not called from some reason.
> 
I don't think it's a problem. It's the same currently with fbcon.
tty0 is the default console with dummy output. if fbdev initialization 
fails, then the only console available is the dummy console, which does 
nothing at all.
So at least there won't be any regression when switching from fbcon to 
drm_log.

>> 3) Use the kernel command line.
> 
> 
> An ideal solution would be to allow calling drm_log_register() so
> that it can be registered as the first console driver by
> try_enable_default_console().
> 
> If this is not possible than we should think hard about it.
> The console registration rules are already very complicated.
> And we should think twice before adding any other twist
> in the logic.

Yes, I agree, we shouldn't make it worse than what it is already.

I will experiment with add_preferred_console() or having an early dummy 
drm_log registration, and see what works best.

> 
> Best Regards,
> Petr
> 

Hi Jocelyn,

On Wed, Dec 18, 2024 at 3:58 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> On 18/12/2024 15:18, Petr Mladek wrote:
> > On Wed 2024-12-18 12:41:39, Jocelyn Falempe wrote:
> >> On 18/12/2024 12:00, Geert Uytterhoeven wrote:
> >>> On Wed, Dec 18, 2024 at 11:14 AM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> >>>> Maybe you need to add console=drm_log to your kernel command line, so
> >>>> the kernel will actually use this console.
> >>>
> >>> Thanks, that does the trick!
> >>>
> >>> Note that I do not need to specify any console= kernel command line
> >>> parameter for the fbdev console.
> >>
> >> Yes, the fbcon console is tty0, which is hardcoded for historical reason.
> >> Some architectures use add_preferred_console() to enable specific consoles,
> >> I'm not sure it's allowed to use that from the drm_log_register() code.
> >
> > add_preferred_console() is used when the console should get enabled
> > intentionally. I would split the intentions into two categories:
> >
> >    + requested by the end-user on the command line, see
> >         __add_preferred_console(..., true) in console_setup()
> >
> >    + enabled by default by a hardware definition (manufacture), see
> >         add_preferred_console() in:
> >
> >       + of_console_check(): generic solution via device tree
> >       + acpi_parse_spcr(): generic solution via SPCR table
> >       + *: hardcoded in few more HW-specific drivers
> >
> > add_preferred_console() causes the console will always get enabled
> > when it is successfully initialized.
> >
> > So, should the "drm_log" console get always enabled?
>
> drm_log is a replacement for fbcon, which is always enabled, so I think
> it should also be always enabled. Otherwise you won't get any console as
> fbcon is no more available.
> drm_log doesn't really fit in the architecture/hardware model, because
> drm drivers are available for a wide range of architecture, and a GPU
> can do either fbdev/fbcon or drm_log.
>
> >> I will still send a patch to add update the Kconfig help for drm_log, as
> >> this command line argument is required to have it working.
> >
> > I guess that the drm_log consoles should get enabled only when
> > requested by the user => documenting the command line parameter
> > is the right solution here.
>
> Most embedded linux specify the console on the command line, but for
> laptop/desktop distributions, it's not the case as fbcon is the default
> since the beginning.

Note that on embedded systems with DT, the console is auto-selected
via chosen/stdout-path. No explicit console= needed.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Hi Petr,

On Wed, Dec 18, 2024 at 3:18 PM Petr Mladek <pmladek@suse.com> wrote:
> On Wed 2024-12-18 12:41:39, Jocelyn Falempe wrote:
> > On 18/12/2024 12:00, Geert Uytterhoeven wrote:
> > > On Wed, Dec 18, 2024 at 11:14 AM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> > > > On 17/12/2024 15:54, Geert Uytterhoeven wrote:
> > > > > On Tue, Dec 17, 2024 at 3:46 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> > > > > > On 17/12/2024 15:19, Geert Uytterhoeven wrote:
> > > > > > > On Wed, Dec 4, 2024 at 6:41 PM Jocelyn Falempe <jfalempe@redhat.com> wrote:
> > > > > > > > drm_log is a simple logger that uses the drm_client API to print the kmsg boot log on the screen.
> > > > > > > > This is not a full replacement to fbcon, as it will only print the kmsg.
> > > > > > > > It will never handle user input, or a terminal because this is better done in userspace.
> > > > > > > >
> > > > > > > > If you're curious on how it looks like, I've put a small demo here:
> > > > > > > > https://people.redhat.com/jfalempe/drm_log/drm_log_draft_boot_v2.mp4
> > > > > > > >
> > > > > > > > Design decisions:
> > > > > > > >      * It uses the drm_client API, so it should work on all drm drivers from the start.
> > > > > > > >      * It doesn't scroll the message, that way it doesn't need to redraw the whole screen for each new message.
> > > > > > > >        It also means it doesn't have to keep drawn messages in memory, to redraw them when scrolling.
> > > > > > > >      * It uses the new non-blocking console API, so it should work well with PREEMPT_RT
> > > > > > >
> > > > > > > I gave this a try on Koelsch (R-Car M2-W), using rcar-du.
> > > > > > > Unfortunately I don't see any kernel messages, and my monitor complains
> > > > > > > about no signal. Does this require special support from the driver?
> > > > > >
> > > > > > It doesn't require a special support from the driver. But as it is the
> > > > > > first drm client other than fbdev emulation, I'm not surprised it's
> > > > > > broken on some driver.
> > > > > > I know it works on virtio-gpu, nouveau, amdgpu, and even on a OnePlus 6
> > > > > > (Qualcomm SDM845/freedreno), without requiring driver changes.
> > > > > >
> > > > > > Do you have a serial console on this device, to check if there is
> > > > > > something in kmsg?
> > > > >
> > > > > Nothing interesting to see. Compared to the fbdev client:
> > > > >
> > > > >        rcar-du feb00000.display: [drm] Registered 2 planes with drm panic
> > > > >        [drm] Initialized rcar-du 1.0.0 for feb00000.display on minor 0
> > > > >        rcar-du feb00000.display: [drm] Device feb00000.display probed
> > > > >       -Console: switching to colour frame buffer device 240x67
> > > > >       -rcar-du feb00000.display: [drm] fb0: rcar-dudrmfb frame buffer device
> > > > >
> > > > > I did verify (by adding my own debug prints) that the code does
> > > > > get to the success case in drm_log_register().
> > > > > Thanks!
> > > >
> > > > Maybe you need to add console=drm_log to your kernel command line, so
> > > > the kernel will actually use this console.
> > >
> > > Thanks, that does the trick!
> > >
> > > Note that I do not need to specify any console= kernel command line
> > > parameter for the fbdev console.
> >
> > Yes, the fbcon console is tty0, which is hardcoded for historical reason.
> > Some architectures use add_preferred_console() to enable specific consoles,
> > I'm not sure it's allowed to use that from the drm_log_register() code.
>
> add_preferred_console() is used when the console should get enabled
> intentionally. I would split the intentions into two categories:
>
>   + requested by the end-user on the command line, see
>        __add_preferred_console(..., true) in console_setup()
>
>   + enabled by default by a hardware definition (manufacture), see
>        add_preferred_console() in:
>
>         + of_console_check(): generic solution via device tree
>         + acpi_parse_spcr(): generic solution via SPCR table
>         + *: hardcoded in few more HW-specific drivers
>
> add_preferred_console() causes the console will always get enabled
> when it is successfully initialized.
>
> So, should the "drm_log" console get always enabled?

Good question!

> > I will still send a patch to add update the Kconfig help for drm_log, as
> > this command line argument is required to have it working.
>
> I guess that the drm_log consoles should get enabled only when
> requested by the user => documenting the command line parameter
> is the right solution here.

There are actually two ways to request it:
  1. Through CONFIG_DRM_CLIENT_DEFAULT, at kernel configuration
     time,
  2. Through drm_client_lib.active=log, at kernel boot or module load time.

Currently both options need console=drm_log on top of that, which
sounds like overkill?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds