This allows to build the kernel with CONFIG_VT enabled, and choose
on the kernel command line to enable it or not.
Add vt.enable=1 to force enable, or vt.enable=0 to force disable.

Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
---
 drivers/tty/Kconfig | 13 +++++++++++++
 drivers/tty/vt/vt.c |  5 +++++
 2 files changed, 18 insertions(+)

diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index 149f3d53b7608..2b94c2710687a 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -41,6 +41,19 @@ config VT
 	  If unsure, say Y, or else you won't be able to do much with your new
 	  shiny Linux system :-)
 
+config VT_ENABLE
+	depends on VT
+	default y
+	bool "enable VT terminal" if EXPERT
+	help
+	  This allows to build the kernel with CONFIG_VT, and choose on the
+	  kernel command line to enable it or not. If set to y, VT will be
+	  enabled by default, but can be disabled with vt.enable=0 on the kernel
+	  command line. Otherwise, use vt.enable=1 to enable VT.
+	  This should help to transition to VT-less system.
+
+	  If unsure, say Y.
+
 config CONSOLE_TRANSLATIONS
 	depends on VT
 	default y
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 59b4b5e126ba1..d83613d98f594 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -164,6 +164,8 @@ EXPORT_SYMBOL(global_cursor_default);
 
 static int cur_default = CUR_UNDERLINE;
 module_param(cur_default, int, S_IRUGO | S_IWUSR);
