minibook-dual-accelerometer icon indicating copy to clipboard operation
minibook-dual-accelerometer copied to clipboard
Published 1 year ago • verified publisher icon rhalkyard

No device /dev/iio:device1 (Manjaro 25.0.0, kernel 6.13.1-2-MANJARO)

Open plazotronik opened this issue 1 year ago • 16 comments

Manjaro 25.0.0, kernel 6.13.1-2-MANJARO, KDE (Plasma 6.2.5), Wayland Minibook X n100, S/N ZMinBXHY4H240700***

when I install 'make install', it swears at the lack of a device /dev/iio:device1

> make install

. . .

Running depmod..... done.  
rmmod intel-hid  
modprobe intel-hid  
udevadm trigger -w /dev/iio:device0  
udevadm trigger -w /dev/iio:device1  
Failed to open the device '/dev/iio:device1': No such device  
make[1]: *** [Makefile:20: install] Ошибка 1  
make[1]: выход из каталога «/root/minibook-dual-accelerometer/hack-driver»  
make: *** [Makefile:9: install] Ошибка 2

next, I roll back make uninstall. I can't figure out why this device isn't there.

> ll /dev/iio*                                
crw------- 1 root root 240, 0 мар  2 15:12 /dev/iio:device0

I tried deleting line 20 in the hack-driver/Makefile (device1). the build was successful, but it didn't do any good. the angle-sensor.service daemon crashed with an error:

> journalctl -xe -u angle-sensor.service
systemd[1]: Started Chuwi MiniBook rotation daemon.
angle-sensor[10122]: Traceback (most recent call last):
angle-sensor[10122]:   File "/usr/local/sbin/angle-sensor", line 381, in <module>
angle-sensor[10122]:     main()
angle-sensor[10122]:     ~~~~^^
angle-sensor[10122]:   File "/usr/local/sbin/angle-sensor", line 350, in main
angle-sensor[10122]:     display_accel = Accel.get(pyudev_ctx, 'display', args.display_accel,
angle-sensor[10122]:                               args.display_transform)
angle-sensor[10122]:   File "/usr/local/sbin/angle-sensor", line 81, in get
angle-sensor[10122]:     raise Exception(f'Could not find any accelerometers in udev '
angle-sensor[10122]:                     f'with ACCEL_LOCATION={location}.')
angle-sensor[10122]: Exception: Could not find any accelerometers in udev with ACCEL_LOCATION=display.
systemd[1]: angle-sensor.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: angle-sensor.service: Failed with result 'exit-code'.

And accordingly, nothing works. I additionally installed the iio-sensor-proxy and libiio packages and tried everything again, but the result did not change.

So that I can try again?

> ls /sys/bus/acpi/devices/MDA6655\:00/  
  
adr  hid  modalias  path  physical_node  physical_node1  power  status  subsystem  uevent  uid  wakeup

> udevadm info /sys/bus/iio/devices/*  
  
P: /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-13/i2c-MDA6655:00/iio:device0  
M: iio:device0  
R: 0  
J: c240:0  
U: iio  
T: iio_device  
D: c 240:0  
N: iio:device0  
L: 0  
E: DEVPATH=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-13/i2c-MDA6655:00/iio:device0  
E: SUBSYSTEM=iio  
E: DEVNAME=/dev/iio:device0  
E: DEVTYPE=iio_device  
E: MAJOR=240  
E: MINOR=0  
E: USEC_INITIALIZED=3904649090  
E: IIO_SENSOR_PROXY_TYPE=iio-poll-accel iio-buffer-accel  
E: SYSTEMD_WANTS=iio-sensor-proxy.service  
E: TAGS=:systemd:  
E: CURRENT_TAGS=:systemd:

Note. Dependency recommendations. In Manjaro, I installed:

  • dkms
  • python-numpy
  • python-pyudev
  • linux613-headers (kernel headers for dkms) - this can be additionally specified in the dependencies

Postinstall: In Manjaro new daemons not in autostart.

> systemctl status angle-sensor.service    
○ angle-sensor.service - Chuwi MiniBook rotation daemon  
    Loaded: loaded (/etc/systemd/system/angle-sensor.service; static)  
    Active: inactive (dead)

Need enable this in installation method:

systemctl enable --now angle-sensor.service

plazotronik avatar Mar 02 '25 12:03 plazotronik

I tried other kernels.

  • 6.12.12-2 - the same thing, there is no device /dev/io:device1
  • 6.6.75-2 - There are no /de/iio* devices at all

plazotronik avatar Mar 02 '25 13:03 plazotronik

Output command iio_info:

> iio_info  

. . . 

        iio:device0: mxc4005 (buffer capable)
                4 channels found:
                        accel_x:  (input, index: 0, format: be:s12/16>>4)
                        4 channel-specific attributes found:
                                attr  0: mount_matrix value: 1, 0, 0; 0, 1, 0; 0, 0, 1
                                attr  1: raw value: -940
                                attr  2: scale value: 0.009582
                                attr  3: scale_available value: 0.009582 0.019164 0.038329
                        accel_y:  (input, index: 1, format: be:s12/16>>4)
                        4 channel-specific attributes found:
                                attr  0: mount_matrix value: 1, 0, 0; 0, 1, 0; 0, 0, 1
                                attr  1: raw value: -21
                                attr  2: scale value: 0.009582
                                attr  3: scale_available value: 0.009582 0.019164 0.038329
                        accel_z:  (input, index: 2, format: be:s12/16>>4)
                        4 channel-specific attributes found:
                                attr  0: mount_matrix value: 1, 0, 0; 0, 1, 0; 0, 0, 1
                                attr  1: raw value: 155
                                attr  2: scale value: 0.009582
                                attr  3: scale_available value: 0.009582 0.019164 0.038329
                        timestamp:  (input, index: 3, format: le:S64/64>>0)
                2 device-specific attributes found:
                                attr  0: current_timestamp_clock value: realtime
                                attr  1: waiting_for_supplier value: 0
                2 buffer-specific attributes found:
                                attr  0: data_available value: 0
                                attr  1: direction value: in
ERROR: checking for trigger : Input/output error (5)

There is only one device device0 and mxc4005 is written opposite.

I ran the command:

> watch -n 0.1 "iio_info | grep -A 30 'iio:device0: mxc4005 (buffer capable)'"

and the xyz 'raw value' indicators were constantly changing when I folded and unfolded the lid, as well as when I rotated it around three axes in tablet mode.

plazotronik avatar Mar 02 '25 13:03 plazotronik

Thank you very much for the detailed information!

It looks like your accelerometer device is showing up on a different devpath to mine (I see devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-MDA6655:00/iio:device0 for the accelerometer detected by the system, and /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/0-0015/iio:device1 for the second accelerometer that my 'hack' forces detection of.

Would you mind dumping the DSDT of your machine? I think the different device path indicates that your machine's accelerometer is on a different I2C bus to mine (13 instead of 1)! Supporting it should just be a matter of adding an appropriate udev rule, but having the DSDT info will let me make sure I get it right.

To dump the DSDT, you will need the acpidump, acpixtract and iasl programs, on OpenSUSE, these come from the acpica package, I think this should be the same on most distros:

# Dump the ACPI tables (must run as root)
acpidump > acpi.dump

# Extract individual tables from the ACPI dump
acpixtract -a acpi.dump

# Decompile DSDT table to text format
iasl dsdt.dat

This will produce a huge text file called dsdt.dsl. You can just attach the whole thing here if you want, but the relevant part will be the entry starting with Device (ACMK). Mine looks like:

       Device (ACMK)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Name (_HID, "MDA6655")  // _HID: Hardware ID
            Name (_CID, "MDA6655")  // _CID: Compatible ID
            Name (_DDN, "Accelerometer with Angle Calculation")  // _DDN: DOS Device Name
            Name (_UID, One)  // _UID: Unique ID
            Name (_DEP, Package (0x02)  // _DEP: Dependencies
            {
                ^PC00.I2C0,
                ^PC00.I2C1
            })
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                Name (RBUF, ResourceTemplate ()
                {
                    I2cSerialBusV2 (0x0015, ControllerInitiated, 0x00061A80,
                        AddressingMode7Bit, "\\_SB.PC00.I2C1",
                        0x00, ResourceConsumer, , Exclusive,
                        )
                    I2cSerialBusV2 (0x0015, ControllerInitiated, 0x00061A80,
                        AddressingMode7Bit, "\\_SB.PC00.I2C0",
                        0x00, ResourceConsumer, , Exclusive,
                        )
                })
                Return (RBUF) /* \_SB_.ACMK._CRS.RBUF */
            }
[...]

Note the _CRS method that defines two I2cSerialBusV2 resources, one on \\_SB.PC00.I2C1, and one on \\_SB.PC00.I2C0. Does yours show the same resources here?

rhalkyard avatar Mar 04 '25 04:03 rhalkyard

I guess this is the part of the file.

       Device (ACMK)  
       {  
           Name (_ADR, Zero)  // _ADR: Address  
           Name (_HID, "MDA6655")  // _HID: Hardware ID  
           Name (_CID, "MDA6655")  // _CID: Compatible ID  
           Name (_DDN, "Accelerometer with Angle Calculation")  // _DDN: DOS Device Name  
           Name (_UID, One)  // _UID: Unique ID  
           Name (_DEP, Package (0x02)  // _DEP: Dependencies  
           {  
               ^PC00.I2C0,    
               ^PC00.I2C1  
           })  
           Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings  
           {  
               Name (RBUF, ResourceTemplate ()  
               {  
                   I2cSerialBusV2 (0x0015, ControllerInitiated, 0x00061A80,  
                       AddressingMode7Bit, "\\_SB.PC00.I2C1",  
                       0x00, ResourceConsumer, , Exclusive,  
                       )  
                   I2cSerialBusV2 (0x0015, ControllerInitiated, 0x00061A80,  
                       AddressingMode7Bit, "\\_SB.PC00.I2C0",  
                       0x00, ResourceConsumer, , Exclusive,  
                       )  
               })  
               Return (RBUF) /* \_SB_.ACMK._CRS.RBUF */  
           }

I'm attaching the file too. I'll be glad to help with something.

dsdt.dsl.txt

plazotronik avatar Mar 04 '25 14:03 plazotronik

I was displaying a list of all iio:device* files with the command

> ls -lahnd /sys/devices/pci0000:00/0000:00:*/*/*/*/*/*/iio:device*

and I found 104 directories. all device0, none device1

ls_pci.txt

plazotronik avatar Mar 04 '25 15:03 plazotronik

Same issue for me

Attached extract from dsdt.dsl

Device (ACMK)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Name (_HID, "MDA6655")  // _HID: Hardware ID
            Name (_CID, "MDA6655")  // _CID: Compatible ID
            Name (_DDN, "Accelerometer with Angle Calculation")  // _DDN: DOS Device Name
            Name (_UID, One)  // _UID: Unique ID
            Name (_DEP, Package (0x02)  // _DEP: Dependencies
            {
                ^PC00.I2C0,
                ^PC00.I2C1
            })
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            {
                Name (RBUF, ResourceTemplate ()
                {
                    I2cSerialBusV2 (0x0015, ControllerInitiated, 0x00061A80,
                        AddressingMode7Bit, "\\_SB.PC00.I2C1",
                        0x00, ResourceConsumer, , Exclusive,
                        )
                    I2cSerialBusV2 (0x0015, ControllerInitiated, 0x00061A80,
                        AddressingMode7Bit, "\\_SB.PC00.I2C0",
                        0x00, ResourceConsumer, , Exclusive,
                        )
                })
                Return (RBUF) /* \_SB_.ACMK._CRS.RBUF */
            }

dufferzz avatar Mar 09 '25 13:03 dufferzz

@rhalkyard Hey bro, is there anything we can do to help you solve this problem?

plazotronik avatar Mar 30 '25 07:03 plazotronik

I think the different device path indicates that your machine's accelerometer is on a different I2C bus to mine (13 instead of 1)! Supporting it should just be a matter of adding an appropriate udev rule, but having the DSDT info will let me make sure I get it right.

Hi,

in my case, I have another i2c bus on the new minibook x (2025) N150...

# identify sensors paths
grep --color -e Synopsys -e MDA6655 \
  /sys/devices/pci0000:00/0000:00:15.*/i2c_designware.0/i2c-*/name \
  /sys/devices/pci0000:00/0000:00:15.*/i2c_designware.1/i2c-*/i2c-MDA6655:00/name

/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-11/name:Synopsys DesignWare I2C adapter
/sys/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-12/i2c-MDA6655:00/name:MDA6655:00

So I saw that my sensor was using bus 11 and 12.

I changed the udev rules such as:

  1. first sensor device0 use bus i2c-12 for its path and enable new device on bus i2c-11
  2. then second sensor device1 use bus i2c-11/11-0015 
# The dual accelerometers on the MiniBook X have the same modalias, so hwdb
# can't tell them apart. Differentiate them using the devpath and set
# ACCEL_LOCATION as appropriate.

SUBSYSTEM=="iio", KERNEL=="iio*", SUBSYSTEMS=="i2c", \
        DEVPATH=="*/i2c-12/i2c-MDA6655:00/iio:device0", \
        ENV{ACCEL_LOCATION}="display", \
        ENV{ACCEL_MOUNT_MATRIX}="0,-1,0;1,0,0;0,0,1", \
        RUN+="/bin/sh -c 'echo mxc4005 0x15 > /sys/bus/i2c/devices/i2c-11/new_device'", \
        ENV{SYSTEMD_WANTS}="angle-sensor.service"

SUBSYSTEM=="iio", KERNEL=="iio*", SUBSYSTEMS=="i2c", \
        DEVPATH=="*/i2c-11/11-0015/iio:device1", \
        ENV{ACCEL_LOCATION}="base", \
        ENV{ACCEL_MOUNT_MATRIX}="0,-1,0;1,0,0;0,0,1", \
        RUN{builtin}+="kmod load chuwi-ltsm-hack", \
        ENV{SYSTEMD_WANTS}="angle-sensor.service"

And thanks all of you, it works ! And thanks a lot @rhalkyard !!!

sudo journalctl -f -t angle-sensor

avril 30 23:41:19 minibookx angle-sensor[711]: INFO:angle-sensor:                 [ 0  0  1]]
avril 30 23:41:19 minibookx angle-sensor[711]: INFO:angle-sensor:Using /sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-11/11-0015/iio:device1 for accelerometer location 'base'.
avril 30 23:41:19 minibookx angle-sensor[711]: INFO:angle-sensor:Found ACCEL_MOUNT_MATRIX property for /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-11/11-0015/iio:device1.
avril 30 23:41:19 minibookx angle-sensor[711]: INFO:angle-sensor:Accelerometer /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-11/11-0015/iio:device1 using transformation matrix:
avril 30 23:41:19 minibookx angle-sensor[711]: INFO:angle-sensor:                [[ 0 -1  0]
avril 30 23:41:19 minibookx angle-sensor[711]: INFO:angle-sensor:                 [ 1  0  0]
avril 30 23:41:19 minibookx angle-sensor[711]: INFO:angle-sensor:                 [ 0  0  1]]
avril 30 23:41:19 minibookx angle-sensor[711]: INFO:angle-sensor:State changed: UNKNOWN->LAPTOP
avril 30 23:44:27 minibookx angle-sensor[711]: INFO:angle-sensor:State changed: LAPTOP->TABLET
avril 30 23:45:12 minibookx angle-sensor[711]: INFO:angle-sensor:State changed: TABLET->LAPTOP

