;
>> 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.4336
...?
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
erging 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
> somewhat more obscure t
TSC 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 patch, this is exactly h
dev 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
rio 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.
Best regards,
Mateusz Kwiatkowski
W
ybe 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
d_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
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
>
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: vec
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
oving the reference mode, then I think you should at least add
checks that the crtc_clock is set to 13.5 MHz (it's otherwise ignored) and that
crtc_htotal is either 858 or 864 (using a switch over reference_mode->htotal as
I proposed in my comment to patch 19/22 would double as such check), as all
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
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 will mak
* 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
ndition 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
eries.
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 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:
>>&
> 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 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
&g
"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
off-center, but
there's no other way
I hope this makes sense for you as well.
Best regards,
Mateusz Kwiatkowski
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
her 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
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) moves the image up off center
by that many pixels. I'd keep the
ment 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
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
31 matches
Mail list logo
