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. 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:
smime.p7s
Description: S/MIME cryptographic signature