+static bool vt_enable = IS_ENABLED(CONFIG_VT_ENABLE) ? true : false;
+module_param_named(enable, vt_enable, bool, S_IRUGO | S_IWUSR);
 
 /*
  * ignore_poke: don't unblank the screen when things are typed.  This is
@@ -3852,6 +3854,9 @@ ATTRIBUTE_GROUPS(vt_dev);
 
 int __init vty_init(const struct file_operations *console_fops)
 {
+	if (!vt_enable)
+		return 0;
+
 	cdev_init(&vc0_cdev, console_fops);
 	if (cdev_add(&vc0_cdev, MKDEV(TTY_MAJOR, 0), 1) ||
 	    register_chrdev_region(MKDEV(TTY_MAJOR, 0), 1, "/dev/vc/0") < 0)

base-commit: 24d479d26b25bce5faea3ddd9fa8f3a6c3129ea7
-- 
2.52.0

On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
> This allows to build the kernel with CONFIG_VT enabled, and choose
> on the kernel command line to enable it or not.

This says what is happening, but not why?

> Add vt.enable=1 to force enable, or vt.enable=0 to force disable.

Why are we using a 1990's technology for a new feature?  What is this
going to allow to have happen?  Who needs/wants this?  Who will use it?
For what?

> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
> ---
>  drivers/tty/Kconfig | 13 +++++++++++++
>  drivers/tty/vt/vt.c |  5 +++++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> index 149f3d53b7608..2b94c2710687a 100644
> --- a/drivers/tty/Kconfig
> +++ b/drivers/tty/Kconfig
> @@ -41,6 +41,19 @@ config VT
>  	  If unsure, say Y, or else you won't be able to do much with your new
>  	  shiny Linux system :-)
>  
> +config VT_ENABLE
> +	depends on VT
> +	default y
> +	bool "enable VT terminal" if EXPERT

So no one will ever really use this config option?

And you are doing 2 things in this patch, not just one, unlike what the
changelog said :(

thanks,

greg k-h

On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
>> This allows to build the kernel with CONFIG_VT enabled, and choose
>> on the kernel command line to enable it or not.
> 
> This says what is happening, but not why?
> 
>> Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
> 
> Why are we using a 1990's technology for a new feature?  What is this
> going to allow to have happen?  Who needs/wants this?  Who will use it?
> For what?

The goal is to ease the transition to disable CONFIG_VT.

So if this is merged, you can boot without VT on any Linux distribution, 
without rebuilding the kernel.

This option will also allow a distribution to disable VT by default, but 
users that really wants this can enable it on the kernel command line, 
without rebuilding the kernel.

It will also avoid hacky solution in userspace like this:
https://overhead.neocities.org/blog/systemd-logind-seat/#very-hacky-solutions


> 
>> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
>> ---
>>   drivers/tty/Kconfig | 13 +++++++++++++
>>   drivers/tty/vt/vt.c |  5 +++++
>>   2 files changed, 18 insertions(+)
>>
>> diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
>> index 149f3d53b7608..2b94c2710687a 100644
>> --- a/drivers/tty/Kconfig
>> +++ b/drivers/tty/Kconfig
>> @@ -41,6 +41,19 @@ config VT
>>   	  If unsure, say Y, or else you won't be able to do much with your new
>>   	  shiny Linux system :-)
>>   
>> +config VT_ENABLE
>> +	depends on VT
>> +	default y
>> +	bool "enable VT terminal" if EXPERT
> 
> So no one will ever really use this config option?
> 
> And you are doing 2 things in this patch, not just one, unlike what the
> changelog said :(

I can split that in two if you prefer.

Adding a module parameter, and adding a Kconfig option, to choose the 
default for this module parameter.

> 
> thanks,
> 
> greg k-h
> 

-- 

Jocelyn

On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
> On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
> > On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
> > > This allows to build the kernel with CONFIG_VT enabled, and choose
> > > on the kernel command line to enable it or not.
> > 
> > This says what is happening, but not why?
> > 
> > > Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
> > 
> > Why are we using a 1990's technology for a new feature?  What is this
> > going to allow to have happen?  Who needs/wants this?  Who will use it?
> > For what?
> 
> The goal is to ease the transition to disable CONFIG_VT.
> 
> So if this is merged, you can boot without VT on any Linux distribution,
> without rebuilding the kernel.

But that's a distro-specific thing, the distro should be enabling or
disabling the option as it needs, it should not be a user-configurable
boot-time selection option as userspace depends entirely on this either
being there or not.  Why would you have a kernel with both options but
userspace without that?

> This option will also allow a distribution to disable VT by default, but
> users that really wants this can enable it on the kernel command line,
> without rebuilding the kernel.

Why would a user want that?  If a user really wants it enabled, why
would userspace even still work and why would they want to not rebuild
the kernel?

> It will also avoid hacky solution in userspace like this:
> https://overhead.neocities.org/blog/systemd-logind-seat/#very-hacky-solutions

Surely that can't be the only way, why can't userspace just handle this
"properly" if it wants to?

> > > Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
> > > ---
> > >   drivers/tty/Kconfig | 13 +++++++++++++
> > >   drivers/tty/vt/vt.c |  5 +++++
> > >   2 files changed, 18 insertions(+)
> > > 
> > > diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> > > index 149f3d53b7608..2b94c2710687a 100644
> > > --- a/drivers/tty/Kconfig
> > > +++ b/drivers/tty/Kconfig
> > > @@ -41,6 +41,19 @@ config VT
> > >   	  If unsure, say Y, or else you won't be able to do much with your new
> > >   	  shiny Linux system :-)
> > > +config VT_ENABLE
> > > +	depends on VT
> > > +	default y
> > > +	bool "enable VT terminal" if EXPERT
> > 
> > So no one will ever really use this config option?
> > 
> > And you are doing 2 things in this patch, not just one, unlike what the
> > changelog said :(
> 
> I can split that in two if you prefer.

I'm objecting to the patch doing something other than what the changelog
describes, which as you know is not a good thing.

> Adding a module parameter, and adding a Kconfig option, to choose the
> default for this module parameter.

I really don't like adding new module parameters that we are going to
have to now support for forever.  Why not just rely on the config option
being there or not as-is?  That's why we allowed it to be turned off at
all, because userspace was going to be moved to not need it anymore.
Why would we want to support "both" at the same time in the kernel?

thanks,

greg k-h

On 26/01/2026 11:20, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
>> On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
>>> On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
>>>> This allows to build the kernel with CONFIG_VT enabled, and choose
>>>> on the kernel command line to enable it or not.
>>>
>>> This says what is happening, but not why?
>>>
>>>> Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
>>>
>>> Why are we using a 1990's technology for a new feature?  What is this
>>> going to allow to have happen?  Who needs/wants this?  Who will use it?
>>> For what?
>>
>> The goal is to ease the transition to disable CONFIG_VT.
>>
>> So if this is merged, you can boot without VT on any Linux distribution,
>> without rebuilding the kernel.
> 
> But that's a distro-specific thing, the distro should be enabling or
> disabling the option as it needs, it should not be a user-configurable
> boot-time selection option as userspace depends entirely on this either
> being there or not.  Why would you have a kernel with both options but
> userspace without that?

Actually the userspace side works with or without VT, at least with 
Fedora, I've my Gnome session in both cases.

> 
>> This option will also allow a distribution to disable VT by default, but
>> users that really wants this can enable it on the kernel command line,
>> without rebuilding the kernel.
> 
> Why would a user want that?  If a user really wants it enabled, why
> would userspace even still work and why would they want to not rebuild
> the kernel?

Rebuilding kernel is not user-friendly, changing a kernel cmdline 
parameter is much easier.

> 
>> It will also avoid hacky solution in userspace like this:
>> https://overhead.neocities.org/blog/systemd-logind-seat/#very-hacky-solutions
> 
> Surely that can't be the only way, why can't userspace just handle this
> "properly" if it wants to?

There is no way for userspace to disable the tty that are running in the 
kernel. It can at best ignore them, but for me it's not a proper solution.
> 
>>>> Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
>>>> ---
>>>>    drivers/tty/Kconfig | 13 +++++++++++++
>>>>    drivers/tty/vt/vt.c |  5 +++++
>>>>    2 files changed, 18 insertions(+)
>>>>
>>>> diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
>>>> index 149f3d53b7608..2b94c2710687a 100644
>>>> --- a/drivers/tty/Kconfig
>>>> +++ b/drivers/tty/Kconfig
>>>> @@ -41,6 +41,19 @@ config VT
>>>>    	  If unsure, say Y, or else you won't be able to do much with your new
>>>>    	  shiny Linux system :-)
>>>> +config VT_ENABLE
>>>> +	depends on VT
>>>> +	default y
>>>> +	bool "enable VT terminal" if EXPERT
>>>
>>> So no one will ever really use this config option?
>>>
>>> And you are doing 2 things in this patch, not just one, unlike what the
>>> changelog said :(
>>
>> I can split that in two if you prefer.
> 
> I'm objecting to the patch doing something other than what the changelog
> describes, which as you know is not a good thing.
> 

ok, I can fix that in a v2.

>> Adding a module parameter, and adding a Kconfig option, to choose the
>> default for this module parameter.
> 
> I really don't like adding new module parameters that we are going to
> have to now support for forever.  Why not just rely on the config option
> being there or not as-is?  That's why we allowed it to be turned off at
> all, because userspace was going to be moved to not need it anymore.
> Why would we want to support "both" at the same time in the kernel?
> 

This parameter is there to ease the transition to VT-less system. So by 
maintaining this few lines of code, it will be possible to deprecate the 
whole VT in the future.

If a module parameter is not a good solution, I'm open to any solution 
that can disable vt from the kernel command line (userspace init runs to 
late to disable vt).

> thanks,
> 
> greg k-h
>

On Mon, Jan 26, 2026 at 11:48:50AM +0100, Jocelyn Falempe wrote:
> On 26/01/2026 11:20, Greg Kroah-Hartman wrote:
> > On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
> > > On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
> > > > On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
> > > > > This allows to build the kernel with CONFIG_VT enabled, and choose
> > > > > on the kernel command line to enable it or not.
> > > > 
> > > > This says what is happening, but not why?
> > > > 
> > > > > Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
> > > > 
> > > > Why are we using a 1990's technology for a new feature?  What is this
> > > > going to allow to have happen?  Who needs/wants this?  Who will use it?
> > > > For what?
> > > 
> > > The goal is to ease the transition to disable CONFIG_VT.
> > > 
> > > So if this is merged, you can boot without VT on any Linux distribution,
> > > without rebuilding the kernel.
> > 
> > But that's a distro-specific thing, the distro should be enabling or
> > disabling the option as it needs, it should not be a user-configurable
> > boot-time selection option as userspace depends entirely on this either
> > being there or not.  Why would you have a kernel with both options but
> > userspace without that?
> 
> Actually the userspace side works with or without VT, at least with Fedora,
> I've my Gnome session in both cases.

Great!  Then why is this even needed?  Who wants such a "let's not make
up our mind until we boot" type of system?

Given that traditionally the command line is a "secure" thing, that is
locked down by distros and orginizations, who would ever be able to be
changing this type of thing?  Who would want to support userspace that
handles both at the same time?

I don't see the issue here, if a distro doesn't want to support VT, then
disable it in the kernel and all is good.  If they do want to support
it, than enable it.  Don't do both :)

thanks,

greg k-h

On 26/01/2026 11:59, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 11:48:50AM +0100, Jocelyn Falempe wrote:
>> On 26/01/2026 11:20, Greg Kroah-Hartman wrote:
>>> On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
>>>> On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
>>>>> On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
>>>>>> This allows to build the kernel with CONFIG_VT enabled, and choose
>>>>>> on the kernel command line to enable it or not.
>>>>>
>>>>> This says what is happening, but not why?
>>>>>
>>>>>> Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
>>>>>
>>>>> Why are we using a 1990's technology for a new feature?  What is this
>>>>> going to allow to have happen?  Who needs/wants this?  Who will use it?
>>>>> For what?
>>>>
>>>> The goal is to ease the transition to disable CONFIG_VT.
>>>>
>>>> So if this is merged, you can boot without VT on any Linux distribution,
>>>> without rebuilding the kernel.
>>>
>>> But that's a distro-specific thing, the distro should be enabling or
>>> disabling the option as it needs, it should not be a user-configurable
>>> boot-time selection option as userspace depends entirely on this either
>>> being there or not.  Why would you have a kernel with both options but
>>> userspace without that?
>>
>> Actually the userspace side works with or without VT, at least with Fedora,
>> I've my Gnome session in both cases.
> 
> Great!  Then why is this even needed?  Who wants such a "let's not make
> up our mind until we boot" type of system?
> 
> Given that traditionally the command line is a "secure" thing, that is
> locked down by distros and orginizations, who would ever be able to be
> changing this type of thing?  Who would want to support userspace that
> handles both at the same time?
> 
> I don't see the issue here, if a distro doesn't want to support VT, then
> disable it in the kernel and all is good.  If they do want to support
> it, than enable it.  Don't do both :)

Maybe the real issue is that VT cannot be built as a module.
That way the userspace would be able to load it only if it needs it.

That's probably more complex than my 3 lines patch, but I can try.
Would you prefer it that way?


> 
> thanks,
> 
> greg k-h
>

On Mon, Jan 26, 2026 at 01:26:34PM +0100, Jocelyn Falempe wrote:
> On 26/01/2026 11:59, Greg Kroah-Hartman wrote:
> > On Mon, Jan 26, 2026 at 11:48:50AM +0100, Jocelyn Falempe wrote:
> > > On 26/01/2026 11:20, Greg Kroah-Hartman wrote:
> > > > On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
> > > > > On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
> > > > > > On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
> > > > > > > This allows to build the kernel with CONFIG_VT enabled, and choose
> > > > > > > on the kernel command line to enable it or not.
> > > > > > 
> > > > > > This says what is happening, but not why?
> > > > > > 
> > > > > > > Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
> > > > > > 
> > > > > > Why are we using a 1990's technology for a new feature?  What is this
> > > > > > going to allow to have happen?  Who needs/wants this?  Who will use it?
> > > > > > For what?
> > > > > 
> > > > > The goal is to ease the transition to disable CONFIG_VT.
> > > > > 
> > > > > So if this is merged, you can boot without VT on any Linux distribution,
> > > > > without rebuilding the kernel.
> > > > 
> > > > But that's a distro-specific thing, the distro should be enabling or
> > > > disabling the option as it needs, it should not be a user-configurable
> > > > boot-time selection option as userspace depends entirely on this either
> > > > being there or not.  Why would you have a kernel with both options but
> > > > userspace without that?
> > > 
> > > Actually the userspace side works with or without VT, at least with Fedora,
> > > I've my Gnome session in both cases.
> > 
> > Great!  Then why is this even needed?  Who wants such a "let's not make
> > up our mind until we boot" type of system?
> > 
> > Given that traditionally the command line is a "secure" thing, that is
> > locked down by distros and orginizations, who would ever be able to be
> > changing this type of thing?  Who would want to support userspace that
> > handles both at the same time?
> > 
> > I don't see the issue here, if a distro doesn't want to support VT, then
> > disable it in the kernel and all is good.  If they do want to support
> > it, than enable it.  Don't do both :)
> 
> Maybe the real issue is that VT cannot be built as a module.
> That way the userspace would be able to load it only if it needs it.
> 
> That's probably more complex than my 3 lines patch, but I can try.
> Would you prefer it that way?

If that would make it simpler for a distro to handle this, perhaps.  Try
it and see, I think the last time this came up, unwinding this into a
module just wasn't possible, but that might have been a long time ago, I
can't recall.

But again, why wouldn't a distro pick a "this is what we are going to
support" line and stick with it?  Why would they want to support both?

thanks,

greg k-h

On 26/01/2026 13:46, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 01:26:34PM +0100, Jocelyn Falempe wrote:
>> On 26/01/2026 11:59, Greg Kroah-Hartman wrote:
>>> On Mon, Jan 26, 2026 at 11:48:50AM +0100, Jocelyn Falempe wrote:
>>>> On 26/01/2026 11:20, Greg Kroah-Hartman wrote:
>>>>> On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
>>>>>> On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
>>>>>>> On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
>>>>>>>> This allows to build the kernel with CONFIG_VT enabled, and choose
>>>>>>>> on the kernel command line to enable it or not.
>>>>>>>
>>>>>>> This says what is happening, but not why?
>>>>>>>
>>>>>>>> Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
>>>>>>>
>>>>>>> Why are we using a 1990's technology for a new feature?  What is this
>>>>>>> going to allow to have happen?  Who needs/wants this?  Who will use it?
>>>>>>> For what?
>>>>>>
>>>>>> The goal is to ease the transition to disable CONFIG_VT.
>>>>>>
>>>>>> So if this is merged, you can boot without VT on any Linux distribution,
>>>>>> without rebuilding the kernel.
>>>>>
>>>>> But that's a distro-specific thing, the distro should be enabling or
>>>>> disabling the option as it needs, it should not be a user-configurable
>>>>> boot-time selection option as userspace depends entirely on this either
>>>>> being there or not.  Why would you have a kernel with both options but
>>>>> userspace without that?
>>>>
>>>> Actually the userspace side works with or without VT, at least with Fedora,
>>>> I've my Gnome session in both cases.
>>>
>>> Great!  Then why is this even needed?  Who wants such a "let's not make
>>> up our mind until we boot" type of system?
>>>
>>> Given that traditionally the command line is a "secure" thing, that is
>>> locked down by distros and orginizations, who would ever be able to be
>>> changing this type of thing?  Who would want to support userspace that
>>> handles both at the same time?
>>>
>>> I don't see the issue here, if a distro doesn't want to support VT, then
>>> disable it in the kernel and all is good.  If they do want to support
>>> it, than enable it.  Don't do both :)
>>
>> Maybe the real issue is that VT cannot be built as a module.
>> That way the userspace would be able to load it only if it needs it.
>>
>> That's probably more complex than my 3 lines patch, but I can try.
>> Would you prefer it that way?
> 
> If that would make it simpler for a distro to handle this, perhaps.  Try
> it and see, I think the last time this came up, unwinding this into a
> module just wasn't possible, but that might have been a long time ago, I
> can't recall.
> 
> But again, why wouldn't a distro pick a "this is what we are going to
> support" line and stick with it?  Why would they want to support both?
> 

It's all about the transition. Talks about VT-less system started in 
2012, but since then no major desktop Linux distribution have done it.
I think that one of the reason, is that if you switch off VT, of course 
some users will complain, as it has a lot of implications.
Telling them to go rebuild their kernel is not good. Telling them to run 
grubby to change the kernel command line until they find alternative for 
their use case is better. They can experiment and do the switch when 
they are ready.
Really it's nothing more than that.
I don't think a distribution will want to maintain VT and noVT for a 
long time.

Thanks,

-- 

Jocelyn


> thanks,
> 
> greg k-h
>

On Mon, Jan 26, 2026 at 02:05:36PM +0100, Jocelyn Falempe wrote:
> On 26/01/2026 13:46, Greg Kroah-Hartman wrote:
> > On Mon, Jan 26, 2026 at 01:26:34PM +0100, Jocelyn Falempe wrote:
> > > On 26/01/2026 11:59, Greg Kroah-Hartman wrote:
> > > > On Mon, Jan 26, 2026 at 11:48:50AM +0100, Jocelyn Falempe wrote:
> > > > > On 26/01/2026 11:20, Greg Kroah-Hartman wrote:
> > > > > > On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
> > > > > > > On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
> > > > > > > > On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
> > > > > > > > > This allows to build the kernel with CONFIG_VT enabled, and choose
> > > > > > > > > on the kernel command line to enable it or not.
> > > > > > > > 
> > > > > > > > This says what is happening, but not why?
> > > > > > > > 
> > > > > > > > > Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
> > > > > > > > 
> > > > > > > > Why are we using a 1990's technology for a new feature?  What is this
> > > > > > > > going to allow to have happen?  Who needs/wants this?  Who will use it?
> > > > > > > > For what?
> > > > > > > 
> > > > > > > The goal is to ease the transition to disable CONFIG_VT.
> > > > > > > 
> > > > > > > So if this is merged, you can boot without VT on any Linux distribution,
> > > > > > > without rebuilding the kernel.
> > > > > > 
> > > > > > But that's a distro-specific thing, the distro should be enabling or
> > > > > > disabling the option as it needs, it should not be a user-configurable
> > > > > > boot-time selection option as userspace depends entirely on this either
> > > > > > being there or not.  Why would you have a kernel with both options but
> > > > > > userspace without that?
> > > > > 
> > > > > Actually the userspace side works with or without VT, at least with Fedora,
> > > > > I've my Gnome session in both cases.
> > > > 
> > > > Great!  Then why is this even needed?  Who wants such a "let's not make
> > > > up our mind until we boot" type of system?
> > > > 
> > > > Given that traditionally the command line is a "secure" thing, that is
> > > > locked down by distros and orginizations, who would ever be able to be
> > > > changing this type of thing?  Who would want to support userspace that
> > > > handles both at the same time?
> > > > 
> > > > I don't see the issue here, if a distro doesn't want to support VT, then
> > > > disable it in the kernel and all is good.  If they do want to support
> > > > it, than enable it.  Don't do both :)
> > > 
> > > Maybe the real issue is that VT cannot be built as a module.
> > > That way the userspace would be able to load it only if it needs it.
> > > 
> > > That's probably more complex than my 3 lines patch, but I can try.
> > > Would you prefer it that way?
> > 
> > If that would make it simpler for a distro to handle this, perhaps.  Try
> > it and see, I think the last time this came up, unwinding this into a
> > module just wasn't possible, but that might have been a long time ago, I
> > can't recall.
> > 
> > But again, why wouldn't a distro pick a "this is what we are going to
> > support" line and stick with it?  Why would they want to support both?
> > 
> 
> It's all about the transition. Talks about VT-less system started in 2012,
> but since then no major desktop Linux distribution have done it.

Then perhaps it's not really ever going to happen if no one actually
does the work and wants their distro to change to not have it.

> I think that one of the reason, is that if you switch off VT, of course some
> users will complain, as it has a lot of implications.

Again, that's a distro's policy decision to make, don't force the kernel
to support a wishy-washy distro's decision :)

> Telling them to go rebuild their kernel is not good.

Agreed, this is a policy decision a distro needs to make.

> Telling them to run
> grubby to change the kernel command line until they find alternative for
> their use case is better. They can experiment and do the switch when they
> are ready.
> Really it's nothing more than that.

Again, policy decision that a distro needs to make.

> I don't think a distribution will want to maintain VT and noVT for a long
> time.

Please define "long time" given that no distro has even done this yet?

thanks,

greg k-h

On 26/01/2026 15:36, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 02:05:36PM +0100, Jocelyn Falempe wrote:
>> On 26/01/2026 13:46, Greg Kroah-Hartman wrote:
>>> On Mon, Jan 26, 2026 at 01:26:34PM +0100, Jocelyn Falempe wrote:
>>>> On 26/01/2026 11:59, Greg Kroah-Hartman wrote:
>>>>> On Mon, Jan 26, 2026 at 11:48:50AM +0100, Jocelyn Falempe wrote:
>>>>>> On 26/01/2026 11:20, Greg Kroah-Hartman wrote:
>>>>>>> On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
>>>>>>>> On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
>>>>>>>>> On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
>>>>>>>>>> This allows to build the kernel with CONFIG_VT enabled, and choose
>>>>>>>>>> on the kernel command line to enable it or not.
>>>>>>>>>
>>>>>>>>> This says what is happening, but not why?
>>>>>>>>>
>>>>>>>>>> Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
>>>>>>>>>
>>>>>>>>> Why are we using a 1990's technology for a new feature?  What is this
>>>>>>>>> going to allow to have happen?  Who needs/wants this?  Who will use it?
>>>>>>>>> For what?
>>>>>>>>
>>>>>>>> The goal is to ease the transition to disable CONFIG_VT.
>>>>>>>>
>>>>>>>> So if this is merged, you can boot without VT on any Linux distribution,
>>>>>>>> without rebuilding the kernel.
>>>>>>>
>>>>>>> But that's a distro-specific thing, the distro should be enabling or
>>>>>>> disabling the option as it needs, it should not be a user-configurable
>>>>>>> boot-time selection option as userspace depends entirely on this either
>>>>>>> being there or not.  Why would you have a kernel with both options but
>>>>>>> userspace without that?
>>>>>>
>>>>>> Actually the userspace side works with or without VT, at least with Fedora,
>>>>>> I've my Gnome session in both cases.
>>>>>
>>>>> Great!  Then why is this even needed?  Who wants such a "let's not make
>>>>> up our mind until we boot" type of system?
>>>>>
>>>>> Given that traditionally the command line is a "secure" thing, that is
>>>>> locked down by distros and orginizations, who would ever be able to be
>>>>> changing this type of thing?  Who would want to support userspace that
>>>>> handles both at the same time?
>>>>>
>>>>> I don't see the issue here, if a distro doesn't want to support VT, then
>>>>> disable it in the kernel and all is good.  If they do want to support
>>>>> it, than enable it.  Don't do both :)
>>>>
>>>> Maybe the real issue is that VT cannot be built as a module.
>>>> That way the userspace would be able to load it only if it needs it.
>>>>
>>>> That's probably more complex than my 3 lines patch, but I can try.
>>>> Would you prefer it that way?
>>>
>>> If that would make it simpler for a distro to handle this, perhaps.  Try
>>> it and see, I think the last time this came up, unwinding this into a
>>> module just wasn't possible, but that might have been a long time ago, I
>>> can't recall.
>>>
>>> But again, why wouldn't a distro pick a "this is what we are going to
>>> support" line and stick with it?  Why would they want to support both?
>>>
>>
>> It's all about the transition. Talks about VT-less system started in 2012,
>> but since then no major desktop Linux distribution have done it.
> 
> Then perhaps it's not really ever going to happen if no one actually
> does the work and wants their distro to change to not have it.

To give some contexts, I proposed to switch to kmscon for Fedora 44, so 
once we are there, it will be feasible to switch off VT, in 1 or 2 
years. But the requirement to rebuild the kernel, makes it painful to 
test, and much harder to get accepted.

>> I think that one of the reason, is that if you switch off VT, of course some
>> users will complain, as it has a lot of implications.
> 
> Again, that's a distro's policy decision to make, don't force the kernel
> to support a wishy-washy distro's decision :)

Agreed, I can also keep this patch as downstream, if you think it's 
better that way. But I though it may interest other distributions as well.

> 
>> Telling them to go rebuild their kernel is not good.
> 
> Agreed, this is a policy decision a distro needs to make.
> 
>> Telling them to run
>> grubby to change the kernel command line until they find alternative for
>> their use case is better. They can experiment and do the switch when they
>> are ready.
>> Really it's nothing more than that.
> 
> Again, policy decision that a distro needs to make.
> 
>> I don't think a distribution will want to maintain VT and noVT for a long
>> time.
> 
> Please define "long time" given that no distro has even done this yet?

I hope it won't get longer than 1 or 2 year.

> 
> thanks,
> 
> greg k-h
>

On Mon, 26 Jan 2026, Greg Kroah-Hartman wrote:

> On Mon, Jan 26, 2026 at 02:05:36PM +0100, Jocelyn Falempe wrote:
> > I think that one of the reason, is that if you switch off VT, of course some
> > users will complain, as it has a lot of implications.
> 
> Again, that's a distro's policy decision to make, don't force the kernel
> to support a wishy-washy distro's decision :)

As a daily VT user for my primary Linux interface due to accessibility 
needs, I'm baffled by the idea of distributions removing this support. 

Of course this has lots of implications. For many users with 
disabilities, VT is not optional - it's the only _fully_ usable 
interface.

Consider this my official objection. Just don't do that.


Nicolas

On 26/01/2026 18:24, Nicolas Pitre wrote:
> On Mon, 26 Jan 2026, Greg Kroah-Hartman wrote:
> 
>> On Mon, Jan 26, 2026 at 02:05:36PM +0100, Jocelyn Falempe wrote:
>>> I think that one of the reason, is that if you switch off VT, of course some
>>> users will complain, as it has a lot of implications.
>>
>> Again, that's a distro's policy decision to make, don't force the kernel
>> to support a wishy-washy distro's decision :)
> 
> As a daily VT user for my primary Linux interface due to accessibility
> needs, I'm baffled by the idea of distributions removing this support.
> 
> Of course this has lots of implications. For many users with
> disabilities, VT is not optional - it's the only _fully_ usable
> interface.
> 
> Consider this my official objection. Just don't do that.

That patch is clearly for people like you, that will need more time to 
adapt their tools and workflow to a VT-less system.
It's also less practical to develop alternative, if you need to rebuild 
your kernel to disable VT.
Regarding accessibility, I don't see any technical reason why a VT-less 
system would be less efficient that what is currently available with VT.

-- 

Jocelyn

> 
> 
> Nicolas
>

On Mon, Jan 26, 2026 at 11:20:21AM +0100, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
> > On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
> > > On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
> > > > This allows to build the kernel with CONFIG_VT enabled, and choose
> > > > on the kernel command line to enable it or not.
> > > 
> > > This says what is happening, but not why?
> > > 
> > > > Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
> > > 
> > > Why are we using a 1990's technology for a new feature?  What is this
> > > going to allow to have happen?  Who needs/wants this?  Who will use it?
> > > For what?
> > 
> > The goal is to ease the transition to disable CONFIG_VT.
> > 
> > So if this is merged, you can boot without VT on any Linux distribution,
> > without rebuilding the kernel.
> 
> But that's a distro-specific thing, the distro should be enabling or
> disabling the option as it needs, it should not be a user-configurable
> boot-time selection option as userspace depends entirely on this either
> being there or not.  Why would you have a kernel with both options but
> userspace without that?

And to follow-up on this, if a distro wanted to support this, why not
just provide 2 different kernel images?  One with this enabled and one
without?  It's up to the distro to support such a thing, not the kernel
community, right?

thanks,

greg k-h

On 26/01/2026 11:30, Greg Kroah-Hartman wrote:
> On Mon, Jan 26, 2026 at 11:20:21AM +0100, Greg Kroah-Hartman wrote:
>> On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
>>> On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
>>>> On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
>>>>> This allows to build the kernel with CONFIG_VT enabled, and choose
>>>>> on the kernel command line to enable it or not.
>>>>
>>>> This says what is happening, but not why?
>>>>
>>>>> Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
>>>>
>>>> Why are we using a 1990's technology for a new feature?  What is this
>>>> going to allow to have happen?  Who needs/wants this?  Who will use it?
>>>> For what?
>>>
>>> The goal is to ease the transition to disable CONFIG_VT.
>>>
>>> So if this is merged, you can boot without VT on any Linux distribution,
>>> without rebuilding the kernel.
>>
>> But that's a distro-specific thing, the distro should be enabling or
>> disabling the option as it needs, it should not be a user-configurable
>> boot-time selection option as userspace depends entirely on this either
>> being there or not.  Why would you have a kernel with both options but
>> userspace without that?
> 
> And to follow-up on this, if a distro wanted to support this, why not
> just provide 2 different kernel images?  One with this enabled and one
> without?  It's up to the distro to support such a thing, not the kernel
> community, right?

That's clearly not an option, they will prefer to keep VT enabled 
forever than adding yet another kernel package. And for distributions 
that already have kernel and kernel-rt, that means maintaining 4 kernels 
for all combination.

> 
> thanks,
> 
> greg k-h
>

On Mon, Jan 26, 2026 at 11:49:45AM +0100, Jocelyn Falempe wrote:
> On 26/01/2026 11:30, Greg Kroah-Hartman wrote:
> > On Mon, Jan 26, 2026 at 11:20:21AM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Jan 26, 2026 at 10:43:35AM +0100, Jocelyn Falempe wrote:
> > > > On 26/01/2026 10:33, Greg Kroah-Hartman wrote:
> > > > > On Mon, Jan 26, 2026 at 10:21:50AM +0100, Jocelyn Falempe wrote:
> > > > > > This allows to build the kernel with CONFIG_VT enabled, and choose
> > > > > > on the kernel command line to enable it or not.
> > > > > 
> > > > > This says what is happening, but not why?
> > > > > 
> > > > > > Add vt.enable=1 to force enable, or vt.enable=0 to force disable.
> > > > > 
> > > > > Why are we using a 1990's technology for a new feature?  What is this
> > > > > going to allow to have happen?  Who needs/wants this?  Who will use it?
> > > > > For what?
> > > > 
> > > > The goal is to ease the transition to disable CONFIG_VT.
> > > > 
> > > > So if this is merged, you can boot without VT on any Linux distribution,
> > > > without rebuilding the kernel.
> > > 
> > > But that's a distro-specific thing, the distro should be enabling or
> > > disabling the option as it needs, it should not be a user-configurable
> > > boot-time selection option as userspace depends entirely on this either
> > > being there or not.  Why would you have a kernel with both options but
> > > userspace without that?
> > 
> > And to follow-up on this, if a distro wanted to support this, why not
> > just provide 2 different kernel images?  One with this enabled and one
> > without?  It's up to the distro to support such a thing, not the kernel
> > community, right?
> 
> That's clearly not an option, they will prefer to keep VT enabled forever
> than adding yet another kernel package.

But that's a distro's choice to make, why are you forcing this onto the
kernel?  Either a distro wants to support a userspace with VT enabled,
or not.  So then choose the kernel option you wish to have here and away
you go!

> And for distributions that already have kernel and kernel-rt, that
> means maintaining 4 kernels for all combination.

Again, that's a distro choice, you are now forcing us to maintain the
option due to the lack of an agreement in your organization :)

thanks,

greg k-h