The Graphics Synthesizer (GS) drivers

[frno7]

The Graphics Synthesizer (GS) frame buffer device driver drivers/video/fbdev/ps2fb.c currently operates in

1. text console mode, via the fbcon driver and its tiled API. It turned out to be a rather good fit. The GS has 4 MiB of local frame buffer video memory that is not directly accessible by the kernel due to its hardware design. No main memory is allocated for the frame buffer, which is a significant saving given that the PlayStation 2 is limited to 32 MiB of total main memory, and mmap is disabled.

   The maximum practical resolution 1920×1080p at 16 bits per pixel is 4147200 bytes, which leaves 47104 bytes for a tiled font, which at 8×8 pixels and at a minimum of a 4 bits indexed texture palette is at most 1464 characters. The indexed palette makes it easy to switch colors. struct fb_tile_ops such as fb_tileblit, fb_fillrect and fb_copyarea are accelerated by GS hardware that is very fast for the kernel via simple DMA (GIF) GS commands. The GS has two CRT merge circuits made for picture-in-picture that are used to accelerate YWRAP in hardware, which is particularly effective for console text scrolling.

   Console text operations are synchronous and therefore work properly in interrupt contexts, with kernel panics, etc. This is essential for debuggability (see also Enable the R5900 breakpoint hardware #27). Various optimisation techniques, such as buffering, can possibly be even faster, but one might want to implement that as a user space console driver via some kind of /dev/gs interface (as explained below) that can do zero-copying of GS commands, etc.

   See also Improve early printk using the Graphics Synthesizer #9 for early printk during booting.

It’s possible to implement a

2. virtual frame buffer mode, similar to the PlayStation 3 in that the whole visible main memory frame buffer is regularly copied to the GS via DMA at vertical blank intervals. This enables mmap, which is required for frame buffer compatibility, but it is otherwise very inefficient and slow. A complete copy of the whole frame buffer is allocated in main memory and GS hardware acceleration is turned off.

An interesting variant,

3. a specific Graphics Synthesizer device driver, is not yet implemented. The GS hardware is essentially a serial device that accepts a series of commands via DMA. A /dev/gs device driver could provide direct access to the GS hardware, which would be very efficient and enable most of the GS features to applications. The main drawback is that this kind of device driver is specific to the GS.

Support the Direct Rendering Manager subsystem?

[frno7]

@sp193, I'm attempting to document the privileged Graphics Synthesizer (GS) registers, and a few bit fields remain unclear. Would you be able to fill in some details?

Specifically, the SMODE1 register has many unknown fields marked with FIXME below. Its CMOD field has some kind of standard (VESA/HDTV) mode apart from PAL and NTSC. Is there a better name than gs_cmod_standard?

The field sizes for SRFSH RFSH and SYNCH1 HS are unknown. The HSEQ and HSVS fields of SYNCH1 are unknown too.

Are more fields symbolical (to be represented with enums) rather than numerical? This is somewhat important because symbols are used whenever appropriate to read/write registers with sysfs. For example, inspecting the PMODE register shows symbols for its fields MMOD, AMOD and SLBG, which is much more helpful than their numerical representations:

# cat /sys/devices/platform/gs/registers/pmode
en1 1
en2 0
crtmd 1
mmod circuit1
amod circuit1
slbg circuit2
alp 0

One or several bit fields can be written simultaneously, so even simple shell scripts can set any conceivable video mode configuration. For example, the SLBG field can be changed with:

# echo "slbg bgcolor" >/sys/devices/platform/gs/registers/pmode

These privileged GS registers and bit fields are at the moment partly unclear:

enum gs_smode1_cmod {
	gs_cmod_standard,	/* FIXME: Better name than standard? */
	/* Reserved */
	gs_cmod_ntsc = 2,	/* NTSC broadcast */
	gs_cmod_pal		/* PAL broadcast */
};

enum gs_smode1_gcont {
	gs_gcont_rgbyc,
	gs_gcont_ycrcb
};

struct gs_smode1 {
	u64 rc : 3;		/* PLL reference divider */
	u64 lc : 7;		/* PLL loop divider */
	u64 t1248 : 2;		/* PLL output divider */
	u64 slck : 1;		/* FIXME */
	u64 cmod : 2;		/* Display mode (PAL, NTSC, VESA, etc.) */
	u64 ex : 1;		/* FIXME */
	u64 prst : 1;		/* PLL reset */
	u64 sint : 1;		/* PLL (phase-locked loop) */
	u64 xpck : 1;		/* FIXME */
	u64 pck2 : 2;		/* FIXME */
	u64 spml : 4;		/* FIXME */
	u64 gcont : 1;		/* Select RGBYC or YCrCb */
	u64 phs : 1;		/* HSync output */
	u64 pvs : 1;		/* VSync output */
	u64 pehs : 1;		/* FIXME */
	u64 pevs : 1;		/* FIXME */
	u64 clksel : 2;		/* FIXME */
	u64 nvck : 1;		/* FIXME */
	u64 slck2 : 1;		/* FIXME */
	u64 vcksel : 2;		/* FIXME */
	u64 vhp : 1;		/* FIXME */
	u64 : 27;
};

struct gs_srfsh {
	u64 rfsh : 4;		/* DRAM refresh FIXME: Number of bits? */
	u64 : 60;
};

struct gs_synch1 {
	u64 hfp : 11;		/* Horizontal front porch */
	u64 hbp : 11;		/* Horizontal back porch */
	u64 hseq : 10;		/* FIXME */
	u64 hsvs : 11;		/* FIXME */
	u64 hs : 21;		/* FIXME: Number of bits? */
};

[sp193]

You should refer to the Sony documentation for the meanings behind the documented registers like PMODE.

Those undocumented registers like SMODE1 were just undocumented. The most official information you can find, is from the official PS2Linux. But they only mentioned the field names.
Everything else you might find on the Internet, were likely derived through experimentation. Other than PS2Linux, everything else went through the EE kernel to get video modes set up.

If you worked with analog video signals, some things like HBP might make sense - it requires domain knowledge that I do not have.

On a side note, setting up a video mode for PS2s requires the DVE to be configured. This device was totally replaced with the SCPH-75000 and later, and was always different on the T10000. On the PC CARD consoles, the access to the DVE required slightly different initialization. In all cases, the register interfaces are undocumented.
You may find some code from dve_reg.S of OPL, as I updated the original version from Kernelloader to support models up to the SCPH-70000.

[frno7]

Thanks! Yes, PMODE is covered by the documentation; it only served as an example in using symbolic text fields with sysfs. I'm happy about how that turned out, since it's so easy and flexible to inspect and configure whatever video mode one may wish for, including all specifics (such as overlays and picture-in-picture) that the Graphics Synthesizer can do, without any ioctls. I think it will be great for applications.

I have gathered as much as I can about SMODE1, SRFSH and SYNCH1. I have also implemented conversion functions from the standard kernel video mode timings notation. For example, the standard Linux frame buffer mode for 1920×1080 at 50 Hz progressive moved 13 px to the right to is

mode "1920x1080-50"
    # D: 148.500 MHz, H: 56.250 kHz, V: 50.000 Hz
    geometry 1920 1080 1920 1080 16
    timings 6734 148 484 36 4 88 5
    bcast true
    rgba 5/0,5/5,5/10,1/15
endmode

One can adjust these standard Linux frame buffer notation timings quite freely to adjust screen margins, refresh rates, etc. and the GS registers are recomputed accordingly.

You may find some code from dve_reg.S of OPL, as I updated the original version from Kernelloader to support models up to the SCPH-70000.

Thanks! What does the abbreviation DVE stand for? Are the DVE registers in dve_reg.S needed if the GS is reset? The Linux GS driver does not yet reset the GS, as it currently relies on the GS already being setup at boot. The GIF is reset, though.

[sp193]

It's the Digital Video Encoder. Originally a COTS device, it was eventually replaced with a Sony part. Only Sony will know what will happen if you don't do things in the right order, unfortunately. But I can tell you that it is required for proper video output. It's a reason why the "old" 576P code in GSM did not seem to work properly on some PS2 models (e.g. G/H/I/J-chassis), as GSM used to only just write to the GS priviledged registers for the 576P mode.

The configuration also involves the selection of the PLL clock input (53.9MHz for PAL, 54.0MHz for NTSC), on the F-chassis and later. They did replace the hardware differences between PAL/NTSC regions with a software switch and the DVE configuration code got longer at some point, along with the introduction of messages about a 53.9MHz/54.0MHz selection in TESTMODE. From the service manual for the GH-015 (F-chassis), the DVE gained the 54CLK_SEL input from the SSBUS Interface controller.

[rickgaiser]

I've attempted a DRM/KMS driver for the ps2 a long time ago. Perhaps the info helps.

This basic DMA driver is fully functional, but breaks some legacy (ps2 specific) interfaces:
https://github.com/rickgaiser/linux/commits/ps2-v3.8-dma

On top of that I tried a DRM/KMS driver, but it's in a terrible state (you'll risk damaging your ps2 if you try this branch, the crtc output is wrong):
https://github.com/rickgaiser/linux/commits/ps2-v3.8-dma-drm

