Re: [Nouveau] [PATCH v7 22/23] drm/vc4: vec: Add support for more analog TV standards

2022-11-09 Thread Lukas Satin
That's great, I will test it on Ubuntu + Nouveau x86_64 and Batocera-Linux.

I'm not interested in Raspberry Pi. I see you have some commit in
RaspberryPi/Linux. Will this go to some Nouveau driver, so I can test it on
x86_64 machine? I have some basic experience compiling Linux kernel (nvidia
driver) from 10 years ago.

Scaling is not the way to go because I do this to not use scaling. I could
use 640x480 and scale 320x240 to that mode, right? That is what old
retrogaming laptop LCD screens do (you can even enable this in their BIOS).

More appropriate is to preserve pixel ratio and have some border. So you
mostly select the closest resolution and live with small border on the
edge. Then you can crop it on analog TV using real world dials :-)

I joined Nouveau developer list here. I don't know why we have like 40
email recipients here and now we discuss Raspberry. Anyway, I would like to
see this in Nouveau, so I could test it on several Geforce devices with TV
out and Windows Media Center devices such as Acer iDEA 510. Such devices
have SCART and component out, they did cost quite a lot and nowadays you
can get them for 30-50 EUR. It is cheaper that Raspberry with all the
additional cables and have better video output quality (RGB is better than
CVBS).

There was NVTV utility that can do this in Linux, but that works only for
Geforce 3 and older. That would make sense if you get Intel Core Quad
motherboard with AGP slot (yes they do exist).

So I'm collecting various retrogaming hardware, have 8 computers on single
KVM and CRT, several big box games and 20 computers total. Two Sony PVM's,
one JVC, several CRT's and Samsung QLED with HDR as well. I prefer CRT :-)

So can we have this NVTV functionality or this above Rasp commit in
Nouveau, so I can test it with Nvidia GPU even it takes me whole weekend to
mess around?

When it works, I would like to present it to regular retrogaming community
and give you a proper credit, of course.

Thank you,
Lukas

On Wed, Nov 9, 2022 at 2:15 AM Mateusz Kwiatkowski 
wrote:

> Hi Maxime,
>
> I ran your v7 patchset on my Pi with Xorg, and the mode switching, as well
> as
> the preferred mode handling, all work really well now!
>
> I just noted that the downstream version of the vc4 driver still has
> inaccurate
> field delays in vc4_crtc.c, which causes vertical lines to appear jagged
> (like
> here:
> https://user-images.githubusercontent.com/4499762/112738569-385c3280-8f64-11eb-83c4-d671537af209.png
> ).
> This has been fixed downstream in
>
> https://github.com/raspberrypi/linux/pull/4241/commits/bc093f27bf2613ec93524fdc19e922dd7dd3d800
> ,
> but I guess that should be upstreamed separately...?
>
> Anyway, it's unrelated to the changes made in this patchset, so... I'm not
> sure
> if I'm qualified or allowed to do these, but just in case:
>
> Tested-by: Mateusz Kwiatkowski 
>
> (that pretty much applies to parts 19-22 in general, I can respond to those
> messages as well if you wish)
>
> Best regards,
> Mateusz Kwiatkowski
>
> W dniu 7.11.2022 o 15:16, Maxime Ripard pisze:
> > From: Mateusz Kwiatkowski 
> >
> > Add support for the following composite output modes (all of them are
> > somewhat more obscure than the previously defined ones):
> >
> > - NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
> >   4.43361875 MHz (the PAL subcarrier frequency). Never used for
> >   broadcasting, but sometimes used as a hack to play NTSC content in PAL
> >   regions (e.g. on VCRs).
> > - PAL_N - PAL with alternative chroma subcarrier frequency,
> >   3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay
> >   and Uruguay to fit 576i50 with colour in 6 MHz channel raster.
> > - PAL60 - 480i60 signal with PAL-style color at normal European PAL
> >   frequency. Another non-standard, non-broadcast mode, used in similar
> >   contexts as NTSC_443. Some displays support one but not the other.
> > - SECAM - French frequency-modulated analog color standard; also have
> >   been broadcast in Eastern Europe and various parts of Africa and Asia.
> >   Uses the same 576i50 timings as PAL.
> >
> > Also added some comments explaining color subcarrier frequency
> > registers.
> >
> > Acked-by: Noralf Trønnes 
> > Signed-off-by: Mateusz Kwiatkowski 
> > Signed-off-by: Maxime Ripard 
> >
> > ---
> > Changes in v6:
> > - Support PAL60 again
> > ---
> >  drivers/gpu/drm/vc4/vc4_vec.c | 111
> --
> >  1 file changed, 107 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_vec.c
> b/drivers/gpu/drm/vc4/vc4_vec.c
> > index a828fc6fb776..d23dbad3cbf6 100644
> > --- a/drivers/gpu/drm/vc4/vc4_vec.c
> > +++ b/drivers/gpu/drm/vc4/vc4_vec.c
> > @@ -46,6 +46,7 @@
> >  #define VEC_CONFIG0_YDEL(x)  ((x) << 26)
> >  #define VEC_CONFIG0_CDEL_MASKGENMASK(25, 24)
> >  #define VEC_CONFIG0_CDEL(x)  ((x) << 24)
> > +#define VEC_CONFIG0_SECAM_STDBIT(21)
> >  #define 

Re: [Nouveau] [PATCH v7 06/23] drm/modes: Add a function to generate analog display modes

2022-11-08 Thread Lukas Satin
Hi, your statement:

"However, analog display usually have fairly loose timings requirements,
the only discrete parameters being the total number of lines and pixel
clock frequency."

Please do not make it as a rule. You said yourself: "usually". Arcade CRT
have more loose timings, but professional broadcast TV's such as Sony PVM,
Sony BVM, JVC. These cost tens of thousand dollars back in the day. Now
they are affordable for gamers. I just solved issue in Retroarch, CRT
Switchres library here: https://github.com/antonioginer/switchres/issues/96

This model is quite common among retrogamers and on Reddit.

Some developers do not test it properly.

This model requires exact number of lines.

For Switchres we came up with these ranges:

