RE: [ltp] Re: IBM HDAPS Someone interested?

RE: [ltp] Re: IBM HDAPS Someone interested?

[Alejandro Bonilla]

>
> > Well, some piece of software needs to park the HDD when the
> notebook is
> > falling, and that piece of software should better be
> running since the
> > notebook is powered on. Hence my suspicion it's in the
> BIOS. It doesn't
> > have to be visible to the user, at all.
>
> No, the software, under Windows, is an application; you can control
> the behaviour of the disk based on the response of the chip.
>
> Anyway I don't think it's a simple task to create a driver for the
> accelerometer; one thing is to read the data from the chip (I suppose
> it's not too hard), but the most part of the job is to know what to do
> with the data you read.
>
> IBM developed a mathematical model that describes the typical usage of
> the ThinkPad, and they based the action on this math model. Developing
> a free math model is quite hard and also we cannot destroy 5 or 6 TP
> only to see how the signals are produced by the chip in all the
> possible situations (IBM instead can destroy as much TP as
> they want :(
>
> I think the only practical solution is to ask IBM to release a free
> driver for linux; maybe joining our forces we can achive some result.
>
> - --
> Flavio Visentin

What is normally done here in Linux? A mass of people starts sending emails
to IBM to ask for ANY support, or do we have contacts? I have already
contacted the Linux developers that created the Linux driver for the
security chip for the IBM's and they had no clue of what they can do?

If this is the case, and there is no normal way for IBM to release the spec
or driver, then we will need to send emails to IBM, asking for the Linux
support. After all, they claim that they are all into Linux (not all, but
they kind of like it)

What should we do? askibm@info.ibm.com ? Should we go into the Query page
and ask them there? https://www.ibm.com/contact/us/en/query

Lenovo has the PC stuff of IBM, but still, they are fully into it and
therefore will be able to know what they can do here. The support is given
by IBM, not lenovo, they just sell the computers.

????

.Alejandro

Re: [ltp] Re: IBM HDAPS Someone interested?

[Yani Ioannou]

Hi Alejandro,

You aren't the only one interested in a Linux active protection
driver, and unfortunately you aren't the first person to try to get
IBM/Lenevo to release the specs for the interface (the chip
documentation itself is useless without it). Lenevo has clearly stated
in the past that it will not open up the specifications and/or write
an open source Linux driver for it at the moment because they consider
it a competitive advantage, if you search back through the lm_sensors
or lkml archives (I can't remember which I saw it in) you will find
the statement.

I myself have tried to determine where it is interfaced from. I
checked ACPI and I2c/Smbus (I don't recommend the latter, although
experimenting with lm_sensors/i2cdump on a thinkpad is often fatal
I've been lucky on my T42p) but with no luck. I had come to the
conclusion myself that it is interfaced through the embedded
controller. Unfortunately the embedded controller is not that well
supported by Linux itself, except what is supported through the
thinkpad (and company) kernel modules, and Lenz seems to think this is
not the case anyway.

If anyone managed to work out how to interface to the sensors (there
is I believe two sensors, an accelerometer and gyroscope) then I might
be willing to help, although I'm sure I haven't got the agility to
drop my notebook and catch it a few hundred times ;-).

On 6/20/05, Alejandro Bonilla <abonilla@linuxwireless.org> wrote:
> >
> > > Well, some piece of software needs to park the HDD when the
> > notebook is
> > > falling, and that piece of software should better be
> > running since the
> > > notebook is powered on. Hence my suspicion it's in the
> > BIOS. It doesn't
> > > have to be visible to the user, at all.
> >
> > No, the software, under Windows, is an application; you can control
> > the behaviour of the disk based on the response of the chip.

Actually it is kind of both, notice when you are booting the thinkpad
pauses as it calibrates/initializes the sensor. If you are unlucky
enough to be on a bumpy train ride like I have been at times when
trying to boot the sensor subsystem can't calibrate/initialize and
won't let you boot. After that initial test though control seems to be
left to the userspace driver.

Yani

Re: [ltp] Re: IBM HDAPS Someone interested?

[Yani Ioannou]

On 6/20/05, Yani Ioannou <yani.ioannou@gmail.com> wrote:
> Hi Alejandro,
> 
> You aren't the only one interested in a Linux active protection
> driver, and unfortunately you aren't the first person to try to get
> IBM/Lenevo to release the specs for the interface (the chip
> documentation itself is useless without it). Lenevo has clearly stated
> in the past that it will not open up the specifications and/or write
> an open source Linux driver for it at the moment because they consider
> it a competitive advantage, if you search back through the lm_sensors
> or lkml archives (I can't remember which I saw it in) you will find
> the statement.

Ah..here it is:
http://lkml.org/lkml/2005/5/11/163

I guess you already know about that satement then ...err..nevermind :-).

Yani

RE: [ltp] Re: IBM HDAPS Someone interested?

[Alejandro Bonilla]

> Ah..here it is:
> http://lkml.org/lkml/2005/5/11/163
>
> I guess you already know about that satement then
> ...err..nevermind :-).
>
> Yani

Yani,

	What company has ever released a Linux driver, just for the heck of it, or
simply because they wanted it out? Hell no.

(maybe a couple odd ones)

We have to be persistent and ask them to release something, we paid a lot of
money, and I have been missinformed to the fact that IBM loved Linux and
wanted to "support it". Looks like a big lie to me. They don't even need to
release a driver, just information. It is not even something that they only
have. Now we all know that Analog Devices makes the hardware. Not them.

So much for anything. I will keep asking for this information.

If people would send emails to IBM like I have, instead of complaining and
doing pilitical arguments, we probably would have an answer already.

.Alejandro

Re: [ltp] Re: IBM HDAPS Someone interested?

[Yani Ioannou]

On 6/20/05, Alejandro Bonilla <abonilla@linuxwireless.org> wrote:
> Yani,
> 
>         What company has ever released a Linux driver, just for the heck of it, or
> simply because they wanted it out? Hell no.

Actually..a quick search through LKML and lm_sensors reveals quite a
few, but there could always be more.

> We have to be persistent and ask them to release something, we paid a lot of
> money, and I have been missinformed to the fact that IBM loved Linux and
> wanted to "support it". Looks like a big lie to me. They don't even need to
> release a driver, just information. It is not even something that they only
> have. Now we all know that Analog Devices makes the hardware. Not them.

Well, aside from this having nothing to do with IBM anymore, I agree
that I personally don't see the great harm in Lenevo releasing the
information. Many other notebook manufactuers have a similair system
now (Apple powerbooks, and some others) so the competitive advantage
is waning.

> If people would send emails to IBM like I have, instead of complaining and
> doing pilitical arguments, we probably would have an answer already.

I don't see how I did either of those :-|. I simply thought you hadn't
seen the statement, obviously you had. I also wanted to provide what I
thought was important feedback on what I had determined myself about
the system.

Yani

RE: [ltp] Re: IBM HDAPS Someone interested?

[Alejandro Bonilla]

>
> I don't see how I did either of those :-|. I simply thought you hadn't
> seen the statement, obviously you had. I also wanted to provide what I
> thought was important feedback on what I had determined myself about
> the system.
>
> Yani
>

Yani,

	I apologize. I meant not to say this. I'm just frustrated that there are
all this hax0rs and shit, and still no one (even me ((no haxor)) don't know
anything about it.

	Again, I would appreciate any input about getting in touch to the hardware.
And if you can't do that, then we shall organize to ask IBM again, that us,
the Linux users, Want support for this feature, whatever it takes.

	I'm sometimes amazed by the fact that this OEM's simply send us to fuck
off, instead of providing more help or support. In IBM there are a lot of
Linux developers, even here in LKML. It would take them like 20 minutes to
make some sort of interface for this thing. BUT NO!

.Alejandro

RE: [ltp] Re: IBM HDAPS Someone interested?

[Lee Revell]

On Mon, 2005-06-20 at 14:48 -0600, Alejandro Bonilla wrote:
> It would take them like 20 minutes to
> make some sort of interface for this thing. BUT NO! 

Sounds like it would also take 20 minutes to RE, has anyone even tried?

Lee

Re: [ltp] Re: IBM HDAPS Someone interested?

[Alejandro Bonilla]

Lenz Grimmer,

I'm trying to do watch -n1 cat /proc/acpi/ibm/ecdump, But I don't have 
ecdump. I'm with ibm-acpi 0.8

Any idea?

.Alejandro

Re: [ltp] Re: IBM HDAPS Someone interested?

[Lee Revell]

1On Mon, 2005-06-20 at 16:57 -0500, Alejandro Bonilla wrote:
> Lenz Grimmer,
> 
> I'm trying to do watch -n1 cat /proc/acpi/ibm/ecdump, But I don't have 
> ecdump. I'm with ibm-acpi 0.8
> 

I was thinking more along the lines of figure out the io port it's
using, then boot windows, set an IO breakpoint in softice, then drop
your laptop on the bed or something.

Lee

Re: [ltp] Re: IBM HDAPS Someone interested?

[Pavel Machek]

Hi!

> > I'm trying to do watch -n1 cat /proc/acpi/ibm/ecdump, But I don't have 
> > ecdump. I'm with ibm-acpi 0.8
> > 
> 
> I was thinking more along the lines of figure out the io port it's
> using, then boot windows, set an IO breakpoint in softice, then drop
> your laptop on the bed or something.

It should be enough to tilt your laptop so that it parks heads... safer than
dropping it.

And perhaps easier solution is to locate the sensor on the mainboard, and
trace where it is connected with magnifying glass (as vojtech already suggested).

				Pavel

-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

RE: [ltp] Re: IBM HDAPS Someone interested?

[Alejandro Bonilla]

> Hi!
>
> > > I'm trying to do watch -n1 cat /proc/acpi/ibm/ecdump, But
> I don't have
> > > ecdump. I'm with ibm-acpi 0.8
> > >
> >
> > I was thinking more along the lines of figure out the io port it's
> > using, then boot windows, set an IO breakpoint in softice, then drop
> > your laptop on the bed or something.
>
> It should be enough to tilt your laptop so that it parks
> heads... safer than
> dropping it.
>
> And perhaps easier solution is to locate the sensor on the
> mainboard, and
> trace where it is connected with magnifying glass (as vojtech
> already suggested).
>
> 				Pavel
>
> --
> 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51
> time=448769.1 ms
>

/proc/acpi/ibm/ecdump is really not providing any information about this
sensor. yesterday, I almost broke the laptop to see if it would generate
anything, but it really only outputs ACPI events...

I shaked it, moved it 90deg and still no result, threw the lappy from like
40cm to the bed and nothing was really generated. Unless it is too fast like
to generate it in the watch or to be seen by human eye. I dunno.

It looks like /ecdump won't do it.

.Alejandro

Re: [ltp] Re: IBM HDAPS Someone interested?

[Vojtech Pavlik]

On Wed, Jun 22, 2005 at 06:50:59AM -0600, Alejandro Bonilla wrote:
> 
> > Hi!
> >
> > > > I'm trying to do watch -n1 cat /proc/acpi/ibm/ecdump, But
> > I don't have
> > > > ecdump. I'm with ibm-acpi 0.8
> > > >
> > >
> > > I was thinking more along the lines of figure out the io port it's
> > > using, then boot windows, set an IO breakpoint in softice, then drop
> > > your laptop on the bed or something.
> >
> > It should be enough to tilt your laptop so that it parks
> > heads... safer than
> > dropping it.
> >
> > And perhaps easier solution is to locate the sensor on the
> > mainboard, and
> > trace where it is connected with magnifying glass (as vojtech
> > already suggested).
> >
> > 				Pavel
> >
> > --
> > 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51
> > time=448769.1 ms
> >
> 
> /proc/acpi/ibm/ecdump is really not providing any information about this
> sensor. yesterday, I almost broke the laptop to see if it would generate
> anything, but it really only outputs ACPI events...
> 
> I shaked it, moved it 90deg and still no result, threw the lappy from like
> 40cm to the bed and nothing was really generated. Unless it is too fast like
> to generate it in the watch or to be seen by human eye. I dunno.
> 
> It looks like /ecdump won't do it.
 
But that doesn't mean it's not connected to the embedded controller. It
just means the embedded controller doesn't generate any inertial events
by itself - it may have to be polled with some specific command.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [ltp] Re: IBM HDAPS Someone interested?

[Eric Piel]

06/23/2005 09:13 AM, Vojtech Pavlik wrote/a écrit:
> On Wed, Jun 22, 2005 at 06:50:59AM -0600, Alejandro Bonilla wrote:
> 
>>/proc/acpi/ibm/ecdump is really not providing any information about this
>>sensor. yesterday, I almost broke the laptop to see if it would generate
>>anything, but it really only outputs ACPI events...
>>
>>I shaked it, moved it 90deg and still no result, threw the lappy from like
>>40cm to the bed and nothing was really generated. Unless it is too fast like
>>to generate it in the watch or to be seen by human eye. I dunno.
>>
>>It looks like /ecdump won't do it.
> 
>  
> But that doesn't mean it's not connected to the embedded controller. It
> just means the embedded controller doesn't generate any inertial events
> by itself - it may have to be polled with some specific command.
> 

Well, in the changelog of the embedded controller firmware 
(ftp://ftp.software.ibm.com/pc/pccbbs/mobiles/1uhj07us.txt) there is:
- (New) Support for IBM Hard Disk Active Protection System.

I would conclude that the embedded controller is involved with the HDAPS!

Just my two cents.

Eric

RE: [ltp] Re: IBM HDAPS Someone interested?

[Alejandro Bonilla]

  
> > But that doesn't mean it's not connected to the embedded 
> controller. It
> > just means the embedded controller doesn't generate any 
> inertial events
> > by itself - it may have to be polled with some specific command.
> > 
> 
> Well, in the changelog of the embedded controller firmware 
> (ftp://ftp.software.ibm.com/pc/pccbbs/mobiles/1uhj07us.txt) there is:
> - (New) Support for IBM Hard Disk Active Protection System.
> 
> I would conclude that the embedded controller is involved 
> with the HDAPS!
> 
> Just my two cents.
> 
> Eric
> 
OK, awesome. This gives us pretty much a where to go from now.

Should the IBM-ACPI project have anything to do with this? I mean, we should, or could be getting more -vvv information from ecdump or the fact that because this is attached to the embedded controller makes things harder?

.Alejandro

Re: [ltp] Re: IBM HDAPS Someone interested?

[Vojtech Pavlik]

On Thu, Jun 23, 2005 at 06:53:15AM -0600, Alejandro Bonilla wrote:
>   
> > > But that doesn't mean it's not connected to the embedded 
> > controller. It
> > > just means the embedded controller doesn't generate any 
> > inertial events
> > > by itself - it may have to be polled with some specific command.
> > > 
> > 
> > Well, in the changelog of the embedded controller firmware 
> > (ftp://ftp.software.ibm.com/pc/pccbbs/mobiles/1uhj07us.txt) there is:
> > - (New) Support for IBM Hard Disk Active Protection System.
> > 
> > I would conclude that the embedded controller is involved 
> > with the HDAPS!
> > 
> > Just my two cents.
> > 
> > Eric
> > 
> OK, awesome. This gives us pretty much a where to go from now.
> 
> Should the IBM-ACPI project have anything to do with this? I mean, we
> should, or could be getting more -vvv information from ecdump or the
> fact that because this is attached to the embedded controller makes
> things harder?
 
We'll likely have to take a look at the extra IBM ACPI BIOS methods the
BIOS exports and see if any of them is interfacing to the EC.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [ltp] Re: IBM HDAPS Someone interested?

[Eric Piel]

06/23/2005 02:53 PM, Alejandro Bonilla wrote/a écrit:
>   
>>Well, in the changelog of the embedded controller firmware 
>>(ftp://ftp.software.ibm.com/pc/pccbbs/mobiles/1uhj07us.txt) there is:
>>- (New) Support for IBM Hard Disk Active Protection System.
>>
>>I would conclude that the embedded controller is involved 
>>with the HDAPS!
>>
>>Just my two cents.
>>
>>Eric
>>
> 
> OK, awesome. This gives us pretty much a where to go from now.
> 
> Should the IBM-ACPI project have anything to do with this? I mean, we should, or could be getting more -vvv information from ecdump or the fact that because this is attached to the embedded controller makes things harder?
> 
Just to add a few more cents, googling around I found that Paul Sladen 
has already been looking for some info on the chip. Started to RE the 
windows driver, this kind of info _might_ be useful :
Windows drivers read in 28-bytes via an IOCTL(0x733fc) on "\ShockMgr" . 
  (See shockprf.sys)

http://www.paul.sladen.org/thinkpad-r31/accelerometer.html
http://www.paul.sladen.org/thinkpad-r31/aps/

Eric (who is looking forward playing Neverball the Right Way (tm) ;-) )


PS: I don't know Paul Sladen's address and couldn't find it on his 
webpage. Hopping this email address will do it anyway.

Re: [ltp] Re: IBM HDAPS Someone interested?

[Lee Revell]

On Thu, 2005-06-23 at 22:22 +0200, Eric Piel wrote:
> 06/23/2005 02:53 PM, Alejandro Bonilla wrote/a écrit:
> Just to add a few more cents, googling around I found that Paul Sladen 
> has already been looking for some info on the chip. Started to RE the 
> windows driver, this kind of info _might_ be useful :
> Windows drivers read in 28-bytes via an IOCTL(0x733fc) on "\ShockMgr" . 
>   (See shockprf.sys)
> 
> http://www.paul.sladen.org/thinkpad-r31/accelerometer.html
> http://www.paul.sladen.org/thinkpad-r31/aps/
> 
> Eric (who is looking forward playing Neverball the Right Way (tm) ;-) )
> 
> 
> PS: I don't know Paul Sladen's address and couldn't find it on his 
> webpage. Hopping this email address will do it anyway.
> 

Yup, it's just doing port IO.  Get a kernel debugger for windows like
softice and this will be trivial to RE.

READ_PORT_USHORT
WRITE_PORT_UCHAR
READ_PORT_UCHAR

Lee

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Paul Sladen]

On Thu, 23 Jun 2005, Lee Revell wrote:
> Yup, it's just doing port IO.  Get a kernel debugger for windows like
> softice and this will be trivial to RE.
> READ_PORT_USHORT / WRITE_PORT_UCHAR / READ_PORT_UCHAR

There are 3 ports involved.  The 0xed "non-existant delay port" and a pair
of ports that are through the Super-I/O / IDE.  They are used in a
index+value setup similar to reading/writing the AT keyboard controller.

>From what I remember, my conclusion was that these instructions were the
ones to park the heads and then lock the IDE bus.  It's a couple of months
ago, but somewhere I have the simplified version of what it was doing...

	-Paul
-- 
It sometimes snows here.  Cambridge, GB

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Vojtech Pavlik]

On Sat, Jun 25, 2005 at 07:17:33AM +0100, Paul Sladen wrote:
> On Thu, 23 Jun 2005, Lee Revell wrote:
> > Yup, it's just doing port IO.  Get a kernel debugger for windows like
> > softice and this will be trivial to RE.
> > READ_PORT_USHORT / WRITE_PORT_UCHAR / READ_PORT_UCHAR
> 
> There are 3 ports involved.  The 0xed "non-existant delay port" and a pair
> of ports that are through the Super-I/O / IDE.  They are used in a
> index+value setup similar to reading/writing the AT keyboard controller.
> 
> >From what I remember, my conclusion was that these instructions were the
> ones to park the heads and then lock the IDE bus.  It's a couple of months
> ago, but somewhere I have the simplified version of what it was doing...
 
It'd rather surprise me, since parking is usually achieved through
sending a IDE command to the drive, which involves a rather different
set of ports.

The ports you mention could possibly set the IDE channel to a 'reset'
condition, although I doubt that, too.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Pavel Machek]

Hi!


> > Yup, it's just doing port IO.  Get a kernel debugger for windows like
> > softice and this will be trivial to RE.
> > READ_PORT_USHORT / WRITE_PORT_UCHAR / READ_PORT_UCHAR
> 
> There are 3 ports involved.  The 0xed "non-existant delay port" and a pair
> of ports that are through the Super-I/O / IDE.  They are used in a
> index+value setup similar to reading/writing the AT keyboard
> > controller.

I think you got it... 2ports seem like enough for some kind of small
u-controller...

> >From what I remember, my conclusion was that these instructions were the
> ones to park the heads and then lock the IDE bus.  It's a couple of months
> ago, but somewhere I have the simplified version of what it was doing...

Don't think so... parking heads will go through IDE layer...
								Pavel

-- 
Boycott Kodak -- for their patent abuse against Java.

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Vojtech Pavlik]

On Sat, Jun 25, 2005 at 04:47:36PM +0200, Pavel Machek wrote:
> Hi!
> 
> 
> > > Yup, it's just doing port IO.  Get a kernel debugger for windows like
> > > softice and this will be trivial to RE.
> > > READ_PORT_USHORT / WRITE_PORT_UCHAR / READ_PORT_UCHAR
> > 
> > There are 3 ports involved.  The 0xed "non-existant delay port" and a pair
> > of ports that are through the Super-I/O / IDE.  They are used in a
> > index+value setup similar to reading/writing the AT keyboard
> > > controller.
> 
> I think you got it... 2ports seem like enough for some kind of small
> u-controller...
 
Quite possibly the ACPI EC. Most likely a side entrance into the onboard 8042.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Alejandro Bonilla]

Vojtech Pavlik wrote:

>On Sat, Jun 25, 2005 at 04:47:36PM +0200, Pavel Machek wrote:
>  
>
>>Hi!
>>
>>
>>    
>>
>>>>Yup, it's just doing port IO.  Get a kernel debugger for windows like
>>>>softice and this will be trivial to RE.
>>>>READ_PORT_USHORT / WRITE_PORT_UCHAR / READ_PORT_UCHAR
>>>>        
>>>>
>>>There are 3 ports involved.  The 0xed "non-existant delay port" and a pair
>>>of ports that are through the Super-I/O / IDE.  They are used in a
>>>index+value setup similar to reading/writing the AT keyboard
>>>      
>>>
>>>>controller.
>>>>        
>>>>
>>I think you got it... 2ports seem like enough for some kind of small
>>u-controller...
>>    
>>
> 
>Quite possibly the ACPI EC. Most likely a side entrance into the onboard 8042.
>
>  
>
Vojtech,

    What is the onboads 8042?

.Alejandro

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Vojtech Pavlik]