One can adjust these standard Linux frame buffer notation timings quite freely to adjust screen margins, refresh rates, etc. and the GS registers are recomputed accordingly.

Does this mean you can now get a proper 1080p50 output? And possible other resolutions and refresh rates? Having these GS register values would be great for other software as well.

PS: Nice to see you're working on this!

[frno7]

Does this mean you can now get a proper 1080p50 output?

Yes, all modes you could reasonably expect, including both 1080p50 and 1080p60. I have also made them compatible with a popular PS2 HDMI adapter.

And possible other resolutions and refresh rates?

Yes, there are currently 34 video modes (shown below) provided for convenience. All of them are calculated from first principles so one can adjust margins, clock speeds, etc. or even invent new modes.

# cat /sys/class/graphics/fb0/modes | column
V:1280x1024p-75	V:640x480p-60	S:1920x1080i-60	U:1688x964p-50	S:1280x720p-50
V:1280x1024p-60	U:1688x964p-60	S:1280x720p-60	U:1688x964i-50	S:720x576p-50
V:1024x768p-75	U:1688x964i-60	S:720x480p-60	U:1124x644p-50	S:720x576i-50
V:1024x768p-60	U:1124x644p-60	S:720x480i-60	U:576x460p-50	S:640x512i-50
V:800x600p-75	U:576x384p-60	S:640x448i-60	U:576x460i-50	S:720x288p-50
V:800x600p-60	U:576x384i-60	S:720x240p-60	S:1920x1080p-50	S:640x256p-50
V:640x480p-75	S:1920x1080p-60	S:640x224p-60	S:1920x1080i-50

