Ideal screen rotation

[Carsten Haitzler (The Rasterman)]

On Sun, 08 Nov 2009 03:14:54 +0000 Dave Ball <openmoko at underhand.org> said:

> Carsten Haitzler (The Rasterman) wrote:
> > On Sun, 08 Nov 2009 02:03:47 +0000 Dave Ball <openmoko at underhand.org> said:
> >
> >   
> >> Sounds like we should be using window properties for passing hints to 
> >> the WM, and dbus for getting orientation information from the 
> >> accelerometers.
> >>     
> >
> > that is sane. :)
> >
> >   
> >> Maybe it's time for omnewrotate to retire, with the WM talking to FSO's 
> >> orientation API [1] directly?
> >>     
> >
> > perhaps. whatever the mechanism
> >
> > 1. the wm is the right place to make the decision.
> > 2. the wm is in the best position to easily gather information about an
> > application's window and know what window is active
> > 3. the wm is already talking to the xserver as part of its job - and it's
> > always hanging around
> > 4. all the wm needs to know is "some external input has decded that the
> > screne should be rotated". 
> 
> I think what you meant here is the WM decides whether the screen should 
> be rotated or not - all the 'external input' provides to the WM is some 
> hint that e.g. the _device_ has been rotated?  WM could decide to NOT 
> rotate the screen, if the current app only works in one orientation.
> 
> > be this an accelerometer, or like the g1, opening up the
> > screen, so be it. as long as
> > 4.1 the current status of this rotation state can be queried at any time
> > (you can ask what position the device is in or the screen is opened up or
> > not etc. etc.)
> > 4.2 you can get an event when this state changes really quickly (not have to
> > wait a while).
> >   
> 
> Indeed.  I've not played with the fso orientation API, but it looks like 
> that is exactly what it's designed to provide.  It seems sensible for 
> this to be over dbus - given that it's an abstraction of hardware.
> 
> > if it were me... i'd even have the current desired rotation state be a
> > property on the root window too... but at this point its moot - dbus or
> > property. 
> 
> If the root window will only work in one orientation, specifying that 
> orientation through a window property would be consistent - but ideally 
> wouldn't we want the root window to be able to cope with being rotated 
> to work in either orientation?  Or have i missed something special about 
> the root window?

root window i special. it's generally got properties for the display/screen(s)
as a whole. as such the desired rotation of the device is implicitly a
property of the screen (device accelerometres and screen are tied in this
case). thus it makes sense to set desired device rotation on the root window
and desired app window rotation on the individual app windows. wm needs to
track both and determine which one takes precedence based on policy and th
en implement that rotation, if needed. policy is what a wm implements - that's
the nature of the beast. that policy may be hard-coded in the wm or
configuration for it.

so to me - it makes perfect sense for such a desired state to be put into the x
domain entirely as the property is related directly to the display/screen. gsm
makes no sense being properties/events of x11. neither does wifi, or bt.... but
brightness of screen, current abient lighting sensor data, etc. makes
sense. as such x also covers input devices (kbd, mouse), thus anything you can
deem to be an input device (touchscreen, buttons on the device, accelerometrs
etc.) makes sense to put via x11, not dbus. its within the logical domain for
its functionality.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com