hwmon: HP Mobile Data Protection System 3D ACPI driver (resend)
Subsystems (2)
PATCH 1/1 hwmon: HP Mobile Data Protection System 3D ACPI driver (resend)
HP Mobile Data Protection System 3D ACPI driver. Similar to hdaps in functionality. This driver provides 4 kinds of functionality:
1) Creates a misc device /dev/accel that acts similar to /dev/rtc and unblocks the process reading from it when the device detects free-fall interrupt
2) Functions as an input class device to provide similar functionality to hdaps, in order to be able to use the laptop as a joystick
3) Provides an interface similar to hdaps, so that hdapsd could work with it
4) Makes it possible to power the device off.
Applications such as hdaps-gl and hdapsd as well as neverball work with this driver unmodified.
Changes:
Fixed all checkpatch warnings/errors
Fixed a potential race in getting the coordinates
Fixed TASK_INTERRUPTIBLE handling
Fixed documentation to state that nw9440 is also supported (it was reported to work)
Documentation/hwmon/mdps +86 -0
@@ -0,0 +1,86 @@ +Kernel driver mdps +================== + +Supported chips: + + * STMicroelectronics LIS3LV02DL and LIS3LV02DQ + +Author: + Yan Burman <[email protected]> + + +Description +----------- + +This driver provides support for the HP Mobile Data Protection +System 3D (mdps), which is an accelerometer. HP nc6420, nw9440 and nx9420 +are supported right now, but it may work on other models as well. The +accelerometer data is readable via /sys/devices/platform/mdps. + +Sysfs attributes under /sys/devices/platform/mdps/: +position - 2D position that the accelerometer reports. Format: "(x,y)" +position3d - 3D position that the accelerometer reports. Format: "(x,y,z)" +calibrate - read: values (x, y) that are used as the base for input class device operation. + write: forces the base to be recalibrated. +rate - reports the sampling rate of the accelerometer device in HZ +state - read: the current power state of the accelerometer device + write: "0" or "1" to power on/off the device +joystick - read: whether the input class device is active or not + write: "0" or "1" to enable/disable the input device + +Load time parameters: +bool joystick - whether to enable the input class device or not (default 1) +bool power_off - whether to power off the device on module load (default 0) +bool hdaps_compat - Make the driver export same interfaces as hdaps, + so that apps like hdaps-gl will work the same as with hdaps (default 0) + The effect of this is: + 1) Instead of /sys/devices/platform/mdps/, /sys/devices/platform/hdaps/ is created + 2) Sensitivity is adjusted to match that of hdaps +bool input_3d - Whether to operate as a 3D input device. (default 0) + BIG FAT WARNING: Do not enable this mode unless you are sure + that you want it, since it eats more CPU + +This driver also provides an absolute input class device, allowing +the laptop to act as a pinball machine-esque joystick. + +Another feature of the driver is misc device called accel that acts +similar to /dev/rtc and reacts on free-fall interrupts received from +the device. It supports blocking operations, poll/select and fasync +operation modes. You must read 4 bytes from the device. +The result is number of free-fall interrupts since the last successful read. + +Example userspace code: + +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> +#include <fcntl.h> +#include <sys/stat.h> +#include <sys/types.h> +#include <string.h> +#include <stdint.h> + +int main(int argc, char* argv[]) +{ + int fd, ret; + uint32_t count; + + fd = open("/dev/accel", O_RDONLY); + if (fd < 0) { + perror("open"); + return EXIT_FAILURE; + } + + for (;;) { + ret = read(fd, &count, sizeof(count)); + if (ret != sizeof(count)) { + perror("read"); + break; + } + + printf("Got %d free-fall interrupts\n", count); + } + + close(fd); + return EXIT_SUCCESS; +}
drivers/hwmon/Kconfig +20 -0
@@ -660,6 +660,26 @@ config SENSORS_HDAPS Say Y here if you have an applicable laptop and want to experience the awesome power of hdaps. +config SENSORS_MDPS + tristate "HP Mobile Data Protection System 3D (mdps)" + depends on ACPI && INPUT && X86 + default n + help + This driver provides support for the HP Mobile Data Protection + System 3D (mdps), which is an accelerometer. HP nc6420, nw9440 and nx9420 + are supported right now, but it may work on other models as well. The + accelerometer data is readable via /sys/devices/platform/mdps. + + This driver also provides an absolute input class device, allowing + the laptop to act as a pinball machine-esque joystick. + + Another feature of the driver is misc device called accel that acts + similar to /dev/rtc and reacts on free-fall interrupts received from + the device. + + This driver can also be built as a module. If so, the module + will be called mdps. + config SENSORS_APPLESMC tristate "Apple SMC (Motion sensor, light sensor, keyboard backlight)" depends on INPUT && X86
drivers/hwmon/Makefile +1 -0
@@ -34,6 +34,7 @@ obj-$(CONFIG_SENSORS_FSCPOS) += fscpos.o obj-$(CONFIG_SENSORS_GL518SM) += gl518sm.o obj-$(CONFIG_SENSORS_GL520SM) += gl520sm.o obj-$(CONFIG_SENSORS_HDAPS) += hdaps.o +obj-$(CONFIG_SENSORS_MDPS) += mdps.o obj-$(CONFIG_SENSORS_IT87) += it87.o obj-$(CONFIG_SENSORS_K8TEMP) += k8temp.o obj-$(CONFIG_SENSORS_LM63) += lm63.o
drivers/hwmon/mdps.c +884 -0
884 lines not on this page · raw message
Quoted 1 line · Yan Burman
3) Provides an interface similar to hdaps, so that hdapsd could work with it
Well, useful HDAPS (the one that is not in-tree :p, see
http://thinkwiki.org/wiki/Tp_smapi, it is distributed as a patch in tp_smapi) is moving to an input device interface. That sysfs attribute "position" was a *bad* way to do it, really.
Signature · 4 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Quoted 8 lines · Yan Burman
HP Mobile Data Protection System 3D ACPI driver. Similar to hdaps in functionality. This driver provides 4 kinds of functionality:
1) Creates a misc device/dev/accelthat acts similar to/dev/rtcand unblocks the process reading from it when the device detects free-fall interrupt
2) Functions as an input class device to provide similar functionality to hdaps, in order to be able to use the laptop as a joystick
3) Provides an interface similar to hdaps, so that hdapsd could work with it
4) Makes it possible to power the device off.
I assume this means 'power the sensor down'? What is interface for that?
Aha, /sys. Could we simply power off the device when its input device is not opened?
Quoted 24 lines
Documentation/hwmon/mdps +24
-0+Description +----------- + +This driver provides support for the HP Mobile Data Protection +System 3D (mdps), which is an accelerometer. HP nc6420, nw9440 and nx9420 +are supported right now, but it may work on other models as well. The +accelerometer data is readable via /sys/devices/platform/mdps. + +Sysfs attributes under /sys/devices/platform/mdps/: +position - 2D position that the accelerometer reports. Format: "(x,y)" +position3d - 3D position that the accelerometer reports. Format: "(x,y,z)" +calibrate - read: values (x, y) that are used as the base for input class device operation. + write: forces the base to be recalibrated. +rate - reports the sampling rate of the accelerometer device in HZ +state - read: the current power state of the accelerometer device + write: "0" or "1" to power on/off the device +joystick - read: whether the input class device is active or not + write: "0" or "1" to enable/disable the input device + +Load time parameters: +bool joystick - whether to enable the input class device or not (default 1) +bool power_off - whether to power off the device on module load (default 0) +bool hdaps_compat - Make the driver export same interfaces as hdaps, + so that apps like hdaps-gl will work the same as with hdaps (default 0)
Documentation/hwmon/mdps line 45
Quoted 10 lines
Documentation/hwmon/mdps +10
-0+ The effect of this is: + 1) Instead of /sys/devices/platform/mdps/, /sys/devices/platform/hdaps/ is created + 2) Sensitivity is adjusted to match that of hdaps +bool input_3d - Whether to operate as a 3D input device. (default 0) + BIG FAT WARNING: Do not enable this mode unless you are sure + that you want it, since it eats more CPU + +This driver also provides an absolute input class device, allowing +the laptop to act as a pinball machine-esque joystick. +
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 12 lines · Pavel Machek
Quoted 9 lines · Yan Burman
HP Mobile Data Protection System 3D ACPI driver. Similar to hdaps in functionality. This driver provides 4 kinds of functionality:
1) Creates a misc device/dev/accelthat acts similar to/dev/rtcand unblocks the process reading from it when the device detects free-fall interrupt
2) Functions as an input class device to provide similar functionality to hdaps, in order to be able to use the laptop as a joystick
3) Provides an interface similar to hdaps, so that hdapsd could work with it
4) Makes it possible to power the device off.
Quoted 7 lines
I assume this means 'power the sensor down'? What is interface for that?
Aha, /sys. Could we simply power off the device when its input device is not opened?
No, we can't since the sys interface provides the position info and some applications (hdaps apps for example) use this interface. It will be very CPU intensive if I power off the device and power it back on every time /sys/ is read - this stuff goes through ACPI for each read/write.
Quoted 38 lines
Quoted 25 lines
Documentation/hwmon/mdps +24
-0+Description +----------- + +This driver provides support for the HP Mobile Data Protection +System 3D (mdps), which is an accelerometer. HP nc6420, nw9440 and nx9420 +are supported right now, but it may work on other models as well. The +accelerometer data is readable via /sys/devices/platform/mdps. + +Sysfs attributes under /sys/devices/platform/mdps/: +position - 2D position that the accelerometer reports. Format: "(x,y)" +position3d - 3D position that the accelerometer reports. Format: "(x,y,z)" +calibrate - read: values (x, y) that are used as the base for input class device operation. + write: forces the base to be recalibrated. +rate - reports the sampling rate of the accelerometer device in HZ +state - read: the current power state of the accelerometer device + write: "0" or "1" to power on/off the device +joystick - read: whether the input class device is active or not + write: "0" or "1" to enable/disable the input device + +Load time parameters: +bool joystick - whether to enable the input class device or not (default 1) +bool power_off - whether to power off the device on module load (default 0) +bool hdaps_compat - Make the driver export same interfaces as hdaps, + so that apps like hdaps-gl will work the same as with hdaps (default 0)Documentation/hwmon/mdps line 45
Quoted 10 lines
Documentation/hwmon/mdps +10
-0+ The effect of this is: + 1) Instead of /sys/devices/platform/mdps/, /sys/devices/platform/hdaps/ is created + 2) Sensitivity is adjusted to match that of hdaps +bool input_3d - Whether to operate as a 3D input device. (default 0) + BIG FAT WARNING: Do not enable this mode unless you are sure + that you want it, since it eats more CPU + +This driver also provides an absolute input class device, allowing +the laptop to act as a pinball machine-esque joystick. +Pavel
Quoted 19 lines · Yan Burman
Quoted 18 lines · Pavel Machek
Quoted 12 lines · Yan Burman
HP Mobile Data Protection System 3D ACPI driver. Similar to hdaps in functionality.
This driver provides 4 kinds of functionality:
1) Creates a misc device/dev/accelthat acts similar to/dev/rtcand unblocks
the process reading from it when the device detects free-fall interrupt
2) Functions as an input class device to provide similar functionality to hdaps, in order to be able to use the laptop as a joystick
3) Provides an interface similar to hdaps, so that hdapsd could work with it
4) Makes it possible to power the device off.I assume this means 'power the sensor down'? What is interface for that?
Quoted 6 lines
Quoted 4 lines
Aha, /sys. Could we simply power off the device when its input device is not opened?
No, we can't since the sys interface provides the position info and some applications (hdaps apps for example) use this interface.
One more reason not to use /sys to access the position data.
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 5 lines · Yan Burman
Quoted 3 lines
Aha, /sys. Could we simply power off the device when its input device is not opened?
No, we can't since the sys interface provides the position info and some applications (hdaps apps for example) use this interface.
Power it off when not used for some time. Power on when opened. -EBUSY while powering on and before it stablizes, if you don't want to get anything userland stuck in D state. This much work might not make sense if your accelerometer doesn't waste resources when enabled.
Heck, try to get rid of that position sysfs crap if you can! It was a bad design idea for hdaps to come up with, there is no reason to let it leak to other drivers.
Input devices are the way to go for this, a joystick-emulation input device (for games and toys), plus a input device that outputs accelerometer data in micro (or mili?) gravities (generic stuff that works with all accelerometers should use this one) and a raw accelerometer data input device (for higly specific signal processing apps) when possible.
HDAPS (the one that matters, which ships in tp_smapi) lacks the g-normalized device, though, but it would be a proper generic accelerometer interface. The in-tree hdaps driver is basically ignored. So some other accelerometer driver gets the dibs on how to implement those interfaces in a proper generic way. Want to be the one? Please? We in hdaps-devel can certainly help with ideas and fix out-of-tree hdaps to also implement the interface.
Signature · 4 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Quoted 18 lines · Henrique de Moraes Holschuh
Quoted 6 lines · Yan Burman
Quoted 4 lines
Aha, /sys. Could we simply power off the device when its input device is not opened?
No, we can't since the sys interface provides the position info and some applications (hdaps apps for example) use this interface.
Power it off when not used for some time. Power on when opened.
-EBUSYwhile powering on and before it stablizes, if you don't want to get anything userland stuck in D state. This much work might not make sense if your accelerometer doesn't waste resources when enabled.Heck, try to get rid of that position sysfs crap if you can! It was a bad design idea for hdaps to come up with, there is no reason to let it leak to other drivers.
Quoted 7 lines
Input devices are the way to go for this, a joystick-emulation input device (for games and toys), plus a input device that outputs accelerometer data in micro (or mili?) gravities (generic stuff that works with all accelerometers should use this one) and a raw accelerometer data input device (for higly specific signal processing apps) when possible.
I don't mind doing it this way, it's just that from what I saw all current applications use the sys interface, so I figured that people would like to be able to use those.
Quoted 4 lines
HDAPS (the one that matters, which ships in
tp_smapi) lacks the g-normalized device, though, but it would be a proper generic accelerometer interface. The in-tree hdaps driver is basically ignored. So some other accelerometer
This is not the impression that I got - I got quite a few responses from people that were using my driver with the hdaps applications that use sys. I just saw gentoo have a package for it and they are using the sys version for the most important feature of this device: HD protection. I got hdapsd to work a while back, so if in-tree hdaps did not change the interface, it should still work with mdps as well.
Debian/Ubuntu also have some stuff for hdaps in their repositories. So it seems to me that people are using the sys interface.
Quoted 5 lines
driver gets the dibs on how to implement those interfaces in a proper generic way. Want to be the one? Please? We in hdaps-devel can certainly help with ideas and fix out-of-tree hdaps to also implement the interface.
I agree that the sys interface is probably not the best choice, but the accelerometer data should provide not only position, but also generate an event when it detects
that it's falling. From what I understood hdaps does not have that info, but mdps and ams do. I am open to suggestions regarding the proper interface assuming it exposes the free-fall events as well, since if you can get an interrupt from the device it's a hell lot better than polling it and doing some heuristics to detect that it's falling. This is especially true for mdps, since each read is rather expensive CPU-wise. I will think about the interface more when I get some more free time.
Quoted 3 lines · Yan Burman
I don't mind doing it this way, it's just that from what I saw all current applications use the sys interface, so I figured that people would like to be able to use those.
Well, they will have to fix their applications to use the input device, if the other drivers do all of us a big favour and NOT implement that hideous crap HDAPS unforunately started with.
That said, if you decide to implement it, we can also live with that. It just takes one warning on the driver to the likes of "warning: application with pid foo is using an outdated, power-wasting interface, please port it to the accelerometer input device" to syslog anytime you notice someone is trying to read it often enough.
HDAPS with input device support is quite new. hdapsd was patched to talk to it, too. I suppose we should port the input device support to the driver in-tree just so that we get it in tree as well. Sounds like an useful reason to bother with in-tree hdaps. Not that it will save much power with the in-tree driver, but at least it will be widely available from there.
Quoted 2 lines
Debian/Ubuntu also have some stuff for hdaps in their repositories. So it seems to me that people are using the sys interface.
They didn't have a choice until a few weeks ago... not for HDAPS, at least.
Quoted 8 lines
Quoted 4 lines
driver gets the dibs on how to implement those interfaces in a proper generic way. Want to be the one? Please? We in hdaps-devel can certainly help with ideas and fix out-of-tree hdaps to also implement the interface.
I agree that the sys interface is probably not the best choice, but the accelerometer data should provide not only position, but also generate an event when it detects
that it's falling. From what I understood hdaps does not have that info,
You can generate events on input devices, but I am not sure that's the best way to go about it for this. Things that block on read until an interrupt happens might work better. And there is also netlink sockets, and other ways to send events to user space. I don't know which way would be best, this is something to ask in LKML.
I'd suggest an accelerometer sysfs interface, that we implement in hdaps (in and out-of-tree), ams and hpmdp. One input device for joystick emulation (optional), one input device with accelerometer data in mg or ug, and an optional one with the raw accelerometer data. Also, an optional way to send events notifying of free-fall to userspace *and* to other kernel drivers (so that you can actually hook it to the queue-freeze engine in-kernel, I fail to see why ams and hpmdp should need userspace at all, unless someone wants to implement their own free-fall algorithms instead of using whatever is in the firmware).
Signature · 4 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Quoted 7 lines · Henrique de Moraes Holschuh
On Wed, 29 Aug 2007, Yan Burman wrote:
HDAPS with input device support is quite new. hdapsd was patched to talk to it, too. I suppose we should port the input device support to the driver in-tree just so that we get it in tree as well. Sounds like an useful reason to bother with in-tree hdaps. Not that it will save much power with the in-tree driver, but at least it will be widely available from there.
In case they'll be of help for such porting, the relevant hdaps patches from my tp_smapi patch series are attached.
Quoted 8 lines
Quoted 4 lines
I agree that the sys interface is probably not the best choice, but the accelerometer data should provide not only position, but also generate an event when it detects
that it's falling. From what I understood hdaps does not have that info,You can generate events on input devices, but I am not sure that's the best way to go about it for this. Things that block on read until an interrupt happens might work better.
You can do the latter via another (4th) input device.
Quoted 3 lines
I'd suggest an accelerometer sysfs interface, that we implement in hdaps (in and out-of-tree), ams and hpmdp. One input device for joystick emulation (optional), one input device with accelerometer data in mg or ug,
Is any of the accelerometer drivers currently capable of computing the physical acceleration? Also, is there an issue of linear vs. angular acceleration?
Quoted 1 line
and an optional one with the raw accelerometer data.
Before or after axis inversion/swapping? The tp_smapi hdaps driver (losslessly) inverts the raw data too, to avoid duplication of model-specific orientation logic.
Quoted 2 lines
unless someone wants to implement their own free-fall algorithms instead of using whatever is in the firmware).
The term "free-fall" is dangerously misleading, for the reasons explained in the IBM APS whitepaper.
Shem
hdaps: Add ID fields to the hdaps joystick-emulation input device
Minor ABI break: the input dev name changes from "hdaps" to a more meaningful "ThinkPad HDAPS joystick emulation", following Documentation/input/input-programming.txt. The bus/vendor/product/version have been coordinated with the maintainer of thinkpad_acpi (the other user of this bus/vendor namespace).
--- drivers/hwmon/hdaps.c | 17 ++++++++++++++--- 1 files changed, 14 insertions(+), 3 deletions(-)
drivers/hwmon/hdaps.c +14 -3
@@ -35,6 +35,7 @@#include <linux/dmi.h> #include <linux/jiffies.h> #include <linux/thinkpad_ec.h> +#include <linux/pci_ids.h> /* Embedded controller accelerometer read command and its result: */ static const struct thinkpad_ec_row ec_accel_args =
@@ -62,9 +63,14 @@ static const struct thinkpad_ec_row ec_accel_args =#define HDAPS_INPUT_FLAT 4#define KMACT_REMEMBER_PERIOD (HZ/10)/* keyboard/mouse persistance */ +/* Input IDs */ +#define HDAPS_INPUT_VENDOR PCI_VENDOR_ID_IBM +#define HDAPS_INPUT_PRODUCT 0x5054/* "TP", shared with thinkpad_acpi */ +#define HDAPS_INPUT_JS_VERSION 0x6801/* Joystick emulation input device */ +static struct timer_list hdaps_timer;static struct platform_device *pdev; -static struct input_dev *hdaps_idev; +static struct input_dev *hdaps_idev;/* joystick-like device with fuzz */ static unsigned int hdaps_invert;static int needs_calibration;
@@ -744,8 +750,13 @@ static int __init hdaps_init(void)/* calibration for the input device (deferred to avoid delay) */ needs_calibration =1 ; -/* initialize the input class */ - hdaps_idev->name ="hdaps" ; +/* initialize the joystick-like fuzzed input device */ + hdaps_idev->name ="ThinkPad HDAPS joystick emulation" ; + hdaps_idev->phys ="hdaps/input0" ; + hdaps_idev->id.bustype =BUS_HOST ; + hdaps_idev->id.vendor =HDAPS_INPUT_VENDOR ; + hdaps_idev->id.product =HDAPS_INPUT_PRODUCT ; + hdaps_idev->id.version =HDAPS_INPUT_JS_VERSION ; hdaps_idev->dev.parent = &pdev->dev; hdaps_idev->evbit[0 ] =BIT (EV_ABS ); input_set_abs_params(hdaps_idev, ABS_X,
Signature · 1 line
1.5.2.4
hdaps: Add a 2nd input device for raw accelerometer data
The current interface used for reading the HDAPS accelerometer requires userspace daemons to poll a sysfs attribute. This causes interrupts on tickless kernels, and introduces a phase difference between the userspace->kernel polling and kernel->hardware polling.
To solve this, this patch introduces an input dev interface to the accelerometer data. It differs from the existing hdaps input dev in that it produces raw measurements, without fuzzing or calibration (but with axis reversal, this the model-specific knowledge is already encoded in the driver).
--- drivers/hwmon/Kconfig | 7 ++++--- drivers/hwmon/hdaps.c | 32 ++++++++++++++++++++++++++++++++ 2 files changed, 36 insertions(+), 3 deletions(-)
drivers/hwmon/Kconfig +4 -3
@@ -608,10 +608,11 @@ config SENSORS_HDAPS This driver provides support for the IBM Hard Drive Active Protection System (hdaps), which provides an accelerometer and other misc. data. ThinkPads starting with the R50, T41, and X40 are supported. The - accelerometer data is readable via sysfs. + accelerometer data is readable via sysfs and via an input device. - This driver also provides an absolute input class device, allowing - the laptop to act as a pinball machine-esque joystick. + This driver also provides another absolute input class device with + calibration and fuzzing, allowing the laptop to act as a pinball + machine-esque joystick. Say Y here if you have an applicable laptop and want to experience the awesome power of hdaps.
drivers/hwmon/hdaps.c +32 -0
@@ -67,10 +67,12 @@ static const struct thinkpad_ec_row ec_accel_args =#define HDAPS_INPUT_VENDOR PCI_VENDOR_ID_IBM#define HDAPS_INPUT_PRODUCT 0x5054/* "TP", shared with thinkpad_acpi */ #define HDAPS_INPUT_JS_VERSION 0x6801/* Joystick emulation input device */ +#define HDAPS_INPUT_RAW_VERSION 0x4801/* Raw accelerometer input device */ static struct timer_list hdaps_timer;static struct platform_device *pdev;static struct input_dev *hdaps_idev;/* joystick-like device with fuzz */ +static struct input_dev *hdaps_idev_raw;/* raw hdaps sensor readouts */ static unsigned int hdaps_invert;static int needs_calibration;
@@ -477,6 +479,9 @@ keep_active:input_report_abs (hdaps_idev,ABS_X , pos_x - rest_x);input_report_abs (hdaps_idev,ABS_Y , pos_y - rest_y);input_sync (hdaps_idev); +input_report_abs (hdaps_idev_raw,ABS_X , pos_x); +input_report_abs (hdaps_idev_raw,ABS_Y , pos_y); +input_sync (hdaps_idev_raw);mod_timer (&hdaps_timer, jiffies +HZ /sampling_rate); }
@@ -747,6 +752,12 @@ static int __init hdaps_init(void) goto out_group; } + hdaps_idev_raw =input_allocate_device (); +if (!hdaps_idev_raw) { + ret = -ENOMEM ; + goto out_idev_first; + } +/* calibration for the input device (deferred to avoid delay) */ needs_calibration =1 ;
@@ -768,12 +779,32 @@ static int __init hdaps_init(void)if (ret) goto out_idev; +/* initialize the raw data input device */ + hdaps_idev_raw->name ="ThinkPad HDAPS accelerometer data" ; + hdaps_idev_raw->phys ="hdaps/input1" ; + hdaps_idev_raw->id.bustype =BUS_HOST ; + hdaps_idev_raw->id.vendor =HDAPS_INPUT_VENDOR ; + hdaps_idev_raw->id.product =HDAPS_INPUT_PRODUCT ; + hdaps_idev_raw->id.version =HDAPS_INPUT_RAW_VERSION ; + hdaps_idev_raw->dev.parent = &pdev->dev; + hdaps_idev_raw->evbit[0 ] =BIT (EV_ABS ); +input_set_abs_params (hdaps_idev_raw,ABS_X ,-32768 ,32767 ,0 ,0 ); +input_set_abs_params (hdaps_idev_raw,ABS_Y ,-32768 ,32767 ,0 ,0 ); + + ret =input_register_device (hdaps_idev_raw); +if (ret) + goto out_idev_reg_first; +mod_timer (&hdaps_timer, jiffies +HZ /sampling_rate);printk (KERN_INFO "hdaps: driver successfully loaded.\n" );return 0 ; +out_idev_reg_first: +input_unregister_device (hdaps_idev); out_idev: +input_free_device (hdaps_idev_raw); +out_idev_first:input_free_device (hdaps_idev); out_group:sysfs_remove_group (&pdev->dev.kobj, &hdaps_attribute_group);
@@ -790,6 +821,7 @@ out: static void __exit hdaps_exit(void) {del_timer_sync (&hdaps_timer); +input_unregister_device (hdaps_idev_raw);input_unregister_device (hdaps_idev);hdaps_device_shutdown ();/* ignore errors, effect is negligible */ sysfs_remove_group (&pdev->dev.kobj, &hdaps_attribute_group);
Signature · 1 line
1.5.2.4
Quoted 10 lines · Shem Multinymous
Quoted 8 lines
Quoted 4 lines
I agree that the sys interface is probably not the best choice, but the accelerometer data should provide not only position, but also generate an event when it detects
that it's falling. From what I understood hdaps does not have that info,You can generate events on input devices, but I am not sure that's the best way to go about it for this. Things that block on read until an interrupt happens might work better.
You can do the latter via another (4th) input device.
We have the events that can be sent over all devices, actually (we can use button events for this). But blocking on read might indeed require a separate input device... or a file, or something like that. And we *definately* should implement something like proper select() and poll() support for the position sysfs attribute.
HDAPS has also some other crap that needs to go over the input device (mouse activity, keyboard activity flags). ams and hpmdp have the "possible shock imminent" events, etc. The goal is to kill all need for userspace to keep pestering the accelerometer driver with open/read/close on sysfs attributes constantly.
Quoted 7 lines
Quoted 3 lines
I'd suggest an accelerometer sysfs interface, that we implement in hdaps (in and out-of-tree), ams and hpmdp. One input device for joystick emulation (optional), one input device with accelerometer data in mg or ug,
Is any of the accelerometer drivers currently capable of computing the physical acceleration? Also, is there an issue of linear vs. angular acceleration?
HDAPS is, if we add the code to calculate it. I suppose the others can, too, if they get the datasheets for the acceleration sensors. However, if it proves too difficult to calculate these values, we will have to do away with it, and instead find a way to export what data we know about the accelerometers (orientation, type of mesaurement, scales of measurement, etc).
As for linear vs angular, we will have to find a way to report either: it will depend on the accelerometer sensor. HDAPS uses only linear, on two axes (bad! ams and hpmdp can do it for three axes). I know of sensors for three axis (also linear), but it is not difficult to imagine people using angular acceleration sensors. Maybe we could export the type of acceleration per-axis or somesuch using sysfs?
Quoted 1 line
Before or after axis inversion/swapping? The
tp_smapihdaps driver
After inversion. The goal is to have something applications can use transparently, so all input devices have to use the same orientation in all platforms. We will have to set those in some arbitrary way, and the drivers will have to do axis inversion when needed.
While one doesn't need (or care) about axis orientation for sudden movement detection (where the really interesting use is :-) ) (it is enough to know the axis are orthogonal to each other), it does matter for toys.
Signature · 4 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Quoted 23 lines · Shem Multinymous
Quoted 10 lines · Henrique de Moraes Holschuh
On Wed, 29 Aug 2007, Yan Burman wrote:
HDAPS with input device support is quite new. hdapsd was patched to talk to it, too. I suppose we should port the input device support to the driver in-tree just so that we get it in tree as well. Sounds like an useful reason to bother with in-tree hdaps. Not that it will save much power with the in-tree driver, but at least it will be widely available from there.
In case they'll be of help for such porting, the relevant hdaps patches from my
tp_smapipatch series are attached.Quoted 5 lines
Quoted 5 lines
I agree that the sys interface is probably not the best choice, but the accelerometer data should provide not only position, but also generate an event when it detects
that it's falling. From what I understood hdaps does not have that info,
Quoted 9 lines
Quoted 4 lines
You can generate events on input devices, but I am not sure that's the best way to go about it for this. Things that block on read until an interrupt happens might work better.
You can do the latter via another (4th) input device.
What's wrong with the stuff I did in mdps? a misc character device that acts like /dev/rtc. Why does it have to be input device oriented?
Quoted 20 lines
Quoted 4 lines
I'd suggest an accelerometer sysfs interface, that we implement in hdaps (in and out-of-tree), ams and hpmdp. One input device for joystick emulation (optional), one input device with accelerometer data in mg or ug,
Is any of the accelerometer drivers currently capable of computing the physical acceleration? Also, is there an issue of linear vs. angular acceleration?
Quoted 2 lines
and an optional one with the raw accelerometer data.
Before or after axis inversion/swapping? The
tp_smapihdaps driver (losslessly) inverts the raw data too, to avoid duplication of model-specific orientation logic.
Quoted 9 lines
Quoted 3 lines
unless someone wants to implement their own free-fall algorithms instead of using whatever is in the firmware).
The term "free-fall" is dangerously misleading, for the reasons explained in the IBM APS whitepaper.
Shem
I also looked at what you did in the patches as well as the modified hdapsd. I'm doing the raw input device right now in the mdps, but I have a suggestion. It seems to me that right now there are at least 3 drivers that provide the same functionality - hdaps, ams and mdps. Why not create the input device that exports raw accelerometer data with a name that is generic - something like accel/input or something along those lines. This way hdapsd could work with any driver that provides the functionality without being hdaps specific.
Yan
Quoted 8 lines · Yan Burman
Quoted 6 lines
Quoted 3 lines
You can generate events on input devices, but I am not sure that's the best way to go about it for this. Things that block on read until an interrupt happens might work better.
You can do the latter via another (4th) input device.
What's wrong with the stuff I did in mdps? a misc character device that acts like
/dev/rtc. Why does it have to be input device oriented?
I am fine with a char device that acts like /dev/rtc, but if we are doing something as heavyweight as a char device, I'd rather we go full generic netlink and send the various events over it. We'd have a netlink device that sends everything over various "channels" and just one input device that does joystick emulation, then.
Can we use a simple sysfs attribute that blocks the caller on write and returns immediately on read? If it has to be more complicated than that, I'd rather we go the netlink path. Any other ideas that are not a char device, not a netlink socket, not an input device node, and not a sysfs attribute?
Quoted 10 lines
I also looked at what you did in the patches as well as the modified hdapsd. I'm doing the raw input device right now in the mdps, but I have a suggestion.
It seems to me that right now there are at least 3 drivers that provide the same functionality - hdaps, ams and mdps. Why not create the input device that exports raw accelerometer data with a name that is generic - something like accel/input or something along those lines. This way hdapsd could work with any driver that provides the functionality without being hdaps specific.
THAT is the idea, IMO. But the naming is userspace's problem (thorugh udev), not ours :-)
Or do you mean the "hardware port" part of the input device? If so, yes, we should try to make standard names for those as that makes it easier for userspace.
Signature · 4 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Quoted 10 lines · Henrique de Moraes Holschuh
Quoted 8 lines · Yan Burman
Quoted 6 lines
Quoted 3 lines
You can generate events on input devices, but I am not sure that's the best way to go about it for this. Things that block on read until an interrupt happens might work better.
You can do the latter via another (4th) input device.
What's wrong with the stuff I did in mdps? a misc character device that acts like
/dev/rtc. Why does it have to be input device oriented?
Quoted 8 lines
I am fine with a char device that acts like
/dev/rtc, but if we are doing something as heavyweight as a char device, I'd rather we go full generic netlink and send the various events over it. We'd have a netlink device that sends everything over various "channels" and just one input device that does joystick emulation, then.Can we use a simple sysfs attribute that blocks the caller on write and returns immediately on read?
Sysfs files support poll, if they are implemented that way. A driver can wake up listeners that wait in poll() for changes.
Kay
Quoted 19 lines · Henrique de Moraes Holschuh
Quoted 10 lines · Yan Burman
Quoted 7 lines
Quoted 4 lines
You can generate events on input devices, but I am not sure that's the best way to go about it for this. Things that block on read until an interrupt happens might work better.
You can do the latter via another (4th) input device.
What's wrong with the stuff I did in mdps? a misc character device that acts like
/dev/rtc. Why does it have to be input device oriented?I am fine with a char device that acts like
/dev/rtc, but if we are doing something as heavyweight as a char device, I'd rather we go full generic netlink and send the various events over it. We'd have a netlink device that sends everything over various "channels" and just one input device that does joystick emulation, then.
Quoted 6 lines
Can we use a simple sysfs attribute that blocks the caller on write and returns immediately on read? If it has to be more complicated than that, I'd rather we go the netlink path. Any other ideas that are not a char device, not a netlink socket, not an input device node, and not a sysfs attribute?
But, how are you going to make the sysfs attribute look generic so that application will not have to know whether to go to /sys/.../mdps /sys/.../hdaps/ or /sys/.../whatever?
I'd probably prefer netlink, since this way it's something more generic and if some more functionality is added, you don't need to start adding more sysfs attributes.
Sorry it took me a while to respond - I was too busy lately.
Quoted 15 lines
Quoted 6 lines
I also looked at what you did in the patches as well as the modified hdapsd. I'm doing the raw input device right now in the mdps, but I have a suggestion.
It seems to me that right now there are at least 3 drivers that provide the same functionality - hdaps, ams and mdps. Why not create the input device that exports raw accelerometer data with a name that is generic - something like accel/input or something along those lines. This way hdapsd could work with any driver that provides the functionality without being hdaps specific.
THAT is the idea, IMO. But the naming is userspace's problem (thorugh udev), not ours :-)
Or do you mean the "hardware port" part of the input device? If so, yes, we should try to make standard names for those as that makes it easier for userspace.
Quoted 3 lines · Yan Burman
But, how are you going to make the sysfs attribute look generic so that application will not have to know whether to go
to/sys/.../mdps/sys/.../hdaps/or/sys/.../whatever?
You use a (new, to be designed and implemented) accelerometer class, and userspace hunts down every device that is a member of that class. Look at how hwmon is doing it in 2.6.22+ and lm-sensors CVS.
Quoted 3 lines
I'd probably prefer netlink, since this way it's something more generic and if some more functionality is added, you don't need to start adding more sysfs attributes.
But you will need to add extra netlink messages, anyway. I don't know for sure what would be the best way.
Signature · 4 lines
"One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh