Hi,
ext Arnim Sauerbier wrote:
> Regarding your portability argument: As things stand today, we already *do*
> need to make
> non-portable changes to get acceptable performance using the existing ITOS.
> The best example of
> this is the fact that to use pixel-doubling, games using SDL_Flip and
--- The ever-informative Daniel Stone <[EMAIL PROTECTED]> wrote:
> The second, and most important, is portability. Not only are you tying
> your app to the internet tablets, but you're tying them to the _current
> generation_. ---
> You're turning a portable app (hell, the point of SDL is portabi
On Sun, May 06, 2007 at 04:57:58PM +0300, ext Siarhei Siamashka wrote:
> On Thursday 03 May 2007 12:58, Eero Tamminen wrote:
> > Yes, it just cannot be done safely / reliably.
>
> I can't be completely sure, but I think it is possible to do safely/reliably.
> At least it is worth trying in my op
On Thu, May 03, 2007 at 11:23:55AM -0700, ext Carl Worth wrote:
> On Thu, 3 May 2007 18:08:36 +0100, "Matthew Allum" wrote:
> > On 5/3/07, Carl Worth <[EMAIL PROTECTED]> wrote:
> > > But isn't this exactly one of the features provided by the new RandR
> > > 1.2 stuff?
> >
> > Can it - any more det
Hi,
ext Siarhei Siamashka wrote:
>> AFAIK Xserver requests & waits DSP to stop updating the framebuffer
>> before proceeding. This works with HW, but you cannot expect it to
>> work reliably with misc X clients as there are no guarantees about
>> what they do. If client is not processing X events
On Thursday 03 May 2007 12:58, Eero Tamminen wrote:
> ext Siarhei Siamashka wrote:
> > What problem with using framebuffer directly? Everything should be
> > fine, you can get notifications from xserver when your window becomes
> > obscured, so you can stop drawing. I suggest you to try MPlayer on
> If new Xomap doesn't work on the 770, I'd like to know about it. (I
> don't have time to constantly test it, but I can -- and will -- fix it.)
I have found what triggers the Xsp disabling from SDL for IT 2005, 2006, and
2007 hacker ed.
Doubling gets disabled whenever we update less than the f
On Thu, 3 May 2007 18:08:36 +0100, "Matthew Allum" wrote:
> On 5/3/07, Carl Worth <[EMAIL PROTECTED]> wrote:
> > But isn't this exactly one of the features provided by the new RandR
> > 1.2 stuff?
>
> Can it - any more details ? Would seem a really nice fit if so.
Here's a link to the latest prot
Hi;
On 5/3/07, Carl Worth <[EMAIL PROTECTED]> wrote:
On Thu, 3 May 2007 15:12:43 +0100, "Matthew Allum" wrote:
>You are essentially changing the server viewport area here
> *not* the display size.
But isn't this exactly one of the features provided by the new RandR
1.2 stuff?
Can
On Thu, 3 May 2007 15:12:43 +0100, "Matthew Allum" wrote:
>You are essentially changing the server viewport area here
> *not* the display size.
But isn't this exactly one of the features provided by the new RandR
1.2 stuff?
-Carl
pgpGTUcbNAuU5.pgp
Description: PGP signature
Hi;
On 5/3/07, Eero Tamminen <[EMAIL PROTECTED]> wrote:
>
> Note, this was just one potential problem - and with any problem
> theres going to be somekind of workaround. Its just special casing
> everything to 'subvert' randr is going to need alot and therefor I
> dont see what you gain from usi
Hi,
ext Matthew Allum wrote:
>> For system dialogs (which take focus) coming on top of the fullscreen
>> application, the screen size was supposed to be switched back to normal
>> by the WM before it allows it on screen. If the dialog contents are
>> rendered before the dialog is shown, this coul
Hi;
On 5/3/07, Eero Tamminen <[EMAIL PROTECTED]> wrote:
Hi,
ext Matthew Allum wrote:
>> > 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
Hi,
ext Matthew Allum wrote:
>> > 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 pr
On Thu, May 03, 2007 at 02:28:04AM -0700, ext Arnim Sauerbier wrote:
> --- Daniel Stone <[EMAIL PROTECTED]> wrote:
> > I don't see the conflict between working on new Xomap versions and
> > improving the N800.
>
> There is none, but look again at the title of this thread. :)
Pretty sure the hac
Hi,
ext Siarhei Siamashka wrote:
>> Same problem as using framebuffer directly. How user switches
>> to another application? How to invoke power menu properly etc.
>
> What problem with using framebuffer directly? Everything should be
> fine, you can get notifications from xserver when your wi
(I have all your other mails queued up to read again and reply to, but
I'd like to reply to this one as quickly as possible.)
On Thu, May 03, 2007 at 12:39:11PM +0300, ext Siarhei Siamashka wrote:
> On 5/3/07, Eero Tamminen <[EMAIL PROTECTED]> wrote:
> >Same problem as using framebuffer directly.
On 5/3/07, Eero Tamminen <[EMAIL PROTECTED]> wrote:
[...]
Same problem as using framebuffer directly. How user switches
to another application? How to invoke power menu properly etc.
What problem with using framebuffer directly? Everything should be
fine, you can get notifications from xse
Eero Tamminen wrote:
ext Markku Vire wrote:
If we need one fullscreen app, why not to launch a new X-session that
uses this lower, pixel-doubled resolution and then run our SDL game
there? Other applications would not recognize anything.
Same problem as using framebuffer directly. How user s
--- Daniel Stone <[EMAIL PROTECTED]> wrote:
> I assume your 'xrandr' screenshot is taken on the desktop?
> RandR doesn't imply a specific scaling algorithm.
Yes. I mistakenly assumed that xrandr would imply a point-scaler algorithm.
> I don't see the conflict between working on new Xomap version
Hi;
On 5/3/07, Markku Vire <[EMAIL PROTECTED]> wrote:
If we need one fullscreen app, why not to launch a new X-session that
uses this lower, pixel-doubled resolution and then run our SDL game
there? Other applications would not recognize anything.
If the games need everything an xserver prov
Hi;
On 5/3/07, Eero Tamminen <[EMAIL PROTECTED]> wrote:
>
> 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...
It would switc
Hi,
ext Markku Vire wrote:
> ...clip...
>>> 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 shou
Hi,
Eero Tamminen wrote:
Hi,
ext Matthew Allum wrote:
...clip...
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).
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
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 wil
On Thu, May 03, 2007 at 12:35:15AM +0300, ext Siarhei Siamashka wrote:
> Maybe it is time to try getting these optimized functions integrated into
> glibc for use on Nokia 770? Surely they need to be tested a bit more
> first. But improving core system components (glibc, xserver, SDL, ..) may
> h
On Wednesday 02 May 2007 23:01, Arnim Sauerbier wrote:
> If the memcpy on 770 is something like 190MB/s, pushing 800x480 at 30fps
> would use only 12 percent of that bandwidth
I'm sorry, I was the source of this misleading information, I forgot that
you are a Nokia 770 user and mentioned some num
On Wed, May 02, 2007 at 01:01:00PM -0700, ext Arnim Sauerbier wrote:
> Siarhei Siamashka wrote:
> > This is what works for MPlayer on Nokia 770. It creates x11 window just
> > to reserve some screen space and prevent other applications from using
> > it. After that, it renders data directly to fra
--- Siarhei Siamashka <[EMAIL PROTECTED]> wrote:
Siarhei Siamashka wrote:
> This is what works for MPlayer on Nokia 770. It creates x11 window just
> to reserve some screen space and prevent other applications from using
> it. After that, it renders data directly to framebuffer and uses x11 for
On Wednesday 02 May 2007 20:40, Daniel Stone 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 frame
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 t
On Wed, May 02, 2007 at 07:08:24PM +0300, Eero Tamminen wrote:
> Hi,
>
> Daniel Stone wrote:
> > Hence, XRandR. The only thing worse than designing a bad API, is
> > designing _another_ API.
>
> Hm. I think the API on Desktop for scaling window content is OpenGL.
> ;-)
Sure, but we don't have O
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 appr
Hi,
Daniel Stone wrote:
> Sure, but that's mainly because pixel-doubling is a non-portable hack
> (doesn't exist in other products, doesn't exist on desktops, may not
> necessarily exist in future products). It's not a hack because of how
> it's implemented, but just by its very n
As for pixel doubling, a practical solution would be just to support
400x240 fullscreen resolution in SDL so that no extra hack would be
required when porting each game or emulator in particular.
+1 to this, as a user. 400x240 is a truely good resolution for a display
size like that of a por
On Monday 30 April 2007 12:26, Frantisek Dufka wrote:
> Daniel Stone wrote:
> > Specifying that pixels must be exactly _doubled_ is a
> > hack around both the performance issues and a lack of resolution
> > independence. Apparently an important one, if you happen to like SDL
> > games, but a hack
Eero Tamminen wrote:
> Hi,
>
> Daniel Stone wrote:
>
On Mon, Apr 30, 2007 at 09:34:38AM +0200, ext Frantisek Dufka wrote:
You mean, modify every single drawing X request in the X protocol so it
contains flags, meaning that we have to change every drawing-related
function in -
On Mon, Apr 30, 2007 at 02:26:37PM +0300, Eero Tamminen wrote:
> Hi,
>
> Daniel Stone wrote:
> >>> On Mon, Apr 30, 2007 at 09:34:38AM +0200, ext Frantisek Dufka wrote:
> >>> You mean, modify every single drawing X request in the X protocol so it
> >>> contains flags, meaning that we have to change
Hi,
Daniel Stone wrote:
>>> On Mon, Apr 30, 2007 at 09:34:38AM +0200, ext Frantisek Dufka wrote:
>>> You mean, modify every single drawing X request in the X protocol so it
>>> contains flags, meaning that we have to change every drawing-related
>>> function in -- on average -- ten (at least) plac
On Mon, Apr 30, 2007 at 11:26:29AM +0200, ext Frantisek Dufka wrote:
> Daniel Stone wrote:
> >>>On Mon, Apr 30, 2007 at 09:34:38AM +0200, ext Frantisek Dufka wrote:
> >>>You mean, modify every single drawing X request in the X protocol so it
> >>>contains flags, meaning that we have to change every
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Eero Tamminen wrote:
> Hi,
>
> ext Frantisek Dufka wrote:
>>> And if the game doesn't disable the double pixeling properly (e.g. if it
>>> crashes or freezes), user needs to reboot the device. Not very nice
>>> either...
>>>
>> So what happened
Daniel Stone wrote:
On Mon, Apr 30, 2007 at 09:34:38AM +0200, ext Frantisek Dufka wrote:
You mean, modify every single drawing X request in the X protocol so it
contains flags, meaning that we have to change every drawing-related
function in -- on average -- ten (at least) places in the server
co
On Mon, Apr 30, 2007 at 11:16:32AM +0300, Tapani Pälli wrote:
> Daniel Stone wrote:
> > On Mon, Apr 30, 2007 at 09:34:38AM +0200, ext Frantisek Dufka wrote:
> > You mean, modify every single drawing X request in the X protocol so it
> > contains flags, meaning that we have to change every drawing-r
Daniel Stone wrote:
> On Mon, Apr 30, 2007 at 09:34:38AM +0200, ext Frantisek Dufka wrote:
>
>> Eero Tamminen wrote:
>>
>>> And if the game doesn't disable the double pixeling properly (e.g. if it
>>> crashes or freezes), user needs to reboot the device. Not very nice
>>> either...
>>>
On Mon, Apr 30, 2007 at 09:34:38AM +0200, ext Frantisek Dufka wrote:
> Eero Tamminen wrote:
> >And if the game doesn't disable the double pixeling properly (e.g. if it
> >crashes or freezes), user needs to reboot the device. Not very nice
> >either...
>
> So what happened to idea mentioned here y
Hi,
ext Frantisek Dufka wrote:
>> And if the game doesn't disable the double pixeling properly (e.g. if it
>> crashes or freezes), user needs to reboot the device. Not very nice
>> either...
>>
>
> So what happened to idea mentioned here year ago to modify Xsp (or
> whatever) API so that pixel d
Daniel Stone wrote:
> On Mon, Apr 30, 2007 at 10:10:23AM +0300, ext Tapani Pälli wrote:
>
>> ext Arnim Sauerbier wrote:
>>
>>> Many of these are acceptably fast at 320x240 but too slow at 640x480 or
>>> 800x480. The problem is
>>> that some SDL applications do not maintain 2x doubling but
Eero Tamminen wrote:
And if the game doesn't disable the double pixeling properly (e.g. if it
crashes or freezes), user needs to reboot the device. Not very nice
either...
So what happened to idea mentioned here year ago to modify Xsp (or
whatever) API so that pixel doubling is flag of each
On Mon, Apr 30, 2007 at 10:23:37AM +0300, ext Eero Tamminen wrote:
> ext Tapani Pälli wrote:
> > Please note that pixeldoubler is very platform specific thing and for it
> > to work you have to touch the code, there's no way around it. Also, it's
> > not very 'official' feature for gaming (at least
Hi,
ext Tapani Pälli wrote:
> ext Arnim Sauerbier wrote:
>> Greetings again, Dear Maemo Developers,
>>
>> I am now porting several emulators and games to the Nokia 770, some of them
>> shown here:
>>
>> http://pupnik.de/software.html
>
> Ultima IV used to be one of my favourite RPG:s, very nice
On Mon, Apr 30, 2007 at 10:10:23AM +0300, ext Tapani Pälli wrote:
> ext Arnim Sauerbier wrote:
> > Many of these are acceptably fast at 320x240 but too slow at 640x480 or
> > 800x480. The problem is
> > that some SDL applications do not maintain 2x doubling but flicker to 1x
> > scaling - exampl
ext Arnim Sauerbier wrote:
> Greetings again, Dear Maemo Developers,
>
> I am now porting several emulators and games to the Nokia 770, some of them
> shown here:
>
> http://pupnik.de/software.html
>
>
Ultima IV used to be one of my favourite RPG:s, very nice :)
> Many of these are acceptably
Greetings again, Dear Maemo Developers,
I am now porting several emulators and games to the Nokia 770, some of them
shown here:
http://pupnik.de/software.html
Many of these are acceptably fast at 320x240 but too slow at 640x480 or
800x480. The problem is
that some SDL applications do not main
54 matches
Mail list logo
