Comment 9 for bug 90455

I don't think that changing the wacom orientation belongs there, since it's too localized to that point of control. Here's what I mean by that:

The tablet rotation needs to change any time the display rotation does, so they stay in sync. In general, with a usb tablet on a desktop workstation, if you have a monitor that swivels to portrait rotation, and use RandR to change it, you might NOT want your wacom rotation to follow it. But on a tablet PC, you always want them to remain in sync. Perhaps the X wacom driver should be made aware of RandR events, and have a setting that tells it to rotate with the screen, automatically. Unset that, and it will not rotate when the screen does.

Since the wacom driver does not presently support RandR, and since there are other things that need to be done when the screen is rotated, the best solution involves arranging for an event handler or hook script to be run when the rotation has occured. It ought to work no matter what program you use to send the RandR commands to the display, and no matter whether you invoke it manually with a command or button, or it's done automatically by an ACPI swivel-down-tablet or swivel-up-laptop event (sort of a button in it's own right).

I've been researching this problem online, and have found a simple daemon that connects to the user's X server, registers to receive RandR Rotation event notifications, and then sleeps until one occurs. When it wakes up, it looks to see what the new screen rotation is, by directly querying the display itself. If it's the same as last time it woke up, it goes back to sleep. Otherwise, it calls a shell script with a single argument for the new rotation, then goes back to sleep.

The shell script is responsible for changing the navpad orientation, the Wacom tablet rotation, etc. Since it's invoked through an actual display rotation event, it runs no matter what program actually called for the rotation. (See bug #217182 for a comment describing this further.)