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