I got my Framework 12 last week and have been having lots of fun getting it up and running but am wondering if there is a way in software to access the hinge sensor that is used to disable the keyboard and trackpad when in tablet mode. I tend to use the tablet mode as a stand for propping the screen up in limited space and tend to hold it in tablet mode with the hinge at the top as the heat blowing from the hinge area can be quite warm and holding that against me gets uncomfortable real fast. I know I can flip the screen around manually in software, but it would be handy if I could have software react to the hinge folding around and auto-flip the screen.
1 Like
What operating system are you using?
If all you need to do is the flip the screen automatically, I believe most operating systems already do this out-of-the-box using the accelerometer (rather than the hinge). I know Fedora KDE does this by default. Do you need to do something other than auto-flip?
Auto-flip/rotate is what I’m looking for but it’s not happening automatically for me, I’m having to go into display options and manually change the orientation. I’m running Gentoo Linux and have both KDE Plasma and Gnome installed and working fine with everything else working. Any idea what piece(s) of software I might be missing to do auto-rotation?
See FW12 - Problems returning from Tablet Mode - Tracking thread - #6 by Daniel_Schaefer and the immediate following message. There’s some workarounds that currently need applying, but with those two changes it’s working perfectly for me on Arch, and I imagine Gentoo will have the same workarounds needed.
1 Like
Test if your sensors work with a latest Fedora KDE live ISO. Most likely yes, but this excludes hardware problems before you start changing your gentoo setup.
If yes, then Gentoo can also work, but you need specific kernel modules included and loaded to get a working iio-sensor-proxy service, which is the actual direct requirement. The other linked post discusses this, but there is no short summary of the requirements (yet).
This has gotten me further down the rabbit hole at least. I’ve realized that KDE Plasma (Wayland) is switching to and from Touch Mode automatically when I flip the screen back and forth, I can see the icons on the dock changing sizes, so the hinge sensor appears to be read somewhere. Not sure about gnome, I don’t know how I would know. I don’t see any settings pertaining to rotation anywhere.
Looking further, I installed libiio and used the iio_info command to list all of the iio sensors and it’s showing both the hinge and accelerometer. A quick hacked script shows that the values are updating properly as I move things around, so the sensors are functioning fine and no kernel modules are missing.
iio-sensor-proxy seems to be the thing that all of the threads online discuss to get rotation working so I looked into that as well. The original source seems to be systemd specific and I’m using openrc, but it appears to be just the service registration that is geared to systemd, not the service itself. There does not appear to be an official ebuild for it but the "guru” overlay has an ebuild and it builds just fine with USE=”-systemd” and installs openrc compatible service files. However, it fails on starting. Modifying the init script to output logs shows it failing to find an sensors.
==> iio-sensor-proxy-stderr.log <==
** (iio-sensor-proxy:6207): WARNING **: 01:00:20.655: Not a switch [/sys/devices/platform/FRMWC004:00/cros-ec-dev.2.auto/cros-ec-sensorhub.3.auto/cros-ec-accel.10.auto/iio:device0/../capabilities/sw]
** (iio-sensor-proxy:6207): WARNING **: 01:00:20.655: Invalid bitmask entry for /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input36/event23
==> iio-sensor-proxy-stdout.log <==
** (iio-sensor-proxy:6207): DEBUG: 01:00:20.655: No sensors or missing kernel drivers for the sensors
That’s where I am for the moment. I’ll also try another live image just to see how/if it works and will keep digging and put any solutions I find back here.
Thanks everyone for the pointers!
People on arch had an issue with the order of kernel modules loading messing up the functions. Check this if you didn’t try already:
Also several distros had an issue with iio-sensor-proxy existing as a service but being unable to fully start with similar errors, due to some but not all requirements missing. I’m using openSUSE personally, and waiting for the following modules to drop into the default kernel, because I can’t be arsed to compile my own:
There’s also an user with nixos, who shared their working config, maybe you can adapt this to configure the same changes on gentoo:
If you are on gentoo, I expect you are using the lates packages. So the iio-sensor-proxy bug that has been fixed upstream about a week ago will not affect you. Do not apply any udev rule patches suggested because of this bug.
1 Like
I did try with a KDE Neon live image and it exhibited the same error as the iio-sensor-proxy ebuild I found on the overlay, the same log saying that there were no sensors found. All of the needed kernel modules are already built as part of the gentoo dist-kernel and were loaded fine, iio_info shows the lid sensor and gyro there and working.
For example:
iio:device2: cros-ec-accel (label: accel-base) (buffer capable)
4 channels found:
accel_x: (input, index: 0, format: le:S16/16>>0)
3 channel-specific attributes found:
attr 0: calibbias value: 0
attr 1: calibscale value: 1.000000
attr 2: raw value: -48
accel_y: (input, index: 1, format: le:S16/16>>0)
3 channel-specific attributes found:
attr 0: calibbias value: 0
attr 1: calibscale value: 1.000000
attr 2: raw value: 3568
accel_z: (input, index: 2, format: le:S16/16>>0)
3 channel-specific attributes found:
attr 0: calibbias value: 0
attr 1: calibscale value: 1.000000
attr 2: raw value: 16240
timestamp: (input, index: 3, format: le:S64/64>>0)
6 device-specific attributes found:
attr 0: calibrate ERROR: Permission denied (13)
attr 1: current_timestamp_clock value: boottime
attr 2: id value: 1
attr 3: sampling_frequency value: 12.500000
attr 4: sampling_frequency_available value: 0.000000 12.500000 200.000000
attr 5: scale value: 0.000598550
4 buffer-specific attributes found:
attr 0: data_available value: 0
attr 1: direction value: in
attr 2: hwfifo_timeout value: 0.000000
attr 3: hwfifo_watermark_max value: 256
I had built iio-sensor-proxy from git master and run it and it was giving me errors but something must have changed between then and now because now if I run it as root it’s finding the sensors and sending the appropriate signals, complete with autorotate in tablet mode working.
I believe all that is needed for this to work is to build and use iio-sensor-proxy from git master, or if a version greater than 3.7 is available from your package manager, use that.
For Gentoo here’s what I did:
Install iio-sensor-proxy 3.7 from the guru overlay to get the appropriate service scripts for openrc:
eselect repository enable guru
emerge --sync
echo 'gnome-extra/iio-sensor-proxy ~amd64' > /etc/portage/package.accept_keywords/iio-sensor-proxy
emerge -av iio-sensor-proxy
Get the latest iio-sensor-proxy code from https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/ and build and install it according to its README. I applied the openrc patch from the guru overlay so that it wouldn’t complain about systemd not being present.
Enable the iio-sensor-proxy service and start it (if you’re using systemd, do it the systemd way).
rc-update add iio-sensor-proxy default
rc-service iio-sensor-proxy start
That should be it. I also installed libiio so I could use the iio_info command to introspect the devices but I don’t think it’s required to be manually installed. I also used hwinfo to check for hardware and kernel modules but that should also not be required. I did not make any kernel changes, I’m using the dist-kernel with no configuration changes, but I am using a Universal Kernel Image so I can have my rootfs LUKS2 encrypted. It shouldn’t matter but I figured I should mention it.
1 Like