Re: [PATCH v2 3/3] drm/panic: Add a drm_panic/draw_test in debugfs

[Jocelyn Falempe <jfalempe@redhat.com>]

On 10/09/2025 12:49, Maxime Ripard wrote:
> Hi,
> 
> On Mon, Sep 08, 2025 at 11:00:31AM +0200, Jocelyn Falempe wrote:
>> This adds a new drm_panic/draw_test file in debugfs.
>> This file allows to test the panic screen rendering at different
>> resolution and pixel format.
>> It's useful only for kernel developers that want to create or
>> customize a panic screen.
>>
>> If you want to check the result at 1024x768 using XRGB8888:
>>
>> cd /sys/kernel/debug/drm_panic/
>> exec 3<> draw_test
>> echo 1024x768:XR24 >&3
>> cat <&3 > ~/panic_screen.raw
>> exec 3<&-
>>
>> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
> 
> I see what you meant in your previous version, and I misunderstood what
> you were saying, sorry.
> 
>> v2:
>>   * Use debugfs instead of sending the framebuffer through the kunit logs. (Thomas Zimmermann).
>>
>>   drivers/gpu/drm/Kconfig     |   2 +
>>   drivers/gpu/drm/drm_panic.c | 117 ++++++++++++++++++++++++++++++++++++
>>   2 files changed, 119 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index f7ea8e895c0c..0d3146070d9c 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -83,6 +83,8 @@ config DRM_PANIC_DEBUG
>>   	  Add dri/[device]/drm_panic_plane_x in the kernel debugfs, to force the
>>   	  panic handler to write the panic message to this plane scanout buffer.
>>   	  This is unsafe and should not be enabled on a production build.
>> +	  Also adds a drm_panic/draw_test file in debugfs, to easily test the
>> +	  panic screen rendering.
>>   	  If in doubt, say "N".
>>   
>>   config DRM_PANIC_SCREEN
>> diff --git a/drivers/gpu/drm/drm_panic.c b/drivers/gpu/drm/drm_panic.c
>> index d89812ff1935..0c01d6067eab 100644
>> --- a/drivers/gpu/drm/drm_panic.c
>> +++ b/drivers/gpu/drm/drm_panic.c
>> @@ -873,6 +873,7 @@ static void drm_panic(struct kmsg_dumper *dumper, struct kmsg_dump_detail *detai
>>    */
>>   #ifdef CONFIG_DRM_PANIC_DEBUG
>>   #include <linux/debugfs.h>
>> +#include <linux/vmalloc.h>
>>   
>>   static ssize_t debugfs_trigger_write(struct file *file, const char __user *user_buf,
>>   				     size_t count, loff_t *ppos)
>> @@ -901,8 +902,122 @@ static void debugfs_register_plane(struct drm_plane *plane, int index)
>>   	debugfs_create_file(fname, 0200, plane->dev->debugfs_root,
>>   			    plane, &dbg_drm_panic_ops);
>>   }
>> +
>> +/*
>> + * Draw test interface
>> + * This can be used to check the panic screen at any resolution/pixel format.
>> + * The framebuffer memory is freed when the file is closed, so use this sh
>> + * script to write the parameters and read the result without closing the file.
>> + * cd /sys/kernel/debug/drm_panic/
>> + * exec 3<> draw_test
>> + * echo 1024x768:XR24 >&3
>> + * cat <&3 > ~/panic_screen.raw
>> + * exec 3<&-
>> + */
> 
> This should be documented properly, and I'm also kind of wondering how
> that would fit in the larger testing ecosystem.
> 
> Ie, how can someone that just starts contributing to Linux, or is
> setting up a CI platform, can have that test running.
> 
> kunit is great for that, kselftests to some extent too, but I'm not sure
> an ad-hoc interface is.

It's a bit harder to setup, but also allows to do some useful things.
I've written a small GUI application which displays the contents of the 
debugfs drm_panic/draw_test file in a window.
The displayed content is automatically refreshed whenever the window is 
resized, making it easy to inspect the DRM panic output at any screen 
resolution.
https://gitlab.com/kdj0c/panicviewer

> 
> Unless we create IGT tests for it too maybe?

Yes, I should also take a look at what IGT can do.

> 
> Maxime


-- 

Jocelyn