How to make it work for Thinkpad Yoga?

[michamos]

Hi,

I have a Thinkpad Yoga laptop, and I am trying to make the sensors work, with no luck so far.
I am using Ubuntu 14.04 with kernel 3.13.0-18-generic on AMD64, and I managed to compile the drivers you provided (the Makefile needs to be adapted though as for the Fedora case).
I blacklisted the original modules and inserted yours instead as in the README, then ran setup (the first line has to be changed to #!/bin/bash, since you use bashisms and on Debian derivatives, sh != bash).

This is the output of orientation --debug 4

iio device number being used is 0
iio trigger number being used is 0
Finding orientation 0
Polling the data

and of sudo ls -R /sys/bus/iio/devices/iio:device0

/sys/bus/iio/devices/iio:device0:
buffer           in_accel_offset          name       subsystem
dev          in_accel_sampling_frequency  power      trigger
in_accel_hysteresis  in_accel_scale       scan_elements  uevent

/sys/bus/iio/devices/iio:device0/buffer:
enable  length

/sys/bus/iio/devices/iio:device0/power:
async             runtime_active_kids  runtime_status
autosuspend_delay_ms  runtime_active_time  runtime_suspended_time
control           runtime_enabled      runtime_usage

/sys/bus/iio/devices/iio:device0/scan_elements:
in_accel_x_en     in_accel_y_en     in_accel_z_en
in_accel_x_index  in_accel_y_index  in_accel_z_index
in_accel_x_type   in_accel_y_type   in_accel_z_type

/sys/bus/iio/devices/iio:device0/trigger:
current_trigger

Please tell me if you need more informaton.

[pfps]

I changed /bin/sh to /bin/bash in the scriptsand pushed this change.

What changes did you make to the drivers' Makefile? I recently made a change
to this Makefile to change KDIR and DDIR depending onthe distribution. (I'm
not sure that my check is ideal, though.)

orientation is waiting for data from the sensor. This indicates that you have
the right permissions for the sensor.

It is entirely possible that the Thinkpad Yoga hassomething
significantlydifferent from the Ideapad Yoga 2 Pro. To see which sensor hub
you have, do
lsusb
and look for a device like
Bus 00x Device 00y: ID 2047:0855 Texas Instruments
This is the sensor hub on the IdeaPad Yoga 2 Pro, anda special quirk had to be
added to its driver make it work correctly. If you don't have a device with
ID 2047:0855 then the quirk will not be active, and the sensors may not be
correctly set up. To patch this for you, you could try to change the above
numbers in hid-ids.h to the numbers you seefor your sensor hub. To check which
device is your sensor hub do a
sudo lsusb -v
and look for a device with iManufacturer Invensense or iInterface HID Sensor
Interface.

If you dohave this device then something else is going wrong. You will
probably have to poke around with generic-buffer. Try

sudo ./generic-buffer -n als -c 10
sudo ./generic-buffer -n accel_3d -c 10
sudo ./generic-buffer -n magn_3d -c 10

You should see something like the following. (For the light sensor you may
need to cover and uncover the sensor itself.)

sensors> sudo ./generic_buffer -n als -c 10
iio device number being used is 2
iio trigger number being used is 2
DEV_DIR_NAME /sys/bus/iio/devices/iio:device2 TRIGGER_NAME als-dev2
SCAN_SIZE 4
N000: in_intensity_both 625 625.0
N001: in_intensity_both 585 585.0
N002: in_intensity_both 507 507.0
N003: in_intensity_both 429 429.0
N004: in_intensity_both 351 351.0
N005: in_intensity_both 312 312.0
N006: in_intensity_both 351 351.0
N007: in_intensity_both 312 312.0
N008: in_intensity_both 273 273.0
N009: in_intensity_both 195 195.0

Let me know what you do see.

peter

On 03/24/2014 04:16 AM, Micha Moskovic wrote:

Hi,

I have a Thinkpad Yoga laptop, and I am trying to make the sensors work,
with no luck so far.
I am using Ubuntu 14.04 with kernel 3.13.0-18-generic on AMD64, and I
managed to compile the drivers you provided (the Makefile needs to be
adapted though as for the Fedora case).
I blacklisted the original modules and inserted yours instead as in the
README, then ran setup (the first line has to be changed to |#!/bin/bash|,
since you use bashisms and on Debian derivatives, |sh != bash|).

This is the output of |orientation --debug 4|

|iio device number being used is 0
iio trigger number being used is 0
Finding orientation 0
Polling the data
|

and of |sudo ls -R /sys/bus/iio/devices/iio:device0|

|buffer in_accel_offset name subsystem
dev in_accel_sampling_frequency power trigger
in_accel_hysteresis in_accel_scale scan_elements uevent

/sys/bus/iio/devices/iio:device0/buffer:
enable length

/sys/bus/iio/devices/iio:device0/power:
async runtime_active_kids runtime_status
autosuspend_delay_ms runtime_active_time runtime_suspended_time
control runtime_enabled runtime_usage

/sys/bus/iio/devices/iio:device0/scan_elements:
in_accel_x_en in_accel_y_en in_accel_z_en
in_accel_x_index in_accel_y_index in_accel_z_index
in_accel_x_type in_accel_y_type in_accel_z_type

/sys/bus/iio/devices/iio:device0/trigger:
current_trigger
|

Please tell me if you need more informaton.

—
Reply to this email directly or view it on GitHub
#4.

[michamos]

Thanks for trying to help me.
I have a different sensor hub, the relevant line of lsusb is

Bus 001 Device 003: ID 0483:91d1 STMicroelectronics

A quick googling shows that quirks are needed for this device too, see
http://www.spinics.net/lists/linux-input/msg29811.html

I applied the patch in that mail (by hand, automatic patching failed)
and recompiled the drivers (I will send you a Pull Request when the
sensors work correctly).
Now I get some output from the sensors, but the output seems incorrect:
./orientation --debug 4 yields

iio device number being used is 0
iio trigger number being used is 0
Finding orientation 0
Polling the data
Reading the data
Read the data
Orientation 1:   -35  -873  -545
Found orientation 1 -1 -1
Orientation at 0.0 is normal
Finding orientation 1
Polling the data
Reading the data
Read the data
Orientation 1:   -35  -873  -545
Found orientation 1 1 -1
Orientation at 1.0 is normal
ROTATE to normal
Finding orientation 1
Polling the data
Reading the data
Read the data
Orientation 1:   -35  -873  -545
Found orientation 1 1 1
Orientation at 2.0 is normal
Finding orientation 1
Polling the data
Reading the data
Read the data
Orientation 1:   -35  -873  -545
Found orientation 1 1 1
Orientation at 3.0 is normal
Finding orientation 1
Polling the data
Reading the data
Read the data
Orientation 1:   -35  -873  -545
Found orientation 1 1 1
Orientation at 4.0 is normal

and from there it just repeats the same thing every second, no matter
the orientation of the laptop.

[pfps]

Hmm.

It appears that the sensor is not updating. The Orientation lines are the
sensor output, the Found lines are the current and two previous orientations.

I would try generic-buffer and see whether you can get any of the four (or
five) sensors to change values. You could also try with the unpatched
hubdriver, if you don't see any changes.

If you can't get the sensors to change values, then the next step, I think is
to contact the person who submitted the patch for your sensor hub.

peter

On 03/24/2014 07:11 AM, Micha Moskovic wrote:

Thanks for trying to help me.
I have a different sensor hub, the relevant line of lsusb is

Bus 001 Device 003: ID 0483:91d1 STMicroelectronics

A quick googling shows that quirks are needed for this device too, see
http://www.spinics.net/lists/linux-input/msg29811.html

I applied the patch in that mail (by hand, automatic patching failed)
and recompiled the drivers (I will send you a Pull Request when the
sensors work correctly).
Now I get some output from the sensors, but the output seems incorrect:
./orientation --debug 4 yields

iio device number being used is 0
iio trigger number being used is 0
Finding orientation 0
Polling the data
Reading the data
Read the data
Orientation 1: -35 -873 -545
Found orientation 1 -1 -1
Orientation at 0.0 is normal
Finding orientation 1
Polling the data
Reading the data
Read the data
Orientation 1: -35 -873 -545
Found orientation 1 1 -1
Orientation at 1.0 is normal
ROTATE to normal
Finding orientation 1
Polling the data
Reading the data
Read the data
Orientation 1: -35 -873 -545
Found orientation 1 1 1
Orientation at 2.0 is normal
Finding orientation 1
Polling the data
Reading the data
Read the data
Orientation 1: -35 -873 -545
Found orientation 1 1 1
Orientation at 3.0 is normal
Finding orientation 1
Polling the data
Reading the data
Read the data
Orientation 1: -35 -873 -545
Found orientation 1 1 1
Orientation at 4.0 is normal

and from there it just repeats the same thing every second, no matter
the orientation of the laptop.

—
Reply to this email directly or view it on GitHub
#4 (comment).

[michamos]

I played a bit with generic_buffer, and it turns out that the sensors
are updated, but each value gets output 16 times
See https://gist.github.com/michamos/9746389 for the output of
generic_buffer -n accel_3d -c 1000.

[pfps]

Weird. Does this happen for the other sensors as well?

This really looks as if something extra should be done to set up thesensors.
I suggest trying to contact the person who put in the quirk for your sensor
hub to see if he is doing anything special. Please also cc me so that I can
keep up with what is happening.

peter

On 03/24/2014 11:42 AM, Micha Moskovic wrote:

I played a bit with generic_buffer, and it turns out that the sensors
are updated, but each value gets output 16 times
See https://gist.github.com/michamos/9746389 for the output of
generic_buffer -n accel_3d -c 1000.

—
Reply to this email directly or view it on GitHub
#4 (comment).

[michamos]

Yes, same thing happens with all other sensors.
The quirk is the same HID_SENSOR_HUB_ENUM_QUIRK that you also applied for your sensor, so nothing special is going on.
I will write to the person who sent the quirk for my sensor as you suggest and cc you.

On 24 Mar 2014, at 20:38, Peter F. Patel-Schneider [email protected] wrote:

Weird. Does this happen for the other sensors as well?

This really looks as if something extra should be done to set up thesensors.
I suggest trying to contact the person who put in the quirk for your sensor
hub to see if he is doing anything special. Please also cc me so that I can
keep up with what is happening.

peter

On 03/24/2014 11:42 AM, Micha Moskovic wrote:

I played a bit with generic_buffer, and it turns out that the sensors
are updated, but each value gets output 16 times
See https://gist.github.com/michamos/9746389 for the output of
generic_buffer -n accel_3d -c 1000.

—
Reply to this email directly or view it on GitHub
#4 (comment).

—
Reply to this email directly or view it on GitHub.

[pfps]

Yes, the quirk looks fine. However, the Linux setup for these sensors is
quite generic and the actual hardware may require some other kind of setup,
one that is not (yet) being applied. The Yoga 2 Pro sensors have other modes
of operation, which cannot (yet) be used, for example.

peter

On 03/25/2014 03:18 AM, Micha Moskovic wrote:

Yes, same thing happens with all other sensors.
The quirk is the same HID_SENSOR_HUB_ENUM_QUIRK that you also applied for
your sensor, so nothing special is going on.
I will write to the person who sent the quirk for my sensor as you suggest
and cc you.

On 24 Mar 2014, at 20:38, Peter F. Patel-Schneider
[email protected] wrote:

Weird. Does this happen for the other sensors as well?

This really looks as if something extra should be done to set up thesensors.
I suggest trying to contact the person who put in the quirk for your sensor
hub to see if he is doing anything special. Please also cc me so that I can
keep up with what is happening.

peter

On 03/24/2014 11:42 AM, Micha Moskovic wrote:

I played a bit with generic_buffer, and it turns out that the sensors
are updated, but each value gets output 16 times
See https://gist.github.com/michamos/9746389 for the output of
generic_buffer -n accel_3d -c 1000.

—
Reply to this email directly or view it on GitHub
#4 (comment).

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#4 (comment).

[TheTioz]

Hello,
I am also interested in making it works for the Thinkpad Yoga. Can you please post here the progress you made? I will try to patch the driver an reach the same level has you this weekend.

Thank you.

[michamos]

@TheTioz for the Thinkpad Yoga, the drivers included in Linux 3.14 work, in the sense that they produce an output.
The easiest way is to use a Linux 3.14 kernel, if your distribution provides it.
For exemple, if you use Ubuntu, you can download a pre-packaged vanilla 3.14 kernel (without the specific ubuntu patches) here: http://kernel.ubuntu.com/~kernel-ppa/mainline/
If you want to stay on an older kernel, you need to replace the files sensors/drivers/hid-ids.h and sensors/drivers/hid-sensor-hub.c with hid-ids.h and hid-sensor-hub.c from the 3.14 kernel.
You can then compile the drivers as explained in the README.
If you then try to run for example generic_buffer -n accel_3d -c 1000, you will notice that the sensors work, but that they are not updated in realtime, the same value gets output several times.
I sent an email two weeks ago to the person who sent the quirk for this sensor on the LKML, but got no answer.
The next step would probably to contact the linux-input kernel mailing list and report the problem.
I don't have much time right now, but I will try to do it this weekend.

[TheTioz]

Ok, thank you for the information.
Do you have any update regarding the delay?

[TheTioz]

Hi @michamos ,
Do you have more information? If you have no time to contact people, I can do it.
Cheers

[michamos]

Sorry, I forgot about this issue.
I did not contact anyone besides the person who sent the quirk and never answered.
A bug report should be sent to the linux-input mailing list. You are welcome to do so (please CC me), otherwise I will do it when I have some more time (probably not before June).

On 08 May 2014, at 21:46, TheTioz [email protected] wrote:

Hi @michamos ,
Do you have more information? If you have no time to contact people, I can do it.
Cheers

—
Reply to this email directly or view it on GitHub.

[TheTioz]

Ok thanks. I also do not have much time. I will try to find time to do some test and take a look at libiio. If I have enough time, I will also report the bug.

[TheTioz]

Hi @michamos,
I just compiled the kernel 3.15-rc5. I tried to run generic_buffer and add 2 kind of different behaviours. If you read the doc, from @pfps, it says:

"The sensors appear to be in one of several states:
1/ stuck - no data is produced and attempts to change the device status produce
Device or resource busy
2/ active with hysteresis - data is produced only after a significant change
3/ active with change - data is produced after any change
4/ free-running - data is produced very rapidly
I do not know how they get in these states, nor do I know how to change the state."

first time I ran the sensors, the data where produced following the mode 2(I think) or maybe 3. Then (I had to reboot because my keyboard was not working any-more), I had the sensors working following mainly 4 and sometime 2 or 3.

In mode 4, the sensors output value so fast that the value is repeated between 5 and 30 times. In the other mode however, the output are ways more slow. I do no think it is a bug, but just us failing to put the sensors in a good state.

I will investigate more before posting a bug report.

cheers

[catch22]

I would also be happy to do any testing required to get the Yoga sensors to work.

[TheTioz]

Hi @catch22
Great, have you already tried your captors? Do you need help setting up the kernel driver?

[pfps]

At this point it is probably better to use the 3.15 or 3.16 drivers, as there has been quite a bit of work done on them since the versions that I grabbed and patched. You will probably have to add the quirk for the Thinkpad Yoga if it isn't already in hid-sensor-hub.c. (If it is the STM hub then the quirk is already present.)

I'll grab the 3.15 drivers. If they work for me I'll do an update.

[pfps]

Hmm. It's not so simple. There are lots of changes in 3.15 so you either have to have quite a bit of the hid/iio subsystem or be running a 3.15 kernel. I'm on a cell-phone connection so I won't be able to upgrade to 3.15 for a while.

Anyway, if you want to test something out, get a 3.15 kernel. You may be able to use the standard drivers from there, with no modifications. (By the way, Fedora 20 just put out a 3.15 kernel so an up-to-date Fedora would be a good setup to test with.)

[TheTioz]

Ok, I currently run an archlinux, I will compile a custom kernel and see how is it working. Do you know if they are still changing the driver in 3.16 (I can try the release candidate).

[pfps]

There have been quite a few patches submitted in this area. I don't know whether they make anything better for Yogas, but if you can try 3.16 it might be a good idea to do so.

[TheTioz]

Hello,
I tried the generic-buffer for the accelerator with the kernel 3.15.3 and 3.16-rc3 and had different behaviours.

3.15.3
Out of the box the accelerators work outputting value really quickly (see @michamos and my above remark).
however this can be fixed changing the sampling and hysteresis values (maybe changing only the hysteresis is enough)
this can be achieved once is the device directory running the command:
echo 1 | sudo tee in_accel_sampling_frequency
echo 0.01 | sudo tee in_accel_hysteresis
where you can change the 1 and 0.01 to any desired values.

So it seems that pfps program should be working and maybe necessitate a little fine tuning in order not to use to much resources.

3.16-rc3
It seems they changed the drivers. Sometime generic-buffer output nothing, sometime 1 or 2 values but no more. However asking for the value using cat seems to work.

It also seems a new devices drivers has been added.

[pfps]

Right now orientation has a timed loop. It looks as if in 3.15 it can set up the sensor so that it can do a wait and get control after a significant change. I'll look into this when I get 3.15 installed.

Do you think that there is a regression in 3.16? Did you try to control the sensor as you did in 3.15? It may be that some random factor caused the sensor to be initialized in different states and that is what you are seeing in 3.16.

[TheTioz]

I made more tests.

the situation for 3.16 looks like a regression. generic-buffer stays stuck. Then if you do cat in_sensorsName_raw... , generic-buffer will output 1 or 2 line and get stuck again, then you can do cat again and again to output more values (the values are outputted both by cat and the generic-buffer).

In my laptop the situation for 3.15 is the following. After booting the sensor output the value really quickly. If you do cat in_sensorsName_sample_frequency, the sensors will put itself in the "normal" state.

Then for the accelerometer and the gyroscope, you can play around with the hysteresis.

I did not manage to change anything (hysteresis, sampling frequency) for the other captor.

I hope I am clear enough.

[catch22]

I have finally installed 3.16 (Linux yoga 3.16.0-031600-generic #201408031935 SMP Sun Aug 3 23:36:11 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux), cloned the repository and run make programs (w/o any additional driver installation). Unfortunately, orientation does not seem to do anything:

sudo ./orientation --debug 4
iio device number being used is 4
iio trigger number being used is 4
Finding orientation 0
Polling the data

However, I observed that screen rotation now generates the an ACPI event, namely the same one that previously only occurred when the tablet was "flipped around" (ibm/hotkey LEN0068:00 00000080 000060c0)!

Update: I can also read the _raw values of the magn_3d, accel_3d, incli_3d and gyro_3d sensors. Together with the ACPI event above, this should be good enough to get automatic screen rotation to work, I suppose...

Is there anything I can do to help?

[pfps]

Exactly when are the ACPI events generated? When the laptop is physically moved or when the display is rotated (so that the top of the display is the LHS of the screen, for example)? The flipped around event does not occur on the Yoga 2 Pro, I think. When do you see it?

The drivers changed quite a bit for 3.16, with new ways of setting them up. If you can figure out how the setup works in 3.16 and get that implemented, it would certainly help. I think that the drivers can be set up to report only significant changes, and the code can then just wait for it, instead of having a read-sleep loop. This would eliminate the 1/2s or so delay.

[catch22]

When the laptop is physically rotated in space (it only fires once I fully rotate the device, e.g., rotate the entire laptop by 90 degree to the left, but without moving the hinge). The ACPI event that is fired is the same one that is generated when the hinge is rotated all the way around (coincidentally, while in the latter state the ACPI events do not fire anymore for the rotations..).

Is there something specific I could try to get your code to run?

[pfps]

So it looks as if there is something on the Thinkpad Yogas looking at the sensors and reporting ACPI events. Hopefully that is not interfering with the way the orientation program works. (I expect not, as I expect that the ACPI events come from the embedded controller.)

As far as updating the code, you would have to find the updated documentation on how the IIO system works and figure out how to set up the sensor to report significant changes and then how to wait for sensor output. This is probably not going to be trivial.

I probably won't a chance to work on this for a while yet, but eventually I will be updating the code for 3.16.