Created attachment 932 [details]
Patch to fix the foreign keyboard handling with SDL

Created attachment 933 [details]
Patch to fix the foreign keyboard handling with SDL ( unified diff version )

(In reply to comment #2)
> Created an attachment (id=933) [edit]
> Patch to fix the foreign keyboard handling with SDL ( unified diff version )
> 

This patches give me some trouble on MacOSX with a US keyboard.  Certain keys end up getting mapped to numbers.  Here is the table if it's any help:

Key  Types
b    2
q    3
w    4
e    5
r    6
t    8
y    9
1    9
2    0

Note that they work properly when typing in the client console, but not into a
UI field (like configuring controls).

I will test this on Linux tomorrow to see if I get similar behaviour.

I suppose that was to be expected somrhow :( You should really never use scancodes.

The only solution I see here is to use a specific scancode convertion depending on the keyboard type used. I wonder if the scancode table depends on the OS or on the hardware. If the former, then maybe we can get it working with a compile time detection.

(In reply to comment #4)
> I suppose that was to be expected somrhow :( You should really never use
> scancodes.
> 
> The only solution I see here is to use a specific scancode convertion depending
> on the keyboard type used. I wonder if the scancode table depends on the OS or
> on the hardware. If the former, then maybe we can get it working with a compile
> time detection.
> 

The patch seems to work fine in Linux with my US keyboard.

Googling for usage of SDL's scancode, I see that the QEMU project handles
non-US keyboards in X11 much the same way that win32/win_wndproc.c does
by mapping an array of certain X11 scancodes to keys.  Perhaps we can
use that array for even broader support?

Anyway, this lends to the idea that the scancodes are going to be common for
X11 platforms.

I'm not convinced this is our bug.

Let's put it in another way : http://www.libsdl.org/cgi/docwiki.cgi/SDLKey

There are 96 WORLD class key events that have no useable ASCII char and are completly ignored by the engine. It causes quite a few keys on foreing keyboard layouts to to be unusable and this includes a good part of the number keys on the french layout. Number keys which are traditionaly used for weapon switching by default. And since the key is ignored, there's no way to remap them anyway.

Also, there are some keys which are aliased one to another or some lost info ( like impossible to bind left alt differently from right alt ).

Created attachment 945 [details]
Cleaner version with no scancode hack

That's patch version is much cleaner. There are no scancode hacks, I've bound all the missing keys I could find in the SDL enums. I've separated the various left and right modifier keys. I've added support for the window keys and the "menu" key and I've added the support for the F13-F15 keys which were also ignored by default.

Should work mostly but there are still some problems with the console handling which is a huge hack from what I've seen.

*** Bug 2834 has been marked as a duplicate of this bug. ***

For that one, I propose a "fix" that hardcodes the F12 key to the console. At least, it will be a very minor change in the code. But you won't be able to open and close the console with the ~ key anymore.

(In reply to comment #10)
> For that one, I propose a "fix" that hardcodes the F12 key to the console. At
> least, it will be a very minor change in the code. But you won't be able to
> open and close the console with the ~ key anymore.

Isn't F12 the default bind to take a screenshot?  Also, it may be a bad idea to use Function keys.  For instance Mozilla avoids using them because certain keyboards don't have them:

http://www.mozilla.org/access/keyboard/#userdefn

It seems like the best fix is either to find a scancode solution that will work for this key location OR if that fails add an additional character that is more universally available (e.g. '/') for the behaviour.

Hard to find a good key that doesn't move between keyboards, easy to reach and with a SDLK_ identifier ( or whatever it's called in the engine ) that doesn't change between keyboard layouts :/

BTW, there is no \ key on a french keyboard either.

Another solution might be a reversed key config in the config file. I mean, the config file is full of lines of the sort :
bind e action1
bind z action2

What we could do is listen to the console key by it's SDLK_ identifier and add a config :
seta ui_console_scancode "e"

But I have no experience in adding new config lines in the engine. I think that one would solve the problem once and for all, provided users of foreign keyboards take the time to assign a new console key.

Created attachment 1079 [details]
not-so-hardcoded console key

Makes traditional console keys less hard-coded.

This is my take on the "Console Key Problem".  My goal was to allow '`' and '~' to act as console keys, but still be bindable to regular actions and not trigger the console.  My approach is to treat `/~ as console key if they are not bound, but to otherwise act as normal keys if they are bound.  Furthermore, to permit reassigning the console key, any key bound with the exact 13-letter all-lowercase string "toggleconsole" is treated as the console key (and consequently untypeable in the console).  Typeability can be maintained by inexact matches, e.g. "ToggleConsole" (uppercases), "toggleconsole;" (trailing semicolon), "toggleconsole " (extra space) -- bounce on ESCAPE to close console.

Goals:
* Permit '`' and '~' to be usable as regular keys
 + /bind GRAVE ...
 + /bind TILDE ...
* allow any key to act as the console key
 + /bind . toggleconsole
* have a backup/fallback/failsafe in case no keys act as console key
 + Pressing ESCAPE then pressing `/~ triggers console (i.e. "escapes" the binding of `/~)

Other notes:
* Restore normal console key with "unbind GRAVE", 'bind GRAVE ""' or "unbindall".

Other problems:
* Disallow '/', '\', BACKSPACE, ENTER, and any alphanumeric keys from being console key?  Otherwise, possible to make quitting (console, "/quit") or restoration ("/unbindall") impossible.
* Permitting other keys to be console key contrary to spirit of a console key?

Does anyone see a problem with just hardcoding the key combination Shift-ESC to toggleconsole (in addition to '`' and '~')?

At least I assume everyone has those :)

AFAIK the key combination is used on windows, but only to "Close certain dialog boxes without confirmation and discard changes" so it should be fine there.  Are there any other OS conflicts?
	

Created attachment 1250 [details]
svn1038 keyboard support

This is Christophe's patch with the following changes:

---

1) Does not differentiate between Right/Left keys such as Shift, Alt, Ctrl. (old behaviour)

2) Does not differentiate between Alt and Meta (old behaviour) 

3) Does not differentiate between Right/Left Windows key (for consistency)

4) Does not remove '~' console hack (not sure why it needs to be removed).

5) Recognizes "Caps Lock" as a bindable key.

6) Adds the proposed Shift-Esc hard-coded toggleconsole bind

---

#1 through #3 are for backwards compatibility for existing configs as well as as config compatability between SDL and Win32.  Although such a change may be desirable, this is a separate issue and deserves a different bug for discussion. 

Caveat:

Unfortunately SDL has no functionality for detecting key true up/down status for the "Caps Lock" and "Num Lock" keys ("Scroll Lock" seems fine).  When one of these keys is pressed, it sends a KEYDOWN event, but does not send a KEYUP event until it is pressed again.   There is no way to detect if the key is being held (even outside of the event checks).  This makes these keys pretty worthless for most binds, but there is no workaround outside of including a hacked SDL with your ioq3 binary.

As for removing the ~ hack, it is not that important I guess, but I think it could cause difficulties in some rare situations. For example, pressing RightAlt and 2 at the same time would open the console on a french keyboard. That hack makes such key combination impossible to use ingame, and even dangerous during play. Unwanted console open at the worse possible time would probably get you killed.

Yet, this is all theorical. I do not use RightAlt myself so I've never faced that behaviour and so, I do not care about it at all. But maybe someone somewhere has and is annoyed by that.

(In reply to comment #16)
> As for removing the ~ hack, it is not that important I guess, but I think it
> could cause difficulties in some rare situations. For example, pressing
> RightAlt and 2 at the same time would open the console on a french keyboard.
> That hack makes such key combination impossible to use ingame, and even
> dangerous during play. Unwanted console open at the worse possible time would
> probably get you killed.

What exactly does id's quake3 client do differently for the toggleConsole bind?  Do you still need to type a ~ or does it just use the upper leftmost key (~ on US keyboards) regardless of label?

Created attachment 1256 [details]
svn1038 keyboard support

* fixed off-by-one error in one MAX_KEYS check (thanks mattn2)
* added section in the README about SDL

added at revision 1044

Setting a QA contact on all ioquake3 bugs, even resolved ones. Sorry if you get a flood of email from this, it should only happen once. Apologies for the incovenience.

--ryan.