From: "Theo de Raadt" Subject: Re: sparc64: X and getty sharing raw keyboard input To: Mark Kettenis Cc: Ted Bullock , tech@openbsd.org Date: Tue, 13 Oct 2026 16:57:33 -0600 Mark Kettenis wrote: > > From: Ted Bullock > > Date: Tue, 13 Oct 2026 09:27:19 -0600 > > Content-Type: text/plain; charset="utf-8" > > > > Hiya folks, > > > > In my pursuit of killing gremlins in sparc64 I made another discovery. > > > > I think I've finally tracked down what was starting the console problem on > > my Sun Blade 100. I was working on the Radeon KMS handoff and testing going > > into and out of X, and occasionally getty would start failing and I would > > lose access to the graphics device from my X session. > > > > With the default keyboard configuration, X and getty are reading from the > > same terminal input queue. X uses /dev/ttyD0, and getty uses /dev/console, > > which forwards to that same terminal. So they are competing for the input, > > rather than each getting a separate copy of keypresses. > > > > X puts the keyboard into raw mode. The number row 3 key then produces the > > scan code 0x04, rather than the character 3. If getty gets that byte > > instead of X, it interprets it as EOT and exits. > > > > I was able to reproduce that by briefly pausing only X's reader and > > pressing the key. The getty trace showed a successful one byte read, > > followed by exit(1). I hadn't killed getty or revoked the console to > > make it happen. Normal typing didn't reliably reproduce it, only when > > I would press 3 and only sometimes at that because sometimes X would > > correctly receive the keypress. > > > > After that exit, the replacement getty failed with login_tty: Operation > > not permitted. Init then kept restarting it and resetting the device > > permissions for the display through fbtab, which explains why some of > > my graphical applications were subsequently reporting permission errors. > > > > Looking back through the history, the old sparc64 X README explicitly > > said to disable console getty when running xdm, and later xenodm. That > > warning was still there before the README was removed in 2020. It didn't > > explain this particular failure, but it clearly described a restriction > > on running the two together. > > > > I can't say which input caused each of the earlier occurrences, since I > > didn't have a trace of their first exit. But this does identify a way that > > ordinary keyboard input can start the problem on sparc machines running x. > > I thought it was worth following up with that explanation, especially after > > the earlier getty error handling discussion. > > This is a known issue and simply not supported. You either have to > > Enable "console" and disable all the other potential console > devices. This means the getty always runs on the console picked by > OpenFirmware, and moves from the glass console to the serial console > when you unplug the kernel. > > or > > Disable "console" and enable all the other potential console > devices. This means that you always have a getty running on all > possible console devices. Yep. There are two ways the console works, it depends upon architecture. On sparc64 and some other architectures "console" is the architectural console. On others, it is a "pointer" to the real console. Playing with sessions will not solve it. The proposed diff just moves the problem forward because it is still the same tty.