Skip to contentSkip to conversation

via-pmu: report powerbutton as proper input event

PATCH In review Johannes Berg 2 participants 6 messages Apr 28, 2006 – May 1, 2006

Subsystems (2)
Input drivers Linux for power macintosh
lore
Share & tools
lore

Johannes Berg

author
#0 lore raw

PATCH 1/1 via-pmu: report powerbutton as proper input event

This patch adds an input device for the power button so that userspace gets notified about the user pressing it via the standard input layer.

Signed-off-by Johannes Berg <[email protected]>
drivers/macintosh/Makefile +1 -1
@@ -11,7 +11,7 @@ obj-$(CONFIG_MAC_EMUMOUSEBTN)	+= mac_hid
 obj-$(CONFIG_INPUT_ADBHID)	+= adbhid.o
 obj-$(CONFIG_ANSLCD)		+= ans-lcd.o
 
-obj-$(CONFIG_ADB_PMU)		+= via-pmu.o
+obj-$(CONFIG_ADB_PMU)		+= via-pmu.o via-pmu-event.o
 obj-$(CONFIG_ADB_PMU_LED)	+= via-pmu-led.o
 obj-$(CONFIG_ADB_CUDA)		+= via-cuda.o
 obj-$(CONFIG_PMAC_APM_EMU)	+= apm_emu.o
drivers/macintosh/via-pmu-event.c new file +35 -0
@@ -0,0 +1,35 @@
+#include <linux/input.h>
+#include "via-pmu-event.h"
+
+static struct input_dev *pmu_input_dev;
+
+int pmu_event_init(void)
+{
+	pmu_input_dev = input_allocate_device();
+	if (unlikely(!pmu_input_dev))
+		return -ENODEV;
+
+	pmu_input_dev->name = "PMU powerbutton";
+	pmu_input_dev->id.bustype = BUS_PMU;
+	pmu_input_dev->id.vendor = 0x0001;
+	pmu_input_dev->id.product = 0x0001;
+	pmu_input_dev->id.version = 0x0100;
+
+	pmu_input_dev->evbit[0] = BIT(EV_KEY);
+	pmu_input_dev->keybit[LONG(KEY_POWER)] = BIT(KEY_POWER);
+
+	return input_register_device(pmu_input_dev);
+}
+
+void pmu_event_powerbutton(int down)
+{
+	static int powerbutton_pressed;
+
+	if (unlikely(!pmu_input_dev))
+		return;
+	if (powerbutton_pressed == down)
+		return;
+	powerbutton_pressed = down;
+	input_report_key(pmu_input_dev, KEY_POWER, down);
+	input_sync(pmu_input_dev);
+}
drivers/macintosh/via-pmu-event.h new file +8 -0
@@ -0,0 +1,8 @@
+#ifndef __VIA_PMU_EVENT_H
+#define __VIA_PMU_EVENT_H
+
+extern int pmu_event_init(void);
+
+extern void pmu_event_powerbutton(int down);
+
+#endif /* __VIA_PMU_EVENT_H */
include/linux/input.h +1 -0
@@ -658,6 +658,7 @@ struct input_absinfo {
 #define BUS_I2C			0x18
 #define BUS_HOST		0x19
 #define BUS_GSC			0x1A
+#define BUS_PMU			0x20
 
 /*
  * Values describing the status of an effect
drivers/macintosh/via-pmu.c +10 -0
@@ -70,6 +70,7 @@
 #endif
 
 #include "via-pmu-led.h"
+#include "via-pmu-event.h"
 
 /* Some compile options */
 #undef SUSPEND_USES_PMU

@@ -1443,6 +1444,11 @@ next:
 		if (pmu_battery_count)
 			query_battery_state();
 		pmu_pass_intr(data, len);
+		/* if the thing has the powerbutton bit set then
+		 * update the powerbutton key status */
+		if (len == 6) {
+			pmu_event_powerbutton(!!(data[1]&8));
+		}
 	} else {
 	       pmu_pass_intr(data, len);
 	}

@@ -2915,6 +2921,10 @@ static int __init init_pmu_led(void)
 		if (pmu_led_init()) {
 			printk(KERN_WARNING "via-pmu: LED failed to init\n");
 		}
