Linux users - new module & daemons for tablet mode & rotation

Laptops Minibook X N100/N150/5100
1

New CHUWI Minibook X Linux kernel module & daemons!

I’m proud to announce the first public release of the “cmx” module and related daemons I’ve put together for the CHUWI Minibook X.

What does it provide or do?

At a high level, it generates tablet mode events (automatically disabling keyboard and mouse “the linux kernel way”), and supports rotation and tablet mode detection. The system is event driven, and not polling, all the way from reading IIO device data in an evented way through the user session daemon responding to event broadcasts.

  • Kernel patches allow the second mxc4005 module for the accelerometer to load automatically and correctly.
  • The cmx module primarily exists to create an input device for SW_TABLET_MODE, and generates that input event when the laptop enters tablet mode. It also identifies the platform and creates sysfs files for the supporting daemon to read and write from.
  • cmxd is the system level daemon that does the math and calculates hinge angles and detects lid orientation, and writes those values to the sysfs files the cmx module manages. It also broadcasts these events on a UNIX Domain socket and (optionally) DBus.
  • cmxsd is the user session daemon which receives events from cmxd and responds accordingly through editable scripts.

CAVEAT 1

This release is likely targeted towards slightly more advanced users as it involves a new kernel module, kernel configuration, and kernel install. If you are comfortable with that – please give it a whirl!

If you are not, you should wait to use or test this. My plan is to submit a Linux kernel patch for the kernel related code, which would mean the kernel components of this release wouldn’t be needed anymore once your distribution updates the kernel.

CAVEAT 2

I am suspect of the DMI information (what a machine tells the OS about itself like Brand, Model, Serial Number, etc) being able to distinguish between different model revisions of the CHUWI Minibook X which may have a different assortment of accelerometers per model.

If you find that the module doesn’t load and bring up two mxc4005 accelerometers, I’d be curious to know the output of the following:

  • ls -1d /sys/bus/iio/devices/iio\:device*
  • cat /sys/bus/iio/devices/iio\:device*/name
  • dmidecode -t system

Why would this info be helpful?

  • Getting this to work with Minibook X revisions that have different DMI info and the same hardware should be very straightforward.
  • Stopping this from attempting to load on Minibook X systems that have the same DMI information but different hardware configurations should be straightforward.
  • Getting this to work with other dual accelerometer setups (ie other drivers beyond mxc4005) should be straightforward (assuming it has the same problems my revision had – if the system already loads two IIO devices, the daemons should be able to work as-is.)

Caveat 3

You will have to configure the user-support cmxsd scripts (tablet on, tablet off, rotate) to support your specific needs and environment. The example scripts work for me under Hyprland. If you want to use wvkbd as an on-screen keyboard, you’ll need the fixes from my fork to fix crashes from rotation triggering bad code in the program, available at: GitHub - greymouser/wvkbd: On-screen keyboard for wlroots

Caveat 4

The cmxd daemon should emit DBus notifications compatible with IIO Sensor Proxy. If you are using IIO Sensor Proxy, you’ll need to turn it off while testing. I’d be curious to know if those notifications from cmxd work for environments that already support IIO Sensor Proxy a bit (GNOME?).

Thanks!

Thanks to any and all that try this out!

2 Likes
2

Thanks for the efforts!

I’ll wait until available in a distribution.

But let me know if you want some output from my Minibook X N100.

Cheers, Jaap

1 Like
3

This looks pretty cool. I will give it a try and give you a feedback. It is always nice to see Linux developers actively working on the Minibook X. :+1:

1 Like
4

Thanks!

Yeah, those 3 commands under “caveat 2” would help a lot.

1 Like
5

Here you go for a non patched MiniBook X N100.

BIOS version: DNN20 V2.13 x64

jaap@MBX:~$ ls -1d /sys/bus/iio/devices/iio\:device*
/sys/bus/iio/devices/iio:device0
jaap@MBX:~$ cat /sys/bus/iio/devices/iio\:device*/name
mxc4005
jaap@MBX:~$ dmidecode -t system

dmidecode 3.6

/sys/firmware/dmi/tables/smbios_entry_point: Permission denied
Scanning /dev/mem for entry point.
Can’t read memory from /dev/mem
jaap@MBX:~$ sudo dmidecode -t system
[sudo: authenticate] Password:

dmidecode 3.6

Getting SMBIOS data from sysfs.
SMBIOS 3.5.0 present.

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: CHUWI Innovation And Technology(ShenZhen)co.,Ltd
Product Name: MiniBook X
Version: Default string
Serial Number: ZMinBXHY4H230901126
UUID: c561b700-65b7-11ee-8038-b78020d80700
Wake-up Type: Power Switch
SKU Number: Default string
Family: Default string

Anything else?

Cheers, Jaap

1 Like
6

