| Author |
Message |
|
|
 Posted: Oct 17, 2006 - 02:48 PM |
|
Joined: Jun 22, 2006
Posts: 132
Location: Greece
|
|
I'm currently developing a graphics toolkit to work just above directfb. Well, everything works great except one thing... when i use
surface->SetColor(surface, r, g, b, a)
something switches blue with red so the colors appear almost inverted from bluescale to redscale on the screen. I could get by with this by programming stuff, but when it comes to rendering images on surfaces then this becomes a major problem.
Moreover although the BSP docs say that the LCDC controller data port pins are straigtly connected to the screen, i see that the main patch to fbv makes some spurious rgb conversions.
Do you believe there is any work around for this problem? |
|
|
| |
|
|
|
|
|
|
Posted: Oct 17, 2006 - 10:14 PM |
|
Joined: Apr 26, 2006
Posts: 1071
Location: Trondheim, Norway
|
|
Hmm...there could be two different reasons for this problem:
DirectFB doesn't pay attention to the color bitfields it gets from the driver
The color bitfields exported from the driver are wrong
I'm not sure which one it is, although I _think_ the bitfields exported by the driver are correct.
The workaround is obvious, however. Just swap red and blue  |
|
|
| |
|
|
|
|
|
|
Posted: Oct 18, 2006 - 03:54 AM |
|
Joined: Aug 28, 2006
Posts: 35
|
|
I guess you didn't remove the commands fbset and fbv in the file /etc/init.d/rcS. I have found they would cause this problem. Good luck!
BTW, can drictFB support multi-processes access framebuff in the same time like X server? I am using Microwindows right now, but found dirctFB+GTK would be a good way. But just care if it can support multi-processes and multi-windows manager. |
|
|
| |
|
|
|
|
|
|
Posted: Oct 18, 2006 - 07:03 AM |
|
Joined: Jan 07, 2003
Posts: 3703
Location: Trondheim, Norway
|
|
| I managed to sort out the color issue, I gave DirectFB an other color scheme than RGB32. I think I used RGB24 instead. |
|
|
| |
|
|
|
|
|
|
Posted: Oct 18, 2006 - 11:48 AM |
|
Joined: Jun 22, 2006
Posts: 132
Location: Greece
|
|
|
hce wrote:
I managed to sort out the color issue, I gave DirectFB an other color scheme than RGB32. I think I used RGB24 instead.
Using rgb24 really fixes colors. using surface->SetColor(surface, r, g, b, a) is ok. But images are still inverted bluescale<->redscale. Isn't that very strange?
Moreover i would like to use alpha channels to make transparencies. In that case depth=32 and pixelformat=ARGB.
With these settings red converts to blue (something that you can overcome by pre-switching them before painting, or by changing the r-channel of an image to b-channel and vice versa). I managed to paint some beautifull transparencies above an image. I see that i have some extent color distortions as if i used a low setting of bpp. But the really interesting thing is that when directfb stops and the framebuffer driver takes over the color distortion goes away...
I must note that when rgb32 is used then there is no color distortion, only r<->b, both for brushes and images
Moreover i see that the framebuffer driver works with
depth 32
rgba 8/16,8/8,8/0,0/0
Depth can be manipulated but you cannot set 'a' of rgba (should be 8/24 to use alpha channels with the framebuffer driver)
Is there anyone to give proper guidance of how to fix things so as:
To have a directfb that can print transparencies without color distortions on 32bpp and without to have to switch red to blue
And finally, yes directfb can be used to create multiprocess applications. You have IDirectFB window, Event buffers per window, surface locks and unlocks, e.t.c... Of cource you need to put in some glue over those directfb features, to make your applications context-switch safe. |
|
|
| |
|
|
|
|
|
|
Posted: Oct 18, 2006 - 02:20 PM |
|
Joined: Apr 26, 2006
Posts: 1071
Location: Trondheim, Norway
|
|
|
parisino wrote:
Moreover i see that the framebuffer driver works with
depth 32
rgba 8/16,8/8,8/0,0/0
Depth can be manipulated but you cannot set 'a' of rgba (should be 8/24 to use alpha channels with the framebuffer driver)
You're right, it looks like the driver doesn't set the alpha bitfield correctly. Could you try the attached patch and see if that fixes the problem? |
|
|
| |
|
|
|
|
|
|
Posted: Oct 18, 2006 - 04:25 PM |
|
Joined: Jun 22, 2006
Posts: 132
Location: Greece
|
|
thanks for the patch. It was needed for the driver to know about alpha and it works ok but it does not solve my other problems.
For anyone that has downloaded directFB to the board
try running the file in the attachment.
It searches for an image in /home/ftp named wallpaper.jpg (copy the splash image) and shows it on screen. It sleep for 5 seconds before exiting. The code resembles the one in the directfb tutorial. No fancy stuff done, no blending.
I run this on directfb settings 320x240, 32 bpp, rgb32 pixelformat.
What i get is an image that flickers a little (although printed on screen) and has a quite nasty color distortion (that gets a lot worse when blending). When the sleep finishes and directfb cleans up (when IDirectFB interface gets released - variable dfb in the c code), then you see the image clearly without any noise.
Do i only see this or this is a generic problem? Any clues on this? I have tried with other formats (gif, png) same shit. I have downloaded the latest of directfb, libjpeg, libpng, libfreetype.
Thanks in advance mates |
|
|
| |
|
|
|
|
|
|
Posted: Oct 18, 2006 - 04:29 PM |
|
Joined: Jun 22, 2006
Posts: 132
Location: Greece
|
|
| You should also see the image as if red became blue and vice versa both in rgb32, rgb24 and argb |
|
|
| |
|
|
|
|
|
|
Posted: Oct 18, 2006 - 04:42 PM |
|
Joined: Apr 26, 2006
Posts: 1071
Location: Trondheim, Norway
|
|
|
parisino wrote:
What i get is an image that flickers a little (although printed on screen) and has a quite nasty color distortion (that gets a lot worse when blending). When the sleep finishes and directfb cleans up (when IDirectFB interface gets released - variable dfb in the c code), then you see the image clearly without any noise.
Ah, crap, I think I know what this is. The sidsafb driver uses a flag in fb_var_screeninfo.sync to determine the polarity of the pixel clock, and it seems like any userspace program that changes any framebuffer settings needs to know about this; otherwise the flag might not get preserved when switching modes.
If the pixel clock polarity is wrong, the LCD panel will sample the data lines while they are toggling, causing quite a bit of distortion.
The fbset utility distributed with the BSP knows about this flag, so it can switch modes without messing with the pixel clock polarity.
Could you try this quick-n-dirty hack to verify if this is indeed the problem? |
|
|
| |
|
|
|
|
|
|
Posted: Oct 18, 2006 - 05:12 PM |
|
Joined: Jun 22, 2006
Posts: 132
Location: Greece
|
|
|
how wrote:
Ah, crap, I think I know what this is.
You knew it all the way didn't ya? hahahaha
Genious how... really great. Whenever you run into something dont hesitate to send me a pm. Will be very glad to help you.
This was the problem indeed. Furthermore when you need to render an image on a surface you just set the surface's pixel format to RGB24 and you get rid of the red swapped with blue problem.
I will send you a screenshot soon!
BTW is there something to be done from my userland programs (or directfb) to fix this pixelclock polarity issue, or this will be solved entirely in the kernel? |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
