Hi,
ext Matthew Allum wrote:
>> > 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.
It can. The problem is that it's not the only process running.
Think what would / should happen if user presses power menu
while game has switched to another VT...
I think Daniel has also mentioned some (kernel) race conditions
in switching VT.
> 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).
That should be a problem only from the performance point of view.
And if that's the thing you're concerned about, then switching
screen orientation will be a similar problem and Matchbox should
anyway be fixed to notify only visible windows of the screen
geometry changes.
- Eero
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
