Screen Rotation Problem with 7.1 RC2 and KXCJ9

[BrokenE39]

I been searching the group for some answers but couldn't find a definite solution to the problem. I have a Teclast X98 Plus A5C6 Intel Cherrytrail Z8300 tablet and I managed to compile a custom ISO and have touch and wifi working. I have done the following:

ro.hardware.sensors = iio

ro.iio.accel.x.opt_scale = -1
ro.iio.accel.y.opt_scale = -1

ro.iio.accel.z.opt_scale = -1

had_sensors=true at the end of the init_hal_sensors section in init.sh

When I run cat /sys/bus/iio/devices/iio\:device0/in_accel_x_raw, I do get different values as I moved the tablet. Repeating the command for Y and Z also produce different values. However, when I loaded Sensor Test app, it detects the accelerator but say no input data. Am I missing a configuration step?

[Chih-Wei Huang]

Looks fine to me. No additional step is required.

Check logcat to see if the sensors hal is really enabled.

[Daniel Cheung]

I reinstalled 7.1 again but without the opt_scale values in the BuildProp file. I found the following:

+ init_hal_sensors
+ getprop ro.hardware
+ ro_hardware=android_x86_64
+ '[' -f /system/lib/hw/sensors.android_x86_64.so ']'
+ typeset 'hal_sensors=kbd'
+ typeset 'has_sensors=true'
+ cat /sys/class/dmi/id/uevent
+ has_sensors=false
+ 2>/dev/null
+ ls /sys/bus/iio/devices/iio:device0
type=1400 audit(0.0:67): avc: denied { ioctl } for comm="ls" path="pipe:[1847]" dev="pipefs" ino=1847 ioctlcmd=0x5413 scontext=u:r:toolbox:s0 tcontext=u:r:init:s0 tclass=fifo_file permissive=1
type=1400 audit(0.0:67): avc: denied { ioctl } for path="pipe:[1847]" dev="pipefs" ino=1847 ioctlcmd=0x5413 scontext=u:r:toolbox:s0 tcontext=u:r:init:s0 tclass=fifo_file permissive=1
+ '[' -n $'buffer\ncurrent_timestamp_clock\ndev\nevents\nin_accel_sampling_frequency\nin_accel_scale\nin_accel_scale_available\nin_accel_x_raw\nin_accel_y_raw\nin_accel_z_raw\nname\npower\nsampling_frequency_available\nscan_elements\nsubsystem\ntrigger\nuevent' ']'
+ busybox chown -R 1000.1000 /sys/bus/iio/devices/iio:device0/
+ 2>/dev/null
+ ls /sys/bus/iio/devices/iio:device0/in_accel_x_raw
+ '[' -n /sys/bus/iio/devices/iio:device0/in_accel_x_raw ']'
+ has_sensors=true
+ hal_sensors=iio
+ set_property ro.hardware.sensors iio
+ setprop ro.hardware.sensors iio
+ '[' -n 2 ']'
+ >>/dev/x86.prop
+ echo 'ro.hardware.sensors=iio'
+ set_property config.override_forced_orient true
+ setprop config.override_forced_orient true
+ '[' -n 2 ']'
+ >>/dev/x86.prop

+ echo 'config.override_forced_orient=true'

So init.sh is setting sensors to true and telling the system there is a sensor to use. However, further down the log, I found this:

SensorService: nuSensorService starting...
Sensors : Initializing IIO sensors HAL module
Sensors : Cannot read string from /sys/bus/iio/devices/iio:device0/in_accel_offset (No such file or directory)
Sensors : Cannot read number from /sys/bus/iio/devices/iio:device0/in_accel_offset (No such file or directory)
Sensors : Cannot read string from /sys/bus/iio/devices/iio:device0/mounting_matrix (No such file or directory)
Sensors : Cannot read string from /sys/bus/iio/devices/iio:device0/../firmware_node/pld/panel (No such file or directory)
Sensors : Cannot read number from /sys/bus/iio/devices/iio:device0/../firmware_node/pld/panel (No such file or directory)
Sensors : Found 3 channels on iio device 0
Sensors : S0 C0 : offset 0, size 2, type le:s12/16>>4
Sensors : S0 C1 : offset 2, size 2, type le:s12/16>>4
Sensors : S0 C2 : offset 4, size 2, type le:s12/16>>4
Sensors : Detected timestamp channel on iio device 0
Sensors : Expecting 16 scan length on iio dev 0
Sensors : Discovered 1 sensors
Sensors : Cannot read string from /sys/bus/iio/devices/trigger0/name (No such file or directory)
Sensors : Sensor 0 (S0-i2c-KIOX000A:00) default trigger: i2c-KIOX000A:00-dev0
Sensors : Discovered 1 sensors
Sensors : S0: S0-i2c-KIOX000A:00
SensorService: Generated new HMAC key.
SensorService: nuSensorService thread starting...
SensorService: new thread SensorEventAckReceiver

