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