crt_range0 15625-15750, 49.50-65.00, 2.000, 4.700, 8.000,
0.064, 0.192, 1.024, 1, 1, 192, 288, 0, 0
crt_range1 15625.00-15625.00, 50.00-50.00, 1.500, 4.700,
5.800, 0.064, 0.160, 1.056, 1, 1, 0, 0, 448, 576
crt_range2 15734.26-15734.26, 59.94-59.94, 1.500, 4.700,
4.700, 0.191, 0.191, 0.953, 1, 1, 0, 0, 448, 480

crt_range0 is default, more loose definition for MAME emulators. crt_range1
is PAL and crt_range2 is NTSC.

Yes, this model does support both NTSC and PAL.

Does your driver or library support that?

For example old driver in Windows 7 with NVIDIA 2007 driver on Geforce 7600
can support both NTSC and PAL and these are being switched automatically by
the resolution you choose. So in desktop properties, you change to 640x480
and it will switch TV chipset to NTSC 480i. Then you change to 720x576 and
it will switch TV chipset to PAL 576i.

It would be preferred if advanced users could set up these numbers from a
commandline during a runtime, so it would depend on the app being used.

Lukas

On Mon, Nov 7, 2022 at 3:17 PM Maxime Ripard  wrote:

> Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
> 625-lines modes in their drivers.
>
> Since those modes are fairly standard, and that we'll need to use them
> in more places in the future, it makes sense to move their definition
> into the core framework.
>
> However, analog display usually have fairly loose timings requirements,
> the only discrete parameters being the total number of lines and pixel
> clock frequency. Thus, we created a function that will create a display
> mode from the standard, the pixel frequency and the active area.
>
> Signed-off-by: Maxime Ripard 
>
> ---
> Changes in v6:
> - Fix typo
>
> Changes in v4:
> - Reworded the line length check comment
> - Switch to HZ_PER_KHZ in tests
> - Use previous timing to fill our mode
> - Move the number of lines check earlier
> ---
>  drivers/gpu/drm/drm_modes.c| 474
> +
>  drivers/gpu/drm/tests/Makefile |   1 +
>  drivers/gpu/drm/tests/drm_modes_test.c | 144 ++
>  include/drm/drm_modes.h|  17 ++
>  4 files changed, 636 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 5d4ac79381c4..71c050c3ee6b 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -116,6 +116,480 @@ void drm_mode_probed_add(struct drm_connector
> *connector,
>  }
>  EXPORT_SYMBOL(drm_mode_probed_add);
>
> +enum drm_mode_analog {
> +   DRM_MODE_ANALOG_NTSC, /* 525 lines, 60Hz */
> +   DRM_MODE_ANALOG_PAL, /* 625 lines, 50Hz */
> +};
> +
> +/*
> + * The timings come from:
> + * -
> https://web.archive.org/web/20220406232708/http://www.kolumbus.fi/pami1/video/pal_ntsc.html
> + * -
> https://web.archive.org/web/20220406124914/http://martin.hinner.info/vga/pal.html
> + * -
> https://web.archive.org/web/20220609202433/http://www.batsocks.co.uk/readme/video_timing.htm
> + */
> +#define NTSC_LINE_DURATION_NS  63556U
> +#define NTSC_LINES_NUMBER  525
> +
> +#define NTSC_HBLK_DURATION_TYP_NS  10900U
> +#define NTSC_HBLK_DURATION_MIN_NS  (NTSC_HBLK_DURATION_TYP_NS - 200)
> +#define NTSC_HBLK_DURATION_MAX_NS  (NTSC_HBLK_DURATION_TYP_NS + 200)
> +
> +#define NTSC_HACT_DURATION_TYP_NS  (NTSC_LINE_DURATION_NS -
> NTSC_HBLK_DURATION_TYP_NS)
> +#define NTSC_HACT_DURATION_MIN_NS  (NTSC_LINE_DURATION_NS -
> NTSC_HBLK_DURATION_MAX_NS)
> +#define NTSC_HACT_DURATION_MAX_NS  (NTSC_LINE_DURATION_NS -
> NTSC_HBLK_DURATION_MIN_NS)
> +
> +#define NTSC_HFP_DURATION_TYP_NS   1500
> +#define NTSC_HFP_DURATION_MIN_NS   1270
> +#define NTSC_HFP_DURATION_MAX_NS   2220
> +
> +#define NTSC_HSLEN_DURATION_TYP_NS 4700
> +#define NTSC_HSLEN_DURATION_MIN_NS (NTSC_HSLEN_DURATION_TYP_NS - 100)
> +#define NTSC_HSLEN_DURATION_MAX_NS (NTSC_HSLEN_DURATION_TYP_NS + 100)
> +
> +#define NTSC_HBP_DURATION_TYP_NS   4700
> +
> +/*
> + * I couldn't find the actual tolerance for the back porch, so let's
> + * just reuse the sync length ones.
> + */
> +#define NTSC_HBP_DURATION_MIN_NS   (NTSC_HBP_DURATION_TYP_NS - 100)
> +#define NTSC_HBP_DURATION_MAX_NS   

Re: [Nouveau] [PATCH v7 00/23] drm: Analog TV Improvements

2022-11-08 Thread Lukas Satin
One can switch from NTSC to PAL now using (on vc4)

modetest -M vc4  -s 53:720x480i -w 53:'TV mode':1 # NTSC
modetest -M vc4  -s 53:720x576i -w 53:'TV mode':4 # PAL


NTSC should be 640x480i, not 720. It will probably work on most TV's, but
NTSC by the spec is 640x480i.

On Mon, Nov 7, 2022 at 3:16 PM Maxime Ripard  wrote:

