[maemo-developers] Xsp pixel-doubling solutions for Nokia 770?
From: Matthew Allum mallum at gmail.comDate: Wed May 2 19:52:38 EEST 2007
- Previous message: Xsp pixel-doubling solutions for Nokia 770?
- Next message: Xsp pixel-doubling solutions for Nokia 770?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi; On 5/2/07, Eero Tamminen <eero.tamminen at nokia.com> 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
- Previous message: Xsp pixel-doubling solutions for Nokia 770?
- Next message: Xsp pixel-doubling solutions for Nokia 770?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]