Having these GS register values would be great for other software as well.

Yes, with direct GS register access only the hardware sets the video mode configuration limits.

[frno7]

@rickgaiser, DRM/KMS is now required to proceed with #1, so I have registered #30 for it.

[Ravenslofty]

A quick note, since I can't think of anywhere better to put this: in your GS privileged register documentation, SMODE1.SPML stands for "sub-pixel magnification level".

EDIT: And SMODE1.VHP controls progressive/interlaced.
EDIT 2: Also, you have self-referential comments for SYNCV.VBP and SYNCV.VBPE. Your comments state that VBP happens after VBPE, but also that VBPE happens after VBP.

[frno7]

A quick note, since I can't think of anywhere better to put this: in your GS privileged register documentation, SMODE1.SPML stands for "sub-pixel magnification level".

Thanks, @ZirconiumX! Fixed here:

linux/arch/mips/include/asm/mach-ps2/gs.h

Line 22 in e795c48

* @spml: sub-pixel magnification level

linux/arch/mips/include/asm/mach-ps2/gs-registers.h

Line 133 in 274d9da

* @spml: sub-pixel magnification level

EDIT: And SMODE1.VHP controls progressive/interlaced.

Fixed here:

linux/arch/mips/include/asm/mach-ps2/gs-registers.h

Line 143 in 274d9da

* @vhp: 0 = interlace mode and 1 = progressive mode

EDIT 2: Also, you have self-referential comments for SYNCV.VBP and SYNCV.VBPE. Your comments state that VBP happens after VBPE, but also that VBPE happens after VBP.

Heh, right, that must be VBPE after VS, as fixed here:

linux/arch/mips/include/asm/mach-ps2/gs-registers.h

Line 266 in 274d9da

* @vbpe: halflines without color burst after @vs

[Ravenslofty]

Another one: if SYNCV.VS is number of VSYNC lines, then SYNCH1.HS must surely be number of HSYNC clocks.

