Intrepid: Missing hdaps_ec kernel module

[Matthäus Brandl]

Since the hdaps module doesn't support many newer Thinkpad models (mine included) and because the tp_smapi module is said to be better, I used the latter one in Hardy (named hdaps_ec) to support the integrated acceleration sensors.
But since I upgraded to Intrepid the hdaps_ec module is missing. (in both 2.6.27-6-generic and 2.6.27-7-generic)
A "locate hdaps_ec" only yields the module of the 2.6.24-21-generic kernel...

There are many people experiencing this problem, but the comment this in bug reports saying that hdaps doesn't support their model.
See e.g. #274512
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/274510/comments/5

[Dimitrios Symeonidis (azimout)]

related discussion in the ubuntu kernel-team mailing list:
http://www.nabble.com/tp_smapi-merge-isues-from-l-u-m-to-u-i,-with-possible-u-i-p-effects-td19655743.html

matthaeus, you're not supposed to confirm your own bug reports!

[Matthäus Brandl (matthaeus)]

That's why I didn't. It was Gert van Dijk on 2008-11-12

[Dimitrios Symeonidis (azimout)]

you're right, sorry, there's something wrong with my launchpad-gm-scripts...

[Matthäus Brandl (matthaeus)]

No problem.
btw, can you give me some links explaining these abbreviations? (l-u-m, u-i, u-i-p) I know that this is not the right place but google is of no help...

[Michael Meese (pelennor)]

Greetings!

I have the same problem. Anything changed yet?

Arnohr

[Dimitrios Symeonidis (azimout)]

(delayed) answer to matthaues:
l-u-m = linux ubuntu modules
u-i = ubuntu intrepid
u-i-p = ???

[Dimitrios Symeonidis (azimout)]

can you guys try loading the tp_smapi.ko module? it's available in the intrepid kernels...

[Dimitrios Symeonidis (azimout)]

oops, wrong click, i meant incomplete

[Philipp Dreimann (philipp-dreimann-deactivatedaccount)]

uhm I'm running jaunty kernels.. its not fixed there. (and should be fixed there as well)

[Matthäus Brandl (matthaeus)]

@Dimitrios:
I thought about that as well, but the result is as follows:
$ sudo modprobe tp_smapi
Runs with return 0
$ dmesg | tail shows:
[22475.378515] tp_smapi 0.37 loading...
[22475.381479] tp_smapi successfully loaded (smapi_port=0xb2).
$ lsmod | grep smapi shows:
tp_smapi 29712 0
thinkpad_ec 14736 1 tp_smapi

So it seems to be up and running nicely, but a test like
$ hdaps-gl yields
open: No such file or directory

I believe this is because tp_smapi for some reason doesn't publish the sensor data at all or not at the right spot. (I forgot where it should be, but I know that I looked for the information manually and didn't find it either)

[Matthäus Brandl (matthaeus)]

Btw, I'm now running on 2.6.27-9-generic, but no changes since I filed the bug

[Philipp Dreimann (philipp-dreimann-deactivatedaccount)]

you have to load the hdaps(_ec) module. the tp_smapi module itself does not fix the problem!

[Matthäus Brandl (matthaeus)]

Well thanks for your help, but actually the reason why I reported this bug is because most newer Thinkpad models are not supported by hdaps and the hdaps_ec module is not available...

% sudo modprobe hdaps
FATAL: Error inserting hdaps (/lib/modules/2.6.27-9-generic/kernel/drivers/hwmon/hdaps.ko): No such device
% dmesg | tail
[ 5029.144387] hdaps: supported laptop not found!
[ 5029.144400] hdaps: driver init failed (ret=-19)!
% sudo modprobe hdaps_ec
FATAL: Module hdaps_ec not found.

[Dimitrios Symeonidis (azimout)]

setting status back to new...

[Dominik Stadler (dominik-stadler)]

I think the module is also called only "hdaps" sometimes, at least for me.

FYI, I have a fairly new Thinkpad (T500) and I get this to work with the following steps, not sure which parts need to be put into which ubuntu package to make this available without manual re-compilation:

- compile my own kernel and patch it with one patch for hdaps from http://cache.gmane.org//gmane/linux/drivers/hdaps/devel/1393-001.bin

