ps3videomode and the ps3fb driver

Hiya,

I've been messing around with various resolutions and settings for the ps3fb video driver using the ps3videomode and kernel boot arguments and I've turned up a number of problems.

720p is scaled down for some strange reason that I can't figure out, leaving black borders around the edge of the display. The scaling slows the entire machine down as it fills the PS3's busses with scaling operations, making video playback jerky and unpredictable.

Worse - the scaling causes screen artifacts that show up as horrible pixellation of any video played.
I think this is why the ps3fb driver supports a dithering mode, an attempt to make video look better in the scaled 720p mode. Of course the dithering causes more operations on the frame buffer - slowing things down even more.

720p with the "-f" fullscreen flag does not scale the image, so it gives a much better picture. It also improves the speed of the whole system, as it's not spending it's time scaling a 1280x720 image. Unfortunately it causes the edges of the screen to be overscanned off the edge of the panel - almost as anoying as the scaling was.

Ideally an improved ps3fb driver would provide a native 1366x768 res without scaling or the silly overscan problem.
The question is - how much of the ps3fb driver's functionality comes from the open-source driver itself?
If it's just a wrapper to a bunch of hypervisor calls, then there's little hope for fixing it, as only Sony control the hypervisor (unless someone engineers an exploit).

If the open-source part of the driver is genuinely capable of controlling video output modes, then we have hope of a fix coming from the linux community, but somehow I doubt that Sony left that much control available.

There seems to be nothing on any of the web forums about the inner workings of the ps3fb driver, so I took a look at the source code in the 2.6.21-rc5 kernel.

The driver code ps3fb.c shows the following interesting table :-

static const struct ps3fb_res_table ps3fb_res[] = {
/* res_x,y margin_x,y full */
{ 720, 480, 72, 48 , 0},
{ 720, 576, 72, 58 , 0},
{ 1280, 720, 78, 38 , 0},
{ 1920, 1080, 116, 58 , 0},
/* full mode */
{ 720, 480, 0, 0 , PS3FB_RES_FULL},
{ 720, 576, 0, 0 , PS3FB_RES_FULL},
{ 1280, 720, 0, 0 , PS3FB_RES_FULL},
{ 1920, 1080, 0, 0 , PS3FB_RES_FULL},
/* vesa: normally full mode */
{ 1280, 768, 0, 0 , 0},
{ 1280, 1024, 0, 0 , 0},
{ 1920, 1200, 0, 0 , 0},
{ 0, 0, 0, 0 , 0} };

The margin_x,y figures (78x and 38y pixels in the case of 720P) are the cause of the black border+scaling in 720P without overscan. Note that the fullscreen modes all specify a margin of zero, but have an additional PS3FB_RES_FULL flag to switch on overscan.

Next step is to modify the table so that margin_x,y=0 for non-fullscreen resolutions and recompile the kernel+all its modules. That will take a loooong time to do on a PS3, so I don't expect to report much progress in the immediate future.

If this works then 720P should be improved a lot - no borders, no scaling, no silly overscan.

It also seems to me that there's scope for adding modes to the driver. It will be a lot more complicated than removing the border, but I think it should be possible to hack in an extra mode for 1366x768.

For more of a clue on what's involved in adding a mode, check out the following function in ps3fb.c :-
static const struct fb_videomode ps3fb_modedb[]
I have no idea what half the numbers in this table actually do, so that's going to take some detective work.

Hey minkey,

I'd be really interested in the results of this. I've been considering building a newer kernel anyway to try and resolve an issue with my bt mighty mouse, if I could get that to work properly, and full screen no oversacan video output - I'd be over the moon

If you haven't already seen it, check out this link - it describes how to cross compile for PS3 from a desktop machine - much faster, if you can make it work I'll give it a try this weekend.

http://julipedia.blogspot.com/2007/0...l-for-ps3.html

Keep us posted!

Thanks for the cross-compiler help frl. Tomorrow being a bank holiday, I'll have some time to look into it properly.

Meanwhile, I've been headscratching about why the border settings exist at all, and I have a theory.
The margin_x,y values would make more sense in the fullscreen (overscan) modes than in the normal modes, where they would counter-act the tendency for pixels to be displayed off-screen. I think they may have been accidentally added to the wrong table.

Just a theory mind you.

Judging from reports on various forums, the amount of overscan in fullscreen mode varies depending on TV. On my Panasonic PX60, it's pretty much unusable both in the command line and X.

Thinking about it, the same happens if I run my PC into the same HDMI port use 1280x720p as the resolution. I wonder if *all* 720p images are being overscanned by my TV - not uncommon for consumer sets. The fix in ps3fb.c being to reduce the resolution right down so it fits. That would explain why full mode has 0,0 for borders - but I'm not clear what the additional "PS3FB_RES_FULL" statement would do. If that's the case though, setting the "margins" to 0,0 for all resolutions will just make all options overscan. I wonder if the solution is to reduce the number of pixels, but not to 0 - could be a case of trial and error to figure it out...

I'll have a poke around...

[Rhyme]

Hiya,

I've been fiddling with videomodes for a while too as well, and looking at the ps3fb code. Note that the git kernel sources obtainable from the link at [Please register to see this link. ] include a 1366x768 mode in the ps3fb code ( or was it 1368, can't remember). Anyway, I tried forcing X to use this resolution but have had no luck sofar :-}

Compiling a kernel on my PS3 takes about 30 minutes, so it's not too long actually. Not worth the hassle setting up a crosscompiler if you ask me (tho it is cool ofcourse ). I used the instructions at the link mentioned, but without the crosscompiling stuff. Once you have your kernel configured you can also use genkernel to build future kernels.

30 minutes? Cool - that's way faster than I expected, having heard some horror stories of 2 days+ !

Also interesting that someone's put in a 1366/8 option...even if it doesn't work

Hi guys,

I've been tinkering with ps3fb.c but with minimal success. As predicted above, lowering margins to 0,0 just results in the exact same overscanning as with the fullscreen mode, which leaves a question mark over exactly what the fullscreen flag really does.

The 1366 mode in the git repository sounds interesting, but I'm using those same sources from the same git repositury (just ran "git pul" and I'm up to date), but I can see no reference to 1366 or 1368 in ps3fb.c.

Compiling the kernel is not the terrible task I thought it would be. This means I don't have to use a cross compiler after all, except in the sense that I use 32-bit userland, so I use the cross-compile flags to compile a 64-bit kernel.

Interesting work you're doing.

Have you tried to set margin to a value between 0 and border, for example to 10-20 pixels just to get rid of the overscan effect on the tv? Will not solve the scaling problem but maybe I can live with that if I get real fullscreen without overscan.

Really annoying with the overscan on the tv, I'm thinking of buying a component cable -> vga to my tv as the vga input on the tv has full pixel support but I still want to play the games over HDMI. Does anyone have knowledge if the ps3 outputs video on hdmi and component at the same time or do I have to disconnect HDMI when I want to run linux and vice versa?

/anton

[Rhyme]

Originally Posted by minkey

The 1366 mode in the git repository sounds interesting, but I'm using those same sources from the same git repositury (just ran "git pul" and I'm up to date), but I can see no reference to 1366 or 1368 in ps3fb.c.

Oops, I lied. The diff was in modedb.c, not in ps3fb.c. It's in the same directory, a 1366 mode was added there in the git kernel sources.