> Hi,
>
> Here's a series aiming at improving the command line named modes support,
> and more importantly how we deal with all the analog TV variants.
>
> The named modes support were initially introduced to allow to specify the
> analog TV mode to be used.
>
> However, this was causing multiple issues:
>
>   * The mode name parsed on the command line was passed directly to the
> driver, which had to figure out which mode it was suppose to match;
>
>   * Figuring that out wasn't really easy, since the video= argument or what
> the userspace might not even have a name in the first place, but
> instead could have passed a mode with the same timings;
>
>   * The fallback to matching on the timings was mostly working as long as
> we were supporting one 525 lines (most likely NSTC) and one 625 lines
> (PAL), but couldn't differentiate between two modes with the same
> timings (NTSC vs PAL-M vs NSTC-J for example);
>
>   * There was also some overlap with the tv mode property registered by
> drm_mode_create_tv_properties(), but named modes weren't interacting
> with that property at all.
>
>   * Even though that property was generic, its possible values were
> specific to each drivers, which made some generic support difficult.
>
> Thus, I chose to tackle in multiple steps:
>
>   * A new TV mode property was introduced, with generic values, each driver
> reporting through a bitmask what standard it supports to the userspace;
>
>   * This option was added to the command line parsing code to be able to
> specify it on the kernel command line, and new atomic_check and reset
> helpers were created to integrate properly into atomic KMS;
>
>   * The named mode parsing code is now creating a proper display mode for
> the given named mode, and the TV standard will thus be part of the
> connector state;
>
>   * Two drivers were converted and tested for now (vc4 and sun4i), with
> some backward compatibility code to translate the old TV mode to the
> new TV mode;
>
> Unit tests were created along the way.
>
> One can switch from NTSC to PAL now using (on vc4)
>
> modetest -M vc4  -s 53:720x480i -w 53:'TV mode':1 # NTSC
> modetest -M vc4  -s 53:720x576i -w 53:'TV mode':4 # PAL
>
> Let me know what you think,
> Maxime
>
> To: David Airlie 
> To: Daniel Vetter 
> To: Maarten Lankhorst 
> To: Maxime Ripard 
> To: Thomas Zimmermann 
> To: Emma Anholt 
> To: Jani Nikula 
> To: Joonas Lahtinen 
> To: Rodrigo Vivi 
> To: Tvrtko Ursulin 
> To: Ben Skeggs 
> To: Karol Herbst 
> To: Lyude Paul 
> To: Chen-Yu Tsai 
> To: Jernej Skrabec 
> To: Samuel Holland 
> Cc: Geert Uytterhoeven 
> Cc: Mateusz Kwiatkowski 
> Cc: "Noralf Trønnes" 
> Cc: Dave Stevenson 
> Cc: Dom Cobley 
> Cc: Phil Elwell 
> Cc: 
> Cc: linux-ker...@vger.kernel.org
> Cc: intel-...@lists.freedesktop.org
> Cc: nouveau@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-su...@lists.linux.dev
> Cc: Hans de Goede 
> Signed-off-by: Maxime Ripard 
>
> ---
> Changes in v7:
> - Switch to another implementation of get_modes from Noralf
> - Made more checks in VEC's atomic_check
> - Fixed typo in a commit log
> - Checked for tv_mode_specified in
> drm_mode_parse_command_line_for_connector
> - Rebased on drm-misc-next-2022-11-03
> - Link to v6:
> https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v6-0-e77927341...@cerno.tech
>
> Changes in v6:
> - Add and convert to a new get_modes helper to create the PAL and NTSC
> modes in
>   the proper order, with the right preferred mode flag, depending on the
> driver
>   capabilities and defaults.
> - Support PAL60
> - Renamed tests to be consistent with DRM tests naming convention
> - Simplified a bit the named mode parsing code
> - Add a tv_mode_specified field
> - Return 0 in get_modes implementations instead of error codes
> - Link to v5:
> https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v5-0-d841cc64f...@cerno.tech
>
> Changes in v5:
> - Dropped TV Standard documentation removal
> - Switched the TV Mode documentation from CSV to actual documentation
> - Switched to kunit assertions where possible
> - Switched to KUNIT_ASSERT_NOT_NULL instead of KUNIT_ASSERT_PTR_NE(...,
> NULL)
> - Shuffled a bit the introduction of
> drm_client_modeset_connector_get_modes between patches
> - Renamed tv_mode_names to legacy_tv_mode_names
> - Removed the count variable in sun4i_tv_comp_get_modes
> - Rebased on top of current drm-misc-next
> - Link to v4:
> https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v4-0-60d38873f...@cerno.tech
>
> Changes in v4:
> - Removed the unused TV Standard property documentation
> 

Re: [Nouveau] [PATCH v7 22/23] drm/vc4: vec: Add support for more analog TV standards

2022-11-08 Thread Lukas Satin
They are important for retrogaming and connecting TV out to CRT TV or using
emulator.

I have PS1 that is using PAL-60 for example.

Can you add 240p and 288p non-interlaced modes for NTSC and PAL, please?

Lukas

On Mon, Nov 7, 2022 at 3:19 PM Maxime Ripard  wrote:

