Support presence of more than just one accelerometer

[fkroener]

My convertible (MEDION E2228T) has two accelerometer sensors built-in.

One in the display the other in the keyboard section. They have a KIOX000A-chip and turn up with two IDs: KIOX010A and KIOX020A. Having both of them enabled in the kernel results in iio-sensor-proxy only selecting the KIOX020A one, which is unfortunately the keyboard part.

I'm not sure whether this sort of implementation is going to become more frequent. But'd be nice if iio-sensor-proxy would learn new events to turn off the keyboard (especially when turning the convertible in a way the keyboard part faces downwards, while the display doesn't rotate) - so far I just disable the keyboard / touchpad whenever the screen is rotated. But having that independent from eachother and dependent on positioning of both sensors to eachother would be nice.

Since my device lacks a LID switch this could be used as well to determine when to suspend.

[hadess]

I think the best for us would be to tag those devices with their location (in the screen or in the keyboard). This requires extending the udev sensor database.

Since my device lacks a LID switch this could be used as well to determine when to suspend.

It probably does, but you don't have a device driver for it in Linux. Run a tool like WinAudit under Windows to check what devices it actually has. Look for "Lid" or "ACPI Lid"

[fkroener]

OK, sounds great. Something similar to ID_INPUT_TOUCHPAD_INTEGRATION=internal I suppose.
Maybe ACCEL_LOCATION=keyboard|display where the default would be display.
How does one go about adding a new tag? Anything I could do?

See below as well some readings from my two sensors in different positions.

Normal mode: _
Keyboard X:6 Y:0 Z:-515 Display X:514 Y:13 Z:-42

Tent mode: /\ (keyboard and display facing outwards)
Keyboard X:9 Y:-454 Z:-224 Display X:-435 Y:13 Z:-245

Tablet mode: = (keyboard faces the table)
Keyboard X:8 Y:-2 Z:509 Display X:42 Y:30 Z:-492

Stand mode: _\ (keyboard faces the table, display the user)
Keyboard X:9 Y:3 Z:521 Display X:486 Y:9 Z:-135

Please advise me on anything you need.

Using the following ACCEL_MOUNT_MATRIX with the display sensor:
sensor:modalias:acpi:KIOX010A*:dmi:svnMEDION*:pnE2228T*
ACCEL_MOUNT_MATRIX=0, -1, 0; -1, 0, 0; 0, 0, 0

[hadess]

OK, sounds great. Something similar to ID_INPUT_TOUCHPAD_INTEGRATION=internal I suppose.
Maybe ACCEL_LOCATION=keyboard|display where the default would be display.
How does one go about adding a new tag? Anything I could do?

Would be something to discuss in a new systemd issue.

I'll leave this open for iio-sensor-proxy to consume that additional information.

[hadess]

Also see https://lkml.org/lkml/2017/9/15/188 for Thinkpads

[floe]

Since I also have the E2228T, two more comments: there's a standalone userspace implementation of the desired behavior at https://github.com/alesguzik/linux_detect_tablet_mode. And while the device does have an ACPI LID0 device, it looks a lot like this is a leftover from another laptop in the ACPI tables and there's absolutely no way to trigger any event. In particular, the screen stays on even if the device is closed all the way, so this is apparently handled entirely in software.

[fkroener]

Thank you for your pointers wrt. linux_detect_table_mode.
The LID actually does appear to work, my device suspends properly with kernel 4.15.18 and button.lid_init_state=open - only lid opening doesn't appear to be detected, but that's alright for me.
Somehow the lid broke with kernel 4.16 and I haven't been able to bisect due to FDE and lack of time.

[floe]

Thanks for the hint - however, on the stock Ubuntu 18.04 kernel (i.e. 4.15.0-36 right now) the addition of ´button.lid_init_state=open´ doesn't seem to have any effect. When I close the lid, the backlight stays on and the laptop keeps running. Did you change any other kernel config parameters?

[Tuxman2]

@fkroener and @floe: As you have the MEDION E2228T, can you tell me if it well supported on Linux (sound, touchscreen, ...) ? Do you encounter other problems than the accelerometer ?

Thanks.

[fkroener]

@floe: nothing special about the kernel config, I just manually patched in sound, since that wasn't supported until 4.16 (and I couldn't get it to work with 4.16 back when I tried it). I stayed with 4.15.18 because of the lid working - no idea what that broke as stated above. If you care I can give you my config and patches.

@Tuxman2 to me everything appears to work just fine, sound has some issues but I guess that's due to me staying with the pre-4.16 stuff (like sometimes plug-detection not working and I'm not entirely sure if I got the mic working).

Touchscreen worked OOTB. Fingerprint should be working but fprint-enroll with current libfingerprintd states no device were detected. And the touchpad doesn't get recognized as touchpad as of yet, but I suspect that http://lkml.iu.edu/hypermail/linux/kernel/1801.1/05964.html could maybe be made to recognize it. In mouse emulation mode it still works quite okeish, but unfortunately 'three-finger-tap' sends a strange keycode and can't be used for MWHEEL_CLICK, which is annoying.

All in all it works quite well for me. I should have a look again and bisect which commit broke the LID_CLOSE event and maybe figure out the fingerprint device not being detected.

[Tuxman2]

@fkroener: Thanks for the information. ;-)

A member of my family could buy this hardware and use it under Linux. That's why I ask you informations about it. Have you got more informations about the hardware available in the E2228T model (sound chip (rt56xx ? es8316 ?), wifi card (realtek ?), Cherry trail ?, autonomy ?, ...) ?

Have you tried the 4.19.x stable kernel or the last 4.20-rc kernel ?

Thanks.

Note: I've got the Medion Akoya E2212T model.

[Tuxman2]

@fkroener and @floe: The 4.18.0-13 kernel is available for Ubuntu 18.04. Have you tried it with your hardware (of course if you use Ubuntu).

[hadess]

@fkroener and @floe: The 4.18.0-13 kernel is available for Ubuntu 18.04. Have you tried it with your hardware (of course if you use Ubuntu).

I'd be grateful if you could take this discussion elsewhere, it's not relevant to this issue.

[ljmf00]

Reference to kernel patch #1057409

[Tuxman2]

@ljmf00: This kernel patch is or will be available in the 5.0.x kernel ?

Thanks.