All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: "Hoosier, Matt" <Matt.Hoosier@garmin.com>
Cc: Simon Ser <contact@emersion.fr>,
	"wayland-devel@lists.freedesktop.org"
	<wayland-devel@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: Multiple DRI card detection in compositor systemd units
Date: Thu, 23 Sep 2021 16:39:22 +0300	[thread overview]
Message-ID: <20210923163922.1537fb36@eldfell> (raw)
In-Reply-To: <8983CFBC-2D55-4AA8-ACFD-10EE410FFAEA@garmin.com>

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

On Wed, 22 Sep 2021 16:16:48 +0000
"Hoosier, Matt" <Matt.Hoosier@garmin.com> wrote:

> 
> The /dev/dri/by-path idea works, I suppose, if you have different
> physical graphics cards. In my case, that's not true. These are
> virtualized cards that the silicon vendor's DRM drivers use to expose
> different subsets of DRM resources as different cards. So there's
> only one /dev/dri/by-path card here. Think: DRM leases, but with the
> lessees popping out as card nodes rather than arranged dynamically
> using the drm ioctl()'s to manufature leases.

That's the standard solution though, I believe: use devpath for
matching the device, because the device doesn't randomly jump from a
physical connector (e.g. PCIe slot) to another.

But since you have virtual cards, that obviously doesn't work. I'm
afraid you need to solve this with your virtual card provider. Maybe
there could be some sort of virtual bus with persistent addresses which
would make devpath reliable?

I wouldn't expect drmGetVersion()->name to differ between the (virtual)
devices since they are all using the same driver, right?


Sorry,
pq


> The use-case here is to allow separate DRM domains for each of
> several containers. It's not really desirable to try to funnel
> everybody's graphics through a common compositor that runs all the
> connectors.
> 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-09-23 13:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-22 15:21 Multiple DRI card detection in compositor systemd units Hoosier, Matt
2021-09-22 15:29 ` Simon Ser
2021-09-22 16:16   ` Hoosier, Matt
2021-09-23 13:39     ` Pekka Paalanen [this message]
2021-09-23 14:49       ` Hoosier, Matt

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=20210923163922.1537fb36@eldfell \
    --to=ppaalanen@gmail.com \
    --cc=Matt.Hoosier@garmin.com \
    --cc=contact@emersion.fr \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=wayland-devel@lists.freedesktop.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.