What are the Linux system requirements for tablet mode?

Please let me know if you find a Solution as i also plan on using opensuse (kde tumbleweed)

1 Like

I just tested on KDE plasma, from Debian trixie, after applying the udev hack and it didn’t immediately solve the issue.

After rebooting, however, everything works flawlessly.

So is the consensus now that this is only a software problem? …or are there a small number of faulty sensors floating around too?

I’m waiting on a board RMA.

I think the conclusion is largely

  • Boot it up on a Fedora 42 v1.1 USB stick. Does the sensor work?
  • Yes → There were some comments about how to get it working in Arch
  • No → Potential hardware fault
2 Likes

While not yet a solution - it seems like OpenSUSE has been made aware of the bug. Turns out some kernel drivers are missing for Tumbleweed. Some required drivers need to get added in to get iio-sensor-proxy to function. Once those drivers get added, I’ll see if I can get Tablet Mode to work on OpenSUSE via a Live ISO.

Edit: it seems like the fix should be merged (Update config files: enable cros-ec IIO modules for x86 too (bsc#1246… Ā· openSUSE/kernel-source@e391104 Ā· GitHub), but yet has to appear in an ISO update. Keep an eye out for the automated releases list for the Tumbleweed ISOs and search (in the details of an updated ISO) for the bug(fix) with number 1246308. As far as I can see, it still hasn’t been merged as of this Saturday’s ISO.

In the meanwhile I did switch to Bazzite, to take advantage of tablet mode + any package I would want to run on it via Distrobox.

2 Likes

It has also stopped working for me on Fedora KDE

For information I’m on arch using KDE

If you write the Fedora KDE live ISO to a thumb drive, and then boot into the live environment from it, does it work ā€œout of the boxā€ without any fiddling whatsoever?

There should be a keyboard icon in the taskbar along with the rest. If there’s not a little green dot on it, tap it to enable the software keyboard (which should add the green dot on the icon). If not, check System Settings here. (Update: this might apply on Arch or Nix, perhaps among other distros.)

Guide for NixOS users

There are some configurations for the FW 12 in the nixos-hardware repo, which for example enable iio-sensor-proxy by default, but they don’t seem to include any of the workarounds necessary right now. You can also enable iio-sensor-proxy without including the full config simply by setting:

hardware.sensor.iio.enable = true;

On top of that I have had success with the following two extra entries in configuration.nix:

# Ensure that the `pinctrl_tigerlake` kernel module is loaded before `soc_button_array`.
# This is required for correcly switching to tablet mode when the display is folded back.
boot.extraModprobeConfig = ''
  softdep soc_button_array pre: pinctrl_tigerlake
'';
# Patch the `udev` rules shipping with `iio-sensor-proxy` according to:
# https://github.com/FrameworkComputer/linux-docs/blob/main/framework12/Ubuntu-25-04-accel-ubuntu25.04.md
nixpkgs.overlays = [
  (final: prev: {
    iio-sensor-proxy = prev.iio-sensor-proxy.overrideAttrs (old: {
      postInstall = ''
        ${old.postInstall or ""}
        sed -i 's/.*iio-buffer-accel/#&/' $out/lib/udev/rules.d/80-iio-sensor-proxy.rules
      '';
    });
  })
];

Extra observations

Before coming up with a declarative solution I was messing around a bit with manually unloading and reloading the kernel modules as well as creating a modified version of the udev rules file, which I bind mounted as a temporary override:

sudo rmmod pinctrl_tigerlake; sudo modprobe pinctrl_tigerlake
sudo rmmod soc_button_array; sudo modprobe soc_button_array
cp /etc/udev/rules.d/80-iio-sensor-proxy.rules /tmp/80-iio-sensor-proxy.rules
sed -i 's/.*iio-buffer-accel/#&/' /tmp/80-iio-sensor-proxy.rules
sudo mount --bind /tmp/80-iio-sensor-proxy.rules /etc/udev/rules.d/80-iio-sensor-proxy.rules
sudo udevadm trigger --settle
sudo systemctl restart iio-sensor-proxy

This was also sufficient to get tablet mode and automatic rotation into a working state. Strangely enough even though the correct output was shown in monitor-sensor, the option to enable automatic rotation didn’t appear in the KDE Display Settings. The section marked with the red rectangle is still missing for me and I have no idea how to make it show up:

Because of this I was under the assumption that what I was trying didn’t work and kept looking for other solutions until at a certain point I ended up demonstrating to my wife (for whom I’m actually setting this machine up) how monitor-sensor can indeed read the accelerometer values and ended up flipping the screen back, when suddenly BAM, it rotated, which meant that it can actually be enabled without showing up in the settings at all. :man_facepalming:

(Also, one more thing to be aware of: If iio-sensor-proxy is enabled, but the workarounds are not applied, all sddm and plasma screens take about an extra 25 seconds to appear, which I assume is due to some kind of DBus activation timeout.)


Note: The actual fix to the iio-sensor-proxy issue has been merged three days ago. Hopefully a new release will happen soon, but until then another way to achieve a working config would be to override the package sources instead of patching the udev rules in postInstall.

3 Likes

… Can we add all the NixOS stuff to the locked placeholder thread perhaps, @Matt_Hartley? Or should we create an entirely new thread for them? :joy_cat:

It’s interesting that device1 has in_angl_raw for you, it’s device2 for me.

Wait, you have a device2? I have device0 and device1. Which one is the angle sensor depends on the module load order. For me, the angle sensor was device1 until I added pinctrl_tigerlake to my initramfs (via mkinitcpio), then it went to device0.

1 Like

This is on Fedora 42 KDE Plasma 6.4.3
Kernel 6.15.7-200.fc42.x86_64 (64-bit)
iio-sensor-proxy-3.5-6.fc42.src.rpm

āžœ  ~ ls /sys/bus/iio/devices/iio:device0
buffer                   in_accel_x_calibbias   in_accel_z_calibbias   sampling_frequency
buffer0                  in_accel_x_calibscale  in_accel_z_calibscale  sampling_frequency_available
calibrate                in_accel_x_raw         in_accel_z_raw         scale
current_timestamp_clock  in_accel_y_calibbias   label                  scan_elements
dev                      in_accel_y_calibscale  name                   subsystem
id                       in_accel_y_raw         power                  uevent
āžœ  ~ ls /sys/bus/iio/devices/iio:device1
buffer                   in_accel_x_calibbias   in_accel_z_calibbias   sampling_frequency
buffer0                  in_accel_x_calibscale  in_accel_z_calibscale  sampling_frequency_available
calibrate                in_accel_x_raw         in_accel_z_raw         scale
current_timestamp_clock  in_accel_y_calibbias   label                  scan_elements
dev                      in_accel_y_calibscale  name                   subsystem
id                       in_accel_y_raw         power                  uevent
āžœ  ~ ls /sys/bus/iio/devices/iio:device2
buffer   current_timestamp_clock  in_angl_raw  power          subsystem  uevent
buffer0  dev                      name         scan_elements  trigger

This is all I have:

$ grep '.*' /sys/bus/iio/devices/*/name
/sys/bus/iio/devices/iio:device0/name:cros-ec-lid-angle
/sys/bus/iio/devices/iio:device1/name:cros-ec-accel
1 Like
/sys/bus/iio/devices/iio:device0/name:cros-ec-accel
/sys/bus/iio/devices/iio:device1/name:cros-ec-accel
/sys/bus/iio/devices/iio:device2/name:cros-ec-lid-angle

If you boot to a Fedora live USB do you have all 3 devices?

Now that you mention it I realize that I have also come across this thread while looking for clues around here. I’d be happy to copy my NixOS related findings over there if it gets unlocked.

1 Like

Nope, always two devices.

1 Like

I just asked my friend to try it on his FW12, his first device is lid-angle vs my third device, I’m wondering if the sensors load or get installed in the wrong order if autorotate breaks, because mine isn’t working right now and his is:

Yeah, that’s what I was thinking; if Matt doesn’t respond within a few days we might as well create it ourselves! @benstor214, would you have anything to add to the thread if we create it?

2 Likes

Hi, sadly I didn’t have time for personal stuff since I posted the fixes in the other thread.
So, no, nothing new from my part :slightly_smiling_face:
I was thinking about creating a dedicated NixOS thread to have all the specific fixes in one place, though I never came around to it.
If someone has more time on their hands than me, I think they absolutely should go along and create one. This will profit everyone running NixOS. I have just one advice: please don’t forget to credit people if you include fixes they posted :wink:
P.S. If someone can create a similar thread for Arch, that would be awesome

1 Like