- compile latest tp-smapi (version 0.40) with adding HDAPS=1 on the make command to enable HDAPS correctly

- install the additional modules provided by this tp-smapi and ensure that any similar modules installed by the kernel itself are removed:

 rm /lib/modules/$KVER/kernel/ubuntu/misc/thinkpad_ec.ko
 rm /lib/modules/$KVER/kernel/ubuntu/misc/tp_smapi.ko
 rm /lib/modules/$KVER/kernel/drivers/hwmon/hdaps.ko

- add the following in a file "/etc/modprobe.d/local" to set the necessarz option
# enable thinkpad_ec
options thinkpad_ec force_io=1

# option to correctly set tilting through hdaps sensor
options hdaps invert=1

then tp-smapi and hdaps works fine for me after loading modules:
 modprobe tp_smapi
 modprobe hdaps

[Dominik Stadler (dominik-stadler)]

Forgot one thing, also hdapsd needs to be updated to a later version, Bug 303915 is related here, it requests an update from latest debian which should have the necessary changes.

[Tim Starling (tstarling)]

The problem is that hdaps_ec was in a directory all by itself in hardy lum:

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=tree;f=ubuntu/hwmon;h=e1a05f606eca36f24fa57367dabb0e801659ac9c;hb=master

Original commit:

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy-lum.git;a=commit;h=2e0a73b13cfe2c8c2d620b46a74013435e30c18b

It was accidentally omitted when the relevant modules were ported to intrepid:

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commitdiff;h=013522314b33a605577843f74cbc0b895b3f3d55

Obviously a very simple thing to fix. Bug 303915 is mostly unrelated.

[Thomas Hood (jdthood)]

> Obviously a very simple thing to fix.

Is anyone going to fix it?

[Tim Starling (tstarling)]

I guess not. I tried emailling Ben Collins, who did the commit, no response. And I tried raising the issue on #ubuntu-kernel on Freenode, but nobody was interested enough to fix it. I gave up at that point, a few weeks ago. I haven't tried the mailing lists.

[Thomas Hood (jdthood)]

I have written to Ben Collins again asking for comment.

[Rebecca Menessec (aloishammer-deactivatedaccount)]

It sure would be nice to have this fixed before Jaunty GA, esp. if it really is a trivial fix. There's kind of no point in having hdapsd and hdaps-utils in universe, else.

If it's not going to be maintained in main, it might as well be moved to its own package in universe so it can be frobbed without having to involve main kernel source.

[Brad Figg (brad-figg)]

Where does hdaps_ec come from? I've found the hdaps project on http://haps.sourceforge.net. If I'm going to try to get this into Jaunty I'd like to get the most recent, stable, version.

[Geir Ove Myhr (gomyhr)]

It should come from the tp_smapi module at http://tpctl.sourceforge.net/

There's some information at http://www.thinkwiki.org/wiki/HDAPS

[Brad Figg (brad-figg)]

Looking at both the latest release from http://tpctl.sourceforge.net/ and http://hdaps.sourceforge.net it looks like the driver hdaps_ec that is in hardy lum matches up with the hdaps driver from http://tpctl.sourceforge.net.

[Brad Figg (brad-figg)]

SRU Justification:

Impact: This seems to be a regression from Hardy that was not fixed for Intrepid. This should only affect ThinkPad users and provide additional functionality.

Fix: Add the hdaps_ec.ko module to the kernel. This is taken from the tp_smapi release found at http://tpctl.sourceforge.net.

Test: Run on a newer thinkpad, verify that hdaps_ec.ko is loaded.

[Geir Ove Myhr (gomyhr)]

