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.

Ted