From timothy.strelchun at intel.com Mon Mar 1 01:54:54 2010 From: timothy.strelchun at intel.com (Strelchun, Timothy) Date: Sun, 28 Feb 2010 16:54:54 -0800 Subject: [directfb-dev] CoreSurfaceAccessorID intent and region_buffer_lock Message-ID: <29F4ED941D916B48B88B4D2A4F3D1B9C8B7E6496@orsmsx509.amr.corp.intel.com> Hi guys, I would like to confirm what the actual long-term design intent of the CoreSurfaceAccessorIDs are. It appears that they now allow surface pools to report what specific display layer(s) they support and support associated querying/negotiation tasks, as well as for other potential special purposes (accelerators, DMA memory transfer related usage?). But, I do not see much coverage of the topic. If so, it seems a step forward in reporting capabilities, but for layers does add some uncertainty... How should CSAID_LAYERx flags be interpreted by a surface buffer pool's lock function? As GPU or CPU? Previously, they received this information (set based on if it had DSCAPS_SYSTEMONLY set or not) and our custom DFB 1.2 display layer surface buffer pool lock would perform extra logic if the CPU was subsequently going to access the buffer memory (for reading and/or writing). Exactly when are the CSAID_LAYERx flags allowed/planned to be used/specified in a call to dfb_surface_buffer_lock? Currently, this only appears to be done when a display layer is configured or flipped (the entire surface using standard flipping not blit flipping). Also, I am curious what it means if a surface pool reports CSAID_ACCELx. Thanks, Timothy -- Timothy Strelchun CE Software Engineering Digital Home Group Intel Corporation The views expressed above are my own and not those of Intel From strikosn at gmail.com Mon Mar 1 16:22:55 2010 From: strikosn at gmail.com (nccc) Date: Mon, 1 Mar 2010 07:22:55 -0800 (PST) Subject: [directfb-dev] Segmentation fault in DirectFB core Message-ID: <27744931.post@talk.nabble.com> Hi, I have run into a segmentation fault while testing some demos from Qt 4.6.1, compiled with DirectFB support. I am using version 1.4.2, but 1.4.3 did not make a change either. Specifically, the problem appears in some accelerated rectangle fills, and more precisely when I move the pointer over the main menu of the Qt application. I am posting below the last portion of DirectFB debug output. Do you think this is a bug in DirectFB or QT? With regards, Strikos Nick Debug output: (-) [Main Thread 942.836] ( 98) Core/GraphicsOps: dfb_gfxcard_fillrectangles( 0x1eb2ec [1], 0x1eb354 ) (-) [Main Thread 942.839] ( 98) Core/GraphicsOps: dfb_gfxcard_state_check( 0x1eb354, 0x00000001 ) [0,0 - 28,16] (-) [Main Thread 942.842] ( 98) Core/GfxState: dfb_gfxcard_state_check( 0x1eb354, 0x00000001 ) drawing -> 0x1eafa8 (-) [Main Thread 943.939] ( 98) Core/GfxState: <- checked 0x00000000, accel 0x00000000, modified 0x00033fff, mod_hw 0x00000000 (-) [Main Thread 943.942] ( 98) Core/GfxState: -> checked 0x00000000, accel 0x00000000, modified 0x00033fff, mod_hw 0x00000000 (-) [Main Thread 943.945] ( 98) Core/GfxState: -> checked 0x00000007, accel 0x00000007, modified 0x00033fff, mod_hw 0x00000000 (-) [Main Thread 943.948] ( 98) Core/GfxState: => checked 0x00000007, accel 0x00000007, modified 0x00000000, mod_hw 0x00033fff (-) [Main Thread 943.951] ( 98) Core/GfxState: dfb_gfxcard_state_acquire( 0x1eb354, 0x00000001 ) drawing -> 0x1eafa8 (-) [Main Thread 943.954] ( 98) Core/SurfBuffer: dfb_surface_buffer_lock( 0x1e5658, 0x02, 0x1eb400 ) <- 29x17 ARGB [0] (-) [Main Thread 943.957] ( 98) Core/SurfBuffer: -> GPU WRITE (-) [Main Thread 943.959] ( 98) Core/SurfacePool: dfb_surface_pools_allocate( 0x1e5658, 0x2 ) (-) [Main Thread 943.961] ( 98) Core/SurfacePool: -> 29x17 ARGB - PRIVATE (-) [Main Thread 943.964] ( 98) Core/SurfacePool: dfb_surface_pools_negotiate( 0x1e5658 [ARGB], 0x02, 0x02, max 4 ) (-) [Main Thread 943.967] ( 98) Core/SurfacePool: -> 0x02 0x000 required (-) [Main Thread 943.969] ( 98) Core/SurfacePool: -> [3] 0x03 0x21f (0) [Frame Buffer Memory] (-) [Main Thread 943.972] ( 98) FBDev/Surfaces: fbdevTestConfig( 0x1e5658 ) (-) [Main Thread 943.975] ( 98) SurfaceManager: dfb_surfacemanager_allocate( 0x1e5658 ) <- 29x17 ARGB (-) [Main Thread 943.977] ( 98) SurfaceManager: -> pitch 116, length 1988, available 6467584 (-) [Main Thread 943.980] ( 98) FBDev/Surfaces: -> OK (-) [Main Thread 943.982] ( 98) Core/SurfacePool: => OK (-) [Main Thread 943.984] ( 98) Core/SurfacePool: => 1 pools available (-) [Main Thread 943.987] ( 98) Core/SurfacePool: => 0 pools out of memory (-) [Main Thread 943.989] ( 98) Core/SurfacePool: dfb_surface_pool_allocate( 0x73898 [3], 0x1e5658 ) (-) [Main Thread 943.992] ( 98) FBDev/Surfaces: fbdevAllocateBuffer( 0x1e5658 ) (-) [Main Thread 943.995] ( 98) SurfaceManager: dfb_surfacemanager_allocate( 0x1e5658 ) <- 29x17 ARGB (-) [Main Thread 943.997] ( 98) SurfaceManager: -> pitch 116, length 1988, available 6467584 (-) [Main Thread 944.000] ( 98) SurfaceManager: -> found free (3317370) (-) [Main Thread 944.002] ( 98) SurfaceManager: occupy_chunk( 1988 bytes at offset 4851382 ) (-) [Main Thread 944.004] ( 98) SurfaceManager: -> occupied 1988, available 6467584 (-) [Main Thread 944.007] ( 98) Core/SurfacePool: -> 0x1619a0 (-) [Main Thread 944.009] ( 98) Core/SurfacePool: -> 0x1619a0 (-) [Main Thread 944.011] ( 98) Core/SurfBuffer: dfb_surface_allocation_update() (-) [Main Thread 944.014] ( 98) Core/SurfBuffer: -> increasing serial... (-) [Main Thread 944.016] ( 98) Core/SurfPoolLock: dfb_surface_pool_lock( 0x73898 [3], 0x1619a0 ) (-) [Main Thread 944.019] ( 98) FBDev/SurfLock: fbdevLock( 0x1e5658 ) (-) [Main Thread 944.021] ( 98) FBDev/SurfLock: -> offset 4851382, pitch 116, addr 0x519786b6, phys 0x734a06b6 (-) [Main Thread 944.024] ( 98) Core/SurfBuffer: -> locked 1x now (-) [Main Thread 944.027] ( 98) Core/GfxState: -> switch from 0x1e524c [1] to 0x1eb354 [1] (-) [Main Thread 944.029] ( 98) Core/GfxState: -> mod_hw 0x00033fff, modified 0x00000000 (-) [Main Thread 944.032] ( 98) Core/GfxState: -> mod_hw 0x00033fff, set 0x00000000 (-) [Main Thread 944.034] ( 98) Core/GfxState: => mod_hw 0x00000000, set 0x00000007 (-) [Main Thread 944.037] ( 98) Core/SurfBuffer: dfb_surface_buffer_unlock( 0x1eb400 ) (-) [Main Thread 944.039] ( 98) Core/SurfPoolLock: dfb_surface_pool_unlock( 0x73898 [3], 0x1619a0 ) (-) [Main Thread 944.042] ( 98) FBDev/SurfLock: fbdevUnlock( 0x1e5658 ) (-) [Main Thread 944.048] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.145] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.148] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.151] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.153] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.158] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.160] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.163] ( 98) IDirectFBSurface: IDirectFBSurface_SetPorterDuff( 0x1eb1b8, 3 ) (-) [Main Thread 945.165] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.168] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.170] ( 98) IDirectFBSurface: IDirectFBSurface_SetClip( 0x1eb1b8, 0xef933610 ) (-) [Main Thread 945.173] ( 98) IDirectFBSurface: <- 0, 0- 29x 17 (-) [Main Thread 945.176] ( 98) IDirectFBSurface: -> 0, 0- 29x 17 (-) [Main Thread 945.178] ( 98) IDirectFBSurface: => CLIP 0, 0- 29x 17 (-) [Main Thread 945.181] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.184] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.188] ( 98) IDirectFBSurface: IDirectFBSurface_Lock( 0x1eb1b8 ) (-) [Main Thread 945.191] ( 98) Core/SurfBuffer: dfb_surface_buffer_lock( 0x1e5658, 0x03, 0x1eb328 ) <- 29x17 ARGB [0] (-) [Main Thread 945.194] ( 98) Core/SurfBuffer: -> CPU READWRITE (-) [Main Thread 945.196] ( 98) Core/SurfBuffer: dfb_surface_allocation_update() (-) [Main Thread 945.199] ( 98) Core/SurfBuffer: -> increasing serial... (-) [Main Thread 945.201] ( 98) Core/SurfPoolLock: dfb_surface_pool_lock( 0x73898 [3], 0x1619a0 ) (-) [Main Thread 945.203] ( 98) FBDev/SurfLock: fbdevLock( 0x1e5658 ) (-) [Main Thread 945.205] ( 98) FBDev/SurfLock: -> offset 4851382, pitch 116, addr 0x519786b6, phys 0x734a06b6 (-) [Main Thread 945.208] ( 98) Core/SurfBuffer: -> locked 1x now (-) [Main Thread 945.210] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.213] ( 98) IDirectFBSurface: IDirectFBSurface_GetPixelFormat( 0x1eb1b8 ) (-) [Main Thread 945.216] ( 98) IDirectFBSurface: IDirectFBSurface_GetCapabilities( 0x1eb1b8 ) (-) [Main Thread 945.219] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.222] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (!) [ 98: 945.229] --> Caught signal 10 (unknown origin) <-- ----- Strikos Nick Think Silicon Ltd http://www.think-silicon.com http://www.think-silicon.com -- View this message in context: http://old.nabble.com/Segmentation-fault-in-DirectFB-core-tp27744931p27744931.html Sent from the DirectFB Dev mailing list archive at Nabble.com. From anders.bakken at nokia.com Tue Mar 2 01:16:00 2010 From: anders.bakken at nokia.com (Anders Bakken) Date: Mon, 1 Mar 2010 16:16:00 -0800 Subject: [directfb-dev] single buffered windows Message-ID: <20100302001600.GW14935@nokia.com> I have two questions about IDirectFBWindows. If I have a single buffered window do I still need to call Flip() to make changes visible (I would expect not) How can I make single buffered windows? They seem to be double-buffered no matter what I do. Is this related to some layer configuration setting? (I am testing this with system=X11) regards -- Qt Development Frameworks, Nokia, http://qt.nokia.com Anders Bakken From jthou at c2micro.com Tue Mar 2 07:20:54 2010 From: jthou at c2micro.com (jthou) Date: Tue, 2 Mar 2010 14:20:54 +0800 Subject: [directfb-dev] (no subject) Message-ID: <2C9A630F1C474FF3A41FE8F0C1DF4526@c2microjthou> Hi, Denis and Niels, Could you help me on these questions? 1, What kind of Graphics standards are supported by DirectFB? GKS? PHIGS? or some thing else? Is there a spec to conference? 2, Does DirectFB support 3-D ? 3, What's the difference of DirectFB 1.2.10, DirectFB 1.4.3, SaWMan 1.4.3? I see them are list on same level in the website. 4, I'm working on version 1.2.6. Do I need to update it to 1.2.10 or 1.4.3? Thank you very much. -Justin -------------- next part -------------- An HTML attachment was scrubbed... URL: From niels at directfb.org Tue Mar 2 12:08:50 2010 From: niels at directfb.org (Niels Roest) Date: Tue, 02 Mar 2010 14:08:50 +0300 Subject: [directfb-dev] SaWMan: layer buffermode reconfiguration ? In-Reply-To: <4d28d4b51002250938w59400e9ev55f6de35d7744365@mail.gmail.com> References: <4d28d4b51002250938w59400e9ev55f6de35d7744365@mail.gmail.com> Message-ID: <4B8CF1C2.4060508@directfb.org> Hi Lionel, I have not looked in close detail, but SaWMan has an optimization to align the layer to the window if only one window is displayed - this holds for size and location. I think you are hitting this, but I don't know why it would go from double to single bufferend in that case. The switching behaviour can be prevented by having the SaWMan callback layer_reconfig() disallowing all changes (not returning DFB_OK). Greets Niels Lionel Landwerlin wrote: > Hi all, > > I'm playing a little bit with SaWMan these days, and I noticed a > strange flicking effect. > Here is my setup : > - a 1280x720 layer double buffered at start > - a 1280x720 window containing a main application > - 2/3 300x200 windows acting as widgets on top of the main application window > > When I destroy the 300x200 windows, and then I recreate one of them, > I'm noticing a > flickering effect of the whole screen. With a few investigation I > found that at this moment, > SaWMan reconfigure the layer to change its buffermode from double > buffered to single > buffered. > > Any explanation ? > > Regards, > > -- > Lionel Landwerlin > _______________________________________________ > directfb-dev mailing list > directfb-dev at directfb.org > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > > -- .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" From llandwerlin at gmail.com Tue Mar 2 14:58:03 2010 From: llandwerlin at gmail.com (Lionel Landwerlin) Date: Tue, 2 Mar 2010 14:58:03 +0100 Subject: [directfb-dev] SaWMan: layer buffermode reconfiguration ? In-Reply-To: <4B8CF1C2.4060508@directfb.org> References: <4d28d4b51002250938w59400e9ev55f6de35d7744365@mail.gmail.com> <4B8CF1C2.4060508@directfb.org> Message-ID: <4d28d4b51003020558o56449b48id8385ecd715218c5@mail.gmail.com> Hi Niels, thanks for the trick. After a few more investigation, I just patched SaWMan to avoid it to change the buffermode of the layer. Maybe this should be an option to use this optimization... My framebuffer driver might be buggy to not be able to change the layer mode without flicking... I don't know. I also would like to add that I have seen some unrefreshed screen zone when using windows and moving+scaling them over the screen. Are you aware of such bugs in SaWMan (also seen it in the default window manager) ? Regards, -- Lionel Landwerlin On Tue, Mar 2, 2010 at 12:08 PM, Niels Roest wrote: > Hi Lionel, > I have not looked in close detail, but SaWMan has an optimization to align > the layer to the window if only one window is displayed - this holds for > size and location. I think you are hitting this, but I don't know why it > would go from double to single bufferend in that case. > The switching behaviour can be prevented by having the SaWMan callback > layer_reconfig() disallowing all changes (not returning DFB_OK). > > Greets > Niels > > Lionel Landwerlin wrote: >> >> Hi all, >> >> I'm playing a little bit with SaWMan these days, and I noticed a >> strange flicking effect. >> Here is my setup : >> ?- a 1280x720 layer double buffered at start >> ?- a 1280x720 window containing a main application >> ?- 2/3 300x200 windows acting as widgets on top of the main application >> window >> >> When I destroy the 300x200 windows, and then I recreate one of them, >> I'm noticing a >> flickering effect of the whole screen. With a few investigation I >> found that at this moment, >> SaWMan reconfigure the layer to change its buffermode from double >> buffered to single >> buffered. >> >> Any explanation ? >> >> Regards, >> >> -- >> Lionel Landwerlin >> _______________________________________________ >> directfb-dev mailing list >> directfb-dev at directfb.org >> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev >> >> > > > -- > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ ? ? ? ? ? ? ? ? | > "------------------------------------------" > From niels at directfb.org Tue Mar 2 14:21:29 2010 From: niels at directfb.org (Niels Roest) Date: Tue, 02 Mar 2010 16:21:29 +0300 Subject: [directfb-dev] SaWMan: layer buffermode reconfiguration ? In-Reply-To: <4d28d4b51003020558o56449b48id8385ecd715218c5@mail.gmail.com> References: <4d28d4b51002250938w59400e9ev55f6de35d7744365@mail.gmail.com> <4B8CF1C2.4060508@directfb.org> <4d28d4b51003020558o56449b48id8385ecd715218c5@mail.gmail.com> Message-ID: <4B8D10D9.2070000@directfb.org> It sounds as if such an option would be useful for you. The unrefreshed zone sounds a bit scary. In principle is the screen redraw governed by the window manager, so you seeing similar behaviour for SaWMan and "default" is a bit unexpected. For SaWMan I can add that if you use the Window Manager callbacks you may need to add an update kick to redraw since SaWMan buffers the requests - however, the default WM does not have such a scheme. I have never seen an issue as you describe. If you have a workable scenario to reproduce the issue I can have a look. Greets Niels Lionel Landwerlin wrote: > Hi Niels, > > thanks for the trick. After a few more investigation, I just patched > SaWMan to avoid it to change the buffermode of the layer. > Maybe this should be an option to use this optimization... My > framebuffer driver might be buggy to not be able to change the layer > mode without flicking... I don't know. > I also would like to add that I have seen some unrefreshed screen zone > when using windows and moving+scaling them over the screen. Are you > aware of such bugs in SaWMan (also seen it in the default window > manager) ? > > Regards, > > -- > Lionel Landwerlin > > On Tue, Mar 2, 2010 at 12:08 PM, Niels Roest wrote: > >> Hi Lionel, >> I have not looked in close detail, but SaWMan has an optimization to align >> the layer to the window if only one window is displayed - this holds for >> size and location. I think you are hitting this, but I don't know why it >> would go from double to single bufferend in that case. >> The switching behaviour can be prevented by having the SaWMan callback >> layer_reconfig() disallowing all changes (not returning DFB_OK). >> >> Greets >> Niels >> >> Lionel Landwerlin wrote: >> >>> Hi all, >>> >>> I'm playing a little bit with SaWMan these days, and I noticed a >>> strange flicking effect. >>> Here is my setup : >>> - a 1280x720 layer double buffered at start >>> - a 1280x720 window containing a main application >>> - 2/3 300x200 windows acting as widgets on top of the main application >>> window >>> >>> When I destroy the 300x200 windows, and then I recreate one of them, >>> I'm noticing a >>> flickering effect of the whole screen. With a few investigation I >>> found that at this moment, >>> SaWMan reconfigure the layer to change its buffermode from double >>> buffered to single >>> buffered. >>> >>> Any explanation ? >>> >>> Regards, >>> >>> -- >>> Lionel Landwerlin >>> _______________________________________________ >>> directfb-dev mailing list >>> directfb-dev at directfb.org >>> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev >>> >>> >>> >> -- >> >> .------------------------------------------. >> | DirectFB - Hardware accelerated graphics | >> | http://www.directfb.org/ | >> "------------------------------------------" >> >> > > -- .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" From timothy.strelchun at intel.com Tue Mar 2 19:21:18 2010 From: timothy.strelchun at intel.com (Strelchun, Timothy) Date: Tue, 2 Mar 2010 10:21:18 -0800 Subject: [directfb-dev] [PATCH] Fix skirmish used in single DFB app usage mode Message-ID: <29F4ED941D916B48B88B4D2A4F3D1B9C8B7E70E9@orsmsx509.amr.corp.intel.com> Attached is a patch for DFB 1.4.3 to fix a single DFB application usage model memory corruption defect in fusion_skirmish_init. This occurred previously when it called strcpy due to the name string buffer pointer being incorrectly calculated. This injection was introduced 2010.12.08 as part of git commit 91afed9692ff15ffc7d2b6221aa5cd061ff44fa9. I discovered it after investigating why our system driver (which is being transitioned to DFB 1.4.3 from 1.2.10) was encountering memory and freeing related errors. It turned out the systems driver used several skirmishes (some with long names such as 32 characters long), and at last one structure had a skirmish with various other pointers stored after it that were corrupted by the skirmish overwriting them when it tried to make a copy of the skirmish name. Regards, Timothy -- Timothy Strelchun CE Software Engineering Digital Home Group Intel Corporation The views expressed above are my own and not those of Intel -------------- next part -------------- A non-text attachment was scrubbed... Name: DirectFB-1.4.3_FixSingleAppSkirmish.patch Type: application/octet-stream Size: 495 bytes Desc: DirectFB-1.4.3_FixSingleAppSkirmish.patch URL: From strikosn at gmail.com Wed Mar 3 18:17:26 2010 From: strikosn at gmail.com (nccc) Date: Wed, 3 Mar 2010 09:17:26 -0800 (PST) Subject: [directfb-dev] Strange behaviour on Blit Message-ID: <27770974.post@talk.nabble.com> Hi, While running some tests, I noticed that DirectFB blits incorrectly a rotated, source colorkeyed image. I am using versions 1.4.2 and 1.4.3, and the problem can be seen if one adds DSBLIT_ROTATE* in df_dok example's source colorkey demo. In some cases the image is rendered mirrored in the X axis, in others only a single line appears. Can you reproduce this behaviour? Regards ----- Strikos Nick Think Silicon Ltd http://www.think-silicon.com http://www.think-silicon.com -- View this message in context: http://old.nabble.com/Strange-behaviour-on-Blit-tp27770974p27770974.html Sent from the DirectFB Dev mailing list archive at Nabble.com. From brian at cranksoftware.com Thu Mar 4 02:21:51 2010 From: brian at cranksoftware.com (Brian Edmond) Date: Wed, 3 Mar 2010 20:21:51 -0500 Subject: [directfb-dev] Layer panning Message-ID: <012e01cabb39$130f72f0$392e58d0$@com> Hi, I am wondering how I would pan the source viewport of a Layer? On some hardware systems you can create a surface for a layer which is larger than the actual layer destination viewport. You can then view different areas of the source by setting a source viewport. I do not see a way in the DirectFB Layer API to change the surface area which is visible. Is there a way to do this? For example the screen is 640x480 and I would like to create a surface which is 1280x480 and then pan it using the hardware and not blits. Thanks, Brian Brian Edmond Crank Software Inc. Office: 613-595-1999 Mobile: 613-796-1320 Online: www.cranksoftware.com Check out: Crank Software's Blog -------------- next part -------------- An HTML attachment was scrubbed... URL: From strikosn at gmail.com Thu Mar 4 07:35:15 2010 From: strikosn at gmail.com (Strikos Nick) Date: Thu, 4 Mar 2010 08:35:15 +0200 Subject: [directfb-dev] Segmentation fault in DirectFB core Message-ID: <23406c481003032235i5ed933fblb866bc3af986ba61@mail.gmail.com> Hi, I have run into a segmentation fault while testing some demos from Qt 4.6.1, compiled with DirectFB support. I am using version 1.4.2, but 1.4.3 did not make a change either. Specifically, the problem appears in some accelerated rectangle fills, and more precisely when I move the pointer over the main menu of the Qt application. I am posting below the last portion of DirectFB debug output. Do you think this is a bug in DirectFB or QT? With regards, Strikos Nick Think Silicon Ltd http://www.think-silicon.com Debug output: (-) [Main Thread 942.836] ( 98) Core/GraphicsOps: dfb_gfxcard_fillrectangles( 0x1eb2ec [1], 0x1eb354 ) (-) [Main Thread 942.839] ( 98) Core/GraphicsOps: dfb_gfxcard_state_check( 0x1eb354, 0x00000001 ) [0,0 - 28,16] (-) [Main Thread 942.842] ( 98) Core/GfxState: dfb_gfxcard_state_check( 0x1eb354, 0x00000001 ) drawing -> 0x1eafa8 (-) [Main Thread 943.939] ( 98) Core/GfxState: <- checked 0x00000000, accel 0x00000000, modified 0x00033fff, mod_hw 0x00000000 (-) [Main Thread 943.942] ( 98) Core/GfxState: -> checked 0x00000000, accel 0x00000000, modified 0x00033fff, mod_hw 0x00000000 (-) [Main Thread 943.945] ( 98) Core/GfxState: -> checked 0x00000007, accel 0x00000007, modified 0x00033fff, mod_hw 0x00000000 (-) [Main Thread 943.948] ( 98) Core/GfxState: => checked 0x00000007, accel 0x00000007, modified 0x00000000, mod_hw 0x00033fff (-) [Main Thread 943.951] ( 98) Core/GfxState: dfb_gfxcard_state_acquire( 0x1eb354, 0x00000001 ) drawing -> 0x1eafa8 (-) [Main Thread 943.954] ( 98) Core/SurfBuffer: dfb_surface_buffer_lock( 0x1e5658, 0x02, 0x1eb400 ) <- 29x17 ARGB [0] (-) [Main Thread 943.957] ( 98) Core/SurfBuffer: -> GPU WRITE (-) [Main Thread 943.959] ( 98) Core/SurfacePool: dfb_surface_pools_allocate( 0x1e5658, 0x2 ) (-) [Main Thread 943.961] ( 98) Core/SurfacePool: -> 29x17 ARGB - PRIVATE (-) [Main Thread 943.964] ( 98) Core/SurfacePool: dfb_surface_pools_negotiate( 0x1e5658 [ARGB], 0x02, 0x02, max 4 ) (-) [Main Thread 943.967] ( 98) Core/SurfacePool: -> 0x02 0x000 required (-) [Main Thread 943.969] ( 98) Core/SurfacePool: -> [3] 0x03 0x21f (0) [Frame Buffer Memory] (-) [Main Thread 943.972] ( 98) FBDev/Surfaces: fbdevTestConfig( 0x1e5658 ) (-) [Main Thread 943.975] ( 98) SurfaceManager: dfb_surfacemanager_allocate( 0x1e5658 ) <- 29x17 ARGB (-) [Main Thread 943.977] ( 98) SurfaceManager: -> pitch 116, length 1988, available 6467584 (-) [Main Thread 943.980] ( 98) FBDev/Surfaces: -> OK (-) [Main Thread 943.982] ( 98) Core/SurfacePool: => OK (-) [Main Thread 943.984] ( 98) Core/SurfacePool: => 1 pools available (-) [Main Thread 943.987] ( 98) Core/SurfacePool: => 0 pools out of memory (-) [Main Thread 943.989] ( 98) Core/SurfacePool: dfb_surface_pool_allocate( 0x73898 [3], 0x1e5658 ) (-) [Main Thread 943.992] ( 98) FBDev/Surfaces: fbdevAllocateBuffer( 0x1e5658 ) (-) [Main Thread 943.995] ( 98) SurfaceManager: dfb_surfacemanager_allocate( 0x1e5658 ) <- 29x17 ARGB (-) [Main Thread 943.997] ( 98) SurfaceManager: -> pitch 116, length 1988, available 6467584 (-) [Main Thread 944.000] ( 98) SurfaceManager: -> found free (3317370) (-) [Main Thread 944.002] ( 98) SurfaceManager: occupy_chunk( 1988 bytes at offset 4851382 ) (-) [Main Thread 944.004] ( 98) SurfaceManager: -> occupied 1988, available 6467584 (-) [Main Thread 944.007] ( 98) Core/SurfacePool: -> 0x1619a0 (-) [Main Thread 944.009] ( 98) Core/SurfacePool: -> 0x1619a0 (-) [Main Thread 944.011] ( 98) Core/SurfBuffer: dfb_surface_allocation_update() (-) [Main Thread 944.014] ( 98) Core/SurfBuffer: -> increasing serial... (-) [Main Thread 944.016] ( 98) Core/SurfPoolLock: dfb_surface_pool_lock( 0x73898 [3], 0x1619a0 ) (-) [Main Thread 944.019] ( 98) FBDev/SurfLock: fbdevLock( 0x1e5658 ) (-) [Main Thread 944.021] ( 98) FBDev/SurfLock: -> offset 4851382, pitch 116, addr 0x519786b6, phys 0x734a06b6 (-) [Main Thread 944.024] ( 98) Core/SurfBuffer: -> locked 1x now (-) [Main Thread 944.027] ( 98) Core/GfxState: -> switch from 0x1e524c [1] to 0x1eb354 [1] (-) [Main Thread 944.029] ( 98) Core/GfxState: -> mod_hw 0x00033fff, modified 0x00000000 (-) [Main Thread 944.032] ( 98) Core/GfxState: -> mod_hw 0x00033fff, set 0x00000000 (-) [Main Thread 944.034] ( 98) Core/GfxState: => mod_hw 0x00000000, set 0x00000007 (-) [Main Thread 944.037] ( 98) Core/SurfBuffer: dfb_surface_buffer_unlock( 0x1eb400 ) (-) [Main Thread 944.039] ( 98) Core/SurfPoolLock: dfb_surface_pool_unlock( 0x73898 [3], 0x1619a0 ) (-) [Main Thread 944.042] ( 98) FBDev/SurfLock: fbdevUnlock( 0x1e5658 ) (-) [Main Thread 944.048] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.145] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.148] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.151] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.153] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.158] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.160] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.163] ( 98) IDirectFBSurface: IDirectFBSurface_SetPorterDuff( 0x1eb1b8, 3 ) (-) [Main Thread 945.165] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.168] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.170] ( 98) IDirectFBSurface: IDirectFBSurface_SetClip( 0x1eb1b8, 0xef933610 ) (-) [Main Thread 945.173] ( 98) IDirectFBSurface: <- 0, 0- 29x 17 (-) [Main Thread 945.176] ( 98) IDirectFBSurface: -> 0, 0- 29x 17 (-) [Main Thread 945.178] ( 98) IDirectFBSurface: => CLIP 0, 0- 29x 17 (-) [Main Thread 945.181] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.184] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.188] ( 98) IDirectFBSurface: IDirectFBSurface_Lock( 0x1eb1b8 ) (-) [Main Thread 945.191] ( 98) Core/SurfBuffer: dfb_surface_buffer_lock( 0x1e5658, 0x03, 0x1eb328 ) <- 29x17 ARGB [0] (-) [Main Thread 945.194] ( 98) Core/SurfBuffer: -> CPU READWRITE (-) [Main Thread 945.196] ( 98) Core/SurfBuffer: dfb_surface_allocation_update() (-) [Main Thread 945.199] ( 98) Core/SurfBuffer: -> increasing serial... (-) [Main Thread 945.201] ( 98) Core/SurfPoolLock: dfb_surface_pool_lock( 0x73898 [3], 0x1619a0 ) (-) [Main Thread 945.203] ( 98) FBDev/SurfLock: fbdevLock( 0x1e5658 ) (-) [Main Thread 945.205] ( 98) FBDev/SurfLock: -> offset 4851382, pitch 116, addr 0x519786b6, phys 0x734a06b6 (-) [Main Thread 945.208] ( 98) Core/SurfBuffer: -> locked 1x now (-) [Main Thread 945.210] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.213] ( 98) IDirectFBSurface: IDirectFBSurface_GetPixelFormat( 0x1eb1b8 ) (-) [Main Thread 945.216] ( 98) IDirectFBSurface: IDirectFBSurface_GetCapabilities( 0x1eb1b8 ) (-) [Main Thread 945.219] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (-) [Main Thread 945.222] ( 98) IDirectFBSurface: IDirectFBSurface_GetSize( 0x1eb1b8 ) (!) [ 98: 945.229] --> Caught signal 10 (unknown origin) <-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From strikosn at gmail.com Thu Mar 4 07:37:10 2010 From: strikosn at gmail.com (Strikos Nick) Date: Thu, 4 Mar 2010 08:37:10 +0200 Subject: [directfb-dev] Strange behaviour on Blit Message-ID: <23406c481003032237o793d9f4rcf61b4d8507b1c60@mail.gmail.com> Hi, While running some tests, I noticed that DirectFB blits incorrectly a rotated, source colorkeyed image. I am using versions 1.4.2 and 1.4.3, and the problem can be seen if one adds DSBLIT_ROTATE* in df_dok example's source colorkey demo. In some cases the image is rendered mirrored in the X axis, in others only a single line appears. Can you reproduce this behaviour? Regards, Strikos Nick Think Silicon Ltd http://www.think-silicon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From strikosn at gmail.com Thu Mar 4 16:03:24 2010 From: strikosn at gmail.com (Strikos Nick) Date: Thu, 4 Mar 2010 17:03:24 +0200 Subject: [directfb-dev] No state update for DrawString Message-ID: <23406c481003040703n5f527f56ideacebdf6312f83b@mail.gmail.com> Hi, I am developing a graphics driver and have run into a situation where DirectFB does not call SetState with SMF_SOURCE bit in state->mod_hw set, even though it should, I think. The following steps should reproduce this behaviour: 1) Blit a YUV image 2) Draw a rectangle 3) Draw a string The string will fail to render correctly because DirectFB does not instruct the driver to update the source format, which has been set earlier to e.g. DSPF_YUY2. By the way, either the enums in DFBSurfacePixelFormat or their descriptions must be wrong, because the comment above DSPF_YUY2 actually describes DSPF_UYVY and vice versa... Regards, Strikos Nick Think Silicon Ltd http://www.think-silicon.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From timothy.strelchun at intel.com Tue Mar 9 00:56:39 2010 From: timothy.strelchun at intel.com (Strelchun, Timothy) Date: Mon, 8 Mar 2010 15:56:39 -0800 Subject: [directfb-dev] [PATCH] Fix RGB24, Fix LUT8, add DSPF_A1_LSB and add DSPF_LUT8 dest color key blitting Message-ID: <29F4ED941D916B48B88B4D2A4F3D1B9C8B9D04D0@orsmsx509.amr.corp.intel.com> Attached is a patch for DFB 1.4.3 that with some fixes and additions. It: 1. Fixed a little endian DSPF_RGB24 byte ordering defect injected 2009.11.06 as part of git commit 0fdf41ff34ed403367d0eb05edc793b15a940860. Previously, the red and blue pixels were reversed. 2. Fixed a DSPF_LUT8 handling defect also injected 2009.11.06 as part of git commit 0fdf41ff34ed403367d0eb05edc793b15a940860. Previously, DSPF_LUT8 was being treated incorrectly as a YUV pixel format. 3. Added pixel format DSPF_A1_LSB that uses the LEAST significant bit first for pixels, because the existing DSPF_A1 format is MSB first. The VDC unit on the Intel(R) CE Media Processors use this for one of the various formats on its many display layers. The DFB software rasterizer functionality provided is almost the same as that already provided for existing DSPF_A1 format. 4. Added a function to support LUT8 to LUT8 blitting with destination color key enabled for surfaces with identical palettes. Thanks, Timothy -- Timothy Strelchun CE Software Engineering Digital Home Group Intel Corporation The views expressed above are my own and not those of Intel From timothy.strelchun at intel.com Tue Mar 9 00:58:21 2010 From: timothy.strelchun at intel.com (Strelchun, Timothy) Date: Mon, 8 Mar 2010 15:58:21 -0800 Subject: [directfb-dev] [PATCH] Fix RGB24, Fix LUT8, add DSPF_A1_LSB and add DSPF_LUT8 dest color key blitting Message-ID: <29F4ED941D916B48B88B4D2A4F3D1B9C8B9D04DC@orsmsx509.amr.corp.intel.com> Attached is a patch for DFB 1.4.3 that with some fixes and additions. It: 1. Fixed a little endian DSPF_RGB24 byte ordering defect injected 2009.11.06 as part of git commit 0fdf41ff34ed403367d0eb05edc793b15a940860. Previously, the red and blue pixels were reversed. 2. Fixed a DSPF_LUT8 handling defect also injected 2009.11.06 as part of git commit 0fdf41ff34ed403367d0eb05edc793b15a940860. Previously, DSPF_LUT8 was being treated incorrectly as a YUV pixel format. 3. Added pixel format DSPF_A1_LSB that uses the LEAST significant bit first for pixels, because the existing DSPF_A1 format is MSB first. The VDC unit on the Intel(R) CE Media Processors use this for one of the various formats on its many display layers. The DFB software rasterizer functionality provided is almost the same as that already provided for existing DSPF_A1 format. 4. Added a function to support LUT8 to LUT8 blitting with destination color key enabled for surfaces with identical palettes. Thanks, Timothy -- Timothy Strelchun CE Software Engineering Digital Home Group Intel Corporation The views expressed above are my own and not those of Intel -------------- next part -------------- A non-text attachment was scrubbed... Name: DirectFB-1.4.3_FixRGB24_AddA1LSB_AddLUT8toLUT8DstColorKeyBlitWithIdenticalPalette.patch Type: application/octet-stream Size: 30919 bytes Desc: DirectFB-1.4.3_FixRGB24_AddA1LSB_AddLUT8toLUT8DstColorKeyBlitWithIdenticalPalette.patch URL: From shivajeekumar at gmail.com Tue Mar 9 12:59:54 2010 From: shivajeekumar at gmail.com (Shivakumar Mishra) Date: Tue, 9 Mar 2010 17:29:54 +0530 Subject: [directfb-dev] single buffered windows In-Reply-To: <20100302001600.GW14935@nokia.com> References: <20100302001600.GW14935@nokia.com> Message-ID: <55b3397a1003090359x1167060by68edc3ab6dd6ddd8@mail.gmail.com> hi, Each window has a surface with a single buffer. You should flip window surface when you are done with drawing operation of window surface bye shiva On Tue, Mar 2, 2010 at 5:46 AM, Anders Bakken wrote: > I have two questions about IDirectFBWindows. > > If I have a single buffered window do I still need to call Flip() to > make changes visible (I would expect not) > > How can I make single buffered windows? They seem to be double-buffered > no matter what I do. Is this related to some layer configuration > setting? > > (I am testing this with system=X11) > > regards > > -- > Qt Development Frameworks, Nokia, http://qt.nokia.com > Anders Bakken > _______________________________________________ > directfb-dev mailing list > directfb-dev at directfb.org > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > -- "The best way to find yourself is to lose yourself in the service of others". Shiva The Great -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre.draszik at st.com Tue Mar 9 14:08:16 2010 From: andre.draszik at st.com (Andre DRASZIK) Date: Tue, 09 Mar 2010 13:08:16 +0000 Subject: [directfb-dev] Layer panning In-Reply-To: <012e01cabb39$130f72f0$392e58d0$@com> References: <012e01cabb39$130f72f0$392e58d0$@com> Message-ID: <1268140096.21054.55.camel@bril0118.bri.st.com> Hi, On Wed, 2010-03-03 at 20:21 -0500, Brian Edmond wrote: > I am wondering how I would pan the source viewport of a Layer? Doesn't IDirectFBDisplayLayer::SetSourceRectangle() do that? Cheers, Andre' From timothy.strelchun at intel.com Tue Mar 9 16:45:59 2010 From: timothy.strelchun at intel.com (Strelchun, Timothy) Date: Tue, 9 Mar 2010 07:45:59 -0800 Subject: [directfb-dev] Layer panning In-Reply-To: <1268140096.21054.55.camel@bril0118.bri.st.com> References: <012e01cabb39$130f72f0$392e58d0$@com> <1268140096.21054.55.camel@bril0118.bri.st.com> Message-ID: <29F4ED941D916B48B88B4D2A4F3D1B9C8B9D0711@orsmsx509.amr.corp.intel.com> Yes, it does. :) Also, if the display layer is smaller than the output display resolution the IDirectFBDisplayLayer::SetScreenPosition function allows the layer to be moved around the display area coordinate space (including overlapping it and/or fully outside the visible area). This function is supported if the DLCAPS_SCREEN_POSITION capability is supported by the display layer. Regards, Timothy -- Timothy Strelchun CE Software Engineering Digital Home Group Intel Corporation The views expressed above are my own and not those of Intel >-----Original Message----- >From: directfb-dev-bounces at directfb.org >[mailto:directfb-dev-bounces at directfb.org] On Behalf Of Andre DRASZIK >Sent: Tuesday, March 09, 2010 5:08 AM >To: directfb-dev >Subject: Re: [directfb-dev] Layer panning > >Hi, > >On Wed, 2010-03-03 at 20:21 -0500, Brian Edmond wrote: >> I am wondering how I would pan the source viewport of a Layer? > >Doesn't IDirectFBDisplayLayer::SetSourceRectangle() do that? > >Cheers, >Andre' From timothy.strelchun at intel.com Tue Mar 9 17:16:10 2010 From: timothy.strelchun at intel.com (Strelchun, Timothy) Date: Tue, 9 Mar 2010 08:16:10 -0800 Subject: [directfb-dev] Layer panning In-Reply-To: <29F4ED941D916B48B88B4D2A4F3D1B9C8B9D0711@orsmsx509.amr.corp.intel.com> References: <012e01cabb39$130f72f0$392e58d0$@com> <1268140096.21054.55.camel@bril0118.bri.st.com> <29F4ED941D916B48B88B4D2A4F3D1B9C8B9D0711@orsmsx509.amr.corp.intel.com> Message-ID: <29F4ED941D916B48B88B4D2A4F3D1B9C8B9D074D@orsmsx509.amr.corp.intel.com> Slight correction: Also, if the display layer is smaller or LARGER than the output display resolution the IDirectFBDisplayLayer::SetScreenPosition function allows the layer to be moved around the display area coordinate space (including overlapping it and/or fully outside the visible area). This function is supported if the DLCAPS_SCREEN_POSITION capability is supported by the display layer. Regards, Timothy >-----Original Message----- >From: directfb-dev-bounces at directfb.org >[mailto:directfb-dev-bounces at directfb.org] On Behalf Of >Strelchun, Timothy >Sent: Tuesday, March 09, 2010 7:46 AM >To: 'directfb-dev at directfb.org' >Subject: Re: [directfb-dev] Layer panning > >Yes, it does. :) > >Also, if the display layer is smaller than the output display >resolution the IDirectFBDisplayLayer::SetScreenPosition >function allows the layer to be moved around the display area >coordinate space (including overlapping it and/or fully >outside the visible area). This function is supported if the >DLCAPS_SCREEN_POSITION capability is supported by the display layer. > >Regards, >Timothy > >-- > >Timothy Strelchun >CE Software Engineering >Digital Home Group >Intel Corporation > >The views expressed above are my own and not those of Intel > >>-----Original Message----- >>From: directfb-dev-bounces at directfb.org >>[mailto:directfb-dev-bounces at directfb.org] On Behalf Of Andre DRASZIK >>Sent: Tuesday, March 09, 2010 5:08 AM >>To: directfb-dev >>Subject: Re: [directfb-dev] Layer panning >> >>Hi, >> >>On Wed, 2010-03-03 at 20:21 -0500, Brian Edmond wrote: >>> I am wondering how I would pan the source viewport of a Layer? >> >>Doesn't IDirectFBDisplayLayer::SetSourceRectangle() do that? >> >>Cheers, >>Andre' >_______________________________________________ >directfb-dev mailing list >directfb-dev at directfb.org >http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > From llandwerlin at gmail.com Wed Mar 10 06:34:32 2010 From: llandwerlin at gmail.com (Lionel Landwerlin) Date: Wed, 10 Mar 2010 05:34:32 -0000 Subject: [directfb-dev] single buffered windows In-Reply-To: <55b3397a1003090359x1167060by68edc3ab6dd6ddd8@mail.gmail.com> References: <20100302001600.GW14935@nokia.com> <55b3397a1003090359x1167060by68edc3ab6dd6ddd8@mail.gmail.com> Message-ID: <1268184865.6952.26.camel@coalu.atr> Le mardi 09 mars 2010 ? 17:29 +0530, Shivakumar Mishra a ?crit : > hi, > Each window has a surface with a single buffer. > You should flip window surface when you are done with drawing operation of window surface Right, without a flip, the dfb stack isn't aware that the window's area must be updated. So the screen is not updated until someone else asks for a refresh, which could create some incoherent display depending on the area to refresh. About the single buffer settings, there is 2 fields you can setup when creating a new window. In the DFBWindowDescription : 'caps' and 'surface_caps'. Make sure to set not set the DWCAPS_DOUBLEBUFFER flag in 'caps' field and to not set DSCAPS_DOUBLE and DSCAPS_TRIPLE in the 'surface_caps' field. > bye > shiva > > On Tue, Mar 2, 2010 at 5:46 AM, Anders Bakken > wrote: > I have two questions about IDirectFBWindows. > > If I have a single buffered window do I still need to call > Flip() to > make changes visible (I would expect not) > > How can I make single buffered windows? They seem to be > double-buffered > no matter what I do. Is this related to some layer > configuration > setting? > > (I am testing this with system=X11) > > regards > > -- > Qt Development Frameworks, Nokia, http://qt.nokia.com > Anders Bakken > _______________________________________________ > directfb-dev mailing list > directfb-dev at directfb.org > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > > > > -- > "The best way to find yourself is to lose yourself in the service of > others". > > Shiva The Great > _______________________________________________ > directfb-dev mailing list > directfb-dev at directfb.org > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev From llandwerlin at gmail.com Wed Mar 10 06:38:42 2010 From: llandwerlin at gmail.com (Lionel Landwerlin) Date: Wed, 10 Mar 2010 05:38:42 -0000 Subject: [directfb-dev] Strange behaviour on Blit In-Reply-To: <23406c481003032237o793d9f4rcf61b4d8507b1c60@mail.gmail.com> References: <23406c481003032237o793d9f4rcf61b4d8507b1c60@mail.gmail.com> Message-ID: <1268185122.6952.27.camel@coalu.atr> Le jeudi 04 mars 2010 ? 08:37 +0200, Strikos Nick a ?crit : > Hi, > > While running some tests, I noticed that DirectFB blits incorrectly a > rotated, source colorkeyed image. I am using versions 1.4.2 and 1.4.3, > and the problem can be seen if one adds DSBLIT_ROTATE* in df_dok > example's source colorkey demo. In some cases the image is rendered > mirrored in the X axis, in others only a single line appears. > > Can you reproduce this behaviour? Which system, gfxdriver, platform ? -- Lionel Landwerlin From timothy.strelchun at intel.com Sat Mar 13 06:27:46 2010 From: timothy.strelchun at intel.com (Strelchun, Timothy) Date: Sat, 13 Mar 2010 05:27:46 -0000 Subject: [directfb-dev] SaWMan: layer buffermode reconfiguration ? In-Reply-To: <4d28d4b51003020558o56449b48id8385ecd715218c5@mail.gmail.com> References: <4d28d4b51002250938w59400e9ev55f6de35d7744365@mail.gmail.com> <4B8CF1C2.4060508@directfb.org> <4d28d4b51003020558o56449b48id8385ecd715218c5@mail.gmail.com> Message-ID: <29F4ED941D916B48B88B4D2A4F3D1B9C8BA2CFC6@orsmsx509.amr.corp.intel.com> Hi Lionel, Last year, when we switched our DFB driver set to 1.2.10 (with a custom systems driver that does not assume one wants a surface buffer automatically initialized since it might immediately be fully rendered on), I noticed several cases where uninitialized surface buffers were automatically flipped onto the display in both single and double/triple buffering and mentioned the fixes (http://mail.directfb.org/pipermail/directfb-dev/2009-September/005245.html and http://mail.directfb.org/pipermail/directfb-dev/2009-September/005235.html). It may not address the issue you are experiencing when using SaWMan, but it might not hurt to try out. So, I have prepared a patch with those fixes applied to 1.4.3 that I will send in my next message. Regards, Timothy -- Timothy Strelchun CE Software Engineering Digital Home Group Intel Corporation The views expressed above are my own and not those of Intel >-----Original Message----- >From: directfb-dev-bounces at directfb.org >[mailto:directfb-dev-bounces at directfb.org] On Behalf Of Lionel >Landwerlin >Sent: Tuesday, March 02, 2010 5:58 AM >To: Niels Roest >Cc: directfb-dev >Subject: Re: [directfb-dev] SaWMan: layer buffermode reconfiguration ? > >Hi Niels, > >thanks for the trick. After a few more investigation, I just >patched SaWMan to avoid it to change the buffermode of the layer. >Maybe this should be an option to use this optimization... My >framebuffer driver might be buggy to not be able to change the >layer mode without flicking... I don't know. >I also would like to add that I have seen some unrefreshed >screen zone when using windows and moving+scaling them over >the screen. Are you aware of such bugs in SaWMan (also seen it >in the default window >manager) ? > >Regards, > >-- >Lionel Landwerlin > >On Tue, Mar 2, 2010 at 12:08 PM, Niels Roest > wrote: >> Hi Lionel, >> I have not looked in close detail, but SaWMan has an optimization to >> align the layer to the window if only one window is displayed - this >> holds for size and location. I think you are hitting this, >but I don't >> know why it would go from double to single bufferend in that case. >> The switching behaviour can be prevented by having the >SaWMan callback >> layer_reconfig() disallowing all changes (not returning DFB_OK). >> >> Greets >> Niels >> >> Lionel Landwerlin wrote: >>> >>> Hi all, >>> >>> I'm playing a little bit with SaWMan these days, and I noticed a >>> strange flicking effect. >>> Here is my setup : >>> ?- a 1280x720 layer double buffered at start >>> ?- a 1280x720 window containing a main application >>> ?- 2/3 300x200 windows acting as widgets on top of the main >>> application window >>> >>> When I destroy the 300x200 windows, and then I recreate one >of them, >>> I'm noticing a flickering effect of the whole screen. With a few >>> investigation I found that at this moment, SaWMan reconfigure the >>> layer to change its buffermode from double buffered to single >>> buffered. >>> >>> Any explanation ? >>> >>> Regards, >>> >>> -- >>> Lionel Landwerlin >>> _______________________________________________ >>> directfb-dev mailing list >>> directfb-dev at directfb.org >>> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev >>> >>> >> >> >> -- >> >> .------------------------------------------. >> | DirectFB - Hardware accelerated graphics | >http://www.directfb.org/ ? ? ? ? ? ? ? ? >> | | >> "------------------------------------------" >> >_______________________________________________ >directfb-dev mailing list >directfb-dev at directfb.org >http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > From timothy.strelchun at intel.com Sat Mar 13 06:30:19 2010 From: timothy.strelchun at intel.com (Strelchun, Timothy) Date: Sat, 13 Mar 2010 05:30:19 -0000 Subject: [directfb-dev] [PATCH] Prevent early flips from occurring possible with uninitialized memory (respect frozen layers) and use background configuration Message-ID: <29F4ED941D916B48B88B4D2A4F3D1B9C8BA2CFCB@orsmsx509.amr.corp.intel.com> Attached is a patch for DFB 1.4.3 that has some fixes and additions. Previously, I had sent these not in patch form and for DFB 1.2 ((http://mail.directfb.org/pipermail/directfb-dev/2009-September/005245.html and http://mail.directfb.org/pipermail/directfb-dev/2009-September/005235.html). 1. Fixes display layer window stack repainting to NOT be performed when it is frozen. This prevents a display layer surface flip from being done and showing an uninitialized buffer when the IDirectFB::GetDisplayLayer function is called with an associated no-init-layer directfbrc command (without init-init[=0-15]). 2. Fixes IDirectFBDisplayLayer::GetSurface function to only perform single buffered display layer clearing when the region is frozen and to render the background if it is configured (each time GetSurface is called the surface should not be cleared). Also added support for this behavior when the cooperative level is DLSCL_ADMINISTRATIVE. NOTE: There are two versions of the attached patch, one against the original DFB 1.4.3 release and one that expects that the DSPF_A1_LSB patch I sent yesterday has already been applied. Regards, Timothy -- Timothy Strelchun CE Software Engineering Digital Home Group Intel Corporation The views expressed above are my own and not those of Intel -------------- next part -------------- A non-text attachment was scrubbed... Name: DirectFB-1.4.3_PreventEarlyFlips_UseBackgroundConfigWhenClearing.patch Type: application/octet-stream Size: 5267 bytes Desc: DirectFB-1.4.3_PreventEarlyFlips_UseBackgroundConfigWhenClearing.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: DirectFB-1.4.3withA1LSB_PreventEarlyFlips_UseBackgroundConfigWhenClearing.patch Type: application/octet-stream Size: 5267 bytes Desc: DirectFB-1.4.3withA1LSB_PreventEarlyFlips_UseBackgroundConfigWhenClearing.patch URL: From llandwerlin at gmail.com Wed Mar 17 00:40:26 2010 From: llandwerlin at gmail.com (Lionel Landwerlin) Date: Wed, 17 Mar 2010 00:40:26 +0100 Subject: [directfb-dev] [PATCH] Bump directfb dependency to 1.4.2 In-Reply-To: <1268771887.5202.20.camel@coalu.atr> References: <1268771887.5202.20.camel@coalu.atr> Message-ID: <1268782826.5202.21.camel@coalu.atr> Oops... This patch is for SaWMan ! :) -- Lionel Landwerlin From llandwerlin at gmail.com Tue Mar 16 21:38:07 2010 From: llandwerlin at gmail.com (Lionel Landwerlin) Date: Tue, 16 Mar 2010 21:38:07 +0100 Subject: [directfb-dev] [PATCH] Bump directfb dependency to 1.4.2 Message-ID: <1268771887.5202.20.camel@coalu.atr> required by usage of application_id in struct CoreWindowConfig Signed-off-by: Lionel Landwerlin --- configure.in | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/configure.in b/configure.in index 9fd259a..38aa6ed 100644 --- a/configure.in +++ b/configure.in @@ -35,8 +35,8 @@ LT_CURRENT=`expr $SAWMAN_MICRO_VERSION - $SAWMAN_INTERFACE_AGE` LT_REVISION=$SAWMAN_INTERFACE_AGE LT_AGE=`expr $SAWMAN_BINARY_AGE - $SAWMAN_INTERFACE_AGE` -AC_SUBST(LT_RELEASE) -AC_SUBST(LT_CURRENT) +AC_SUBST(LT_RELEASE) +AC_SUBST(LT_CURRENT) AC_SUBST(LT_REVISION) AC_SUBST(LT_AGE) @@ -49,7 +49,7 @@ AM_MAINTAINER_MODE AM_CONFIG_HEADER(config.h) -AC_DISABLE_STATIC +AC_DISABLE_STATIC AM_PROG_LIBTOOL AM_SANITY_CHECK AC_ISC_POSIX @@ -77,7 +77,7 @@ fi # # Check for DirectFB-Internal # -DFB_VERSION=1.2.10 +DFB_VERSION=1.4.2 AC_MSG_CHECKING(for DirectFB-Internal >= $DFB_VERSION) if $PKG_CONFIG --atleast-version $DFB_VERSION directfb-internal ; then MODULEDIR=$libdir/`$PKG_CONFIG --variable=moduledirname directfb-internal` @@ -158,7 +158,7 @@ wm/sawman/Makefile AC_MSG_RESULT([ -Build options: +Build options: Module directory $MODULEDIR Debug mode $enable_debug CFLAGS $CFLAGS -- 1.7.0 From swami.viswanathan at gmail.com Fri Mar 19 21:02:15 2010 From: swami.viswanathan at gmail.com (Swami Viswanathan) Date: Fri, 19 Mar 2010 13:02:15 -0700 Subject: [directfb-dev] Adding support for 4-bit greyscale Message-ID: Hello How difficult will it be to add support for 4-bit greyscale to directfb? I am somewhat familiar with the directfb architecture. I have already implemented a systems driver that communicates with a custom lcd driver. (Similar to frame buffer driver). But I am converting from RGB16 to grey scale in the updateregion and flipregion functions and I would like to remove this. thanks swami From lindo at tataelxsi.co.in Thu Mar 18 12:56:47 2010 From: lindo at tataelxsi.co.in (Lindo Lonappan) Date: Thu, 18 Mar 2010 17:26:47 +0530 Subject: [directfb-dev] Some General doubt about fusion in DirectFB-1.0.0 Message-ID: <4BA214FF.4030802@tataelxsi.co.in> Dear All, I am using DirectFB-1.0.0. From the code and Google, we found that IDirectFB interface is a singleton one. So the subsequent call to the DirectFBInit() will simply return without changing any configuration and DirectFBCreate() call will return a reference to first IDirectFB handler. Our questions are, 1. We are configured, DirectFB as single core mode(ie without any fusion module). Is this is sufficient even if there is multiple DirectFBInit/DirectFBCreate call from the same applications? 2. Can we control the z-order of windows in this case also? (The two windows are created from two different references) 3. If above is possible can any one lead me to the APIs for that? (Both at the time of Creating new window and at run time) 4. Is fusion always necessary if there is multilple applications over DFB? (I read, it is required for IPCs. Can anyone explain a little more details) 5. Inside fusion module, there is a mmap() which using a flag MAP_FIXED. In our system the addresses it tries to map is already used by some other one and we are not able to free that. So is there any way to change this fixed address need?? Thanks a lot for your valuable time. -- Thanks & Regards, Lindo Lonappan. From llandwerlin at gmail.com Wed Mar 24 13:56:12 2010 From: llandwerlin at gmail.com (Lionel Landwerlin) Date: Wed, 24 Mar 2010 13:56:12 +0100 Subject: [directfb-dev] linux-fusion 32/64bits ioctls compatibility Message-ID: <4d28d4b51003240556x7f96bd62va6b586bdf2a041e9@mail.gmail.com> Hi everyone, I'm trying to run a 32bits compiled directfb application on a 64bits host system. Unfortunatly, because of long integer fields in fusion's structures, an application compiled with with a 32bits compiler won't work on a 64bits system. Is there any plan to make this work in future fusion's releases ? Regards, -- Lionel From rhilding at cisco.com Wed Mar 24 17:00:51 2010 From: rhilding at cisco.com (Robert Hildinger) Date: Wed, 24 Mar 2010 11:00:51 -0500 Subject: [directfb-dev] Ramifications of [no-]thread-block-signals option Message-ID: Hello, Could someone enlighten my as to why DirectFB defaults to creating threads that block all signals? Also, what are the ramifications of using the option to turn this off (no-thread-block-signals)? Thanks! -Robert Hildinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.j.zhao at intel.com Thu Mar 25 06:11:44 2010 From: juan.j.zhao at intel.com (Zhao, Juan J) Date: Thu, 25 Mar 2010 13:11:44 +0800 Subject: [directfb-dev] Is git service OK? Message-ID: Hi guys, I can't use "git clone git://git.directfb.org/git/directfb/core/DirectFB.git" to download the source code now. I have found that "git.directfb.org:9418 port is closed". Is the git service OK for DirectFB? ----------- *^_^* Many thanks & Best Regards Zhao Juan From juan.j.zhao at intel.com Thu Mar 25 06:34:12 2010 From: juan.j.zhao at intel.com (Zhao, Juan J) Date: Thu, 25 Mar 2010 13:34:12 +0800 Subject: [directfb-dev] [PATCH] Fix LUT8 convert to rgb32 error Message-ID: <1269495252.3978.45.camel@.sh.intel.com> Attached is a patch for DirectFB based on tip commit: 3a9360cb003f605be22134b54eeeee1858d727bd. DSPF_LUT8 pixel format is not correctly handling in update_screen in system/x11/primary.c. And this caused error message "[unsupported format]***[convert.c:987 in dfb_convert_to_rgb32()]" when running demos such as df_fire. ---- *^_^* Many thanks & Best Regards Juan Zhao -------------- next part -------------- A non-text attachment was scrubbed... Name: DirectFB-1.4.3-add-DSPF_LUT8-for-24bpp.patch Type: text/x-patch Size: 1614 bytes Desc: not available URL: From niels at directfb.org Sat Mar 27 11:16:02 2010 From: niels at directfb.org (Niels Roest) Date: Sat, 27 Mar 2010 13:16:02 +0300 Subject: [directfb-dev] Segmentation fault in DirectFB core In-Reply-To: <23406c481003032235i5ed933fblb866bc3af986ba61@mail.gmail.com> References: <23406c481003032235i5ed933fblb866bc3af986ba61@mail.gmail.com> Message-ID: <4BADDAE2.4010603@directfb.org> Hi Nick, just had a look, I assume you are using linux where signal 10 is USR1 (type kill -l 10 on your system). DirectFB does not emit that signal. No idea where it might come from otherwise.. Greets Niels Strikos Nick wrote: > Hi, > > I have run into a segmentation fault while testing some demos from Qt > 4.6.1, compiled with DirectFB support. I am using version 1.4.2, but > 1.4.3 did not make a change either. Specifically, the problem appears > in some accelerated rectangle fills, and more precisely when I move > the pointer over the main menu of the Qt application. I am posting > below the last portion of DirectFB debug output. Do you think this is > a bug in DirectFB or QT? > > With regards, > Strikos Nick > Think Silicon Ltd > http://www.think-silicon.com > > Debug output: > > (-) [Main Thread 942.836] ( 98) Core/GraphicsOps: > dfb_gfxcard_fillrectangles( 0x1eb2ec [1], 0x1eb354 ) > (-) [Main Thread 942.839] ( 98) Core/GraphicsOps: > dfb_gfxcard_state_check( 0x1eb354, 0x00000001 ) [0,0 - 28,16] > (-) [Main Thread 942.842] ( 98) Core/GfxState: > dfb_gfxcard_state_check( 0x1eb354, 0x00000001 ) drawing -> 0x1eafa8 > (-) [Main Thread 943.939] ( 98) Core/GfxState: <- checked > 0x00000000, accel 0x00000000, modified 0x00033fff, mod_hw 0x00000000 > (-) [Main Thread 943.942] ( 98) Core/GfxState: -> checked > 0x00000000, accel 0x00000000, modified 0x00033fff, mod_hw 0x00000000 > (-) [Main Thread 943.945] ( 98) Core/GfxState: -> checked > 0x00000007, accel 0x00000007, modified 0x00033fff, mod_hw 0x00000000 > (-) [Main Thread 943.948] ( 98) Core/GfxState: => checked > 0x00000007, accel 0x00000007, modified 0x00000000, mod_hw 0x00033fff > (-) [Main Thread 943.951] ( 98) Core/GfxState: > dfb_gfxcard_state_acquire( 0x1eb354, 0x00000001 ) drawing -> 0x1eafa8 > (-) [Main Thread 943.954] ( 98) Core/SurfBuffer: > dfb_surface_buffer_lock( 0x1e5658, 0x02, 0x1eb400 ) <- 29x17 ARGB [0] > (-) [Main Thread 943.957] ( 98) Core/SurfBuffer: -> GPU WRITE > (-) [Main Thread 943.959] ( 98) Core/SurfacePool: > dfb_surface_pools_allocate( 0x1e5658, 0x2 ) > (-) [Main Thread 943.961] ( 98) Core/SurfacePool: -> 29x17 > ARGB - PRIVATE > (-) [Main Thread 943.964] ( 98) Core/SurfacePool: > dfb_surface_pools_negotiate( 0x1e5658 [ARGB], 0x02, 0x02, max 4 ) > (-) [Main Thread 943.967] ( 98) Core/SurfacePool: -> > 0x02 0x000 required > (-) [Main Thread 943.969] ( 98) Core/SurfacePool: -> [3] > 0x03 0x21f (0) [Frame Buffer Memory] > (-) [Main Thread 943.972] ( 98) FBDev/Surfaces: > fbdevTestConfig( 0x1e5658 ) > (-) [Main Thread 943.975] ( 98) SurfaceManager: > dfb_surfacemanager_allocate( 0x1e5658 ) <- 29x17 ARGB > (-) [Main Thread 943.977] ( 98) SurfaceManager: -> pitch > 116, length 1988, available 6467584 > (-) [Main Thread 943.980] ( 98) FBDev/Surfaces: -> OK > (-) [Main Thread 943.982] ( 98) Core/SurfacePool: => OK > (-) [Main Thread 943.984] ( 98) Core/SurfacePool: => 1 pools > available > (-) [Main Thread 943.987] ( 98) Core/SurfacePool: => 0 pools > out of memory > (-) [Main Thread 943.989] ( 98) Core/SurfacePool: > dfb_surface_pool_allocate( 0x73898 [3], 0x1e5658 ) > (-) [Main Thread 943.992] ( 98) FBDev/Surfaces: > fbdevAllocateBuffer( 0x1e5658 ) > (-) [Main Thread 943.995] ( 98) SurfaceManager: > dfb_surfacemanager_allocate( 0x1e5658 ) <- 29x17 ARGB > (-) [Main Thread 943.997] ( 98) SurfaceManager: -> pitch > 116, length 1988, available 6467584 > (-) [Main Thread 944.000] ( 98) SurfaceManager: -> found > free (3317370) > (-) [Main Thread 944.002] ( 98) SurfaceManager: > occupy_chunk( 1988 bytes at offset 4851382 ) > (-) [Main Thread 944.004] ( 98) SurfaceManager: -> > occupied 1988, available 6467584 > (-) [Main Thread 944.007] ( 98) Core/SurfacePool: -> 0x1619a0 > (-) [Main Thread 944.009] ( 98) Core/SurfacePool: -> 0x1619a0 > (-) [Main Thread 944.011] ( 98) Core/SurfBuffer: > dfb_surface_allocation_update() > (-) [Main Thread 944.014] ( 98) Core/SurfBuffer: -> > increasing serial... > (-) [Main Thread 944.016] ( 98) Core/SurfPoolLock: > dfb_surface_pool_lock( 0x73898 [3], 0x1619a0 ) > (-) [Main Thread 944.019] ( 98) FBDev/SurfLock: fbdevLock( > 0x1e5658 ) > (-) [Main Thread 944.021] ( 98) FBDev/SurfLock: -> offset > 4851382, pitch 116, addr 0x519786b6, phys 0x734a06b6 > (-) [Main Thread 944.024] ( 98) Core/SurfBuffer: -> locked > 1x now > (-) [Main Thread 944.027] ( 98) Core/GfxState: -> switch > from 0x1e524c [1] to 0x1eb354 [1] > (-) [Main Thread 944.029] ( 98) Core/GfxState: -> mod_hw > 0x00033fff, modified 0x00000000 > (-) [Main Thread 944.032] ( 98) Core/GfxState: -> mod_hw > 0x00033fff, set 0x00000000 > (-) [Main Thread 944.034] ( 98) Core/GfxState: => mod_hw > 0x00000000, set 0x00000007 > (-) [Main Thread 944.037] ( 98) Core/SurfBuffer: > dfb_surface_buffer_unlock( 0x1eb400 ) > (-) [Main Thread 944.039] ( 98) Core/SurfPoolLock: > dfb_surface_pool_unlock( 0x73898 [3], 0x1619a0 ) > (-) [Main Thread 944.042] ( 98) FBDev/SurfLock: fbdevUnlock( > 0x1e5658 ) > (-) [Main Thread 944.048] ( 98) IDirectFBSurface: > IDirectFBSurface_GetSize( 0x1eb1b8 ) > (-) [Main Thread 945.145] ( 98) IDirectFBSurface: > IDirectFBSurface_GetSize( 0x1eb1b8 ) > (-) [Main Thread 945.148] ( 98) IDirectFBSurface: > IDirectFBSurface_GetSize( 0x1eb1b8 ) > (-) [Main Thread 945.151] ( 98) IDirectFBSurface: > IDirectFBSurface_GetSize( 0x1eb1b8 ) > (-) [Main Thread 945.153] ( 98) IDirectFBSurface: > IDirectFBSurface_GetSize( 0x1eb1b8 ) > (-) [Main Thread 945.158] ( 98) IDirectFBSurface: > IDirectFBSurface_GetSize( 0x1eb1b8 ) > (-) [Main Thread 945.160] ( 98) IDirectFBSurface: > IDirectFBSurface_GetSize( 0x1eb1b8 ) > (-) [Main Thread 945.163] ( 98) IDirectFBSurface: > IDirectFBSurface_SetPorterDuff( 0x1eb1b8, 3 ) > (-) [Main Thread 945.165] ( 98) IDirectFBSurface: > IDirectFBSurface_GetSize( 0x1eb1b8 ) > (-) [Main Thread 945.168] ( 98) IDirectFBSurface: > IDirectFBSurface_GetSize( 0x1eb1b8 ) > (-) [Main Thread 945.170] ( 98) IDirectFBSurface: > IDirectFBSurface_SetClip( 0x1eb1b8, 0xef933610 ) > (-) [Main Thread 945.173] ( 98) IDirectFBSurface: <- > 0, 0- 29x 17 > (-) [Main Thread 945.176] ( 98) IDirectFBSurface: -> > 0, 0- 29x 17 > (-) [Main Thread 945.178] ( 98) IDirectFBSurface: => CLIP > 0, 0- 29x 17 > (-) [Main Thread 945.181] ( 98) IDirectFBSurface: > IDirectFBSurface_GetSize( 0x1eb1b8 ) > (-) [Main Thread 945.184] ( 98) IDirectFBSurface: > IDirectFBSurface_GetSize( 0x1eb1b8 ) > (-) [Main Thread 945.188] ( 98) IDirectFBSurface: > IDirectFBSurface_Lock( 0x1eb1b8 ) > (-) [Main Thread 945.191] ( 98) Core/SurfBuffer: > dfb_surface_buffer_lock( 0x1e5658, 0x03, 0x1eb328 ) <- 29x17 ARGB [0] > (-) [Main Thread 945.194] ( 98) Core/SurfBuffer: -> CPU > READWRITE > (-) [Main Thread 945.196] ( 98) Core/SurfBuffer: > dfb_surface_allocation_update() > (-) [Main Thread 945.199] ( 98) Core/SurfBuffer: -> > increasing serial... > (-) [Main Thread 945.201] ( 98) Core/SurfPoolLock: > dfb_surface_pool_lock( 0x73898 [3], 0x1619a0 ) > (-) [Main Thread 945.203] ( 98) FBDev/SurfLock: fbdevLock( > 0x1e5658 ) > (-) [Main Thread 945.205] ( 98) FBDev/SurfLock: -> offset > 4851382, pitch 116, addr 0x519786b6, phys 0x734a06b6 > (-) [Main Thread 945.208] ( 98) Core/SurfBuffer: -> locked > 1x now > (-) [Main Thread 945.210] ( 98) IDirectFBSurface: > IDirectFBSurface_GetSize( 0x1eb1b8 ) > (-) [Main Thread 945.213] ( 98) IDirectFBSurface: > IDirectFBSurface_GetPixelFormat( 0x1eb1b8 ) > (-) [Main Thread 945.216] ( 98) IDirectFBSurface: > IDirectFBSurface_GetCapabilities( 0x1eb1b8 ) > (-) [Main Thread 945.219] ( 98) IDirectFBSurface: > IDirectFBSurface_GetSize( 0x1eb1b8 ) > (-) [Main Thread 945.222] ( 98) IDirectFBSurface: > IDirectFBSurface_GetSize( 0x1eb1b8 ) > (!) [ 98: 945.229] --> Caught signal 10 (unknown origin) <-- > ------------------------------------------------------------------------ > > _______________________________________________ > directfb-dev mailing list > directfb-dev at directfb.org > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > -- .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" From niels at directfb.org Sat Mar 27 11:16:15 2010 From: niels at directfb.org (Niels Roest) Date: Sat, 27 Mar 2010 13:16:15 +0300 Subject: [directfb-dev] single buffered windows In-Reply-To: <20100302001600.GW14935@nokia.com> References: <20100302001600.GW14935@nokia.com> Message-ID: <4BADDAEF.2090209@directfb.org> How come you have double buffered windows? Afaik, windows are default single buffered. If you change the content of a window, the layer buffer is only updated when you do a window->Flip after your change - this copies the updated area from the window buffer to the layer buffer (generally the back buffer followed by a implicit flip, if your layer is double buffered) Greets Niels Anders Bakken wrote: > I have two questions about IDirectFBWindows. > > If I have a single buffered window do I still need to call Flip() to > make changes visible (I would expect not) > > How can I make single buffered windows? They seem to be double-buffered > no matter what I do. Is this related to some layer configuration > setting? > > (I am testing this with system=X11) > > regards > > -- .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" From niels at directfb.org Sat Mar 27 11:18:38 2010 From: niels at directfb.org (Niels Roest) Date: Sat, 27 Mar 2010 13:18:38 +0300 Subject: [directfb-dev] (no subject) In-Reply-To: <2C9A630F1C474FF3A41FE8F0C1DF4526@c2microjthou> References: <2C9A630F1C474FF3A41FE8F0C1DF4526@c2microjthou> Message-ID: <4BADDB7E.2090305@directfb.org> jthou wrote: > > Hi, Denis and Niels, > > Could you help me on these questions? > > > > > > 1, What kind of Graphics standards are supported by DirectFB? > GKS? PHIGS? or some thing else? Is there a spec to conference? > For 2D pixel drawing primitives refer to the DirectFB API, which supports the basic primitives (box, rectangle, line, etc) and the basic modifiers (blending, opacity, rotation, etc). There is also a function for 3D-skewing bitmaps if your hardware supports this. For 3D vector based primitives, a development revision of DirectFB works in conjunction with OpenGL. > > 2, Does DirectFB support 3-D ? > > 3, What's the difference of DirectFB 1.2.10, DirectFB 1.4.3, > SaWMan 1.4.3? I see them are list on same level in the website. > SaWMan is an add-on window manager for DirectFB. DirectFB is DirectFB :) > > 4, I'm working on version 1.2.6. Do I need to update it to > 1.2.10 or 1.4.3? > I cannot tell. The latest is always the best, but might not be viable since you are e.g. bound by compiled drivers or required support from your hardware provider. 1.4.3 is the latest. The differences can be found in the changelogs, there are too many to list. > > > > Thank you very much. > > > > -Justin > > > > ------------------------------------------------------------------------ > > _______________________________________________ > directfb-dev mailing list > directfb-dev at directfb.org > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > -- .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" From lindo at tataelxsi.co.in Mon Mar 29 06:59:17 2010 From: lindo at tataelxsi.co.in (Lindo Lonappan) Date: Mon, 29 Mar 2010 10:29:17 +0530 Subject: [directfb-dev] Some General doubt about fusion in DirectFB-1.0.0 In-Reply-To: <55b3397a1003272009r26317905o5e1245fd9f8bd921@mail.gmail.com> References: <4BA214FF.4030802@tataelxsi.co.in> <55b3397a1003272008x355a3c5bt9235672e46315317@mail.gmail.com> <55b3397a1003272009r26317905o5e1245fd9f8bd921@mail.gmail.com> Message-ID: <4BB033A5.20300@tataelxsi.co.in> Dear Shivakumar, Thanks for your reply. Sorry for posting the same mail again in user's list. It's a mistake from me. Dear Shivakumar/all, I am expecting more clarifications in Question number 4.( What is mean by smooth running. Is any crash/undefined behavious occur?) Can some one give me some explanation for Question number 5. Thanks & Regards, Lindo Lonappan. On 3/28/2010 8:39 AM, Shivakumar Mishra wrote: > > > On Sun, Mar 28, 2010 at 8:38 AM, Shivakumar Mishra > > wrote: > > hi, > > On Thu, Mar 18, 2010 at 5:26 PM, Lindo Lonappan > > wrote: > > Dear All, > > I am using DirectFB-1.0.0. > > >From the code and Google, we found that IDirectFB interface > is a singleton one. > So the subsequent call to the DirectFBInit() will simply > return without changing any configuration > and DirectFBCreate() call will return a reference to first > IDirectFB handler. > > Our questions are, > > 1. We are configured, DirectFB as single core mode(ie without > any fusion module). > Is this is sufficient even if there is multiple > DirectFBInit/DirectFBCreate call from the same applications? > > You can call multiple times .But it will give you same instance.It > has no effect. > > 2. Can we control the z-order of windows in this case also? > (The two windows are created from two different references) > > Yes you can. > > > 3. If above is possible can any one lead me to the APIs for that? > (Both at the time of Creating new window and at run time) > > There are two ways:- > 1. Create window with different layer and SetLevel for that > layer(according to your requirement) > 2.You can use these api for specific window:- (If you want it > from window operation) > > SetStackingClass,Raise,RaiseToTop,Lower etc. go through link:- > http://directfb.org/docs/DirectFB_Reference_1_4/IDirectFBWindow.html > > > 4. Is fusion always necessary if there is multilple > applications over DFB? > (I read, it is required for IPCs. Can anyone explain a > little more details) > > No (But necessary for smoother running of applications). > > > 5. Inside fusion module, there is a mmap() which using a flag > MAP_FIXED. > In our system the addresses it tries to map is already used > by some other one and we are not able to free that. > So is there any way to change this fixed address need?? > > Thanks a lot for your valuable time. > > -- > Thanks & Regards, > Lindo Lonappan. > > > > _______________________________________________ > directfb-dev mailing list > directfb-dev at directfb.org > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > > > > > -- > "The best way to find yourself is to lose yourself in the service > of others". > > Shiva The Great > > > > > -- > "The best way to find yourself is to lose yourself in the service of > others". > > Shiva The Great -------------- next part -------------- An HTML attachment was scrubbed... URL: From llandwerlin at gmail.com Sun Mar 28 01:39:45 2010 From: llandwerlin at gmail.com (Lionel Landwerlin) Date: Sun, 28 Mar 2010 01:39:45 +0100 Subject: [directfb-dev] Is git service OK? In-Reply-To: References: Message-ID: <1269736785.31425.2.camel@coalu.atr> Le jeudi 25 mars 2010 ? 13:11 +0800, Zhao, Juan J a ?crit : > Hi guys, > I can't use "git clone git://git.directfb.org/git/directfb/core/DirectFB.git" to download the source code now. > I have found that "git.directfb.org:9418 port is closed". Is the git service OK for DirectFB? > > ----------- Sometimes, it's down... The mailing list also... -- Lionel Landwerlin From anders.bakken at nokia.com Mon Mar 29 00:40:05 2010 From: anders.bakken at nokia.com (anders.bakken at nokia.com) Date: Mon, 29 Mar 2010 00:40:05 +0200 Subject: [directfb-dev] single buffered windows In-Reply-To: <4BADDAEF.2090209@directfb.org> References: <20100302001600.GW14935@nokia.com>, <4BADDAEF.2090209@directfb.org> Message-ID: <4369FB1FEB99B3409C8B882D1D764CA01C38EEC528@NOK-EUMSG-03.mgdnok.nokia.com> > _______________________________________ > From: ext Niels Roest [niels at directfb.org] > Sent: Saturday, March 27, 2010 3:16 AM > To: Bakken Anders (Nokia-D-Qt/RedwoodCity) > Cc: directfb-dev at directfb.org > Subject: Re: [directfb-dev] single buffered windows > > How come you have double buffered windows? > Afaik, windows are default single buffered. > If you change the content of a window, the layer buffer is only updated > when you do a window->Flip after your change - this copies the updated > area from the window buffer to the layer buffer (generally the back > buffer followed by a implicit flip, if your layer is double buffered) > > Greets > Niels Hi Niels That seems to what DirectFB is giving me. I use the attached example and the output is: 12 DSCAPS_DOUBLE 1 This is running 1.4.3 and system=x11 regards Anders -------------- next part -------------- A non-text attachment was scrubbed... Name: main.cpp Type: text/x-c++src Size: 1633 bytes Desc: main.cpp URL: From shivajeekumar at gmail.com Mon Mar 29 07:32:28 2010 From: shivajeekumar at gmail.com (Shivakumar Mishra) Date: Mon, 29 Mar 2010 11:02:28 +0530 Subject: [directfb-dev] Some General doubt about fusion in DirectFB-1.0.0 In-Reply-To: <4BB033A5.20300@tataelxsi.co.in> References: <4BA214FF.4030802@tataelxsi.co.in> <55b3397a1003272008x355a3c5bt9235672e46315317@mail.gmail.com> <55b3397a1003272009r26317905o5e1245fd9f8bd921@mail.gmail.com> <4BB033A5.20300@tataelxsi.co.in> Message-ID: <55b3397a1003282232ibb264b8s5324167fdb7a47a2@mail.gmail.com> Dear Lindo, On Mon, Mar 29, 2010 at 10:29 AM, Lindo Lonappan wrote: > Dear Shivakumar, > > Thanks for your reply. > Sorry for posting the same mail again in user's list. It's a mistake from > me. > > Dear Shivakumar/all, > > I am expecting more clarifications in Question number 4.( What is mean by > smooth running. Is any crash/undefined behavious occur?) > > Yes, crash and undefined behavior is possible .In some cases top windows on different layer of different application are not freeing memory properly.What I observed,There is some blurred and fading effect of surface or window of application which has been already exited on currently running applications. > Can some one give me some explanation for Question number 5. > > Thanks & Regards, > > Lindo Lonappan. > > > On 3/28/2010 8:39 AM, Shivakumar Mishra wrote: > > > > On Sun, Mar 28, 2010 at 8:38 AM, Shivakumar Mishra < > shivajeekumar at gmail.com> wrote: > >> hi, >> >> On Thu, Mar 18, 2010 at 5:26 PM, Lindo Lonappan wrote: >> >>> Dear All, >>> >>> I am using DirectFB-1.0.0. >>> >>> >From the code and Google, we found that IDirectFB interface is a >>> singleton one. >>> So the subsequent call to the DirectFBInit() will simply return without >>> changing any configuration >>> and DirectFBCreate() call will return a reference to first IDirectFB >>> handler. >>> >>> Our questions are, >>> >>> 1. We are configured, DirectFB as single core mode(ie without any fusion >>> module). >>> Is this is sufficient even if there is multiple >>> DirectFBInit/DirectFBCreate call from the same applications? >>> >>> You can call multiple times .But it will give you same instance.It has >> no effect. >> >> >>> 2. Can we control the z-order of windows in this case also? >>> (The two windows are created from two different references) >>> >> Yes you can. >> >>> >>> 3. If above is possible can any one lead me to the APIs for that? >>> (Both at the time of Creating new window and at run time) >>> >> There are two ways:- >> 1. Create window with different layer and SetLevel for that >> layer(according to your requirement) >> 2.You can use these api for specific window:- (If you want it from >> window operation) >> >> SetStackingClass,Raise,RaiseToTop,Lower etc. go through link:- >> http://directfb.org/docs/DirectFB_Reference_1_4/IDirectFBWindow.html >> >> >>> 4. Is fusion always necessary if there is multilple applications over >>> DFB? >>> (I read, it is required for IPCs. Can anyone explain a little more >>> details) >>> >> No (But necessary for smoother running of applications). >> >>> >>> 5. Inside fusion module, there is a mmap() which using a flag MAP_FIXED. >>> In our system the addresses it tries to map is already used by some >>> other one and we are not able to free that. >>> So is there any way to change this fixed address need?? >>> >>> Thanks a lot for your valuable time. >>> >>> -- >>> Thanks & Regards, >>> Lindo Lonappan. >>> >>> >>> >>> _______________________________________________ >>> directfb-dev mailing list >>> directfb-dev at directfb.org >>> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev >>> >> >> >> >> -- >> "The best way to find yourself is to lose yourself in the service of >> others". >> >> Shiva The Great >> > > > > -- > "The best way to find yourself is to lose yourself in the service of > others". > > Shiva The Great > > -- "The best way to find yourself is to lose yourself in the service of others". Shiva The Great -------------- next part -------------- An HTML attachment was scrubbed... URL: From jthou at c2micro.com Mon Mar 29 05:51:14 2010 From: jthou at c2micro.com (Justin Hou) Date: Mon, 29 Mar 2010 11:51:14 +0800 Subject: [directfb-dev] (no subject) In-Reply-To: <4BADDB7E.2090305@directfb.org> References: <2C9A630F1C474FF3A41FE8F0C1DF4526@c2microjthou> <4BADDB7E.2090305@directfb.org> Message-ID: <00dc01cacef3$172843d0$4578cb70$@com> Hi, Diels, Thanks very much for your answer. I've ported 1.4.0 on my chip, and seems it work well. Of course, I'm doing more test on it. You mentioned a 3D version of DirectFB can conjunct with OpenGL, and What's the version ? Can I do some porting now ? I'm going to support OpenGL Es on my chip, but not clear what's version is better. -Justin -----Original Message----- From: directfb-dev-bounces at directfb.org [mailto:directfb-dev-bounces at directfb.org] On Behalf Of Niels Roest Sent: Saturday, March 27, 2010 6:19 PM To: jthou Cc: directfb-dev at directfb.org Subject: Re: [directfb-dev] (no subject) jthou wrote: > > Hi, Denis and Niels, > > Could you help me on these questions? > > > > > > 1, What kind of Graphics standards are supported by DirectFB? > GKS? PHIGS? or some thing else? Is there a spec to conference? > For 2D pixel drawing primitives refer to the DirectFB API, which supports the basic primitives (box, rectangle, line, etc) and the basic modifiers (blending, opacity, rotation, etc). There is also a function for 3D-skewing bitmaps if your hardware supports this. For 3D vector based primitives, a development revision of DirectFB works in conjunction with OpenGL. > > 2, Does DirectFB support 3-D ? > > 3, What's the difference of DirectFB 1.2.10, DirectFB 1.4.3, > SaWMan 1.4.3? I see them are list on same level in the website. > SaWMan is an add-on window manager for DirectFB. DirectFB is DirectFB :) > > 4, I'm working on version 1.2.6. Do I need to update it to > 1.2.10 or 1.4.3? > I cannot tell. The latest is always the best, but might not be viable since you are e.g. bound by compiled drivers or required support from your hardware provider. 1.4.3 is the latest. The differences can be found in the changelogs, there are too many to list. > > > > Thank you very much. > > > > -Justin > > > > ------------------------------------------------------------------------ > > _______________________________________________ > directfb-dev mailing list > directfb-dev at directfb.org > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > -- .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list directfb-dev at directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev From zwolfox_meego at 126.com Mon Mar 29 05:52:06 2010 From: zwolfox_meego at 126.com (zwolfox_meego) Date: Mon, 29 Mar 2010 11:52:06 +0800 (CST) Subject: [directfb-dev] could directfb be ported to Android to replace framebuffer? Message-ID: <29f505.3bdb.127a80c3e0d.Coremail.zwolfox_meego@126.com> i think framebuffer is not efficient for lager screen such as 1080. so weather is possible port directfb to Android ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From luojiazhen at gmail.com Sat Mar 27 07:52:31 2010 From: luojiazhen at gmail.com (luojiazhen at gmail.com) Date: Sat, 27 Mar 2010 07:52:31 +0100 (CET) Subject: [directfb-dev] =?utf-8?q?luojiazhen=40gmail=2Ecom_l=C3=A4dt_Sie_z?= =?utf-8?q?um_GMX_OnlineChat_ein?= Message-ID: <1733116930.16897.1269672751101.JavaMail.nobody@imweb-shared002.v300.gmx.net> ------------------------------------------------------------------ luojiazhen at gmail.com l?dt Sie zum GMX OnlineChat ein ------------------------------------------------------------------ Hallo! luojiazhen at gmail.com m?chte gern mit Ihnen chatten. Bei GMX chattet man mit dem neuen OnlineChat ganz einfach. 1. Kostenlos bei GMX anmelden 2. Klick auf die OnlineChat-Sprechblasen im oberen Teil Ihres Postfachs 3. luojiazhen at gmail.com mit Ihrem neuen GMX-Account einladen Und schon k?nnen Sie mit luojiazhen at gmail.com chatten. Zur kostenlosen Anmeldung http://service.gmx.net/de/cgi/g.fcgi/products/mail/overview Viel Spa? beim Chatten w?nscht, das GMX OnlineChat-Team ------------------------------------------------------------------ Alternativ k?nnen Sie auch den MultiMessenger nutzen - chatten per Sprach- und Video-Chat und mit allen Freunden bei ICQ, MSN, Yahoo und AIM. Zum kostenlosen Download http://service.gmx.net/de/cgi/g.fcgi/products/messenger ------------------------------------------------------------------ Diese Nachricht wurde automatisch generiert. Bitte antworten Sie nicht darauf. ?ber Anregungen & Feedback freuen wir uns! http://befragungen.gmx.de/rogator/Mafo_intern/Onlinechat_GMX/ ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From shivajeekumar at gmail.com Sun Mar 28 05:09:19 2010 From: shivajeekumar at gmail.com (Shivakumar Mishra) Date: Sun, 28 Mar 2010 08:39:19 +0530 Subject: [directfb-dev] Some General doubt about fusion in DirectFB-1.0.0 In-Reply-To: <55b3397a1003272008x355a3c5bt9235672e46315317@mail.gmail.com> References: <4BA214FF.4030802@tataelxsi.co.in> <55b3397a1003272008x355a3c5bt9235672e46315317@mail.gmail.com> Message-ID: <55b3397a1003272009r26317905o5e1245fd9f8bd921@mail.gmail.com> On Sun, Mar 28, 2010 at 8:38 AM, Shivakumar Mishra wrote: > hi, > > On Thu, Mar 18, 2010 at 5:26 PM, Lindo Lonappan wrote: > >> Dear All, >> >> I am using DirectFB-1.0.0. >> >> From the code and Google, we found that IDirectFB interface is a singleton >> one. >> So the subsequent call to the DirectFBInit() will simply return without >> changing any configuration >> and DirectFBCreate() call will return a reference to first IDirectFB >> handler. >> >> Our questions are, >> >> 1. We are configured, DirectFB as single core mode(ie without any fusion >> module). >> Is this is sufficient even if there is multiple >> DirectFBInit/DirectFBCreate call from the same applications? >> >> You can call multiple times .But it will give you same instance.It has no > effect. > > >> 2. Can we control the z-order of windows in this case also? >> (The two windows are created from two different references) >> > Yes you can. > >> >> 3. If above is possible can any one lead me to the APIs for that? >> (Both at the time of Creating new window and at run time) >> > There are two ways:- > 1. Create window with different layer and SetLevel for that > layer(according to your requirement) > 2.You can use these api for specific window:- (If you want it from window > operation) > > SetStackingClass,Raise,RaiseToTop,Lower etc. go through link:- > http://directfb.org/docs/DirectFB_Reference_1_4/IDirectFBWindow.html > > >> 4. Is fusion always necessary if there is multilple applications over >> DFB? >> (I read, it is required for IPCs. Can anyone explain a little more >> details) >> > No (But necessary for smoother running of applications). > >> >> 5. Inside fusion module, there is a mmap() which using a flag MAP_FIXED. >> In our system the addresses it tries to map is already used by some >> other one and we are not able to free that. >> So is there any way to change this fixed address need?? >> >> Thanks a lot for your valuable time. >> >> -- >> Thanks & Regards, >> Lindo Lonappan. >> >> >> >> _______________________________________________ >> directfb-dev mailing list >> directfb-dev at directfb.org >> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev >> > > > > -- > "The best way to find yourself is to lose yourself in the service of > others". > > Shiva The Great > -- "The best way to find yourself is to lose yourself in the service of others". Shiva The Great -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogus@does.not.exist.com Mon Mar 29 08:43:03 2010 From: bogus@does.not.exist.com () Date: Mon, 29 Mar 2010 06:43:03 -0000 Subject: No subject Message-ID: one.
So the subsequent call to the DirectFBInit() will simply return without cha= nging any configuration
and DirectFBCreate() call will return a reference to first IDirectFB handle= r.

