Please let me know if you find a Solution as i also plan on using opensuse (kde tumbleweed)
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
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.
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.
(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
.
⦠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?
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.
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
/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.
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?
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
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
P.S. If someone can create a similar thread for Arch, that would be awesome