Tapani Pälli wrote:
As for the manual vs automatic updates, that brings another question.
How often is the screen really updated? I saw in the kernel source
there is manual vs automatic update mode but which one is actualy
We are updating areas (dirty-rects), it would hog the memorybus if we
w
ext Frantisek Dufka wrote:
> Eero Tamminen wrote:
>> Hi,
>>
>>> Yes. So to draw without tearing effect either X of framebuffer driver
>>> should report when to draw (vblank period or which line is currently
>>> drawn by hardware)
>>
>> Another possibility is that (SDL) application could ask X serve
Eero Tamminen wrote:
Hi,
Yes. So to draw without tearing effect either X of framebuffer driver
should report when to draw (vblank period or which line is currently
drawn by hardware)
Another possibility is that (SDL) application could ask X server to
ask Framebuffer to flush the framebuffer c
I'm starting to build a set of applications that will turn one or more 770's
into control panels for all the lighting in my church's sanctuary, which as
of this last week are all on DMX-512 controlled dimmer packs. An Art-Net
(http://www.artisticlicence.com/dwnart.htm) to DMX-512 bridge will allo
Hi,
> Yes. So to draw without tearing effect either X of framebuffer driver
> should report when to draw (vblank period or which line is currently
> drawn by hardware)
Another possibility is that (SDL) application could ask X server to
ask Framebuffer to flush the framebuffer contents to the LCD
Tapani Pälli wrote:
I think there's no guarantee that you will get "HW surface" from SDL, it
will silently fallback to SW surface if it cannot have HW one.
SDL draws to X, X draws to the framebuffer mapped by kernel which then
updates that data to the lcd controller where screen gets finally
u
ext Frantisek Dufka wrote:
> Visti Andresen wrote:
>
>> My "flashingTest" reports that:
>> It got a hardware surface (I should be writing directly to "video
>> memory" accordingly to the SDL docs)
>> And the surface is double buffered.
>>
>> The size of the surface is 800x480 16 bit (R5G6B5)
>> So
Hi,
> im using "localhost", as it cant accept the display
> without it. there must be some workaound.
I had a bug about that in the Maemo bugzilla and it's
fixed in the newer SDK version.
Just remove the "exit" line after the "DISPLAY" check
in the af-sb-init.sh.
- Eero
__
Visti Andresen wrote:
My "flashingTest" reports that:
It got a hardware surface (I should be writing directly to "video memory"
accordingly to the SDL docs)
And the surface is double buffered.
The size of the surface is 800x480 16 bit (R5G6B5)
So there should be at least 1536000 bytes of video
My "flashingTest" reports that:
It got a hardware surface (I should be writing directly to "video memory"
accordingly to the SDL docs)
And the surface is double buffered.
Don't trust SDL, SDL is a liar. In X backend the SDL trusts what X says
so "HW surface" could mean actually "server si
On Mon, 29 May 2006 16:50:50 +0200
Frantisek Dufka <[EMAIL PROTECTED]> wrote:
> Juha Yrjölä wrote:
>
> > Unfortunately we don't provide user-space with the vsync information (or
> > "Tearing Effect" signal, as it's called in LCD land).
> >
> > If there's large enough need for this, we might con
>-Original Message-
>From: [EMAIL PROTECTED]
>Hi,
>Is there is any open source code available for Certificate
>manager application in maemo? If yes, from where in maemo
>repository can I download the source?
>I tried using apt-get, but it always throws error.
>
>Thanks & rgrds,
>shridevi
12 matches
Mail list logo
