Discussion:
Sharing a KMS device
Troll Berserker
2018-09-18 19:22:48 UTC
Permalink
In DRM, only one application can be drmMaster at a time.
This is one of the reasons why one can't run a Xorg server per Connector to have multiseat with one GPU.

Is it theoretically possible to implement a driver (let's call it shared-modesetting) which will offload mode setting to a helper daemon (drmMaster) thus allowing to run multiple Xorg servers on one DRM device? (provided that there are enough CRTCs (?) available).
_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Inf
Keith Packard
2018-09-18 19:49:20 UTC
Permalink
Post by Troll Berserker
Is it theoretically possible to implement a driver (let's call it
shared-modesetting) which will offload mode setting to a helper daemon
(drmMaster) thus allowing to run multiple Xorg servers on one DRM
device? (provided that there are enough CRTCs (?) available).
We've recently add a new technique in DRM called 'leasing', which allows
you to create a new DRM controller for a subset of the available resources.
--
-keith
Troll Berserker
2018-09-18 21:01:51 UTC
Permalink
Post by Keith Packard
Post by Troll Berserker
Is it theoretically possible to implement a driver (let's call it
shared-modesetting) which will offload mode setting to a helper daemon
(drmMaster) thus allowing to run multiple Xorg servers on one DRM
device? (provided that there are enough CRTCs (?) available).
We've recently add a new technique in DRM called 'leasing', which allows
you to create a new DRM controller for a subset of the available resources.
Cool. In your talk you even mentions multiseating.
AFAIU with this technique one doesn't get multiple /dev/dri/card* for a GPU out of the box, so it is not possible to use unmodified modesetting driver to run multiple X servers.
_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: htt
Keith Packard
2018-09-18 22:02:44 UTC
Permalink
Post by Troll Berserker
Cool. In your talk you even mentions multiseating.
AFAIU with this technique one doesn't get multiple /dev/dri/card* for
a GPU out of the box, so it is not possible to use unmodified
modesetting driver to run multiple X servers.
Correct. I have posted X server patches to pass the DRM file descriptor
in from an external program, and a sample program which creates a lease
for that purpose.
--
-keith
Troll Berserker
2018-09-18 23:21:53 UTC
Permalink
Post by Keith Packard
Post by Troll Berserker
Cool. In your talk you even mentions multiseating.
AFAIU with this technique one doesn't get multiple /dev/dri/card* for
a GPU out of the box, so it is not possible to use unmodified
modesetting driver to run multiple X servers.
Correct. I have posted X server patches to pass the DRM file descriptor
in from an external program, and a sample program which creates a lease
for that purpose.
Hmm. I see that drmDropMaster became conditional:

if (!ms->fd_passed)
drmDropMaster(ms->fd);

(https://github.com/mirror/xserver/commit/38ff29ec8ead0a293f50ac52146199babe4205ca#diff-4db01e9b0bfda6e79f6b85426b0cdb0aR1780)

I was thinking that may be it is possible to implement a CUSE driver to expose leased descriptors as /dev/dri/card* devices so that it would be possible to run X server unmodified.
But now I see that these leased FDs are somehow special so you can't perform drmDropMaster on them.
Why?
_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x
Keith Packard
2018-09-18 23:42:37 UTC
Permalink
This post might be inappropriate. Click to display it.
Troll Berserker
2018-09-19 00:16:40 UTC
Permalink
Post by Keith Packard
Post by Troll Berserker
if (!ms->fd_passed)
drmDropMaster(ms->fd);
That's actually a fix which is necessary so that the lessee doesn't give
away control of the whole device.
I've missed that drmSetMaster is also conditional now.
I was thinking that lessee has to perform drmSetMaster in order to use the FD.
Such an asymmetry between the Owner and Lessees seems unfortunate for me.
Post by Keith Packard
Post by Troll Berserker
I was thinking that may be it is possible to implement a CUSE driver
to expose leased descriptors as /dev/dri/card* devices so that it
would be possible to run X server unmodified.
I suppose it could, but I'm not sure why you'd want to?
To pretend that there are multiple GPUs in a system to reuse multiseat setup methods for the case of multiple GPUs.
Prolly CUSE method wouldn't work even if there was a symmetry, because seats are defined in terms of /sys/devices, not /dev/dri/cards
_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http
Pekka Paalanen
2018-09-19 07:18:32 UTC
Permalink
On Tue, 18 Sep 2018 16:42:37 -0700
Post by Keith Packard
Post by Troll Berserker
if (!ms->fd_passed)
drmDropMaster(ms->fd);
That's actually a fix which is necessary so that the lessee doesn't give
away control of the whole device.
Hi Keith,

sorry to bump in, but do you mean that a lessee doing drmDropMaster()
will both succeed and drop master also for the lessor (and recursively
through the whole leasing tree up and down as a consequence)?


Thanks,
pq
Keith Packard
2018-09-19 14:54:54 UTC
Permalink
Post by Pekka Paalanen
Hi Keith,
sorry to bump in, but do you mean that a lessee doing drmDropMaster()
will both succeed and drop master also for the lessor (and recursively
through the whole leasing tree up and down as a consequence)?
If that call weren't disabled for lessees, then yes. And, that's why
patch 761e05a702f5d537ffcca1ba933f9f0a968aa022 was added...
--
-keith
Troll Berserker
2018-09-19 15:12:03 UTC
Permalink
Post by Keith Packard
Post by Pekka Paalanen
Hi Keith,
sorry to bump in, but do you mean that a lessee doing drmDropMaster()
will both succeed and drop master also for the lessor (and recursively
through the whole leasing tree up and down as a consequence)?
If that call weren't disabled for lessees, then yes. And, that's why
patch 761e05a702f5d537ffcca1ba933f9f0a968aa022 was added...
And the ioctl will return EINVAL...
What is the motivation behind such asymmetry?


BTW, what is 'mastern'? (DRM_DEBUG_LEASE("Attempt to drop lessee %d as mastern", file_priv->master->lessee_id);)
_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info
Troll Berserker
2018-09-19 15:13:06 UTC
Permalink
Post by Troll Berserker
BTW, what is 'mastern'? (DRM_DEBUG_LEASE("Attempt to drop lessee %d as mastern", file_priv->master->lessee_id);)
Sry, it is already fiexed.
_______________________________________________
xorg-***@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://list
Pekka Paalanen
2018-09-20 07:20:25 UTC
Permalink
On Wed, 19 Sep 2018 07:54:54 -0700
Post by Keith Packard
Post by Pekka Paalanen
Hi Keith,
sorry to bump in, but do you mean that a lessee doing drmDropMaster()
will both succeed and drop master also for the lessor (and recursively
through the whole leasing tree up and down as a consequence)?
If that call weren't disabled for lessees, then yes. And, that's why
patch 761e05a702f5d537ffcca1ba933f9f0a968aa022 was added...
Very good, thanks!
pq

Continue reading on narkive:
Loading...