> From: Mateusz Kwiatkowski 
>
> Add support for the following composite output modes (all of them are
> somewhat more obscure than the previously defined ones):
>
> - NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
>   4.43361875 MHz (the PAL subcarrier frequency). Never used for
>   broadcasting, but sometimes used as a hack to play NTSC content in PAL
>   regions (e.g. on VCRs).
> - PAL_N - PAL with alternative chroma subcarrier frequency,
>   3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay
>   and Uruguay to fit 576i50 with colour in 6 MHz channel raster.
> - PAL60 - 480i60 signal with PAL-style color at normal European PAL
>   frequency. Another non-standard, non-broadcast mode, used in similar
>   contexts as NTSC_443. Some displays support one but not the other.
> - SECAM - French frequency-modulated analog color standard; also have
>   been broadcast in Eastern Europe and various parts of Africa and Asia.
>   Uses the same 576i50 timings as PAL.
>
> Also added some comments explaining color subcarrier frequency
> registers.
>
> Acked-by: Noralf Trønnes 
> Signed-off-by: Mateusz Kwiatkowski 
> Signed-off-by: Maxime Ripard 
>
> ---
> Changes in v6:
> - Support PAL60 again
> ---
>  drivers/gpu/drm/vc4/vc4_vec.c | 111
> --
>  1 file changed, 107 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> index a828fc6fb776..d23dbad3cbf6 100644
> --- a/drivers/gpu/drm/vc4/vc4_vec.c
> +++ b/drivers/gpu/drm/vc4/vc4_vec.c
> @@ -46,6 +46,7 @@
>  #define VEC_CONFIG0_YDEL(x)((x) << 26)
>  #define VEC_CONFIG0_CDEL_MASK  GENMASK(25, 24)
>  #define VEC_CONFIG0_CDEL(x)((x) << 24)
> +#define VEC_CONFIG0_SECAM_STD  BIT(21)
>  #define VEC_CONFIG0_PBPR_FIL   BIT(18)
>  #define VEC_CONFIG0_CHROMA_GAIN_MASK   GENMASK(17, 16)
>  #define VEC_CONFIG0_CHROMA_GAIN_UNITY  (0 << 16)
> @@ -76,6 +77,27 @@
>  #define VEC_SOFT_RESET 0x10c
>  #define VEC_CLMP0_START0x144
>  #define VEC_CLMP0_END  0x148
> +
> +/*
> + * These set the color subcarrier frequency
> + * if VEC_CONFIG1_CUSTOM_FREQ is enabled.
> + *
> + * VEC_FREQ1_0 contains the most significant 16-bit half-word,
> + * VEC_FREQ3_2 contains the least significant 16-bit half-word.
> + * 0x8000 seems to be equivalent to the pixel clock
> + * (which itself is the VEC clock divided by 8).
> + *
> + * Reference values (with the default pixel clock of 13.5 MHz):
> + *
> + * NTSC  (3579545.[45] Hz) - 0x21F07C1F
> + * PAL   (4433618.75 Hz)   - 0x2A098ACB
> + * PAL-M (3575611.[888111] Hz) - 0x21E6EFE3
> + * PAL-N (3582056.25 Hz)   - 0x21F69446
> + *
> + * NOTE: For SECAM, it is used as the Dr center frequency,
> + * regardless of whether VEC_CONFIG1_CUSTOM_FREQ is enabled or not;
> + * that is specified as 4406250 Hz, which corresponds to 0x29C71C72.
> + */
>  #define VEC_FREQ3_20x180
>  #define VEC_FREQ1_00x184
>
> @@ -118,6 +140,14 @@
>
>  #define VEC_INTERRUPT_CONTROL  0x190
>  #define VEC_INTERRUPT_STATUS   0x194
> +
> +/*
> + * Db center frequency for SECAM; the clock for this is the same as for
> + * VEC_FREQ3_2/VEC_FREQ1_0, which is used for Dr center frequency.
> + *
> + * This is specified as 425 Hz, which corresponds to 0x284BDA13.
> + * That is also the default value, so no need to set it explicitly.
> + */
>  #define VEC_FCW_SECAM_B0x198
>  #define VEC_SECAM_GAIN_VAL 0x19c
>
> @@ -197,10 +227,15 @@ enum vc4_vec_tv_mode_id {
> VC4_VEC_TV_MODE_NTSC_J,
> VC4_VEC_TV_MODE_PAL,
> VC4_VEC_TV_MODE_PAL_M,
> +   VC4_VEC_TV_MODE_NTSC_443,
> +   VC4_VEC_TV_MODE_PAL_60,
> +   VC4_VEC_TV_MODE_PAL_N,
> +   VC4_VEC_TV_MODE_SECAM,
>  };
>
>  struct vc4_vec_tv_mode {
> unsigned int mode;
> +   u16 expected_htotal;
> u32 config0;
> u32 config1;
> u32 custom_freq;
> @@ -236,35 +271,68 @@ static const struct debugfs_reg32 vec_regs[] = {
>  static const struct vc4_vec_tv_mode vc4_vec_tv_modes[] = {
> {
> .mode = DRM_MODE_TV_MODE_NTSC,
> +   .expected_htotal = 858,
> .config0 = VEC_CONFIG0_NTSC_STD | VEC_CONFIG0_PDEN,
> .config1 = VEC_CONFIG1_C_CVBS_CVBS,
> },
> +   {
> +   .mode = DRM_MODE_TV_MODE_NTSC_443,
> +   .expected_htotal = 858,
> +   .config0 = VEC_CONFIG0_NTSC_STD,
> +   .config1 = VEC_CONFIG1_C_CVBS_CVBS |
> VEC_CONFIG1_CUSTOM_FREQ,
> +   .custom_freq = 0x2a098acb,

Re: [Nouveau] [PATCH v6 13/23] drm/modes: Introduce the tv_mode property as a command-line option

2022-11-06 Thread Lukas Satin
1) Can we have access to TV chip registers (as nvtv) in order so set
horizontal / vertical properties in order to set 240p resolution in NTSC or
288p in PAL?

2) Why the reply to email list is like that and not just
nouveau@lists.freedesktop.org ? I see a couple of individuals plus four
mailing lists

Lukas

On Sun, Nov 6, 2022 at 2:11 PM Noralf Trønnes  wrote:

>
>
> Den 26.10.2022 17.33, skrev max...@cerno.tech:
> > Our new tv mode option allows to specify the TV mode from a property.
> > However, it can still be useful, for example to avoid any boot time
> > artifact, to set that property directly from the kernel command line.
> >
> > Let's add some code to allow it, and some unit tests to exercise that
> code.
> >
> > Signed-off-by: Maxime Ripard 
> >
> > ---
>
> I would have just squashed the named mode part of this patch together
> with the 2 other named mode patches and keep just the video= option part
> here, but up to you:
>
> Reviewed-by: Noralf Trønnes 
>


Re: [Nouveau] TV Out question

2022-11-04 Thread Lukas Satin
Switch to 360x240 works, but it is only scaled to 640x480.

I read that it should be possible to set particular TV chipset registers
and there's nvtv utility for that:
https://manpages.ubuntu.com/manpages/focal/man1/nvtv.1x.html

I guess it will work only with nvidia driver, which in NV40 case is legacy
304 series, which means compiling custom kernel and patching it on Ubuntu
18:
http://blog.schmorp.de/2019-08-03-nvidia-legacy-304-patch-for-post-50-linux-kernels.html

It would be great if your nuvo can set these tv chipset registers as well.

I collect retro hardware and I'm retrogamer (born 1987). There are
significant costs, most retrogamers buy 500 Eur video converter because
they want to output 240p TV resolution.

Currently only Calamity's CRT EmuDriver works and that one is for AMD
GPU's only.

For NVIDIA you need Linux kernel with 15Khz fix (which I have):
https://github.com/D0023R/linux_kernel_15khz and then you can output 15khz
240P over VGA, DVI-I or even HDMI. Then you apply some kind of adapter, for
example HDMI to VGA or DVI to VGA. Then you can use VGA to BNC cable and
use BNC directly in TV or you can buy RCA BNC connector and go from HDMI to
RCA and it will output directly 240p using custom made modelines and
enabling either custom unsigned AMD driver or having Linux kernel with
15khz patch.

Controlling TV out chipset directly would be the next level and it would be
great if it could be achieved.

On Fri, Nov 4, 2022 at 6:29 PM Lukas Satin  wrote:

> Yes, switching to 360x240 works! Interesting...it is definitely a step
> forward while still not satisfying result.
>
> On Fri, Nov 4, 2022 at 6:13 PM Lukas Satin  wrote:
>
>> 1) Some people here say: " Scrap everything already stated. The old
>> Nvidia cards with the mini DIN analog video out can ONLY do 480i output.
>> 240p is not an option."
>>
>> Source:
>> https://www.reddit.com/r/crtgaming/comments/a9k85n/old_nvidia_geforce_output_240p/
>>
>> But I guess that is due to using Windows and NVIDIA driver.
>>
>> 2) Here:
>> https://www.reddit.com/r/retrogaming/comments/40dv00/240p_signal_from_svideo_port_on_old_video_card/
>> someone says: "240p doesn't actually exist, it's really a trick that
>> uses a non-standard 480i signal to cause the alternating fields line up the
>> scanlines instead of offsetting them. "
>>
>> So I guess it could be done by sending non-standard 480i signal.
>>
>> On Fri, Nov 4, 2022 at 6:06 PM Ilia Mirkin  wrote:
>>
>>> On Fri, Nov 4, 2022 at 12:56 PM Lukas Satin 
>>> wrote:
>>> >
>>> > Hello, sorry fo the typos. Wanted to catch you before the weekend, to
>>> get some hints for upcoming work.
>>> >
>>> > I'm back at PC.
>>> >
>>> > Does your driver support switching to 240p in NTSC and 288p in PAL on
>>> the go via xrandr, for example?
>>> >
>>> > If not, can I find some relevant part of code in your repository where
>>> to implement that?
>>>
>>>
>>> https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
>>> + tvmodesnv17.c
>>>
>>> There's definitely a lot of hard-coding going on. A lot of the
>>> pre-nv50 display code is from This code is (likely) originally from
>>> https://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src but I
>>> can't immediately find the TV code in there. But perhaps it's there
>>> anyways, I only spent about 30s looking for it.
>>>
>>> I don't remember by now, but there _might_ be a kms property (which
>>> should get piped through to xrandr properties) which allows you to
>>> change this live?
>>>
>>> > Some info I found regarding 240p and that it is a part of NTSC:
>>> https://en.wikipedia.org/wiki/Low-definition_television
>>> >
>>> > TV with S-Video mostly supports 480i and 240p as well. So the current
>>> issue is outputting that via TV out.
>>> >
>>> > My current configuration looks like this:
>>> > TV-1 connected 240x224+0+0 (normal left inverted right x axis y axis)
>>> 0mm x 0mm
>>> >720x480   59.94 +
>>> >1024x768  59.94
>>> >800x600   59.94
>>> >720x576   59.94
>>> >640x480   59.94
>>> >400x300   59.94
>>> >320x240   59.93
>>> >320x200   59.94
>>> >768x576   50.00
>>> >360x200   60.00
>>> >360x240   60.00
>>> >640x240   60.00
>>> >SR-1_240x224@60.10  60.10*
>>> >
>>> > I see I have created 240x224 (I need to fix that), but even 320x240
>>> does not work. It always stays at 480i.
>>>
>>> Did you try 360x240? I have no idea though, sorry. I was just happy
>>> when the S-Video worked at all. It could require further modifications
>>> to how we configure those registers.
>>>
>>


