Function keys wont work in fullscreen game

Bug #619256 reported by Abhijit Navale
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
libsdl
Incomplete
Medium
libsdl1.2 (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Hello.

When ever i play any game which goes to full screen e.g. widelands,freecol, beneath the steel sky and more.
At that time only my brightness function key work.
But function key for sound dont work.
This bug is reproducible.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: libsdl1.2debian-alsa (not installed)
ProcVersionSignature: Ubuntu 2.6.32-24.39-generic 2.6.32.15+drm33.5
Uname: Linux 2.6.32-24-generic x86_64
Architecture: amd64
Date: Tue Aug 17 19:59:19 2010
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
ProcEnviron:
 LANG=en_IN
 SHELL=/bin/bash
SourcePackage: libsdl1.2

Revision history for this message
In , mjau (mjau-deactivatedaccount) wrote :
Download full text (20.0 KiB)

I'm on 64-bit Linux, X.org server 1.5.3, KDE 4, using "evdev-managed" keyboard layout. The keyboard has a norwegian layout and a bunch of extra multimedia keys like play/pause, mute, back, forward, etc. The keys work fine in KDE/GTK/etc.

I recently discovered that the extra multimedia keys on my keyboard no longer generates any events at all with SDL 1.3 (testing with the checkkeys program in test). The ¨/^/~ key (a dead key) also doesn't generate any press events, though it does generate text input. Since I remembered these keys generating events before, I checked out a couple revisions and found out where things got broken.

I did notice that the svn log for revision 4176 acknowledges the dead keys missing keypress events bug, but I couldn't find a bug report for it and there's no mention of multimedia key issues, so I figured it was worth reporting this anyway.

The extra multimedia keys used to at least generate events before revision 3568, but with a warning that the key was unrecognized and that the layout should be mailed to the SDL mailinglist (I think I did send a mail back then with the reported layout, but can't find the mail now for some reason, so perhaps I forgot?). Anyway, this was how it worked up to revision 3567. In revision 3568, most of the extra keys stopped working (with the exception of "Stop"), but some debug output shows that the keys were still detected but not processed(?). In revision 3569 the debug output was removed. Revision 4176 broke the "Stop" key as well. (Also, dead keypress events stopped working in 3568, but text composition started working in that revision.)

To clarify a bit, here's the results of running the checkkeys program in revision 3567, 3568, 3569, 4175 and 4176, and pressing first the key identified as "XF86Back", then "Stop", then the ¨ key (a dead key), and finally the e key (to compose into ë). Added key names in brackets to show what keypress generated what output, and snipped output that occured before I started pressing keys

- 3567 -
[XF86Back]
The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL mailing list <email address hidden> X11 KeyCode 166 (158), X11 KeySym 0x1008FF26 (XF86Back).
[Stop]
Key pressed : scancode 120 = Stop, keycode 0x40000078 = Stop modifiers: (none)
Key released: scancode 120 = Stop, keycode 0x40000078 = Stop modifiers: (none)
[¨]
The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL mailing list <email address hidden> X11 KeyCode 35 (27), X11KeySym 0xFE57 (dead_diaeresis).
Sending text event �
Text: �
[e]
Sending text event e
Key pressed : scancode 8 = E, keycode 0x00000065 = E (e) modifiers: (none)
Text: e
Key released: scancode 8 = E, keycode 0x00000065 = E modifiers: (none)

- 3568 -
[XF86Back]
KeyPress (X11 keycode = 0xA6)
KeyRelease (X11 keycode = 0xA6)
[Stop] ...

Revision history for this message
In , Sam Lantinga (slouken) wrote :

What's the output of xev for the affected keys?

Revision history for this message
In , mjau (mjau-deactivatedaccount) wrote :
Download full text (7.0 KiB)

Copied the output of xev below. Also, I found out that the Print Screen/SysRq key ("Print") and the Pause/Break key ("Pause") also stopped working in revision 4176, so I included those here as well. The key I called "Stop" above is called "Cancel" here, and dead_diaeresis is the dead ¨ key. Removed the KeyRelease events for brevity =)

KeyPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x1a6, subw 0x0, time 33711830, (-584,89), root:(906,118),
    state 0x0, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x1a6, subw 0x0, time 33712408, (-584,89), root:(906,118),
    state 0x0, keycode 121 (keysym 0x1008ff12, XF86AudioMute), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x1a6, subw 0x0, time 33712912, (-584,89), root:(906,118),
    state 0x0, keycode 174 (keysym 0x1008ff15, XF86AudioStop), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x1a6, subw 0x0, time 33713869, (-584,89), root:(906,118),
    state 0x0, keycode 173 (keysym 0x1008ff16, XF86AudioPrev), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x1a6, subw 0x0, time 33714253, (-584,89), root:(906,118),
    state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x1a6, subw 0x0, time 33714646, (-584,89), root:(906,118),
    state 0x0, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x1a6, subw 0x0, time 33715143, (-584,89), root:(906,118),
    state 0x0, keycode 171 (keysym 0x1008ff17, XF86AudioNext), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 30, synthetic NO, window 0x3c00001,
    root 0x1a6, subw 0x0, time 33716852, (-584,89), root:...

Read more...

Revision history for this message
In , mjau (mjau-deactivatedaccount) wrote :

One more: The keypad enter key also stopped working in revision 4176.

KeyPress event, serial 30, synthetic NO, window 0x2000001,
    root 0x1a6, subw 0x0, time 34253593, (-407,622), root:(1083,651),
    state 0x0, keycode 104 (keysym 0xff8d, KP_Enter), same_screen YES,
" XLookupString gives 1 bytes: (0d) "
    XFilterEvent returns: False

Revision history for this message
In , Robert Ancell (robert-ancell) wrote :

Getting the volume keys to work (XF86AudioMute, XF86AudioLowerVolume and XF86AudioRaiseVolume) is particularly useful as otherwise playing a full screen game (in this case tuxracer) can be very loud and users immediately try and reduce the volume by pressing the multimedia keys on their keyboards.

SDL currently passes these events as SDLK_UNKNOWN

Revision history for this message
In , Robert Ancell (robert-ancell) wrote :

Sorry, ignore that last comment - I didn't notice this bug was regarding the development version of libsdl

Revision history for this message
In , Sam Lantinga (slouken) wrote :

This is mostly fixed in the current SDL 1.3 snapshot:
http://www.libsdl.orgdead_diaeresis/tmp/SDL-1.3.zip

All the multimedia keys should be recognized. The only thing I'm not sure about is dead_diaeresis. It'll currently be recognized as SDL_SCANCODE_RIGHTBRACKET.

Revision history for this message
In , mjau (mjau-deactivatedaccount) wrote :
Download full text (3.9 KiB)

(In reply to comment #6)
> This is mostly fixed in the current SDL 1.3 snapshot:
> http://www.libsdl.orgdead_diaeresis/tmp/SDL-1.3.zip
>
> All the multimedia keys should be recognized. The only thing I'm not sure
> about is dead_diaeresis. It'll currently be recognized as
> SDL_SCANCODE_RIGHTBRACKET.

Hm, I'm still getting unrecognized keys here with that.. Here's some checkkeys output

KeyPress (X11 keycode = 0xF2)
The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL mailing list <email address hidden> X11 KeyCode 242 (234), X11 KeySym 0x1008FF77 (XF86Save).
KeyRelease (X11 keycode = 0xF2)

KeyPress (X11 keycode = 0xB3)
The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL mailing list <email address hidden> X11 KeyCode 179 (171), X11 KeySym 0x1008FF81 (XF86Tools).
KeyRelease (X11 keycode = 0xB3)

There's also some unknown keys (removed release events):

KeyPress (X11 keycode = 0x6C)
Unknown Key (scancode 230 = Right Alt) pressed modifiers: RALT
KeyPress (X11 keycode = 0xA3)
Unknown Key (scancode 265 = Mail) pressed modifiers: (none)
KeyPress (X11 keycode = 0xB4)
Unknown Key (scancode 269 = AC Home) pressed modifiers: (none)
KeyPress (X11 keycode = 0xAC)
Unknown Key (scancode 261 = AudioPlay) pressed modifiers: (none)
KeyPress (X11 keycode = 0xAD)
Unknown Key (scancode 259 = AudioPrev) pressed modifiers: (none)
KeyPress (X11 keycode = 0xAB)
Unknown Key (scancode 258 = AudioNext) pressed modifiers: (none)
KeyPress (X11 keycode = 0x94)
Unknown Key (scancode 266 = Calculator) pressed modifiers: (none)
KeyPress (X11 keycode = 0xAE)
Unknown Key (scancode 260 = AudioStop) pressed modifiers: (none)
KeyPress (X11 keycode = 0xA6)
Unknown Key (scancode 270 = AC Back) pressed modifiers: (none)
KeyPress (X11 keycode = 0xA7)
Unknown Key (scancode 271 = AC Forward) pressed modifiers: (none)
KeyPress (X11 keycode = 0xB5)
Unknown Key (scancode 273 = AC Refresh) pressed modifiers: (none)
KeyPress (X11 keycode = 0xA3)
Unknown Key (scancode 265 = Mail) pressed modifiers: (none)
KeyPress (X11 keycode = 0xE1)
Unknown Key (scancode 268 = AC Search) pressed modifiers: (none)

Also, volume up/down only generates release events, never press events:

KeyRelease (X11 keycode = 0x7A)
KeyRelease (X11 keycode = 0x7B)

The dead "/^/~ key generates only a release event on the first press, and is unrecognized on the second press:

KeyRelease (X11 keycode = 0x23)
KeyPress (X11 keycode = 0x0)
The key you just pressed is not recognized by SDL. To help get this fixed, please report this to the SDL mailing list <email address hidden> X11 KeyCode 0 (-8), X11 KeySym 0x0 ((null)).
KeyRelease (X11 keycode = 0x23)

Pressing that key once and then a key it modifies (eg e) makes the second key be unrecognized as well. Here I pressed e, ¨, e:

Key pressed : scancode 8 = E, keycode 0x00000065 = E (e) modifiers: (none)
Text: e
KeyRelease (X11 keycode = 0x1A)
Key released: scancode 8 = E, keycode 0x00000065 = E modifiers: (none)
KeyRelease (X11 keycode = 0x23)
KeyPress (X11 keycode = 0x0)
The key you just pressed is not recognized by SDL. To help get this fixed, please report this to ...

Read more...

Revision history for this message
In , mjau (mjau-deactivatedaccount) wrote :

The \ key by itself works fine btw:

KeyPress (X11 keycode = 0x15)
Key pressed : scancode 46 = =, keycode 0x0000005C = \ (\) modifiers: (none)
Text: \
KeyRelease (X11 keycode = 0x15)
Key released: scancode 46 = =, keycode 0x0000005C = \ modifiers: (none)

It only misbehaves when combined with a modifier key that makes it dead (shift or alt-gr here).

Changed in libsdl1.2 (Ubuntu):
status: New → Confirmed
Revision history for this message
Charlie Kravetz (cjkgeek) wrote :

 Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here. Thanks for taking the time to make Ubuntu better!

Changed in libsdl1.2 (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Medium
Changed in libsdl:
importance: Unknown → Medium
status: Unknown → In Progress
Revision history for this message
In , Ryan C. Gordon (icculus) wrote :

(Sorry if you get a lot of copies of this email, we're touching dozens of bug reports right now.)

Tagging a bunch of bugs as target-2.0.0, Priority 1.

This means we're in the final stretch for an official SDL 2.0.0 release! These are the bugs we really want to fix before shipping if humanly possible.

That being said, we don't promise to fix them because of this tag, we just want to make sure we don't forget to deal with them before we bless a final 2.0.0 release, and generally be organized about what we're aiming to ship.

Hopefully you'll hear more about this bug soon. If you have more information (including "this got fixed at some point, nevermind"), we would love to have you come add more information to the bug report when you have a moment.

Thanks!
--ryan.

Revision history for this message
In , Sam Lantinga (slouken) wrote :

I need some help. Gerry, can you dig into the keyboard code and see what's going on? I can't reproduce the issues here.

Changed in libsdl:
status: In Progress → Incomplete
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.