> From: Ted Bullock <tbullock@comlore.com>
> 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.