EDIT: Actually, your documentation states that SYNCV.V[BF]P[E] talks about colorburst, but this is wrong because colorburst happens every horizontal sync in analogue TV, not every vertical sync.

EDIT 2: The above leads me to believe that SYNCH1.{HSEQ,HSVS} must have something to do with colorburst, but I do not have an oscilloscope to test.

[frno7]

Another one: if SYNCV.VS is number of VSYNC lines, then SYNCH1.HS must surely be number of HSYNC clocks.

Indeed, there is a certain correspondence, modulated with SPML. The HDTV modes (720×576p, 1920×1080p, etc.) computed in the vm_to_sp_hdtv function show some register relationships, how they sum, and so on (the functions vm_to_sp_sdtv for SDTV and vm_to_sp_vesa for VESA are similar):

linux/drivers/video/fbdev/ps2fb.c

Lines 1771 to 1827 in c94ed72

	static struct gs_sync_param vm_to_sp_hdtv(
	const struct fb_videomode *vm, const struct gs_synch_gen sg)
	{
	const u32 spml = sg.spml;
	const u32 t1248 = sg.t1248;
	const u32 lc = sg.lc;
	const u32 rc = sg.rc;
	const u32 vc = vm->yres <= 576 ? 1 : 0;
	const u32 hadj = spml / 2;
	const u32 vhp = (vm->vmode & FB_VMODE_INTERLACED) ? 0 : 1;
	const u32 hb = vm->xres * spml * 3 / 5;
	return (struct gs_sync_param) {
	.smode1 = {
	.vhp = vhp, .vcksel = vc, .slck2 = 1, .nvck = 1,
	.clksel = 1, .pevs = 0, .pehs = 0, .pvs = 0,
	.phs = 0, .gcont = 0, .spml = spml, .pck2 = 0,
	.xpck = 0, .sint = 1, .prst = 0, .ex = 0,
	.cmod = 0, .slck = 0, .t1248 = t1248,
	.lc = lc, .rc = rc
	},
	.smode2 = {
	.intm = (vm->vmode & FB_VMODE_INTERLACED) ? 1 : 0
	},
	.srfsh = {
	.rfsh = gs_rfsh_from_synch_gen(sg)
	},
	.synch1 = {
	.hs = vm->hsync_len * spml,
	.hsvs = (vm->left_margin + vm->xres +
	vm->right_margin - vm->hsync_len) * spml / 2,
	.hseq = vm->hsync_len * spml,
	.hbp = vm->left_margin * spml - hadj,
	.hfp = vm->right_margin * spml + hadj
	},
	.synch2 = {
	.hb = hb,
	.hf = vm->xres * spml - hb
	},
	.syncv = {
	.vs = vm->vsync_len,
	.vdp = vm->yres,
	.vbpe = 0,
	.vbp = vm->upper_margin,
	.vfpe = 0,
	.vfp = vm->lower_margin
	},
	.display = {
	.dh = vm->yres - 1,
	.dw = vm->xres * spml - 1,
	.magv = 0,
	.magh = spml - 1,
	.dy = vm->vsync_len + vm->upper_margin - 1,
	.dx = (vm->hsync_len + vm->left_margin) * spml - 1 - hadj
	}
	};
	}

EDIT: Actually, your documentation states that SYNCV.V[BF]P[E] talks about colorburst, but this is wrong because colorburst happens every horizontal sync in analogue TV, not every vertical sync.

Well, it is to say that there is no colour burst for the entirety of the horizontal line.

EDIT 2: The above leads me to believe that SYNCH1.{HSEQ,HSVS} must have something to do with colorburst, but I do not have an oscilloscope to test.

HSEQ and HSVS are computed like so, for SDTV:

linux/drivers/video/fbdev/ps2fb.c

Lines 1722 to 1723 in c94ed72

	.hsvs = cmod == gs_cmod_pal ? 1474 : 1462,
	.hseq = cmod == gs_cmod_pal ? 127 : 124,

and HDTV and VESA:

linux/drivers/video/fbdev/ps2fb.c

Lines 1800 to 1802 in c94ed72

	.hsvs = (vm->left_margin + vm->xres +
	vm->right_margin - vm->hsync_len) * spml / 2,
	.hseq = vm->hsync_len * spml,

[Ravenslofty]

Well, it is to say that there is no colour burst for the entirety of the horizontal line.

I'm sorry, I don't quite understand what you mean here. While there is no colorburst for VESA or digital TV modes, both PAL and NTSC require a colourburst in the horizontal back porch.

[frno7]

I'm sorry, I don't quite understand what you mean here. While there is no colorburst for VESA or digital TV modes, both PAL and NTSC require a colourburst in the horizontal back porch.

Perhaps a more accurate term than colour burst could be used? In any case, no pixels from the frame buffer are displayed for the given line, as I recall.

[Ravenslofty]

So, here's something which I think should be tested.

From http://martin.hinner.info/vga/pal.html

You can stop the display being interlaced if you want - the solution appears to be to just use the same sync pulse train each field, ie: the 6-5-5 one from 'field one' (which lasts 8 whole lines). I've seen it done like this in chip data sheets and tested it with my Z80 project (also confirmed with a oscilloscope connected to a Playstation2 running a non-interlaced game).

I wonder if what SMODE1.VHP actually controls is the sync pulse pattern.

[AKuHAK]

Is it possible to switch the default video mode from 1080p to standard NTSC mode? I am asking cause PS3 BC doesn't support 1080p, it supports a maximum of 480p, when setting video mode into 1080p, ps2kernel is crashing.
If I understand correctly, to lower the resolution currently I need to undefine CONFIG_PRINTK in kernel config and change in /sbin/init modprobe ps2fb mode_option=576x384i@60 ?
Also, it will be more user-friendly.

[frno7]

Is it possible to switch the default video mode from 1080p to standard NTSC mode? I am asking cause PS3 BC doesn't support 1080p, it supports a maximum of 480p, when setting video mode into 1080p, ps2kernel is crashing. If I understand correctly, to lower the resolution currently I need to undefine CONFIG_PRINTK in kernel config

I suppose it’d be the EARLY_PRINTK kernel config knob, or revert commit fce1c18 before compiling your kernel (using patch -R <gs-early-putc.patch, for instance).

and change in /sbin/init modprobe ps2fb mode_option=576x384i@60 ?

That should work, yes.

Also, it will be more user-friendly.

See #28 (comment) for ideas. Issue #9 is the one for the boot console.

[Arch91]

Sorry if I'm writting about it not in the right place, but I think that question is related to GS driver. About the absent cursor.

static void ps2fb_cb_tilecursor(struct fb_info *info,
	struct fb_tilecursor *cursor)

{
	/*
	 * FIXME: Drawing the cursor seems to require composition such as
	 * xor, which is not possible here. If the character under the
	 * cursor was known, a simple change of foreground and background
	 * colors could be implemented to achieve the same effect.
	 */
}

the function "ps2fb_cb_tilecursor" is already exists in the driver code and it is responsible for the background changing, right? The question - what kind of things (function inclusion, lines) it could contain? Can you assume anything - for example, to "miss" and this function will draw the whole screen?

Another aspect - in the GNU linux there is possible to change the background color of the cursor, the speed of it's flashing and the times after those flashing stops. For the first one, the colors can be changed using this command:
echo N > /sys/module/vt/parameters/cur_default
where N is the integer value from 0 to 15 . Will GS driver support that? Is it supporting that already now but the only thing to do is to locate the cursor position in the driver?

[frno7]

The question - what kind of things (function inclusion, lines) it could contain? Can you assume anything - for example, to "miss" and this function will draw the whole screen?

The comment in the code is an attempt to explain that the character under the cursor must be known in order to draw them both. Otherwise the cursor would overwrite the character on the screen and the character would vanish. It wouldn’t work to have the cursor ‘delete’ characters on the screen in this way. The problem could be solved by letting ps2fb_cb_tilecursor know what the character under the cursor is, which means that the generic kernel frame buffer code needs to be updated to supply the character under the cursor.

[Arch91]

The problem could be solved by letting ps2fb_cb_tilecursor know what the character under the cursor is

Let's suppose that the character is always "C" :D An uppercase third letter of the latin alphabet. Can you write an example how "ps2fb_cb_tilecursor" function could be looked like?

[frno7]

Let's suppose that the character is always "C" :D An uppercase third letter of the latin alphabet. Can you write an example how "ps2fb_cb_tilecursor" function could be looked like?

As a kernel developer in the making one would

