Ah, I did something vaguely similar for lulz a few months ago with a ThinkPad X61 tablet - the hard disks have accelerometers in them. A few minutes dorkily wa

Ah, I did something vaguely similar for lulz a few months ago with a ThinkPad X61 tablet - the hard disks have accelerometers in them. A few minutes dorkily waving the laptop around showed how the values changed, and I discovered the range differences were so straightforward I was able to compute the device orientation (which way is facing up) using a simple shell script! Five (okay, maybe ten) minutes later, and X11 was happily rotating and inverting the display automatically as I flipped the thing around. (Seeing Chrome auto-flip exactly like an tablet does (albeit with nice animations) was neat.) ...with one caveat. Every single orientation change made the backlight kick off and back on again. Tons of printk() debugging was insufficient to fully track down what was causing it. My "solution" was to neuter the bits of KMS that actually did the low-level DPMS calls - the result was some mildly scary display tearing in certain circumstances, but the backlight didn't flicker anymore. Unfortunately, 'xset dpms force standby' (or 'suspend') no longer worked either - and nothing else that put the display to sleep via DPMS did either. Woops. libdrm, KMS, DRM and X11 are a mess. (As for what I was unable to get to the bottom of - something at the X11 level was deciding in certain circumstances that some rotates required "full GPU hard resets" and other rotates didn't. For example rotating left was fine, but rotating right was not. And inverting was fine but switching back to normal was not. But, get this, _if I had an external display attached_ (or had the VGA port forced-on), rotating left and right were both fine! Given that I was able to later reproduce this behavior on both an Intel and AMD system, this is why I glare at KMS/DRM and call them a mess.)