Why is Zaxxon's X server running in 16 bits ?


Because OMAP X driver did not support anything else at the time OS was being brought up.


Downsides are slower speed, more memory being used, 16bpp games having to do color conversion and so on.
 
I did catch a gtk theme ('outcrop') with highly noticeable and ugly banding the other day - is this likely to be the culprit?
 
Last edited by a moderator:
Ah ok, thanks for clarifying.


Some Qt4 apps look also ugly.
 
Last edited by a moderator:
notaz said:
Because OMAP X driver did not support anything else at the time OS was being brought up.


Downsides are slower speed, more memory being used, 16bpp games having to do color conversion and so on.
Click to expand...

Is there a way to get 32bpp overlays? If so is SDL utilizing it?
 
Last edited by a moderator:
Maybe there should be an easy way to switch between 16bpp and 24bpp. For desktop use (including things like browsing, viewing pictures or movies, etc.), I suspect most people will prefer 24bpp, because the difference is noticeable (esp. banding in gradients can be really ugly) and 16bpp makes the Pandora screen look crappier than it really is.
 
Last edited by a moderator:
Does the LCD support bitdepths higher than 16bpp? Pretty sure I remember reading that it ran natively at 16bpp, but... my memory could be hazy there.


D.
 
notaz said:
Yes and yes (if the app asks for it).
Click to expand...

Excellent, thanks for letting me know :D

ZXDunny said:
Does the LCD support bitdepths higher than 16bpp? Pretty sure I remember reading that it ran natively at 16bpp, but... my memory could be hazy there.


D.
Click to expand...

Yes, it's true 24-bit.


A lot of LCDs are still 18-bit (sometimes with builtin dithering) but you'd be hard pressed to find one that's < 16-bit, and you probably won't find a 16-bit one.
 
Last edited by a moderator:
I was not able to get the omapfb X driver to accept 24 bit mode but the omapfb kernel driver does work in "32bit" mode (using SZ 1.52 with the kernel 3.2). So if anybody has hints on getting that omapfb X driver to accept 24 bpp go ahead...


Anyways the basic fbdev driver accepts 24bpp just fine and the X runs in 24bit - proven by a lack of banding in my chosen xfce loading screen named "Balou". The loss is that fbdev doesnt have xv support so the basic mplayer will barf and fallback on the slow x11 output. But SMPlayer2's omapfb output still works. A few old pnds I had lying around - old xbmc beta and tuxrace fail with "No valid X11 visual" in the log - this could be that they want 16bit or that they want some omapfb function (I'm guessing open gl es might not work in 24bpp?)


I'll come and edit in my changes to xorg.conf here in a minute with the pandora.


From 'doras xorg.conf:



Code: 
Section "Screen"

	    Identifier	  "Screen0"

	    Device		  "FBDEV"

	    Monitor		 "Monitor0"

	    DefaultDepth    24

	    SubSection "Display"

			    Depth   24

			    FbBpp   32

			    Modes   "800x480"

	    EndSubSection

EndSection

FbBpp is propably unnecessary, it got left in from fighting with omapfb.
 
Last edited by a moderator:
In /etc/init.d/slim-init, change to:


fbset -depth 24


In /etc/X11/xorg.conf:


DefaultDepth 24


SubSection "Display"


Depth 24


Should work.
 
Last edited by a moderator:
Do we have a better way to do this in SuperZaxxon yet?
 
Last edited by a moderator:
Hey interesting Thread :)

But why need anyone 32 Bit?

The maximum Colours that an Eye can see are 24 Bit...

(Learned that in Differrent Seller Trainings)

24Bit are Nice but there is no visible differrent to 32 Bit Desktop Color depth.

:)
 
32 bits per pixel doesn't mean that the colors are actually encoded in 32 bit (at least not in this case). It's still 24 bits for the color, the 8 bits are used for something else or they're just for padding. That's because it's a lot more efficient to address individual 32-bit elements than packed 24-bit ones.
 
My last Slackware-current builds works in 24 bits, as many apps look nicer, especially KDE stuff.

The only glitch i found is with fbgrab who takes bad screen captures. Other cap apps work fine.
 
As Exophase says, I'd rather have the higher speed of 32bit than have to suffer the penalties of 24bit. And if that's not available, 16bit is faster still than 24bit I'd imagine - correct me if I'm wrong on that last one!

D.
 
Linux-SWAT said:
A bench would be interesting.
Click to expand...
Is there a way to make Pandora SuperZaxxon desktop work with either 24bit or 32bit, and if so - how?

Linux-SWAT ... can you edit the first post with precise directions...?

I could then try to make a "colour depth switch" PND.

I don't know if urjaman's solution with different framebuffer works, Linux-SWAT's suggestion that "should work" does not work for me.
 
Last edited by a moderator:
First, i enable


fbset -depth 32
at boot.

Then in xorg.conf:

Code: 
Section "Screen"
        Identifier      "Screen0"
        Device          "OMAPFB"
        Monitor         "Monitor0"
        DefaultDepth    24
        SubSection "Display"
	  Depth        24
	  Modes	"800x480"
       EndSubSection
EndSection
 
You must log in or register to reply here.

Similar threads

H
GP2X Minlib Button Mapping
Replies
0
Views
1K
[hjd_uk]
H
O
GP2X Color Scheme In Gp2x?
Replies
6
Views
2K
Dryer Lint
D
R
GP2X Gp2x Executable Format
2 3 4
Replies
64
Views
11K
Squidge
S
A
GP2X X Server
Replies
8
Views
2K
paranoidd
P
C
GP32 Fixed Point Math
Replies
3
Views
2K
mithris
M
Back
Top