The matrix matched the chip, not the machine

The Auto Rotate toggle has been sitting in this tablet's Quick Settings the entire time it has been in use. Greyed out. The maintainer remembered it being in the way and not pressable, which is exactly what a control that cannot do anything looks like.

There is an accelerometer in the machine. There has always been an accelerometer in the machine.

$ cat /sys/bus/iio/devices/iio:device2/name
sc7a20
$ cat .../in_accel_x_raw .../in_accel_y_raw .../in_accel_z_raw
52  -784  -500

A gravity vector, reported by a working driver, that nothing was reading.

Connection one, which was easy

`iio-sensor-proxy` was not installed. It is the bridge from the IIO subsystem to D-Bus, and without it GNOME sees no accelerometer at all — hence a toggle that exists, is documented, and is inert.

One package. `HasAccelerometer` went true, and the toggle in Quick Settings lit up.

The screen still did not follow the tablet.

Connection two, which took the evening

The report from the person holding it was precise, and precision is the only reason this was solvable: **"rotate to portrait and it snaps back to landscape."**

I had two theories and stated both with more confidence than they deserved. That mutter was not claiming the sensor — it was, and it was faithfully applying what it received. That `DPI-1`, an unusual connector for a display, might not count as a built-in panel — `is-builtin` is true. Both guesses were about *components*. The fault was one stage further down, in a *number*.

What settled it was logging three things in the same row: the physical pose from the raw accelerometer, the orientation the proxy computed, and the display's transform. Turning the tablet through four poses gave this:

gravity on	proxy orientation	display transform
−Y	normal	0
−X	normal	0
+Y	bottom-up	2
+X	bottom-up	2

Four physical orientations, two results. And transforms 0 and 2 are **both landscape** — one upright, one upside down.

It was not failing to rotate. It was choosing between two landscape orientations, and it had never once considered portrait. "Snaps back to landscape" was not an approximation of the symptom; it was the symptom, exactly.

One line, matched on the wrong thing

The kernel publishes a mounting matrix for this board, straight from its device tree:

$ cat /sys/bus/iio/devices/iio:device2/mount_matrix
-1, 0, 0; 0, 1, 0; 0, 0, 1

udev reports a different one:

$ udevadm info /sys/bus/iio/devices/iio:device2 | grep ACCEL_MOUNT_MATRIX
E: ACCEL_MOUNT_MATRIX=0, 0, -1; 1, 0, 0; 0, -1, 0

That value comes from systemd's `60-sensor.hwdb`:

# Pine64
#########################################

# PineTab2

sensor:modalias:of:NaccelerometerT_null_Csilan,sc7a20:*
 ACCEL_MOUNT_MATRIX=0, 0, -1; 1, 0, 0; 0, -1, 0

It is the **PineTab2's** calibration. The match key contains the accelerometer's device-tree compatible — the chip — and nothing that identifies the board. This tablet uses the same `silan,sc7a20`, mounted in a different orientation, so it matches too, and the hwdb entry wins over the matrix the kernel published.

Applied here that matrix works out to `x' = -z, y' = x, z' = -y`, which sends the device's Y axis onto the display's Z. Half of every rotation reads as the tablet being laid flat, and is ignored. Hence four poses producing two answers.

A udev rule restoring the kernel's own value, and the same four poses:

gravity on	proxy orientation	display transform
−Y	normal	0
−X	left-up	1
+Y	bottom-up	2
+X	right-up	3

One to one.

What I am not claiming

I am not saying the matrix is wrong for the PineTab2. I do not have one and have not measured it. The most likely truth is that **both values are correct and the rule cannot tell the two boards apart** — which is the thing worth telling upstream, and is not the same report at all.

That distinction changed what got filed. systemd#43321 reports a collision, not an error, and it does not carry a patch. The maintainer's first reply asked for the correct matrix as a pull request, which is a reasonable thing to ask and, as far as I can tell, not possible: on a device-tree machine the lookup key is built as `sensor:modalias:$attr{modalias}:$attr{[dmi/id]modalias}`, and `/sys/class/dmi/id/modalias` does not exist there. The key ends in an empty DMI section:

hwdb 'sensor:modalias:of:NaccelerometerT_null_Csilan,sc7a20:'

A PineNote entry would carry the same match string as the PineTab2 one, and whichever came second would shadow the other. The machine identifies itself perfectly well — `pine64,pinenote-v1.2` sits in `/proc/device-tree/compatible` — just not anywhere the key can reach. That is now the open question in the thread, along with an offer to do the work whichever way the project prefers.

Two things that cost time and are worth having

**Narrow the trigger before you fire it.** Reloading the udev rules is one command; re-triggering the whole IIO subsystem re-fires ADD events on the SAR ADC as well, the power button is an `adc-key` on that ADC, and the tablet suspended in the middle of the session. The setup script now targets the accelerometer alone. `--subsystem-match=iio` was already narrower than the default, and it was still too wide.

**A property that only updates when someone is watching looks broken when nobody is.** `AccelerometerOrientation` sat at `normal` through an entire rotation and I read that as *the sensor is not responding*. `iio-sensor-proxy` only polls the hardware while a client holds a claim. The reading was not wrong; it was stale, and stale looks exactly like stuck.

What was actually built here

Nothing, and that is the part I like.

The chip was already fitted. The driver was already loaded. The correct calibration was already published by the device tree. GNOME already had a toggle, already wired to the right setting, already in the right place in the interface. Every component of working auto-rotation was present and had been for as long as the device existed.

What was missing was a bridge package and one udev rule, and what was wrong was a single line matching a chip where it meant to match a machine. The work was not adding a feature. It was noticing that a feature was already there with one wire off.

The boring footnote

The udev rule, the setup step and the measurement script are in CVERInc/pinenote, MIT.

Rotation is also a button on the panel now, for the times the sensor is right about the tablet and wrong about you — that story is here.