Re: [Nouveau] TV Out question

2022-11-04 Thread Lukas Satin
Yes, switching to 360x240 works! Interesting...it is definitely a step
forward while still not satisfying result.

On Fri, Nov 4, 2022 at 6:13 PM Lukas Satin  wrote:

> 1) Some people here say: " Scrap everything already stated. The old
> Nvidia cards with the mini DIN analog video out can ONLY do 480i output.
> 240p is not an option."
>
> Source:
> https://www.reddit.com/r/crtgaming/comments/a9k85n/old_nvidia_geforce_output_240p/
>
> But I guess that is due to using Windows and NVIDIA driver.
>
> 2) Here:
> https://www.reddit.com/r/retrogaming/comments/40dv00/240p_signal_from_svideo_port_on_old_video_card/
> someone says: "240p doesn't actually exist, it's really a trick that uses
> a non-standard 480i signal to cause the alternating fields line up the
> scanlines instead of offsetting them. "
>
> So I guess it could be done by sending non-standard 480i signal.
>
> On Fri, Nov 4, 2022 at 6:06 PM Ilia Mirkin  wrote:
>
>> On Fri, Nov 4, 2022 at 12:56 PM Lukas Satin  wrote:
>> >
>> > Hello, sorry fo the typos. Wanted to catch you before the weekend, to
>> get some hints for upcoming work.
>> >
>> > I'm back at PC.
>> >
>> > Does your driver support switching to 240p in NTSC and 288p in PAL on
>> the go via xrandr, for example?
>> >
>> > If not, can I find some relevant part of code in your repository where
>> to implement that?
>>
>>
>> https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
>> + tvmodesnv17.c
>>
>> There's definitely a lot of hard-coding going on. A lot of the
>> pre-nv50 display code is from This code is (likely) originally from
>> https://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src but I
>> can't immediately find the TV code in there. But perhaps it's there
>> anyways, I only spent about 30s looking for it.
>>
>> I don't remember by now, but there _might_ be a kms property (which
>> should get piped through to xrandr properties) which allows you to
>> change this live?
>>
>> > Some info I found regarding 240p and that it is a part of NTSC:
>> https://en.wikipedia.org/wiki/Low-definition_television
>> >
>> > TV with S-Video mostly supports 480i and 240p as well. So the current
>> issue is outputting that via TV out.
>> >
>> > My current configuration looks like this:
>> > TV-1 connected 240x224+0+0 (normal left inverted right x axis y axis)
>> 0mm x 0mm
>> >720x480   59.94 +
>> >1024x768  59.94
>> >800x600   59.94
>> >720x576   59.94
>> >640x480   59.94
>> >400x300   59.94
>> >320x240   59.93
>> >320x200   59.94
>> >768x576   50.00
>> >360x200   60.00
>> >360x240   60.00
>> >640x240   60.00
>> >SR-1_240x224@60.10  60.10*
>> >
>> > I see I have created 240x224 (I need to fix that), but even 320x240
>> does not work. It always stays at 480i.
>>
>> Did you try 360x240? I have no idea though, sorry. I was just happy
>> when the S-Video worked at all. It could require further modifications
>> to how we configure those registers.
>>
>


Re: [Nouveau] TV Out question

2022-11-04 Thread Lukas Satin
1) Some people here say: " Scrap everything already stated. The old Nvidia
cards with the mini DIN analog video out can ONLY do 480i output. 240p is
not an option."

Source:
https://www.reddit.com/r/crtgaming/comments/a9k85n/old_nvidia_geforce_output_240p/

But I guess that is due to using Windows and NVIDIA driver.

2) Here:
https://www.reddit.com/r/retrogaming/comments/40dv00/240p_signal_from_svideo_port_on_old_video_card/
someone says: "240p doesn't actually exist, it's really a trick that uses a
non-standard 480i signal to cause the alternating fields line up the
scanlines instead of offsetting them. "

So I guess it could be done by sending non-standard 480i signal.

On Fri, Nov 4, 2022 at 6:06 PM Ilia Mirkin  wrote:

> On Fri, Nov 4, 2022 at 12:56 PM Lukas Satin  wrote:
> >
> > Hello, sorry fo the typos. Wanted to catch you before the weekend, to
> get some hints for upcoming work.
> >
> > I'm back at PC.
> >
> > Does your driver support switching to 240p in NTSC and 288p in PAL on
> the go via xrandr, for example?
> >
> > If not, can I find some relevant part of code in your repository where
> to implement that?
>
>
> https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
> + tvmodesnv17.c
>
> There's definitely a lot of hard-coding going on. A lot of the
> pre-nv50 display code is from This code is (likely) originally from
> https://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src but I
> can't immediately find the TV code in there. But perhaps it's there
> anyways, I only spent about 30s looking for it.
>
> I don't remember by now, but there _might_ be a kms property (which
> should get piped through to xrandr properties) which allows you to
> change this live?
>
> > Some info I found regarding 240p and that it is a part of NTSC:
> https://en.wikipedia.org/wiki/Low-definition_television
> >
> > TV with S-Video mostly supports 480i and 240p as well. So the current
> issue is outputting that via TV out.
> >
> > My current configuration looks like this:
> > TV-1 connected 240x224+0+0 (normal left inverted right x axis y axis)
> 0mm x 0mm
> >720x480   59.94 +
> >1024x768  59.94
> >800x600   59.94
> >720x576   59.94
> >640x480   59.94
> >400x300   59.94
> >320x240   59.93
> >320x200   59.94
> >768x576   50.00
> >360x200   60.00
> >360x240   60.00
> >640x240   60.00
> >SR-1_240x224@60.10  60.10*
> >
> > I see I have created 240x224 (I need to fix that), but even 320x240 does
> not work. It always stays at 480i.
>
> Did you try 360x240? I have no idea though, sorry. I was just happy
> when the S-Video worked at all. It could require further modifications
> to how we configure those registers.
>


Re: [Nouveau] TV Out question

2022-11-04 Thread Lukas Satin
240p compatibility list of TVs:
https://static1.squarespace.com/static/51f517f0e4b01da70d01ca2a/t/5a2f36e953450aa1429361d9/1513043690556/240p-TVs_20171211.pdf

Source: https://www.hdretrovision.com/240p

On Fri, Nov 4, 2022 at 5:55 PM Lukas Satin  wrote:

> Hello, sorry fo the typos. Wanted to catch you before the weekend, to get
> some hints for upcoming work.
>
> I'm back at PC.
>
> Does your driver support switching to 240p in NTSC and 288p in PAL on the
> go via xrandr, for example?
>
> If not, can I find some relevant part of code in your repository where to
> implement that?
>
> Some info I found regarding 240p and that it is a part of NTSC:
> https://en.wikipedia.org/wiki/Low-definition_television
>
> TV with S-Video mostly supports 480i and 240p as well. So the current
> issue is outputting that via TV out.
>
> My current configuration looks like this:
> TV-1 connected 240x224+0+0 (normal left inverted right x axis y axis) 0mm
> x 0mm
>720x480   59.94 +
>1024x768  59.94
>800x600   59.94
>720x576   59.94
>640x480   59.94
>400x300   59.94
>320x240   59.93
>320x200   59.94
>768x576   50.00
>360x200   60.00
>360x240   60.00
>640x240   60.00
>SR-1_240x224@60.10  60.10*
>
> I see I have created 240x224 (I need to fix that), but even 320x240 does
> not work. It always stays at 480i.
>
> I read somewhere that older GPU with TV out can do it. Only newer cards in
> Windows cannot do it.
>
> Thank you a lot,
> Lukas
>
>
>
> On Fri, Nov 4, 2022 at 5:43 PM Lukas Satin  wrote:
>
>> Yes I just figured it out an hour ago. It works same as hd480i.
>>
>> Win7 can switch pal and ntsc just by changing desktop tesolution. Wht
>> about here?
>>
>> TV with svideo or component rca supporr 480i and 240p by the spec.
>>
>> I hve added modelines for that. It works via dvi to vga to bnc to rca
>> wity 15khz kernel.
>>
>> How to modify ut driver to outtput 240p via tv out?
>>
>> Imvon phone sorry fot ttyoos
>>
>> On Fri 4. 11. 2022 at 17:35, Ilia Mirkin  wrote:
>>
>>> https://nouveau.freedesktop.org/KernelModuleParameters.html
>>>
>>> Perhaps nouveau.tv_norm=NTSC-M will help get you the 60hz modes? I
>>> haven't played with these options much at all, it has always sorta
>>> Just Worked for me.
>>>
>>> This should have the validation of new modes, make sure you don't run
>>> afoul of this:
>>>
>>>
>>> https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c#n303
>>>
>>> Cheers,
>>>
>>>   -ilia
>>>
>>> On Thu, Nov 3, 2022 at 10:56 PM Lukas Satin 
>>> wrote:
>>> >
>>> > Hi, I am currently testing Batocera Linux for retrogaming with 15KHz
>>> output on CRT / TV.
>>> >
>>> > The machine I discovered is a certified Windows Media Center / Intel
>>> ViiV machine: Acer iDEA 510
>>> >
>>> > It features:
>>> > RCA component output
>>> > S-Video CVBS output
>>> > S-Video DIN output
>>> > Scart IN / Scart OUT (two DVB-T tuners for realtime playback and
>>> recording)
>>> > DVI-I out
>>> > HDMI out
>>> >
>>> > Laptop style components, MXM module Geforce 7 Go 7600 (NVIDIA Curie).
>>> >
>>> > Now, BIOS default output via RCA component is 640x480 NTSC (480i,
>>> 60Hz). In Windows I can switch between NTSC and PAL (480i or 576i).
>>> >
>>> > As this is EU machine, after BIOS it often defaults to 576i PAL,
>>> unless set otherwise.
>>> >
>>> > Now your nouveau driver therefore defaults to 576i.
>>> >
>>> > Xrandr looks like this:
>>> > TV-1 connected 640x480+0+0 (normal left inverted right x axis y axis)
>>> 0mm x 0mm
>>> >720x576   50.00 +
>>> >1024x768  50.00
>>> >800x600   50.00
>>> >720x480   50.00
>>> >640x480   50.00*
>>> >400x300   50.00
>>> >320x240   50.00
>>> >320x200   50.00
>>> >768x576   50.00
>>> >360x200   60.00
>>> >360x240   60.00
>>> >640x240   60.00
>>> >
>>> > I tried to add some additional modelines. But look at 640x480. It
>>> forces 50Hz and I am unable to remove it, create new or change it to 60Hz.
>>> Therefore the TV is always set to 576i and screen output is 640x480,
>>> therefore it looks like GPU scaled. First I read your troubleshooting which
>>> mentions scaling, so I tried to disable scaling. Did not help.
>>> >
>>> > Now I read about this:
>>> >
>>> https://nvidia.custhelp.com/app/answers/detail/a_id/177/~/linux---configuring-tv-out
>>> >
>>> > And this might be the solution and issue. It would correspond with
>>> what can be observed in Windows 7.
>>> >
>>> > Does your driver have some options for configuring TV Out and name
>>> switching from PAL to NTSC or HD480i mode? It should be automatic based on
>>> 480i or 576i or 240p or 288p, but it is not.
>>> >
>>> > Thanks,
>>> > Lukas
>>>
>>


