;
>> 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
...?
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
ime's point
to focus on merging existing functionality first.
> Lukas
Best regards,
Mateusz Kwiatkowski
> 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
&g
itch 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.
As far as I understand the patc
file
> using a udev rule?
>
> Noralf.
I think that leaving named modes only would be a bit limiting. There are use
cases for custom modes, e.g. we might want progressive 240p "NTSC" (like 80s/90s
home computers and video game consoles) or the modes with non-13.5MHz pixel
clock that Geert requested with Amiga in mind.
I'm not sure if the current cmdline-to-drm_mode conversion is flexible enough
to meaningfully facilitate those, but we're at least getting the syntax down.
Best regards,
Mateusz Kwiatkowski
admit that this scenario is likely a stretch and the
number of people who would actually use it is probably close to the proverbial
two ;) So it's your call, I'm just leaving those settings here just in case.
I'll get back in a couple of days when I do some testing of this v6 patchset
modes array
will leak.
Also, I wonder if maybe the if (cmdline->tv_mode_specified) clause should go
first? If we're going to use the default from cmdline, there's no point in even
querying the property default value.
Best regards,
Mateusz Kwiatkowski
mode->tv_mode) condition here. This will break on NTSC.
Best regards,
Mateusz Kwiatkowski
Hi Maxime,
W dniu 18.10.2022 o 12:00, Maxime Ripard pisze:
> On Mon, Oct 17, 2022 at 12:31:31PM +0200, Noralf Trønnes wrote:
>> Den 16.10.2022 20.52, skrev Mateusz Kwiatkowski:
>>>> static int vc4_vec_connector_get_modes(struct drm_connector *connector)
>>>> {
&
Hi Maxime,
W dniu 18.10.2022 o 10:31, Maxime Ripard pisze:
> Hi,
>
> On Sun, Oct 16, 2022 at 09:46:49PM +0200, Mateusz Kwiatkowski wrote:
>> @@ -308,14 +324,15 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[]
>> = {
>> };
>>
>> sta
Add support for the PAL-60 mode. Because there is no separate TV mode
property value for PAL-60, this requires matching the settings based on
the modeline in addition to just that property alone.
Signed-off-by: Mateusz Kwiatkowski
---
This patch depends on patch
'[PATCH v5 21/22] drm/vc4
Hi Maxime,
W dniu 13.10.2022 o 15:19, 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 sub
h 19/22 would double as such check), as all
other values causes VEC to output garbage.
Best regards,
Mateusz Kwiatkowski
n: %d\n", ret);
If this (!tv_mode) condition is somehow triggered, the power management goes
somewhat crazy. vc4_vec_encoder_enable() cannot return an error, so when
vc4_vec_encoder_disable() is eventually called after a failed enable, it hangs
in pm_runtime_put() for quite a bit.
At least I think that's what's happening. Anyway, to solve this, I'd propose
this thing below:
Best regards,
Mateusz Kwiatkowski
Hi Maxime,
Sorry about the mess that happened to the previous message. I hope this one
will be delivered more cleanly.
W dniu 13.10.2022 o 15:19, Maxime Ripard pisze:
> From: Mateusz Kwiatkowski
>
> The VEC can accept pretty much any relatively reasonable mode, but still
> ha
Hi Maxime,
W dniu 13.10.2022 o 15:19, Maxime Ripard pisze:
> From: Mateusz Kwiatkowski > > The VEC can accept pretty much any relatively
> reasonable mode, but still > has a bunch of constraints to meet. > > Let's
> create an atomic_check() implementation that wil
t gonna force my opinion here, but I wanted to bring your attention to
this issue, maybe you have some other solution in mind for this problem. Or if
you don't see that as a problem at all, that's fine, too.
Best regards,
Mateusz Kwiatkowski
t be in either the front porch or sync
> +* period.
> +*/
> + PARAM_FIELD(19, 20)),
> +};
Nit: setting vbp limits like that makes it impossible to use
drm_analog_tv_mode() to generate modes that include the VBI for e.g. emitting
teletext.
This probably doesn't matter, as it can still be created as a custom mode from
userspace, hence I'm mentioning it as a nit.
> + * By convention, NSTC (aka 525/60) systems start with
Typo: s/NSTC/NTSC/
Best regards,
Mateusz Kwiatkowski
> Yes, lines 0-23 is the entire blanking area. And the "back porch" in this
> context is everything from the start of the sync pulse to the start of active
> video. It's not just the equalizing pulses.
I meant "from the end of the sync pulse", obviously. Sorry about the slipup.
Hi Maxime,
W dniu 9.09.2022 o 15:54, Maxime Ripard pisze:
> Hi,
>
> On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote:
> [...]
>> I think you're confusing the "post-equalizing pulses" with the "vertical back
>> porch" a little
W dniu 9.09.2022 o 11:46, Maxime Ripard pisze:
> On Wed, Sep 07, 2022 at 09:52:09PM +0200, Mateusz Kwiatkowski wrote:
>> W dniu 7.09.2022 o 14:10, Maxime Ripard pisze:
>>> Hi,
>>>
>>> On Fri, Sep 02, 2022 at 12:00:33AM +0200, Mateusz Kwiatkowski wrote:
>>&
modes in patch 33/41 in this series.
And the values (and names!) added by that patch (33/41) don't match those
currently used by the downstream version
(https://github.com/raspberrypi/linux/blob/rpi-5.15.y/drivers/gpu/drm/vc4/vc4_vec.c).
If any userspace software is manipulating this property, it's most likely
targeting the downstream code. But since you're not aiming for consistency with
that, I was under the impression that compatibility isn't a concern.
Best regards,
Mateusz Kwiatkowski
Hi Maxime,
W dniu 7.09.2022 o 16:34, Maxime Ripard pisze:
> On Mon, Sep 05, 2022 at 06:44:42PM +0200, Mateusz Kwiatkowski wrote:
>> Hi Maxime,
>>
>> W dniu 5.09.2022 o 15:37, Maxime Ripard pisze:
>>>>> + vfp = vfp_min + (porches_rem / 2);
>>>&g
Hi Maxime,
W dniu 7.09.2022 o 14:10, Maxime Ripard pisze:
> Hi,
>
> On Fri, Sep 02, 2022 at 12:00:33AM +0200, Mateusz Kwiatkowski wrote:
>> W dniu 29.08.2022 o 15:11, Maxime Ripard pisze:
>>> The TV mode property has been around for a while now to select and get the
>&
ly be off-center, but
there's no other way
I hope this makes sense for you as well.
Best regards,
Mateusz Kwiatkowski
> I'd rather have a common name that everyone can understand in this case
> rather than a *perfect* name where most will scratch their head
> wondering what it's about.
You may have a point. But in that case, maybe it'd make sense to at least add
a short comment explaining what do you mean by "NTSC" and "PAL" in this context?
Best regards,
Mateusz Kwiatkowski
Hi Maxime,
> + if (!named_mode->tv_mode)
> + continue;
As mentioned in the previous email replying to 19/41, this makes it impossible
to specify DRM_MODE_TV_MODE_NTSC_443 as currently defined in the named mode
successfully.
Best regards,
Mateusz Kwiatkowski
hatever output, and a composite output, switches to NTSC-443 on the
composite output by default because a named mode for the modern output is
selected.
Maybe something like DRM_MODE_TV_MODE_NONE = 0 would make sense?
Maybe not. This is not an actual suggestion, just "thinking out loud".
Best regards,
Mateusz Kwiatkowski
N/PAL, PAL-CN
etc.) are just different "spellings" referring to exactly the same system.
> + /**
> + * @DRM_MODE_TV_MODE_SECAM_K: CCIR System G together with the
> + * SECAM color system. Similar to @DRM_MODE_TV_MODE_SECAM_G but
> + * with different channels.
> + */
> + DRM_MODE_TV_MODE_SECAM_K,
> +
> + /**
> + * @DRM_MODE_TV_MODE_SECAM_K1: CCIR System G together with the
> + * SECAM color system. Similar to @DRM_MODE_TV_MODE_SECAM_G and
> + * @DRM_MODE_TV_MODE_SECAM_K but with different channels.
> + */
> + DRM_MODE_TV_MODE_SECAM_K1,
Typos: you meant CCIR Systems K and K1, not System G.
Best regards,
Mateusz Kwiatkowski
line validation like I suggested in the
comment above, then without setting the preferred mode properly, Xorg will just
give up and sit on a blank screen until you run xrandr from another terminal
if tv_mode incompatible with 576i is selected.
Best regards,
Mateusz Kwiatkowski
_add_cmdline_mode()
taking over the mode generation (badly), and a horrible mess on screen.
> + vfp = vfp_min + (porches_rem / 2);
> + vbp = porches - vfp;
Relative position of the vertical sync within the VBI effectively moves the
image up and down. Adding that (porches_rem / 2
least not from USB - I might try some SD card
after the weekend.
Best regards,
Mateusz Kwiatkowski
W dniu 25.08.2022 o 18:17, Mateusz Kwiatkowski pisze:
Hi Maxime,
W dniu 25.08.2022 o 17:55, Maxime Ripard pisze:
Hi Mateusz,
On Mon, Aug 22, 2022 at 10:57:26AM +0200, Mateusz Kwiatkowski wrote:
Hi Maxime,
W dniu 25.08.2022 o 17:55, Maxime Ripard pisze:
> Hi Mateusz,
>
> On Mon, Aug 22, 2022 at 10:57:26AM +0200, Mateusz Kwiatkowski wrote:
>> Hi Maxime,
>>
>> I tried testing and reviewing your changes properly over the last weekend,
>> but
>> ult
I once had an old multi-standard Sharp CRT TV that allowed manually selecting
the expected color encoding (PAL/SECAM/NTSC/NTSC-443), and the relevant button
on the remote was labeled "SYSTEM".
V4L2 calls this "standard", see include/uapi/linux/videodev2.h, compare with
v4l2_std_id, V4L2_STD_* etc.
BTW, maybe reusing those V4L2 constants, or aligning the numerical values,
would make some sense?
>
> Maxime
Best regards,
Mateusz Kwiatkowski
Hi Maxime,
W dniu 15.08.2022 o 10:37, Maxime Ripard pisze:
> Hi,
>
> On Fri, Jul 29, 2022 at 07:55:30PM +0200, Mateusz Kwiatkowski wrote:
>> Hi Maxime,
>>
>> I think that declaring PAL-B and SECAM-B as the only supported 576i
>> norms is a bit random.
>
> St
that the norms for analog TV are rather loose, and I think we
shouldn't limit the drivers to only accepting the "proper" modes as defined in
the spec. Those should of course be the default, but if non-standard modelines
can be generated - there are legitimate use cases why people might want those.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
Best regards,
Mateusz Kwiatkowski
er, possibly later today, and maybe check
the rpi-6.0.y branch as well.
Best regards,
Mateusz Kwiatkowski
W dniu 22.08.2022 o 09:48, Maxime Ripard pisze:
> Hi,
>
> On Sun, Aug 21, 2022 at 06:33:12PM +0200, Noralf Trønnes wrote:
>> Den 29.07.2022 18.34, skrev Maxime Ripard:
>>>
for all of those, and all should map to the
same VEC settings. Some users from e.g. the UK might think that they
won't get proper picture if PAL-I is not on the list of supported norms.
Same goes for e.g. SECAM-D/K in the former Soviet territories, and so on.
Best regards,
Mateusz Kwiatkow
he differences in vertical sync are even more dramatic. It's
entirely possible that the current timings in sun4i are broken and the
new ones are correct (the new ones certainly look saner to me), but I'd
double-check if that driver does not have any quirks that would
_require_ such weir
Hi Maxime,
I'm pretty sure that PAL-60 and SECAM-60 should be tied to the 480i
mode. Those are non-standard "norms" that use 60 Hz sync (which is
largely synonymous with 480i in the analog TV world) with PAL/SECAM
color encoding.
Best regards,
Mateusz Kwiatkowski
W dniu 29.
40 matches
Mail list logo