Manajaro 2025 linux612, mini howto:

# clone repo
git clone https://github.com/rhalkyard/minibook-dual-accelerometer.git
# install dependency for Manjaro
pamac install --no-confirm dkms python-numpy python-pyudev $(sed -n 's,.*(\(linux[0-9]*\)).*,\1,p' <<<"$(mhwd-kernel -li)")-headers
# go in repo, modify udev rules if needed
cd ~/minibook-dual-accelerometer &&vim hack-driver/60-sensor-chuwi.rules
# make install
sudo make install
# reboot and enjoy

typhoe avatar Apr 30 '25 22:04 typhoe

So I saw that my sensor was using bus 11 and 12.

this is a really cool option and it works. It's only a partial pity...

when I ran the "grep" command, I also got bus 11 and 12. the hack was set up and started working. BUT...

with each iteration of the reboot, my bus numbers change. sometimes it's 11 and 12, then 11 and 13, then 12 and 13. the pairs of numbers alternate randomly. therefore, this code will only work if there is a match, which was specified in "60-sensor-chuwi.rules". and this is not even every second reboot.

plazotronik avatar May 03 '25 15:05 plazotronik

Yeah, indeed I have the same problem it seems :'(

# 2025/05/03 19:43 - boot n° 1
/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-12/name:Synopsys DesignWare I2C adapter
/sys/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-13/i2c-MDA6655:00/name:MDA6655:00
# 2025/05/03 19:45 - boot n° 2
/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-11/name:Synopsys DesignWare I2C adapter
/sys/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-13/i2c-MDA6655:00/name:MDA6655:00
# 2025/05/03 19:46 - boot n° 3
/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-11/name:Synopsys DesignWare I2C adapter
/sys/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-13/i2c-MDA6655:00/name:MDA6655:00
# 2025/05/03 19:47 - boot n° 4
/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-11/name:Synopsys DesignWare I2C adapter
/sys/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-12/i2c-MDA6655:00/name:MDA6655:00
# 2025/05/03 19:48 - boot n° 5
/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-11/name:Synopsys DesignWare I2C adapter
/sys/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-12/i2c-MDA6655:00/name:MDA6655:00
# 2025/05/03 19:49 - boot n° 6
/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-12/name:Synopsys DesignWare I2C adapter
/sys/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-13/i2c-MDA6655:00/name:MDA6655:00
# 2025/05/03 19:50 - boot n° 7
/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-11/name:Synopsys DesignWare I2C adapter
/sys/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-13/i2c-MDA6655:00/name:MDA6655:00
# 2025/05/03 19:51 - boot n° 8
/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-11/name:Synopsys DesignWare I2C adapter
/sys/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-13/i2c-MDA6655:00/name:MDA6655:00
# 2025/05/03 19:51 - boot n° 9
/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-11/name:Synopsys DesignWare I2C adapter
/sys/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-12/i2c-MDA6655:00/name:MDA6655:00
# 2025/05/03 19:52 - boot n° 10
/sys/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-11/name:Synopsys DesignWare I2C adapter
/sys/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-12/i2c-MDA6655:00/name:MDA6655:00

