[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090215102707.174e770f@hyperion.delvare>
Date: Sun, 15 Feb 2009 10:27:07 +0100
From: Jean Delvare <khali@...ux-fr.org>
To: Shem Multinymous <multinymous@...il.com>
Cc: Frank Seidel <fseidel@...e.de>,
linux kernel <linux-kernel@...r.kernel.org>,
akpm@...ux-foundation.org, rlove@...ve.org, protasnb@...il.com,
Michael Ruoss <miruoss@...dent.ethz.ch>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Tim Gardner <tim.gardner@...onical.com>,
Frank Seidel <frank@...eidel.de>
Subject: Re: [PATCH] hwmon/hdaps: Fix bug 7154 inversion of separate axis
On Sat, 14 Feb 2009 19:32:02 -0500, Shem Multinymous wrote:
> Hi Frank,
>
> On Fri, Feb 13, 2009 at 7:38 AM, Frank Seidel <fseidel@...e.de> wrote:
> > From: Frank Seidel <frank@...eidel.de>
> >
> > Fix for kernel.org bug #7154:hdaps inversion of
> > each axis. This version is based on the work
> > from Michael Ruoss <miruoss@...dent.ethz.ch>.
> >
> > Signed-off-by: Frank Seidel <frank@...eidel.de>
> > ---
> > drivers/hwmon/hdaps.c | 49 ++++++++++++++++++++++++++++---------------------
> > 1 file changed, 28 insertions(+), 21 deletions(-)
> >
> > --- a/drivers/hwmon/hdaps.c
> > +++ b/drivers/hwmon/hdaps.c
> > @@ -65,6 +65,10 @@
> > #define HDAPS_INPUT_FUZZ 4 /* input event threshold */
> > #define HDAPS_INPUT_FLAT 4
> >
> > +#define HDAPS_X_AXIS 1UL
> > +#define HDAPS_Y_AXIS 2UL
> > +#define HDAPS_BOTH_AXES 3UL
>
> There are more possibilities than these: axes could also switched, for
> a total of 8 possibilities.
Which leads to the simple conclusion that this chip was never meant to
be used as an input device. Think about it: this chip is there to
protect the hard disk drive from shocks. Instead of this we are
proposing to the user to abuse the chip as an input device, that is:
voluntarily shock the laptop. Of course these are small movements,
nothing like a free fall, but I still believe this is conceptually
wrong.
Honestly, who uses this feature in practice? I bet this makes users
laugh for a minute when they discover the feature, and then they forget
about it. I think it would make sense to plain get rid of the input
feature of hdaps.
> See the table at the bottom of the tp_smapi page
> (http://www.thinkwiki.org/wiki/Tp_smapi), or hdaps.c inside the
> tp_smapi package, for more model-specific information.
> It would be nice if you made the interface (constants and their
> meaning) the same as in the tp_smapi version of hdaps, which is
> already widely deployed and packaged by several distros.
Why is this code not upstream? Ah yeah, I remember now: because it was
written by an anonymous developer, which makes the contribution legally
dubious. Copying such code into the upstream version of hdaps would be
no different, so we cannot do that, sorry.
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists