Nobody had plugged in a mouse

**Series: The PineNote pen and glass** 1. Part 1: It had been five frames a second the whole time 2. Part 2: Nothing to press 3. Part 3: Nobody had plugged in a mouse *(Current)*

In August this was a finished feature. The accelerometer had been matched to the wrong tablet by a hardware database that could only see the chip, we restored the mounting matrix with one udev rule, and the closing line of that post was that every component of working auto-rotation was present. In the same week the rotate action moved out of a menu, fifteen items deep, and became a single button in the top bar.

A month later the screen did not turn. Both of those posts are still true. That is the interesting part.

The button was doing exactly what it was built to do

Our rotate button turns the screen and sets `orientation-lock`. That is its contract and it always was: a manual rotation is a decision, and a decision that the sensor is free to overrule two seconds later is not a decision.

Nothing on this tablet ever cleared that lock again. GNOME has a control that does, the Auto Rotate toggle in Quick Settings, and that toggle was not on screen either, for reasons that took another day to find. So the tap that made rotation one gesture instead of fifteen menu items was also, every time, the tap that switched off the automatic rotation it had been built to sit beside, and the only thing that could switch it back had gone missing. The feature was not broken. It was off, held off by us, with the light switch hidden.

The sensor stops answering after the cover closes

Clearing the lock got the tablet as far as the second defect. Closing the cover suspends this device, through a script the community image ships, and the accelerometer driver survives it: the kernel logs a matching suspend and resume every time. `iio-sensor-proxy` does not. After the first cover close, a claim on the accelerometer times out, and orientation stops updating until the service is restarted by hand. A oneshot unit hung off `suspend.target` now restarts it on every resume, which is not a fix so much as a bucket under a drip, and it is honest about being that.

With the proxy healthy and the lock off, the sensor reported `left-up` when the tablet was turned, and Mutter still applied no transform at all. So the extension does the rotation itself: claim the accelerometer, subscribe to its changes, debounce 600 ms so that a tilt through the diagonal does not apply three transforms on the way to the one you wanted, and route it through the same rotate call the button already used. Two triggers, one path.

That worked. It also meant the tablet turned without Mutter's own machinery ever coming back, and I had no explanation for why Mutter was sitting it out.

Three cuts that proved nothing

The explanation was supposed to come from GNOME's Auto Rotate toggle, and the toggle itself was what kept disappearing, which is an awkward thing to chase: a missing switch and a feature that is off look exactly alike from the front.

The first night I ran three A/B cuts against our own extension, disabling one piece at a time and asking CHOD to look in the drawer. The results said nothing. Between two of the arms the tablet rebooted, which changes a great deal more than the one setting under test, and for part of that night a Bluetooth keyboard was paired, which I had not written down as a variable because it was not a variable I was testing.

Mutter manages panel orientation only while the seat is in touch mode, and touch mode ends the moment libinput reports anything shaped like a pointer. That keyboard enumerates as two devices, a keyboard and a mouse, which is ordinary for anything with a knob or media keys on it, so pairing it tells the compositor that this is a desktop with a screen bolted to the front, and a desktop does not rotate. The keyboard is not doing anything wrong, and neither is any particular model: what ends touch mode is the pointer, whoever brings one. The Auto Rotate toggle goes with it, since what the toggle is bound to is that same judgement.

Nobody said it. It is inferred, from the same signal a desktop uses to know it is a desktop, on a machine that is both at different hours of the day.

Four cuts that proved something

The next day the keyboard was gone from the room and each cut changed exactly one thing.

Extension off: the toggle is there. Extension on with no virtual input devices created: there. Extension on with only the virtual keyboard device, the one the two-finger undo gesture holds open: there. Extension on with the virtual pointer device: gone.

The pointer belonged to the long press that synthesises a right click, from the other half of the same week's work. It was created once when the extension started and held for the life of the session, which is what you do with a device you will use often, and it is indistinguishable to Mutter from a mouse someone plugged in. Our own convenience had been telling the compositor that this tablet was a desktop.

The fix is a change of lifetime and nothing else. The pointer is created at the instant a long press fires, sends its motion and its click, and the reference is dropped in the same breath. Clutter offers no destroy for a virtual device, so letting go is the whole disposal. The gesture behaves exactly as before. The toggle stays in the drawer, and the screen keeps following the sensor through as many long presses as you care to do.

What stays

The rotate button stays. It is no longer load bearing, since the sensor is back and GNOME's own toggle is visible again, and CHOD's reasoning for keeping it is the reasoning I would want from anyone: the new path has been trustworthy for about a day, and one tap that means "leave it exactly like this" is worth having whether or not the automatic path is working this week.

Two things are worth taking out of it. The first is that "every component is present" has a shelf life. Nothing about that August sentence was wrong when it was written, and nothing had to be removed for it to stop being true: one component was switched off by a button we shipped, and another was hidden by a device we created. The second is about the three cuts that proved nothing, which is my own to keep. An A/B comparison is only about the thing you changed if it is the only thing that changed, and a reboot in the middle of the run is a change, and a keyboard on the desk is a change, and neither of them shows up anywhere in the result. The answer looks just as clean either way. That is what makes it expensive.