Hi
Am 26.11.25 um 13:19 schrieb Daniel Thompson:
On Tue, Nov 25, 2025 at 07:26:33AM -0800, Doug Anderson wrote:
On Tue, Nov 25, 2025 at 5:06 AM Thomas Zimmermann <[email protected]> wrote:
<snip>
Therefore remove the remaining support for kdb from the DRM drivers
and from DRM fbdev emulation. Also remove the hooks from fbdev, as
there are no fbdev drivers with kdb support.
If we ever want to address kdb support within DRM drivers, a place to
start would be the scanout buffers used by DRM's panic screen. These
use the current display mode. They can be written and flushed without
mode setting involved.
Note: kdb over serial lines is not affected by this series and continues
to work as before.
Thomas Zimmermann (5):
drm/amdgpu: Do not implement mode_set_base_atomic callback
drm/nouveau: Do not implement mode_set_base_atomic callback
drm/radeon: Do not implement mode_set_base_atomic callback
drm/fbdev-helper: Remove drm_fb_helper_debug_enter/_leave()
fbcon: Remove fb_debug_enter/_leave from struct fb_ops
Personally, I've never worked with kdb over anything other than
serial, so this won't bother any of my normal workflows. That being
said, at least as of a year ago someone on the lists was talking about
using kdb with a keyboard and (presumably) a display. You can see a
thread here:
http://lore.kernel.org/r/[email protected]
Daniel may also have comments here?
TL;DR - I'm pretty relaxed about these changes... but I'd like
to know how to test the changes.
Like Doug I only really use kdb via serial but, since I'm maintain
the thing I do occasionally test kdb works on the qemu console. I don't
do it very often though because it's a manual test!
I'd assume that will still work since it won't involve any of the
drivers above. I'm afraid I can't double check that since patch 4
doesn't apply cleanly in v6.18-rc7 (nor to linux-next... and neither
does the base-commit appear in linux-next).
To test its effects, ignore this series and simply clear the two
calbacks at [1]. This is where the debugger invokes fbcon. The series
removes their implementation in the final patch.
[1]
https://elixir.bootlin.com/linux/v6.17.9/source/drivers/video/fbdev/core/fbcon.c#L3202
Best regards
Thomas
Anyhow, the only testing I do for kgdboc=kms,kdb is to boot an x86-64
defconfig+kgdb+kdb kernel in qemu with something like the following
command line, which FWIW does still work:
qemu-system-x86_64 -enable-kvm -m 1G -smp 2 \
-kernel arch/x86/boot/bzImage \
-monitor none -chardev stdio,id=mon,mux=on,signal=off \
-serial chardev:mon \
-initrd rootfs.cpio.gz \
-append " console=tty0 console=ttyS0,115200 kgdboc=kms,kbd,ttyS0
kgdbwait"
The reason I'm fairly relaxed about changes here is that the kbd driver
only works on PCs with legacy keyboard interfaces. If the kernel is
talking to the keyboard using USB or I2C (which almost all PCs do) then
kdb cannot be used anyway.
So... it would be a "cool project"[1] to get kdb running on
a special interrupt-free I2C mode and with the DRM panic code so you
can do live analysis if your laptop/chomebook crashes. However it is
simply not "real enough" to justify slowing down other developers.
Daniel.
[1] ... but not quite cool enough that I see myself spending time on it
though!
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
