Debugging 3D sensor on Lenovo YOGA 700-11ISK

Debugging 3D sensor on Lenovo YOGA 700-11ISK

[Alexey Kardashevskiy]

Hi!

I got a quite old Lenovo YOGA 700-11ISK with flip screen and run
fedora29 on it. I found that gnome3 cannot properly detect the screen
orientation and the screen keeps rotating non stop.

I opened an issue agains iio-sensor-proxy, not much luck there.
https://github.com/hadess/iio-sensor-proxy/issues/220

I resumed my debugging and the situation seems improving.

The yoga is running fedora29 v4.20.14. The fedora's iio-sensor-proxy
still has this problem and so does the iio-sensor-proxy upstream version.

Then I commented out &iio_buffer_accel to make &iio_poll_accel work -
and things worked nicely. I looked in sysfs and in_accel_?_raw seem to
have correct values (same as in the first log below, give or take), all
good. Recorded some debug from iio-sensor-proxy:

Accel read from IIO on 'accel_3d': -39, -937, -378 (scale 0.009807)
Accel sent by driver (quirk applied): -39, -937, -378 (scale: 0.009807)
Emitted orientation changed: from undefined to normal
No new data available on 'iio:device3'
Accel read from IIO on 'accel_3d': -39, -933, -371 (scale 0.009807)
Accel sent by driver (quirk applied): -39, -933, -371 (scale: 0.009807)
No new data available on 'iio:device3'
Accel read from IIO on 'accel_3d': -39, -933, -367 (scale 0.009807)
Accel sent by driver (quirk applied): -39, -933, -367 (scale: 0.009807)

This is the good log, gnome works fine.


Then I recorded debug with the buffer driver enabled:

rocess_scan_1: channel_index: 0, chan_name: in_accel_x,
channel_data_index: 0 location: 0
process_scan_1: channel_index: 1, chan_name: in_accel_y,
channel_data_index: 1 location: 4
process_scan_1: channel_index: 2, chan_name: in_accel_z,
channel_data_index: 2 location: 8
Accel read from IIO on 'iio:device4': -15, -898, -375 (scale 0.009807)
Accel sent by driver (quirk applied): -15, -898, -375 (scale: 0.009807)
Emitted orientation changed: from undefined to normal
No new data available on 'iio:device3'
process_scan_1: channel_index: 0, chan_name: in_accel_x,
channel_data_index: 0 location: 0
process_scan_1: channel_index: 1, chan_name: in_accel_y,
channel_data_index: 1 location: 4
process_scan_1: channel_index: 2, chan_name: in_accel_z,
channel_data_index: 2 location: 8
Accel read from IIO on 'iio:device4': 20774, 27203, 0 (scale 0.009807)
Accel sent by driver (quirk applied): 20774, 27203, 0 (scale: 0.009807)
Emitted orientation changed: from normal to left-up
No new data available on 'iio:device3'
process_scan_1: channel_index: 0, chan_name: in_accel_x,
channel_data_index: 0 location: 0
process_scan_1: channel_index: 1, chan_name: in_accel_y,
channel_data_index: 1 location: 4
process_scan_1: channel_index: 2, chan_name: in_accel_z,
channel_data_index: 2 location: 8
Accel read from IIO on 'iio:device4': -31, -929, -398 (scale 0.009807)
Accel sent by driver (quirk applied): -31, -929, -398 (scale: 0.009807)
Emitted orientation changed: from left-up to normal
No new data available on 'iio:device3'
process_scan_1: channel_index: 0, chan_name: in_accel_x,
channel_data_index: 0 location: 0
process_scan_1: channel_index: 1, chan_name: in_accel_y,
channel_data_index: 1 location: 4
process_scan_1: channel_index: 2, chan_name: in_accel_z,
channel_data_index: 2 location: 8
Accel read from IIO on 'iio:device4': -14345, -32024, 12738 (scale 0.009807)
Accel sent by driver (quirk applied): -14345, -32024, 12738 (scale:
0.009807)

So it is good reading, bad reading, good reading, bad reading, and gnome
rotates the screen non stop. No wonder gnome3 goes crazy.

I would debug further and even come up with a fix but I failed to find
quickly where there reads are handled in the kernel, and what defines
these in_accel_?_raw files in sysfs, tried grepping - nothing. Any pointers?


Also, how do I identify my particular 3d sensor? Or it is the same model
everywhere? Or it is the driver for all of them?

Here is dmesg | grep i2c:

[root@aikyoga iio:device4]# dmesg | egrep '(i2c|iio)'
[    5.389867] i2c_hid i2c-ITE8350:00: i2c-ITE8350:00 supply vdd not
found, using dummy regulator
[    5.389893] i2c_hid i2c-ITE8350:00: Linked as a consumer to regulator.0
[    5.389896] i2c_hid i2c-ITE8350:00: i2c-ITE8350:00 supply vddl not
found, using dummy regulator
[    5.502896] hid-generic 0018:048D:8350.0002: hidraw1: I2C HID v1.00
Device [ITE8350:00 048D:8350] on i2c-ITE8350:00
[    5.528455] i2c_hid i2c-SYNA2B23:00: i2c-SYNA2B23:00 supply vdd not
found, using dummy regulator
[    5.528485] i2c_hid i2c-SYNA2B23:00: Linked as a consumer to regulator.0
[    5.528489] i2c_hid i2c-SYNA2B23:00: i2c-SYNA2B23:00 supply vddl not
found, using dummy regulator
[    5.543440] input: SYNA2B23:00 06CB:2714 Mouse as
/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-SYNA2B23:00/0018:06CB:2714.0003/input/input13
[    5.543690] hid-generic 0018:06CB:2714.0003: input,hidraw2: I2C HID
v1.00 Mouse [SYNA2B23:00 06CB:2714] on i2c-SYNA2B23:00
[    6.053237] input: Synaptics TM2714-002 as
/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-SYNA2B23:00/0018:06CB:2714.0003/input/input16
[    6.053444] hid-rmi 0018:06CB:2714.0003: input,hidraw1: I2C HID v1.00
Mouse [SYNA2B23:00 06CB:2714] on i2c-SYNA2B23:00

Thanks!


-- 
Alexey

Re: Debugging 3D sensor on Lenovo YOGA 700-11ISK

[Jonathan Cameron]

+CC bastien and (guessing it is a HID sensor) Srinivas.
On Sat, 16 Mar 2019 20:16:39 +1100
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:

> Hi!
> 
> I got a quite old Lenovo YOGA 700-11ISK with flip screen and run
> fedora29 on it. I found that gnome3 cannot properly detect the screen
> orientation and the screen keeps rotating non stop.
> 
> I opened an issue agains iio-sensor-proxy, not much luck there.
> https://github.com/hadess/iio-sensor-proxy/issues/220
> 
> I resumed my debugging and the situation seems improving.
> 
> The yoga is running fedora29 v4.20.14. The fedora's iio-sensor-proxy
> still has this problem and so does the iio-sensor-proxy upstream version.
> 
> Then I commented out &iio_buffer_accel to make &iio_poll_accel work -
> and things worked nicely. I looked in sysfs and in_accel_?_raw seem to
> have correct values (same as in the first log below, give or take), all
> good. Recorded some debug from iio-sensor-proxy:
> 
> Accel read from IIO on 'accel_3d': -39, -937, -378 (scale 0.009807)
> Accel sent by driver (quirk applied): -39, -937, -378 (scale: 0.009807)
> Emitted orientation changed: from undefined to normal
> No new data available on 'iio:device3'
> Accel read from IIO on 'accel_3d': -39, -933, -371 (scale 0.009807)
> Accel sent by driver (quirk applied): -39, -933, -371 (scale: 0.009807)
> No new data available on 'iio:device3'
> Accel read from IIO on 'accel_3d': -39, -933, -367 (scale 0.009807)
> Accel sent by driver (quirk applied): -39, -933, -367 (scale: 0.009807)
> 
> This is the good log, gnome works fine.
> 
> 
> Then I recorded debug with the buffer driver enabled:
> 
> rocess_scan_1: channel_index: 0, chan_name: in_accel_x,
> channel_data_index: 0 location: 0
> process_scan_1: channel_index: 1, chan_name: in_accel_y,
> channel_data_index: 1 location: 4
> process_scan_1: channel_index: 2, chan_name: in_accel_z,
> channel_data_index: 2 location: 8
> Accel read from IIO on 'iio:device4': -15, -898, -375 (scale 0.009807)
> Accel sent by driver (quirk applied): -15, -898, -375 (scale: 0.009807)
> Emitted orientation changed: from undefined to normal
> No new data available on 'iio:device3'
> process_scan_1: channel_index: 0, chan_name: in_accel_x,
> channel_data_index: 0 location: 0
> process_scan_1: channel_index: 1, chan_name: in_accel_y,
> channel_data_index: 1 location: 4
> process_scan_1: channel_index: 2, chan_name: in_accel_z,
> channel_data_index: 2 location: 8
> Accel read from IIO on 'iio:device4': 20774, 27203, 0 (scale 0.009807)
> Accel sent by driver (quirk applied): 20774, 27203, 0 (scale: 0.009807)
> Emitted orientation changed: from normal to left-up
> No new data available on 'iio:device3'
> process_scan_1: channel_index: 0, chan_name: in_accel_x,
> channel_data_index: 0 location: 0
> process_scan_1: channel_index: 1, chan_name: in_accel_y,
> channel_data_index: 1 location: 4
> process_scan_1: channel_index: 2, chan_name: in_accel_z,
> channel_data_index: 2 location: 8
> Accel read from IIO on 'iio:device4': -31, -929, -398 (scale 0.009807)
> Accel sent by driver (quirk applied): -31, -929, -398 (scale: 0.009807)
> Emitted orientation changed: from left-up to normal
> No new data available on 'iio:device3'
> process_scan_1: channel_index: 0, chan_name: in_accel_x,
> channel_data_index: 0 location: 0
> process_scan_1: channel_index: 1, chan_name: in_accel_y,
> channel_data_index: 1 location: 4
> process_scan_1: channel_index: 2, chan_name: in_accel_z,
> channel_data_index: 2 location: 8
> Accel read from IIO on 'iio:device4': -14345, -32024, 12738 (scale 0.009807)
> Accel sent by driver (quirk applied): -14345, -32024, 12738 (scale:
> 0.009807)
> 
> So it is good reading, bad reading, good reading, bad reading, and gnome
> rotates the screen non stop. No wonder gnome3 goes crazy.
> 
> I would debug further and even come up with a fix but I failed to find
> quickly where there reads are handled in the kernel, and what defines
> these in_accel_?_raw files in sysfs, tried grepping - nothing. Any pointers?

The raw files are built by the IIO core to call the read_raw callback in the
each driver.  The path for buffered data is very different. Ultimately
it goes through a call to iio_push_to_buffers.

> 
> 
> Also, how do I identify my particular 3d sensor? Or it is the same model
> everywhere? Or it is the driver for all of them?
Lots an lots and lots of drivers ;)   But in laptops they are often
hid-sensors, or at least there is a little microcontroller that handles
the different streams and reformats them as hid sensor records.

> 
> Here is dmesg | grep i2c:

First of all, let us check the device. I'm going to guess it's a hid
sensor of some type.
Could you cat
/sys/bus/iio/devices/iio\:device0/name