Thanks! Ahh, good call on sudo – I’ll update the post to mention it.
*** EDIT: for the life of me, I cannot figure out how to edit a post. Maybe the edit ability disappears after some time, or after replies on the post happen? Anyways, to all readers: use sudo with that command in order to get permissions to read the system id info with dmidecode.
And yes, that is very helpful. The good news is that the module would definitely load as the DMI info matches (though the platform is slightly different than mine). And, it looks like you have the same issue my CMX did, so it’d likely solve that. If tablet mode works in Windows (if you ever tested – I never did), then you undoubtedly have a second mxc4005 sensor mounted in the base waiting to come up, but can’t under Linux atm (which my patches & module fixes).
Thanks again!

7

Hey! Thx for the amazing work. However beeing newbie to Linux its a little hard to patch the kernel. Can u help with that personally? A little. I didnt find your email to write to as you said somewhere here. Can you refer where I can find it?

8

One way to communicate in this forum is by selecting a portion of what another user writes, as shown above.

When you click on a username, you’ll see a menu:
Message
Chat

9

I see that the code is for Gentoo. I’m trying to modify it so I can apply it to Kubuntu. If I get anywhere, I’ll post it here.

@greymouser Are you planning to send the patch to the kernel?

10

The program code works for any system.

The kernel patches apply against mainline and should work for nearly all kernel source trees (since It’s most additive patches).

Yes, I plan on getting the changes into mainline kernel.

11

To ask directly, what part did you find is gentoo specific?

“cat /path/patch | patch -p1” in the kernel source tree should do it. (Add —dry-run to test.)

12

The path that appears in the patch points to Gentoo paths, so I thought it might be something specific to that distribution.

This is my first time applying a patch to the kernel. I am trying to download the Ubuntu kernel code using dev-src, but I cannot find the files that appear in the patch.

I have installed the code with

apt source linux-image-$(uname -r)

but in the path /usr/src/linux-headers-6.17.0-8-generic/drivers/acpi/ I cannot find any .c files, so I am stuck there.

13

I don’t know Ubuntu’s kernel compilation process, but I can tell you that /usr/src/linux-headers-* is likely just the header files, not the source.

1 Like
14

Thanks for making this, I tried it out, but it’s not working. No fault of the module as far as I can tell. Seems my issue may be firmware related. A grueling 2 hour compile job on the N100 with -j$(nproc) burning every core at near 100%.

Everything went well until step 3 where the kernel module build errored out due to a lack of signing_key.pem

SSL error:1E08010C:DECODER routines::unsupported: 
crypto/encode_decode/decoder_lib.c:104
sign-file: /usr/lib/modules/6.18.7-arch1-1-minibook-x/build/certs/signing_key.pem

I previously setup secure boot via the sbctl utility, so I only needed to link the sbctl PK.pem to resolve the make modules_install error.

$ sudo ln -s /var/lib/sbctl/keys/PK/PK.pem /usr/lib/modules/6.18.7-arch1-1-minibook-x/build/certs/signing_key.pem

After the daemon dbus rule was installed in /etc/dbus-1/system.d/cmxd-dbus.conf the dbus service was not restarted resulting in a dbus policy error.

ERROR: Failed to request DBus service name com.noonshy.cmxd: Request to own name refused by policy
ERROR: Failed to initialize DBus module
ERROR: Failed to initialize DBus
ERROR: Failed to initialize event system

sudo systemctl reload dbus resolved this issue.

As for the mxc4005 accelerometers, the lid (device0) was detected, and the base (device1) was not

INFO: Lid device from kernel: iio:device0
ERROR: Base IIO device not ready: iio:device1

I mean, the base device1 was detected per dmesg, or at least appeared to be detected

cmx: IIO device assignments: lid=iio:device0, base=iio:device1

…but not appearing in devices

$ ls /sys/bus/iio/devices/
iio:device0

Seems this might be a known issue around the firmware. I understand version 2.17 is the latest known version where as I am running 2.10. I’ve asked Chuwi support for a firmware upgrade (for an NVMe detection issue for Crucial P5 drives), but have not yet heard back (2 weeks ago as of this post)

$ sudo dmidecode | grep -Ei -A3 “^platform firmware|system information”
Platform Firmware Information
Vendor: American Megatrends International, LLC.
Version: DNN20 V2.10
Release Date: 07/24/2023

System Information
Manufacturer: CHUWI Innovation And Technology(ShenZhen)co.,Ltd
Product Name: MiniBook X

Personally, I’ve disabled the touch screen, and never considered to use it in tablet mode, but it looked like fun to try.

FWIW, I did setup autoload for the needed modules. Both devices did not appear whether the modules were loaded or not.

$ cat /etc/modules-load.d/minibook-x.conf
serial-multi-instantiate
mxc4005
cmx