On 9/1/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > diff --git a/Documentation/hwmon/sysfs-interface
> > b/Documentation/hwmon/sysfs-interface
> > index b3a9e1b..da546ce 100644
> > --- a/Documentation/hwmon/sysfs-interface
> > +++ b/Documentation/hwmon/sysfs-interface
> > @@ -304,6 +304,21 @@
On 9/1/07, Pavel Machek [EMAIL PROTECTED] wrote:
diff --git a/Documentation/hwmon/sysfs-interface
b/Documentation/hwmon/sysfs-interface
index b3a9e1b..da546ce 100644
--- a/Documentation/hwmon/sysfs-interface
+++ b/Documentation/hwmon/sysfs-interface
@@ -304,6 +304,21 @@
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 b
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).
Signed-off-by: Shem Multinymous [EMAIL PROTECTED]
---
drivers/hwmon/hdaps.c | 17 ++---
1 files changed
On 7/9/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> Sounds good, then. It's a bit of a hack, but the benefits are well
> worth it (if we can resolve the scheduling issue).
You know, I slept on it and I think I want to move the polldev into
opposite direction - to accomodte devices that need
Hi,
On 7/9/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
On Monday 09 July 2007 01:29, Shem Multinymous wrote:
> > Every input event carries a timestamp so even if there are irregularities
> > in taking the samples you should be able to account for it.
>
> The issue i
Hi,
On 7/9/07, Dmitry Torokhov [EMAIL PROTECTED] wrote:
On Monday 09 July 2007 01:29, Shem Multinymous wrote:
Every input event carries a timestamp so even if there are irregularities
in taking the samples you should be able to account for it.
The issue is how good are the input event
On 7/9/07, Dmitry Torokhov [EMAIL PROTECTED] wrote:
Sounds good, then. It's a bit of a hack, but the benefits are well
worth it (if we can resolve the scheduling issue).
You know, I slept on it and I think I want to move the polldev into
opposite direction - to accomodte devices that need
On 7/9/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> > input-polldev uses a separate workqueue, not keventd, and so should not
> > suffer from other workqueue users loading keventd. But if entire box
> > is under stress then workqueue vs timer context does not matter much -
> > your daemon
Hi Dmitry,
On 7/8/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> First, the hdaps driver regularly polls the embedded controller, which
> in turns regularly polls the hardware. If the two polling rates differ
> or fluctuate, we lose events.
That was the case with the original driver as well
On 5/25/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
HWMON: hdaps - convert to use input-polldev.
Switch to using input-polldev skeleton instead of implementing
polling loop by itself. This also fixes problem with trylock
on a mutex in atomic context.
Signed-off-by: Dmitry Torokhov <[EMAIL
On 5/25/07, Dmitry Torokhov [EMAIL PROTECTED] wrote:
HWMON: hdaps - convert to use input-polldev.
Switch to using input-polldev skeleton instead of implementing
polling loop by itself. This also fixes problem with trylock
on a mutex in atomic context.
Signed-off-by: Dmitry Torokhov [EMAIL
Hi Dmitry,
On 7/8/07, Dmitry Torokhov [EMAIL PROTECTED] wrote:
First, the hdaps driver regularly polls the embedded controller, which
in turns regularly polls the hardware. If the two polling rates differ
or fluctuate, we lose events.
That was the case with the original driver as well bit
On 7/9/07, Dmitry Torokhov [EMAIL PROTECTED] wrote:
input-polldev uses a separate workqueue, not keventd, and so should not
suffer from other workqueue users loading keventd. But if entire box
is under stress then workqueue vs timer context does not matter much -
your daemon which is in
On 5/3/07, Anton Vorontsov <[EMAIL PROTECTED]> wrote:
This class is result of "external power" and "battery" classes merge,
as suggested by David Woodhouse. He also implemented uevent support.
Looks great. In particular, the policies you've chosen for the
attributes and units are very
On 5/3/07, Anton Vorontsov [EMAIL PROTECTED] wrote:
This class is result of external power and battery classes merge,
as suggested by David Woodhouse. He also implemented uevent support.
Looks great. In particular, the policies you've chosen for the
attributes and units are very reasonable.
Hi,
On 4/12/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
On Fri, 13 Apr 2007, Anton Vorontsov wrote:
> * Yup, I've read last discussion regarding batteries, and I've seen
> objections against "charge" term, quoting Shem Multinymous:
>
> "
Hi Anton,
On 4/12/07, Anton Vorontsov <[EMAIL PROTECTED]> wrote:
On Thu, Apr 12, 2007 at 11:00:07AM -0400, Shem Multinymous wrote:
> I suggest adding "remaining operating time" and "remaining charging
> time". You can try deducing these from the above attribut
Hi Anton,
A few comments on the ever-contentious choice of battery attributes:
On 4/11/07, Anton Vorontsov <[EMAIL PROTECTED]> wrote:
+ * All voltages, currents, capacities and temperatures in mV, mA, mAh and
+ * tenths of a degree unless otherwise stated. It's driver's job to convert
+ * its
Hi Anton,
A few comments on the ever-contentious choice of battery attributes:
On 4/11/07, Anton Vorontsov [EMAIL PROTECTED] wrote:
+ * All voltages, currents, capacities and temperatures in mV, mA, mAh and
+ * tenths of a degree unless otherwise stated. It's driver's job to convert
+ * its
Hi Anton,
On 4/12/07, Anton Vorontsov [EMAIL PROTECTED] wrote:
On Thu, Apr 12, 2007 at 11:00:07AM -0400, Shem Multinymous wrote:
I suggest adding remaining operating time and remaining charging
time. You can try deducing these from the above attributes, but in
practice this gives very
Hi,
On 4/12/07, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
On Fri, 13 Apr 2007, Anton Vorontsov wrote:
* Yup, I've read last discussion regarding batteries, and I've seen
objections against charge term, quoting Shem Multinymous:
And, for the reasons I explained earlier, I
On 11/30/06, Pavel Machek <[EMAIL PROTECTED]> wrote:
Should we have kernel doing auto-unfreeze? Perhaps we can just mlock()
the daemon?
You could be in the middle of suspend with by-now-frozen userspace; or
maybe the daemon had a SEGV or was accidentally killed. Can't trust
that.
Shem
-
To
On 11/30/06, Pavel Machek <[EMAIL PROTECTED]> wrote:
> >Does hdaps work for you, btw? It gave all zeros on my x60, iirc.
>
> Yes, vanilla hdaps is broken. It blindly issues commands to the
> embedded controller without following the protocol or checking the
> status. The patched version in the
On 11/30/06, Pavel Machek [EMAIL PROTECTED] wrote:
Does hdaps work for you, btw? It gave all zeros on my x60, iirc.
Yes, vanilla hdaps is broken. It blindly issues commands to the
embedded controller without following the protocol or checking the
status. The patched version in the tp_smapi
On 11/30/06, Pavel Machek [EMAIL PROTECTED] wrote:
Should we have kernel doing auto-unfreeze? Perhaps we can just mlock()
the daemon?
You could be in the middle of suspend with by-now-frozen userspace; or
maybe the daemon had a SEGV or was accidentally killed. Can't trust
that.
Shem
-
To
26 matches
Mail list logo
