View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001507 | FSSCP | --------- | public | 2007-09-18 11:06 | 2007-09-18 16:48 |
| Reporter | whereami | Assigned To | taylor | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | no change required | ||
| Summary | 0001507: keymap differences when using SDL (on *nix) | ||||
| Description | As noted in [1], non-US keymaps are problematic on platforms that use SDL. This is because the game gets the keypress events as keysyms instead of scancodes. Most keyboards are laid out the same way, but are just labeled differently, meaning the key in the position normally labeled "X" on US keyboards always has the same scancode, though it may have a different label and can be interpreted by the OS as a keysym other than that representing "X". [1] mentions french and UK keyboards, which seem to be somewhat handled in the game code. There are countless other keyboard layouts, however. In Dvorak, the key labeled "X" in the US layout corresponds to the letter "B". Games should interpret scancodes when using the keyboard as a controller. This allows the default keymap to have the same layout on nearly every keyboard and keymap. However, when requiring text input (typing messages, etc), the game should use keysyms. This should provide compatibility with every keyboard and layout out there. SDL makes this easy by providing both the scancode and the keysym in its keyboard events [2]. Despite what [2] says, scancodes are very consistent for the first 104 keys on PC keyboards (otherwise you would need a different driver for every keyboard). To fix this issue in the freespace engine, when processing SDL_KEY(UP|DOWN) events in unix_process() in osapi_unix.cpp, use event.key.keysym.scancode instead of event.key.keysym.sym except when actually expecting text input. I'm not sure exactly how you should deal with the two realms.. One possibility is to store both in the queue, and access the right one in the right places. I think this might be the cleanest solution. [1] http://www.hard-light.net/wiki/index.php/Fs2_open_on_Linux/I18n_and_Key_mapping_problems [2] http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fkeysym | ||||
| Tags | No tags attached. | ||||
|
|
This is just something that the engine suffers from, it's not merely a SDL issue. It's already slated to be fixed in 3.7 though, since it requires a sizable rewrite of the code to make the change to dealing with the keys properly. It also requires moving to SDL on Windows, which is another reason that it's not going to get fixed until 3.7. Regardless, this is more of a feature request, so it doesn't really belong in Mantis. It is near the top of the feature request list, so it's definitely going to be fixed as soon as possible, but everyone just has to wait a bit longer. |
|
|
Marking as "no change required" since it's a feature request more than a bug. But it is going to be "fixed" at a later time. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-09-18 11:06 | whereami | New Issue | |
| 2007-09-18 16:47 | taylor | Note Added: 0008534 | |
| 2007-09-18 16:48 | taylor | Status | new => resolved |
| 2007-09-18 16:48 | taylor | Resolution | open => no change required |
| 2007-09-18 16:48 | taylor | Assigned To | => taylor |
| 2007-09-18 16:48 | taylor | Note Added: 0008535 |