Openbox does not have a definition for the eject media key

[Fritz Hudnut]

The default configuration in both Lubuntu and upstream Openbox does not include a definition for the eject media key.

Solution:
 1. Open up ~/.config/openbox/lubuntu-rc.xml in an editor
 2. Go to either the beginning or ending of the <keyboard> section
 3. Add this:

  <keybind key="XF86Eject">
    <action name="Execute">
      <command>eject</command>
    </action>
  </keybind>

 4. Save and restart openbox with `openbox --reconfigure`

Note however, though, combining this with a definition for the stop media key could create a potential conflict:

$ xmodmap -pke | grep Eject
keycode 169 = XF86Eject NoSymbol XF86Eject
keycode 170 = XF86Eject XF86Eject XF86Eject XF86Eject
keycode 174 = XF86AudioStop XF86Eject XF86AudioStop XF86Eject

This affects 18.04-19.04.

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

As far as I know, there's no binding in the Openbox configuration for an eject key either upstream or within lubuntu-default-settings, nor has there ever been. Assuming that the keybinding is standardized, we can make it a wishlist item for lubuntu-default-settings, though.

As long as hitting the key in `xev` produces a named keysym (should be XF86Eject), I'd feel relatively comfortable with that. Hopefully you get keycode 204, too.

[Fritz Hudnut (este-el-paz)]

@walter:

Sure, this one isn't a death sentence, I found the same issue in regular Lu 18.04 and filed a bug on it there. I'm over in Gecko right now and in that OS the eject key works . . . possibly I checked it in U-MATE and possibly it works there as well??

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

Regardless of how it works elsewhere, in Openbox it depends on the name of the key and optionally the keycode. It may be different and perhaps more flexible in other window managers. That said, I still need the above information to get this implemented in Lubuntu.

[Fritz Hudnut (este-el-paz)]

"As long as hitting the key in `xev` produces a named keysym (should be XF86Eject), I'd feel relatively comfortable with that. Hopefully you get keycode 204, too."

@walter:

Assuming you are referring to this data . . . I don't know what "xev" is, I am happy to check whatever you would like checked, but I would need "details" on how to provide that info for "us" the next time I'm back in Lu Nxt . . .

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

 1. Open up the terminal
 2. Type xev
 3. Hit enter
 4. Press the eject key
 5. Close the window that was opened by xev
 6. Copy and paste the last "KeyRelease event" from the terminal here

You should have something like (except this is for a different key):

KeyRelease event, serial 40, synthetic NO, window 0x5200001,
    root 0x2c6, subw 0x0, time 412958213, (-187,504), root:(515,575),
    state 0x10, keycode 174 (keysym 0x1008ff15, XF86AudioStop), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

[Fritz Hudnut (este-el-paz)]

This is the last "KeyRelease event" . . . and then there was a **bunch** of "EnterNotify event" and possibly "MotionEvent"??? As far as I recall I just hit the eject key and released it.

code: KeyRelease event, serial 48, synthetic NO, window 0x2a00001,
    root 0x4d6, subw 0x0, time 245022, (289,-470), root:(291,374),
    state 0x0, keycode 169 (keysym 0x1008ff2c, XF86Eject), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

EnterNotify event, serial 49, synthetic NO, window 0x2a00001,
    root 0x4d6, subw 0x0, time 261007, (177,32), root:(179,876),
    mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
    focus YES, state 0
etc:

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

Actually, yeah, that 204 I got from some wiki page. It seems the possible keycodes are:

$ xmodmap -pke | grep Eject
keycode 169 = XF86Eject NoSymbol XF86Eject
keycode 170 = XF86Eject XF86Eject XF86Eject XF86Eject
keycode 174 = XF86AudioStop XF86Eject XF86AudioStop XF86Eject

The fact that 174 is potentially both XF86AudioStop and XF86Eject makes me somewhat concerned but it doesn't look like we're using XF86AudioStop. It's possible some other user is using this and adding something for XF86Eject will maybe break it, which is not necessarily ideal. We could just use the specific keycodes (169, 170) and ignore 174 and let that be a known bug. That's probably my inclination and it wouldn't negatively affect you, Fritz.

I assume you use `eject` on the command line?

[Fritz Hudnut (este-el-paz)]

That is what I am doing now in Lu, using the console command . . . minor inconvenience factor, but considering that Lu Next is like "next gen" in appearance it would be value added to have keyboard full function . . . .

But, interesting and educational to see how each and every action in the gUI generates a command line "call and response" . . . .

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

The question I was trying to ask was what specific command you use.

[Fritz Hudnut (este-el-paz)]

O . . . wow . . . (putting bong down now) . . . didn't know that was a
question . . . sorry . . . (cough, cough) . . . .

I have those commands written down at home and I'm away at work . . . but,
a gentleman posted his command options on my bug report for regular Lu
18.04 . . . it's pretty simple but I can't recall it, or the bug # right
now . . . I'll post back on it . . .

[Fritz Hudnut (este-el-paz)]

"Thomas Schmitt <email address hidden> via canonical.com

Apr 10

to me
Hi,

what happens if you perform one of these shell commands:

  eject /dev/sr0

  xorriso -outdev /dev/sr0 -eject all

In case of failure please report all error messages of the programs.

Have a nice day :)"

