stuck arrow key on zdoom 2.3.0 on linux.

[Guest]

Hello,

I have recently installed zdoom 2.3.0 on Linux Fedora 10.

It mostly works okay, but I have this weird problem that the up/down arrow gets stuck in the menus.
for example I press down arrow, then it will stuck going down all the time. The same problem is with up arrow.

it seems to me that the problem is with menu only. I don't see stuck keys in the game play.

Have anyone seen anything similar? googling for hints did not help at all

[Guest]

to follow-up my last post.

it also happens in console. pretty much any key repeats. for example if I press 'a' it will just repeats infinitely until I press someo other key.

as I said before it does not seems to affect game play in anyway. it is just in menu and console only.

what other information do I need to provide in order to make this report more useful?

[Guest]

this is again me.

for what it is worth I have noticed following code in zdoom-2.3.0/src/m_menu.cpp

Code: Select all

        // [RH] Menu eats all keydown events while active
        return (ev->subtype == EV_GUI_KeyDown);

However I guess it must be something specific to my computer otherwise everyone else would be reporting such an error. Perhaps it is something about Fedora X. Maybe the unicode processing? I do not have good ideas.

[Pinky's ass]

Maybe avoiding triple posting?

[Macil]

He doesn't seem to have an account, so editing isn't really an option for him now

Do older SVN versions work fine? (Note that a lot of them don't compile on linux, so you'll have to jump around a bit.)

[Guest]

pinky's ass,

those are just news flash as I find on new stuff.
for me this is essentially an show-stopper bug as I can't even save game easily.

Agent me,
can you recommend some svn version? This is the first time ever that I use zdoom, so I am newbie here.

For what it is worth, I am using kaiser_6.wad with doom2.wad
kaiser 6 wad -> http://www.doomworld.com/idgames/?id=12369

Like I said it is Linux Fedora 10 system with fmodapi42202linux.tar.gz, everything else is from default rpm repository.

[Macil]

[wiki]Compile ZDoom on Linux[/wiki] points out how to get zdoom from the svn (and compile it, but it would seem that you've got that down). The current revision is 1463 (which is a bit more up-to-date than 2.3.0), so I'd try that first.

[Guest]

nope, it is still in r1463

Code: Select all

/trunk/release/zdoom -nosound -iwad doom2 -file kaiser_6.wad 
ZDoom v2.3.0 - SVN revision 1463 - SDL version
Compiled on Mar  6 2009

M_LoadDefaults: Load system defaults.
W_Init: Init WADfiles.
 adding /home/guest/games/doom/zdoom/trunk/release/zdoom.pk3
 adding /usr/share/doom/doom2.wad (2919 lumps)
 adding kaiser_6.wad (144 lumps)
I_Init: Setting up machine state.
CPU Vendor ID: AuthenticAMD
  Name: AMD Athlon(tm) XP 1800+
  Family 6 (7), Model 6, Stepping 2
  Features: MMX SSE
V_Init: allocate screen.
S_Init: Setting up sound.
ST_Init: Init startup screen.
P_Init: Checking cmd-line parameters...
G_ParseMapInfo: Load map definitions.
S_InitData: Load sound definitions.
Texman.Init: Init texture manager.
ParseTeamInfo: Load team definitions.
LoadActors: Load actor definitions.
R_Init: Init Doom refresh subsystem.
DecalLibrary: Load decals.
Patch installed
M_Init: Init miscellaneous info.
P_Init: Init Playloop state.
ParseSBarInfo: Loading default status bar definition.
ParseSBarInfo: Loading custom status bar definition.
D_CheckNetGame: Checking network game status.
player 1 of 1 (1 nodes)
Resolution: 640 x 480
Playing demo DEMO1
Cannot play non-ZDoom demos.
(They would go out of sync badly.)
Playing demo DEMO2
Cannot play non-ZDoom demos.
(They would go out of sync badly.)
Playing demo DEMO3
Cannot play non-ZDoom demos.
(They would go out of sync badly.)

+MAP01 - The Community is Falling!!! OH NO!!!

[Guest]

for what it is worth I have noticed that it only happens after I load doom2.wad (ie I start or restore saved game). no such problem occurs right after start up.

[Guest]

for what it is worth I have noticed that it only happens after I load doom2.wad (ie I start or restore saved game). no such problem occurs right after start up.

I think I was wrong above. It can start repeating w/out loading game first.

I have added a Print() inside of zdoom-2.3.0/src/m_menu.cpp:M_Responder() and it looks like the M_Responder() gets called repeatedly when some key gets stuck.

Thus it seems to me that in some circumstances the keys does not get eaten like they should be.

I still can't find the place where they are eaten like the comments claim though ought to be eaten.

[Guest]

For what's it worth.

I have determined that theMessagePump() gets called repeatedly. Thus I think that zdoom/trunk/src/sdl/i_input.cpp:SDL_PollEvent (&sev) constantly generates new data as if the key was pressed.

I have SDL-1.2.13-7.fc10.i386 and recommended SDL for zdoom is SDL 1.2.13 so it is not the problem.

As I understand there are on the list other Linux users that run the 2.3.0 without any problems????

[skadoomer]

As I understand there are on the list other Linux users that run the 2.3.0 without any problems????

There are a few other bug topics about controls acting weird in linux. It seems to be a sparse problem that differs based on the users setup, and given the lack of a solid linux developer for zdoom (though there are a few well respected contributors), different things work for different people. What you have is something that works for most of the developers, not for the general population. Since you've tracked the bug this far (and given that you have enough skill to have gotten as far as you have), I recommend getting some input from either of the zdoom developers on this section of code (Graf or Randy) and writing a fix for yourself (if they can't re-produce your problem on their system). If its solid fix, it will be included into the source.

Maybe avoiding triple posting?

Guests can't edit topics/posts, so there really is no other option.

[Guest]

Code: Select all

diff src/sdl/i_input.cpp 
Index: src/sdl/i_input.cpp
===================================================================
--- src/sdl/i_input.cpp	(revision 1463)
+++ src/sdl/i_input.cpp	(working copy)
@@ -217,7 +217,7 @@
 		{
 			FlushDIKState ();
 			memset (DownState, 0, sizeof(DownState));
-			SDL_EnableKeyRepeat (SDL_DEFAULT_REPEAT_DELAY, SDL_DEFAULT_REPEAT_INTERVAL);
+			SDL_EnableKeyRepeat (0, SDL_DEFAULT_REPEAT_INTERVAL);
 			SDL_EnableUNICODE (1);
 		}
 		else

okay. the above code fixes the problem for me. I do not claim that's the right fix because it is NOT. However, I post it here in hope that perhaps it will inspire someone on the list as to what the real problem might be and point me in the right direction.

[Rachael]

The fix you posted might be the only one that works. However, as I see it, it's very likely that a cvar will be implemented to control such behavior. And it's definitely not a problem in Windows, so any Windows version might not see such a cvar at all, or if it does it might have no effect. I really don't see that making it into the main code, however, without such an option... but I've been wrong about such things before.

[randi]

Added as a cvar, sdl_nokeyrepeat. Note that I don't need it, since the keys repeat sanely for me.