[maemo-developers] Xsp pixel-doubling solutions for Nokia 770?

[From: Daniel Stone]

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?

> 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.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.maemo.org/pipermail/maemo-developers/attachments/20070502/ac053425/attachment.pgp