Hi;

On 5/2/07, Eero Tamminen <[EMAIL PROTECTED]> wrote:

It's evil that games change screen resolution, system changes
should be controlled by system software instead of random apps.

If it's enough that the whole screen is scaled instead of a window or
specific update, for Maemo the XRandR approach could be joined with
my earlier proposal.

I.e. if window has certain property (say geometry=320x200), the window
manager could use XRandR to switch the screen resolution when that kind
of a window is on top/focused/fullscreen(ed).  When the window is not
anymore focused/top/fullscreen or is closed, the previous/default
resolution is restored. This way banners above the window wouldn't
get the resolution changed (banners don't take focus), but dialogs
(like power menu) would.

Do you see any problems (besides getting these changes to Matchbox and
SDL after adding XRandR support to Xomap)?


Theres a big downside to this approach in that matchbox already
supports randr and has done for a while in order to facilitate stuff
like screen rotation - matchbox will in effect resize all windows and
position dialogs as to adapt to the new screen resolution - like other
WM's also do. This is what you'd expect in the general case.

So if you pixel double via randr every single application is going to
get resized and un resized. Whats worse is theres not going to be an
easy way around this as much stuff in matchbox is obviously dependant
on the 'real' display geometry.

For the use case which is being described here - namely always full
screen applications which need exclusive access to the display at a
lower resolution Why not do something like switch to another VT and do
it directly on the framebuffer ? and then wrap this with something
that makes sure you can always safely return to/from X - maybe
something managed through systemUI or some such. This is a different
approach but could prove simpler in the long run though I havn't
thought long and hard about it so there could be some obvious
downsides - More a random idea :)

 -- Matthew
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Reply via email to