Man yeah I see this has been a swamp for a long time.

For my workstation i'm working around it with this which at least
stops getty from breaking like it does for me under the default
configuration.

Section "InputClass"
    Identifier "mykeyboard"
    MatchIsKeyboard "on"
    MatchDriver "kbd"
    Option "Protocol" "wskbd"
    Option "Device" "/dev/wskbd"
EndSection

Would it make sense to use the existing virtual terminal support and
put X on a separate terminal, leaving getty on the console? That seems
like it could address shared input problems while retaining the
existing raw keyboard handling.

I would start with radeon drm, where the driver already has screen
switching operations.

The older framebuffer drivers appear to have more limited screen
support, so I don't think this is appropriate across sparc64, at least
without extra effort. We would also need to account for a serial
console with local X.

How would you feel about that approach? Was there a particular reason
virtual terminals weren’t enabled on sparc64, or some limitation I’m
missing?

On Tue, Oct 13, 2026 at 4:58 PM Theo de Raadt <deraadt@openbsd.org> wrote:
>
> Ted Bullock <tbullock@comlore.com> wrote:
>
> > I'm using the first arrangement you describe. Only console is enabled in
> > /etc/ttys, and there's only one getty running. The individual console
> > devices are disabled, which matches the current sparc64 defaults. My
> > console terminal type is rcons-color rather than sun.
> >
> > The competing readers were X and that one getty, rather than two gettys.
> > With the default standard keyboard protocol, X reads /dev/ttyD0 and getty
> > reads /dev/console, which forwards to the same terminal input queue.
> >
> > Does the restriction also cover X holding the underlying terminal open
> > with this arrangement? I'm trying to understand whether there's another
> > setting needed beyond the current sparc64 defaults. Selecting wskbd for
> > X locally separates the input and addresses the problem on this machine.
>
> You may need to step back to understand this.
>
> On amd64, the "console" is a redirection to some special device.
>
> What is it on sparc64?  Oh. It is not a redirection.  It *IS* a device.



-- 
Ted Bullock <tbullock@comlore.com>