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@xxxxxxxxx> 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
