Ideal screen rotation

Carsten Haitzler (The Rasterman) raster at
Sat Nov 7 13:50:30 CET 2009

On Sat, 7 Nov 2009 10:20:37 +0000 Rui Miguel Silva Seabra <rms at> said:

> On Fri, Nov 06, 2009 at 08:24:13PM +0000, Neil Jerram wrote:
> > 2009/11/6 Rui Miguel Silva Seabra <rms at>:
> > > On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote:
> > >>
> > >> Well, you cannot expect every app to have such preferences, this device
> > >> runs generic linux apps that aren't made specially for the freerunner.
> > >> Now, of course the app loader can do this, similiar to how we already
> > >> request the cpu/backlight when launching some apps.
> > >>
> > >> But there is a problem. The user may switch between several apps with
> > >> different rotation needs. (xmahjongg needs landscape, tetris needs
> > >> portrait, ...)  How will omnewrotate be notified about this?
> > >
> > > The proper way is to define a set of DBUS signals.
> > 
> > Thanks to everyone for your replies on this topic.
> > 
> > I agree with Helge, in that I don't think DBUS is a good solution,
> > because I really want a solution that works for existing apps.
> You have no solution for existing apps other than causing a full
> stop on rotation once you get the desired rotation (which is what I
> do for apps that work better on landscape).
> > I suppose for existing apps there could be a DBUS proxy that somehow
> > works out the best orientation and then sends a DBUS signal on the
> > app's behalf.  But that seems complicated.
> Not smart either, because you'd have a buttload of work for little gain,
> and there will always be one more app which isn't supported yet, etc...
> > Also I'm not sure why DBUS helps at all.  Once a program somewhere has
> > worked out the best orientation, why not just call xrandr directly?
> DBUS helps a lot because you can define a standard set of signals:
>   1. screen rotation apps could listen for specific screen rotation signals
>   2. apps which have specific needs can broadcast said needs to DBUS
> This means minimal aditional work for everyone.
> > Another thought that occurred to me is that if this was a window
> > manager responsibility, perhaps the window manager could infer
> > preferred orientation simply from the requested window size?  (i.e.
> > requesting width > height implies a preference for landscape).
> The only way this could be the window manager's job, was if the window
> manager had auto-rotation routings. AFAICT, E doesn't yet.

the wm is who knows the properties of all windows - and knows which one(s) are
active. it is by far ion the best position to make a decision. a stand-alone
rotator is asking for trouble. it will be hell as any app can just ask for
whatever rotation they want irrespective if they are active or not. it's
everyone fighting over a single resource.

the right place for this is as properties of a window and part of the windowing
system setup - thus a matter between apps and the wm.

> Of course "rotator" apps only come up because people feel the need
> and writing a simple daemon is simpler than patching a quite evolved
> window manager.

actually it's much more work doing a stand-alone rotator.

> > That should often work for apps that were designed for the desktop.  I
> > would guess that apps written for the FR might not request specific
> > sizes, because they'd know that they will always be fullscreen anyway
> > - so for those apps some explicit configuration would be needed
> > somewhere (prefer-portrait, prefer-landscape, or auto-rotate).
> So "rotators" would need to parse all the configurations? I still think
> DBUS is the way to do it well, but I'm open for proof otherwise.

dbus is by far and wide NOT the way to do it.

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

More information about the community mailing list