If I run xev under either KDE or Fluxbox when I hit the brightness control keys xev generates the expected out put namely:
FocusOut event, serial 45, synthetic NO, window 0x4a00001,
mode NotifyGrab, detail NotifyAncestor
FocusIn event, serial 45, synthetic NO, window 0x4a00001,
mode NotifyUngrab, detail NotifyAncestor
KeymapNotify event, serial 45, synthetic NO, window 0x0,
keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
KeyRelease event, serial 45, synthetic NO, window 0x4a00001,
root 0x105, subw 0x0, time 4746798, (-14,322), root:(692,370),
state 0x0, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
MappingNotify event, serial 45, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 8, count 248
FocusOut event, serial 45, synthetic NO, window 0x4a00001,
mode NotifyGrab, detail NotifyAncestor
FocusIn event, serial 46, synthetic NO, window 0x4a00001,
mode NotifyUngrab, detail NotifyAncestor
KeymapNotify event, serial 46, synthetic NO, window 0x0,
keys: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0
KeyRelease event, serial 46, synthetic NO, window 0x4a00001,
root 0x105, subw 0x0, time 4746813, (-14,322), root:(692,370),
state 0x0, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
All in all exactly as expected. Now when I run it in Openbox I get this abnormally cryptic output I can't make head or tails of. Now the brightness control keys do control the brightness perfectly well but why this weird output:
FocusOut event, serial 39, synthetic NO, window 0x2200001,
mode NotifyGrab, detail NotifyAncestor
FocusIn event, serial 39, synthetic NO, window 0x2200001,
mode NotifyUngrab, detail NotifyAncestor
KeymapNotify event, serial 39, synthetic NO, window 0x0,
keys: 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
MappingNotify event, serial 39, synthetic NO, window 0x0,
request MappingKeyboard, first_keycode 8, count 248
FocusOut event, serial 39, synthetic NO, window 0x2200001,
mode NotifyGrab, detail NotifyAncestor
FocusIn event, serial 39, synthetic NO, window 0x2200001,
mode NotifyUngrab, detail NotifyAncestor
KeymapNotify event, serial 39, synthetic NO, window 0x0,
keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
FocusOut event, serial 40, synthetic NO, window 0x2200001,
mode NotifyNormal, detail NotifyNonlinear
VisibilityNotify event, serial 40, synthetic NO, window 0x2200001,
state VisibilityFullyObscured
Granted I'm not sure how serious of a problem this is but this is definitely an abnormality. I try using xev to find the xf86 name of the brightness controls and get this weird result. That's how I stumbled into the problem. After googling the right name and further experimentation on KDE and Fluxbox it seems the problem must be with Openbox or possibly Xorg and both KDE and Openbox tweaked with who knows what...
Interestingly enough the volume controls do respond as expected in xev but they don't actually work. Now I'm not sure if this is a feature or a bug of Openbox. On one hand since there are various sound backends alsa/oss/pulseaudio/etc so Openbox has no way of knowing which you have and what you want the volume control keys to do. On the other hand KDE and in most cases GNOME seem to recognize the keys and perform the appropriate action. Furthermore launching kmix in my autostart.sh works in terms of changing the volume and have that volume control notification popup appear on the center of the screen. I don't know what to make of this.
Minor correction of the bug description. Replace the sentence:
After googling the right name and further experimentation on KDE and Fluxbox it seems the problem must be with Openbox or possibly Xorg and both KDE and Openbox
tweaked with who knows what...
with:
After
googling the right name and further experimentation on KDE and Fluxbox it seems
the problem must be with Openbox or possibly Xorg and both KDE and Fluxbox
tweaked with who knows what...
Openbox does what you ask of it with key bindings.
KDE runs kmix (or whatever) which grabs the volume keys and then responds to them. GNOME runs some other program which grabs the volume keys and then responds to them. Openbox doesn't run things automatically unless you ask it to. Easiest way is the autostart script (see wiki).
The cryptic output looks exactly like the first one but the key releases are gone. I would guess something is grabbing them (hence them doing something), and xev doesn't get the events.
The volume keys go to xev cuz no program is grabbing them. You can bind them to something in your rc.xml (see wiki) or you can run an application to grab them and respond to them.
Seems like this is just a matter of binding keys or running apps to handle them appropriately. Cheers.
(In reply to comment #2)
> Openbox does what you ask of it with key bindings.
>
> KDE runs kmix (or whatever) which grabs the volume keys and then responds to
> them. GNOME runs some other program which grabs the volume keys and then
> responds to them. Openbox doesn't run things automatically unless you ask it
> to. Easiest way is the autostart script (see wiki).
>
> The cryptic output looks exactly like the first one but the key releases are
> gone. I would guess something is grabbing them (hence them doing something),
> and xev doesn't get the events.
>
> The volume keys go to xev cuz no program is grabbing them. You can bind them
> to something in your rc.xml (see wiki) or you can run an application to grab
> them and respond to them.
>
> Seems like this is just a matter of binding keys or running apps to handle them
> appropriately. Cheers.
Mhm I'm actually not so sure about that. My autostart.sh consists of just 4 lines:
tint2&
xfce4-power-manager&
nm-applet&
kmix&
Now you say that whatever is grabbing the brightness control keys makes it so that xev doesn't get the event and yet still does the correct action. But to the best of my knowledge none of these grab the brightness control keys. Furthermore greping for XF86MonBrightnessUp or XF86MonBrightnessDown in my rc.xml yeilds no results whatsoever let alone any in the keyboard section. So how these keys do the right thing when pressed I do not know. The output in xev however still isn't right.
Furthermore as you notice I launch kmix to handle the volume. As you yourself said it grabs the keys and performs it's task of changing the volume and showing the notification popup. Yet when running xev the event still gets through in spite of the keys being grabbed and the output is the expected:
FocusOut event, serial 47, synthetic NO, window 0x1e00001,
mode NotifyGrab, detail NotifyAncestor
FocusIn event, serial 47, synthetic NO, window 0x1e00001,
mode NotifyUngrab, detail NotifyAncestor
KeymapNotify event, serial 47, synthetic NO, window 0x0,
keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
KeyRelease event, serial 47, synthetic NO, window 0x1e00001,
root 0x105, subw 0x0, time 2650786, (-594,215), root:(0,502),
state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
FocusOut event, serial 47, synthetic NO, window 0x1e00001,
mode NotifyNormal, detail NotifyNonlinear
I don't know why that is. Again I don't experience this under KDE or Fluxbox. Something clearly isn't quite right with the way the brightness control keys are handled I have no explanation of why that is.
You may be right and me wrong. There may be something I don't know/misunderstand. However please look into it and don't be as fast at striking this out as my previous bug which after I refiled it with clearer details turned out to be quite valid(using _ to set accelerators was undocumented).
(In reply to comment #3)
> (In reply to comment #2)
> > Openbox does what you ask of it with key bindings.
> >
> > KDE runs kmix (or whatever) which grabs the volume keys and then responds to
> > them. GNOME runs some other program which grabs the volume keys and then
> > responds to them. Openbox doesn't run things automatically unless you ask it
> > to. Easiest way is the autostart script (see wiki).
> >
> > The cryptic output looks exactly like the first one but the key releases are
> > gone. I would guess something is grabbing them (hence them doing something),
> > and xev doesn't get the events.
> >
> > The volume keys go to xev cuz no program is grabbing them. You can bind them
> > to something in your rc.xml (see wiki) or you can run an application to grab
> > them and respond to them.
> >
> > Seems like this is just a matter of binding keys or running apps to handle them
> > appropriately. Cheers.
>
> Mhm I'm actually not so sure about that. My autostart.sh consists of just 4
> lines:
>
> tint2&
> xfce4-power-manager&
> nm-applet&
> kmix&
>
> Now you say that whatever is grabbing the brightness control keys makes it so
> that xev doesn't get the event and yet still does the correct action. But to
> the best of my knowledge none of these grab the brightness control keys.
> Furthermore greping for XF86MonBrightnessUp or XF86MonBrightnessDown in my
> rc.xml yeilds no results whatsoever let alone any in the keyboard section. So
> how these keys do the right thing when pressed I do not know. The output in xev
> however still isn't right.
Well I'd wager your X server has some config somewhere saying to respond to those keys.. but personally I wouldn't know where that is and it's not something Openbox is supposed to be involved in at all.
> Furthermore as you notice I launch kmix to handle the volume. As you yourself
> said it grabs the keys and performs it's task of changing the volume and
> showing the notification popup. Yet when running xev the event still gets
> through in spite of the keys being grabbed and the output is the expected:
>
>
> FocusOut event, serial 47, synthetic NO, window 0x1e00001,
> mode NotifyGrab, detail NotifyAncestor
>
> FocusIn event, serial 47, synthetic NO, window 0x1e00001,
> mode NotifyUngrab, detail NotifyAncestor
>
> KeymapNotify event, serial 47, synthetic NO, window 0x0,
> keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4
> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>
> KeyRelease event, serial 47, synthetic NO, window 0x1e00001,
> root 0x105, subw 0x0, time 2650786, (-594,215), root:(0,502),
> state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume),
> same_screen YES,
> XLookupString gives 0 bytes:
> XFilterEvent returns: False
>
> FocusOut event, serial 47, synthetic NO, window 0x1e00001,
> mode NotifyNormal, detail NotifyNonlinear
>
In this case you see the KeyRelease events but the KeyPress ones are missing (grabbed by kmix I guess). Depending how you grabbed the key it would be possible to eat both the Press and Release, which is why my first thought went that way.
> I don't know why that is. Again I don't experience this under KDE or Fluxbox.
> Something clearly isn't quite right with the way the brightness control keys
> are handled I have no explanation of why that is.
It is quite bizarre that behaviour is different in Fluxbox, but I have to chalk it up to running a different application or changing X settings. Openbox is just another client on the X server and grabs keys like everyone else, it doesn't have control over XInput in any magical way..
> You may be right and me wrong. There may be something I don't
> know/misunderstand. However please look into it and don't be as fast at
> striking this out as my previous bug which after I refiled it with clearer
> details turned out to be quite valid(using _ to set accelerators was
> undocumented).
I'll leave it to think about but I'm not sure where to look really. If openbox doesn't grab the key then it should be no different than any other key, unless you change your settings in X (xmodmap.. config files.. idk..) or other apps interact with it in some way.
Many gnome or KDE apps end up running their backend configuration stuff which mess with X in all kinds of ways to set things up according to their preferences. So while it may not seem to you that you are running gnome-settings-daemon, for example, you may be depending what other things you run. Perhaps something like that is going on.
I'd certainly love to resolve anything that I could but atm this seems outside of Openbox's domain completely to me, so I'm not really sure where to begin besides your X configuration.
Considering that the keys all work as you would like them to, though, I'm not sure what the problem is to be solved, other than some xev output. And like I said, if we're not grabbing the key, then we don't see the key at all and it gets to xev completely outside of channels which we control.
Fair enough so long as it works there really may be nothing to fix.
I just wish I knew what program was grabbing the keys. When I start Openbox standalone I don't know what does it. Perhaps there are other daemons screwing with X in who knows what ways. But so long as it works it's a sin to complain.
Though I may be woefully wrong here I've been thinking and I have come up with yet another explanation of what may be going on. There were times when I've done installs of Arch and Debian on my laptop with no GUI. Out of sheer habbit I started pressing the brightness control keys to adjust to my eyes. Surprisingly enough they worked. Therefore clearly something on a system level much deeper than X also recognizes and responds to these buttons. Perhaps it is that thing which changes the brightness and which grabs the keys. Perhaps KDE and Openbox devs were aware of this and reconfigured it somehow to be changed by their code.
Again I may be woefully wrong here but this may be a possibility.
(In reply to comment #5)
> Fair enough so long as it works there really may be nothing to fix.
>
> I just wish I knew what program was grabbing the keys. When I start Openbox
> standalone I don't know what does it. Perhaps there are other daemons screwing
> with X in who knows what ways. But so long as it works it's a sin to complain.
>
> Though I may be woefully wrong here I've been thinking and I have come up with
> yet another explanation of what may be going on. There were times when I've
> done installs of Arch and Debian on my laptop with no GUI. Out of sheer habbit
> I started pressing the brightness control keys to adjust to my eyes.
> Surprisingly enough they worked. Therefore clearly something on a system level
> much deeper than X also recognizes and responds to these buttons. Perhaps it is
> that thing which changes the brightness and which grabs the keys. Perhaps KDE
> and Openbox devs were aware of this and reconfigured it somehow to be changed
> by their code.
> Again I may be woefully wrong here but this may be a possibility.
If they don't get to X at all, that would explain why they don't show up in Xev, and would also mean that you couldn't bind them to something in Openbox.
Again I don't know. What I said before was just a guess. I don't know how the brightness control keys work but they work.
I just wonder why this doesn't happen in kde or fluxbox. Perhaps they aren't conforming to standards and you are. Perhaps vice versa. This stuff has driven me nuts trying to figure out. I wish I could better understand the source code and fix this myself...
Also you're wrong about me not being about me not being able to bind them to anything.
I added this to the keyboard/keybindings section of my rc.xml as an experiment to see if it'd launch terminator:
<keybind key="XF86MonBrightnessUp">
<action name="Execute">
<startupnotify>
<enabled>true</enabled>
<name>terminator</name>
</startupnotify>
<command>/usr/bin/terminator</command>
</action>
</keybind>
See now here it gets interesting. The keybinding worked. Every time I pressed the brightness increased and terminator got launched. For some perverse reason it got launched not once but twice that is two terminators. Again no clue why. All I can do is describe the symptoms.
What in the name of Richard Matthew Stallman is going on?
Ok I'll give it a shot. See if I can get anything interesting to report back.
From how updated the xorg site is im not too optimistic. Or is that freedesktop.org I recall one of them really being out of date... :(
If I run xev under either KDE or Fluxbox when I hit the brightness control keys xev generates the expected out put namely: FocusOut event, serial 45, synthetic NO, window 0x4a00001, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 45, synthetic NO, window 0x4a00001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 45, synthetic NO, window 0x0, keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 KeyRelease event, serial 45, synthetic NO, window 0x4a00001, root 0x105, subw 0x0, time 4746798, (-14,322), root:(692,370), state 0x0, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False MappingNotify event, serial 45, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 FocusOut event, serial 45, synthetic NO, window 0x4a00001, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 46, synthetic NO, window 0x4a00001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 46, synthetic NO, window 0x0, keys: 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 KeyRelease event, serial 46, synthetic NO, window 0x4a00001, root 0x105, subw 0x0, time 4746813, (-14,322), root:(692,370), state 0x0, keycode 232 (keysym 0x1008ff03, XF86MonBrightnessDown), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False All in all exactly as expected. Now when I run it in Openbox I get this abnormally cryptic output I can't make head or tails of. Now the brightness control keys do control the brightness perfectly well but why this weird output: FocusOut event, serial 39, synthetic NO, window 0x2200001, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 39, synthetic NO, window 0x2200001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 39, synthetic NO, window 0x0, keys: 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 MappingNotify event, serial 39, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 FocusOut event, serial 39, synthetic NO, window 0x2200001, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 39, synthetic NO, window 0x2200001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 39, synthetic NO, window 0x0, keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 FocusOut event, serial 40, synthetic NO, window 0x2200001, mode NotifyNormal, detail NotifyNonlinear VisibilityNotify event, serial 40, synthetic NO, window 0x2200001, state VisibilityFullyObscured Granted I'm not sure how serious of a problem this is but this is definitely an abnormality. I try using xev to find the xf86 name of the brightness controls and get this weird result. That's how I stumbled into the problem. After googling the right name and further experimentation on KDE and Fluxbox it seems the problem must be with Openbox or possibly Xorg and both KDE and Openbox tweaked with who knows what... Interestingly enough the volume controls do respond as expected in xev but they don't actually work. Now I'm not sure if this is a feature or a bug of Openbox. On one hand since there are various sound backends alsa/oss/pulseaudio/etc so Openbox has no way of knowing which you have and what you want the volume control keys to do. On the other hand KDE and in most cases GNOME seem to recognize the keys and perform the appropriate action. Furthermore launching kmix in my autostart.sh works in terms of changing the volume and have that volume control notification popup appear on the center of the screen. I don't know what to make of this.Again I don't know. What I said before was just a guess. I don't know how the brightness control keys work but they work. I just wonder why this doesn't happen in kde or fluxbox. Perhaps they aren't conforming to standards and you are. Perhaps vice versa. This stuff has driven me nuts trying to figure out. I wish I could better understand the source code and fix this myself... Also you're wrong about me not being about me not being able to bind them to anything. I added this to the keyboard/keybindings section of my rc.xml as an experiment to see if it'd launch terminator: <keybind key="XF86MonBrightnessUp"> <action name="Execute"> <startupnotify> <enabled>true</enabled> <name>terminator</name> </startupnotify> <command>/usr/bin/terminator</command> </action> </keybind> See now here it gets interesting. The keybinding worked. Every time I pressed the brightness increased and terminator got launched. For some perverse reason it got launched not once but twice that is two terminators. Again no clue why. All I can do is describe the symptoms. What in the name of Richard Matthew Stallman is going on?