With reasonable reliability, I can cause Oolite to fail to "see" the keyboard at startup: -- see post #7 for a better description of the bug -- see post #16 for a none-too-helpful table of affected (or not) systems -- see post #44 for a workaround to what turned out to be an ibus bug
Quit the game when it's running in a window, not full screen (so that, on restart, it will open in a window rather than full screen).
In very rapid succession: start the game, press F12.
You can now access the menu with the mouse, but not with the keyboard. You can't see anything else on your desktop, as you're in full-screen mode, so I'd recommend quitting the game rather than starting a new one at this point
I think you can cause the same effect mid-game, too, going from minimised to windowed, then F12 to go full screen without a keyboard. I don't know how to use the mouse to quit the game when that happens, so I hope you'll understand that I've not tested this case exhaustively.
Nothing in the logs differentiates normal startup from startup-and-lock-out.
This has been a problem for a while, I think. I'm running the trunk nightly on Ubuntu 14.04 on an x86-64 PC.
Last edited by jh145 on Sat Jun 13, 2015 7:57 pm, edited 4 times in total.
I've tried this on two different Linux systems and can't reproduce it. When do I press F12? When the splash screen shows, when the main window appears or when it's loading up the commander?
Nothing here, either. Could there be some unexpected interaction with the window manager, perhaps, causing the full-screen Oolite to end up as a background window? (But if so, clicking the mouse on it should be clearing that...)
Further experimentation suggests it's the rapid transition between full screen and windowed that's breaking things. In particular, I can leave it on the start screen, go make a coffee, come back and hammer F12 quickly, and after only a few F12 whacks the keyboard will become unresponsive. Perhaps the computer's trying to teach me a lesson.
Here are two easily-reproducible cases, one healthy and one not, that I'm seeing:
waiting happily on full screen ---[rapid F12,F12]---> waiting happily on full screen
waiting happily in windowed mode ---[rapid F12,F12]---> keyboard unresponsive in windowed mode
Here are two further cases that are much harder to reproduce, as you must hit F12 just once and at exactly the right time:
start-up in windowed mode ---[F12 immediately after the splash screen disappears]---> waiting happily on full screen
start-up on full screen ---[F12 immediately after the splash screen disappears]---> keyboard unresponsive in windowed mode
I would guess that some critical initialisation in full screen mode is being interrupted at just the wrong time, leaving the keyboard "uninitialised" when the game subsequently arrives in windowed mode <*gesticulates in confused manner*>
I replicated the case on Ubuntu 14.04 64bit with nVidia 340.76 drivers GTX750Ti card.
Don't try to replicate if you are not at the Main Menu!
It's really easy to replicate.
Start Oolite and at the Main Menu screen start hammering F12, as fast as if you are playing Daley Thompson's Decathlon, until Oolite stops switching between Windowed and Full Screen modes.
You have just lost your keyboard! If you are fast enough it will not even take a second.
If it happens that the last state is Full Screen and you are not at the Main Menu screen, then the only way I have found so far to regain access to the desktop (forget Alt-Tab), is to Ctrl-Alt-F1 (linux terminal mode), logon and kill Oolite. Then Ctrl-Alt-F7 to go back to the desktop session.
If you are at the Main Menu screen, you can just double-click the Exit Game option.
EDIT: Do NOT try it with 1.80!
I managed to brick my desktop session and had to reset (not just kill Oolite) from Ctrl-Alt-F1 terminal screen.
"Any sufficiently advanced information is indistinguishable from noise." [Newman, Lachmann, Moore]
Thanks for confirming. Interesting, too, that you could lock yourself out in full screen mode (is that what you implied? I could only achieve lock-out in windowed mode).
Yes. I have a couple of occurences in Windowed mode and many in Full Screen mode.
It depends on towards which mode you switch when you manage to replicate the case.
I cannot replicate it in Oolite for Windows. (I can already see the face of a_c)
"Any sufficiently advanced information is indistinguishable from noise." [Newman, Lachmann, Moore]
If we've got this on nVidia and Radeon cards, perhaps it's something to do with the generic drivers that sit on top of the hardware-specific stuff. I really don't know how to go about checking this, but shall we see if we can find any diagnostics that separate the good and bad cases?
For starters, here are the OpenGL options from ~/.Oolite/Logs/Latest.log
![[EliteWiki]](/images/elitewikismall.png){kind=small}
New Cargoes
Don't try to replicate if you are not at the Main Menu! 
face of a_c)
