Eject button handling in quickstart driver

Background: Fujitsu is releasing currently small desktop systems like the ESPRIMO Q510 that have no direct accessible eject button for the optical drive.

http://www.fujitsu.com/fts/products/computing/pc/desktops/all-round/esprimo-q510/index.html

Instead of an eject button on the drive the system has a button on the mainboard that will send a notify event to the assigned device using the following ACPI code:

Scope(\_GPE)
{
       Method(_L15, 0)                                         // ODD Eject GPIO handler {
                Notify(\_SB.ODDE, 0x80)                         // Notify a ODD Eject Button event to the OS
       }
} //Scope(\_GPE)

Scope(\_SB)
{
//
// Direct Application Launch Button definition used for Windows Vista, Windows 7, Linux ... //
       Device(ODDE)                                            // Eject Button Device {
               Name(_HID, EISAID("PNP0C32"))   // HID ACPI button device Name(_UID, 1)                                   // Unique instance # of that device Name(_STA, 0x0F)                                // Device is working properly

               Method(GHID, 0)                                 // Button "role" method {
                       Return(Buffer(){1})                 // Application Launch Button role }
       }

Matthew Garrett advised me that there is a quickstart driver in staging that was designed to handle the PNP0C32 devices. I had a look at it and it needed patching for my purpose because

- the driver only reports the pressed button on wakeup events, but in my case it should report the pressure of the "Optical Disc Drive Eject" button during runtime.
- The driver was generating character input events when I pressed the button during runtime, resulting in the funny question of the bash open if I want to see all possible completions.

So I made a minor change to this driver to handle my "ODDE" button event as I want it and to be minimal intrusive to the remaining functionality.

Of course this needs a small "daemon like skript" that polls the pressed_button file frequently and initiates the eject command if the button is pressed. This one (modified from the Sourceforge quickstart download) works:

#!/bin/bash
#
# Sample application launcher.
# Angelo Arrifano <[email protected]>
# http://quickstart.sourceforge.net
#
# Put this script on ~/.config/autostart.
#

# Add your button actions here
LAUNCH["ODDE"]="eject /dev/sr0"

# The sysfs file telling which button was pressed PRESSEDFILE="/sys/devices/platform/quickstart/pressed_button"

if [[ ! -e "$PRESSEDFILE" ]]; then
       exit 1
fi

while (true) do
PRESSEDBUTTON="$(cat "$PRESSEDFILE")"
if [[ "$PRESSEDBUTTON" != "none" ]]; then
       ${LAUNCH[$PRESSEDBUTTON]};
       echo -n "none" > "$PRESSEDFILE"
fi
sleep 1;
done

# End of script

Signed-off-by Rainer Koenig <[email protected]>

---

drivers/staging/quickstart/quickstart.c 2012-03-07 14:50:36.000000000 +0100 renamed from drivers/staging/quickstart/quickstart.c    2012-03-07 14:32:37.000000000 +0100 +3 -4

@@ -223,10 +223,16 @@
        if (event == QUICKSTART_EVENT_WAKE)
                quickstart_data.pressed = quickstart->btn;
        else if (event == QUICKSTART_EVENT_RUNTIME) {
-               input_report_key(quickstart_input, quickstart->btn->id, 1);
-               input_sync(quickstart_input);
-               input_report_key(quickstart_input, quickstart->btn->id, 0);
-               input_sync(quickstart_input);
+                if (strncasecmp(quickstart->btn->name, "ODDE", 4) == 0) {
+                  /* ODDE is Optical Disc Drive Eject */
+                  quickstart_data.pressed = quickstart->btn;

This is wrong. Since the GHID method returns an arbitrary vendor-specific value, you should just make sure that there's appropriate keymap remapping support and then provide a udev fragment that does the appropriate GHID->keycode assignment. Also, you really do need to report this as KEY_CDEJECT - it's not acceptable to require an acpid script.

I had a look at the driver this morning. Just for testing purposes I changed it in a way that it sends KEY_EJECTCD codes over the input_report_key()-function, but this just works when I also have set the KEY_EJECTCD bit with set_bit() before.

This brings me to the point, how I need to set the bits in that array when the driver is loaded? Setting it with the "0x01" that the GHID method returns is of no use, on the other hand I can replace the keymap with /lib/udev/keymap, but that probably doesn't affect the bits in this array.

The easiest (and maybe possible because BIOS development is just around the corner here) would be to change the ACPI code so that GHID returns the KEY_EJECTCD already, then it works out of the box, but the open
question is if this change will lead do regressions in the already existing Windows driver.

Another idea: Making the quickstart driver aware of common HIDs like the ODDE in my case and creating a correct keymap during driver initalization. Then there is no need to remap GHID results to keycodes
via /lib/udev/keymap. What do you think of this idea?