From: "Éric Piel" <eric.piel@tremplin-utc.net>
To: lm-sensors@vger.kernel.org
Subject: Re: [lm-sensors] [RFC PATCH 09/10] lis3: Scale output values to mg
Date: Tue, 10 Nov 2009 13:23:20 +0000 [thread overview]
Message-ID: <4AF96948.1010408@tremplin-utc.net> (raw)
In-Reply-To: <1257250185-7929-10-git-send-email-samu.p.onkalo@nokia.com>
Op 10-11-09 13:47, Daniel Mack schreef:
> Hi,
Hi
> On Tue, Nov 03, 2009 at 02:25:18PM +0100, Éric Piel wrote:
>> * I don't know any userspace program which would be affected by this
>> change (they only rely on the relative difference). Arguably, I know
>> only few programs.
>
> Hmm. Maybe I don't understand the change then. I thought the patch will
> alter the _scale_ of the values to something more standard? If that's
> the case, also applications that take relative changes will be affected,
> right?
Ah, yes, you are right, my mistake. Scale do change the relative
difference as well! But what I actually meant was that the programs
either look if "it's getting smaller/bigger" (aka neverball), or "it's
positive/negative" (aka rotate screen).
>> * Eventually, we should converge to a userspace API compatible with any
>> accelerometer device and exposed by all the accelerometer drivers. So
>> for now I consider the userspace interface of the lis3 driver quite
>> "soft", and any move toward this goal good.
>> * Having platform data to select between old unit/new unit will add
>> complexity to the driver, which should be avoided whenever possible.
>
> True, and I'm not against dropping legacy. However, if it affects every
> user space application, we cannot simply change it. I happen to be
> copied in this thread, so I can react on it, but all other users are
> not.
Yes in general I completely agree with you: if we define some interface
that userspace is supposed to use, "we shall never change it". However,
in this specific case I'm willing to accept the possibility of breakage.
Because in the little chance that a program depends on this specific
metric it is making too much assumption on the hardware anyway: so far,
depending on the type of sensor (8b/12b, hdaps...) the values could be
very different.
Eric
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
next prev parent reply other threads:[~2009-11-10 13:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-03 12:09 [lm-sensors] [RFC PATCH 09/10] lis3: Scale output values to mg Samu Onkalo
2009-11-03 12:17 ` Daniel Mack
2009-11-03 12:30 ` samu.p.onkalo
2009-11-03 12:32 ` Daniel Mack
2009-11-03 13:25 ` Éric Piel
2009-11-06 11:55 ` samu.p.onkalo
2009-11-10 12:47 ` Daniel Mack
2009-11-10 13:23 ` Éric Piel [this message]
2009-11-10 13:31 ` Daniel Mack
2009-11-10 13:42 ` Éric Piel
2009-11-11 7:32 ` Onkalo Samu
2010-04-21 12:10 ` Daniel Mack
2010-04-22 6:33 ` samu.p.onkalo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AF96948.1010408@tremplin-utc.net \
--to=eric.piel@tremplin-utc.net \
--cc=lm-sensors@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.