Brad, thank you for taking responsibility for this. Do you have a
kernel already that we can test? (I see you don't have a PPA yet...)

[Brad Figg (brad-figg)]

I'm working on getting one put together now.

[Brad Figg (brad-figg)]

While I figure out how to put a proper PPA together you can get the kernel that I have build with the hdaps_ec driver. It is located at http://kernel.ubuntu.com/~bradf/.

[Lele83x (lele83x)]

Unbelievable ! The first Ubuntu release that uses a kernel with the proper hdaps patch doesn't have the hdaps_ec module !!!!!!!! What the f##k

[Stefan Hammer (j-4-deactivatedaccount)]

@ axx83: this is nothing!

hdapsd daemon, also needed to get APS working, is form year 2007 and doesn't work on newer thinkpads.
The youngest version is from April 2009, but nobody won't integrate it into the sources. There is an bug already existing: #300814

[Geir Ove Myhr (gomyhr)]

@Brad: I downloaded and installed the 2.6.28-11.43~lp297213bradf1 kernel packages. More specifically, I installed the packages
linux-headers-2.6.28-11_2.6.28-11.43~lp297213bradf1_all.deb
linux-headers-2.6.28-11-generic_2.6.28-11.43~lp297213bradf1_i386.deb
linux-image-2.6.28-11-generic_2.6.28-11.43~lp297213bradf1_i386.deb
linux-libc-dev_2.6.28-11.43~lp297213bradf1_i386.deb
with `dpkg -i linux-*.deb` and rebooted.

hdaps_ec did not show up at lsmod, and hdaps-pivot and hdaps-gl did not work right away. After `modprobe hdaps_ec` it worked well, cool!

@axx83 and jango: Complaining in a bug report does not help advance your case. It just makes everyone involved a little bit sad, unmotivated and less likely to follow up. Even though a working hdaps module is a really nice feature for us who have built-in accelerometers, it is not really of something most people have and the computer is totally usable without it, so I understand that it gets lower priority than bugs which causes crashes, hangs and loss of data.

[Tim Starling (tstarling)]

@Geir: it causes data loss if I drop my laptop enough.

[Igor (igor47)]

i got the hdaps working for now by downloading the smapi drivers from http://tpctl.sourceforge.net/

i then untarred, did 'make HDAPS=1', and then insmod hdaps.ko. this is on thinkpad x200s. i'd love to see the module incorporated into mainline ubuntu.

[Brad Figg (brad-figg)]

I posted the patch to the ubuntu kernel team mailing list for inclusion in Karmic. The request has been NAK'd
and the patch will not be accepted.

Please see: https://lists.ubuntu.com/archives/kernel-team/2009-April/date.html

When this was included in Hardy, the maintainers indicated that they would be attempting
to get the driver upstream. For whatever reason, this did not happen. It is quite a bit of work
for us to maintain drivers that are not upstream. It is felt that the maintainers of the two drivers
should work together to get a combined driver upstream.

[Tom Jaeger (thjaeger)]

Brad Figg wrote:
> I posted the patch to the ubuntu kernel team mailing list for inclusion in Karmic. The request has been NAK'd
> and the patch will not be accepted.
>
> Please see: https://lists.ubuntu.com/archives/kernel-
> team/2009-April/date.html
>
>
> When this was included in Hardy, the maintainers indicated that they would be attempting
> to get the driver upstream. For whatever reason, this did not happen.
IIRC, the reason is that the author of the drivers wants to remain
anonymous, and GregKH won't accept any code from anonymous authors for
fear they might have violated a NDA.

> It is quite a bit of work for us to maintain drivers that are not upstream.
This one I don't buy. How is it more work to rip the tp_smapi driver
out of the tpctl package than to include the whole thing?

> It is felt that the maintainers of the two drivers
> should work together to get a combined driver upstream.

I highly doubt that this is going to happen anytime soon.

[Brad Figg (brad-figg)]

>> It is quite a bit of work for us to maintain drivers that are not upstream.
>This one I don't buy. How is it more work to rip the tp_smapi driver
>out of the tpctl package than to include the whole thing?

For this example, there is already a hdaps driver upstream. I just doesn't have
the support that a part of the community desires. In order to put in a second
hdaps driver, I have to go into the package, pull out the desired bits, rename
where necessary and integrate them into our kernel tree.

Now, in this case that isn't a great deal of work. However, if you apply this to
all the requests that we get you can see how it can be quite a bit of work.

>> It is felt that the maintainers of the two drivers
>> should work together to get a combined driver upstream.

>I highly doubt that this is going to happen anytime soon.

That might be, however, that is what should have been happening all along. Even
when the driver was included into Hardy. And if you want it in Karmic that's what
it's going to take.

Also, if it goes upstream, all distros can take advantage of it and it benefits a larger
section of the community.

[Tom Jaeger (thjaeger)]

Brad Figg wrote:
>>> It is quite a bit of work for us to maintain drivers that are not upstream.
>> This one I don't buy. How is it more work to rip the tp_smapi driver
>> out of the tpctl package than to include the whole thing?
>
> For this example, there is already a hdaps driver upstream. I just doesn't have
> the support that a part of the community desires. In order to put in a second
> hdaps driver, I have to go into the package, pull out the desired bits, rename
> where necessary and integrate them into our kernel tree.
>
> Now, in this case that isn't a great deal of work. However, if you apply this to
> all the requests that we get you can see how it can be quite a bit of work.

For drivers that are not in mainline for one reason or another, there's
always a trade-off between the benefit to the community and the work
required to maintain the driver out-of tree, which has to be decided on
a case-by-case basis and not by some flawed slippery-slope argument.
Besides, all the work has been done in this case already.

>>> It is felt that the maintainers of the two drivers
>>> should work together to get a combined driver upstream.
>
>> I highly doubt that this is going to happen anytime soon.
>
> That might be, however, that is what should have been happening all along. Even
> when the driver was included into Hardy. And if you want it in Karmic that's what
> it's going to take.

It's not going to happen, though -- not until either Shem Multinymous
decides to come out of his anonymity or GregKH stops worrying about a
NDA that probably doesn't exist in the first place.

http://lkml.org/lkml/2008/9/15/126

> Also, if it goes upstream, all distros can take advantage of it and it benefits a larger
> section of the community.

If the kernel-team thinks that not including the driver in their kernel
will somehow help get this driver into mainline faster, I think they're
mistaken.

[Thomas Hood (jdthood)]

For users it's best if Ubuntu includes the patch until such time as it gets merged upstream.

Perhaps this represents an unreasonable amount of work. If so, then fair enough.

But I would hope that Ubuntu won't make users suffer merely because there's disagreement about who really ought to apply the patch.

[Lele83x (lele83x)]

what kind of non disclosure agreement could there be on an open source implementation of a probably patented technology ??? If it's open source and if the hardware is patented of course.

Really I don't understand the issue, if someone needs a legal analysis of this issue I could work on it with some help. But from a brief look it seems illogical.

[Tom Jaeger (thjaeger)]

On Mon, Apr 27, 2009 at 4:27 PM, Axx83 <email address hidden> wrote:
> what kind of non disclosure agreement could there be on an open source
> implementation of a probably patented technology ??? If it's open source
> and if the hardware is patented of course.
>
> Really I don't understand the issue, if someone needs a legal analysis
> of this issue I could work on it with some help. But from a brief look
> it seems illogical.

It doesn't seem like all the facts are out in the open. GregKH claims
he /knows/ the information was obtained illegally [1], which Shem
disputes [2].

[1] http://lkml.org/lkml/2008/10/7/403
[2] http://lkml.org/lkml/2008/10/7/428

[Lele83x (lele83x)]

That is completely ridiculous. Nda is a PERSONAL binding contract, If you are not under a nda yourself and you obtain infos that bind someone, no one can do anything to you, the infos are not protected by a patent, can't be anymore, no action can be taken against a third part using those info. NONE.

Now, the person who didn't respect the nda can be sued, but if no one knows who that was and the first party of the contract doesn't take action...WHAT IS THE PROBLEM ???

the only shadow on that is that the author of hdaps wants to remain anonymous...why would anyone do that if he has nothing to hide ? Probably not all is known

But my doubts stay.

[Rebecca Menessec (aloishammer-deactivatedaccount)]

Brad, I appreciate your efforts in trying to get this module into the default kernel. If there's anything I can do to get us closer to that goal (taking a cluestick to upstream, for instance), please let me know. Meantime, I'm unsubscribing to avoid the troll-spam flood. :(

[Christoph Pegel (rio-eta-ori)]

Why did you change the status to wontfix, Brad?
I tried your custom kernel, it works fine, so why not get it into upstream?

[Brad Figg (brad-figg)]

The status is changed to "Won't Fix" because of the issues covered earlier in this bug (see my previous comments).

[RichardNeill (ubuntu-richardneill)]

For anyone who wants an easy workaround, may I point this out:
http://meandmyubuntu.blogspot.com/2009/05/getting-hdasp-to-work-on-jaunty.html
It helped me a great deal - and took only 2 minutes.