Broken keyboard handling

[Stof]

This is the feedback forum isn't it ? Well then, the keyboard doesn't work correctly when using a french layout on Linux This isn't new since I have yet to see a commercial game or ex-commercial game with non broken non-us keyboard support. Some knows what should be done to fix that ? I'm ready to tackle the problem if needed.

[Lava Croft]

Get a proper keyboard~  :roll:

[Stof]

At least I avoided the "Get a proper OS" joke. Seriously, it's annoying having to switch to a qwerty layout each time I want to play. Most often, I forget to do that and I have to quit the game to change it because console cannot be opened at that point, and if I can't open the console, I cannot Alt+Tab out of the game.

[SLAVE|Mietz]

At least I avoided the "Get a proper OS" joke. Seriously, it's annoying having to switch to a qwerty layout each time I want to play. Most often, I forget to do that and I have to quit the game to change it because console cannot be opened at that point, and if I can't open the console, I cannot Alt+Tab out of the game.

Seriously, i dont understand your problem.
maybe explain it a bit, why wouldn't you open the console? do french keyboards have no "~"?

[Neo]

Granted it wouldn't be easy, but you could just rebind the keys to fit an Azerty keyboard.

[Stof]

Granted it wouldn't be easy, but you could just rebind the keys to fit an Azerty keyboard.

Some keys cannot be used when in french layout. The key used typicaly for the console doesn't work anymore, quite a few of the number keys ( not the numpad ) cannot be used either etc ...

[Catalyc]

You can always bind the console to something else. Look this line up in the autogen.cfg:

Code: [Select]

bind ` "toggleconsole"

and change ` for whatever suits you.

On another note, you can probably Alt+Enter and switch to windowed mode, you'll have to reload the map though.

[Stof]

You can always bind the console to something else. Look this line up in the autogen.cfg:

Code: [Select]

bind ` "toggleconsole"

and change ` for whatever suits you.

Probably but I would still like the other keys to work.

On another note, you can probably Alt+Enter and switch to windowed mode, you'll have to reload the map though.

I'll have you know that I can perfectly ALT+ENTER and switch between fullscreen and windowed mode without reloading the level at all. And also, since I use the same resolution ingame and outgame, the switch is instant

Unfortunately, when I do that, I just get a window which covers the whole screen and that I cannot leave at all. The game doesn't unlock the mouse and ALT+TAB until I open the console.

As a matter of fact, looking at the source code, I found a horible hack : if there's a SDL KEYDOWN event with a display char of '~', then it is translated as a the ~ key itself. It means that when I use "Right Alt ( Alt Gr ) + 3" I get the console to open and close Fortunately for me, that's two key's I have no reason to use yet but I wouldn't like the console to open at the worse possible time else

[tjw]

http://www.lokigames.com/support/quake3/faq3-installation.php3

xmodmap -e "keycode 49 = asciitilde"

might work for you.

For a real fix to ioquake3, perhaps unix/sdl_glimp.c needs a similar type of extended ascii mapping that win32/win_wndproc.c has.

[Stof]

Not sure about that. It looks like win_wndproc uses a scancode -> key convertion table which is something flawed to begin with because that table depends on the keyboard layout.

I'll have to test the windows version but looking at the code, I'm sure that pressing the A key on the keyboard config screen will display the Q key instead. Still, it might be possible to do it that way. It'll be far from perfect though.

As a matter of fact, the best thing to do would probably be to use SDL for all key handling on all platforms. At least there will be only one code path and there won't be a need for some "os dependend keyboard routine keycode" -> "game engine keycodes" convertion function.

[Stof]

Ok, problem is rather "simple" in the end. Looking at unix/sdl_gimpl.c line 180, we have the convertion table. What it says is that :
- if the symbol pressed is a printable ASCII char, then it is passed as it is. So far, so good
- else, if the sym matches a big switch case, we convert to the internal ioquake keycode.
- else, the key is ignored

and after that, a second test is made :
- if the key symbol is a pure ASCII value, then we pass it to the input buffer

First part is used to handle ingame keys like forward, fire etc ... and second part is used to handle console commands, text input fields etc ...

The problem is that french keyboards ( and many othe keyboards ) have some keys which produce a symbol which isn't ASCII but is still considered printable ( although not for quake ). And there's little chance to get them working like that. It'll require quite some change in the internals of the keyboard handling.

[PierreF]

I've done a quick and durty patch to allow french keyboard to work well with the key ² (which is ~ on qwerty keyboard).

It's work for opening and closing console

Code: [Select]


