intel-xe.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Michael Olbrich" <m.olbrich@pengutronix.de>,
	dri-devel@lists.freedesktop.org,
	"David Airlie" <airlied@gmail.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Tvrtko Ursulin" <tursulin@ursulin.net>,
	intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Cc: graphics@pengutronix.de
Subject: Re: Reliably selecting non-CEA modes on Intel graphics (and maybe others)
Date: Mon, 22 Apr 2024 17:13:00 +0300	[thread overview]
Message-ID: <8734rdtrir.fsf@intel.com> (raw)
In-Reply-To: <ZiZs94-ZP1n98RZu@pengutronix.de>

On Mon, 22 Apr 2024, Michael Olbrich <m.olbrich@pengutronix.de> wrote:
> Hi,
>
> In short: I have a HDMI monitor attached to Intel graphics. I'm trying to
> set a non-CEA mode but the driver always maps it to the corresponding CEA
> mode.

Please file a bug as described at [1], and attach dmesg with debugs
enabled, so we can see what's going on and what kernel and hardware
you're using exactly, and so on.

BR,
Jani.



[1] https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html


>
> More specifically, the monitor has two 1920x1080@60 modes in the EDID:
> 1. The CEA mode with VIC 16
> 2. A custom DTD mode with exactly the same timings (this is the preferred
>    mode).
>
> From a userspace perspective, the two modes are mostly identical, except
> for the 16:9 aspect ratio flag in the CEA mode and the preferred type in
> the other.
>
> I want to select the second (preferred) mode, but that does not seem
> possible:
> intel_hdmi_compute_avi_infoframe() tries to determine which VIC should be
> added to the avi infoframe and if limited or full range is used.
> It uses various DRM helpers here but in the end drm_match_cea_mode() is
> called. And here lies the problem:
> The mode provided by the userspace has explicitly no aspect ratio. But
> here, it is interpreted as "the aspect ration is undefined". So matching
> ignored the aspect ratio and the CEA mode with VIC 16 is found and limited
> range is used.
>
> The commit that introduces this fuzzy matching
> 357768cc9e3fdacf6551da0ae1483bc87dbcb4e8 ("drm/edid: Fix cea mode aspect
> ratio handling") made sense at the time. The capability
> DRM_CLIENT_CAP_ASPECT_RATIO that exposes aspect ratios to userspace was
> introduced later in the same merge request, from what I can tell
> 7595bda2fb4378ccbb8db1d0e8de56d15ea7f7fa ("drm: Add DRM client cap for
> aspect-ratio").
>
> Am I missing something here, or is it just not possible to select the
> non-CEA mode right now? In my specific example, the selected CEA mode is
> actually supported by the monitor, but as far as I can tell, the CEA mode
> is used even if the monitor does not support it at all.
>
> I've only tested this on Intel, but I assume that other drivers that use
> the same helpers have the same problem.
>
> So how can this be fixed? I've considered matching the aspect ratio based
> on the DRM_CLIENT_CAP_ASPECT_RATIO capability, but I'm not sure if that is
> valid. The documentation is limited and I found nothing that describes what
> the userspace should do here.
> Or would a new capability make sense here? Or something entirely different?
> I'm not sure how I should proceed here. Any help would be appreciated.
>
> Regards,
> Michael

-- 
Jani Nikula, Intel

      reply	other threads:[~2024-04-22 14:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-22 13:58 Reliably selecting non-CEA modes on Intel graphics (and maybe others) Michael Olbrich
2024-04-22 14:13 ` Jani Nikula [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8734rdtrir.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=airlied@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=graphics@pengutronix.de \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.olbrich@pengutronix.de \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=tursulin@ursulin.net \
    --cc=tzimmermann@suse.de \
    --cc=ville.syrjala@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).