From: Mark Kettenis Subject: Re: sparc64: X and getty sharing raw keyboard input To: Ted Bullock Cc: tech@openbsd.org Date: Tue, 13 Oct 2026 21:38:35 +0200 > From: Ted Bullock > Date: Tue, 13 Oct 2026 13:11:00 -0600 > > Hi Mark, > > 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. Well, this works just fine on other architectures, at lest when the glass console is ttyC0. Multi-GPU systems have always been tricky, but at some point I made changes to x86 to make sure the wsdisplay that attaches to the console/primary GPU always ends up as wsdisplay0. Currently sparc64 doesn't have that, but what might work is to do something like: radeondrm* at pci? # ATI Radeon DRM driver drm0 at radeondrm? console 1 drm* at radeondrm? wsdisplay0 at radeondrm? console 1 wsdisplay* at radeondrm? mux -1 in the kernel config file. This might need some changes for machfb(4) as well to keep it from attaching wsdisplay0 if it isn't the console.