So I tried more joker and it does the trick ! (the new device detection seems to always stay on bus 11 for me)

# The dual accelerometers on the MiniBook X have the same modalias, so hwdb
# can't tell them apart. Differentiate them using the devpath and set
# ACCEL_LOCATION as appropriate.

SUBSYSTEM=="iio", KERNEL=="iio*", SUBSYSTEMS=="i2c", \
        DEVPATH=="*/i2c-1*/i2c-MDA6655:00/iio:device0", \
        ENV{ACCEL_LOCATION}="display", \
        ENV{ACCEL_MOUNT_MATRIX}="0,-1,0;1,0,0;0,0,1", \
        RUN+="/bin/sh -c 'echo mxc4005 0x15 > /sys/bus/i2c/devices/i2c-11/new_device'", \
        ENV{SYSTEMD_WANTS}="angle-sensor.service"

SUBSYSTEM=="iio", KERNEL=="iio*", SUBSYSTEMS=="i2c", \
        DEVPATH=="*/i2c-1*/1*-0015/iio:device1", \
        ENV{ACCEL_LOCATION}="base", \
        ENV{ACCEL_MOUNT_MATRIX}="0,-1,0;1,0,0;0,0,1", \
        RUN{builtin}+="kmod load chuwi-ltsm-hack", \
        ENV{SYSTEMD_WANTS}="angle-sensor.service"

typhoe avatar May 03 '25 18:05 typhoe

Hi,

I had one more problem being that the bus of the device to use to activate the device1 is not always the same... In my case (Minibookx 2025 N150), it jumps from buss 11 to bus 12... so sometimes, the initialization was not working.

So I did an other tweak to the file to detect what bus to use for the activation of device1, and so far, on each boot of my minibookx, it now works as expected.

@rhalkyard could you check if it also works for you, and if it's the case, update to make your kernel module more generic ?

# The dual accelerometers on the MiniBook X have the same modalias, so hwdb
# can't tell them apart. Differentiate them using the devpath and set
# ACCEL_LOCATION as appropriate.

