linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dariusz Marcinkiewicz <darekm@google.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: linux-media@vger.kernel.org, hans.verkuil@cisco.com,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] media: cec: DRM connector to CEC dev mapping
Date: Tue, 9 Apr 2019 09:33:06 +0200	[thread overview]
Message-ID: <CALFZZQHjtToO_gmUQUZUsdb84LarsfTsvuoQTws6h_2ypOGhbg@mail.gmail.com> (raw)
In-Reply-To: <c1b7d461-d0b1-e3a4-f8fd-7c757a5e38f6@xs4all.nl>

Hi Hans.

On Thu, Apr 4, 2019 at 2:23 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
...
> > Notes:
> >     Sending the patch in its current form the get feedback if that is
> >     considered a right approach or if some other way of learning
> >     the mapping in userland is preferred.
>
> Thank you for this patch. It's interesting, but I think it should be
> redesigned a bit.
>
> Basically what you want to do is to provide a way for userspace to associate
> the CEC device with the HDMI connector it is associated with.
>
> But this information is known the moment the cec adapter is allocated or the
> cec_notifier is registered for a connector. So I would provide this information
> at that time, rather than through separate functions. This makes everything
> nicely atomic. This also avoids the need of a connector_info event, since the
> connector info is known from the very beginning. You still need the ioctl to
> obtain this information, though.
>
Great, good to know that the event can be removed. I wasn't 100% sure
if in all cases it can be assumed that connector info will be set on
the notifier before the CEC adapter is created, hence the event.
Sending an updated patch with the event no longer there.

> There are also two related issues.
>
> Firstly, CEC is used not only for DRM, but also for V4L2, and it makes sense
> to provide connector info there as well. For V4L2 this would probably look
> like this (tentative as I am not completely sure about the major/minor numbers):
>
>         struct v4l2_connector_info {
>                 __u32 major;
>                 __u32 minor;
>                 __u16 connector_mask;
>         }
>
> Where the major/minor numbers determine the video or v4l-subdev device that controls
> the HDMI connector(s). Since a CEC device for HDMI receivers can be responsible for
> multiple HDMI inputs we need the connector_mask to indicate which HDMI inputs it is
> associated with.
Would simply allowing for multiple connector types to be hooked up
with cec adapters be sufficient to cover this? Please take a look at
the follow up patch.

>
> Secondly, there are USB-CEC dongles that are not directly associated with an HDMI
> connector since the driver simply doesn't know. But it would be nice if the user
> can provide that information. I did a proof-of-concept here:
>
> https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=pulse8-notifier
>
> and it works fine. But the problem is that the connector name is currently only
> available on the i915 via port_identifier(port), and that that port identifier
> string is not visible to the end-user. I had to try various port names ("Port A",
> "Port B", etc) before I hit the right one.
>
Is there something extra needed for the proposed approach to work in
this case? Looking at the above change - since a notifier is going to
be used to pass the connector info, it should work there as well. And
not being a DRM specialist myself, I don't know what would be the
better way (that wouldn't rely on port identifier) of pairing up a
connector with an adapter.

Thank you very much for your comments and apologies for delayed response.

  reply	other threads:[~2019-04-09  7:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-04  7:30 [RFC PATCH] media: cec: DRM connector to CEC dev mapping Dariusz Marcinkiewicz
2019-04-04 12:23 ` Hans Verkuil
2019-04-09  7:33   ` Dariusz Marcinkiewicz [this message]
2019-04-09  7:33   ` [RFC PATCH v2] " Dariusz Marcinkiewicz
2019-04-11 13:37     ` Hans Verkuil

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=CALFZZQHjtToO_gmUQUZUsdb84LarsfTsvuoQTws6h_2ypOGhbg@mail.gmail.com \
    --to=darekm@google.com \
    --cc=hans.verkuil@cisco.com \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    /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 NNTP newsgroup(s).