Further down the log:

Sensors : Sensor 0 (S0-i2c-KIOX000A:00) sampling rate set to 25

Sensors : Enabling sensor 0 (iio device 0: S0-i2c-KIOX000A:00)
Sensors : Setting S0 (S0-i2c-KIOX000A:00) trigger to i2c-KIOX000A:00-dev0
Sensors : Cannot write to /sys/bus/iio/devices/iio:device0/buffer/enable (Invalid argument)
Sensors : Failed enabling buffer on dev0, retrying
Sensors : Cannot write to /sys/bus/iio/devices/iio:device0/buffer/enable (Invalid argument)
Sensors : Failed enabling buffer on dev0, retrying
Sensors : Cannot write to /sys/bus/iio/devices/iio:device0/buffer/enable (Invalid argument)
Sensors : Failed enabling buffer on dev0, retrying
wm_task_removed: [1,removeAppToken: last token]
wm_task_removed: [1,removeTask]
Sensors : Could not enable buffer
Sensors : Activation of sensor S0-i2c-KIOX000A:00 took 1 ms

If I'm reading this correctly, it appears that there aren't enough information to run the sensor correctly.

--
You received this message because you are subscribed to the Google Groups "Android-x86" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-x86+unsubscribe@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-x86.
For more options, visit https://groups.google.com/d/optout.

[Chih-Wei Huang]

It looks like the sensor driver is buggy.

Does it work in other Linux distro like Ubuntu?


--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[Daniel Cheung]

I have not tried installing the latest Ubuntu on it but I can give it a test and report back. Kionix has publish their own Android drivers but when I read the file, it only have i2c_bus values for Tegra4 and OMAP type of CPU. I also saw a Chromium OS driver when I was searching around.

https://chromium.googlesource.com/chromiumos/platform/ec/+/master/driver/accel_kionix.c

[Daniel Cheung]

Tested with Ubuntu 17.04 and no luck with the sensor working. Since wireless LAN also doesn't work, I don't know if I need to download updates for it to work on Ubuntu.

[Daniel Cheung]

Using iio-old instead of iio, I got the rotation to work. However, the orientation is off by 90 degrees. I tried using x_opt scale -1, order 102, and playing with the matrix values but don't have much luck. Also, I couldn't understand how the matrix values work. Any suggestions?

To unsubscribe from this group and stop receiving emails from it, send an email to android-x86...@googlegroups.com.

[Chih-Wei Huang]

2018-08-25 15:29 GMT+08:00 Daniel Cheung <dwt.c...@gmail.com>:
> Using iio-old instead of iio, I got the rotation to work. However, the
> orientation is off by 90 degrees. I tried using x_opt scale -1, order 102,
> and playing with the matrix values but don't have much luck. Also, I
> couldn't understand how the matrix values work. Any suggestions?

The iio-old use the property to set the rotation matrix:
hal.sensors.iio.accel.matrix

For example, if you want to exchange x and y axes, set
hal.sensors.iio.accel.matrix=0,1,0,1,0,0,0,0,1

[Daniel Cheung]

After some trial and error, I got the matrix to work with 0,-1,0,-1,0,0,0,1. No idea why but it worked. I read the original code comment that I found online and it doesn't even explain how it works. What is the difference between iio and iio-old?

[Chih-Wei Huang]

2018-08-30 3:54 GMT+08:00 Daniel Cheung <dwt.c...@gmail.com>:
> After some trial and error, I got the matrix to work with 0,-1,0,-1,0,0,0,1.
> No idea why but it worked. I read the original code comment that I found

Just a rotation matrix.
Your matrix means to exchange x and y axes
and reverse both values.