When iio-sensor-proxy is running (or after you've killed it) check
what the values in the various files in
/sys/bus/iio/devices/iio\:device0/scan_elements/* 
are.  One thought is we have some unexpected channels enabled and
the code is thinking they are acceleration when they aren't.

> 
> [root@aikyoga iio:device4]# dmesg | egrep '(i2c|iio)'
> [    5.389867] i2c_hid i2c-ITE8350:00: i2c-ITE8350:00 supply vdd not
> found, using dummy regulator
> [    5.389893] i2c_hid i2c-ITE8350:00: Linked as a consumer to regulator.0
> [    5.389896] i2c_hid i2c-ITE8350:00: i2c-ITE8350:00 supply vddl not
> found, using dummy regulator
> [    5.502896] hid-generic 0018:048D:8350.0002: hidraw1: I2C HID v1.00
> Device [ITE8350:00 048D:8350] on i2c-ITE8350:00
> [    5.528455] i2c_hid i2c-SYNA2B23:00: i2c-SYNA2B23:00 supply vdd not
> found, using dummy regulator
> [    5.528485] i2c_hid i2c-SYNA2B23:00: Linked as a consumer to regulator.0
> [    5.528489] i2c_hid i2c-SYNA2B23:00: i2c-SYNA2B23:00 supply vddl not
> found, using dummy regulator
> [    5.543440] input: SYNA2B23:00 06CB:2714 Mouse as
> /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-SYNA2B23:00/0018:06CB:2714.0003/input/input13
> [    5.543690] hid-generic 0018:06CB:2714.0003: input,hidraw2: I2C HID
> v1.00 Mouse [SYNA2B23:00 06CB:2714] on i2c-SYNA2B23:00
> [    6.053237] input: Synaptics TM2714-002 as
> /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-SYNA2B23:00/0018:06CB:2714.0003/input/input16
> [    6.053444] hid-rmi 0018:06CB:2714.0003: input,hidraw1: I2C HID v1.00
> Mouse [SYNA2B23:00 06CB:2714] on i2c-SYNA2B23:00
> 
> Thanks!
> 
> 

Re: Debugging 3D sensor on Lenovo YOGA 700-11ISK

[Alexey Kardashevskiy]

On 17/03/2019 05:33, Jonathan Cameron wrote:
> 
> +CC bastien and (guessing it is a HID sensor) Srinivas.
> On Sat, 16 Mar 2019 20:16:39 +1100
> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> 
>> Hi!
>>
>> I got a quite old Lenovo YOGA 700-11ISK with flip screen and run
>> fedora29 on it. I found that gnome3 cannot properly detect the screen
>> orientation and the screen keeps rotating non stop.
>>
>> I opened an issue agains iio-sensor-proxy, not much luck there.
>> https://github.com/hadess/iio-sensor-proxy/issues/220
>>
>> I resumed my debugging and the situation seems improving.
>>
>> The yoga is running fedora29 v4.20.14. The fedora's iio-sensor-proxy
>> still has this problem and so does the iio-sensor-proxy upstream version.
>>
>> Then I commented out &iio_buffer_accel to make &iio_poll_accel work -
>> and things worked nicely. I looked in sysfs and in_accel_?_raw seem to
>> have correct values (same as in the first log below, give or take), all
>> good. Recorded some debug from iio-sensor-proxy:
>>
>> Accel read from IIO on 'accel_3d': -39, -937, -378 (scale 0.009807)
>> Accel sent by driver (quirk applied): -39, -937, -378 (scale: 0.009807)
>> Emitted orientation changed: from undefined to normal
>> No new data available on 'iio:device3'
>> Accel read from IIO on 'accel_3d': -39, -933, -371 (scale 0.009807)
>> Accel sent by driver (quirk applied): -39, -933, -371 (scale: 0.009807)
>> No new data available on 'iio:device3'
>> Accel read from IIO on 'accel_3d': -39, -933, -367 (scale 0.009807)
>> Accel sent by driver (quirk applied): -39, -933, -367 (scale: 0.009807)
>>
>> This is the good log, gnome works fine.
>>
>>
>> Then I recorded debug with the buffer driver enabled:
>>
>> rocess_scan_1: channel_index: 0, chan_name: in_accel_x,
>> channel_data_index: 0 location: 0
>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>> channel_data_index: 1 location: 4
>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>> channel_data_index: 2 location: 8
>> Accel read from IIO on 'iio:device4': -15, -898, -375 (scale 0.009807)
>> Accel sent by driver (quirk applied): -15, -898, -375 (scale: 0.009807)
>> Emitted orientation changed: from undefined to normal
>> No new data available on 'iio:device3'
>> process_scan_1: channel_index: 0, chan_name: in_accel_x,
>> channel_data_index: 0 location: 0
>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>> channel_data_index: 1 location: 4
>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>> channel_data_index: 2 location: 8
>> Accel read from IIO on 'iio:device4': 20774, 27203, 0 (scale 0.009807)
>> Accel sent by driver (quirk applied): 20774, 27203, 0 (scale: 0.009807)
>> Emitted orientation changed: from normal to left-up
>> No new data available on 'iio:device3'
>> process_scan_1: channel_index: 0, chan_name: in_accel_x,
>> channel_data_index: 0 location: 0
>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>> channel_data_index: 1 location: 4
>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>> channel_data_index: 2 location: 8
>> Accel read from IIO on 'iio:device4': -31, -929, -398 (scale 0.009807)
>> Accel sent by driver (quirk applied): -31, -929, -398 (scale: 0.009807)
>> Emitted orientation changed: from left-up to normal
>> No new data available on 'iio:device3'
>> process_scan_1: channel_index: 0, chan_name: in_accel_x,
>> channel_data_index: 0 location: 0
>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>> channel_data_index: 1 location: 4
>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>> channel_data_index: 2 location: 8
>> Accel read from IIO on 'iio:device4': -14345, -32024, 12738 (scale 0.009807)
>> Accel sent by driver (quirk applied): -14345, -32024, 12738 (scale:
>> 0.009807)
>>
>> So it is good reading, bad reading, good reading, bad reading, and gnome
>> rotates the screen non stop. No wonder gnome3 goes crazy.
>>
>> I would debug further and even come up with a fix but I failed to find
>> quickly where there reads are handled in the kernel, and what defines
>> these in_accel_?_raw files in sysfs, tried grepping - nothing. Any pointers?
> 
> The raw files are built by the IIO core to call the read_raw callback in the
> each driver.  The path for buffered data is very different. Ultimately
> it goes through a call to iio_push_to_buffers.
> 
>>
>>
>> Also, how do I identify my particular 3d sensor? Or it is the same model
>> everywhere? Or it is the driver for all of them?
> Lots an lots and lots of drivers ;)   But in laptops they are often
> hid-sensors, or at least there is a little microcontroller that handles
> the different streams and reformats them as hid sensor records.

And lots and lots of such microcontrollers as well? :)


>>
>> Here is dmesg | grep i2c:
> 
> First of all, let us check the device. I'm going to guess it's a hid
> sensor of some type.
> Could you cat
> /sys/bus/iio/devices/iio\:device0/name


[root@aikyoga iio:device4]# cat /sys/bus/iio/devices/iio\:device0/name
dev_rotation


> When iio-sensor-proxy is running (or after you've killed it) check
> what the values in the various files in
> /sys/bus/iio/devices/iio\:device0/scan_elements/*

> are.  One thought is we have some unexpected channels enabled and
> the code is thinking they are acceleration when they aren't.


[root@aikyoga iio:device4]# for i in
/sys/bus/iio/devices/iio\:device0/scan_elements/* ; do echo $i ; cat $i
; done
/sys/bus/iio/devices/iio:device0/scan_elements/in_rot_quaternion_en
0
/sys/bus/iio/devices/iio:device0/scan_elements/in_rot_quaternion_index
0
/sys/bus/iio/devices/iio:device0/scan_elements/in_rot_quaternion_type
le:s32/32X4>>0


The values do not change whether iio-sensor-proxy is running or not.

> 
>>
>> [root@aikyoga iio:device4]# dmesg | egrep '(i2c|iio)'
>> [    5.389867] i2c_hid i2c-ITE8350:00: i2c-ITE8350:00 supply vdd not
>> found, using dummy regulator
>> [    5.389893] i2c_hid i2c-ITE8350:00: Linked as a consumer to regulator.0
>> [    5.389896] i2c_hid i2c-ITE8350:00: i2c-ITE8350:00 supply vddl not
>> found, using dummy regulator
>> [    5.502896] hid-generic 0018:048D:8350.0002: hidraw1: I2C HID v1.00
>> Device [ITE8350:00 048D:8350] on i2c-ITE8350:00
>> [    5.528455] i2c_hid i2c-SYNA2B23:00: i2c-SYNA2B23:00 supply vdd not
>> found, using dummy regulator
>> [    5.528485] i2c_hid i2c-SYNA2B23:00: Linked as a consumer to regulator.0
>> [    5.528489] i2c_hid i2c-SYNA2B23:00: i2c-SYNA2B23:00 supply vddl not
>> found, using dummy regulator
>> [    5.543440] input: SYNA2B23:00 06CB:2714 Mouse as
>> /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-SYNA2B23:00/0018:06CB:2714.0003/input/input13
>> [    5.543690] hid-generic 0018:06CB:2714.0003: input,hidraw2: I2C HID
>> v1.00 Mouse [SYNA2B23:00 06CB:2714] on i2c-SYNA2B23:00
>> [    6.053237] input: Synaptics TM2714-002 as
>> /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-SYNA2B23:00/0018:06CB:2714.0003/input/input16
>> [    6.053444] hid-rmi 0018:06CB:2714.0003: input,hidraw1: I2C HID v1.00
>> Mouse [SYNA2B23:00 06CB:2714] on i2c-SYNA2B23:00
>>
>> Thanks!
>>
>>
> 

-- 
Alexey

Re: Debugging 3D sensor on Lenovo YOGA 700-11ISK

[Alexey Kardashevskiy]

On 17/03/2019 05:33, Jonathan Cameron wrote:
> 
> +CC bastien and (guessing it is a HID sensor) Srinivas.
> On Sat, 16 Mar 2019 20:16:39 +1100
> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> 
>> Hi!
>>
>> I got a quite old Lenovo YOGA 700-11ISK with flip screen and run
>> fedora29 on it. I found that gnome3 cannot properly detect the screen
>> orientation and the screen keeps rotating non stop.

While at this topic, when I "convert" the laptop to a tablet (one side
is screen, the other is keyboard and touchpad), the keyboard gets
disabled (good) but the touchpad does not (bad). What in
gnome3/fedora/linux/... does handle this?


-- 
Alexey

Re: Debugging 3D sensor on Lenovo YOGA 700-11ISK

[Pandruvada, Srinivas]

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

[...]

> [root@aikyoga iio:device4]# for i in
> /sys/bus/iio/devices/iio\:device0/scan_elements/* ; do echo $i ; cat
> $i
> ; done
> /sys/bus/iio/devices/iio:device0/scan_elements/in_rot_quaternion_en
> 0
> /sys/bus/iio/devices/iio:device0/scan_elements/in_rot_quaternion_inde
> x
> 0
> /sys/bus/iio/devices/iio:device0/scan_elements/in_rot_quaternion_type
> le:s32/32X4>>0
> 
> 
> The values do not change whether iio-sensor-proxy is running or not.
iio-sensor-proxy don't use quaternion. It depends on accel-3D for
rotation.

Thanks,
Srinivas

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3290 bytes --]

Re: Debugging 3D sensor on Lenovo YOGA 700-11ISK

[Pandruvada, Srinivas]

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

On Sun, 2019-03-17 at 12:58 +1100, Alexey Kardashevskiy wrote:
> 
> On 17/03/2019 05:33, Jonathan Cameron wrote:
> > 
> > +CC bastien and (guessing it is a HID sensor) Srinivas.
> > On Sat, 16 Mar 2019 20:16:39 +1100
> > Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> > 
> > > Hi!
> > > 
> > > I got a quite old Lenovo YOGA 700-11ISK with flip screen and run
> > > fedora29 on it. I found that gnome3 cannot properly detect the
> > > screen
> > > orientation and the screen keeps rotating non stop.
> 
> While at this topic, when I "convert" the laptop to a tablet (one
> side
> is screen, the other is keyboard and touchpad), the keyboard gets
> disabled (good) but the touchpad does not (bad). What in
> gnome3/fedora/linux/... does handle this?

These are ACPI events. Monitor input events using evetest.
Touchpad is coming through another hid device, so the user space may
not be disabling that.

> 
> 

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3290 bytes --]

Re: Debugging 3D sensor on Lenovo YOGA 700-11ISK

[Pandruvada, Srinivas]

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

On Sat, 2019-03-16 at 18:33 +0000, Jonathan Cameron wrote:
> +CC bastien and (guessing it is a HID sensor) Srinivas.
> On Sat, 16 Mar 2019 20:16:39 +1100
> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> 
> > Hi!
> > 
> > I got a quite old Lenovo YOGA 700-11ISK with flip screen and run
> > fedora29 on it. I found that gnome3 cannot properly detect the
> > screen
> > orientation and the screen keeps rotating non stop.
> > 
> > I opened an issue agains iio-sensor-proxy, not much luck there.
> > https://github.com/hadess/iio-sensor-proxy/issues/220
> > 
> > I resumed my debugging and the situation seems improving.
> > 
> > The yoga is running fedora29 v4.20.14. The fedora's iio-sensor-
> > proxy
> > still has this problem and so does the iio-sensor-proxy upstream
> > version.
> > 
> > Then I commented out &iio_buffer_accel to make &iio_poll_accel work
> > -
> > and things worked nicely. I looked in sysfs and in_accel_?_raw seem
> > to
> > have correct values (same as in the first log below, give or take),
> > all
> > good. Recorded some debug from iio-sensor-proxy:
> > 
> > Accel read from IIO on 'accel_3d': -39, -937, -378 (scale 0.009807)
> > Accel sent by driver (quirk applied): -39, -937, -378 (scale:
> > 0.009807)
> > Emitted orientation changed: from undefined to normal
> > No new data available on 'iio:device3'
> > Accel read from IIO on 'accel_3d': -39, -933, -371 (scale 0.009807)
> > Accel sent by driver (quirk applied): -39, -933, -371 (scale:
> > 0.009807)
> > No new data available on 'iio:device3'
> > Accel read from IIO on 'accel_3d': -39, -933, -367 (scale 0.009807)
> > Accel sent by driver (quirk applied): -39, -933, -367 (scale:
> > 0.009807)
> > 
> > This is the good log, gnome works fine.
> > 
> > 
> > Then I recorded debug with the buffer driver enabled:
> > 
> > rocess_scan_1: channel_index: 0, chan_name: in_accel_x,
> > channel_data_index: 0 location: 0
> > process_scan_1: channel_index: 1, chan_name: in_accel_y,
> > channel_data_index: 1 location: 4
> > process_scan_1: channel_index: 2, chan_name: in_accel_z,
> > channel_data_index: 2 location: 8
> > Accel read from IIO on 'iio:device4': -15, -898, -375 (scale
> > 0.009807)
> > Accel sent by driver (quirk applied): -15, -898, -375 (scale:
> > 0.009807)
> > Emitted orientation changed: from undefined to normal
> > No new data available on 'iio:device3'
> > process_scan_1: channel_index: 0, chan_name: in_accel_x,
> > channel_data_index: 0 location: 0
> > process_scan_1: channel_index: 1, chan_name: in_accel_y,
> > channel_data_index: 1 location: 4
> > process_scan_1: channel_index: 2, chan_name: in_accel_z,
> > channel_data_index: 2 location: 8
> > Accel read from IIO on 'iio:device4': 20774, 27203, 0 (scale
> > 0.009807)
> > Accel sent by driver (quirk applied): 20774, 27203, 0 (scale:
> > 0.009807)
> > Emitted orientation changed: from normal to left-up
> > No new data available on 'iio:device3'
> > process_scan_1: channel_index: 0, chan_name: in_accel_x,
> > channel_data_index: 0 location: 0
> > process_scan_1: channel_index: 1, chan_name: in_accel_y,
> > channel_data_index: 1 location: 4
> > process_scan_1: channel_index: 2, chan_name: in_accel_z,
> > channel_data_index: 2 location: 8
> > Accel read from IIO on 'iio:device4': -31, -929, -398 (scale
> > 0.009807)
> > Accel sent by driver (quirk applied): -31, -929, -398 (scale:
> > 0.009807)
> > Emitted orientation changed: from left-up to normal
> > No new data available on 'iio:device3'
> > process_scan_1: channel_index: 0, chan_name: in_accel_x,
> > channel_data_index: 0 location: 0
> > process_scan_1: channel_index: 1, chan_name: in_accel_y,
> > channel_data_index: 1 location: 4
> > process_scan_1: channel_index: 2, chan_name: in_accel_z,
> > channel_data_index: 2 location: 8
> > Accel read from IIO on 'iio:device4': -14345, -32024, 12738 (scale
> > 0.009807)
> > Accel sent by driver (quirk applied): -14345, -32024, 12738 (scale:
> > 0.009807)
> > 
> > So it is good reading, bad reading, good reading, bad reading, and
> > gnome
> > rotates the screen non stop. No wonder gnome3 goes crazy.
I suppose you don't move the screen. Try this to see if there is some
conversion errors in iio-sensor-proxy in some cases. Raw data is a
simply push from firmware, without any conversion..

rename /usr/sbin/iio-sensor-proxy for test only. Then reboot.
As part of linux kernel git, tools/iio, build iio-generic-buffer.

#sudo ./iio_generic_buffer -l 1 -a -c 100 -n accel_3d'


Thanks,
Srinivas

> > 
> > I would debug further and even come up with a fix but I failed to
> > find
> > quickly where there reads are handled in the kernel, and what
> > defines
> > these in_accel_?_raw files in sysfs, tried grepping - nothing. Any
> > pointers?


> 
> The raw files are built by the IIO core to call the read_raw callback
> in the
> each driver.  The path for buffered data is very different.
> Ultimately
> it goes through a call to iio_push_to_buffers.
> 
> > 
> > 
> > Also, how do I identify my particular 3d sensor? Or it is the same
> > model
> > everywhere? Or it is the driver for all of them?
> 
> Lots an lots and lots of drivers ;)   But in laptops they are often
> hid-sensors, or at least there is a little microcontroller that
> handles
> the different streams and reformats them as hid sensor records.
> 
> > 
> > Here is dmesg | grep i2c:
> 
> First of all, let us check the device. I'm going to guess it's a hid
> sensor of some type.
> Could you cat
> /sys/bus/iio/devices/iio\:device0/name
> 
> When iio-sensor-proxy is running (or after you've killed it) check
> what the values in the various files in
> /sys/bus/iio/devices/iio\:device0/scan_elements/* 
> are.  One thought is we have some unexpected channels enabled and
> the code is thinking they are acceleration when they aren't.
> 
> > 
> > [root@aikyoga iio:device4]# dmesg | egrep '(i2c|iio)'
> > [    5.389867] i2c_hid i2c-ITE8350:00: i2c-ITE8350:00 supply vdd
> > not
> > found, using dummy regulator
> > [    5.389893] i2c_hid i2c-ITE8350:00: Linked as a consumer to
> > regulator.0
> > [    5.389896] i2c_hid i2c-ITE8350:00: i2c-ITE8350:00 supply vddl
> > not
> > found, using dummy regulator
> > [    5.502896] hid-generic 0018:048D:8350.0002: hidraw1: I2C HID
> > v1.00
> > Device [ITE8350:00 048D:8350] on i2c-ITE8350:00
> > [    5.528455] i2c_hid i2c-SYNA2B23:00: i2c-SYNA2B23:00 supply vdd
> > not
> > found, using dummy regulator
> > [    5.528485] i2c_hid i2c-SYNA2B23:00: Linked as a consumer to
> > regulator.0
> > [    5.528489] i2c_hid i2c-SYNA2B23:00: i2c-SYNA2B23:00 supply vddl
> > not
> > found, using dummy regulator
> > [    5.543440] input: SYNA2B23:00 06CB:2714 Mouse as
> > /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-
> > SYNA2B23:00/0018:06CB:2714.0003/input/input13
> > [    5.543690] hid-generic 0018:06CB:2714.0003: input,hidraw2: I2C
> > HID
> > v1.00 Mouse [SYNA2B23:00 06CB:2714] on i2c-SYNA2B23:00
> > [    6.053237] input: Synaptics TM2714-002 as
> > /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-
> > SYNA2B23:00/0018:06CB:2714.0003/input/input16
> > [    6.053444] hid-rmi 0018:06CB:2714.0003: input,hidraw1: I2C HID
> > v1.00
> > Mouse [SYNA2B23:00 06CB:2714] on i2c-SYNA2B23:00
> > 
> > Thanks!
> > 
> > 
> 
> 

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3290 bytes --]

Re: Debugging 3D sensor on Lenovo YOGA 700-11ISK

[Alexey Kardashevskiy]

On 18/03/2019 03:26, Pandruvada, Srinivas wrote:
> On Sun, 2019-03-17 at 12:58 +1100, Alexey Kardashevskiy wrote:
>>
>> On 17/03/2019 05:33, Jonathan Cameron wrote:
>>>
>>> +CC bastien and (guessing it is a HID sensor) Srinivas.
>>> On Sat, 16 Mar 2019 20:16:39 +1100
>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>
>>>> Hi!
>>>>
>>>> I got a quite old Lenovo YOGA 700-11ISK with flip screen and run
>>>> fedora29 on it. I found that gnome3 cannot properly detect the
>>>> screen
>>>> orientation and the screen keeps rotating non stop.
>>
>> While at this topic, when I "convert" the laptop to a tablet (one
>> side
>> is screen, the other is keyboard and touchpad), the keyboard gets
>> disabled (good) but the touchpad does not (bad). What in
>> gnome3/fedora/linux/... does handle this?
> 
> These are ACPI events. Monitor input events using evetest.
> Touchpad is coming through another hid device, so the user space may
> not be disabling that.

So you are saying that the keyboard gets disabled by ACPI with no
interaction from Linux?

Anyway, if I want to catch such event and disable touchpad, how do I
catch transition to the tablet mode and back?



-- 
Alexey

Re: Debugging 3D sensor on Lenovo YOGA 700-11ISK

[Alexey Kardashevskiy]

On 18/03/2019 03:39, Pandruvada, Srinivas wrote:
> On Sat, 2019-03-16 at 18:33 +0000, Jonathan Cameron wrote:
>> +CC bastien and (guessing it is a HID sensor) Srinivas.
>> On Sat, 16 Mar 2019 20:16:39 +1100
>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>
>>> Hi!
>>>
>>> I got a quite old Lenovo YOGA 700-11ISK with flip screen and run
>>> fedora29 on it. I found that gnome3 cannot properly detect the
>>> screen
>>> orientation and the screen keeps rotating non stop.
>>>
>>> I opened an issue agains iio-sensor-proxy, not much luck there.
>>> https://github.com/hadess/iio-sensor-proxy/issues/220
>>>
>>> I resumed my debugging and the situation seems improving.
>>>
>>> The yoga is running fedora29 v4.20.14. The fedora's iio-sensor-
>>> proxy
>>> still has this problem and so does the iio-sensor-proxy upstream
>>> version.
>>>
>>> Then I commented out &iio_buffer_accel to make &iio_poll_accel work
>>> -
>>> and things worked nicely. I looked in sysfs and in_accel_?_raw seem
>>> to
>>> have correct values (same as in the first log below, give or take),
>>> all
>>> good. Recorded some debug from iio-sensor-proxy:
>>>
>>> Accel read from IIO on 'accel_3d': -39, -937, -378 (scale 0.009807)
>>> Accel sent by driver (quirk applied): -39, -937, -378 (scale:
>>> 0.009807)
>>> Emitted orientation changed: from undefined to normal
>>> No new data available on 'iio:device3'
>>> Accel read from IIO on 'accel_3d': -39, -933, -371 (scale 0.009807)
>>> Accel sent by driver (quirk applied): -39, -933, -371 (scale:
>>> 0.009807)
>>> No new data available on 'iio:device3'
>>> Accel read from IIO on 'accel_3d': -39, -933, -367 (scale 0.009807)
>>> Accel sent by driver (quirk applied): -39, -933, -367 (scale:
>>> 0.009807)
>>>
>>> This is the good log, gnome works fine.
>>>
>>>
>>> Then I recorded debug with the buffer driver enabled:
>>>
>>> rocess_scan_1: channel_index: 0, chan_name: in_accel_x,
>>> channel_data_index: 0 location: 0
>>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>>> channel_data_index: 1 location: 4
>>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>>> channel_data_index: 2 location: 8
>>> Accel read from IIO on 'iio:device4': -15, -898, -375 (scale
>>> 0.009807)
>>> Accel sent by driver (quirk applied): -15, -898, -375 (scale:
>>> 0.009807)
>>> Emitted orientation changed: from undefined to normal
>>> No new data available on 'iio:device3'
>>> process_scan_1: channel_index: 0, chan_name: in_accel_x,
>>> channel_data_index: 0 location: 0
>>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>>> channel_data_index: 1 location: 4
>>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>>> channel_data_index: 2 location: 8
>>> Accel read from IIO on 'iio:device4': 20774, 27203, 0 (scale
>>> 0.009807)
>>> Accel sent by driver (quirk applied): 20774, 27203, 0 (scale:
>>> 0.009807)
>>> Emitted orientation changed: from normal to left-up
>>> No new data available on 'iio:device3'
>>> process_scan_1: channel_index: 0, chan_name: in_accel_x,
>>> channel_data_index: 0 location: 0
>>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>>> channel_data_index: 1 location: 4
>>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>>> channel_data_index: 2 location: 8
>>> Accel read from IIO on 'iio:device4': -31, -929, -398 (scale
>>> 0.009807)
>>> Accel sent by driver (quirk applied): -31, -929, -398 (scale:
>>> 0.009807)
>>> Emitted orientation changed: from left-up to normal
>>> No new data available on 'iio:device3'
>>> process_scan_1: channel_index: 0, chan_name: in_accel_x,
>>> channel_data_index: 0 location: 0
>>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>>> channel_data_index: 1 location: 4
>>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>>> channel_data_index: 2 location: 8
>>> Accel read from IIO on 'iio:device4': -14345, -32024, 12738 (scale
>>> 0.009807)
>>> Accel sent by driver (quirk applied): -14345, -32024, 12738 (scale:
>>> 0.009807)
>>>
>>> So it is good reading, bad reading, good reading, bad reading, and
>>> gnome
>>> rotates the screen non stop. No wonder gnome3 goes crazy.
> I suppose you don't move the screen.

Correct.

> Try this to see if there is some
> conversion errors in iio-sensor-proxy in some cases. Raw data is a
> simply push from firmware, without any conversion..

Where does this push happen? Here?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/accel/hid-sensor-accel-3d.c#n244


> rename /usr/sbin/iio-sensor-proxy for test only. Then reboot.
> As part of linux kernel git, tools/iio, build iio-generic-buffer.
> 
> #sudo ./iio_generic_buffer -l 1 -a -c 100 -n accel_3d'


I'll give it a try tonight.


> 
> 
> Thanks,
> Srinivas
> 
>>>
>>> I would debug further and even come up with a fix but I failed to
>>> find
>>> quickly where there reads are handled in the kernel, and what
>>> defines
>>> these in_accel_?_raw files in sysfs, tried grepping - nothing. Any
>>> pointers?
> 
> 
>>
>> The raw files are built by the IIO core to call the read_raw callback
>> in the
>> each driver.  The path for buffered data is very different.
>> Ultimately
>> it goes through a call to iio_push_to_buffers.
>>
>>>
>>>
>>> Also, how do I identify my particular 3d sensor? Or it is the same
>>> model
>>> everywhere? Or it is the driver for all of them?
>>
>> Lots an lots and lots of drivers ;)   But in laptops they are often
>> hid-sensors, or at least there is a little microcontroller that
>> handles
>> the different streams and reformats them as hid sensor records.
>>
>>>
>>> Here is dmesg | grep i2c:
>>
>> First of all, let us check the device. I'm going to guess it's a hid
>> sensor of some type.
>> Could you cat
>> /sys/bus/iio/devices/iio\:device0/name
>>
>> When iio-sensor-proxy is running (or after you've killed it) check
>> what the values in the various files in
>> /sys/bus/iio/devices/iio\:device0/scan_elements/* 
>> are.  One thought is we have some unexpected channels enabled and
>> the code is thinking they are acceleration when they aren't.
>>
>>>
>>> [root@aikyoga iio:device4]# dmesg | egrep '(i2c|iio)'
>>> [    5.389867] i2c_hid i2c-ITE8350:00: i2c-ITE8350:00 supply vdd
>>> not
>>> found, using dummy regulator
>>> [    5.389893] i2c_hid i2c-ITE8350:00: Linked as a consumer to
>>> regulator.0
>>> [    5.389896] i2c_hid i2c-ITE8350:00: i2c-ITE8350:00 supply vddl
>>> not
>>> found, using dummy regulator
>>> [    5.502896] hid-generic 0018:048D:8350.0002: hidraw1: I2C HID
>>> v1.00
>>> Device [ITE8350:00 048D:8350] on i2c-ITE8350:00
>>> [    5.528455] i2c_hid i2c-SYNA2B23:00: i2c-SYNA2B23:00 supply vdd
>>> not
>>> found, using dummy regulator
>>> [    5.528485] i2c_hid i2c-SYNA2B23:00: Linked as a consumer to
>>> regulator.0
>>> [    5.528489] i2c_hid i2c-SYNA2B23:00: i2c-SYNA2B23:00 supply vddl
>>> not
>>> found, using dummy regulator
>>> [    5.543440] input: SYNA2B23:00 06CB:2714 Mouse as
>>> /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-
>>> SYNA2B23:00/0018:06CB:2714.0003/input/input13
>>> [    5.543690] hid-generic 0018:06CB:2714.0003: input,hidraw2: I2C
>>> HID
>>> v1.00 Mouse [SYNA2B23:00 06CB:2714] on i2c-SYNA2B23:00
>>> [    6.053237] input: Synaptics TM2714-002 as
>>> /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-
>>> SYNA2B23:00/0018:06CB:2714.0003/input/input16
>>> [    6.053444] hid-rmi 0018:06CB:2714.0003: input,hidraw1: I2C HID
>>> v1.00
>>> Mouse [SYNA2B23:00 06CB:2714] on i2c-SYNA2B23:00
>>>
>>> Thanks!
>>>
>>>
>>
>>

-- 
Alexey

Re: Debugging 3D sensor on Lenovo YOGA 700-11ISK

[Alexey Kardashevskiy]

On 18/03/2019 11:39, Alexey Kardashevskiy wrote:
> 
> 
> On 18/03/2019 03:39, Pandruvada, Srinivas wrote:
>> On Sat, 2019-03-16 at 18:33 +0000, Jonathan Cameron wrote:
>>> +CC bastien and (guessing it is a HID sensor) Srinivas.
>>> On Sat, 16 Mar 2019 20:16:39 +1100
>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>
>>>> Hi!
>>>>
>>>> I got a quite old Lenovo YOGA 700-11ISK with flip screen and run
>>>> fedora29 on it. I found that gnome3 cannot properly detect the
>>>> screen
>>>> orientation and the screen keeps rotating non stop.
>>>>
>>>> I opened an issue agains iio-sensor-proxy, not much luck there.
>>>> https://github.com/hadess/iio-sensor-proxy/issues/220
>>>>
>>>> I resumed my debugging and the situation seems improving.
>>>>
>>>> The yoga is running fedora29 v4.20.14. The fedora's iio-sensor-
>>>> proxy
>>>> still has this problem and so does the iio-sensor-proxy upstream
>>>> version.
>>>>
>>>> Then I commented out &iio_buffer_accel to make &iio_poll_accel work
>>>> -
>>>> and things worked nicely. I looked in sysfs and in_accel_?_raw seem
>>>> to
>>>> have correct values (same as in the first log below, give or take),
>>>> all
>>>> good. Recorded some debug from iio-sensor-proxy:
>>>>
>>>> Accel read from IIO on 'accel_3d': -39, -937, -378 (scale 0.009807)
>>>> Accel sent by driver (quirk applied): -39, -937, -378 (scale:
>>>> 0.009807)
>>>> Emitted orientation changed: from undefined to normal
>>>> No new data available on 'iio:device3'
>>>> Accel read from IIO on 'accel_3d': -39, -933, -371 (scale 0.009807)
>>>> Accel sent by driver (quirk applied): -39, -933, -371 (scale:
>>>> 0.009807)
>>>> No new data available on 'iio:device3'
>>>> Accel read from IIO on 'accel_3d': -39, -933, -367 (scale 0.009807)
>>>> Accel sent by driver (quirk applied): -39, -933, -367 (scale:
>>>> 0.009807)
>>>>
>>>> This is the good log, gnome works fine.
>>>>
>>>>
>>>> Then I recorded debug with the buffer driver enabled:
>>>>
>>>> rocess_scan_1: channel_index: 0, chan_name: in_accel_x,
>>>> channel_data_index: 0 location: 0
>>>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>>>> channel_data_index: 1 location: 4
>>>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>>>> channel_data_index: 2 location: 8
>>>> Accel read from IIO on 'iio:device4': -15, -898, -375 (scale
>>>> 0.009807)
>>>> Accel sent by driver (quirk applied): -15, -898, -375 (scale:
>>>> 0.009807)
>>>> Emitted orientation changed: from undefined to normal
>>>> No new data available on 'iio:device3'
>>>> process_scan_1: channel_index: 0, chan_name: in_accel_x,
>>>> channel_data_index: 0 location: 0
>>>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>>>> channel_data_index: 1 location: 4
>>>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>>>> channel_data_index: 2 location: 8
>>>> Accel read from IIO on 'iio:device4': 20774, 27203, 0 (scale
>>>> 0.009807)
>>>> Accel sent by driver (quirk applied): 20774, 27203, 0 (scale:
>>>> 0.009807)
>>>> Emitted orientation changed: from normal to left-up
>>>> No new data available on 'iio:device3'
>>>> process_scan_1: channel_index: 0, chan_name: in_accel_x,
>>>> channel_data_index: 0 location: 0
>>>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>>>> channel_data_index: 1 location: 4
>>>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>>>> channel_data_index: 2 location: 8
>>>> Accel read from IIO on 'iio:device4': -31, -929, -398 (scale
>>>> 0.009807)
>>>> Accel sent by driver (quirk applied): -31, -929, -398 (scale:
>>>> 0.009807)
>>>> Emitted orientation changed: from left-up to normal
>>>> No new data available on 'iio:device3'
>>>> process_scan_1: channel_index: 0, chan_name: in_accel_x,
>>>> channel_data_index: 0 location: 0
>>>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>>>> channel_data_index: 1 location: 4
>>>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>>>> channel_data_index: 2 location: 8
>>>> Accel read from IIO on 'iio:device4': -14345, -32024, 12738 (scale
>>>> 0.009807)
>>>> Accel sent by driver (quirk applied): -14345, -32024, 12738 (scale:
>>>> 0.009807)
>>>>
>>>> So it is good reading, bad reading, good reading, bad reading, and
>>>> gnome
>>>> rotates the screen non stop. No wonder gnome3 goes crazy.
>> I suppose you don't move the screen.
> 
> Correct.
> 
>> Try this to see if there is some
>> conversion errors in iio-sensor-proxy in some cases. Raw data is a
>> simply push from firmware, without any conversion..
> 
> Where does this push happen? Here?
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/accel/hid-sensor-accel-3d.c#n244
> 
> 
>> rename /usr/sbin/iio-sensor-proxy for test only. Then reboot.
>> As part of linux kernel git, tools/iio, build iio-generic-buffer.
>>
>> #sudo ./iio_generic_buffer -l 1 -a -c 100 -n accel_3d'
> 
> 
> I'll give it a try tonight.


Tried. The laptop was on a desk, firmly fixed, the tool printed first 2
entries and stops, I had to tap slightly on the laptop to make it
continue. Tried a few times, first few readings, a pause, a tap,
continues. In the example below one reading is weird (usually more are
weird), others seem good.

[root@aikyoga aik]# ./iio_generic_buffer -l 1 -a -c 100 -n accel_3d
iio device number being used is 0
iio trigger number being used is 0
Enabling all channels
Enabling: in_accel_x_en
Enabling: in_accel_z_en
Enabling: in_timestamp_en
Enabling: in_accel_y_en
/sys/bus/iio/devices/iio:device0 accel_3d-dev0
-0.382459 -9.071151 -3.824593 1552900771368191813
-0.382459 -9.071151 -3.824593 1552900771376264500
-0.343233 -8.423912 -4.971972 1552900776231212060
0.000000 0.000000 0.000000 1552900776232597107
-0.343233 -8.384686 -4.971972 1552900776251252367
0.000000 0.000000 0.000000 1552900776252606419
-0.343233 -8.345459 -5.011198 1552900776271057304
0.000000 0.000000 0.000000 1552900776272409930
-0.264780 -8.306232 -5.089651 1552900776291133439
0.000000 0.000000 0.000000 1552900776292461896
-0.225553 -8.306232 -5.168105 1552900776311581316
225.484299 -153.042572 20.466478 1552900776312958364
-0.225553 -8.306232 -5.168105 1552900776331232430
0.000000 0.000000 0.000000 1552900776332459423
-0.225553 -8.267006 -5.128878 1552900776351265820
0.000000 0.000000 0.000000 1552900776352593055
-0.264780 -8.267006 -5.168105 1552900776371443772
0.000000 0.000000 0.000000 1552900776372784463
-0.264780 -8.267006 -5.246558 1552900776391549343
0.000000 0.000000 0.000000 1552900776392968369
-0.225553 -8.306232 -5.315204 1552900776411677753
0.000000 0.000000 0.000000 1552900776412998853
-0.225553 -8.306232 -5.285784 1552900776431528699
0.000000 0.000000 0.000000 1552900776432881821
-0.225553 -8.306232 -5.207331 1552900776451678405
0.000000 0.000000 0.000000 1552900776452999756
-0.264780 -8.306232 -5.168105 1552900776471988891
0.000000 0.000000 0.000000 1552900776473335616
-0.264780 -8.306232 -5.168105 1552900776491891346
0.000000 0.000000 0.000000 1552900776493215237
-0.264780 -8.306232 -5.207331 1552900776516048625
0.000000 0.000000 0.000000 1552900776517478859
-0.264780 -8.306232 -5.207331 1552900776535855901
0.000000 0.000000 0.000000 1552900776537239117
-0.264780 -8.306232 -5.207331 1552900776556004660
0.000000 0.000000 0.000000 1552900776557361617
-0.264780 -8.306232 -5.168105 1552900776575969969
0.000000 0.000000 0.000000 1552900776577367957
-0.264780 -8.306232 -5.168105 1552900776596219505
0.000000 0.000000 0.000000 1552900776597645139
-0.304006 -8.306232 -5.168105 1552900776616188646
0.000000 0.000000 0.000000 1552900776617519289
-0.304006 -8.306232 -5.168105 1552900776636243776
0.000000 0.000000 0.000000 1552900776637629204
-0.264780 -8.306232 -5.207331 1552900776656315247
0.000000 0.000000 0.000000 1552900776657662508
-0.264780 -8.306232 -5.246558 1552900776676430435
0.000000 0.000000 0.000000 1552900776677854697
-0.225553 -8.306232 -5.246558 1552900776696561899
0.000000 0.000000 0.000000 1552900776697953993
-0.225553 -8.306232 -5.246558 1552900776716687038
0.000000 0.000000 0.000000 1552900776718013507
-0.225553 -8.306232 -5.207331 1552900776736600192
0.000000 0.000000 0.000000 1552900776737979245
-0.264780 -8.306232 -5.207331 1552900776756661393
0.000000 0.000000 0.000000 1552900776757973656
-0.264780 -8.345459 -5.168105 1552900776776918044
0.000000 0.000000 0.000000 1552900776778285204
-0.304006 -8.345459 -5.168105 1552900776796719607
0.000000 0.000000 0.000000 1552900776798043915
-0.304006 -8.345459 -5.168105 1552900776816969788
0.000000 0.000000 0.000000 1552900776818346899
-0.304006 -8.345459 -5.168105 1552900776836866458
0.000000 0.000000 0.000000 1552900776838190275
-0.264780 -8.306232 -5.207331 1552900776857025283
0.000000 0.000000 0.000000 1552900776858365006
-0.225553 -8.306232 -5.246558 1552900776876999835
0.000000 0.000000 0.000000 1552900776878320702
-0.225553 -8.306232 -5.246558 1552900776897067887
0.000000 0.000000 0.000000 1552900776898409864
-0.264780 -8.306232 -5.246558 1552900776917154306
0.000000 0.000000 0.000000 1552900776918528686
-0.264780 -8.306232 -5.207331 1552900776937174085
0.000000 0.000000 0.000000 1552900776938501132
-0.264780 -8.345459 -5.168105 1552900776957203402
0.000000 0.000000 0.000000 1552900776958540063
-0.264780 -8.345459 -5.168105 1552900776977338314
0.000000 0.000000 0.000000 1552900776978682085
-0.264780 -8.345459 -5.168105 1552900776997480789
0.000000 0.000000 0.000000 1552900776998808922
-0.264780 -8.306232 -5.168105 1552900777017397456
0.000000 0.000000 0.000000 1552900777018741222
-0.264780 -8.306232 -5.207331 1552900777037476271
0.000000 0.000000 0.000000 1552900777038806156
-0.264780 -8.306232 -5.207331 1552900777057563044
0.000000 0.000000 0.000000 1552900777058959603
-0.264780 -8.306232 -5.207331 1552900777077670982
0.000000 0.000000 0.000000 1552900777078985450
-0.264780 -8.306232 -5.207331 1552900777097699720
0.000000 0.000000 0.000000 1552900777099120245
-0.264780 -8.306232 -5.168105 1552900777117694705
0.000000 0.000000 0.000000 1552900777119056044
-0.264780 -8.306232 -5.168105 1552900777137793443
0.000000 0.000000 0.000000 1552900777139114214
-0.264780 -8.306232 -5.168105 1552900777158067260
0.000000 0.000000 0.000000 1552900777159426560
-0.264780 -8.306232 -5.207331 1552900777177946936
0.000000 0.000000 0.000000 1552900777179274696
-0.264780 -8.306232 -5.207331 1552900777198216778
0.000000 0.000000 0.000000 1552900777199587760
Disabling: in_accel_x_en
Disabling: in_accel_z_en
Disabling: in_timestamp_en
Disabling: in_accel_y_en
[root@aikyoga aik]#


But then I did more experimenting. I put laptop on my laps (so it was
not firmly fixed but I did not move it or rotate it) and started the
tool again. I got quite inconsistent readings:

-0.186326 -8.463139 -4.971972 1552900984763903094
-141.853195 -235.241913 251.001205 1552900984765201219
-0.186326 -8.423912 -4.824872 1552900984783855026
172.204773 249.824402 -219.482635 1552900984785172204
-0.147100 -8.423912 -4.628739 1552900984803895624
-219.482635 186.777451 -235.241913 1552900984805211796
-0.029420 -8.463139 -4.403186 1552900984823989997
0.000000 -32.705177 -235.241913 1552900984825302896
0.107873 -8.502365 -4.285506 1552900984843951448
0.000000 -32.705177 -235.241913 1552900984845283264
0.186326 -8.541592 -4.442412 1552900984864076546
251.001205 -173.381561 187.964050 1552900984865409126


And then I run it as "./iio_generic_buffer -l 1 -a -c 10000 -n accel_3d"
(10000 vs 100) and I got 10000 of very consistent readings like this:

-0.068647 -8.463139 -4.785645 1552900954123256005
-0.068647 -8.463139 -4.785645 1552900954124609317
0.000000 -8.502365 -5.050425 1552900954223793352
0.000000 -8.502365 -5.050425 1552900954225123224
0.107873 -8.463139 -4.824872 1552900954504475745
0.107873 -8.463139 -4.824872 1552900954505898733
-0.147100 -8.463139 -4.824872 1552900954564807056


I tried bisecting the number but around 3900..4000 it simply gave up :)

[  539.215108] i2c_designware i2c_designware.0: controller timed out
[  539.240414] i2c_designware i2c_designware.0: timeout in disabling adapter
[  539.263406] i2c_designware i2c_designware.0: timeout waiting for bus
ready
[  539.263410] i2c_hid i2c-ITE8350:00: failed to set a report to device.
[  539.285978] i2c_designware i2c_designware.0: timeout waiting for bus
ready


Looks like a weird accident though.


> 
> 
>>
>>
>> Thanks,
>> Srinivas
>>
>>>>
>>>> I would debug further and even come up with a fix but I failed to
>>>> find
>>>> quickly where there reads are handled in the kernel, and what
>>>> defines
>>>> these in_accel_?_raw files in sysfs, tried grepping - nothing. Any
>>>> pointers?
>>
>>
>>>
>>> The raw files are built by the IIO core to call the read_raw callback
>>> in the
>>> each driver.  The path for buffered data is very different.
>>> Ultimately
>>> it goes through a call to iio_push_to_buffers.
>>>
>>>>
>>>>
>>>> Also, how do I identify my particular 3d sensor? Or it is the same
>>>> model
>>>> everywhere? Or it is the driver for all of them?
>>>
>>> Lots an lots and lots of drivers ;)   But in laptops they are often
>>> hid-sensors, or at least there is a little microcontroller that
>>> handles
>>> the different streams and reformats them as hid sensor records.
>>>
>>>>
>>>> Here is dmesg | grep i2c:
>>>
>>> First of all, let us check the device. I'm going to guess it's a hid
>>> sensor of some type.
>>> Could you cat
>>> /sys/bus/iio/devices/iio\:device0/name
>>>
>>> When iio-sensor-proxy is running (or after you've killed it) check
>>> what the values in the various files in
>>> /sys/bus/iio/devices/iio\:device0/scan_elements/* 
>>> are.  One thought is we have some unexpected channels enabled and
>>> the code is thinking they are acceleration when they aren't.
>>>
>>>>
>>>> [root@aikyoga iio:device4]# dmesg | egrep '(i2c|iio)'
>>>> [    5.389867] i2c_hid i2c-ITE8350:00: i2c-ITE8350:00 supply vdd
>>>> not
>>>> found, using dummy regulator
>>>> [    5.389893] i2c_hid i2c-ITE8350:00: Linked as a consumer to
>>>> regulator.0
>>>> [    5.389896] i2c_hid i2c-ITE8350:00: i2c-ITE8350:00 supply vddl
>>>> not
>>>> found, using dummy regulator
>>>> [    5.502896] hid-generic 0018:048D:8350.0002: hidraw1: I2C HID
>>>> v1.00
>>>> Device [ITE8350:00 048D:8350] on i2c-ITE8350:00
>>>> [    5.528455] i2c_hid i2c-SYNA2B23:00: i2c-SYNA2B23:00 supply vdd
>>>> not
>>>> found, using dummy regulator
>>>> [    5.528485] i2c_hid i2c-SYNA2B23:00: Linked as a consumer to
>>>> regulator.0
>>>> [    5.528489] i2c_hid i2c-SYNA2B23:00: i2c-SYNA2B23:00 supply vddl
>>>> not
>>>> found, using dummy regulator
>>>> [    5.543440] input: SYNA2B23:00 06CB:2714 Mouse as
>>>> /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-
>>>> SYNA2B23:00/0018:06CB:2714.0003/input/input13
>>>> [    5.543690] hid-generic 0018:06CB:2714.0003: input,hidraw2: I2C
>>>> HID
>>>> v1.00 Mouse [SYNA2B23:00 06CB:2714] on i2c-SYNA2B23:00
>>>> [    6.053237] input: Synaptics TM2714-002 as
>>>> /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-
>>>> SYNA2B23:00/0018:06CB:2714.0003/input/input16
>>>> [    6.053444] hid-rmi 0018:06CB:2714.0003: input,hidraw1: I2C HID
>>>> v1.00
>>>> Mouse [SYNA2B23:00 06CB:2714] on i2c-SYNA2B23:00
>>>>
>>>> Thanks!
>>>>
>>>>
>>>
>>>
> 

-- 
Alexey

Re: Debugging 3D sensor on Lenovo YOGA 700-11ISK

[Pandruvada, Srinivas]

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

On Mon, 2019-03-18 at 20:32 +1100, Alexey Kardashevskiy wrote:
> 
> On 18/03/2019 11:39, Alexey Kardashevskiy wrote:
> > 
> > 
> > On 18/03/2019 03:39, Pandruvada, Srinivas wrote:
> > > On Sat, 2019-03-16 at 18:33 +0000, Jonathan Cameron wrote:
> > > > +CC bastien and (guessing it is a HID sensor) Srinivas.
> > > > On Sat, 16 Mar 2019 20:16:39 +1100
> > > > Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> > > > 
> > > > > Hi!
> > > > > 
> > > > > I got a quite old Lenovo YOGA 700-11ISK with flip screen and
> > > > > run
> > > > > fedora29 on it. I found that gnome3 cannot properly detect
> > > > > the
> > > > > screen
> > > > > orientation and the screen keeps rotating non stop.
> > > > > 
> > > > > I opened an issue agains iio-sensor-proxy, not much luck
> > > > > there.
> > > > > https://github.com/hadess/iio-sensor-proxy/issues/220
> > > > > 
> > > > > I resumed my debugging and the situation seems improving.
> > > > > 
> > > > > The yoga is running fedora29 v4.20.14. The fedora's iio-
> > > > > sensor-
> > > > > proxy
> > > > > still has this problem and so does the iio-sensor-proxy
> > > > > upstream
> > > > > version.
> > > > > 
> > > > > Then I commented out &iio_buffer_accel to make
> > > > > &iio_poll_accel work
> > > > > -
> > > > > and things worked nicely. I looked in sysfs and
> > > > > in_accel_?_raw seem
> > > > > to
> > > > > have correct values (same as in the first log below, give or
> > > > > take),
> > > > > all
> > > > > good. Recorded some debug from iio-sensor-proxy:
> > > > > 
> > > > > Accel read from IIO on 'accel_3d': -39, -937, -378 (scale
> > > > > 0.009807)
> > > > > Accel sent by driver (quirk applied): -39, -937, -378 (scale:
> > > > > 0.009807)
> > > > > Emitted orientation changed: from undefined to normal
> > > > > No new data available on 'iio:device3'
> > > > > Accel read from IIO on 'accel_3d': -39, -933, -371 (scale
> > > > > 0.009807)
> > > > > Accel sent by driver (quirk applied): -39, -933, -371 (scale:
> > > > > 0.009807)
> > > > > No new data available on 'iio:device3'
> > > > > Accel read from IIO on 'accel_3d': -39, -933, -367 (scale
> > > > > 0.009807)
> > > > > Accel sent by driver (quirk applied): -39, -933, -367 (scale:
> > > > > 0.009807)
> > > > > 
> > > > > This is the good log, gnome works fine.
> > > > > 
> > > > > 
> > > > > Then I recorded debug with the buffer driver enabled:
> > > > > 
> > > > > rocess_scan_1: channel_index: 0, chan_name: in_accel_x,
> > > > > channel_data_index: 0 location: 0
> > > > > process_scan_1: channel_index: 1, chan_name: in_accel_y,
> > > > > channel_data_index: 1 location: 4
> > > > > process_scan_1: channel_index: 2, chan_name: in_accel_z,
> > > > > channel_data_index: 2 location: 8
> > > > > Accel read from IIO on 'iio:device4': -15, -898, -375 (scale
> > > > > 0.009807)
> > > > > Accel sent by driver (quirk applied): -15, -898, -375 (scale:
> > > > > 0.009807)
> > > > > Emitted orientation changed: from undefined to normal
> > > > > No new data available on 'iio:device3'
> > > > > process_scan_1: channel_index: 0, chan_name: in_accel_x,
> > > > > channel_data_index: 0 location: 0
> > > > > process_scan_1: channel_index: 1, chan_name: in_accel_y,
> > > > > channel_data_index: 1 location: 4
> > > > > process_scan_1: channel_index: 2, chan_name: in_accel_z,
> > > > > channel_data_index: 2 location: 8
> > > > > Accel read from IIO on 'iio:device4': 20774, 27203, 0 (scale
> > > > > 0.009807)
> > > > > Accel sent by driver (quirk applied): 20774, 27203, 0 (scale:
> > > > > 0.009807)
> > > > > Emitted orientation changed: from normal to left-up
> > > > > No new data available on 'iio:device3'
> > > > > process_scan_1: channel_index: 0, chan_name: in_accel_x,
> > > > > channel_data_index: 0 location: 0
> > > > > process_scan_1: channel_index: 1, chan_name: in_accel_y,
> > > > > channel_data_index: 1 location: 4
> > > > > process_scan_1: channel_index: 2, chan_name: in_accel_z,
> > > > > channel_data_index: 2 location: 8
> > > > > Accel read from IIO on 'iio:device4': -31, -929, -398 (scale
> > > > > 0.009807)
> > > > > Accel sent by driver (quirk applied): -31, -929, -398 (scale:
> > > > > 0.009807)
> > > > > Emitted orientation changed: from left-up to normal
> > > > > No new data available on 'iio:device3'
> > > > > process_scan_1: channel_index: 0, chan_name: in_accel_x,
> > > > > channel_data_index: 0 location: 0
> > > > > process_scan_1: channel_index: 1, chan_name: in_accel_y,
> > > > > channel_data_index: 1 location: 4
> > > > > process_scan_1: channel_index: 2, chan_name: in_accel_z,
> > > > > channel_data_index: 2 location: 8
> > > > > Accel read from IIO on 'iio:device4': -14345, -32024, 12738
> > > > > (scale
> > > > > 0.009807)
> > > > > Accel sent by driver (quirk applied): -14345, -32024, 12738
> > > > > (scale:
> > > > > 0.009807)
> > > > > 
> > > > > So it is good reading, bad reading, good reading, bad
> > > > > reading, and
> > > > > gnome
> > > > > rotates the screen non stop. No wonder gnome3 goes crazy.
> > > 
> > > I suppose you don't move the screen.
> > 
> > Correct.
> > 
> > > Try this to see if there is some
> > > conversion errors in iio-sensor-proxy in some cases. Raw data is
> > > a
> > > simply push from firmware, without any conversion..
> > 
> > Where does this push happen? Here?
> > 
> > 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/accel/hid-sensor-accel-3d.c#n244
> > 
> > 
> > > rename /usr/sbin/iio-sensor-proxy for test only. Then reboot.
> > > As part of linux kernel git, tools/iio, build iio-generic-buffer.
> > > 
> > > #sudo ./iio_generic_buffer -l 1 -a -c 100 -n accel_3d'
> > 
> > 
> > I'll give it a try tonight.
> 
> 
> Tried. The laptop was on a desk, firmly fixed, the tool printed first
> 2
> entries and stops, I had to tap slightly on the laptop to make it
> continue. Tried a few times, first few readings, a pause, a tap,
> continues. In the example below one reading is weird (usually more
> are
> weird), others seem good.
That is the correct behavior. Unless the data changes by some
threshold, it shouldn't send more samples.

> 
> [root@aikyoga aik]# ./iio_generic_buffer -l 1 -a -c 100 -n accel_3d
> iio device number being used is 0
> iio trigger number being used is 0
> Enabling all channels
> Enabling: in_accel_x_en
> Enabling: in_accel_z_en
> Enabling: in_timestamp_en
> Enabling: in_accel_y_en
> /sys/bus/iio/devices/iio:device0 accel_3d-dev0
> -0.382459 -9.071151 -3.824593 1552900771368191813
> -0.382459 -9.071151 -3.824593 1552900771376264500
> -0.343233 -8.423912 -4.971972 1552900776231212060
> 0.000000 0.000000 0.000000 1552900776232597107
We are getting false interrupts, with invalid data (0s here).
We can try ignoring samples in iio-sensor-proxy when all axes are 0s to
workaround and try. In kernel drivers, we don't look at the data
received in buffer mode.

The iio-sensor-proxy code in github, so if you want to give a try.

Thanks,
Srinivas 

> -0.343233 -8.384686 -4.971972 1552900776251252367
> 0.000000 0.000000 0.000000 1552900776252606419
> -0.343233 -8.345459 -5.011198 1552900776271057304
> 0.000000 0.000000 0.000000 1552900776272409930
> -0.264780 -8.306232 -5.089651 1552900776291133439
> 0.000000 0.000000 0.000000 1552900776292461896
> -0.225553 -8.306232 -5.168105 1552900776311581316
> 225.484299 -153.042572 20.466478 1552900776312958364
> -0.225553 -8.306232 -5.168105 1552900776331232430
> 0.000000 0.000000 0.000000 1552900776332459423
> -0.225553 -8.267006 -5.128878 1552900776351265820
> 0.000000 0.000000 0.000000 1552900776352593055
> -0.264780 -8.267006 -5.168105 1552900776371443772
> 0.000000 0.000000 0.000000 1552900776372784463
> -0.264780 -8.267006 -5.246558 1552900776391549343
> 0.000000 0.000000 0.000000 1552900776392968369
> -0.225553 -8.306232 -5.315204 1552900776411677753
> 0.000000 0.000000 0.000000 1552900776412998853
> -0.225553 -8.306232 -5.285784 1552900776431528699
> 0.000000 0.000000 0.000000 1552900776432881821
> -0.225553 -8.306232 -5.207331 1552900776451678405
> 0.000000 0.000000 0.000000 1552900776452999756
> -0.264780 -8.306232 -5.168105 1552900776471988891
> 0.000000 0.000000 0.000000 1552900776473335616
> -0.264780 -8.306232 -5.168105 1552900776491891346
> 0.000000 0.000000 0.000000 1552900776493215237
> -0.264780 -8.306232 -5.207331 1552900776516048625
> 0.000000 0.000000 0.000000 1552900776517478859
> -0.264780 -8.306232 -5.207331 1552900776535855901
> 0.000000 0.000000 0.000000 1552900776537239117
> -0.264780 -8.306232 -5.207331 1552900776556004660
> 0.000000 0.000000 0.000000 1552900776557361617
> -0.264780 -8.306232 -5.168105 1552900776575969969
> 0.000000 0.000000 0.000000 1552900776577367957
> -0.264780 -8.306232 -5.168105 1552900776596219505
> 0.000000 0.000000 0.000000 1552900776597645139
> -0.304006 -8.306232 -5.168105 1552900776616188646
> 0.000000 0.000000 0.000000 1552900776617519289
> -0.304006 -8.306232 -5.168105 1552900776636243776
> 0.000000 0.000000 0.000000 1552900776637629204
> -0.264780 -8.306232 -5.207331 1552900776656315247
> 0.000000 0.000000 0.000000 1552900776657662508
> -0.264780 -8.306232 -5.246558 1552900776676430435
> 0.000000 0.000000 0.000000 1552900776677854697
> -0.225553 -8.306232 -5.246558 1552900776696561899
> 0.000000 0.000000 0.000000 1552900776697953993
> -0.225553 -8.306232 -5.246558 1552900776716687038
> 0.000000 0.000000 0.000000 1552900776718013507
> -0.225553 -8.306232 -5.207331 1552900776736600192
> 0.000000 0.000000 0.000000 1552900776737979245
> -0.264780 -8.306232 -5.207331 1552900776756661393
> 0.000000 0.000000 0.000000 1552900776757973656
> -0.264780 -8.345459 -5.168105 1552900776776918044
> 0.000000 0.000000 0.000000 1552900776778285204
> -0.304006 -8.345459 -5.168105 1552900776796719607
> 0.000000 0.000000 0.000000 1552900776798043915
> -0.304006 -8.345459 -5.168105 1552900776816969788
> 0.000000 0.000000 0.000000 1552900776818346899
> -0.304006 -8.345459 -5.168105 1552900776836866458
> 0.000000 0.000000 0.000000 1552900776838190275
> -0.264780 -8.306232 -5.207331 1552900776857025283
> 0.000000 0.000000 0.000000 1552900776858365006
> -0.225553 -8.306232 -5.246558 1552900776876999835
> 0.000000 0.000000 0.000000 1552900776878320702
> -0.225553 -8.306232 -5.246558 1552900776897067887
> 0.000000 0.000000 0.000000 1552900776898409864
> -0.264780 -8.306232 -5.246558 1552900776917154306
> 0.000000 0.000000 0.000000 1552900776918528686
> -0.264780 -8.306232 -5.207331 1552900776937174085
> 0.000000 0.000000 0.000000 1552900776938501132
> -0.264780 -8.345459 -5.168105 1552900776957203402
> 0.000000 0.000000 0.000000 1552900776958540063
> -0.264780 -8.345459 -5.168105 1552900776977338314
> 0.000000 0.000000 0.000000 1552900776978682085
> -0.264780 -8.345459 -5.168105 1552900776997480789
> 0.000000 0.000000 0.000000 1552900776998808922
> -0.264780 -8.306232 -5.168105 1552900777017397456
> 0.000000 0.000000 0.000000 1552900777018741222
> -0.264780 -8.306232 -5.207331 1552900777037476271
> 0.000000 0.000000 0.000000 1552900777038806156
> -0.264780 -8.306232 -5.207331 1552900777057563044
> 0.000000 0.000000 0.000000 1552900777058959603
> -0.264780 -8.306232 -5.207331 1552900777077670982
> 0.000000 0.000000 0.000000 1552900777078985450
> -0.264780 -8.306232 -5.207331 1552900777097699720
> 0.000000 0.000000 0.000000 1552900777099120245
> -0.264780 -8.306232 -5.168105 1552900777117694705
> 0.000000 0.000000 0.000000 1552900777119056044
> -0.264780 -8.306232 -5.168105 1552900777137793443
> 0.000000 0.000000 0.000000 1552900777139114214
> -0.264780 -8.306232 -5.168105 1552900777158067260
> 0.000000 0.000000 0.000000 1552900777159426560
> -0.264780 -8.306232 -5.207331 1552900777177946936
> 0.000000 0.000000 0.000000 1552900777179274696
> -0.264780 -8.306232 -5.207331 1552900777198216778
> 0.000000 0.000000 0.000000 1552900777199587760
> Disabling: in_accel_x_en
> Disabling: in_accel_z_en
> Disabling: in_timestamp_en
> Disabling: in_accel_y_en
> [root@aikyoga aik]#
> 
> 
> But then I did more experimenting. I put laptop on my laps (so it was
> not firmly fixed but I did not move it or rotate it) and started the
> tool again. I got quite inconsistent readings:
> 
> -0.186326 -8.463139 -4.971972 1552900984763903094
> -141.853195 -235.241913 251.001205 1552900984765201219
> -0.186326 -8.423912 -4.824872 1552900984783855026
> 172.204773 249.824402 -219.482635 1552900984785172204
> -0.147100 -8.423912 -4.628739 1552900984803895624
> -219.482635 186.777451 -235.241913 1552900984805211796
> -0.029420 -8.463139 -4.403186 1552900984823989997
> 0.000000 -32.705177 -235.241913 1552900984825302896
> 0.107873 -8.502365 -4.285506 1552900984843951448
> 0.000000 -32.705177 -235.241913 1552900984845283264
> 0.186326 -8.541592 -4.442412 1552900984864076546
> 251.001205 -173.381561 187.964050 1552900984865409126
> 
> 
> And then I run it as "./iio_generic_buffer -l 1 -a -c 10000 -n
> accel_3d"
> (10000 vs 100) and I got 10000 of very consistent readings like this:
> 
> -0.068647 -8.463139 -4.785645 1552900954123256005
> -0.068647 -8.463139 -4.785645 1552900954124609317
> 0.000000 -8.502365 -5.050425 1552900954223793352
> 0.000000 -8.502365 -5.050425 1552900954225123224
> 0.107873 -8.463139 -4.824872 1552900954504475745
> 0.107873 -8.463139 -4.824872 1552900954505898733
> -0.147100 -8.463139 -4.824872 1552900954564807056
> 
> 
> I tried bisecting the number but around 3900..4000 it simply gave up
> :)
> 
> [  539.215108] i2c_designware i2c_designware.0: controller timed out
> [  539.240414] i2c_designware i2c_designware.0: timeout in disabling
> adapter
> [  539.263406] i2c_designware i2c_designware.0: timeout waiting for
> bus
> ready
> [  539.263410] i2c_hid i2c-ITE8350:00: failed to set a report to
> device.
> [  539.285978] i2c_designware i2c_designware.0: timeout waiting for
> bus
> ready
> 
> 
> Looks like a weird accident though.
> 
> 
> > 
> > 
> > > 
> > > 
> > > Thanks,
> > > Srinivas
> > > 
> > > > > 
> > > > > I would debug further and even come up with a fix but I
> > > > > failed to
> > > > > find
> > > > > quickly where there reads are handled in the kernel, and what
> > > > > defines
> > > > > these in_accel_?_raw files in sysfs, tried grepping -
> > > > > nothing. Any
> > > > > pointers?
> > > 
> > > 
> > > > 
> > > > The raw files are built by the IIO core to call the read_raw
> > > > callback
> > > > in the
> > > > each driver.  The path for buffered data is very different.
> > > > Ultimately
> > > > it goes through a call to iio_push_to_buffers.
> > > > 
> > > > > 
> > > > > 
> > > > > Also, how do I identify my particular 3d sensor? Or it is the
> > > > > same
> > > > > model
> > > > > everywhere? Or it is the driver for all of them?
> > > > 
> > > > Lots an lots and lots of drivers ;)   But in laptops they are
> > > > often
> > > > hid-sensors, or at least there is a little microcontroller that
> > > > handles
> > > > the different streams and reformats them as hid sensor records.
> > > > 
> > > > > 
> > > > > Here is dmesg | grep i2c:
> > > > 
> > > > First of all, let us check the device. I'm going to guess it's
> > > > a hid
> > > > sensor of some type.
> > > > Could you cat
> > > > /sys/bus/iio/devices/iio\:device0/name
> > > > 
> > > > When iio-sensor-proxy is running (or after you've killed it)
> > > > check
> > > > what the values in the various files in
> > > > /sys/bus/iio/devices/iio\:device0/scan_elements/* 
> > > > are.  One thought is we have some unexpected channels enabled
> > > > and
> > > > the code is thinking they are acceleration when they aren't.
> > > > 
> > > > > 
> > > > > [root@aikyoga iio:device4]# dmesg | egrep '(i2c|iio)'
> > > > > [    5.389867] i2c_hid i2c-ITE8350:00: i2c-ITE8350:00 supply
> > > > > vdd
> > > > > not
> > > > > found, using dummy regulator
> > > > > [    5.389893] i2c_hid i2c-ITE8350:00: Linked as a consumer
> > > > > to
> > > > > regulator.0
> > > > > [    5.389896] i2c_hid i2c-ITE8350:00: i2c-ITE8350:00 supply
> > > > > vddl
> > > > > not
> > > > > found, using dummy regulator
> > > > > [    5.502896] hid-generic 0018:048D:8350.0002: hidraw1: I2C
> > > > > HID
> > > > > v1.00
> > > > > Device [ITE8350:00 048D:8350] on i2c-ITE8350:00
> > > > > [    5.528455] i2c_hid i2c-SYNA2B23:00: i2c-SYNA2B23:00
> > > > > supply vdd
> > > > > not
> > > > > found, using dummy regulator
> > > > > [    5.528485] i2c_hid i2c-SYNA2B23:00: Linked as a consumer
> > > > > to
> > > > > regulator.0
> > > > > [    5.528489] i2c_hid i2c-SYNA2B23:00: i2c-SYNA2B23:00
> > > > > supply vddl
> > > > > not
> > > > > found, using dummy regulator
> > > > > [    5.543440] input: SYNA2B23:00 06CB:2714 Mouse as
> > > > > /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-
> > > > > SYNA2B23:00/0018:06CB:2714.0003/input/input13
> > > > > [    5.543690] hid-generic 0018:06CB:2714.0003:
> > > > > input,hidraw2: I2C
> > > > > HID
> > > > > v1.00 Mouse [SYNA2B23:00 06CB:2714] on i2c-SYNA2B23:00
> > > > > [    6.053237] input: Synaptics TM2714-002 as
> > > > > /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-6/i2c-
> > > > > SYNA2B23:00/0018:06CB:2714.0003/input/input16
> > > > > [    6.053444] hid-rmi 0018:06CB:2714.0003: input,hidraw1:
> > > > > I2C HID
> > > > > v1.00
> > > > > Mouse [SYNA2B23:00 06CB:2714] on i2c-SYNA2B23:00
> > > > > 
> > > > > Thanks!
> > > > > 
> > > > > 
> > > > 
> > > > 
> 
> 

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3290 bytes --]

Re: Debugging 3D sensor on Lenovo YOGA 700-11ISK

[Alexey Kardashevskiy]

On 19/03/2019 02:57, Pandruvada, Srinivas wrote:
> On Mon, 2019-03-18 at 20:32 +1100, Alexey Kardashevskiy wrote:
>>
>> On 18/03/2019 11:39, Alexey Kardashevskiy wrote:
>>>
>>>
>>> On 18/03/2019 03:39, Pandruvada, Srinivas wrote:
>>>> On Sat, 2019-03-16 at 18:33 +0000, Jonathan Cameron wrote:
>>>>> +CC bastien and (guessing it is a HID sensor) Srinivas.
>>>>> On Sat, 16 Mar 2019 20:16:39 +1100
>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> I got a quite old Lenovo YOGA 700-11ISK with flip screen and
>>>>>> run
>>>>>> fedora29 on it. I found that gnome3 cannot properly detect
>>>>>> the
>>>>>> screen
>>>>>> orientation and the screen keeps rotating non stop.
>>>>>>
>>>>>> I opened an issue agains iio-sensor-proxy, not much luck
>>>>>> there.
>>>>>> https://github.com/hadess/iio-sensor-proxy/issues/220
>>>>>>
>>>>>> I resumed my debugging and the situation seems improving.
>>>>>>
>>>>>> The yoga is running fedora29 v4.20.14. The fedora's iio-
>>>>>> sensor-
>>>>>> proxy
>>>>>> still has this problem and so does the iio-sensor-proxy
>>>>>> upstream
>>>>>> version.
>>>>>>
>>>>>> Then I commented out &iio_buffer_accel to make
>>>>>> &iio_poll_accel work
>>>>>> -
>>>>>> and things worked nicely. I looked in sysfs and
>>>>>> in_accel_?_raw seem
>>>>>> to
>>>>>> have correct values (same as in the first log below, give or
>>>>>> take),
>>>>>> all
>>>>>> good. Recorded some debug from iio-sensor-proxy:
>>>>>>
>>>>>> Accel read from IIO on 'accel_3d': -39, -937, -378 (scale
>>>>>> 0.009807)
>>>>>> Accel sent by driver (quirk applied): -39, -937, -378 (scale:
>>>>>> 0.009807)
>>>>>> Emitted orientation changed: from undefined to normal
>>>>>> No new data available on 'iio:device3'
>>>>>> Accel read from IIO on 'accel_3d': -39, -933, -371 (scale
>>>>>> 0.009807)
>>>>>> Accel sent by driver (quirk applied): -39, -933, -371 (scale:
>>>>>> 0.009807)
>>>>>> No new data available on 'iio:device3'
>>>>>> Accel read from IIO on 'accel_3d': -39, -933, -367 (scale
>>>>>> 0.009807)
>>>>>> Accel sent by driver (quirk applied): -39, -933, -367 (scale:
>>>>>> 0.009807)
>>>>>>
>>>>>> This is the good log, gnome works fine.
>>>>>>
>>>>>>
>>>>>> Then I recorded debug with the buffer driver enabled:
>>>>>>
>>>>>> rocess_scan_1: channel_index: 0, chan_name: in_accel_x,
>>>>>> channel_data_index: 0 location: 0
>>>>>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>>>>>> channel_data_index: 1 location: 4
>>>>>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>>>>>> channel_data_index: 2 location: 8
>>>>>> Accel read from IIO on 'iio:device4': -15, -898, -375 (scale
>>>>>> 0.009807)
>>>>>> Accel sent by driver (quirk applied): -15, -898, -375 (scale:
>>>>>> 0.009807)
>>>>>> Emitted orientation changed: from undefined to normal
>>>>>> No new data available on 'iio:device3'
>>>>>> process_scan_1: channel_index: 0, chan_name: in_accel_x,
>>>>>> channel_data_index: 0 location: 0
>>>>>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>>>>>> channel_data_index: 1 location: 4
>>>>>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>>>>>> channel_data_index: 2 location: 8
>>>>>> Accel read from IIO on 'iio:device4': 20774, 27203, 0 (scale
>>>>>> 0.009807)
>>>>>> Accel sent by driver (quirk applied): 20774, 27203, 0 (scale:
>>>>>> 0.009807)
>>>>>> Emitted orientation changed: from normal to left-up
>>>>>> No new data available on 'iio:device3'
>>>>>> process_scan_1: channel_index: 0, chan_name: in_accel_x,
>>>>>> channel_data_index: 0 location: 0
>>>>>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>>>>>> channel_data_index: 1 location: 4
>>>>>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>>>>>> channel_data_index: 2 location: 8
>>>>>> Accel read from IIO on 'iio:device4': -31, -929, -398 (scale
>>>>>> 0.009807)
>>>>>> Accel sent by driver (quirk applied): -31, -929, -398 (scale:
>>>>>> 0.009807)
>>>>>> Emitted orientation changed: from left-up to normal
>>>>>> No new data available on 'iio:device3'
>>>>>> process_scan_1: channel_index: 0, chan_name: in_accel_x,
>>>>>> channel_data_index: 0 location: 0
>>>>>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>>>>>> channel_data_index: 1 location: 4
>>>>>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>>>>>> channel_data_index: 2 location: 8
>>>>>> Accel read from IIO on 'iio:device4': -14345, -32024, 12738
>>>>>> (scale
>>>>>> 0.009807)
>>>>>> Accel sent by driver (quirk applied): -14345, -32024, 12738
>>>>>> (scale:
>>>>>> 0.009807)
>>>>>>
>>>>>> So it is good reading, bad reading, good reading, bad
>>>>>> reading, and
>>>>>> gnome
>>>>>> rotates the screen non stop. No wonder gnome3 goes crazy.
>>>>
>>>> I suppose you don't move the screen.
>>>
>>> Correct.
>>>
>>>> Try this to see if there is some
>>>> conversion errors in iio-sensor-proxy in some cases. Raw data is
>>>> a
>>>> simply push from firmware, without any conversion..
>>>
>>> Where does this push happen? Here?
>>>
>>>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/accel/hid-sensor-accel-3d.c#n244
>>>
>>>
>>>> rename /usr/sbin/iio-sensor-proxy for test only. Then reboot.
>>>> As part of linux kernel git, tools/iio, build iio-generic-buffer.
>>>>
>>>> #sudo ./iio_generic_buffer -l 1 -a -c 100 -n accel_3d'
>>>
>>>
>>> I'll give it a try tonight.
>>
>>
>> Tried. The laptop was on a desk, firmly fixed, the tool printed first
>> 2
>> entries and stops, I had to tap slightly on the laptop to make it
>> continue. Tried a few times, first few readings, a pause, a tap,
>> continues. In the example below one reading is weird (usually more
>> are
>> weird), others seem good.
> That is the correct behavior. Unless the data changes by some
> threshold, it shouldn't send more samples.
> 
>>
>> [root@aikyoga aik]# ./iio_generic_buffer -l 1 -a -c 100 -n accel_3d
>> iio device number being used is 0
>> iio trigger number being used is 0
>> Enabling all channels
>> Enabling: in_accel_x_en
>> Enabling: in_accel_z_en
>> Enabling: in_timestamp_en
>> Enabling: in_accel_y_en
>> /sys/bus/iio/devices/iio:device0 accel_3d-dev0
>> -0.382459 -9.071151 -3.824593 1552900771368191813
>> -0.382459 -9.071151 -3.824593 1552900771376264500
>> -0.343233 -8.423912 -4.971972 1552900776231212060
>> 0.000000 0.000000 0.000000 1552900776232597107
> We are getting false interrupts, with invalid data (0s here).
> We can try ignoring samples in iio-sensor-proxy when all axes are 0s to
> workaround and try. In kernel drivers, we don't look at the data
> received in buffer mode.
> 
> The iio-sensor-proxy code in github, so if you want to give a try.


Try what precisely? I am already using the version from there with the
buffer driver disabled so it uses the polling driver which works well,
and the last update there was to add more debug logging for
https://github.com/hadess/iio-sensor-proxy/issues/220 which I updated
with the new logs.

Could you please point me in the kernel where the values used by the
polling driver are calculated? Literally, where is sysfs's
in_accel_x_raw is defined? Thanks.


-- 
Alexey

Re: Debugging 3D sensor on Lenovo YOGA 700-11ISK

[Alexey Kardashevskiy]

On 19/03/2019 11:30, Pandruvada, Srinivas wrote:
> On Tue, 2019-03-19 at 10:28 +1100, Alexey Kardashevskiy wrote:
>>
>> On 19/03/2019 02:57, Pandruvada, Srinivas wrote:
>>> On Mon, 2019-03-18 at 20:32 +1100, Alexey Kardashevskiy wrote:
>>>>
>>>> On 18/03/2019 11:39, Alexey Kardashevskiy wrote:
>>>>>
>>>>>
>>>>> On 18/03/2019 03:39, Pandruvada, Srinivas wrote:
>>>>>> On Sat, 2019-03-16 at 18:33 +0000, Jonathan Cameron wrote:
>>>>>>> +CC bastien and (guessing it is a HID sensor) Srinivas.
>>>>>>> On Sat, 16 Mar 2019 20:16:39 +1100
>>>>>>> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>>>
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> I got a quite old Lenovo YOGA 700-11ISK with flip screen
>>>>>>>> and
>>>>>>>> run
>>>>>>>> fedora29 on it. I found that gnome3 cannot properly
>>>>>>>> detect
>>>>>>>> the
>>>>>>>> screen
>>>>>>>> orientation and the screen keeps rotating non stop.
>>>>>>>>
>>>>>>>> I opened an issue agains iio-sensor-proxy, not much luck
>>>>>>>> there.
>>>>>>>> https://github.com/hadess/iio-sensor-proxy/issues/220
>>>>>>>>
>>>>>>>> I resumed my debugging and the situation seems improving.
>>>>>>>>
>>>>>>>> The yoga is running fedora29 v4.20.14. The fedora's iio-
>>>>>>>> sensor-
>>>>>>>> proxy
>>>>>>>> still has this problem and so does the iio-sensor-proxy
>>>>>>>> upstream
>>>>>>>> version.
>>>>>>>>
>>>>>>>> Then I commented out &iio_buffer_accel to make
>>>>>>>> &iio_poll_accel work
>>>>>>>> -
>>>>>>>> and things worked nicely. I looked in sysfs and
>>>>>>>> in_accel_?_raw seem
>>>>>>>> to
>>>>>>>> have correct values (same as in the first log below, give
>>>>>>>> or
>>>>>>>> take),
>>>>>>>> all
>>>>>>>> good. Recorded some debug from iio-sensor-proxy:
>>>>>>>>
>>>>>>>> Accel read from IIO on 'accel_3d': -39, -937, -378 (scale
>>>>>>>> 0.009807)
>>>>>>>> Accel sent by driver (quirk applied): -39, -937, -378
>>>>>>>> (scale:
>>>>>>>> 0.009807)
>>>>>>>> Emitted orientation changed: from undefined to normal
>>>>>>>> No new data available on 'iio:device3'
>>>>>>>> Accel read from IIO on 'accel_3d': -39, -933, -371 (scale
>>>>>>>> 0.009807)
>>>>>>>> Accel sent by driver (quirk applied): -39, -933, -371
>>>>>>>> (scale:
>>>>>>>> 0.009807)
>>>>>>>> No new data available on 'iio:device3'
>>>>>>>> Accel read from IIO on 'accel_3d': -39, -933, -367 (scale
>>>>>>>> 0.009807)
>>>>>>>> Accel sent by driver (quirk applied): -39, -933, -367
>>>>>>>> (scale:
>>>>>>>> 0.009807)
>>>>>>>>
>>>>>>>> This is the good log, gnome works fine.
>>>>>>>>
>>>>>>>>
>>>>>>>> Then I recorded debug with the buffer driver enabled:
>>>>>>>>
>>>>>>>> rocess_scan_1: channel_index: 0, chan_name: in_accel_x,
>>>>>>>> channel_data_index: 0 location: 0
>>>>>>>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>>>>>>>> channel_data_index: 1 location: 4
>>>>>>>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>>>>>>>> channel_data_index: 2 location: 8
>>>>>>>> Accel read from IIO on 'iio:device4': -15, -898, -375
>>>>>>>> (scale
>>>>>>>> 0.009807)
>>>>>>>> Accel sent by driver (quirk applied): -15, -898, -375
>>>>>>>> (scale:
>>>>>>>> 0.009807)
>>>>>>>> Emitted orientation changed: from undefined to normal
>>>>>>>> No new data available on 'iio:device3'
>>>>>>>> process_scan_1: channel_index: 0, chan_name: in_accel_x,
>>>>>>>> channel_data_index: 0 location: 0
>>>>>>>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>>>>>>>> channel_data_index: 1 location: 4
>>>>>>>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>>>>>>>> channel_data_index: 2 location: 8
>>>>>>>> Accel read from IIO on 'iio:device4': 20774, 27203, 0
>>>>>>>> (scale
>>>>>>>> 0.009807)
>>>>>>>> Accel sent by driver (quirk applied): 20774, 27203, 0
>>>>>>>> (scale:
>>>>>>>> 0.009807)
>>>>>>>> Emitted orientation changed: from normal to left-up
>>>>>>>> No new data available on 'iio:device3'
>>>>>>>> process_scan_1: channel_index: 0, chan_name: in_accel_x,
>>>>>>>> channel_data_index: 0 location: 0
>>>>>>>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>>>>>>>> channel_data_index: 1 location: 4
>>>>>>>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>>>>>>>> channel_data_index: 2 location: 8
>>>>>>>> Accel read from IIO on 'iio:device4': -31, -929, -398
>>>>>>>> (scale
>>>>>>>> 0.009807)
>>>>>>>> Accel sent by driver (quirk applied): -31, -929, -398
>>>>>>>> (scale:
>>>>>>>> 0.009807)
>>>>>>>> Emitted orientation changed: from left-up to normal
>>>>>>>> No new data available on 'iio:device3'
>>>>>>>> process_scan_1: channel_index: 0, chan_name: in_accel_x,
>>>>>>>> channel_data_index: 0 location: 0
>>>>>>>> process_scan_1: channel_index: 1, chan_name: in_accel_y,
>>>>>>>> channel_data_index: 1 location: 4
>>>>>>>> process_scan_1: channel_index: 2, chan_name: in_accel_z,
>>>>>>>> channel_data_index: 2 location: 8
>>>>>>>> Accel read from IIO on 'iio:device4': -14345, -32024,
>>>>>>>> 12738
>>>>>>>> (scale
>>>>>>>> 0.009807)
>>>>>>>> Accel sent by driver (quirk applied): -14345, -32024,
>>>>>>>> 12738
>>>>>>>> (scale:
>>>>>>>> 0.009807)
>>>>>>>>
>>>>>>>> So it is good reading, bad reading, good reading, bad
>>>>>>>> reading, and
>>>>>>>> gnome
>>>>>>>> rotates the screen non stop. No wonder gnome3 goes crazy.
>>>>>>
>>>>>> I suppose you don't move the screen.
>>>>>
>>>>> Correct.
>>>>>
>>>>>> Try this to see if there is some
>>>>>> conversion errors in iio-sensor-proxy in some cases. Raw data
>>>>>> is
>>>>>> a
>>>>>> simply push from firmware, without any conversion..
>>>>>
>>>>> Where does this push happen? Here?
>>>>>
>>>>>
>>>
>>>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/accel/hid-sensor-accel-3d.c#n244
>>>>>
>>>>>
>>>>>> rename /usr/sbin/iio-sensor-proxy for test only. Then reboot.
>>>>>> As part of linux kernel git, tools/iio, build iio-generic-
>>>>>> buffer.
>>>>>>
>>>>>> #sudo ./iio_generic_buffer -l 1 -a -c 100 -n accel_3d'
>>>>>
>>>>>
>>>>> I'll give it a try tonight.
>>>>
>>>>
>>>> Tried. The laptop was on a desk, firmly fixed, the tool printed
>>>> first
>>>> 2
>>>> entries and stops, I had to tap slightly on the laptop to make it
>>>> continue. Tried a few times, first few readings, a pause, a tap,
>>>> continues. In the example below one reading is weird (usually
>>>> more
>>>> are
>>>> weird), others seem good.
>>>
>>> That is the correct behavior. Unless the data changes by some
>>> threshold, it shouldn't send more samples.
>>>
>>>>
>>>> [root@aikyoga aik]# ./iio_generic_buffer -l 1 -a -c 100 -n
>>>> accel_3d
>>>> iio device number being used is 0
>>>> iio trigger number being used is 0
>>>> Enabling all channels
>>>> Enabling: in_accel_x_en
>>>> Enabling: in_accel_z_en
>>>> Enabling: in_timestamp_en
>>>> Enabling: in_accel_y_en
>>>> /sys/bus/iio/devices/iio:device0 accel_3d-dev0
>>>> -0.382459 -9.071151 -3.824593 1552900771368191813
>>>> -0.382459 -9.071151 -3.824593 1552900771376264500
>>>> -0.343233 -8.423912 -4.971972 1552900776231212060
>>>> 0.000000 0.000000 0.000000 1552900776232597107
>>>
>>> We are getting false interrupts, with invalid data (0s here).
>>> We can try ignoring samples in iio-sensor-proxy when all axes are
>>> 0s to
>>> workaround and try. In kernel drivers, we don't look at the data
>>> received in buffer mode.
>>>
>>> The iio-sensor-proxy code in github, so if you want to give a try.
>>
>>
>> Try what precisely? I am already using the version from there with
>> the
>> buffer driver disabled so it uses the polling driver which works
>> well,
>> and the last update there was to add more debug logging for
>> https://github.com/hadess/iio-sensor-proxy/issues/220 which I updated
>> with the new logs.
> 
> If this works then you don't need to worry. You can always use raw
> interface unless you want to debug iio buffer interface.

My worry is that iio-sensor-proxy from distros uses the buffer driver
which does not work for unknown reason.

>>
>> Could you please point me in the kernel where the values used by the
>> polling driver are calculated? Literally, where is sysfs's
>> in_accel_x_raw is defined? 
> /sys/bus/iio/devices/iio:device*
> where name = accel_3d.
> 
> Refer to iio buffer interface for how to read from buffers by enabling
> channels. tools/iio/iio_generic_buffer.c is an example how to use.


No, my question was about the kernel side of the device, not the
userspace, it is late to look there - the data seems to be broken. I am
interested to see how these buffers are filled with data and compare to
what linux exposes via in_accel_x_raw sysfs properties. Oh well, it is
debugging time them.



-- 
Alexey

Re: Debugging 3D sensor on Lenovo YOGA 700-11ISK

[Pandruvada, Srinivas]

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

On Tue, 2019-03-19 at 12:14 +1100, Alexey Kardashevskiy wrote:
> 

[...]

> Refer to iio buffer interface for how to read from buffers by
> > enabling
> > channels. tools/iio/iio_generic_buffer.c is an example how to use.
> 
> 
> No, my question was about the kernel side of the device, not the
> userspace, it is late to look there - the data seems to be broken. I
> am
> interested to see how these buffers are filled with data and compare
> to
> what linux exposes via in_accel_x_raw sysops properties. Oh well, it
> is
> debugging time them.
kernel processing is done in multiple layers, from transport->hid-
sensor-hub.c->hid-sensor-accel-3d.c
The kernel is just sending what FW is sending in buffer mode.
FW is sending 0,0,0 for x,y,z. This is the way FW is telling that it
completed a batch. Basically the user space could have gone to sleep by
informing that don't bother it for x amount of time or samples. It
seems that this platform is enabling batch mode, whether user space
wants it or not.

Try this change iio-sensor-proxy. From raw data 

diff --git a/src/drv-iio-buffer-accel.c b/src/drv-iio-buffer-accel.c
index ebf94de..84a83a3 100644
--- a/src/drv-iio-buffer-accel.c
+++ b/src/drv-iio-buffer-accel.c
@@ -65,6 +65,11 @@ process_scan (IIOSensorData data, DrvData *or_data)
        tmp.y = accel_y;
        tmp.z = accel_z;
 
+       if (tmp.x == 0 && tmp.y == 0 && tmp.z == 0) {
+               g_debug("batch complete\n");
+               return 0;
+       }
+
        if (!apply_mount_matrix (or_data->mount_matrix, &tmp))
                g_warning ("Could not apply mount matrix");
 

Thanks,
Srinivas


> 
> 
> 

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3290 bytes --]

Re: Debugging 3D sensor on Lenovo YOGA 700-11ISK

[Alexey Kardashevskiy]

On 20/03/2019 07:46, Pandruvada, Srinivas wrote:
> On Tue, 2019-03-19 at 12:14 +1100, Alexey Kardashevskiy wrote:
>>
> 
> [...]
> 
>> Refer to iio buffer interface for how to read from buffers by
>>> enabling
>>> channels. tools/iio/iio_generic_buffer.c is an example how to use.
>>
>>
>> No, my question was about the kernel side of the device, not the
>> userspace, it is late to look there - the data seems to be broken. I
>> am
>> interested to see how these buffers are filled with data and compare
>> to
>> what linux exposes via in_accel_x_raw sysops properties. Oh well, it
>> is
>> debugging time them.
> kernel processing is done in multiple layers, from transport->hid-
> sensor-hub.c->hid-sensor-accel-3d.c
> The kernel is just sending what FW is sending in buffer mode.
> FW is sending 0,0,0 for x,y,z. This is the way FW is telling that it
> completed a batch. Basically the user space could have gone to sleep by
> informing that don't bother it for x amount of time or samples. It
> seems that this platform is enabling batch mode, whether user space
> wants it or not.
> 
> Try this change iio-sensor-proxy. From raw data 
> 
> diff --git a/src/drv-iio-buffer-accel.c b/src/drv-iio-buffer-accel.c
> index ebf94de..84a83a3 100644
> --- a/src/drv-iio-buffer-accel.c
> +++ b/src/drv-iio-buffer-accel.c
> @@ -65,6 +65,11 @@ process_scan (IIOSensorData data, DrvData *or_data)
>         tmp.y = accel_y;
>         tmp.z = accel_z;
>  
> +       if (tmp.x == 0 && tmp.y == 0 && tmp.z == 0) {
> +               g_debug("batch complete\n");
> +               return 0;
> +       }
> +

I tried, it did not help - worked for a little bit - turned laptop 3
times - and then started rotating it endlessly. The problem is not with
zero samples (or not just with them) but with wrong samples too.


>         if (!apply_mount_matrix (or_data->mount_matrix, &tmp))
>                 g_warning ("Could not apply mount matrix");
>  
> 
> Thanks,
> Srinivas
> 
> 
>>
>>
>>

-- 
Alexey