@walter: I use the "eject /dev/sr0" and that works . . . I didn't have xorriso installed then, don't think I have it now . . . .

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

Actually `eject` is a standard part of the install and doesn't even require the device name. Obviously if there's more than one device and you want to open one over the other, it needs to be specific, but there's always a default device. That said, the solution is fairly easy:

 1. Open up ~/.config/openbox/lubuntu-rc.xml in an editor
 2. Go to either the beginning or ending of the <keyboard> section
 3. Add this:

  <keybind key="XF86Eject">
    <action name="Execute">
      <command>eject</command>
    </action>
  </keybind>

 4. Save and restart openbox with `openbox --reconfigure`

I'll add this to a future version of lubuntu-default-settings, but you can do that in the meanwhile.

[Fritz Hudnut (este-el-paz)]

@walter:

Alrighty, thanks for that data, I'll check into it in a day or so . . . and post back on results.

As far as the "eject" . . . I think I might have tried that alone, there is only one optical drive, but possibly it didn't work . . . . Some of this might be posted on the regular Lu 18.04 bug report with a similar subject line . . . . But using the "/dev/sr0" . . . seemed to be needed?? I try to keep commands as simple as possible . . . .

[Fritz Hudnut (este-el-paz)]

Ran the suggested commands, but it didn't show anything like <keyboard> ??? Operator error?? I copied/pasted your data with "sudo nano" in front of it and got:
[code]
<?xml version="1.0" encoding="UTF-8"?>

<!-- Do not edit this file, it will be overwritten on install.
        Copy the file to $HOME/.config/openbox/ instead. -->

<openbox_config xmlns="http://openbox.org/3.4/rc"
                xmlns:xi="http://www.w3.org/2001/XInclude">

<resistance>
  <strength>10</strength>
  <screen_edge_strength>20</screen_edge_strength>
</resistance>

<focus>
  <focusNew>yes</focusNew>
  <!-- always try to focus new windows when they appear. other rules do
       apply -->
[end code]

Ran out of time to try other thoughts on it . . . .

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

That can't be the end as that's not even a complete and valid config file. Openbox would complain at you when you tried to run it. My guess is that you're not arrowing down enough. Nano should say "Read 744 lines" in its status when you open it. That doesn't look like 744 lines. :)

The sections are, in order:

 1. resistance
 2. focus
 3. placement
 4. theme
 5. desktops
 6. resize
 7. margins
 8. dock
 9. keyboard
10. mouse
11. menu
12. applications

I believe the keyboard sections starts at line 192. In nano, you can hold CTRL and hit _ and then enter 192 and hit return and it should take you there. You could also use CTRL W (or F6) to start a search. Just enter keyboard and hit enter.

By the way, I think you figured it out, but the name of the file in is actually lxqt-rc.xml for LXQt. I gave the answer for LXDE.

[Fritz Hudnut (este-el-paz)]

Thanks for the reply . . . but, no, I didn't figure anything out . . . I
just copy/pasted what you provided after the "sudo nano" . . . and what I
pasted here is what was there . . . I tried to arrow down or up, but the
scroll bar was "full" . . . i.e., what was showing was the full show . . .
and then the statement about "don't edit this file" etc, etc . . . there
was nothing anywhere along the edges of the window saying something about
"192 pages" . . . as there sometimes might be.

So, maybe I'll try again with the "lxqt" data and see if that shows up as a
big document . . . I was thinking that maybe "nano" is too primitive an
editor for the newer systems, but since you didn't say anything about it
nano is simpler to type . . . .

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

The file is ~/.config/openbox/lxqt-rc.xml. Since it's in your home folder (~), you don't need to sudo anything. I'm not sure what file you're looking at but it's most certainly not the right one based on what you're explaining or unless you broke something. That said, there's no reason why nano can't do the trick, but it might be wise to just open it up in a graphical editor since it's a little more user friendly.

If that still fails then copy /etc/xdg/openbox/lxqt-rc.xml to ~/.config/openbox/lxqt-rc.xml and then follow the instructions above.

[Fritz Hudnut (este-el-paz)]

Success!!! I did use sudo, but using the "lxqt" option brought me to the
"744 lines" and I used your shortcut to get me to line 192 and then
scrolled down to the end right before "mouse" and I dropped your code in
and . . . seems like I must have done "OK" because hitting the eject key .
. . opens the tray!! I'm ready to be hired as a "programmer" . . . . : -
))

Also, as you mentioned in Lu Next just typing "eject" does work . . .
pretty sure it didn't over in reg Lu 18 . . . .

One question . . . now that I've "modified" this file, will anything
"strange" be in store whenever the next update/upgrade comes down the
tubes? Or, will the system "see" that the change has been made and won't
"care"? Or, will it have to be trashed . . .manually??

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

The system won't clobber over your config files on update/upgrade, at least not the ones in your home. It will ask you if it notices that things have changed on systemwide stuff.

[Fritz Hudnut (este-el-paz)]

@walter:

Thanks for the reply . . . haven't had to do an update/upgrade recently,
checked a few days ago and apt said, "nothing to do at this time" . . . .
Sometimes over in one of my "rolling" distros there can be a lot of
"dependency" issues that crop up with updates, requiring actual thought . .
. . I try to avoid that if possible.

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

I'm going to decline this after all because I'm not confident that all keyboards are going to produce the same keycode.