On Sat, Jun 25, 2005 at 01:14:54PM -0500, Alejandro Bonilla wrote:
> >>I think you got it... 2ports seem like enough for some kind of small
> >>u-controller...
> >>   
> >>
> >
> >Quite possibly the ACPI EC. Most likely a side entrance into the onboard 
> >8042.
> >
> > 
> >
> Vojtech,
> 
>    What is the onboads 8042?

Every PC has a small microprocessor on the mainboard, descended from the
ancient Intel i8042. It is primarily intended to take care of the
keyboard and mouse, but in notebooks the input functionality is
overshadowed by other uses.

Those often include: Battery monitoring and communication, display
backlight control, power on/off, and similar stuff.

It is usually accessible through ACPI, and ACPI calls it the EC -
embedded controller. ACPI doesn't mandate the EC to be the 8042, they
could be separate, but for cost reasons, they usually are the same chip.

Since the 8042 is the chip where you attach stuff that no other chip
wants, it's probably the primary choice for connecting the ADXL output.

A small problem is that the 8042 normally doesn't have any ADCs,
however, I assume most of the 8042 implementations in modern notebooks
do have at least a few ADCs, for battery monitoring, etc.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Lenz Grimmer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Vojtech, thanks for the great description.

Vojtech Pavlik wrote:

> Every PC has a small microprocessor on the mainboard, descended from
> the ancient Intel i8042. It is primarily intended to take care of
> the keyboard and mouse, but in notebooks the input functionality is 
> overshadowed by other uses.
> 
> Those often include: Battery monitoring and communication, display 
> backlight control, power on/off, and similar stuff.
> 
> It is usually accessible through ACPI, and ACPI calls it the EC - 
> embedded controller. ACPI doesn't mandate the EC to be the 8042, they
>  could be separate, but for cost reasons, they usually are the same 
> chip.
> 
> Since the 8042 is the chip where you attach stuff that no other chip 
> wants, it's probably the primary choice for connecting the ADXL 
> output.
> 
> A small problem is that the 8042 normally doesn't have any ADCs, 
> however, I assume most of the 8042 implementations in modern 
> notebooks do have at least a few ADCs, for battery monitoring, etc.

Hmm, but isn't that exactly the kind of data that is printed by the
ibm_acpi kernel module in "/proc/acpi/ibm/ecdump" then?

According to the README "this feature dumps the values of 256 embedded
controller registers." So shouldn't the reading of the accelerometers
be included in these values as well?

Or could this mean that the embedded controller might have more than
these 256 registers that could be read out? Or does it need to be "told"
to poll the accelerometer for these values repeatedly?

Many register values in there change automatically (e.g. fan speed), but
so far we have not seen a pattern of register value changes that look
like they are related to acceleration of the laptop in any direction.

Bye,
	LenZ
- --
- ------------------------------------------------------------------
 Lenz Grimmer <lenz@grimmer.com>                             -o)
 [ICQ: 160767607 | Jabber: LenZGr@jabber.org]                /\\
 http://www.lenzg.org/                                       V_V
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCv/IeSVDhKrJykfIRAokmAJ45VnDjUXgopPJrlatdXs1DXoArqACfaJKD
sQgfJr0mZ0JLmypk7HmfxYk=
=qcpP
-----END PGP SIGNATURE-----

RE: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Alejandro Bonilla]