Re: [Nouveau] TV Out question

2022-11-04 Thread Lukas Satin
Hello, sorry fo the typos. Wanted to catch you before the weekend, to get
some hints for upcoming work.

I'm back at PC.

Does your driver support switching to 240p in NTSC and 288p in PAL on the
go via xrandr, for example?

If not, can I find some relevant part of code in your repository where to
implement that?

Some info I found regarding 240p and that it is a part of NTSC:
https://en.wikipedia.org/wiki/Low-definition_television

TV with S-Video mostly supports 480i and 240p as well. So the current issue
is outputting that via TV out.

My current configuration looks like this:
TV-1 connected 240x224+0+0 (normal left inverted right x axis y axis) 0mm x
0mm
   720x480   59.94 +
   1024x768  59.94
   800x600   59.94
   720x576   59.94
   640x480   59.94
   400x300   59.94
   320x240   59.93
   320x200   59.94
   768x576   50.00
   360x200   60.00
   360x240   60.00
   640x240   60.00
   SR-1_240x224@60.10  60.10*

I see I have created 240x224 (I need to fix that), but even 320x240 does
not work. It always stays at 480i.

I read somewhere that older GPU with TV out can do it. Only newer cards in
Windows cannot do it.

Thank you a lot,
Lukas



On Fri, Nov 4, 2022 at 5:43 PM Lukas Satin  wrote:

> Yes I just figured it out an hour ago. It works same as hd480i.
>
> Win7 can switch pal and ntsc just by changing desktop tesolution. Wht
> about here?
>
> TV with svideo or component rca supporr 480i and 240p by the spec.
>
> I hve added modelines for that. It works via dvi to vga to bnc to rca wity
> 15khz kernel.
>
> How to modify ut driver to outtput 240p via tv out?
>
> Imvon phone sorry fot ttyoos
>
> On Fri 4. 11. 2022 at 17:35, Ilia Mirkin  wrote:
>
>> https://nouveau.freedesktop.org/KernelModuleParameters.html
>>
>> Perhaps nouveau.tv_norm=NTSC-M will help get you the 60hz modes? I
>> haven't played with these options much at all, it has always sorta
>> Just Worked for me.
>>
>> This should have the validation of new modes, make sure you don't run
>> afoul of this:
>>
>>
>> https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c#n303
>>
>> Cheers,
>>
>>   -ilia
>>
>> On Thu, Nov 3, 2022 at 10:56 PM Lukas Satin  wrote:
>> >
>> > Hi, I am currently testing Batocera Linux for retrogaming with 15KHz
>> output on CRT / TV.
>> >
>> > The machine I discovered is a certified Windows Media Center / Intel
>> ViiV machine: Acer iDEA 510
>> >
>> > It features:
>> > RCA component output
>> > S-Video CVBS output
>> > S-Video DIN output
>> > Scart IN / Scart OUT (two DVB-T tuners for realtime playback and
>> recording)
>> > DVI-I out
>> > HDMI out
>> >
>> > Laptop style components, MXM module Geforce 7 Go 7600 (NVIDIA Curie).
>> >
>> > Now, BIOS default output via RCA component is 640x480 NTSC (480i,
>> 60Hz). In Windows I can switch between NTSC and PAL (480i or 576i).
>> >
>> > As this is EU machine, after BIOS it often defaults to 576i PAL, unless
>> set otherwise.
>> >
>> > Now your nouveau driver therefore defaults to 576i.
>> >
>> > Xrandr looks like this:
>> > TV-1 connected 640x480+0+0 (normal left inverted right x axis y axis)
>> 0mm x 0mm
>> >720x576   50.00 +
>> >1024x768  50.00
>> >800x600   50.00
>> >720x480   50.00
>> >640x480   50.00*
>> >400x300   50.00
>> >320x240   50.00
>> >320x200   50.00
>> >768x576   50.00
>> >360x200   60.00
>> >360x240   60.00
>> >640x240   60.00
>> >
>> > I tried to add some additional modelines. But look at 640x480. It
>> forces 50Hz and I am unable to remove it, create new or change it to 60Hz.
>> Therefore the TV is always set to 576i and screen output is 640x480,
>> therefore it looks like GPU scaled. First I read your troubleshooting which
>> mentions scaling, so I tried to disable scaling. Did not help.
>> >
>> > Now I read about this:
>> >
>> https://nvidia.custhelp.com/app/answers/detail/a_id/177/~/linux---configuring-tv-out
>> >
>> > And this might be the solution and issue. It would correspond with what
>> can be observed in Windows 7.
>> >
>> > Does your driver have some options for configuring TV Out and name
>> switching from PAL to NTSC or HD480i mode? It should be automatic based on
>> 480i or 576i or 240p or 288p, but it is not.
>> >
>> > Thanks,
>> > Lukas
>>
>