> online and it doesn't even explain how it works. What is the difference
> between iio and iio-old?

Current iio hal was developed by Intel.
It works well on most iio type sensors I've tested.

iio-old (former iio hal) is written by me.
It's just a simple hacking since I'm not really
familiar with iio protocol.
It works on some devices but not all.
I'm surprised but glad to know it works for you.

Please provide your device info by the commands:
(by root)

cat /sys/class/dmi/id/product_name
cat /sys/class/dmi/id/board_name
cat /sys/class/dmi/id/uevent

I'll add it in the later release.

[Daniel Cheung]

Don't think the following will help:

To be filled by O.E.M.
Cherry Trail CR
MODALIAS=dmi:bvnAmericanMegatrendsInc.:bvr5.011:bd11/03/2015:svnTobefilledbyO.E.M.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnAMICorporation:rnCherryTrailCR:rvrTobefilledbyO.E.M.:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:

[Chih-Wei Huang]

2018-09-01 10:02 GMT+08:00 Daniel Cheung <dwt.c...@gmail.com>:
> Don't think the following will help:
>
> To be filled by O.E.M.
> Cherry Trail CR
> MODALIAS=dmi:bvnAmericanMegatrendsInc.:bvr5.011:bd11/03/2015:svnTobefilledbyO.E.M.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnAMICorporation:rnCherryTrailCR:rvrTobefilledbyO.E.M.:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:

Alas! It seems the vendor didn't fill any useful info
for this device.

[Daniel Cheung]

From what I found online, without the correct information from the BIOS, the OS can't load the iio driver? That explains why your iio-old driver worked while the Intel ones don't. Does this also impact that natural orientation of the screen? When my device boots, the manufacturer's logo can some of the loading info does display correctly (self facing camera at top). Half way into loading Android, the screen would flip.

[Daniel Cheung]

Someone else have the similar issue in Unix and here's how they fixed it. Not sure if this approach is workable for Android X86.

https://unix.stackexchange.com/questions/410826/change-iio-sensors-data-via-custom-accel-mount-matrix

[Chih-Wei Huang]

2018-09-07 11:10 GMT+08:00 Daniel Cheung <dwt.c...@gmail.com>:
> Someone else have the similar issue in Unix and here's how they fixed it.
> Not sure if this approach is workable for Android X86.
>
> https://unix.stackexchange.com/questions/410826/change-iio-sensors-data-via-custom-accel-mount-matrix

In Intel's iio HAL, you can exchange x and y axes by
the property: ro.iio.accel.order=102

[Daniel Cheung]

That doesn't work because I can't use iio as the tablet manufacturer didn't fill in the information. Tried it with iio-old just to see what happens and there's no effect on the natural orientation. At this point, it's a minor annoyance unless there's a way to change the information, which is why I posted that link in my previous post. Personally, waiting for the volunteers to improve the hardware codec is much more important.

[Chih-Wei Huang]

2018-09-07 12:22 GMT+08:00 Daniel Cheung <dwt.c...@gmail.com>:
> That doesn't work because I can't use iio as the tablet manufacturer didn't
> fill in the information. Tried it with iio-old just to see what happens and

That's manufacturer info nothing to do with the iio HAL.
I asked the info is just because I hope to add specified
properties for this device.

From what you have posted, I think what you need to do
to make iio HAL to work is just exchange x and y axes
by the property. Have you really tried?

> there's no effect on the natural orientation. At this point, it's a minor
> annoyance unless there's a way to change the information, which is why I
> posted that link in my previous post. Personally, waiting for the volunteers
> to improve the hardware codec is much more important.

[Daniel Cheung]

Thank you for clearing up my questions regarding the manufacturer info. If I understand your instructions correctly, I should change the following in init.sh:

has_sensors=true

hal_sensors=iio

set_property ro.iio.accel.order 102

If so, then yes, I have try the above settings in init.sh, rebooted the tablet and confirmed rotation doesn't work. This setting is very similar to what I originally tried in Aug 19. I have attached the log file from my test with the above settings. Same error messages logged as my post on Aug 19. I searched on the net and it seems there's a problem with the iio sensor proxy in the Linux kernel. Not sure if it's applicable to Android X86 but if it does apply then I have to wait for the newer kernel.

https://github.com/hadess/iio-sensor-proxy/issues/85