> > A small problem is that the 8042 normally doesn't have any ADCs,
> > however, I assume most of the 8042 implementations in modern
> > notebooks do have at least a few ADCs, for battery monitoring, etc.
>
> Hmm, but isn't that exactly the kind of data that is printed by the
> ibm_acpi kernel module in "/proc/acpi/ibm/ecdump" then?
>
> According to the README "this feature dumps the values of 256 embedded
> controller registers." So shouldn't the reading of the accelerometers
> be included in these values as well?
>
> Or could this mean that the embedded controller might have more than
> these 256 registers that could be read out? Or does it need
> to be "told"
> to poll the accelerometer for these values repeatedly?
>
> Many register values in there change automatically (e.g. fan
> speed), but
> so far we have not seen a pattern of register value changes that look
> like they are related to acceleration of the laptop in any direction.
>
> Bye,
> 	LenZ

Borislav,

	Do you have any input or anything to say? You are probably the one who has
messed more with the ecdump or with the controller and might be able to help
us grow a clue here. Any answer should point us more to were we want.

Could ecdump give any output of the accelerometer?
Could this be really attached to the controller?

.Alejandro

RE: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Lee Revell]

On Mon, 2005-06-27 at 07:10 -0600, Alejandro Bonilla wrote:
>         Do you have any input or anything to say? You are probably the
> one who has
> messed more with the ecdump or with the controller and might be able
> to help
> us grow a clue here. Any answer should point us more to were we want.
> 
> Could ecdump give any output of the accelerometer?
> Could this be really attached to the controller?

IMHO anything other than capturing the port IO from the Windows driver
is a waste of time.  You'll never figure it out with blind guesswork.

Good luck,

Lee 

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Alejandro Bonilla]

Lee Revell wrote:

>On Mon, 2005-06-27 at 07:10 -0600, Alejandro Bonilla wrote:
>  
>
>>        Do you have any input or anything to say? You are probably the
>>one who has
>>messed more with the ecdump or with the controller and might be able
>>to help
>>us grow a clue here. Any answer should point us more to were we want.
>>
>>Could ecdump give any output of the accelerometer?
>>Could this be really attached to the controller?
>>    
>>
>
>IMHO anything other than capturing the port IO from the Windows driver
>is a waste of time.  You'll never figure it out with blind guesswork.
>
>Good luck,
>
>Lee 
>  
>
Lee,

    Any idea on how can I do this? I guess I will need to get myself 
working here...

.Alejandro

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Lee Revell]

On Mon, 2005-06-27 at 22:22 -0500, Alejandro Bonilla wrote:
>     Any idea on how can I do this? I guess I will need to get myself 
> working here...

As I explained at the beginning of the thread, the easiest way is to get
a kernel debugger for Windows like SoftICE and set some IO breakpoints.

Lee

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Vojtech Pavlik]

On Mon, Jun 27, 2005 at 02:33:36PM +0200, Lenz Grimmer wrote:

> Hmm, but isn't that exactly the kind of data that is printed by the
> ibm_acpi kernel module in "/proc/acpi/ibm/ecdump" then?
> 
> According to the README "this feature dumps the values of 256 embedded
> controller registers." So shouldn't the reading of the accelerometers
> be included in these values as well?

Not necessarily. The registers are just a way to communicate with the
EC. For example on the amd8111 chipset, the SMBus is accessed through
the EC, and it takes several writes and reads to initiate an SMBus
transaction.

Similarly here, reading the accelerometer may take more than just
reading the register values.

> Or could this mean that the embedded controller might have more than
> these 256 registers that could be read out?

Unlikely, I believe it's byte addressed. But there may be address and
data registers among those, for accessing specific functionality.

> Or does it need to be "told"
> to poll the accelerometer for these values repeatedly?

Quite possibly.

> Many register values in there change automatically (e.g. fan speed), but
> so far we have not seen a pattern of register value changes that look
> like they are related to acceleration of the laptop in any direction.

It really depends on how IBM implemented it.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Alejandro Bonilla]

Pavel Machek wrote:

>Hi!
>
>
>  
>
>>>Yup, it's just doing port IO.  Get a kernel debugger for windows like
>>>softice and this will be trivial to RE.
>>>READ_PORT_USHORT / WRITE_PORT_UCHAR / READ_PORT_UCHAR
>>>      
>>>
>>There are 3 ports involved.  The 0xed "non-existant delay port" and a pair
>>of ports that are through the Super-I/O / IDE.  They are used in a
>>index+value setup similar to reading/writing the AT keyboard
>>    
>>
>>>controller.
>>>      
>>>
>
>I think you got it... 2ports seem like enough for some kind of small
>u-controller...
>
>  
>
>>>From what I remember, my conclusion was that these instructions were the
>>ones to park the heads and then lock the IDE bus.  It's a couple of months
>>ago, but somewhere I have the simplified version of what it was doing...
>>    
>>
>
>Don't think so... parking heads will go through IDE layer...
>								Pavel
>
>  
>
I have a question here, how do you guys think that the head is parked, 
is it done by the controller directly, which then sends the command to 
the HD to park the head, or this is done by the operating system in some 
kind of way?

I think the OS or user space is too slow like to react to send a park 
command to the hard drive, so this most be done directly by the embedded 
controller, but still I think it needs some input from the OS, to 
initialize it's settings. i.e. after all, in windows you do have the 
settings in the software for HDAPS, but it looks like it is _not_ 
managed by the operating system at all if there is some type of action 
to  be taken. This is also probably why HDAPS won't kick in until 
booted, and that is because it needs to load its config setup by the 
software.

This is what I think, please correct me if I'm saying something crazy.


OS booted, sends settings to the controller, if settings changed, the OS 
will send the settings again to the controller. -> once the controller 
has the configuration from the user, which is in Windows, loaded by 
default, then the controller reacts depending on it's output from the 
accelerometer, sending inmediate commands or parking the head of the HD.

Then also, the OS is either notified about the movement, or actually it 
starts reading from the controller, for example, when doing the 3D view.

The 3D view software takes some time loading, if it would be normally 
monitoring, then It wouldn't take the 4 seconds it takes. I think the OS 
only reads to give the user a clue of their nice feature, but is all 
really done with the controller-> HD.

After all, IBM testing says that HDAPS worked perfectly from a 70cm fall.

.Alejandro

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Vojtech Pavlik]

On Sat, Jun 25, 2005 at 01:13:17PM -0500, Alejandro Bonilla wrote:

> I have a question here, how do you guys think that the head is parked, 
> is it done by the controller directly, which then sends the command to 
> the HD to park the head, or this is done by the operating system in some 
> kind of way?
> 
> I think the OS or user space is too slow like to react to send a park 
> command to the hard drive, so this most be done directly by the embedded 
> controller, but still I think it needs some input from the OS, to 
> initialize it's settings.

The only way to park a drive is to send a command to it through the IDE
interface. This can't be done by the controller itself, since the
controller in the ThinkPad is a classic Intel ICH chip which only passes
commands around.

The OS is definitely fast enough for this kind of task, it's doable even
in userspace, although not easy.

> i.e. after all, in windows you do have the settings in the software
> for HDAPS, but it looks like it is _not_ managed by the operating
> system at all if there is some type of action to  be taken. This is
> also probably why HDAPS won't kick in until booted, and that is
> because it needs to load its config setup by the software.

> This is what I think, please correct me if I'm saying something crazy.

It is definitely all done by the windows kernel driver.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Alejandro Bonilla]

Vojtech Pavlik wrote:

>On Sat, Jun 25, 2005 at 01:13:17PM -0500, Alejandro Bonilla wrote:
>
>  
>
>>I have a question here, how do you guys think that the head is parked, 
>>is it done by the controller directly, which then sends the command to 
>>the HD to park the head, or this is done by the operating system in some 
>>kind of way?
>>
>>I think the OS or user space is too slow like to react to send a park 
>>command to the hard drive, so this most be done directly by the embedded 
>>controller, but still I think it needs some input from the OS, to 
>>initialize it's settings.
>>    
>>
>
>The only way to park a drive is to send a command to it through the IDE
>interface. This can't be done by the controller itself, since the
>controller in the ThinkPad is a classic Intel ICH chip which only passes
>commands around.
>
>The OS is definitely fast enough for this kind of task, it's doable even
>in userspace, although not easy.
>
>  
>
>>i.e. after all, in windows you do have the settings in the software
>>for HDAPS, but it looks like it is _not_ managed by the operating
>>system at all if there is some type of action to  be taken. This is
>>also probably why HDAPS won't kick in until booted, and that is
>>because it needs to load its config setup by the software.
>>    
>>
>
>  
>
>>This is what I think, please correct me if I'm saying something crazy.
>>    
>>
>
>It is definitely all done by the windows kernel driver.
>
>  
>
OK, So if this is done by the user space then I think we can play more 
with it? I guess that we could do a type of hdparm -F or hdparm -S to 
spin down the drive or maybe there is a way to add feature to hdparm to 
park the drive itself.

Aside from what we should do when we get the data... How can we/us/I 
start checking and see if we can find any response from the embedded 
controller?

Do we have to backengineer everything, can we get anything of this from 
IBM-ACPI, or our only way to go here is see if IBM will do anything?

Thanks for all the answers. I really don't want to drop the topic, so 
that we can figure this one out.

.Alejandro

Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Shawn Starr]

Perhaps a kernel space daemon but with some ioctls that userspace can 
manipulate?

Or can the whole daemon be offloaded to userspace? Having some driver ioctls 
and a sysfs interface would allow the KDE and GNOME people to read the sysfs 
info and parse accordingly for some nifty tools.

Sounds good?

Shawn.


On June 25, 2005 16:09, Vojtech Pavlik wrote:
> On Sat, Jun 25, 2005 at 01:13:17PM -0500, Alejandro Bonilla wrote:
> > I have a question here, how do you guys think that the head is parked,
> > is it done by the controller directly, which then sends the command to
> > the HD to park the head, or this is done by the operating system in some
> > kind of way?
> >
> > I think the OS or user space is too slow like to react to send a park
> > command to the hard drive, so this most be done directly by the embedded
> > controller, but still I think it needs some input from the OS, to
> > initialize it's settings.
>
> The only way to park a drive is to send a command to it through the IDE
> interface. This can't be done by the controller itself, since the
> controller in the ThinkPad is a classic Intel ICH chip which only passes
> commands around.
>
> The OS is definitely fast enough for this kind of task, it's doable even
> in userspace, although not easy.
>
> > i.e. after all, in windows you do have the settings in the software
> > for HDAPS, but it looks like it is _not_ managed by the operating
> > system at all if there is some type of action to  be taken. This is
> > also probably why HDAPS won't kick in until booted, and that is
> > because it needs to load its config setup by the software.
> >
> > This is what I think, please correct me if I'm saying something crazy.
>
> It is definitely all done by the windows kernel driver.

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Alejandro Bonilla]

>>This is what I think, please correct me if I'm saying something crazy.
>>    
>>
>
>It is definitely all done by the windows kernel driver.
>
>  
>
Guys,

    We might have something here. If you are a driver writer, developer 
or want to help us, this is when.

PLEASE read the following article, it has the data of a guy that made a 
driver in IBM for Linux and he described the driver he made. He cannot 
release it, but he explained it and someone can write one. Believe me, 
that I would do it, if I would have any knowledge. ;-)
http://www.almaden.ibm.com/cs/people/marksmith/tpaps.html


If you have an IBM Thinkpad with HDAPS, this is when you can help us 
with a driver.

Thanks,

.Alejandro

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Vojtech Pavlik]

On Sun, Jul 03, 2005 at 03:37:06AM -0500, Alejandro Bonilla wrote:

> Guys,
> 
>    We might have something here. If you are a driver writer, developer 
> or want to help us, this is when.
> 
> PLEASE read the following article, it has the data of a guy that made a 
> driver in IBM for Linux and he described the driver he made. He cannot 
> release it, but he explained it and someone can write one. Believe me, 
> that I would do it, if I would have any knowledge. ;-)
> http://www.almaden.ibm.com/cs/people/marksmith/tpaps.html

This should indeed be enough to write a Linux driver.

> If you have an IBM Thinkpad with HDAPS, this is when you can help us 
> with a driver.
 
I don't yet. 

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Jesper Juhl]

On 7/3/05, Vojtech Pavlik <vojtech@suse.cz> wrote:
> On Sun, Jul 03, 2005 at 03:37:06AM -0500, Alejandro Bonilla wrote:
> 
> > Guys,
> >
> >    We might have something here. If you are a driver writer, developer
> > or want to help us, this is when.
> >
> > PLEASE read the following article, it has the data of a guy that made a
> > driver in IBM for Linux and he described the driver he made. He cannot
> > release it, but he explained it and someone can write one. Believe me,
> > that I would do it, if I would have any knowledge. ;-)
> > http://www.almaden.ibm.com/cs/people/marksmith/tpaps.html
> 
> This should indeed be enough to write a Linux driver.
> 
I'll give it a shot. I've got the day off today so I'll try a simple
module and test it on my T42. I'll post whatever I come up with
tonight.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Jesper Juhl]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

Jesper Juhl wrote:
> On 7/3/05, Vojtech Pavlik <vojtech@suse.cz> wrote:
> 
>>On Sun, Jul 03, 2005 at 03:37:06AM -0500, Alejandro Bonilla wrote:
>>
>>
>>>Guys,
>>>
>>>   We might have something here. If you are a driver writer, developer
>>>or want to help us, this is when.
>>>
>>>PLEASE read the following article, it has the data of a guy that made a
>>>driver in IBM for Linux and he described the driver he made. He cannot
>>>release it, but he explained it and someone can write one. Believe me,
>>>that I would do it, if I would have any knowledge. ;-)
>>>http://www.almaden.ibm.com/cs/people/marksmith/tpaps.html
>>
>>This should indeed be enough to write a Linux driver.
>>
> 
> I'll give it a shot. I've got the day off today so I'll try a simple
> module and test it on my T42. I'll post whatever I come up with
> tonight.
> 
Ok, just to show you people what I've done so far.
This doesn't work yet, but it should be resonably close (at least it
builds ;)

Stuff the two (attached) files into some directory, then build with
     make -C /path/to/kernel/source SUBDIRS=$PWD modules

it may blow up, it may do anything, I take no responsability for it in
its current state - play with it at your own risk.


-- 
Jesper Juhl


[-- Attachment #2: Makefile --]
[-- Type: text/plain, Size: 22 bytes --]

obj-m := ibm_hdaps.o


[-- Attachment #3: ibm_hdaps.c --]
[-- Type: text/x-csrc, Size: 7150 bytes --]

/*
 * Driver for IBM HDAPS (HardDisk Active Protection system)
 *
 * Based on the document by Mark A. Smith available at
 * http://www.almaden.ibm.com/cs/people/marksmith/tpaps.html
 *
 * Copyright (c) 2005  Jesper Juhl <jesper.juhl@gmail.com>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
 */



#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/config.h>
#include <linux/compiler.h>
#include <linux/ioport.h>
#include <linux/timer.h>
#include <linux/delay.h>
#include <asm/io.h>



#define HDAPS_LOW_PORT	0x1600	/* first port used by accelerometer */
#define HDAPS_NR_PORTS	0x30	/* nr of ports total - 0x1600 through 0x162f */

#define STATE_STALE	0x00	/* accelerometer data is stale */
#define STATE_FRESH	0x50	/* accelerometer data fresh fresh */

#define REFRESH_ASYNC	0x00	/* do asynchronous refresh */
#define REFRESH_SYNC	0x01	/* do synchronous refresh */

/* 
 * where to find the various accelerometer data
 * these map to the members of struct hdaps_accel_data
 */
#define HDAPS_PORT_STATE	0x1611
#define	HDAPS_PORT_XACCEL	0x1612
#define HDAPS_PORT_YACCEL	0x1614
#define HDAPS_PORT_TEMP		0x1616
#define HDAPS_PORT_XVAR		0x1617
#define HDAPS_PORT_YVAR		0x1619
#define HDAPS_PORT_TEMP2	0x161b
#define HDAPS_PORT_UNKNOWN	0x161c
#define HDAPS_PORT_KMACCT	0x161d

/* structure to hold data from the accelerometer */
struct hdaps_accel_data {
	unsigned char	state;		/* accelerometer state */
	unsigned short	x_accel;	/* X acceleration value */
	unsigned short	y_accel;	/* Y acceleration value */
	unsigned char	temp;		/* accelerometer temp (in celcius) */
	unsigned short	x_variation;	/* this might hold something else */
	unsigned short	y_variation;	/* this might hold something else */
	unsigned char	temp2;		/* really the temperature again? */
	unsigned char	unknown;	/* we don't know what this holds */
	unsigned char	km_activity;	/* any keyboard/mouse activity */
};

/* check a port latch for a given value */
static unsigned int check_latch(unsigned short port, unsigned char val)
{
	unsigned read;
	read = inb(port & 0xff);
	if (read == val)
		return 1;

	return 0;
}

/* wait for a latch to get a certain value for up to 50 microseconds */
static unsigned int wait_latch(unsigned short port, unsigned char val)
{
	unsigned char i;
	
	for (i = 0; i < 10; i++) {
		if (check_latch(port, val))
			return 1;
		udelay(5);
	}

	return 0;
}

/* check the refresh state of the accelerometer */
unsigned int check_state(void)
{
	unsigned state;

	state = inb(0x1604);
	if (state != STATE_FRESH)
		state = STATE_STALE;

	return state;
}

/* request a refresh from accelerometer */
static int request_refresh(int sync)
{
	unsigned state;
	
	state = check_state();
	if (state == STATE_FRESH) {
		return 1;
	} else {
		outb(0x1610, 0x11);
		outb(0x161f, 0x01);
		if (sync)
			return wait_latch(0x1604, STATE_FRESH);
	}

	/* if we get here we didn't do a synchronous wait and all we can say
	 * is that we initiated the refresh request, so the state *ought* to
	 * be fresh when read next time - but no guarantees.
	 * Do a synchronous wait if you need to be sure you read fresh data.
	 */
	return 1;
}

/* indicate to the accelerometer that we are done reading data */
static void tell_accelerometer_done(void)
{
	inb(0x161f);
	inb(0x1604);
}

/* read accelerometer data into provided struct, return success or failure */
unsigned int accelerometer_read(struct hdaps_accel_data *data) {
	/* do a sync refresh - we need to be sure we read fresh data */
	if (!request_refresh(REFRESH_SYNC))
		return 0;
	
	data->state = inb(HDAPS_PORT_STATE);
	data->x_accel = inw(HDAPS_PORT_XACCEL);
	data->y_accel = inw(HDAPS_PORT_YACCEL);
	data->temp = inb(HDAPS_PORT_TEMP);
	data->x_variation = inw(HDAPS_PORT_XVAR);
	data->y_variation = inw(HDAPS_PORT_YVAR);
	data->temp2 = inb(HDAPS_PORT_TEMP2);
	data->unknown = inb(HDAPS_PORT_UNKNOWN);
	data->km_activity = inb(HDAPS_PORT_KMACCT);

	tell_accelerometer_done();
	return request_refresh(REFRESH_ASYNC);
}

/* initialize the accelerometer, wait up to `timeout' seconds for success */
int accelerometer_init(unsigned int timeout)
{
	unsigned long wait_until = jiffies + timeout * HZ;
	
	outb(0x13, 0x1610);
	outb(0x01, 0x161f);
 	if (!wait_latch(0x00, 0x161f))
		return -EIO;
	if (!wait_latch(0x03, 0x1611))
		return -EIO;
	outb(0x17, 0x1610);
	outb(0x81, 0x1611);
	outb(0x01, 0x161f);
	if (!wait_latch(0x00, 0x161f))
		return -EIO;
	if (!wait_latch(0x00, 0x1611))
		return -EIO;
	if (!wait_latch(0x60, 0x1612))
		return -EIO;
	if (!wait_latch(0x00, 0x1613))
		return -EIO;
	outb(0x14, 0x1610);
	outb(0x01, 0x1611);
	outb(0x01, 0x161f);
	if (!wait_latch(0x00, 0x161f))
		return -EIO;
	outb(0x10, 0x1610);
	outb(0xc8, 0x1611);
	outb(0x00, 0x1612);
	outb(0x02, 0x1613);
	outb(0x01, 0x161f);
	if (!wait_latch(0x00, 0x161f))
		return -EIO;
	if (!request_refresh(REFRESH_SYNC))
		return -EIO;
	if (!wait_latch(0x00, 0x1611))
		return -EIO;

	while (1) {
		if (wait_latch(0x02, 0x1611)) {
			struct hdaps_accel_data data;
			/* 
			 * accelerometer initialized, do an initial read and
			 * return success.
			 */
			 accelerometer_read(&data);
			return 0;
		} else if (time_before(jiffies, wait_until)) {
			set_current_state(TASK_INTERRUPTIBLE);
			schedule_timeout(HZ);
		} else {
			/* we timed out, return failure */
			return -ENXIO;
		}
	}
}

static int ibm_hdaps_init(void)
{
	int i;
	int retval;
	struct hdaps_accel_data data;

	printk(KERN_WARNING "init 1\n");
	if (!request_region(HDAPS_LOW_PORT, HDAPS_NR_PORTS, "ibm_hdaps"))
		return -ENXIO;

	printk(KERN_WARNING "init 2\n");
	retval = accelerometer_init(10);
	if (retval)
		return retval;

	printk(KERN_WARNING "init 3\n");
	for (i = 0; i < 5; i++) {
		accelerometer_read(&data);
		printk(KERN_WARNING "state = %d\n", data.state);
		printk(KERN_WARNING "x_accel = %d\n", data.x_accel);
		printk(KERN_WARNING "y_accel = %d\n", data.y_accel);
		printk(KERN_WARNING "temp = %d\n", data.temp);
		printk(KERN_WARNING "x_variation = %d\n", data.x_variation);
		printk(KERN_WARNING "y_variation = %d\n", data.y_variation);
		printk(KERN_WARNING "temp2 = %d\n", data.temp2);
		printk(KERN_WARNING "unknown = %d\n", data.unknown);
		printk(KERN_WARNING "km_activity = %d\n", data.km_activity);
		printk(KERN_WARNING "\n");
	}

	printk(KERN_WARNING "init 4\n");
	return 0;
}

static void ibm_hdaps_exit(void)
{
	release_region(HDAPS_LOW_PORT, HDAPS_NR_PORTS);
}

module_init(ibm_hdaps_init);
module_exit(ibm_hdaps_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Jesper Juhl");

Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Dave Hansen]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

On Sun, 2005-07-03 at 20:17 +0200, Jesper Juhl wrote:
> Ok, just to show you people what I've done so far.
> This doesn't work yet, but it should be resonably close (at least it
> builds ;)

On top of what you sent at first this morning (not the most recent one)
I did some stuff (in the attached patch).  It implements the last bit of
initialization that your earlier one didn't do, but I see you've done in
the most recent one.

Anyway, I get 10 reads out of it, 1 second apart, and it appears to be
getting real data:

10 seconds while tilting my thinkpad around:

x_accel: 372
y_accel: 339
x_accel: 475
y_accel: 396
x_accel: 429
y_accel: 414
x_accel: 441
y_accel: 519
x_accel: 431
y_accel: 525
x_accel: 387
y_accel: 311
x_accel: 389
y_accel: 246
x_accel: 385
y_accel: 266

10 seconds of stationary reads:

x_accel: 368
y_accel: 390
x_accel: 368
y_accel: 391
x_accel: 368
y_accel: 390
x_accel: 369
y_accel: 390
x_accel: 369
y_accel: 391
x_accel: 369
y_accel: 390
x_accel: 370
y_accel: 390
x_accel: 369
y_accel: 392
x_accel: 369
y_accel: 392
x_accel: 368
y_accel: 390
x_accel: 368
y_accel: 391


-- Dave

[-- Attachment #2: accel-0.diff --]
[-- Type: text/x-patch, Size: 4931 bytes --]

--- accelerometer.c.orig	2005-07-03 11:37:07.000000000 -0700
+++ accelerometer.c	2005-07-03 12:16:50.000000000 -0700
@@ -53,17 +53,17 @@
 
 static inline int latch_wait(unsigned char value, unsigned short port)
 {
-	printk(KERN_DEBUG DRV_NAME ": latch_wait(0x%x, 0x%x)\n", value, port);
-
 	int status = 0;
 	int i;
 
-	for (i = 0; i < 10; i++) {
+	printk(KERN_DEBUG DRV_NAME ": latch_wait(0x%x, 0x%x)\n", value, port);
+
+	for (i = 0; i < 100; i++) {
 		if (latch_check(value, port)) {
 			status = 1;
 			break;
 		}
-		udelay(5);
+		udelay(10);
 	}
 
 	return status;
@@ -78,9 +78,9 @@
 
 static inline int refresh(int synchronous)
 {
-	printk(KERN_DEBUG DRV_NAME ": refresh(%d)\n", synchronous);
-
 	int status = 0;
+	
+	printk(KERN_DEBUG DRV_NAME ": refresh(%d)\n", synchronous);
 
 	if (refresh_check()) {
 		status = 1;
@@ -103,29 +103,54 @@
 	inb(0x1604);
 }
 
-static int read(void)
-{
-	printk(KERN_DEBUG DRV_NAME ": read()\n");
+struct accelerometer_data { 
+	unsigned char state;
+	unsigned short x_accel;
+	unsigned short y_accel;
+	unsigned char temperature_a;
+	unsigned short x_variation;
+	unsigned short y_variation;
+	unsigned char temperature_b;
+	unsigned char unknown;
+	unsigned char mk_use;
+} __attribute__ ((packed));
 
+static int read(int print)
+{
+	int i;
 	int status = 0;
+	struct accelerometer_data d;
+
+	printk(KERN_DEBUG DRV_NAME ": read()\n");
 
 	if (refresh(ACCELEROMETER_SYNC)) {
+		for (i=0; i< sizeof(struct accelerometer_data); i++) {
+			((unsigned char *)(&d))[i] = inb(0x1611 + i);
+		}
+
 		/* FIXME: read data from 0x1611 through 0x161E */
 
 		read_done();
 		refresh(ACCELEROMETER_ASYNC);
 		status = 1;
 	}
+	if (print) {
+		//for (i=0; i< sizeof(struct accelerometer_data); i++)
+		//	printk("data[%2d]: %02x\n", i, ((unsigned char *)(&d))[i]);
+		printk("x_accel: %d\n", d.x_accel);
+		printk("y_accel: %d\n", d.y_accel);
+	}
 
 	return status;
 }
 
 static int initialize(void)
 {
+	int ret = -EIO;
 	outb(0x13, 0x1610);
 	outb(0x01, 0x161f);
 	if (! latch_wait(0x0, 0x161f))
-		return -EIO;
+		return ret;
 	if (! latch_wait(0x3, 0x1611))
 		return -EIO;
 
@@ -140,6 +165,7 @@
 		return -EIO;
 	if (! latch_wait(0x0, 0x1613))
 		return -EIO;
+	printk("%s() 5\n", __func__);
 
 	outb(0x14, 0x1610);
 	outb(0x01, 0x1611);
@@ -159,9 +185,57 @@
 	if (! latch_wait(0x0, 0x1611))
 		return -EIO;
 
-	/* FIXME: finish init sequence */
+/*
+ * I issue an outb at port 0x1610 of value 0x13,
+ * followed by an outb at port 0x161f of value 0x01.
+ * I then waits for latch 0x161f for value 0x0,
+ * and then wait for latch 0x1611 for value 0x3.
+ *
+ * Three more outbs at ports 0x1610, 0x1611, and 0x161f of values 0x17, 0x81, and 0x01, respectively follow.
+ *
+ * Four more waits for latches 0x161f, 0x1611, 0x1612, and 0x1613 for values 0x0, 0x0, 0x60, and 0x0 respectively.
+ * Then three more outbs at ports 0x1610, 0x1611, and 0x161f of values 0x14, 0x01, and 0x01.
+ *
+ * Then I wait for latch 0x161f for value 0x0.
+ * Then five outbs at ports 0x1610, 0x1611, 0x1612, 0x1613, and 0x161f of values 0x10, 0xc8, 0x00, 0x02, and 0x01
+ *
+ * I then wait for latch 0x161f for value 0x0 again.
+ *
+ * I then issues a synchronous refresh of the accelerometer data, and wait for latch 0x1611 to become 0x0.
+ */
+	
+ /*----------------------------------------------
+ * The next part is a little bit tricky because it can take a long time for the accelerometer to complete.
+ * I loop forever until latch 0x1611 becomes 0x02.
+ * 	Inside this loop, I check the timeout value against the "time waited so far" variable.
+ * 	If the function has taken too long,
+ * 		return failure.
+ * 	else, I call the function which reads the accelerometer data
+ * 	and I throw away the (probably garbage) data
+ * 		(this read somehow seems to kick the accelerometer into being initialized).
+ * 	I set_current_state to TASK_INTERRUPTIBLE, and schedule_timeout for HZ.
+ * 	I then increment our "seconds waited so far" variable and continue the loop.
+ * 	If the loop ever exits successfully, the function returns success.
+ * 	A good value to pass for the initialize timeout value is 10 seconds.
+ *
+ */
+        /* I loop forever until latch 0x1611 becomes 0x02. */ {
+	unsigned long msecs_to_sleep = 10000;
+	unsigned long msecs_per_sleep = 100;
+	unsigned long msecs_slept = 0;
+	while (msecs_slept <= msecs_to_sleep) {
+		if (latch_check(0x2, 0x1611)) {
+			printk("good latch check\n");
+			ret = 0;
+			break;
+		}
+		
+		read(0);
+		msleep_interruptible(msecs_per_sleep);
+		msecs_slept += msecs_per_sleep;
+	}}
 
-	return 0;
+	return ret;
 }
 
 static int __init accelerometer_init(void)
@@ -180,6 +254,17 @@
 	}
 
 	ret = initialize();
+	printk("initialize() ret: %d\n", ret);
+	if (ret)
+		return ret;
+	read(1);
+	{
+		int i;
+		for (i=0; i<10;i++) {
+			msleep_interruptible(1000);
+			read(1);
+		}
+	}
 
 	if (ret != 0) {
 		printk(KERN_ERR DRV_NAME ": initialization failed\n");

Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Alejandro Bonilla]

Dave Hansen wrote:

>On Sun, 2005-07-03 at 20:17 +0200, Jesper Juhl wrote:
>  
>
>>Ok, just to show you people what I've done so far.
>>This doesn't work yet, but it should be resonably close (at least it
>>builds ;)
>>    
>>
>
>On top of what you sent at first this morning (not the most recent one)
>I did some stuff (in the attached patch).  It implements the last bit of
>initialization that your earlier one didn't do, but I see you've done in
>the most recent one.
>
>Anyway, I get 10 reads out of it, 1 second apart, and it appears to be
>getting real data:
>
>10 seconds while tilting my thinkpad around:
>
>x_accel: 372
>y_accel: 339
>x_accel: 475
>  
>
Dave,

Simply awesome. Could you please send me the complete source that you 
have? Maybe also cc hdaps mailing list?

It's appreciated.

or, is this patch against Brix source?

.Alejandro

Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Dave Hansen]

On Sun, 2005-07-03 at 13:29 -0500, Alejandro Bonilla wrote:
> or, is this patch against Brix source?

It was against the files posted in this message:

>    From: Henrik Brix Andersen <brix@ge...>
>    Re: Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)
>    2005-07-03 09:01

Sorry, I wasn't on the m/l then, and I don't have a full msgid.  

I'll redo and retest against the files that were just posted under
msgid:
42C82BBB.9090008@gmail.com.

-- Dave

Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Jesper Juhl]

On 7/3/05, Dave Hansen <dave@sr71.net> wrote:
> On Sun, 2005-07-03 at 20:17 +0200, Jesper Juhl wrote:
> > Ok, just to show you people what I've done so far.
> > This doesn't work yet, but it should be resonably close (at least it
> > builds ;)
> 
> On top of what you sent at first this morning (not the most recent one)

I believe you are refering to the driver Henrik Brix Andersen wrote.
It seems we both started implementing the same thing at aproximately
the same time. I only saw Henriks version after I had send in my own.
His seems to work a bit better than mine :-)


Henrik: Are you planning on doing more work on this?   I ask since it
seems we are duplicating effort atm.  I think we should instead pool
our resources and work on just one implementation (don't know if
you've seen mine, but it's in the lkml archives earlier in this
thread).
What are your plans? Got any suggestions on how we should proceed? 
Personally I just want to end up with a working driver and I don't
care much if we use your work or mine as a starting point.

 
> I did some stuff (in the attached patch).  It implements the last bit of
> initialization that your earlier one didn't do, but I see you've done in
> the most recent one.
> 
Again, you did something on top of Henriks driver, but it is fairly
close to what I myself did.

> Anyway, I get 10 reads out of it, 1 second apart, and it appears to be
> getting real data:
> 

Great, nice to see that something seems to be working. :-)


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Alejandro Bonilla]

Jesper Juhl wrote:

>On 7/3/05, Dave Hansen <dave@sr71.net> wrote:
>  
>
>>On Sun, 2005-07-03 at 20:17 +0200, Jesper Juhl wrote:
>>    
>>
>>>Ok, just to show you people what I've done so far.
>>>This doesn't work yet, but it should be resonably close (at least it
>>>builds ;)
>>>      
>>>
>>On top of what you sent at first this morning (not the most recent one)
>>    
>>
>
>I believe you are refering to the driver Henrik Brix Andersen wrote.
>It seems we both started implementing the same thing at aproximately
>the same time. I only saw Henriks version after I had send in my own.
>His seems to work a bit better than mine :-)
>  
>
Guys,

    Great job, by looking at Dave's posts, he got data from the accel. 
Nice. I'm removing some people from the CC list as I'm getting flooded 
with admin messages from the ML settings and crap... Will leave LKML, 
HDAPS and dev.

    Thanks again. I hope we can make a tarball by the end of the day and 
see what we have.

.Alejandro

Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Henrik Brix Andersen]

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

On Sun, 2005-07-03 at 21:42 +0200, Jesper Juhl wrote:
> Henrik: Are you planning on doing more work on this?   I ask since it
> seems we are duplicating effort atm.  I think we should instead pool
> our resources and work on just one implementation (don't know if
> you've seen mine, but it's in the lkml archives earlier in this
> thread).

No need to duplicate effort.

> What are your plans? Got any suggestions on how we should proceed? 
> Personally I just want to end up with a working driver and I don't
> care much if we use your work or mine as a starting point.

I'd love to be able to work on this driver, but unfortunately it seem
IBM did not put any accelerometers in the X31, which is what I have
available for testing.

I keep getting 0x01 and 0x80 from the first latch check instead of 0x0.
So unless someone wants to sponsor me an X41... ;)

>  Great, nice to see that something seems to be working. :-)

Yes, good to hear.

Sincerely,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Jesper Juhl]

On 7/3/05, Henrik Brix Andersen <brix@gentoo.org> wrote:
> On Sun, 2005-07-03 at 21:42 +0200, Jesper Juhl wrote:
> > Henrik: Are you planning on doing more work on this?   I ask since it
> > seems we are duplicating effort atm.  I think we should instead pool
> > our resources and work on just one implementation (don't know if
> > you've seen mine, but it's in the lkml archives earlier in this
> > thread).
> 
> No need to duplicate effort.
> 
> > What are your plans? Got any suggestions on how we should proceed?
> > Personally I just want to end up with a working driver and I don't
> > care much if we use your work or mine as a starting point.
> 
> I'd love to be able to work on this driver, but unfortunately it seem
> IBM did not put any accelerometers in the X31, which is what I have
> available for testing.
> 
Ok, I'll carry this forward then. I see some good bits in your driver
and some good bits in mine. I'll merge the good bits from both and
carry on with that.

Thanks a lot for the work you did so far :-)

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Tomasz Torcz]

On Sun, Jul 03, 2005 at 12:21:54PM -0700, Dave Hansen wrote:
> On Sun, 2005-07-03 at 20:17 +0200, Jesper Juhl wrote:
> > Ok, just to show you people what I've done so far.
> > This doesn't work yet, but it should be resonably close (at least it
> > builds ;)
> 
> On top of what you sent at first this morning (not the most recent one)
> I did some stuff (in the attached patch).  It implements the last bit of
> initialization that your earlier one didn't do, but I see you've done in
> the most recent one.
> 
> Anyway, I get 10 reads out of it, 1 second apart, and it appears to be
> getting real data:

 Could this be done in userspace?


-- 
Tomasz Torcz                Only gods can safely risk perfection,
zdzichu@irc.-nie.spam-.pl     it's a dangerous thing for a man.  -- Alia

Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Dave Hansen]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

On Sun, 2005-07-03 at 20:17 +0200, Jesper Juhl wrote:
>         while (1) {
....
>                 } else if (time_before(jiffies, wait_until)) {
>                         set_current_state(TASK_INTERRUPTIBLE);
>                         schedule_timeout(HZ);
>                 } else {

Please don't do the manual task state setting.  It's preferable to just
use msleep_interruptable().  jiffies and HZ can change with each kernel
configuration, and are not dependable.  

I've attached an untested patch that cleans up the init function a bit
(I think).

-- Dave

[-- Attachment #2: init-function-cleanup.patch --]
[-- Type: text/x-patch, Size: 2042 bytes --]

--- accelerometer.c-0.1.orig	2005-07-03 12:28:28.000000000 -0700
+++ accelerometer.c	2005-07-03 12:33:39.000000000 -0700
@@ -158,45 +158,49 @@
 }
 
 /* initialize the accelerometer, wait up to `timeout' seconds for success */
-int accelerometer_init(unsigned int timeout)
+int accelerometer_init(unsigned int timeout_secs)
 {
-	unsigned long wait_until = jiffies + timeout * HZ;
+	unsigned long total_wait_msecs = timeout_secs * 1000;
+	unsinged msec_per_wait = 10;
+	unsigned long msecs_waited = 0;
+	int ret = -EIO;
 	
 	outb(0x13, 0x1610);
 	outb(0x01, 0x161f);
  	if (!wait_latch(0x00, 0x161f))
-		return -EIO;
+		return ret;
 	if (!wait_latch(0x03, 0x1611))
-		return -EIO;
+		return ret;
 	outb(0x17, 0x1610);
 	outb(0x81, 0x1611);
 	outb(0x01, 0x161f);
 	if (!wait_latch(0x00, 0x161f))
-		return -EIO;
+		return ret;
 	if (!wait_latch(0x00, 0x1611))
-		return -EIO;
+		return ret;
 	if (!wait_latch(0x60, 0x1612))
-		return -EIO;
+		return ret;
 	if (!wait_latch(0x00, 0x1613))
-		return -EIO;
+		return ret;
 	outb(0x14, 0x1610);
 	outb(0x01, 0x1611);
 	outb(0x01, 0x161f);
 	if (!wait_latch(0x00, 0x161f))
-		return -EIO;
+		return ret;
 	outb(0x10, 0x1610);
 	outb(0xc8, 0x1611);
 	outb(0x00, 0x1612);
 	outb(0x02, 0x1613);
 	outb(0x01, 0x161f);
 	if (!wait_latch(0x00, 0x161f))
-		return -EIO;
+		return ret;
 	if (!request_refresh(REFRESH_SYNC))
-		return -EIO;
+		return ret;
 	if (!wait_latch(0x00, 0x1611))
-		return -EIO;
+		return ret;
 
-	while (1) {
+	ret = -ENXIO;
+	while (msecs_waited <= total_wait_msecs) {
 		if (wait_latch(0x02, 0x1611)) {
 			struct hdaps_accel_data data;
 			/* 
@@ -204,15 +208,13 @@
 			 * return success.
 			 */
 			 accelerometer_read(&data);
-			return 0;
-		} else if (time_before(jiffies, wait_until)) {
-			set_current_state(TASK_INTERRUPTIBLE);
-			schedule_timeout(HZ);
-		} else {
-			/* we timed out, return failure */
-			return -ENXIO;
+			ret = 0;
+			break;
 		}
+		msleep(msecs_per_wait);
+		msecs_waited += msecs_per_wait;
 	}
+	return ret;
 }
 
 static int ibm_hdaps_init(void)

Re: [ltp] IBM HDAPS Someone interested? (Userspace accelerometer viewer)

[Paul Sladen]

On Sun, 3 Jul 2005, Alejandro Bonilla wrote:
> PLEASE read the following article, it has the data of a guy that made a 
> driver in IBM for Linux and he described the driver he made.
> http://www.almaden.ibm.com/cs/people/marksmith/tpaps.html

Yesterday evening, I used my time here at Debconf5 constructively!  ;-)

  http://www.paul.sladen.org/thinkpad-r31/aps/accelerometer-viewer.jpg    (43kB)
  http://www.paul.sladen.org/thinkpad-r31/aps/accelerometer-lid-shut.jpg  (27kB)

The sensor gives us two 10-bit AD values (corresponding to 0..1 volts on the
ADI chip), temperature (Celsius) and three status bits indicating:

  * lid open/closed
  * keyboard activity
  * nipple movement

On the X40 I borrowed (thanks Robert McQueen), at rest the outputs hover
around 512 (0x200).  Gravity is supposed to fall off in a sine-wave during
rotation, but I found that:

  theta = (N - 512) * 0.5

provides a surprisingly good approximation for pitch/roll values in degrees
in the range (-90..+90) so I think the sensor can do ~= +/-2.5G .

  http://www.paul.sladen.org/thinkpad-r31/aps/accelerometer-screenshot.png (9kB)

	-Paul

PS.  Coincidently, the name of the machine I borrowed is 'theta'...
-- 
Mostly it snows here.  Helsinki, FI

Re: [ltp] IBM HDAPS Someone interested? (Userspace accelerometer viewer)

[Alan Cox]

On Llu, 2005-07-11 at 10:42, Paul Sladen wrote:
>   theta = (N - 512) * 0.5
> 
> provides a surprisingly good approximation for pitch/roll values in degrees
> in the range (-90..+90) so I think the sensor can do ~= +/-2.5G .
> 
>   http://www.paul.sladen.org/thinkpad-r31/aps/accelerometer-screenshot.png (9kB)

Is the quality good enough to use it DEC itsy style as an input device
for games like Marble madness ?

Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Userspace accelerometer viewer)

[Dave Hansen]

On Mon, 2005-07-11 at 15:26 +0100, Alan Cox wrote:
> On Llu, 2005-07-11 at 10:42, Paul Sladen wrote:
> >   theta = (N - 512) * 0.5
> > 
> > provides a surprisingly good approximation for pitch/roll values in degrees
> > in the range (-90..+90) so I think the sensor can do ~= +/-2.5G .
> > 
> >   http://www.paul.sladen.org/thinkpad-r31/aps/accelerometer-screenshot.png (9kB)
> 
> Is the quality good enough to use it DEC itsy style as an input device
> for games like Marble madness ?

I was using it as a mouse as I tested interfacing it as an input device.
It could use some fine tuning, but it worked well enough for me to
navigate over to some icons.  Should be fine for games like that.

-- Dave

Re: [ltp] IBM HDAPS Someone interested? (Userspace accelerometer viewer)

[Paul RIVIER]

When I recieved my laptop last week, I had windows preinstalled on and 
before reinstalling a proper free system, I wanted to have a look to 
that feature, so I lauched the ibm HDAPS monitor. But to my mind 
precision is not really good, and when you roll your laptop twice or 
more the monitor forget its initial position and movements are only 
relative (may be a software issue, I don't know). But i love your idea ;)

Paul

Alan Cox wrote:

>On Llu, 2005-07-11 at 10:42, Paul Sladen wrote:
>  
>
>>  theta = (N - 512) * 0.5
>>
>>provides a surprisingly good approximation for pitch/roll values in degrees
>>in the range (-90..+90) so I think the sensor can do ~= +/-2.5G .
>>
>>  http://www.paul.sladen.org/thinkpad-r31/aps/accelerometer-screenshot.png (9kB)
>>    
>>
>
>Is the quality good enough to use it DEC itsy style as an input device
>for games like Marble madness ?
>
>  
>

Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Userspace accelerometer viewer)

[Daniel Willmann]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

Hello,

On Mon, 11 Jul 2005 15:26:57 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> Is the quality good enough to use it DEC itsy style as an input device
> for games like Marble madness ?

it sure is good enough to play neverball.

I have implemented an absolute input driver (aka joystick) on the
basis of Dave's 0.02 version of the driver. I attached the diff to this
mail or just get it from:
http://thebe.orbit.homelinux.net/~alphaone/ibm_hdaps_joystick.tar.gz

Before you can use your thinkpad as a joystick you have to set the
upper and lower bounds for both axis and if any of your axis are
reversed (like X40) through the files in 
/sys/devices/platform/ibm_hdaps/ I wrote a little python script to
calibrate and enable the joystick which is included in the tarball or
can be downloaded from 
http://thebe.orbit.homelinux.net/svn/ibm-hdaps/util/calibrate.py


Regards,
Daniel