1. study the documentation for .fb_tilecursor in

   linux/include/linux/fb.h

   Lines 346 to 353 in 59a11ab

   	struct fb_tilecursor {
   	__u32 sx; /* cursor position in the x-axis */
   	__u32 sy; /* cursor position in the y-axis */
   	__u32 mode; /* 0 = erase, 1 = draw */
   	__u32 shape; /* see FB_TILE_CURSOR_* */
   	__u32 fg; /* foreground color */
   	__u32 bg; /* background color */
   	};

2. study some of the other drivers using .fb_tilecursor (use the git grep command to find them);
3. study capabilities of the ps2fb.c driver;
4. study the capabilities of the hardware, especially the document GS User’s Manual, version 6.0, by Sony Computer Entertainment;
5. and then make a prototype.

That’s reasonable series of steps for starting to understand and implementing the cursor.

[Arch91]

2. study some of the other drivers...

By looking to the source files of the other fb drivers I found there were the persons who created that. I decided to write to him... and he responded! And answered back me the next (I think I must be careful with noting the names/nicknames, so no note here from me about that):

Ah, these drivers use tile blitting (fb_tile_ops). I have no experience
with that.
And the only upstream drivers supporting tiles use that for SVGA text mode.

However, is there really no way to XOR the image? I see there is a copyarea
function, so you can copy to offscreen memory, XOR by the CPU, and copy
back to the display memory?

[frno7]

By looking to the source files of the other fb drivers I found there were the persons who created that. I decided to write to him... and he responded!

To my knowledge it’s very tricky and inefficient to read GS memory. Confer section 4.2.2 Transmission from Local Buffer to Host p. 77 in the GS User’s Manual, and I’m not aware of any XOR function within the GS itself.

A workaround could be to have a GS local scratch buffer for saving/restoring the character under the cursor, while overdrawing said character with a cursor, but I’d suggest studying the most promising and flexible variant instead which is, I believe, to supply the character to the fb_tilecursor function.

[rickgaiser]

I think you can XOR by using alpha blending and the ALPHA register. It can do things like:
(Cs - Cd) * As + 0

Cs = source color, use full white (0xff,0xff,0xff)
Cd = destination color (the thing we want to invert)
As = source alpha, use 0x80

[frno7]

Thanks, @rickgaiser! I’ve registered issue #79 for this. Will have a cursor to play with soon.

[AKuHAK]

@frno7 looks like currently, all video modes are incompatible with composite cable, cause smode1.gcont is always 1 aka ycrcb even in low res PAL and NTSC modes. Composite cable doesn't support ycrcb, so it leads to black screen for users with such cables.

[AKuHAK]

echo "gcont rgbyc" >/sys/devices/platform/gs/registers/smode1 fixes the problem, this fix should be applied for all video modes before 640x480p, as this is the first video mode that doesnt supported by composite

[AKuHAK]

so assuming:
Progressive modes:
224p
240p
are the only 2 progressive modes that composite supports, so rgbyc should be set for them. For other progressive modes, ycrcb should be set.
Interlaced modes:
all interlaced modes up to 576i support composite, so rgbyc should be set for them
964i and 1080i are not supported so ycrcb should be set

[frno7]

echo "gcont rgbyc" >/sys/devices/platform/gs/registers/smode1 fixes the problem,

Neat. :-)

this fix should be applied for all video modes before 640x480p, as this is the first video mode that doesnt supported by composite

That would break those video modes for people having PS2 HDMI adapters, component cables, etc. I suppose there is a reason Sony made the choice between YCbCr and RGB a manual System Configuration setting for the PlayStation 2. Presumably it can’t be configured automatically to suit everyone. Isn’t this setting stored in NVRAM?

[AKuHAK]

That would break those video modes for people having PS2 HDMI adapters, component cables

But all of these types of video connectors weren't included in standard PlayStation 2 shipments, so they cannot be called "standard". All you mention is non-standard equipment and should not be set by default.

For users with such types of adapters exist high-res modes, so one can set, for example, 1080p or 480p or something else. Anyway PS3 does support only rgbyc so currently linux kernel is incompatible with that. And I dont know if it is crashing at the moment when ycrcb is set, or these can be fixed by setting rgbyc later after kernel booted.

[frno7]

But all of these types of video connectors weren't included in standard PlayStation 2 shipments, so they cannot be called "standard". All you mention is non-standard equipment and should not be set by default.

