[HEAD] Keyboard system lock-out with latest in Ubuntu 14.04

[Edward-san]

It was posted here, but it's possible to reproduce this also in zdoom.

Quoting the thread:

This is a nasty one, and very hard to track down. After playing for a while and pulling down the console with ` a few times, keyboard and mouse input will stop being accepted, which means I can't quit the application, alt-tab out and kill the process, or much of anything else. Ctrl-Alt-F1/F2/F3 etc to bring up text mode terminals works, but no keyboard input is accepted beyond that. I just have to hard-restart the machine.

I'm running from git commit 5a0f1a882a5b1e10c31db0bcdadf5703abbb3bfc, though I've been seeing this for the past couple of weeks from a few previous commits. Nothing non-standard about my setup really, Ubuntu 14.04 64-bit with an Nvidia GTX 660 graphics card. I've never been able to get this bug to occur in ZDoom latest; it seems to be GZDoom-specific.

I realize I don't have a log or debugger access when the bug happens, but please let me know what kind of info I could maybe provide to help track this down, as well as any more specific repro advice than what I've given.

I'm afraid there isn't much that can be done on my side. I don't use Linux so I can't test it. You need to be very lucky to find someone who also experiences this and can debug it. It's probably related to some driver issue because aside from initializing OpenGL the code is exactly the same as in ZDoom.

I noticed this recently, but my mouse is not locked, so I can click the 'exit' button to close. I can reproduce this also in zandronum, so it's hard to tell if it's gzdoom or the sdl package ... I have to find a way to debug this...

[VGA]

Check if it's happening in software mode

[Edward-san]

It happens in software, too.

[Leonard2]

It happened on zandronum's opengl renderer for me too.
However I don't have ubuntu installed anymore so I can't test..
I recall that it only happened after I used the chat key or opened the console and that the only keys it accepted were my arrows which printed something like "^T1"
Also if I intensively spammed my keyboard it would sometimes pickup the spacebar input (join the game in zandronum) but that's it and I was basically forced to quit zandronum.exe

[Watermelon]

After typing 3-4 lines of text, it usually locks up and I'm toast (locks up as in keyboard input is completely lost, yet the mouse still works).

Ubuntu is currently unplayable if any typing is involved. Alt tabbing also contributes to random key input loss as well.

[JPL]

Hm, I'm getting this too. Is everyone who's experiencing this using Ubuntu 14.04? I've noticed other X-related bugs in other applications besides ZDoom...

[Watermelon]

Okay I believe I traced this to SDL_PollEvent losing the ability to poll events. Keyboard input is completely lost, yet it seems to still pump events for mouse input. This only happens when I click Esc or 't' which is binded to 'say'. Esc just brings up the menu. The actual bound keys to strafing in game (w/a/s/d) are fine

This completely kills zdoom and all its source ports on linux though. It's reproducible within 10 or so seconds... so it's not like this can just be ignored.

Having to ctrl + alt + f# to my terminal to kill zdoom is a major pain in the ass -- you can't even save or anything, you're just locked out.

EDIT:
Interesting, so if I bind 'say' to mouse3 (mouse wheel) it never glitches out. As soon as I go back to 't', then it glitches out pretty quickly after doing 't' + Esc a few times.

====================

EDIT 2:
Odamex does not have this happen and it uses SDL 1.2.15 -- which I think ZDoom does(?)
If so then it's something ZDoom is doing. What, I'm not sure exactly.

[Blzut3]

It's reproducible within 10 or so seconds... so it's not like this can just be ignored.

Unless someone experiencing the problem finds a fix, it definitely can be ignored. It still works just fine here on 14.04.

[Nightfall]

It appears to also happen when the console is brought up (the most common way of this happening to me). So the lock-up can happen when the input mode is changed? Perhaps Ubuntu 14.10 will resolve this with an updated SDL?

[Watermelon]

It's reproducible within 10 or so seconds... so it's not like this can just be ignored.

Unless someone experiencing the problem finds a fix, it definitely can be ignored. It still works just fine here on 14.04.

How did you install Ubuntu 14.04? Was it just a fresh install without any sudo apt-get'ing updates? I'm going to post on the SDL forums and see if I can gather anything, but so far I'm most likely going to have to just do any kind of doom code development on Windows since having to go to tty and killing it also screws up the resolution.

This really sucks

[Blzut3]

Both of my active Kubuntu systems are upgrade installs, but I don't know off hand what version I started with. In any case it's stock SDL, locale is en_US.UTF-8.

All I know is I can mash t, pause, esc, and ~ without any issues whatsoever.

[VoidMage]

This kind-of, sort-of sounds like the problem I had back here that got (in a way) solved.

[Watermelon]

This kind-of, sort-of sounds like the problem I had back here that got (in a way) solved.

Awesome, this solves it!

I commented out line 133 (SDL_EnableUnicode(0);) from i_input.cpp on line 133 as of the HEAD revision from this date, and the keyboard never locks up on me.
The game seems to also work fine for me (no apparent bugs), so I'll be doing this for my custom builds.

[Nightfall]

So it turns out that upgrading SDL to the mercurial version does resolve this problem.

[Blzut3]

Closing as [Not ZDoom] as I plan on ditching SDL 1.2 in the near future now that the OS X back end is ready.