[-- Attachment #2: ibm_hdaps_joystick.patch --]
[-- Type: text/x-patch, Size: 11667 bytes --]

Index: ibm_hdaps.c
===================================================================
--- ibm_hdaps.c	(revision 23)
+++ ibm_hdaps.c	(revision 27)
@@ -5,6 +5,7 @@
  * http://www.almaden.ibm.com/cs/people/marksmith/tpaps.html
  *
  * Copyright (c) 2005  Jesper Juhl <jesper.juhl@gmail.com>
+ * Copyright (c) 2005  Daniel Willmann <d.willmann@tu-bs.de>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -356,18 +357,7 @@
  **************************************************************************/
 
 static struct input_dev hdaps_idev;
-static u16 restx = 0;
-static u16 resty = 0;
 
-static void hdaps_calibrate(void)
-{
-	struct hdaps_accel_data accel_data;
-	accelerometer_read(&accel_data);
-	restx = accel_data.x_accel;
-	resty = accel_data.y_accel;
-	printk("restx: %d resty: %d\n", restx, resty);
-}
-
 static struct miscdevice ibm_hdaps_dev = {
 	.minor = MISC_DYNAMIC_MINOR,
 	.name = "ibm_hdaps",
@@ -376,41 +366,64 @@
 
 static struct timer_list ibm_hdaps_poll_timer;
 
-static unsigned long ibm_hdaps_mousedev_fuzz = 4;
 static unsigned long ibm_hdaps_poll_int_msecs = 25;
-static void ibm_hdaps_mousedev_poll(unsigned long unused)
+static unsigned int ibm_hdaps_joystick_reversex = 0;
+static unsigned int ibm_hdaps_joystick_reversey = 0;
+static u16 lastx = 0, lasty = 0;
+
+static void ibm_hdaps_joystick_poll(unsigned long unused)
 {
-	int movex, movey;
+	int posx, posy;
 	struct hdaps_accel_data accel_data;
 
 	accelerometer_read(&accel_data);
-	movex = restx - accel_data.x_accel;
-	movey = resty - accel_data.y_accel;
-	if (abs(movex) > ibm_hdaps_mousedev_fuzz)
-		input_report_rel(&hdaps_idev, REL_Y, movex);
-	if (abs(movey) > ibm_hdaps_mousedev_fuzz)
-		input_report_rel(&hdaps_idev, REL_X, movey);
+	posx = accel_data.x_accel;
+	posy = accel_data.y_accel;
+
+	if (ibm_hdaps_joystick_reversex)
+		posy = hdaps_idev.absmax[ABS_X] + (hdaps_idev.absmin[ABS_X] - posy);
+	if (ibm_hdaps_joystick_reversey)
+		posx = hdaps_idev.absmax[ABS_Y] + (hdaps_idev.absmin[ABS_Y] - posx);
+
+	if (abs(posx-lastx) > 0)
+		input_report_abs(&hdaps_idev, ABS_Y, posx);
+	if (abs(posy-lasty) > 0)
+		input_report_abs(&hdaps_idev, ABS_X, posy);
 	input_sync(&hdaps_idev);
+	lastx = posx;
+	lasty = posy;
 
 	mod_timer(&ibm_hdaps_poll_timer,
 		  jiffies + msecs_to_jiffies(ibm_hdaps_poll_int_msecs));
 }
 
-static int calibrated = 0;
-static int ibm_hdaps_mousedev_registered = 0;
-static int ibm_hdaps_mousedev_enable(void)
+static int ibm_hdaps_joystick_registered = 0;
+
+static void ibm_hdaps_joystick_disable(void)
 {
-	printk("ibm_hdaps_mousedev_enable()\n");
+	if (!ibm_hdaps_joystick_registered)
+		return;
+
+	del_timer_sync(&ibm_hdaps_poll_timer);
+	input_unregister_device(&hdaps_idev);
+	ibm_hdaps_joystick_registered = 0;
+
+	return;
+}
+
+static int ibm_hdaps_joystick_enable(void)
+{
+	printk(KERN_DEBUG "ibm_hdaps_joystick_enable()\n");
 	hdaps_idev.dev = &ibm_hdaps_plat_dev.dev;
 	init_input_dev(&hdaps_idev);
-	hdaps_idev.evbit[0] = BIT(EV_KEY) | BIT(EV_REL);
-	hdaps_idev.relbit[0] = BIT(REL_X) | BIT(REL_Y);
-	hdaps_idev.keybit[LONG(BTN_LEFT)] = BIT(BTN_LEFT);
+	hdaps_idev.name = "IBM Accelerometer";
+	hdaps_idev.evbit[0] = BIT(EV_ABS);
+	hdaps_idev.absbit[0] = BIT(ABS_X) | BIT(ABS_Y);
 	input_register_device(&hdaps_idev);
-	ibm_hdaps_mousedev_registered = 1;
+	ibm_hdaps_joystick_registered = 1;
 
 	init_timer(&ibm_hdaps_poll_timer);
-	ibm_hdaps_poll_timer.function = ibm_hdaps_mousedev_poll;
+	ibm_hdaps_poll_timer.function = ibm_hdaps_joystick_poll;
 	ibm_hdaps_poll_timer.expires =
 		jiffies + msecs_to_jiffies(ibm_hdaps_poll_int_msecs);
 	add_timer(&ibm_hdaps_poll_timer);
@@ -418,39 +431,199 @@
 	return 1;
 }
 
-static void ibm_hdaps_mousedev_disable(void)
+static ssize_t
+hdaps_joystick_enable_read(struct device *dev, char *buf)
 {
-	if (!ibm_hdaps_mousedev_registered)
-		return;
+	if (ibm_hdaps_joystick_registered)
+	{
+		snprintf(buf, 256, "enabled\n");
+	}
+	else
+		snprintf(buf, 256, "disabled\n");
+	return strlen(buf)+1;
+}
 
-	del_timer_sync(&ibm_hdaps_poll_timer);
-	input_unregister_device(&hdaps_idev);
+static ssize_t
+hdaps_joystick_enable_store(struct device *dev, const char * buf, size_t count)
+{
+	if ((strncmp(buf, "1", 1) == 0)&&(!ibm_hdaps_joystick_registered))
+	{
+		ibm_hdaps_joystick_enable();
+	}
+	else if ((strncmp(buf, "0", 1) == 0)&&(ibm_hdaps_joystick_registered))
+	{
+		ibm_hdaps_joystick_disable();
+	}
+	return count;
+}
+static DEVICE_ATTR(joystick_enable, S_IWUGO | S_IRUGO, hdaps_joystick_enable_read, hdaps_joystick_enable_store);
 
-	return;
+static ssize_t
+hdaps_joystick_fuzzx_read(struct device *dev, char *buf)
+{
+	snprintf(buf, 256, "%hu\n", hdaps_idev.absfuzz[ABS_X]);
+	return strlen(buf)+1;
 }
 
 static ssize_t
-hdaps_mousedev_enable_store(struct device *dev, struct device_attribute *attr,
-		const char * buf, size_t count)
+hdaps_joystick_fuzzx_store(struct device *dev, const char * buf, size_t count)
 {
-	if (!calibrated)
+	uint16_t temp;
+	if (ibm_hdaps_joystick_registered)
 		return -EINVAL;
+	if (sscanf(buf, "%hu", &temp) == 1)
+	{
+		hdaps_idev.absfuzz[ABS_X] = temp;
+	}
+	return count;
+}
+static DEVICE_ATTR(joystick_fuzzx, S_IWUGO | S_IRUGO, hdaps_joystick_fuzzx_read, hdaps_joystick_fuzzx_store);
 
-	ibm_hdaps_mousedev_enable();
+static ssize_t
+hdaps_joystick_fuzzy_read(struct device *dev, char *buf)
+{
+	snprintf(buf, 256, "%hu\n", hdaps_idev.absfuzz[ABS_Y]);
+	return strlen(buf)+1;
+}
+
+static ssize_t
+hdaps_joystick_fuzzy_store(struct device *dev, const char * buf, size_t count)
+{
+	uint16_t temp;
+	if (ibm_hdaps_joystick_registered)
+		return -EINVAL;
+	if (sscanf(buf, "%hu", &temp) == 1)
+	{
+		hdaps_idev.absfuzz[ABS_Y] = temp;
+	}
 	return count;
 }
-static DEVICE_ATTR(mousedev_enable,S_IWUGO, NULL, hdaps_mousedev_enable_store);
+static DEVICE_ATTR(joystick_fuzzy, S_IWUGO | S_IRUGO, hdaps_joystick_fuzzy_read, hdaps_joystick_fuzzy_store);
 
-ssize_t hdaps_calibrate_store(struct device *dev,
-		struct device_attribute *attr,
-		const char * buf, size_t count)
+static ssize_t
+hdaps_joystick_minx_read(struct device *dev, char *buf)
 {
-	hdaps_calibrate();
-	calibrated = 1;
+	snprintf(buf, 256, "%hu\n", hdaps_idev.absmin[ABS_X]);
+	return strlen(buf)+1;
+}
+
+static ssize_t
+hdaps_joystick_minx_store(struct device *dev, const char * buf, size_t count)
+{
+	uint16_t temp;
+	if (ibm_hdaps_joystick_registered)
+		return -EINVAL;
+	if (sscanf(buf, "%hu", &temp) == 1)
+	{
+		hdaps_idev.absmin[ABS_X] = temp;
+	}
 	return count;
 }
-static DEVICE_ATTR(calibrate,S_IWUGO, NULL, hdaps_calibrate_store);
+static DEVICE_ATTR(joystick_minx, S_IWUGO | S_IRUGO, hdaps_joystick_minx_read, hdaps_joystick_minx_store);
 
+static ssize_t
+hdaps_joystick_miny_read(struct device *dev, char *buf)
+{
+	snprintf(buf, 256, "%hu\n", hdaps_idev.absmin[ABS_Y]);
+	return strlen(buf)+1;
+}
+
+static ssize_t
+hdaps_joystick_miny_store(struct device *dev, const char * buf, size_t count)
+{
+	uint16_t temp;
+	if (ibm_hdaps_joystick_registered)
+		return -EINVAL;
+	if (sscanf(buf, "%hu", &temp) == 1)
+	{
+		hdaps_idev.absmin[ABS_Y] = temp;
+	}
+	return count;
+}
+static DEVICE_ATTR(joystick_miny, S_IWUGO | S_IRUGO, hdaps_joystick_miny_read, hdaps_joystick_miny_store);
+
+static ssize_t
+hdaps_joystick_maxx_read(struct device *dev, char *buf)
+{
+	snprintf(buf, 256, "%hu\n", hdaps_idev.absmax[ABS_X]);
+	return strlen(buf)+1;
+}
+
+static ssize_t
+hdaps_joystick_maxx_store(struct device *dev, const char * buf, size_t count)
+{
+	uint16_t temp;
+	if (ibm_hdaps_joystick_registered)
+		return -EINVAL;
+	if (sscanf(buf, "%hu", &temp) == 1)
+	{
+		hdaps_idev.absmax[ABS_X] = temp;
+	}
+	return count;
+}
+static DEVICE_ATTR(joystick_maxx, S_IWUGO | S_IRUGO, hdaps_joystick_maxx_read, hdaps_joystick_maxx_store);
+
+static ssize_t
+hdaps_joystick_maxy_read(struct device *dev, char *buf)
+{
+	snprintf(buf, 256, "%hu\n", hdaps_idev.absmax[ABS_Y]);
+	return strlen(buf)+1;
+}
+
+static ssize_t
+hdaps_joystick_maxy_store(struct device *dev, const char * buf, size_t count)
+{
+	uint16_t temp;
+	if (ibm_hdaps_joystick_registered)
+		return -EINVAL;
+	if (sscanf(buf, "%hu", &temp) == 1)
+	{
+		hdaps_idev.absmax[ABS_Y] = temp;
+	}
+	return count;
+}
+static DEVICE_ATTR(joystick_maxy, S_IWUGO | S_IRUGO, hdaps_joystick_maxy_read, hdaps_joystick_maxy_store);
+
+static ssize_t
+hdaps_joystick_reversex_read(struct device *dev, char *buf)
+{
+	snprintf(buf, 256, "%hu\n", ibm_hdaps_joystick_reversex);
+	return strlen(buf)+1;
+}
+
+static ssize_t
+hdaps_joystick_reversex_store(struct device *dev, const char * buf, size_t count)
+{
+	if (ibm_hdaps_joystick_registered)
+		return -EINVAL;
+	if (strncmp(buf, "1", 1) == 0)
+		ibm_hdaps_joystick_reversex = 1;
+	else if (strncmp(buf, "0", 1) == 0)
+		ibm_hdaps_joystick_reversex = 0;
+	return count;
+}
+static DEVICE_ATTR(joystick_reversex, S_IWUGO | S_IRUGO, hdaps_joystick_reversex_read, hdaps_joystick_reversex_store);
+
+static ssize_t
+hdaps_joystick_reversey_read(struct device *dev, char *buf)
+{
+	snprintf(buf, 256, "%hu\n", ibm_hdaps_joystick_reversey);
+	return strlen(buf)+1;
+}
+
+static ssize_t
+hdaps_joystick_reversey_store(struct device *dev, const char * buf, size_t count)
+{
+	if (ibm_hdaps_joystick_registered)
+		return -EINVAL;
+	if (strncmp(buf, "1", 1) == 0)
+		ibm_hdaps_joystick_reversey = 1;
+	else if (strncmp(buf, "0", 1) == 0)
+		ibm_hdaps_joystick_reversey = 0;
+	return count;
+}
+static DEVICE_ATTR(joystick_reversey, S_IWUGO | S_IRUGO, hdaps_joystick_reversey_read, hdaps_joystick_reversey_store);
+
 static int ibm_hdaps_init(void)
 {
 	int retval;
@@ -475,8 +648,15 @@
 	
 	printk(KERN_DEBUG "ibm_hdaps_init: platform_dev_register\n");
 	platform_device_register(&ibm_hdaps_plat_dev);
-	device_create_file(&ibm_hdaps_plat_dev.dev, &dev_attr_calibrate);
-	device_create_file(&ibm_hdaps_plat_dev.dev, &dev_attr_mousedev_enable);
+	device_create_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_enable);
+	device_create_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_fuzzx);
+	device_create_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_fuzzy);
+	device_create_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_minx);
+	device_create_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_miny);
+	device_create_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_maxx);
+	device_create_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_maxy);
+	device_create_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_reversex);
+	device_create_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_reversey);
 
 	printk(KERN_DEBUG "ibm_hdaps_init: done\n");
 	return 0;
@@ -484,10 +664,17 @@
 
 static void ibm_hdaps_exit(void)
 {
-	ibm_hdaps_mousedev_disable();
+	ibm_hdaps_joystick_disable();
 
-	device_remove_file(&ibm_hdaps_plat_dev.dev, &dev_attr_calibrate);
-	device_remove_file(&ibm_hdaps_plat_dev.dev, &dev_attr_mousedev_enable);
+	device_remove_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_enable);
+	device_remove_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_fuzzx);
+	device_remove_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_fuzzy);
+	device_remove_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_minx);
+	device_remove_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_miny);
+	device_remove_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_maxx);
+	device_remove_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_maxy);
+	device_remove_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_reversex);
+	device_remove_file(&ibm_hdaps_plat_dev.dev, &dev_attr_joystick_reversey);
 	platform_device_unregister(&ibm_hdaps_plat_dev);
 
 	misc_deregister(&ibm_hdaps_dev);

Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Userspace accelerometer viewer)

[Dave Hansen]

On Mon, 2005-07-11 at 22:09 +0200, Daniel Willmann wrote: 
> I have implemented an absolute input driver (aka joystick) on the
> basis of Dave's 0.02 version of the driver. I attached the diff to this
> mail or just get it from:
> http://thebe.orbit.homelinux.net/~alphaone/ibm_hdaps_joystick.tar.gz

Thanks for doing this.  A few comments below.

> +static u16 lastx = 0, lasty = 0;
> 
> 
> +static void ibm_hdaps_joystick_poll(unsigned long unused)
>  {
> -       int movex, movey;
> +       int posx, posy;
>         struct hdaps_accel_data accel_data;
>  
>         accelerometer_read(&accel_data);
> -       movex = restx - accel_data.x_accel;
> -       movey = resty - accel_data.y_accel;
> -       if (abs(movex) > ibm_hdaps_mousedev_fuzz)
> -               input_report_rel(&hdaps_idev, REL_Y, movex);
> -       if (abs(movey) > ibm_hdaps_mousedev_fuzz)
> -               input_report_rel(&hdaps_idev, REL_X, movey);
> +       posx = accel_data.x_accel;
> +       posy = accel_data.y_accel;
> +
> +       if (ibm_hdaps_joystick_reversex) 
> +               posy = hdaps_idev.absmax[ABS_X] + (hdaps_idev.absmin[ABS_X] - posy);
> +       if (ibm_hdaps_joystick_reversey)
> +               posx = hdaps_idev.absmax[ABS_Y] + (hdaps_idev.absmin[ABS_Y] - posx);

I'm not sure this is a good idea to do in the driver.  Reversing the
movement like this is something that surely should be going into the
input layer.  It might even be there already.

> +       if (abs(posx-lastx) > 0)
> +               input_report_abs(&hdaps_idev, ABS_Y, posx);
> +       if (abs(posy-lasty) > 0)
> +               input_report_abs(&hdaps_idev, ABS_X, posy);

Why do you suppress the events like this?  I think this is done inside
of the input layer already.  What happens if you don't do this?

> +       if (ibm_hdaps_joystick_registered)
> +       {
> +               snprintf(buf, 256, "enabled\n");
> +       }
> +       else
> +               snprintf(buf, 256, "disabled\n");

Please follow the coding style that Jesper and I have been working with:

        if () {
        	foo();
        } else {
        	bar();
        } 

> +static ssize_t
> +hdaps_joystick_enable_store(struct device *dev, const char * buf, size_t count)
> +{
> +       if ((strncmp(buf, "1", 1) == 0)&&(!ibm_hdaps_joystick_registered))
> +       {
> +               ibm_hdaps_joystick_enable();
> +       }
> +       else if ((strncmp(buf, "0", 1) == 0)&&(ibm_hdaps_joystick_registered))
> +       {
> +               ibm_hdaps_joystick_disable();
> +       }
> +       return count;
> +}

I think this makes the sysfs interface a bit counter-intuitive.  The
"cat joystick_enable" shows "enabled" or "disabled", but you have to
echo "0" and "1" into it to get it to do what you want.

> +hdaps_joystick_fuzzx_store(struct device *dev, const char * buf,
> size_t count)
>  {
> -       if (!calibrated)
> +       uint16_t temp;
> +       if (ibm_hdaps_joystick_registered)
>                 return -EINVAL;
> +       if (sscanf(buf, "%hu", &temp) == 1)
> +       {
> +               hdaps_idev.absfuzz[ABS_X] = temp;
> +       }
> +       return count;
> +}

Since that fuzz variable is actually part of the input layer, we should
probably have a conversation with the input people to see if they want a
generic, adjustable fuzz for all ABS input devices, instead of
duplicating it in a bunch of drivers.

BTW, I don't think there's a need for a different fuzzx and fuzzy.

-- Dave

Re: [ltp] IBM HDAPS Someone interested? (Userspace accelerometer viewer)

[Pavel Machek]

Hi!

> > PLEASE read the following article, it has the data of a guy that made a 
> > driver in IBM for Linux and he described the driver he made.
> > http://www.almaden.ibm.com/cs/people/marksmith/tpaps.html
> 
> Yesterday evening, I used my time here at Debconf5 constructively!  ;-)
> 
>   http://www.paul.sladen.org/thinkpad-r31/aps/accelerometer-viewer.jpg    (43kB)
>   http://www.paul.sladen.org/thinkpad-r31/aps/accelerometer-lid-shut.jpg  (27kB)
> 
> The sensor gives us two 10-bit AD values (corresponding to 0..1 volts on the
> ADI chip), temperature (Celsius) and three status bits indicating:
> 
>   * lid open/closed
>   * keyboard activity
>   * nipple movement