Right, but people will be happiest if the equipment (such as HDMI) they tend to use today works properly. That’s worthwhile to pay attention to, in addition to what people used to have 20 or so years ago. I just registered issue #80 for this. :-)

For users with such types of adapters exist high-res modes, so one can set, for example, 1080p or 480p or something else.

True, but how could we determine whether 1080p would work or not in the /sbin/init script of the initramfs? If we can’t, the safest choice seems to be the same video mode chosen by the Sony BIOS.

Anyway PS3 does support only rgbyc so currently linux kernel is incompatible with that. And I dont know if it is crashing at the moment when ycrcb is set, or these can be fixed by setting rgbyc later after kernel booted.

As a test, you might want to change the line

linux/drivers/video/fbdev/ps2fb.c

Line 1915 in 59a11ab

sp.smode1.gcont = gs_gcont_ycrcb;

and try that for the PS3!

[Arch91]

I had a deep dialog with @frno in the past about the fitting the videomodes resolutions to the actual screen borders, and obtained for myself that my english is not enough to explain what I mean and what I would like to be done.

However, I would like to ask the question at least about the next.
I am activating the ps2fb module using this command:
modprobe ps2fb mode_option=1920x1080p@50 mode_margin=+33+0
Then I have the prefect (almost perfect, to move the screen +1 dx from the left border and narrow to -2 dx from the right border would be even better) 1080p resolution for my TV. I consider +33 for the dx is quite a large distance! The question is
what kernel source file and where is the certain place in it I could edit so the screen for 1080p YPbPr resolution will be moved right to 33? I would like to be making that just for myself, no any pull requests)

[frno7]

Then I have the prefect (almost perfect, to move the screen +1 dx from the left border and narrow to -2 dx from the right border would be even better) 1080p resolution for my TV.

It should be possible to shrink the pixel width to fit it by speeding up the pixel clock a bit, and recalculate the margins accordingly. The fbset command is probably best for it. Study the frame buffer documentation:

linux/Documentation/fb/framebuffer.txt

Lines 217 to 253 in c94ed72

	+----------+---------------------------------------------+----------+-------+
	| | ↑ | | |
	| | |upper_margin | | |
	| | ↓ | | |
	+----------###############################################----------+-------+
	| # ↑ # | |
	| # | # | |
	| # | # | |
	| # | # | |
	| left # | # right | hsync |
	| margin # | xres # margin | len |
	|<-------->#<---------------+--------------------------->#<-------->|<----->|
	| # | # | |
	| # | # | |
	| # | # | |
	| # |yres # | |
	| # | # | |
	| # | # | |
	| # | # | |
	| # | # | |
	| # | # | |
	| # | # | |
	| # | # | |
	| # | # | |
	| # ↓ # | |
	+----------###############################################----------+-------+
	| | ↑ | | |
	| | |lower_margin | | |
	| | ↓ | | |
	+----------+---------------------------------------------+----------+-------+
	| | ↑ | | |
	| | |vsync_len | | |
	| | ↓ | | |
	+----------+---------------------------------------------+----------+-------+
	The frame buffer device expects all horizontal timings in number of dotclocks
	(in picoseconds, 1E-12 s), and vertical timings in number of scanlines.

I consider +33 for the dx is quite a large distance!

I’ve had +48 px for some devices. :-)

The question is what kernel source file and where is the certain place in it I could edit so the screen for 1080p YPbPr resolution will be moved right to 33?

Changing the default here?

linux/drivers/video/fbdev/ps2fb.c

Lines 2352 to 2358 in 59a11ab

	/*
	* Analogue devices are frequently a few pixels off. Use this mode_margin
	* option to make necessary device dependent adjustments to the built-in modes.
	*/
	module_param(mode_margin, charp, 0);
	MODULE_PARM_DESC(mode_margin,
	"Adjust initial video mode margin as \"<-|+><dx><-|+><dy>\"");

[Arch91]

to fit it by speeding up the pixel clock

Yes, I remember that this influences to the screen narrowing. But the more clock value the more faded the output; moreover, the clock value can be too high/too low so TV will not show anything anymore. That's why I abandoned the idea of fitting/perfecting the resolutions to the actual screen border.
Anyway, I would like to move the default 1080p YPbPr position to 33 px right, and

