We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

There is some trouble around a console ioctl call (KDGKBENT) in the SDL_evdev code, giving an unexpected (?) translation of a key code.

When I press the "Q"-key on my keyboard, the following happens:

In file: "src/core/linux/SDL_evdev.c" function "SDL_EVDEV_do_text_input" gets called with an argument of keycode==0x10.
This looks correct, according to a list with Linux keycodes that is indeed the "Q"-key.

Next, an IOCTL is performed (KDGKBENT) to translate that keycode into a kb_value, taking into account modifier keys etc...

For the "Q"-key, the IOCTL produces a translation of kb_value == 0xb71 (not sure if that's correct).
Macro KTYP yields a value of (0xb71 >> 8) which equals 0xb.

The SDL_EVDEV_do_text_input function decides that a KTYP value of 0xb is smaller than 0xf0 and quits. At that location a code comment reads: 

/*
 * FIXME: keysyms with a type below 0xf0 represent a unicode character
 * which requires special handling due to dead characters, diacritics,
 * etc. For perfect input a proper way to deal with such characters
 * should be implemented.
 *
 * For reference, the only place I was able to find out about this
 * special 0xf0 value was in an unused? couple of patches listed below.
 *
 * http://ftp.tc.edu.tw/pub/docs/Unicode/utf8/linux-2.3.12-keyboard.diff
 * http://ftp.tc.edu.tw/pub/docs/Unicode/utf8/linux-2.3.12-console.diff
*/

If I press a number key, like the "0" keytop, I get a kb_value of 0x30, which looks like it is simply just the ASCII code for the key. 
In that case there is also no SDL_TEXTINPUT event due to the fact the KTYP is lower than 0xf0 (0x00f0 >> 8, so zero in this case).

I'm starting to have doubts about my console/keymap and keyboard configuration now.

As for the other problem of characters reaching the console, if I understand correctly there is no code to stop that?

In function "SDL_EVDEV_mute_keyboard" some code has been commented out:

/* Prevent keystrokes from reaching the tty */
static int SDL_EVDEV_mute_keyboard(int tty_fd, int* old_kb_mode)
{
...
    
    /* FIXME: atm this absolutely ruins the vt, and KDSKBMUTE isn't implemented
       in the kernel */
    /*
    if (ioctl(tty_fd, KDSKBMODE, K_OFF) < 0) {
        return SDL_SetError("Failed to set keyboard mode during muting");
    }
    */
    
    return 0;  
}

Note that the SDL program runs directly on the console and not under X.

The locale has been set to "en_GB.UTF-8".

It looks like the ioctl function KDGKBENT only translates key codes to ASCII.

After reading about Linux and keyboard handling, I now understand that the console has been deliberately kept 'simple'.

Could it be that the recent Linux kernel (4.4) further simplifies the console?
Perhaps not to provide Unicode translations at all anymore. The ioctls seem quite undocumented and may therefore change from one moment to next without notice.

We might have to implement some POSIX calls to perform the translation according to the configured locale?

Can you try with the latest snapshot?
http://www.libsdl.org/tmp/SDL-2.0.zip

This should have been fixed for 2.0.6.

Thanks!

Characters no longer echo to the console and text input now works again. 
Thanks so much for fixing this!

P.S. In order to compile my app after building SDL2 from scratch, I had to remove two of the old (Raspbian packaged) SDL2 header files (SDL.h and SDL_version.h) which clashed with the newly installed ones.