Hi;
On 5/2/07, Daniel Stone <[EMAIL PROTECTED]> wrote:
On Wed, May 02, 2007 at 05:52:38PM +0100, ext Matthew Allum wrote:
> 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.
I guess you could hack around this by walking the tree and looking for a
full-screen override-redirect window (or one with the appropriate
class). If you find one, then pend the resolution change of all windows
to when you switch away from it; a correctly-behaved app will fix the
resolution before it leaves, thus leaving you with no need to bother
everything else. Would that work?
Yeah you'd basically have to have matchbox put a 'lock' on the
geometry all other windows and just hope they dont notice the randr
event or new display size and start acting in response to that. Im
sure it will be filled with nasty edge cases.
> 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 :)
Egh, my eyes! Dealing with input in particular could be a pain.
=)
I guess that means SDL cant run on a raw framebuffer.
I really think using xrandr for this wont buy you much though (in fact
you'll probably loose) as you really only want the single topped app
to notice the display has shrunk not everything server wide (as randr
is intended).
Perhaps a simple solution is just an addition to something that tracks
the window stack (not necessarily mb - maybe something maemo specific
like the TN) and checks for a 'PIXEL_DOUBLE' hint (or similar
mechanism) when the top application window changes. If its set,
perform the pixel doubling magic, if its not unset it (or do nothing).
Make sure the window also has the right hints so MB never lets any
dialogs above it (which would appear XL).
-- Matthew
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