Our questions are,

1. We are configured, DirectFB as single core mode(ie without any fusion mo= dule).
=A0 =A0 Is this is sufficient even if there is multiple DirectFBInit/Direc= tFBCreate call from the same applications?

You can call multiple times .But it will give y= ou same instance.It has no effect.=A0
=A0
=
2. Can we control the z-order of windows in this case also?
=A0 =A0(The two windows are created from two different references)
Yes you can.=A0

3. If above is possible can any one lead me to the APIs for that?
=A0 =A0(Both at the time of Creating new window and at run time)
There are two ways:-
=A0=A01. Create window wit= h different layer and SetLevel for that layer(according to =A0your requirem= ent)
2.You can use these api for specific window:- (If you want it =A0from windo= w operation)

SetStackingClass,Raise,RaiseToTop,Low= er etc. go through link:-


4. =A0Is fusion always necessary if there is multilple applications over DF= B?
=A0 =A0(I read, it is required for IPCs. Can anyone explain a little more = details)
No (But necessary for smoother running = of applications).=A0

5. Inside fusion module, there is a mmap() which using a flag MAP_FIXED. =A0 =A0In our system the addresses it tries to map is already used by some= other one and we are not able to free that.
=A0 =A0So is there any way to change this fixed address need??

Thanks a lot for your valuable time.