+
+		/* only on keylargo can the power button be on the pmu ... */
+		if (pmu_event_init())
+			printk(KERN_WARNING "via-pmu: couldn't add event device");
 	}
 
 	return 0;
#1 lore raw
Quoted 2 lines · Johannes Berg

This patch adds an input device for the power button so that userspace gets notified about the user pressing it via the standard input layer.

Looks interesting. Waht about other buttons/events the PMU can report ?

include/linux/input.h struct input_absinfo { · line 661

Quoted 8 lines
drivers/macintosh/via-pmu-event.h new file +1 -0
+#endif /* __VIA_PMU_EVENT_H */
include/linux/input.h +1 -0
@@ -658,6 +658,7 @@ struct input_absinfo {
 #define BUS_I2C			0x18
 #define BUS_HOST		0x19
 #define BUS_GSC			0x1A
+#define BUS_PMU			0x20

Magic numbers... BAD BAD BAD ... Somebody needs to LART the input layer people.

include/linux/input.h static int __init init_pmu_led(void) · line 2930

Quoted 11 lines
include/linux/input.h +4 -0
@@ -2915,6 +2921,10 @@ static int __init init_pmu_led(void)
 		if (pmu_led_init()) {
 			printk(KERN_WARNING "via-pmu: LED failed to init\n");
 		}
+
+		/* only on keylargo can the power button be on the pmu ... */
+		if (pmu_event_init())
+			printk(KERN_WARNING "via-pmu: couldn't add event device");
 	}
 
 	return 0;

Do we need these here ? Why not an initcall self-contained in each file ?

Ben.

author
#2 lore raw
Quoted 5 lines · Benjamin Herrenschmidt
Quoted 2 lines · Johannes Berg

This patch adds an input device for the power button so that userspace gets notified about the user pressing it via the standard input layer.

Looks interesting. Waht about other buttons/events the PMU can report ?

What else does it report? As far as I know it doesn't have anything else, at least on my system.

Quoted 4 lines
Quoted 1 line

+#define BUS_PMU 0x20

Magic numbers... BAD BAD BAD ... Somebody needs to LART the input layer people.

It's not really a "magic" number since it doesn't really carry any information, or would you like string identifiers in each device descriptor? An enum would be just the same, in fact, the definition could be rewritten as an enum :)

Quoted 2 lines

Do we need these here ? Why not an initcall self-contained in each file ?

No heh, good point.

Thanks,
johannes

#3 lore raw
Quoted 9 lines · Johannes Berg
Quoted 5 lines · Benjamin Herrenschmidt
Quoted 2 lines · Johannes Berg

This patch adds an input device for the power button so that userspace gets notified about the user pressing it via the standard input layer.

Looks interesting. Waht about other buttons/events the PMU can report ?

What else does it report? As far as I know it doesn't have anything else, at least on my system.

Depends on the machine... earlier ones have the backlight there or volume control.. then LID close could be an event too...

Quoted 17 lines
Quoted 4 lines
Quoted 1 line

+#define BUS_PMU 0x20

Magic numbers... BAD BAD BAD ... Somebody needs to LART the input layer people.

It's not really a "magic" number since it doesn't really carry any information, or would you like string identifiers in each device descriptor? An enum would be just the same, in fact, the definition could be rewritten as an enum :)

Quoted 2 lines

Do we need these here ? Why not an initcall self-contained in each file ?

No heh, good point.

Thanks,
johannes

author
#4 lore raw
Quoted 5 lines · Benjamin Herrenschmidt
Quoted 2 lines

What else does it report? As far as I know it doesn't have anything else, at least on my system.

Depends on the machine... earlier ones have the backlight there or volume control.. then LID close could be an event too...

Ok, yea. Well, we need to rework all of that. Currently, to get at the lid status, you have to open /dev/adb and do something through that.

I honestly don't understand the reason for this. Is it just historic?

johannes

#5 lore raw
Quoted 11 lines · Johannes Berg
Quoted 5 lines · Benjamin Herrenschmidt
Quoted 2 lines

What else does it report? As far as I know it doesn't have anything else, at least on my system.

Depends on the machine... earlier ones have the backlight there or volume control.. then LID close could be an event too...

Ok, yea. Well, we need to rework all of that. Currently, to get at the lid status, you have to open /dev/adb and do something through that.

I honestly don't understand the reason for this. Is it just historic?

Yes.

Ben.