SUBSYSTEM=="iio", KERNEL=="iio*", SUBSYSTEMS=="i2c", \
        DEVPATH=="*/i2c-*/i2c-MDA6655:00/iio:device0", \
        ENV{ACCEL_LOCATION}="display", \
        ENV{ACCEL_MOUNT_MATRIX}="0,-1,0;1,0,0;0,0,1", \
        RUN+="/bin/sh -c 'echo mxc4005 0x15 > $(dirname $(grep Synopsys /sys/bus/i2c/devices/i2c-*/name 2>/dev/null |head -n1) |head -n1)/new_device'", \
        ENV{SYSTEMD_WANTS}="angle-sensor.service"

SUBSYSTEM=="iio", KERNEL=="iio*", SUBSYSTEMS=="i2c", \
        DEVPATH=="*/i2c-*/*-0015/iio:device1", \
        ENV{ACCEL_LOCATION}="base", \
        ENV{ACCEL_MOUNT_MATRIX}="0,-1,0;1,0,0;0,0,1", \
        RUN{builtin}+="kmod load chuwi-ltsm-hack", \
        ENV{SYSTEMD_WANTS}="angle-sensor.service"

What I do to get the right bus:

  1. check all I2C bus where name contains Synopsys using grep
  2. keep only the first one using head -n1
  3. remove the name part of the path with dirname
  4. I had a few lines with only a dot . (don't really understand why), so I used another head -n1 to remove them

typhoe avatar May 11 '25 13:05 typhoe

So I did an other tweak to the file to detect what bus to use for the activation of device1, and so far, on each boot of my minibookx, it now works as expected.

Hi Typhoe and plazotronik,

I am also running on Manjaro 25 with Gnome and the latest script provided by Typhoe. Both devices are active in the system (checked).

So when I fold into tablet mode, the script seems to work initially. But the orientation of the screen gets distorted after it ran ( the screen is turning into the wrong direction) -which I fixed at boot with video right_side_up in grub. Also turning back into laptop mode, it does not get fixed... Also, Once I fold back into laptop, the script recognizes correctly that I am in laptop mode, however, it will never let me go back to tablet mode even when completely fold it again...

What could cause this? Any thoughts on how to trouble-shoot?

talan-z avatar Jun 09 '25 10:06 talan-z

Hi @talan-z ,

I sometime have this behavior after exiting from sleep but it's quite rare.

Are you using a Minibook X with N150 too ? The latest 2025 model ?

Maybe we have a different hardware model ?

Here's mine info:

for Id in bios-vendor bios-version bios-release-date bios-revision firmware-revision system-manufacturer system-product-name system-version system-serial-number system-uuid system-sku-number system-family baseboard-manufacturer baseboard-product-name baseboard-version baseboard-serial-number baseboard-asset-tag chassis-manufacturer chassis-type chassis-version chassis-serial-number chassis-asset-tag processor-family processor-manufacturer processor-version processor-frequency ;do
  Result="$(sudo dmidecode -s "$Id")"
  case "$Result" in
    "Default string" |\
    "Other" ) continue;;
    * ) echo -e "$(printf '%-25s' "$Id") $Result";;
  esac
done

bios-vendor American Megatrends International, LLC.
bios-version DNN20 V2.50
bios-release-date 11/21/2024
bios-revision 2.50
firmware-revision 0.18
system-manufacturer CHUWI Innovation And Technology(ShenZhen)co.,Ltd
system-product-name MiniBook X
system-version V1.0
system-serial-number ZMin--REDACTED
system-uuid REDACTED
baseboard-serial-number DNN20--REDACTED
chassis-type Notebook
processor-manufacturer Intel(R) Corporation
processor-version Intel(R) N150
processor-frequency 2871 MHz

When I first tried to get the orientation working, I remember I tried another matrix for the ACCEL_MOUNT_MATRIX variable, maybe check if your model uses another one ?

typhoe avatar Jun 09 '25 21:06 typhoe

HI @typhoe

https://github.com/rhalkyard/minibook-dual-accelerometer/issues/3#issuecomment-2869854538 I applied this fix and every time I reboot the devices work despite their id. super

but I also have problems with the orientation of the screen in tablet mode (there are no problems in laptop mode). each time I have a 90 degree deviation to the left (counterclockwise).