--- tremulous-1.1.0-src/src/unix/sdl_glimp.c    2006-03-04 00:59:01.000000000 +0100
+++ tremulous-1.1.0-src.my/src/unix/sdl_glimp.c 2006-09-10 13:06:51.000000000 +0200
@@ -250,6 +250,9 @@
   case SDLK_KP_MINUS: *key = K_KP_MINUS; break;
   case SDLK_KP_DIVIDE: *key = K_KP_SLASH; break;

+  // pierref, console for french keyboard
+  case SDLK_WORLD_18: *key = '~'; break;
+
   default: break;
   }


[rasz_pl]

oh cmon, just
setxkbmap blabla
trem
setxkbmap blabla_back

[Stof]

oh cmon, just
setxkbmap blabla
trem
setxkbmap blabla_back

:roll: :evil: :x

[PierreF]

Also buy qwerty keyboard !

It FAR easier for me to use a azerty keyboard, it's the layout I use all the time, I don't understand why I should change my layout only for a game, moreover when a simple patch solve the problem

[Stof]

What I don't like about your patch which is a hack ( but to counter another hack ) is that it might break other layouts.

[Taiyo.uk]

oh cmon, just
setxkbmap blabla
trem
setxkbmap blabla_back

or just put this in your .bashrc:

Code: [Select]

alias trem="setxkbmap blabla; tremulous; setxkbmap blabla_back"
Then you can completely forget that it's a really lousy kludge :wink:

[Stof]

oh cmon, just
setxkbmap blabla
trem
setxkbmap blabla_back

or just put this in your .bashrc:

Code: [Select]

alias trem="setxkbmap blabla; tremulous; setxkbmap blabla_back"
Then you can completely forget that it's a really lousy kludge :wink:

Goodness! Maybe you don't know it but doing a setxkbmap will change the keyboard map! It means you'll be having a english keyboard map on an nonengligh keyboard :x

Unacceptable.

[rasz_pl]

http://cgi.ebay.co.uk/English-QWERTY-UK-keyboard-stickers-Acer-Dell-IBM-512A_W0QQitemZ300019570316QQihZ020QQcategoryZ31568QQcmdZViewItem

[Taiyo.uk]

Goodness! Maybe you don't know it but doing a setxkbmap will change the keyboard map! It means you'll be having a english keyboard map on an nonengligh keyboard :x

Unacceptable.

Yeah, pretty wicked, huh? It's like das keyboard but more confusing  :wink:

In fact get youself one of those, then what keymap you set is completely irrelevant. Kludgetastic!

[kevlarman]

this is still a hack, but at least it doesn't screw up your entire keyboard (or depend on a specific layout): you can wrap trem in a script that uses xmodmap to remap a few keys, and then unremaps them when trem exits, but you'll have a messed up keyboard when you alt-tab out of trem.

[Karmon]

I have the same problem as Stof but with a german keyboard.

BUT...only when playing Trem under Linux.
That's the weird thing about it because it works ok under Win98.

For example, the "ü" and "ö"-keys which are to the right of the "P" and "L"-keys, respectively, can be set under the Win-version of Trem, but under Linux they don't even respond.

Another annoyance:
If I use a certain key, for opening the console under Linux, it will open it but when pressing this specific key again it will print that key within the console instead of closing the console again.

Please don't tell me that playing Trem under Linux is behind playing it under Win.

Hopefully these problems can be fixed easily in the next version.
Or are there some simple workarounds ?


Karmon

[PFB]

well keyboards are cheap
get a qwerty us keyboard

[Stof]

I have the same problem as Stof but with a german keyboard.

BUT...only when playing Trem under Linux.
That's the weird thing about it because it works ok under Win98.

For example, the "ü" and "ö"-keys which are to the right of the "P" and "L"-keys, respectively, can be set under the Win-version of Trem, but under Linux they don't even respond.

Another annoyance:
If I use a certain key, for opening the console under Linux, it will open it but when pressing this specific key again it will print that key within the console instead of closing the console again.

Please don't tell me that playing Trem under Linux is behind playing it under Win.

Hopefully these problems can be fixed easily in the next version.
Or are there some simple workarounds ?


Karmon

Are you using the latest tjw client backport? IIRC, some of us submitted a few patches for that and it should work much better now, provided they got integrated in that client Next version should work much better for that, even the console key I hope.

Of course, there's always the problem that maybe nobody tested with your specific keyboard some there might still be some specific problems.

[Karmon]

@ PFB
Unqualified and useless comment...  --> /dev/null

@ stof
No, I haven't tried that so far. I just installed Trem with aptitude from the Debian stable repository.
I just find it strange that Trem doesn't stick to the OS's settings as it does under Windows.