I have been trying the virtual surfaces, It compiles :-).
However when I run I keep getting
.......
(>) [Main Thread 5.184] ( 515) NXP/STB22X/VIDEO: Entering
phStbDFB_TestRegion
() [Main Thread 5.185] ( 515) NXP/STB22X/VIDEO: Entering
phStbDFB_TestRegion
() [Main Thread 5.186] ( 515) NXP/STB22X/VIDEO: Entering
phStbDFB_TestRegion
( size 1280x720
(-) [Main Thread 5.551] ( 515) Core/Layers: -> format UYVY
(-) [Main Thread 5.551] ( 515) Core/Layers: -> surf caps
0x00000000
(-) [Main Thread 5.552] ( 515) Core/Layers: -> buffermode 1
(-) [Main Thread 5.552] ( 515) Core/Layers: -> options
0x00000021
(-) [Main Thread 5.552] ( 515) Core/Layers: -> source
0,0-1280x720
(-) [Main Thread 5.552] ( 515) Core/Layers: -> dest
0,0-720x576
(-) [Main Thread 5.552] ( 515) Core/Layers: -> opacity 255
(-) [Main Thread 5.552] ( 515) Core/Layers: -> src_key
000000 (index 0)
(-) [Main Thread 5.552] ( 515) Core/Layers: -> dst_key
000000 (index 0)
(-) [Main Thread 5.553] ( 515) Core/Layers: -> state
0x00000015
(-) [Main Thread 5.553] ( 515) Core/Layers: -> FROZEN!
(-) [Main Thread 5.553] ( 515) Core/WindowStack:
dfb_windowstack_resize( 0x45b0a0, 1280x720 )
(-) [Main Thread 5.553] ( 515) Core/WindowStack:
dfb_windowstack_repaint_all( 0x45b0a0 )
(-) [Main Thread 5.554] ( 515) Core/Layers: destroying region
0x45ac80 (Secondary Vid Layer [tmdlVss2], 1280x720, configured, enabled,
inactive, not realized)
(-) [Main Thread 5.554] ( 515) Core/Layers: destroying context
0x45a728 (Secondary Vid Layer [tmdlVss2], inactive)
(-) [Main Thread 5.554] ( 515) Core/Layers:
dfb_layer_remove_context (Secondary Vid Layer [tmdlVss2], 0x45a728)
(-) [Main Thread 5.554] ( 515) Core/WindowStack:
dfb_windowstack_destroy( 0x45a948 )
(!) [Main Thread 5.555] ( 515) *** Assumption [region->surface != NULL]
failed *** [layer_region.c:390 in dfb_layer_region_get_surface()]
I am struggling to see why region->surface is NULL. And If I look at what
calls this:
/* Lock the region. */
if (dfb_layer_region_lock( region ))
return DFB_FUSION;
I presume that this call makes sure that region->surface is ! NULL or fills it
in.
Any quick clues as to what i must have done or is this a virtual surface
issue.....
Cheers
Daniel Laird
Daniel Laird
[EMAIL PROTECTED]
----------------------------------------
> Date: Fri, 25 Jul 2008 18:19:44 +0200
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: directfb-dev@directfb.org
> Subject: Re: [directfb-dev] Virtual Surfaces for Video Layers in gfxdrivers
>
> Daniel Laird wrote:
>> On STB810 (pnx8950 based) and STB225 DFB1.0 we used virtual surfaces.
>> These had no associated memory but reported sizes etc and this was done by
>> using the allocate surface function for video layers:
>>
>> dfb_surface_create_preallocated(core, config->width, config->height,
>> config->format, CSP_SYSTEMONLY,
>> Caps, NULL, NULL, NULL, 0, 0, ret_surface);
>>
>> This AFAIK meant we had a surface but no memory attached.
>>
>> This allowed us to call GetSurface on a VideoLayer and then we used the
>> surface handle
>> to look up what video layer we really meant and make sure our decoder output
>> to that layer.
>> Also solved issues where our HW always has layer 0 = video. Whereas DFB has
>> Primary FB layer as 0
>>
>> I am now trying to move to DFB1.2 and did not like V1 of my DFB1.0 driver as
>> it relied on FBDev system.
>> So I used your rather nice davinci driver as a basis.
>> This also will make it Open and more supportable in the future.
>
> Great!
>
> Are you going to use devmem for the OSD and offscreen surfaces?
>
> I guess you're at least keeping the kernel module for acceleration.
>
>> However I now want to handle virtual surfaces and this is a difference to
>> the davinci.
>
> Well, you can still do the same and simply set lock.addr to NULL or at least
> allocate on dummy line
> and set lock.pitch to 0 :)
>
>> I am happy passing a NULL surface to PlayTo but I have no way of getting the
>> Source etc as you indicated above. This means I have
>> no easy way of specifiying which of the 2 video layers I am rendering to. I
>> could hack the ctx parameter but this is a dirty hack.
>
> True, the virtual surface is a nicer solution, at least for DirectFB 1.x...
>
>> Should PlayTo be modified to take either a surface or a Layer?
>
> I'm planning to change the API anyhow, moving away from the strong
> layer-surface binding,
> allowing to call something like IDirectFBDisplayLayer::SetSurface() or even
> more advanced.
>
> This will also allow showing one surface on different layers,
> allowing different positioning and scaling on different screens.
>
>> Could we move CreateVideoProvider from top level interface to Surface/Layer
>> so that either can create a VideoProvider.
>> i.e DisplayLayer->CreateVideoProvider and Surface->CreateVideoProvider.
>> The Video Provider could then be passed the 'parent' creator in the
>> Construct call and then we would be able to handle both Layer or Surface.
>>
>> I am looking for some advice and am happy to try things out as we try to
>> make a better version of the DFB1.2 driver.
>
> Let's keep the virtual surfaces with 1.2 and do heavier changes in 1.3
> (->1.4) or better in 1.5 (->2.0).
>
> Those changes would better match the virtual surfaces anyhow :)
>
> --
> Best regards,
> Denis Oliver Kropp
>
> .------------------------------------------.
> | DirectFB - Hardware accelerated graphics |
> | http://www.directfb.org/ |
> "------------------------------------------"
>
> _______________________________________________
> directfb-dev mailing list
> directfb-dev@directfb.org
> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
_________________________________________________________________
100’s of Nikon cameras to be won with Live Search
http://clk.atdmt.com/UKM/go/101719808/direct/01/
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