however, I believe that the reason is the base position from which the accelerometers are repelled. since my device is oriented 90 degrees to the left (counterclockwise) at the first start after shutdown, as well as at the time of shutdown (or reboot). and this is all the time in laptop mode (I didn't check on/off in other modes, because for me these are not relevant user cases). after logging into the session, the orientation switches correctly in laptop mode. when I put the mini-book into hibernation mode and bring it out of this mode, I have no problems with orientation in laptop mode. but all the problems with the tablet mode remain.

Image

Video with orientation problems: https://youtu.be/9VX_FUbpcfI?si=fr103ktHS4wSrWjt My parameters are currently:

bios-vendor               American Megatrends International, LLC.
bios-version              DNN20 V2.22
bios-release-date         06/12/2024
bios-revision             2.22
firmware-revision         0.18
system-manufacturer       CHUWI Innovation And Technology(ShenZhen)co.,Ltd
system-product-name       MiniBook X
system-serial-number      ZMinBXHY4H240700...
system-uuid               b1f700..-.....-.....-.....-.....503800
baseboard-serial-number   DNN2005......2681
chassis-type              Notebook
processor-manufacturer    Intel(R) Corporation
processor-version         Intel(R) N100
processor-frequency       2871 MHz

Kernel: 6.14.6-2-MANJARO
OS: Manjaro Linux 25.0.3
DE: KDE (Plasma 6.3.5), Wayland
Minibook X n100 2024

p.s. This version of the implementation also had exactly the same orientation issues - https://github.com/rhalkyard/minibook-dual-accelerometer/issues/3#issuecomment-2843471704

plazotronik avatar Jun 10 '25 13:06 plazotronik

@typhoe I was thinking about your question about ACCEL_MOUNT_MATRIX.

the ".rules" files use the value of ENV{ACCEL_MOUNT_MATRIX}="0,-1,0;1,0,0;0,0,1", but when I entered the cat /sys/devices/pci command.:00/*/*/*/*/*/ in_accel_mount_matrix I got 7 files with the same value - "1,0,0;0,1,0;0,0,1"

this gave me the idea to try changing the values. I did the following:

  1. make uninstall
  2. changed the values in both ".rules" files to "1,0,0;0,1,0;0,0,1" and made a make install
  3. Rebooted
  4. and nothing happened after the download. tablet mode did not turn on at all.
  5. I did NOT reboot and did make uninstall
  6. Returned the values to the old ones in both files. made a make install with the old parameters "0,-1,0;1,0,0;0,0,1"
  7. Voila! My tablet mode is working fine!!! the orientation is correct!
  8. Rebooted
  9. The orientation has stopped working correctly again - the offset is 90 degrees as before.
  10. I changed the parameters to "1,0,0;0,1,0;0,0,1" and applied them, but only in one file - hack-driver/60-sensor-chuwi.rules
  11. Rebooted - the correct orientation started working. BUT...

but in the end, my tablet mode does not activate immediately after folding the lid in the opposite direction, but only after I smooth the lid in the opposite direction And turn the device over at least to one side. and only in the inverted position do my icons change size as in the real tablet mode. and now, if you just turn the device on its side in normal laptop mode, the screen also turns over. it turns out that we need to somehow find a middle ground so that the device starts behaving correctly and expectedly in all positions.

plazotronik avatar Jun 10 '25 18:06 plazotronik

Hi all,

I managed to make it work. I have the N100 edition with the following details:

bios-vendor American Megatrends International, LLC. bios-version DNN20 V2.09 bios-release-date 07/19/2023 bios-revision 2.9 firmware-revision 0.13 system-manufacturer CHUWI Innovation And Technology(ShenZhen)co.,Ltd system-product-name MiniBook X system-serial-number ZMinBXHY3Hxxxxxxxxx system-uuid f5e96800-3e34-11ee-xxxxxxxxxxxxx baseboard-serial-number DNN20042xxxxxxxxx chassis-type Notebook processor-manufacturer Intel(R) Corporation processor-version Intel(R) N100 processor-frequency 2871 MHz

This is how it works:

  • Fix screen orientation with grub config (panel_orientation).
  • Implement above steps
  • Change parameters to "1,0,0;0,1,0;0,0,1"

talan-z avatar Jun 15 '25 12:06 talan-z