Re: [Nouveau] TV Out question

2022-11-04 Thread Lukas Satin
Yes I just figured it out an hour ago. It works same as hd480i.

Win7 can switch pal and ntsc just by changing desktop tesolution. Wht about
here?

TV with svideo or component rca supporr 480i and 240p by the spec.

I hve added modelines for that. It works via dvi to vga to bnc to rca wity
15khz kernel.

How to modify ut driver to outtput 240p via tv out?

Imvon phone sorry fot ttyoos

On Fri 4. 11. 2022 at 17:35, Ilia Mirkin  wrote:

> https://nouveau.freedesktop.org/KernelModuleParameters.html
>
> Perhaps nouveau.tv_norm=NTSC-M will help get you the 60hz modes? I
> haven't played with these options much at all, it has always sorta
> Just Worked for me.
>
> This should have the validation of new modes, make sure you don't run
> afoul of this:
>
>
> https://cgit.freedesktop.org/drm/drm/tree/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c#n303
>
> Cheers,
>
>   -ilia
>
> On Thu, Nov 3, 2022 at 10:56 PM Lukas Satin  wrote:
> >
> > Hi, I am currently testing Batocera Linux for retrogaming with 15KHz
> output on CRT / TV.
> >
> > The machine I discovered is a certified Windows Media Center / Intel
> ViiV machine: Acer iDEA 510
> >
> > It features:
> > RCA component output
> > S-Video CVBS output
> > S-Video DIN output
> > Scart IN / Scart OUT (two DVB-T tuners for realtime playback and
> recording)
> > DVI-I out
> > HDMI out
> >
> > Laptop style components, MXM module Geforce 7 Go 7600 (NVIDIA Curie).
> >
> > Now, BIOS default output via RCA component is 640x480 NTSC (480i, 60Hz).
> In Windows I can switch between NTSC and PAL (480i or 576i).
> >
> > As this is EU machine, after BIOS it often defaults to 576i PAL, unless
> set otherwise.
> >
> > Now your nouveau driver therefore defaults to 576i.
> >
> > Xrandr looks like this:
> > TV-1 connected 640x480+0+0 (normal left inverted right x axis y axis)
> 0mm x 0mm
> >720x576   50.00 +
> >1024x768  50.00
> >800x600   50.00
> >720x480   50.00
> >640x480   50.00*
> >400x300   50.00
> >320x240   50.00
> >320x200   50.00
> >768x576   50.00
> >360x200   60.00
> >360x240   60.00
> >640x240   60.00
> >
> > I tried to add some additional modelines. But look at 640x480. It forces
> 50Hz and I am unable to remove it, create new or change it to 60Hz.
> Therefore the TV is always set to 576i and screen output is 640x480,
> therefore it looks like GPU scaled. First I read your troubleshooting which
> mentions scaling, so I tried to disable scaling. Did not help.
> >
> > Now I read about this:
> >
> https://nvidia.custhelp.com/app/answers/detail/a_id/177/~/linux---configuring-tv-out
> >
> > And this might be the solution and issue. It would correspond with what
> can be observed in Windows 7.
> >
> > Does your driver have some options for configuring TV Out and name
> switching from PAL to NTSC or HD480i mode? It should be automatic based on
> 480i or 576i or 240p or 288p, but it is not.
> >
> > Thanks,
> > Lukas
>


[Nouveau] TV Out question

2022-11-03 Thread Lukas Satin
Hi, I am currently testing Batocera Linux for retrogaming with 15KHz output
on CRT / TV.

The machine I discovered is a certified Windows Media Center / Intel ViiV
machine: Acer iDEA 510

It features:
RCA component output
S-Video CVBS output
S-Video DIN output
Scart IN / Scart OUT (two DVB-T tuners for realtime playback and recording)
DVI-I out
HDMI out

Laptop style components, MXM module Geforce 7 Go 7600 (NVIDIA Curie).

Now, BIOS default output via RCA component is 640x480 NTSC (480i, 60Hz). In
Windows I can switch between NTSC and PAL (480i or 576i).

As this is EU machine, after BIOS it often defaults to 576i PAL, unless set
otherwise.

Now your nouveau driver therefore defaults to 576i.

Xrandr looks like this:
TV-1 connected 640x480+0+0 (normal left inverted right x axis y axis) 0mm x
0mm
   720x576   50.00 +
   1024x768  50.00
   800x600   50.00
   720x480   50.00
   640x480   50.00*
   400x300   50.00
   320x240   50.00
   320x200   50.00
   768x576   50.00
   360x200   60.00
   360x240   60.00
   640x240   60.00

I tried to add some additional modelines. But look at 640x480. It forces
50Hz and I am unable to remove it, create new or change it to 60Hz.
Therefore the TV is always set to 576i and screen output is 640x480,
therefore it looks like GPU scaled. First I read your troubleshooting which
mentions scaling, so I tried to disable scaling. Did not help.

Now I read about this:
https://nvidia.custhelp.com/app/answers/detail/a_id/177/~/linux---configuring-tv-out

And this might be the solution and issue. It would correspond with what can
be observed in Windows 7.

Does your driver have some options for configuring TV Out and name
switching from PAL to NTSC or HD480i mode? It should be automatic based on
480i or 576i or 240p or 288p, but it is not.

Thanks,
Lukas