mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	Tejas Vipin <tejasvipin76@gmail.com>,
	Laurent.pinchart@ideasonboard.com, patrik.r.jakobsson@gmail.com,
	maarten.lankhorst@linux.intel.com, mripard@kernel.org,
	airlied@gmail.com, daniel@ffwll.ch
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] drm/gma500: replace drm_detect_hdmi_monitor() with drm_display_info.is_hdmi
Date: Thu, 12 Sep 2024 15:10:41 +0200	[thread overview]
Message-ID: <1d16c1ae-2e27-4daa-b8a6-5eab179ef551@suse.de> (raw)
In-Reply-To: <87bk0tgll7.fsf@intel.com>

Hi

Am 12.09.24 um 13:25 schrieb Jani Nikula:
> On Thu, 12 Sep 2024, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>> Hi
>>
>> Am 12.09.24 um 11:38 schrieb Jani Nikula:
>>> On Thu, 12 Sep 2024, Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>>> Am 12.09.24 um 10:56 schrieb Jani Nikula:
>>>>> Moreover, in this case .detect() only detects digital displays as
>>>>> reported by EDID. If you postpone that to .get_modes(), the probe helper
>>>>> will still report connected, and invent non-EDID fallback modes. The
>>>>> behaviour changes.
>>>> The change in behavior is intentional, because the current test seems
>>>> arbitrary. Does the driver not work with analog outputs?
>>> Not on a DVI/HDMI port. Same with i915.
>>>
>>> That's possibly the only way to distinguish a DVI-A display connected to
>>> DVI-D source.
>> That's a detect failure, but IMHO our probe helpers should really handle
>> this case.
> How? Allow returning detect failures from .get_modes()?

Something like that, I guess.

For the specific problem it would be enough to read the first 20 bytes 
of EDID data on DVI connectors and test the digital-input flag bit 
against the exact connector requirements. drm_probe_ddc() could do this. 
Non-DVI connectors would continue to read a single bytes to detect the DDC.

For more sophisticated problems, it would be good to introduce an 
intermediate callback that updates the connector state. So the probe 
logic would look like:

  1) call ->detect to read physical connector status
  2) return if physical status did not change
  3) increment epoch counter
  4) call ->update to update connector state and properties (EDID, etc) 
get new connector status
  5) call ->get_modes if connected

The initial ->detect would be minimal. The ->update, if implemented, 
could do more processing and error checking. It's result would be the 
connector's new status.

On a side note, I've recently spend quite a few patches on getting the 
BMC output for ast and mgag200 usable. Something like the above logic 
would have helped, I think. Because with the current probe logic, I had 
to implement steps 1 to 4 in ->detect itself. The result has to maintain 
physical status and epoch counter by itself. [1]

Best regards
Thomas

[1] 
https://gitlab.freedesktop.org/drm/kernel/-/commit/2a2391f857cdc5cf16f8df030944cef8d3d2bc30

>
> BR,
> Jani.
>
>

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)


  reply	other threads:[~2024-09-12 13:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-11 18:06 Tejas Vipin
2024-09-12  7:19 ` Thomas Zimmermann
2024-09-12  8:48   ` Jani Nikula
2024-09-12  8:56     ` Jani Nikula
2024-09-12  9:26       ` Thomas Zimmermann
2024-09-12  9:38         ` Jani Nikula
2024-09-12 10:45           ` Thomas Zimmermann
2024-09-12 11:25             ` Jani Nikula
2024-09-12 13:10               ` Thomas Zimmermann [this message]
2024-09-12 13:25                 ` Jani Nikula
2024-09-12  9:18     ` Thomas Zimmermann
2024-09-12  9:30       ` Jani Nikula
2024-09-12 11:08         ` Thomas Zimmermann
2024-09-12 13:30           ` Ville Syrjälä
2024-09-12 14:29   ` Tejas Vipin
2024-09-23  9:36     ` Jani Nikula

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=1d16c1ae-2e27-4daa-b8a6-5eab179ef551@suse.de \
    --to=tzimmermann@suse.de \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=airlied@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=patrik.r.jakobsson@gmail.com \
    --cc=tejasvipin76@gmail.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

all inboxes | Powered by JetHome®