--
Thanks & Regards,
Lindo Lonappan.



_______________________________________________
directfb-dev mailing list
directfb-dev= @directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directf= b-dev



= --
"The best way to find yourself is to lose yourself in the servi= ce of others".

Shiva The Great



--
"The best w= ay to find yourself is to lose yourself in the service of others".
=
Shiva The Great
--=_h0-24136-1269846522-0001-2-- From luojiazhen at gmail.com Sat Mar 27 07:52:31 2010 From: luojiazhen at gmail.com (luojiazhen at gmail.com) Date: Sat, 27 Mar 2010 07:52:31 +0100 (CET) Subject: [directfb-dev] =?utf-8?q?luojiazhen=40gmail=2Ecom_l=C3=A4dt_Sie_z?= =?utf-8?q?um_GMX_OnlineChat_ein?= Message-ID: <2044762794.16997.1269672751402.JavaMail.nobody@imweb-shared006.v300.gmx.net> ------------------------------------------------------------------ luojiazhen at gmail.com l?dt Sie zum GMX OnlineChat ein ------------------------------------------------------------------ Hallo! luojiazhen at gmail.com m?chte gern mit Ihnen chatten. Bei GMX chattet man mit dem neuen OnlineChat ganz einfach. 1. Kostenlos bei GMX anmelden 2. Klick auf die OnlineChat-Sprechblasen im oberen Teil Ihres Postfachs 3. luojiazhen at gmail.com mit Ihrem neuen GMX-Account einladen Und schon k?nnen Sie mit luojiazhen at gmail.com chatten. Zur kostenlosen Anmeldung http://service.gmx.net/de/cgi/g.fcgi/products/mail/overview Viel Spa? beim Chatten w?nscht, das GMX OnlineChat-Team ------------------------------------------------------------------ Alternativ k?nnen Sie auch den MultiMessenger nutzen - chatten per Sprach- und Video-Chat und mit allen Freunden bei ICQ, MSN, Yahoo und AIM. Zum kostenlosen Download http://service.gmx.net/de/cgi/g.fcgi/products/messenger ------------------------------------------------------------------ Diese Nachricht wurde automatisch generiert. Bitte antworten Sie nicht darauf. ?ber Anregungen & Feedback freuen wir uns! http://befragungen.gmx.de/rogator/Mafo_intern/Onlinechat_GMX/ ------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From strikosn at gmail.com Sat Mar 27 19:44:58 2010 From: strikosn at gmail.com (Strikos Nick) Date: Sat, 27 Mar 2010 20:44:58 +0200 Subject: [directfb-dev] Strange behaviour on Blit In-Reply-To: <1268185122.6952.27.camel@coalu.atr> References: <23406c481003032237o793d9f4rcf61b4d8507b1c60@mail.gmail.com> <1268185122.6952.27.camel@coalu.atr> Message-ID: <23406c481003271144s1eb56b3dm87fe83807219db85@mail.gmail.com> Hi Lionel, I'm talking about DirectFB's software fallback. The same problem also exists for rotated destination colorkeyed blits. On Wed, Mar 10, 2010 at 03:38, Lionel Landwerlin wrote: > Le jeudi 04 mars 2010 ? 08:37 +0200, Strikos Nick a ?crit : > > Hi, > > > > While running some tests, I noticed that DirectFB blits incorrectly a > > rotated, source colorkeyed image. I am using versions 1.4.2 and 1.4.3, > > and the problem can be seen if one adds DSBLIT_ROTATE* in df_dok > > example's source colorkey demo. In some cases the image is rendered > > mirrored in the X axis, in others only a single line appears. > > > > Can you reproduce this behaviour? > > Which system, gfxdriver, platform ? > > > -- > Lionel Landwerlin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.j.zhao at intel.com Tue Mar 30 05:15:22 2010 From: juan.j.zhao at intel.com (Zhao, Juan J) Date: Tue, 30 Mar 2010 11:15:22 +0800 Subject: [directfb-dev] When will DirectFB 1.4.4 release? Message-ID: Hi, When will DirectFB1.4.4 release? ----------- *^_^* Many thanks & Best Regards Zhao Juan From yusunn at gmail.com Tue Mar 30 17:37:36 2010 From: yusunn at gmail.com (yushang) Date: Tue, 30 Mar 2010 23:37:36 +0800 Subject: [directfb-dev] directfb-dev Digest, Vol 61, Issue 12 In-Reply-To: References: Message-ID: <298d852f1003300837k722a63efl96af40605ebd719a@mail.gmail.com> 1.4.3 is good enough :) 2010/3/30 : > Send directfb-dev mailing list submissions to > ? ? ? ?directfb-dev at directfb.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > or, via email, send a message with subject or body 'help' to > ? ? ? ?directfb-dev-request at directfb.org > > You can reach the person managing the list at > ? ? ? ?directfb-dev-owner at directfb.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of directfb-dev digest..." > > > Today's Topics: > > ? 1. When will DirectFB 1.4.4 release? (Zhao, Juan J) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 30 Mar 2010 11:15:22 +0800 > From: "Zhao, Juan J" > Subject: [directfb-dev] When will DirectFB 1.4.4 release? > To: "directfb-dev at directfb.org" > Message-ID: > ? ? ? ? > > Content-Type: text/plain; charset="us-ascii" > > Hi, > ? ? ? ?When will DirectFB1.4.4 release? > > ----------- > ? ?*^_^* > Many thanks & Best Regards > Zhao Juan > > > > ------------------------------ > > _______________________________________________ > directfb-dev mailing list > directfb-dev at directfb.org > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > > > End of directfb-dev Digest, Vol 61, Issue 12 > ******************************************** > From andre.draszik at st.com Tue Mar 30 21:31:13 2010 From: andre.draszik at st.com (Andre DRASZIK) Date: Tue, 30 Mar 2010 20:31:13 +0100 Subject: [directfb-dev] configure patches Message-ID: <1269977473.17530.1.camel@bril0118.bri.st.com> Hi, attached are two configure.in patches 1) convert to using AC_HELP_STRING for help texts 2) use pkg-config for libpng detection OK to commit? Cheers, Andre' From andre.draszik at st.com Fri Mar 12 05:46:25 2010 From: andre.draszik at st.com (=?UTF-8?q?Andr=C3=A9=20Draszik?=) Date: Fri, 12 Mar 2010 04:46:25 +0000 Subject: [PATCH] configure.in: use AC_HELP_STRING() where appropriate Message-ID: --- configure.in | 269 +++++++++++++++++++++++++++++++++++----------------------- 1 files changed, 162 insertions(+), 107 deletions(-) diff --git a/configure.in b/configure.in index c2f3f2d..9a9964f 100644 --- a/configure.in +++ b/configure.in @@ -56,7 +56,7 @@ AM_INIT_AUTOMAKE($PACKAGE, $VERSION, no-define) PKG_PROG_PKG_CONFIG -AM_CONFIG_HEADER(config.h) +AC_CONFIG_HEADER([config.h]) AM_MAINTAINER_MODE AC_DISABLE_STATIC @@ -110,9 +110,9 @@ AM_CONDITIONAL(HAVE_MAN2HTML, test "$MAN2HTML" != "no") dnl Test for OSX AC_ARG_ENABLE(osx, - [ --enable-osx build with Mac OS X support [[default=auto]]],, - enable_osx=yes) - + AC_HELP_STRING([--enable-osx], + [build with Mac OS X support @<:@default=auto@:>@]), + [], [enable_osx=yes]) if test "$enable_osx" = "yes"; then AC_CHECK_HEADER(Carbon/Carbon.h, osx_found=yes, osx_found=no) if test "$osx_found" = no; then @@ -128,9 +128,9 @@ AM_CONDITIONAL(OSX_CORE, test "$enable_osx" = "yes") dnl Test for X11 AC_ARG_ENABLE(x11, - [ --enable-x11 build with X11 support [[default=auto]]],, - enable_x11=yes) - + AC_HELP_STRING([--enable-x11], + [build with X11 support @<:@default=auto@:>@]), + [], [enable_x11=yes]) if test "$enable_x11" = "yes"; then PKG_CHECK_MODULES([X11], [xproto x11 xext], [enable_x11="yes"], [enable_x11="no", AC_MSG_WARN([*** no X11 found -- building without X11 support])]) @@ -152,8 +152,9 @@ CFLAGS="-O3 -ffast-math -pipe $CFLAGS" DFB_INTERNAL_CFLAGS="-D_GNU_SOURCE $DFB_INTERNAL_CFLAGS" AC_ARG_ENABLE(extra-warnings, - [ --enable-extra-warnings enable extra warnings [[default=no]]],, - enable_extra_warnings=no) + AC_HELP_STRING([--enable-extra-warnings], + [enable extra warnings @<:@default=no@:>@]), + [], [enable_extra_warnings=no]) if test "$enable_extra_warnings" = "yes"; then CFLAGS="-W -Wno-sign-compare -Wno-unused-parameter -Wundef -Wcast-qual -Wcast-align -Waggregate-return -Wmissing-declarations -Winline $CFLAGS" fi @@ -361,8 +362,9 @@ fi AC_ARG_ENABLE(profiling, - [ --enable-profiling enable profiling support [[default=no]]],, - enable_profiling=no) + AC_HELP_STRING([--enable-profiling], + [enable profiling support @<:@default=no@:>@]), + [], [enable_profiling=no]) if test "$enable_profiling" = "yes"; then CFLAGS="$CFLAGS -pg -g3" else @@ -371,8 +373,9 @@ fi AC_ARG_ENABLE(debug, - [ --enable-debug enable debugging [[default=no]]],, - enable_debug=no) + AC_HELP_STRING([--enable-debug], + [enable debugging @<:@default=no@:>@]), + [], [enable_debug=no]) if test "$enable_debug" = "yes"; then CFLAGS="$CFLAGS -g3 -fno-inline -Wno-inline" DIRECT_BUILD_DEBUG=1 @@ -385,7 +388,9 @@ AC_SUBST(DIRECT_BUILD_DEBUG) AC_ARG_ENABLE(debug-support, - [ --enable-debug-support enable debugging support [[default=yes]]],, enable_debug_support=yes) + AC_HELP_STRING([--enable-debug-support], + [enable debugging support @<:@default=yes@:>@]), + [], [enable_debug_support=yes]) if test "$enable_debug_support" = "yes" || test "$enable_debug" = "yes"; then enable_debug_support=yes DIRECT_BUILD_DEBUGS=1 @@ -398,8 +403,9 @@ AC_SUBST(DIRECT_BUILD_DEBUGS) AC_ARG_ENABLE(trace, - [ --enable-trace enable call tracing [[default=no]]],, - enable_trace=no) + AC_HELP_STRING([--enable-trace], + [enable call tracing @<:@default=no@:>@]), + [], [enable_trace=no]) if test "$enable_trace" = "yes"; then DFB_INTERNAL_CFLAGS="$DFB_INTERNAL_CFLAGS -finstrument-functions" DIRECT_BUILD_TRACE=1 @@ -412,8 +418,9 @@ AC_SUBST(DIRECT_BUILD_TRACE) AC_ARG_ENABLE(text, - [ --enable-text enable text output [[default=yes]]],, - enable_text=yes) + AC_HELP_STRING([--enable-text], + [enable text output @<:@default=yes@:>@]), + [], [enable_text=yes]) if test "$enable_text" = "no"; then DIRECT_BUILD_TEXT=0 else @@ -424,8 +431,9 @@ AC_SUBST(DIRECT_BUILD_TEXT) AC_ARG_ENABLE(gettid, - [ --enable-gettid enable usage of gettid() [[default=yes]]],, - enable_gettid=yes) + AC_HELP_STRING([--enable-gettid], + [enable usage of gettid() @<:@default=yes@:>@]), + [], [enable_gettid=yes]) if test "$enable_gettid" = "no"; then DIRECT_BUILD_GETTID=0 else @@ -436,8 +444,9 @@ AC_SUBST(DIRECT_BUILD_GETTID) AC_ARG_ENABLE(network, - [ --enable-network enable network support [[default=yes]]],, - enable_network=yes) + AC_HELP_STRING([--enable-network], + [enable network support @<:@default=yes@:>@]), + [], [enable_network=yes]) if test "$enable_network" = "no"; then DIRECT_BUILD_NETWORK=0 else @@ -454,8 +463,9 @@ AC_SUBST(DIRECT_BUILD_STDBOOL) linux_fusion="N/A" AC_ARG_ENABLE(multi, - [ --enable-multi enable multi application core [[default=no]]],, - enable_multi=no) + AC_HELP_STRING([--enable-multi], + [enable multi application core @<:@default=no@:>@]), + [], [enable_multi=no]) if test "$enable_multi" = "yes"; then dnl Test for Fusion Kernel Device linux_fusion=yes @@ -481,26 +491,30 @@ AC_SUBST(FUSION_BUILD_KERNEL) AC_ARG_ENABLE(voodoo, - [ --enable-voodoo enable Voodoo (network support) [[default=no]]],, - enable_voodoo=no) + AC_HELP_STRING([--enable-voodoo], + [enable Voodoo (network support) @<:@default=no@:>@]), + [], [enable_voodoo=no]) AM_CONDITIONAL(ENABLE_VOODOO, test "$enable_voodoo" = "yes") AC_ARG_ENABLE(unique, - [ --enable-unique enable Unique (WM Module) [[default=no]]],, - enable_unique=no) + AC_HELP_STRING([--enable-unique], + [enable Unique (WM Module) @<:@default=no@:>@]), + [], [enable_unique=no]) AM_CONDITIONAL(ENABLE_UNIQUE, test "$enable_unique" = "yes") AC_ARG_ENABLE(mmx, - [ --enable-mmx enable MMX support [[default=auto]]],, - enable_mmx=$have_x86) + AC_HELP_STRING([--enable-mmx], + [enable MMX support @<:@default=auto@:>@]), + [], [enable_mmx=$have_x86]) AC_ARG_ENABLE(sse, - [ --enable-sse enable SSE support [[default=auto]]],, - enable_sse=$have_x86) + AC_HELP_STRING([enable-sse], + [enable SSE support @<:@default=auto@:>@]), + [], [enable_sse=$have_x86]) if test "$enable_mmx" = "yes"; then @@ -528,8 +542,8 @@ if test "$enable_mmx" = "yes"; then AC_MSG_RESULT(no) AC_MSG_WARN([ **************************************************************** - The installed assembler does not supports the SSE command set. - Update your binutils package, if you want to compile SSE code. + The installed assembler does not support the SSE command set. + Update your binutils package, if you want to compile SSE code. ****************************************************************]) fi @@ -540,8 +554,8 @@ if test "$enable_mmx" = "yes"; then AC_MSG_RESULT(no) AC_MSG_WARN([ **************************************************************** - The installed assembler does not supports the MMX command set. - Update your binutils package, if you want to compile MMX code. + The installed assembler does not support the MMX command set. + Update your binutils package, if you want to compile MMX code. ****************************************************************]) fi @@ -555,10 +569,12 @@ fi AM_CONDITIONAL(BUILDMMX, test "$enable_mmx" = "yes") + dnl Test for DevMem system AC_ARG_ENABLE(devmem, - [ --enable-devmem build with generic /dev/mem support [[default=yes]]],, - enable_devmem=yes) + AC_HELP_STRING([--enable-devmem], + [build with generic /dev/mem support @<:@default=yes@:>@]), + [], [enable_devmem=yes]) AM_CONDITIONAL(DEVMEM_CORE, test "$enable_devmem" = "yes") @@ -566,8 +582,9 @@ AM_CONDITIONAL(DEVMEM_CORE, test "$enable_devmem" = "yes") dnl Test for Linux frame buffer device AC_ARG_ENABLE(fbdev, - [ --enable-fbdev build with linux fbdev support [[default=auto]]],, - enable_fbdev=yes) + AC_HELP_STRING([--enable-fbdev], + [build with linux fbdev support @<:@default=auto@:>@]), + [], [enable_fbdev=yes]) if test "$have_linux" = "no"; then enable_fbdev=no @@ -608,30 +625,34 @@ AM_CONDITIONAL(STMFBDEV_CORE, test "$enable_stmfbdev" = "yes") dnl Test for SDL AC_ARG_ENABLE(sdl, - [ --enable-sdl build with SDL support [[default=no]]],, - enable_sdl=no) - + AC_HELP_STRING([--enable-sdl], + [build with SDL support @<:@default=no@:>@]), + [], [enable_sdl=no]) if test "$enable_sdl" = "yes"; then if test "$enable_osx" = "yes"; then AC_MSG_WARN([ *** SDL is now unsupported on OSX.]) enable_sdl=no - else - PKG_CHECK_MODULES([SDL], [sdl], enable_sdl=yes, [enable_sdl=no, - AC_MSG_WARN([*** no sdl -- building without SDL support.])]) + else + PKG_CHECK_MODULES([SDL], [sdl], + [enable_sdl=yes], + [ + enable_sdl=no, + AC_MSG_WARN([*** no sdl -- building without SDL support.]) + ]) fi fi AC_SUBST(OSX_LIBS) AM_CONDITIONAL(SDL_CORE, test "$enable_sdl" = "yes") + + dnl Test for VNC AC_ARG_ENABLE(vnc, - [ --enable-vnc build with VNC support [[default=auto]]],, - enable_vnc=yes) - - - + AC_HELP_STRING([--enable-vnc], + [build with VNC support @<:@default=auto@:>@]), + [], [enable_vnc=yes]) if test "$enable_vnc" = "yes"; then AC_PATH_PROG(VNC_CONFIG, libvncserver-config, no) if test "$VNC_CONFIG" = "no"; then @@ -644,17 +665,17 @@ if test "$enable_vnc" = "yes"; then fi fi - - - AM_CONDITIONAL(VNC_CORE, test "$enable_vnc" = "yes") AC_SUBST(VNC_LIBS) AC_SUBST(VNC_CFLAGS) + + dnl Test for libsysfs AC_ARG_ENABLE(sysfs, - [ --enable-sysfs build with sysfs support [[default=auto]]],, - enable_sysfs=yes) + AC_HELP_STRING([--enable-sysfs], + [build with sysfs support @<:@default=auto@:>@]), + [], [enable_sysfs=yes]) use_sysfs=no SYSFS_LIBS= @@ -676,12 +697,14 @@ fi AC_SUBST(SYSFS_LIBS) + dnl Test for libjpeg JPEG=no AC_ARG_ENABLE(jpeg, - [ --enable-jpeg build JPEG image provider [[default=yes]]], - enable_jpeg="$enableval", enable_jpeg=yes) + AC_HELP_STRING([--enable-jpeg], + [build JPEG image provider @<:@default=yes@:>@]), + [], [enable_jpeg=yes]) if test "$enable_jpeg" = "yes"; then if test -z "$LIBJPEG"; then @@ -718,9 +741,11 @@ JPEG support is missing - many applications won't work correctly!" fi + AC_ARG_ENABLE(zlib, - [ --enable-zlib use zlib, e.g. for screen shots [[default=no]]], - enable_zlib="$enableval", enable_zlib=no) + AC_HELP_STRING([--enable-zlib], + [use zlib, e.g. for screen shots @<:@default=no@:>@]), + [], [enable_zlib=no]) use_zlib=no ZLIB_LIBS= @@ -747,9 +772,9 @@ dnl Test for libpng and libz PNG=no AC_ARG_ENABLE(png, - [ --enable-png build PNG image provider [[default=yes]]], - enable_png="$enableval", enable_png=yes) - + AC_HELP_STRING([--enable-png], + [build PNG image provider, @<:@default=yes@:>@]), + [], [enable_png=yes]) if test "$enable_png" = "yes"; then dnl Test for libz if test -z "$ZLIB_LIBS"; then @@ -825,19 +850,22 @@ PNG support is missing - many applications won't work correctly!" fi + dnl Allow to disable GIF support AC_ARG_ENABLE(gif, - [ --enable-gif build GIF image/video provider [[default=yes]]], - enable_gif="$enableval", enable_gif=yes) + AC_HELP_STRING([--enable-gif], + [build GIF image/video provider @<:@default=yes@:>@]), + [], [enable_gif=yes]) AM_CONDITIONAL(GIF_PROVIDER, test "$enable_gif" = "yes") + dnl Test for freetype AC_ARG_ENABLE(freetype, - [ --enable-freetype build FreeType2 font provider [[default=yes]]], - enable_freetype="$enableval", enable_freetype=yes) - + AC_HELP_STRING([--enable-freetype], + [build FreeType2 font provider @<:@default=yes@:>@]), + [], [enable_freetype=yes]) if test "$enable_freetype" = "yes"; then PKG_CHECK_MODULES(FREETYPE, freetype2, FREETYPE="yes", [FREETYPE="no", AC_MSG_WARN([*** no freetype -- FreeType font provider will not be built.])]) @@ -850,15 +878,17 @@ if test "$enable_freetype" != "no" && test "$FREETYPE" != "yes"; then FreeType2 support is missing - many applications won't work correctly!" fi + + dnl Test for video4linux V4L=no if test "$have_linux" = "yes"; then AC_ARG_ENABLE(video4linux, - [ --enable-video4linux build Video4Linux video provider [[default=yes]]], - enable_v4l="$enableval", enable_v4l=yes) - - if test "$enable_v4l" = "yes"; then + AC_HELP_STRING([--enable-video4linux], + [build Video4Linux video provider @<:@default=yes@:>@]), + [], [enable_video4linux=yes]) + if test "$enable_video4linux" = "yes"; then V4L=yes fi fi @@ -866,15 +896,16 @@ fi AM_CONDITIONAL(V4L_PROVIDER, test "$V4L" = "yes") + dnl Test for video4linux V4L2=no if test "$V4L" = "yes"; then AC_ARG_ENABLE(video4linux2, - [ --enable-video4linux2 build with Video4Linux2 support [[default=no]]], - enable_v4l2="$enableval", enable_v4l2=no) - - if test "$enable_v4l2" = "yes"; then + AC_HELP_STRING([--enable-video4linux2], + [build with Video4Linux2 support @<:@default=no@:>@]), + [], [enable_video4linux2=no]) + if test "$enable_video4linux2" = "yes"; then V4L2=yes AC_DEFINE( DFB_HAVE_V4L2, 1, [Define to 1 if Video4Linux 2 is supported.] ) fi @@ -911,14 +942,15 @@ if test "$have_linux" = "yes"; then AC_MSG_CHECKING(which gfxdrivers should be built) AC_ARG_WITH(gfxdrivers, -[ --with-gfxdrivers= compile gfxdrivers in ] -[ gfxdrivers may be comma separated ] -[ 'all' builds all drivers (default), 'none' builds none ] -[ Possible gfxdrivers are: ] -[ ati128, cle266, cyber5k, davinci, ep9x, gl, i810, i830, mach64,] -[ matrox, neomagic, nsc, nvidia, omap, pxa3xx, radeon, savage, sh772x,] -[ sis315, tdfx, unichrome, vmware], gfxdrivers="$withval",[gfxdrivers="all"]) - + AC_HELP_STRING([--with-gfxdrivers=LIST], + [LIST is a comma separated selection of gfxdrivers] + [to build. Possible gfxdrivers are: all (builds all] + [drivers), none (builds none), ati128, cle266,] + [cyber5k, davinci, ep9x, gl, i810, i830, mach64,] + [matrox, neomagic, nsc, nvidia, omap, pxa3xx,] + [radeon, savage, sh772x, sis315, tdfx, unichrome,] + [vmware. @<:@default=all@:>@]), + [gfxdrivers="$withval"], [gfxdrivers=all]) if test "$gfxdrivers" = "all"; then checkfor_ati128=yes checkfor_cle266=no @@ -1150,14 +1182,16 @@ checkfor_wm97xx=no AC_MSG_CHECKING(which inputdrivers should be built) AC_ARG_WITH(inputdrivers, -[ --with-inputdrivers= compile inputdrivers in ] -[ inputdrivers may be comma separated ] -[ 'all' builds all drivers (default), 'none' builds none ] -[ Possible inputdrivers are: ] -[ dbox2remote, dreamboxremote, dynapro, elo-input, gunze, h3600_ts, ] -[ joystick, keyboard, linuxinput, lirc, mutouch, penmount, ps2mouse, ] -[ serialmouse, sonypijogdial, tslib, ucb1x00, wm97xx, zytronic], -inputdrivers="$withval",[inputdrivers="all"]) + AC_HELP_STRING([--with-inputdrivers=LIST], + [LIST is a comma separated selection of] + [inputdrivers to build. Possible inputdrivers] + [are: all (builds all drivers), none (builds none),] + [dbox2remote, dreamboxremote, dynapro, elo-input,] + [gunze, h3600_ts, joystick, keyboard, linuxinput,] + [lirc, mutouch, penmount, ps2mouse, serialmouse,] + [sonypijogdial, tslib, ucb1x00, wm97xx, zytronic.] + [@<:@default=all@:>@]), + [inputdrivers="$withval"], [inputdrivers=all]) if test "$inputdrivers" = "all"; then checkfor_dbox2remote=yes @@ -1387,8 +1421,11 @@ fi fi + AC_ARG_WITH(software, - [ --without-software build without software rendering (can decrease binary size by >100k)]) + AC_HELP_STRING([--without-software], + [build without software rendering (can decrease binary size by >100k)]), + [], []) if test "$with_software" != "no"; then with_software=yes fi @@ -1396,8 +1433,11 @@ fi AM_CONDITIONAL(SOFTWARE_RENDERING, test "$with_software" != "no") + AC_ARG_WITH(smooth-scaling, - [ --with-smooth-scaling build with smooth software scaling code (can increase binary size by >100k)]) + AC_HELP_STRING([--with-smooth-scaling], + [build with smooth software scaling code (can increase binary size by >100k)]), + [], []) if test "$with_smooth_scaling" != "yes" -o "$with_software" != "yes"; then with_smooth_scaling=no else @@ -1407,16 +1447,19 @@ fi AC_SUBST(DFB_SMOOTH_SCALING) + AC_DEFINE(DFB_DITHER_SIMPLE,1,[Simple dithering, uses small dither table]) AC_DEFINE(DFB_DITHER_ADVANCED,2,[Advanced dithering, uses large dither table]) AC_ARG_WITH(dither-rgb16, - [ --with-dither-rgb16=TYPE dithering to use when loading images into RGB16 surfaces [[default=none]]] - [ Possible types are: ] - [ none - no dithering ] - [ simple - simple dithering (increases data section by 256 bytes) ] - [ advanced - advanced dithering (increases data section by 64 KBytes) ]) - + AC_HELP_STRING([--with-dither-rgb16=TYPE], + [dithering to use when loading images into RGB16] + [surfaces. Possible values for TYPE are: none] + [(no dithering), simple (simple dithering, which] + [increases the data section by 256 bytes), advanced] + [(advanced dithering, which increases the data] + [section by 64 KBytes). @<:@default=none@:>@]), + [], [with_dither_rgb16=none]) case x"$with_dither_rgb16" in x | xnone) with_dither_rgb16=none @@ -1434,39 +1477,50 @@ case x"$with_dither_rgb16" in esac + AC_ARG_WITH(tests, - [ --with-tests build test programs]) + AC_HELP_STRING([--with-tests], + [build test programs]), + [], []) if test "$with_tests" != "yes"; then with_tests=no fi + # How big of a buffer fusion uses to read messages from the fusion device AC_ARG_WITH(message-size, -[ --with-message-size=SIZE allow fusion messages up to SIZE bytes [[default=1024]]], -[ ], [with_message_size=no]) + AC_HELP_STRING([--with-message-size=SIZE], + [allow fusion messages up to SIZE bytes @<:@default=1024@:>@]), + [], [with_message_size=no]) test x"$with_message_size" = x"no" && with_message_size=1024 FUSION_MESSAGE_SIZE=$with_message_size AC_SUBST(FUSION_MESSAGE_SIZE) + # Build tools? AC_ARG_WITH(tools, - [ --without-tools do not build any tools]) + AC_HELP_STRING([--without-tools], + [do not build any tools]), + [], []) if test "$with_tools" != "no"; then with_tools=yes fi + # Sysroot used for runtime module loading, etc. AC_ARG_WITH(sysroot, -[ --with-sysroot=DIR search for lib/share et al within DIR at runtime] -[ (e.g. when loading modules)], -[ RUNTIME_SYSROOT="$withval" ], [ RUNTIME_SYSROOT= ] ) + AC_HELP_STRING([--with-sysroot=DIR], + [search for lib/share et al within DIR at runtime,] + [e.g. when loading modules]), + [ RUNTIME_SYSROOT="$withval" ], [ RUNTIME_SYSROOT= ]) test x"$RUNTIME_SYSROOT" = x"no" && RUNTIME_SYSROOT= AC_SUBST(RUNTIME_SYSROOT) + dnl *** Look for directfb-csource in PATH if we are cross-compiling *** if test "$enable_unique" = "yes"; then @@ -1479,6 +1533,7 @@ if test "$enable_unique" = "yes"; then fi + AM_CONDITIONAL(GFX_ATI128, test "$ati128" = "yes") AM_CONDITIONAL(GFX_CLE266, test "$cle266" = "yes") AM_CONDITIONAL(GFX_CYBER5K, test "$cyber5k" = "yes") -- 1.7.0 --=-O+T08A1DTz/fls0ZevOM Content-Disposition: attachment; filename="0002-configure.in-use-pkg-config-for-libpng.patch" Content-Type: text/x-patch; name="0002-configure.in-use-pkg-config-for-libpng.patch"; charset="UTF-8" Content-Transfer-Encoding: 7bit From andre.draszik at st.com Fri Mar 12 05:56:23 2010 From: andre.draszik at st.com (=?UTF-8?q?Andr=C3=A9=20Draszik?=) Date: Fri, 12 Mar 2010 04:56:23 +0000 Subject: [PATCH] configure.in: use pkg-config for libpng Message-ID: --- configure.in | 68 +++------------------------------------------------------ 1 files changed, 4 insertions(+), 64 deletions(-) diff --git a/configure.in b/configure.in index 5b7b453..720b7b0 100644 --- a/configure.in +++ b/configure.in @@ -769,7 +769,8 @@ fi AC_SUBST(ZLIB_LIBS) -dnl Test for libpng and libz + +dnl Test for libpng PNG=no AC_ARG_ENABLE(png, @@ -777,69 +778,8 @@ AC_ARG_ENABLE(png, [build PNG image provider, @<:@default=yes@:>@]), [], [enable_png=yes]) if test "$enable_png" = "yes"; then - dnl Test for libz - if test -z "$ZLIB_LIBS"; then - AC_CHECK_LIB(z, gzsetparams, - [ - AC_CHECK_HEADER(zlib.h, - ZLIB_LIBS='-lz', - AC_MSG_WARN([ -*** libz header files not found. PNG image provider will not be built.])) - ],[ - AC_MSG_WARN([ *** libz not found. PNG image provider will not be built.]) - ]) - fi - - dnl Test for libpng - if test -n "$LIBPNG_LIBS"; then - PNG=yes - else - AC_PATH_PROG(LIBPNG_CONFIG, libpng-config, no) - if test "$LIBPNG_CONFIG" = no; then - PNG=no - AC_MSG_WARN([ -*** libpng-config not found ]) - else - PNG=yes - LIBPNG_CFLAGS=`$LIBPNG_CONFIG --cflags` - LIBPNG_LIBS=`$LIBPNG_CONFIG --libs` - fi - - dnl Test for libpng - if test -z "$LIBPNG_LIBS" && test -n "$ZLIB_LIBS"; then - AC_CHECK_LIB(png, png_read_info, - [ - AC_CHECK_HEADER(png.h, - png_ok=yes, - AC_MSG_WARN([ -*** PNG header files not found. PNG image provider will not be built.])) - ],[ - AC_MSG_WARN([ -*** PNG library not found. PNG image provider will not be built.]) - ], - $ZLIB_LIBS -lm) - if test "$png_ok" = yes; then - AC_MSG_CHECKING([for png_structp in png.h]) - AC_TRY_COMPILE([#include ], - [png_structp pp; - png_infop info; - png_colorp cmap; - (void)png_create_read_struct; (void)pp; (void)info; (void)cmap;], - png_ok=yes, png_ok=no) - AC_MSG_RESULT($png_ok) - if test "$png_ok" = yes; then - PNG=yes - LIBPNG_LIBS="-lpng $ZLIB_LIBS -lm" - else - PNG=no - AC_MSG_WARN([ -*** PNG library is too old. PNG image provider will not be built.]) - fi - else - PNG=no - fi - fi - fi + PKG_CHECK_MODULES([LIBPNG], [libpng >= 1.2.2], [PNG=yes], [PNG=no + AC_MSG_WARN([*** PNG library not found. PNG image provider will not be built.])]) fi AM_CONDITIONAL(PNG_PROVIDER, test "$PNG" = "yes") -- 1.7.0 --=-O+T08A1DTz/fls0ZevOM-- From jonas at romfelt.se Wed Mar 31 09:33:02 2010 From: jonas at romfelt.se (Jonas Romfelt) Date: Wed, 31 Mar 2010 09:33:02 +0200 Subject: [directfb-dev] Synchronize custom FB device driver with DirectFB application Message-ID: Hi. I've implemented a Linux frame buffer device driver for a custom embedded board design. It was very straightforward to start using DirectFB to render graphics, thanks for the great work. My device driver has a memory buffer that is mmap'ed by DirectFB via the frame buffer mmap interface. My HW is connected to the CPU via PCIe and the driver periodically transfers the whole buffer to HW via DMA. My problem is that the transfer is limited in bandwidth and I want to synchronize the frame buffer use so that the application using DirectFB is aware of when it is OK to start rendering new data. Is there any way that it is possible to signal user space (DirectFB) from the frame buffer device that "we are currently transferring data, please hold off"? I've tried the WaitIdle() and WaitForSync() in DirectFB, how do these map to the frame buffer API or don't they? Could the frame buffer operation: int (*fb_sync)(struct fb_info *info) be used for this? Cheers, Jonas Romfelt