Changing the default here?

no, not here. I remember that for each of the resolutions - 480/720/1080, etc... - the screen should be moved to the right not for an equal px "distance". So, +33 for 1080p YPbPr only. I thought it would be some value among this line (line 189 in that file, I don't know how do you, guys, pasting the certain place/lines of some file)

{ "1080p", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED, FB_MODE_IS_STANDARD },

Did I assume wrong that some of these values is resposible for the x starting position?

By the way - mode_option=1920x1080p@50 - is that pal or ntsc?)

[frno7]

Yes, I remember that this influences to the screen narrowing. But the more clock value the more faded the output; moreover, the clock value can be too high/too low so TV will not show anything anymore. That's why I abandoned the idea of fitting/perfecting the resolutions to the actual screen border.

The timings of everything else should be possible to keep perfectly synchronised too, if you prolong the margins according to the pixel clock speed-up.

{ "1080p", 50, 1920, 1080, 6734, 148, 484, 36, 4, 88, 5,
FB_SYNC_BROADCAST, FB_VMODE_NONINTERLACED, FB_MODE_IS_STANDARD },

Did I assume wrong that some of these values is resposible for the x starting position?

The fbset command should, essentially, be able to use similar values. They can be put in a custom /etc/fb.modes file, see the fb.modes manual, with all adjustments you fancy. Check the fbset manual. Study its -move option for display positioning. You may also find the Modeline Calculator useful, with tutorials, documentation, and everything to get started making your own pixel-perfect video modes.

[AKuHAK]

1080p is not pal or ntsc, these division only applies to interlace modes.

[frno7]

@AKuHAK, 1080p tends to be either 50 Hz or 60 Hz, which are the traditional PAL and NTSC frequencies, after all.

[uyjulian]

If the image appears to be zoomed, I would recommend checking the TV/monitor zoom setting. Make sure it is set to "Zoom disabled" or "No zoom" or "Exact" or "1:1" mode. That should give you a pixel perfect display.

[Arch91]

...so... quite long time no any progress anywhere... Let me at least trigger some 'memories' about the project :p

A pare of questions. Let's suppose that virtual frame buffer graphic driver is completely perfect ready. Then, since it is completed,
what's the main problem was solved for it's completion?
Which X-server is usable for that driver showing the X stuff in real time as it should be (not just a screenshots of the in-memory launched X programs without graphic output using Xvfb server)?

[frno7]

I believe the main improvement over the Linux 2.x frame buffer would be to permit noncontinuous physical memory. The hardware can do it, but Linux 2.x didn’t use it (and therefore Linux 2.x has to be rebooted once memory is fragmented). Another important improvement would be a proper vertical sync, which avoids tearing during animations, etc.

I don’t know which X server would be best. In principle it should be possible to make X work directly with Graphics Synthesizer (GS) commands, and not necessarily use a virtual frame buffer. More effective, but technically more difficult too. As an alternative to X, perhaps you could consider using the GEM desktop environment? :-)

[Arch91]

As an alternative to X, perhaps you could consider using the GEM desktop environment? :-)
oh no, I wouldn't give it any chance :p
The only X server which is worths is a xorg's. As for the one of the goals I have, it's to have a working internet browser to play some browser games. Such as Super Mario Crossover. However, the days of the javascript games are passed, so I doubt that it is achievable... Well, in the same time having a good stable browser which shows everything normally is nice too.
SDL has more implementations and usabilities in Linux than some GEM :/

With the frame buffer graphic driver it make a full copy of the graphic data from the GS memory to the main memory, right? If you'd ask me, I consider the copyings times and the memory duplication are the wastes.

[frno7]

The only X server which is worths is a xorg's. As for the one of the goals I have, it's to have a working internet browser to play some browser games. Such as Super Mario Crossover. However, the days of the javascript games are passed, so I doubt that it is achievable...

Browser performance will most likely be mediocre, unfortunately. But maybe Scumm VM could be a ported nicely?

With the frame buffer graphic driver it make a full copy of the graphic data from the GS memory to the main memory, right? If you'd ask me, I consider the copyings times and the memory duplication are the wastes.

Yeah, a virtual frame buffer is often wasteful, and slow too. Its main advantage is simplicity, since it’s compatible with SDL, etc.