Hello, Jiri. On Mon, Feb 24, 2025 at 21:08:50 +0100, Jiri Slaby wrote: > On 24. 02. 25, 19:22, Alan Mackenzie wrote: > > Hello, Greg. > > On Sun, Feb 23, 2025 at 08:47:53 +0100, Greg Kroah-Hartman wrote: > >> On Sat, Feb 22, 2025 at 03:36:12PM +0000, Alan Mackenzie wrote: > >>> On Sat, Feb 22, 2025 at 09:48:32 +0100, Greg Kroah-Hartman wrote: > > [ .... ] > >>> But I think you are also asking why I use the console at all. That's > >>> a fair question which I'll try to answer. > >> I'm not disputing using the console, it's the vt layer that I'm talking > >> about. The DRM developers have the long-term goal of getting rid of > >> CONFIG_VT which will remove a ton of mess that we have overall. > >> DRM-based consoles should provide the same functionality that a vt > >> console does today. If not, please let them know so that the remaining > >> corner cases can be resolved. > > Does a DRM based console exist at the moment? I spent quite some time > > looking for it yesterday, but found nothing. > I didn't read the thread, but are you looking e.g. for kmscon? No, I wasn't. I was looking for a drm replacement for the drivers/tty/vt code inside the kernel. I may have misunderstood Greg when he referred to a replacement which uses drm. kmscon doesn't seem to be a suitable replacement for the Linux console. According to Wikipedia, it stopped being maintained ~10 years ago. Also, it is a user level program, not a kernel level program, so will only become active later in the boot process than the current console, which is not a good thing. It might well steal key sequences from application programs, the way X and X window managers do, but maybe it doesn't. On Gentoo, kmscon is "masked", i.e. strongly recommended not to be installed, and installable only after taking special measures. > -- > js > suse labs -- Alan Mackenzie (Nuremberg, Germany).