Oh, very nice pictures indeed...  What is the current interface
between userspace and kernel parts?
								Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.

Re: [ltp] IBM HDAPS Someone interested? (Userspace accelerometer viewer)

[Matthew Garrett]

Pavel Machek <pavel@suse.cz> wrote:

> Oh, very nice pictures indeed...  What is the current interface
> between userspace and kernel parts?

This one is implemented entirely in userspace, with stdio between the io
application and the 3D viewer.

-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

Re: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Userspace accelerometer viewer)

[Dave Hansen]

On Mon, 2005-07-11 at 10:42 +0100, Paul Sladen wrote:
> The sensor gives us two 10-bit AD values (corresponding to 0..1 volts on the
> ADI chip), temperature (Celsius) and three status bits indicating:
> 
>   * lid open/closed

Which bit did you find this in?  I haven't tried with the lid closed.

>   * keyboard activity
>   * nipple movement

Technically, it's mouse movement :)  I think it gets set on my T41p when
I'm using the touchpad.

> On the X40 I borrowed (thanks Robert McQueen), at rest the outputs hover
> around 512 (0x200).  Gravity is supposed to fall off in a sine-wave during
> rotation, but I found that:
> 
>   theta = (N - 512) * 0.5
> 
> provides a surprisingly good approximation for pitch/roll values in degrees
> in the range (-90..+90) so I think the sensor can do ~= +/-2.5G .

Interesting.  

-- Dave

RE: [Hdaps-devel] Re: [ltp] IBM HDAPS Someone interested? (Userspace accelerometer viewer)

[Alejandro Bonilla]

> On Sun, 3 Jul 2005, Alejandro Bonilla wrote:
> > PLEASE read the following article, it has the data of a guy 
> that made a 
> > driver in IBM for Linux and he described the driver he made.
> > http://www.almaden.ibm.com/cs/people/marksmith/tpaps.html
> 
> Yesterday evening, I used my time here at Debconf5 
> constructively!  ;-)
> 


Paul,

	Nice info. We need to look more deep into this.

Have you tried what we have so far?

.Alejandro

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[Alejandro Bonilla]

Paul Sladen wrote:

>On Thu, 23 Jun 2005, Lee Revell wrote:
>  
>
>>Yup, it's just doing port IO.  Get a kernel debugger for windows like
>>softice and this will be trivial to RE.
>>READ_PORT_USHORT / WRITE_PORT_UCHAR / READ_PORT_UCHAR
>>    
>>
>
>There are 3 ports involved.  The 0xed "non-existant delay port" and a pair
>of ports that are through the Super-I/O / IDE.  They are used in a
>index+value setup similar to reading/writing the AT keyboard controller.
>
>>From what I remember, my conclusion was that these instructions were the
>ones to park the heads and then lock the IDE bus.  It's a couple of months
>ago, but somewhere I have the simplified version of what it was doing...
>
>	-Paul
>  
>
Paul, if you can find that information and Join us into the Project, 
then we will be very happy about it. I hope you still have your 
ThinkPad. ;-)

So, let me get this correct. The Super-I/O only sends the information or 
should we be reading the information of what the accelerometer is 
outputting?

The way I was thinking about it, is that you would only read from the 
accelerometer, and within the value that is read, you will park or not 
the heads depending on how sensitive the user specified the option on 
the driver.

.Alejandro

Re: [ltp] IBM HDAPS Someone interested? (Accelerometer)

[P]

Alejandro Bonilla wrote:
> Paul Sladen wrote:
> 
>> On Thu, 23 Jun 2005, Lee Revell wrote:
>>  
>>
>>> Yup, it's just doing port IO.  Get a kernel debugger for windows like
>>> softice and this will be trivial to RE.
>>> READ_PORT_USHORT / WRITE_PORT_UCHAR / READ_PORT_UCHAR
>>>   
>>
>>
>> There are 3 ports involved.  The 0xed "non-existant delay port" and a 
>> pair
>> of ports that are through the Super-I/O / IDE.  They are used in a
>> index+value setup similar to reading/writing the AT keyboard controller.

Note the winbond docs are incomplete for the W83627HF at least.
I needed to download the reference for the W83697HF to complete
the picture for when I was writing:
http://lxr.linux.no/source/drivers/char/watchdog/w83627hf_wdt.c

Give us a shout if you need any docs/programming help.

-- 
Pádraig Brady - http://www.pixelbeat.org
--

Re: [ltp] Re: IBM HDAPS Someone interested?

[Jan Knutar]

On Tuesday 21 June 2005 02:35, Lee Revell wrote:

> I was thinking more along the lines of figure out the io port it's
> using, then boot windows, set an IO breakpoint in softice, then drop
> your laptop on the bed or something.

io ports 0x2E, 0x2F and 0xED aren't assigned to anything "known"
on other computers, are they? Someone with windows, softice and
tendency to reach deep insights into life, the universe and everything,
might find it fun to stare at.

Re: [ltp] Re: IBM HDAPS Someone interested?

[Lee Revell]

On Thu, 2005-06-23 at 18:33 +0300, Jan Knutar wrote:
> On Tuesday 21 June 2005 02:35, Lee Revell wrote:
> 
> > I was thinking more along the lines of figure out the io port it's
> > using, then boot windows, set an IO breakpoint in softice, then drop
> > your laptop on the bed or something.
> 
> io ports 0x2E, 0x2F and 0xED aren't assigned to anything "known"
> on other computers, are they? Someone with windows, softice and
> tendency to reach deep insights into life, the universe and everything,
> might find it fun to stare at.
> 

Now you're talking my language... nope, they aren't used on any of my
machines... hmm...  Anyone want to lend me their Thinkpad? ;-P

On a related note, I found it kind of depressing when I went to RE a
Windows driver, I got millions of hits on how to crack copy protection
on games, and only one guide to RE for Linux driver development:

http://dxr3.sourceforge.net/re.html

I'd really like to create a HOWTO, as there are some tricky aspects
(like getting your IDA Pro symbols loaded into SoftICE), and it's much
easier to find the register write routines than the document indicates.
Just grep for "inb", "outb" and friends, most likely they each appear
exactly once.

Of course, with IO breakpoints, you don't even have to do that, but the
register read/write routines are a good place to work backwards from...

Lee

Re: [ltp] Re: IBM HDAPS Someone interested?

[Andrew Haninger]

On 6/23/05, Lee Revell <rlrevell@joe-job.com> wrote:
> Anyone want to lend me their Thinkpad? ;-P
While I'd like APS support on my Thinkpad while running Linux as much
as the next guy/gal, I'm not sure that I'm ready to do this just yet
(unless someone on the Ohio State University campus thinks they can do
something, in which case, contact me off-list).

However, if the more knowledgeable hardware hackers amongst us could
put together some instructions for the daring but not-yet-initiated of
us that happen to have this hardware, I'd be happy to try to do what I
can.

Someone else mentioned SoftIce, which appears to cost more than 0USD,
so I'm not going to get and try that right away. Are there any other
low-cost methods of getting detailed information about the hardware as
it's initialized and used?

-Andy

Re: [ltp] Re: IBM HDAPS Someone interested?

[P]

Lee Revell wrote:
> On Thu, 2005-06-23 at 18:33 +0300, Jan Knutar wrote:
> 
>>On Tuesday 21 June 2005 02:35, Lee Revell wrote:
>>
>>
>>>I was thinking more along the lines of figure out the io port it's
>>>using, then boot windows, set an IO breakpoint in softice, then drop
>>>your laptop on the bed or something.
>>
>>io ports 0x2E, 0x2F and 0xED aren't assigned to anything "known"
>>on other computers, are they?

Generally watchdogs use 2[EF]

Pádraig.

RE: [ltp] Re: IBM HDAPS Someone interested?

[Alejandro Bonilla]

> >
> > io ports 0x2E, 0x2F and 0xED aren't assigned to anything "known"
> > on other computers, are they? Someone with windows, softice and
> > tendency to reach deep insights into life, the universe and
> everything,
> > might find it fun to stare at.
> >
>
> Now you're talking my language... nope, they aren't used on any of my
> machines... hmm...  Anyone want to lend me their Thinkpad? ;-P
>
>
> Of course, with IO breakpoints, you don't even have to do
> that, but the
> register read/write routines are a good place to work
> backwards from...
>
> Lee
>
>


Lee,

	I can lend you the laptop with SSH. :) I'll out the dammed thing with a
public IP and anyone can do whatever they want to with it. (Of course, that
won't kill the PC)  ;-|

	That is all I can do.

Also, if anyone wants to check this pdf, it talks about the protection
system and how well it worked...

http://www-605.ibm.com/misc_includes/en_IN/drop_test.pdf

.Alejandro

RE: [ltp] Re: IBM HDAPS Someone interested?

[Alejandro Bonilla]

Guys/Gals,

Let's please NOT drop this subject... But I think we can do it somewhere
else...

If you are some sort of engineer, but don't have an IBM laptop. Feel free to
help us.
If you own a IBM laptop and care about HD APS or will get a laptop in the
future with this, please continue with us.
If you want to follow the project anyway, please feel free to join us.
And of course. If you know about making drivers... :) don't hesitate to join
us either...

I created a mailing list. Let's see if we can continue with this and get HD
APS to work.

http://lists.sourceforge.net/lists/listinfo/hdaps-devel

Let's keep trying....

.Alejandro



>
> Now you're talking my language... nope, they aren't used on any of my
> machines... hmm...  Anyone want to lend me their Thinkpad? ;-P
>
> On a related note, I found it kind of depressing when I went to RE a
> Windows driver, I got millions of hits on how to crack copy protection
> on games, and only one guide to RE for Linux driver development:
>
> http://dxr3.sourceforge.net/re.html
>
> I'd really like to create a HOWTO, as there are some tricky aspects
> (like getting your IDA Pro symbols loaded into SoftICE), and it's much
> easier to find the register write routines than the document
> indicates.
> Just grep for "inb", "outb" and friends, most likely they each appear
> exactly once.
>
> Of course, with IO breakpoints, you don't even have to do
> that, but the
> register read/write routines are a good place to work
> backwards from...
>
> Lee

Re: [ltp] Re: IBM HDAPS Someone interested?

[Vojtech Pavlik]

On Mon, Jun 20, 2005 at 02:25:52PM -0600, Alejandro Bonilla wrote:

> Yani,
> 
> 	What company has ever released a Linux driver, just for the heck
> 	of it, or simply because they wanted it out? Hell no.
> 
> (maybe a couple odd ones)
> 
> We have to be persistent and ask them to release something, we paid a
> lot of money, and I have been missinformed to the fact that IBM loved
> Linux and wanted to "support it". Looks like a big lie to me. They
> don't even need to release a driver, just information. It is not even
> something that they only have. Now we all know that Analog Devices
> makes the hardware. Not them.

Motorola makes similar sensors (MMA1220D, etc). The fact that the sensor
is from AD doesn't mean anything, unfortunately, it's a generic sensor
used in videocameras (picture stabilization), digital cameras (picture
orientation detection), joysticks (logitech wingman gamepad), and many
other devices.

It's IBM (Lenovo) who interfaced it to some kind of a A/D and a
processor inside the machine that detects the free fall condition and
informs the BIOS/OS about it.

> So much for anything. I will keep asking for this information.
> 
> If people would send emails to IBM like I have, instead of complaining and
> doing pilitical arguments, we probably would have an answer already.

I believe at this moment the best approach is to track where the
connections on the mainboard go from the accelerometer. ;)

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: [ltp] Re: IBM HDAPS Someone interested?

[Pavel Machek]

Hi!

> > No, the software, under Windows, is an application; you can control
> > the behaviour of the disk based on the response of the chip.
> >
> > Anyway I don't think it's a simple task to create a driver for the
> > accelerometer; one thing is to read the data from the chip (I suppose
> > it's not too hard), but the most part of the job is to know what to do
> > with the data you read.
> >
> > IBM developed a mathematical model that describes the typical usage of
> > the ThinkPad, and they based the action on this math model. Developing
> > a free math model is quite hard and also we cannot destroy 5 or 6 TP
> > only to see how the signals are produced by the chip in all the
> > possible situations (IBM instead can destroy as much TP as
> > they want :(

You basically want to detect free fall. You don't need to make the machine
hit the concrete at the bottom; as long as it detects free fall, it is okay.
It does not seem *that* hard to me (but I do speech recognition at university :-).

Anyway, accelerometers are usefull for other stuff, too, like playing neverball.

Oh, and there should be reasonable way to develop this. First, detect
"machine sitting on unmoving table", and park heads if you detect anythink
else. Now, someone who really cares can develop model for "train", but most users are already quite well protected after you do "table" model.
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms