From: "Hoosier, Matt" <Matt.Hoosier@garmin.com>
To: Simon Ser <contact@emersion.fr>
Cc: "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: Wed, 22 Sep 2021 16:16:48 +0000 [thread overview]
Message-ID: <8983CFBC-2D55-4AA8-ACFD-10EE410FFAEA@garmin.com> (raw)
In-Reply-To: <xiT2GOL-X7GZiZUihjkIOFEbbS3vuVQrvogRKQjVdONfi07OwXydRhIUWU_elgmh0Ug9mAUONLEDC-bQe69fsOcd7Iq31R8T_Ai5KGhOnzE=@emersion.fr>
I get the intuition behind the suggestion to aggregate using logind seats, as far as it goes. But it still seems to me that this just pushes the question back: how do you identify which card is which in order to assign it to a seat? Normally this is done using udev rules, right? Additionally, I'm working with some constraints that not all of the compositors are logind-aware. I realize that's not really your problem, and it doesn't really influence the merits of your suggestion.
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.
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.
Thanks for the thoughts.
-Matt
On 9/22/21, 10:29 AM, "Simon Ser" <contact@emersion.fr> wrote:
CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
Maybe try creating multiple physical seats with logind, and start each
compositor on its own seat? A physical seat is a collection of devices like
DRM nodes and evdev device files.
Also udev creates files in /dev/dri/by-path/, these should be stable across
reboots. `udevadm settle` before a compositor start-up can wait for udev to
finish its job.
Out of curiosity, can you explain your use-case? Why do you need to start
multiple compositors, each on its own GPU?
________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
next prev parent reply other threads:[~2021-09-23 7:09 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 [this message]
2021-09-23 13:39 ` Pekka Paalanen
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=8983CFBC-2D55-4AA8-ACFD-10EE410FFAEA@garmin.com \
--to=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.