[PATCH] appletouch: add myself as maintainer
After the last patch that broke appletouch for powerbooks again (many more have previously been proposed), I'd like to take over maintainership of this driver to make sure it doesn't break again in the future. Signed-off-by: Johannes Berg [EMAIL PROTECTED] --- MAINTAINERS |6 ++ 1 file changed, 6 insertions(+) --- linux-2.6.orig/MAINTAINERS 2007-10-24 13:44:34.550220973 +0200 +++ linux-2.6/MAINTAINERS 2007-10-24 13:45:31.630206271 +0200 @@ -398,6 +398,12 @@ P: Arnaldo Carvalho de Melo M: [EMAIL PROTECTED] S: Maintained +APPLETOUCH TOUCHPAD DRIVER +P: Johannes Berg +M: [EMAIL PROTECTED] +L: linux-input@atrey.karlin.mff.cuni.cz +S: Maintained + ARC FRAMEBUFFER DRIVER P: Jaya Kumar M: [EMAIL PROTECTED]
Re: [PATCH] Input: Support for a less exclusive grab.
On Tue, Oct 23, 2007 at 11:33:08PM -0400, Dmitry Torokhov wrote: On Tuesday 23 October 2007, Ryan Lortie wrote: On Tue, 2007-23-10 at 14:10 -0400, Dmitry Torokhov wrote: No, rfkill want to see keypresses, period. It does not care if there are other applications also seeing the same keypresses, it just does not want keypresses stolen from it. Right. This is exactly the problem. The current grab API exists to prevent keys from being delivered to normal users, but rfkill still wants to see them. No matter how you slice it, if both of these desires are to be satisfied then there needs to be some sort of a system to differentiate between rfkill and normal users. That's what the priority is here. And the solution is pretty simple - do not use grab. xf86-input-evdev will never open the console in raw mode and toss the data, it's not going to happen. We need a way to, at the absolute minimum, unbind the keyboard from the text console. The current solution sucks for things like rfkill. I'm not convinced that Ryan's fix is any better, but just saying that X should open the console and ignore the characters is simply not an option as far as I am concerned for X. Zephaniah E. Hull. -- Dmitry --
[2.6 patch] input/serio/hp_sdc.c section fix
hp_sdc_exit() mustn't be __exit since it's called from the
__init hp_sdc_register().
This patch fixes the following section mismatch:
-- snip --
...
MODPOST vmlinux.o
...
WARNING: vmlinux.o(.init.text+0x1af68): Section mismatch: reference to
.exit.text:hp_sdc_exit (between 'hp_sdc_register' and 'hp_sdc_mlc_init')
...
-- snip --
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
4022ed345d1b61dc5b6ac0fc35877656e444a11d
diff --git a/drivers/input/serio/hp_sdc.c b/drivers/input/serio/hp_sdc.c
index 6af1998..02b3ad8 100644
--- a/drivers/input/serio/hp_sdc.c
+++ b/drivers/input/serio/hp_sdc.c
@@ -944,11 +944,7 @@ static int __init hp_sdc_init_hppa(struct parisc_device *d)
#endif /* __hppa__ */
-#if !defined(__mc68000__) /* Link error on m68k! */
-static void __exit hp_sdc_exit(void)
-#else
static void hp_sdc_exit(void)
-#endif
{
write_lock_irq(hp_sdc.lock);
Re: [PATCH] Fujitsu application panel driver
On Tue, 23 Oct 2007 12:55:55 -0700
Stephen Hemminger [EMAIL PROTECTED] wrote:
This driver supports the application buttons on some Fujitsu Lifebook
laptops. It is based on the earlier apanel driver done by Jochen
Eisenger, but with many changes. The original driver used ioctl's and
a separate user space program (see http://apanel.sourceforge.net). This
driver hooks into the input subsystem so that the normal keys act as
expected without a daemon. In addition to buttons, the Mail Led is
handled via LEDs class device.
The driver now supports redefinable keymaps and no longer has to
have a DMI table for all Fujitsu laptops.
I thought about mixing this driver should be integrated into the Fujitsu
laptop
extras driver that handles backlight, but rejected the idea because
it wasn't clear if all the Fujitsu laptops supported both.
...
+
+/* Magic constants in BIOS that tell about buttons */
+enum apanel_devid {
+ APANEL_DEV_NONE = 0,
+ APANEL_DEV_APPBTN = 1,
+ APANEL_DEV_CDBTN = 2,
+ APANEL_DEV_LCD= 3,
+ APANEL_DEV_LED= 4,
+ APANEL_DEV_MAX,
+};
APANEL_DEV_MAX == 5.
+enum apanel_chip {
+ CHIP_NONE= 0,
+ CHIP_OZ992C = 1,
+ CHIP_OZ163T = 2,
+ CHIP_OZ711M3 = 4,
+};
+
+/* Result of BIOS snooping/probing -- what features are supported */
+static enum apanel_chip device_chip[APANEL_DEV_MAX];
+
+/* names for APANEL_XXX */
+static const char *device_names[APANEL_DEV_MAX] __initdata = {
We just wasted sizeof(char *)?
+ [APANEL_DEV_APPBTN] = Application Buttons,
+ [APANEL_DEV_LCD]= LCD,
+ [APANEL_DEV_LED]= LED,
+ [APANEL_DEV_CDBTN] = CD Buttons,
+};
+
+
+/* Poll for key changes
+ *
+ * Read Application keys via SMI
+ * A (0x4), B (0x8), Internet (0x2), Email (0x1).
+ *
+ * CD keys:
+ * Forward (0x100), Rewind (0x200), Stop (0x400), Pause (0x800)
+ */
+static void apanel_poll(struct input_polled_dev *ipdev)
+{
+ struct apanel *ap = ipdev-private;
+ struct input_dev *idev = ipdev-input;
+ u8 cmd = device_chip[APANEL_DEV_APPBTN] == CHIP_OZ992C ? 0 : 8;
+ s32 data;
+ int i;
+
+ data = i2c_smbus_read_word_data(ap-client, cmd);
+ if (data 0)
+ return; /* ignore errors (due to ACPI??) */
+
+ /* write back to clear latch */
+ i2c_smbus_write_word_data(ap-client, cmd, 0);
+
+ if (!data)
+ return;
+
+ dev_dbg(ipdev-input-dev, APANEL : data %#x\n, data);
+ for (i = 0; i ipdev-input-keycodemax; i++)
+ if (1ul i data)
You made me google for the c precedence table.
+ report_key(idev, ap-keymap[i]);
+}
...
