From: Ted Bullock Subject: Re: sparc64: X and getty sharing raw keyboard input To: Theo de Raadt Cc: Mark Kettenis , tech@openbsd.org Date: Tue, 13 Oct 2026 22:36:09 -0600 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 wrote: > > Ted Bullock 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