Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#2018 closed defect (fixed)

x11 mplayer improper handling of XF86AudioRaiseVolume key

Reported by: threeoften@… Owned by: reimar
Priority: normal Component: core
Version: HEAD Severity: normal
Keywords: Cc: threeoften@…
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

Description

(Apologies in advance for not getting "component" correct; I'm not entirely sure where this actually belongs.)
I noticed this bug when upgrading from the mplayer in Debian Stable to more recent versions (for unrelated bugfixes). _This issue is present in svn head._

For reference, this is I believe exactly my keyboard: http://www.tandswebdesign.com/blog/wp-content/uploads/2008/05/design_keyboard20080226.jpg

My hardware is an Apple MacBook? 3,1. As such, the upper right three keys are, in order, vol down (fn + thiskey gets f11), vol up (fn + thiskey gets f12), and eject. The issue here is that the vol up key is interpreted by mplayer not only as VOLUME_UP but also as XF86_PAUSE. With default input configuration, what this means is that my vol up key not only, when pressed, raises the volume as expected, but also causes the video to be paused. In practice, regardless of video state, the video will start playing, the volume will raise, and then the video will stop. Finally, as alluded to above, my stopgap workaround fix is to set XF86_PAUSE to ignore in my input.conf.

As a final note, xev tells me the following about the vol up key:

KeyRelease? event, serial 27, synthetic NO, window 0x1a00001,

root 0x105, subw 0x0, time 18422777, (478,67), root:(479,84),
state 0x0, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

Also relevant is that this is only an issue in the x11 interface of standard mplayer; when using framebuffer, these keys are not recognized at all (which is fine with me since I was trying to turn them off anyway).

If there is any more information I can provide, please let me know. Thanks in advance.

Change History (6)

comment:1 Changed 8 years ago by threeoften@…

  • Cc threeoften@… added

comment:2 Changed 8 years ago by reimar

I can't see how this should happen due to MPlayer's fault.
Your xev log is incomplete, the should at least be a down and a up event.
I would expect something is buggy about the keyboard driver and that key ends up sending both volume up and pause events.

comment:3 Changed 8 years ago by threeoften@…

(In reply to comment #1)

I can't see how this should happen due to MPlayer's fault.
Your xev log is incomplete, the should at least be a down and a up event.
I would expect something is buggy about the keyboard driver and that key ends
up sending both volume up and pause events.

If you would like a complete xev log, I can post it. Yes, an up and down are both generated. My keyboard driver is fine; there is no pause event generated. This was not a problem prior to upgrading the version of mplayer on my system; as nothing else on my system has changed, I am rather inclined to blame mplayer.

comment:4 Changed 8 years ago by reimar

  • Resolution set to fixed
  • Status changed from new to closed

You are right, this was a case of a bad coincidence of the keysym values.
Should be fixed in SVN r34357.
I could not test it properly though, while I just discovered that my keyboard has such "multimedia" stuff as well, it only works in xev but is ignored in MPlayer, very strange...

comment:5 Changed 8 years ago by reimar

Now I could test and can confirm that it is fixed for me.
I had to find out that my OpenGL driver installation is broken, causing MPlayer with -vo gl to use SDL instead of X11 directly, and SDL (at least in MPlayer) does not support those special keys.

comment:6 Changed 8 years ago by threeoften@…

You are right, this was a case of a bad coincidence of the keysym values.
Should be fixed in SVN r34357.

It is indeed. Thank you very much!

Note: See TracTickets for help on using tickets.