Re: linux-dmabuf and eglBindWaylandDisplayWl

[Matt Hoosier]

On Thu, Apr 9, 2020 at 5:51 PM Simon Ser  wrote:

> On Friday, April 10, 2020 12:48 AM, Matt Hoosier 
> wrote:
>
> > As a compositor author, do I have to account for the possibility that
> the EGL implementation may provide (squat on) the
> “zwp_linux_linux_dmabuf_v1” buffer factory itself, it is that strictly the
> prerogative of the individual compositor?
>
> No, this is the compositor's responsibility only.
>

Thanks, I think that answers the original question pretty clearly.

-Matt
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: linux-dmabuf and eglBindWaylandDisplayWl

[Simon Ser]

On Friday, April 10, 2020 12:48 AM, Matt Hoosier  wrote:

> As a compositor author, do I have to account for the possibility that the EGL 
> implementation may provide (squat on) the “zwp_linux_linux_dmabuf_v1” buffer 
> factory itself, it is that strictly the prerogative of the individual 
> compositor?

No, this is the compositor's responsibility only.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: linux-dmabuf and eglBindWaylandDisplayWl

[Matt Hoosier]

+ list

On Thu, Apr 9, 2020 at 5:48 PM Matt Hoosier  wrote:

> On Thu, Apr 9, 2020 at 5:42 PM Scott Anderson  wrote:
>
>> On 10/04/20 10:34 am, Matt Hoosier wrote:
>> > On Thu, Apr 9, 2020 at 2:51 PM Simon Ser > > > wrote:
>> >
>> > On Thursday, April 9, 2020 9:41 PM, Matt Hoosier
>> > mailto:matt.hoos...@gmail.com>> wrote:
>> >
>> >  > If I remember correctly, I've read various messages on the list
>> > here saying that eventually it would be preferred for EGL
>> > implementations would just use linux-dmabuf as their buffer factory.
>> > That would mean that EGL backends would now also want to register a
>> > zwp_linux_dmabuf_v1 global.
>> >
>> > Mesa already binds to zwp_linux_dmabuf_v1 and uses it if possible.
>> >
>> >  > I'm wondering how the logistics on that would work. Normally, you
>> > can't register two globals having the same name in the compositor.
>> > Does this lead to a conflict between the EGL implementation's
>> > ability to enumerate a linux-dmabuf API for its own use, and the
>> > linux-dmabuf API that the overall compositor might offer?
>> >
>> > Just to be clear: we're talking about the client side right?
>> >
>> > It's fine to bind twice to the same global. This creates two
>> > independent objects.
>> >
>> >
>> > No, I mean from the standpoint of a compositor implementer.
>> >
>> > -Matt
>>
>> Mesa does not implement zwp_linux_dmabuf_v1 on the compositor side. It's
>> the compositor's job to do that, and they can use EGL or Vulkan
>> extensions [1] to import them for rendering with, or otherwise use them
>> with anything capable of consuming dmabufs.
>>
>> eglBindWaylandDisplayWL still only handles wl_drm.
>>
>> - Scott
>>
>> [1]:
>>
>> https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
>>
>> https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VK_EXT_external_memory_dma_buf
>
>
> Okay, interesting that Mesa’s client will use Linux-dmabuf if the
> compositor happens to provide it, but the server-side EGL of Mesa offers
> wl_drm as a fallback.
>
> As a compositor author, do I have to account for the possibility that the
> EGL implementation may provide (squat on) the “zwp_linux_linux_dmabuf_v1”
> buffer factory itself, it is that strictly the prerogative of the
> individual compositor?
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: linux-dmabuf and eglBindWaylandDisplayWl

[Scott Anderson]

On 10/04/20 10:34 am, Matt Hoosier wrote:
On Thu, Apr 9, 2020 at 2:51 PM Simon Ser > wrote:


On Thursday, April 9, 2020 9:41 PM, Matt Hoosier
mailto:matt.hoos...@gmail.com>> wrote:

 > If I remember correctly, I've read various messages on the list
here saying that eventually it would be preferred for EGL
implementations would just use linux-dmabuf as their buffer factory.
That would mean that EGL backends would now also want to register a
zwp_linux_dmabuf_v1 global.

Mesa already binds to zwp_linux_dmabuf_v1 and uses it if possible.

 > I'm wondering how the logistics on that would work. Normally, you
can't register two globals having the same name in the compositor.
Does this lead to a conflict between the EGL implementation's
ability to enumerate a linux-dmabuf API for its own use, and the
linux-dmabuf API that the overall compositor might offer?

Just to be clear: we're talking about the client side right?

It's fine to bind twice to the same global. This creates two
independent objects.


No, I mean from the standpoint of a compositor implementer.

-Matt


Mesa does not implement zwp_linux_dmabuf_v1 on the compositor side. It's 
the compositor's job to do that, and they can use EGL or Vulkan 
extensions [1] to import them for rendering with, or otherwise use them 
with anything capable of consuming dmabufs.


eglBindWaylandDisplayWL still only handles wl_drm.

- Scott

[1]:
https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#VK_EXT_external_memory_dma_buf
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: linux-dmabuf and eglBindWaylandDisplayWl

[Matt Hoosier]

On Thu, Apr 9, 2020 at 2:51 PM Simon Ser  wrote:

> On Thursday, April 9, 2020 9:41 PM, Matt Hoosier 
> wrote:
>
> > If I remember correctly, I've read various messages on the list here
> saying that eventually it would be preferred for EGL implementations
> would just use linux-dmabuf as their buffer factory. That would mean that
> EGL backends would now also want to register a zwp_linux_dmabuf_v1 global.
>
> Mesa already binds to zwp_linux_dmabuf_v1 and uses it if possible.
>
> > I'm wondering how the logistics on that would work. Normally, you can't
> register two globals having the same name in the compositor. Does this lead
> to a conflict between the EGL implementation's ability to enumerate a
> linux-dmabuf API for its own use, and the linux-dmabuf API that the overall
> compositor might offer?
>
> Just to be clear: we're talking about the client side right?
>
> It's fine to bind twice to the same global. This creates two
> independent objects.


No, I mean from the standpoint of a compositor implementer.

-Matt
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: linux-dmabuf and eglBindWaylandDisplayWl

[Simon Ser]

On Thursday, April 9, 2020 9:41 PM, Matt Hoosier  wrote:

> If I remember correctly, I've read various messages on the list here saying 
> that eventually it would be preferred for EGL implementations would just use 
> linux-dmabuf as their buffer factory. That would mean that EGL backends would 
> now also want to register a zwp_linux_dmabuf_v1 global.

Mesa already binds to zwp_linux_dmabuf_v1 and uses it if possible.

> I'm wondering how the logistics on that would work. Normally, you can't 
> register two globals having the same name in the compositor. Does this lead 
> to a conflict between the EGL implementation's ability to enumerate a 
> linux-dmabuf API for its own use, and the linux-dmabuf API that the overall 
> compositor might offer?

Just to be clear: we're talking about the client side right?

It's fine to bind twice to the same global. This creates two
independent objects.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

linux-dmabuf and eglBindWaylandDisplayWl

[Matt Hoosier]

Hi,

Historically, many EGL implementations have registered a private wl_drm
buffer factory for use internally by the implementation's Wayland backend,
as part of the setup work done go eglBindWaylandDisplayWl().

Separately, compositors have started to implement explicit support for the
zwp_linux_dmabuf_v1 buffer factory, independent of the GPU backend.

If I remember correctly, I've read various messages on the list here saying
that eventually it would be preferred for EGL implementations would just
use linux-dmabuf as their buffer factory. That would mean that EGL backends
would now also want to register a zwp_linux_dmabuf_v1 global.

I'm wondering how the logistics on that would work. Normally, you can't
register two globals having the same name in the compositor. Does this lead
to a conflict between the EGL implementation's ability to enumerate a
linux-dmabuf API for its own use, and the linux-dmabuf API that the overall
compositor might offer?

-Matt
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Chrome Remote Desktop and Wayland

[The Rasterman]

On Thu, 9 Apr 2020 12:05:57 -0700 Erik Jensen  said:

> On Thu, Apr 9, 2020 at 12:17 AM Jonas Ådahl  wrote:
> [snip]
> > DRM master and input device revocation should be handled more or less
> > already by most if not all compositors, by closing devices, by then
> > going dorment until access is returned to the compositor. I don't know
> > if there is any compositor that can already handle continuing it's
> > session headless with an active PipeWire stream.
> 
> Ideally, (though not a strict requirement for us), there'd also be a
> way to specify the resolution of the offscreen virtual display (to
> match the resolution of the client) without modifying the modes used
> locally once the session is switched back to the local display(s).
> 
> [snip]
> > More or less, yes. Launching sessions without DRM master and going
> > headless is probably things we can add capability fields for in the
> > session .desktop files, and show dialogs like "Wait" or "Terminate
> > session" if a conflict appears (as mentioned in the linked GDM bug). All
> > of this would also not need be specific to a certain windowing system,
> > so that you we can use the same APIs for handling both Wayland sessions,
> > X11 sessions, and whatever more types that may eventually appear.
> 
> You mentioned that integration with session management makes sense to
> discuss with display manager folks. Where would be the best place to
> discuss other such potential cross-windowing system remote-desktop
> APIs like .desktop fields or headless startup?

my take is this should be a daemon like a hybrid login manager/sshd, but
instead of a text login shell, it authenticates then launches a "virtual fb"
parent compositor that sets up a wayland compositor "rendering to ram" and then
launches the actual user session as a wayland client. this will require
compositors that are compatible need to support targeting both drm/kms directly
in the tty AND as a wayland client of this compositor. this compositor would
probably use something like the wayland fullscreen shell. it would be this
compositor that encodes and transmits the compositing results over the network
as well as reading in input from the remote system. the dbus session problem
just need working around probably with another dbus session bus launched for
this session and if apps have a problem with being run multiple times with
different dbus sessions on the same system/homedir.. well.. there is nothing to
be done - it's a problem with that app. it only matters if the user is logged
in on the console and remotely and uses one of these types of apps. they can
opt to not use them or do that, or these apps get fixed.

if they want to "take over their existing console login session" the same idea
applies but this remote compositor is actually a full system-wide fullscreen
compositor and can auth some user then redirect their on screen session to be
remote (and issue appropriate monitor reconfiguring when this happens) and
replace their on-console session with a picture of a horses behind until the
remote session ends... the same daemon can do both just with the option of it
being a system-wide console compositor as opposed to "virtual, only for remote
clients" most of the code is the same/shared. then they will bypass the above
singleton problem apps by having only a single login (gui one) and single dbus
session.

the takeaway from this is more that the ecosystem at large needs to support
compositors running as wayland clients with a system compositor using a
fullscreen shell with all the appropriate logic to handle real local screens and
expose them and let the client compositor configure them, as well as doing the
"virtual rendering to memory and fake a virtual screen and modify that one (or
ones if you want multiple screens) by unplugging/plugging it with new resolution
options etc. if this system compositor is fairly lean and efficient and
essentially doesn't get in the way of real desktop compositors, then it
probably will be supported by most major compositors eventually.

-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Chrome Remote Desktop and Wayland

[Erik Jensen]

On Thu, Apr 9, 2020 at 12:17 AM Jonas Ådahl  wrote:
[snip]
> DRM master and input device revocation should be handled more or less
> already by most if not all compositors, by closing devices, by then
> going dorment until access is returned to the compositor. I don't know
> if there is any compositor that can already handle continuing it's
> session headless with an active PipeWire stream.

Ideally, (though not a strict requirement for us), there'd also be a
way to specify the resolution of the offscreen virtual display (to
match the resolution of the client) without modifying the modes used
locally once the session is switched back to the local display(s).

[snip]
> More or less, yes. Launching sessions without DRM master and going
> headless is probably things we can add capability fields for in the
> session .desktop files, and show dialogs like "Wait" or "Terminate
> session" if a conflict appears (as mentioned in the linked GDM bug). All
> of this would also not need be specific to a certain windowing system,
> so that you we can use the same APIs for handling both Wayland sessions,
> X11 sessions, and whatever more types that may eventually appear.

You mentioned that integration with session management makes sense to
discuss with display manager folks. Where would be the best place to
discuss other such potential cross-windowing system remote-desktop
APIs like .desktop fields or headless startup?

Thanks!
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Chrome Remote Desktop and Wayland

[Jonas Ådahl]

On Wed, Apr 08, 2020 at 11:17:14AM -0700, Erik Jensen wrote:
> On Wed, Apr 8, 2020 at 2:02 AM Jonas Ådahl  wrote:
> > Either multiple separate units (e.g. GDM and Chrome Remote Desktop login
> > manager) needs to both try to manage the same sessions via logind, which
> > sounds fragile and unlikely to be able to cope with the various security
> > policies mentioned above; or an session management API, using the D-Bus
> > system bus, needs to be added and implemented by the relevant display
> > managers. This API would need to handle things like opening headless
> > sessions without making them DRM master; handing over control of a
> > headless session if the session is supposed to be turned into a local
> > one, then hand it back etc, with all the various policy related to e.g.
> > when to show the lock screen or not taken into account.
> 
> It sounds like this would require a few new pieces:
>  * The session management API you mentioned for coordinating sessions.
>  * Compositor support for launching without DRM master.
>  * Compositor support for offscreen rendering when DRM master is
> revoked. (Presumably grant and revocation of DRM master is already
> handled due to VT switching? Do any compositors already support this
> if there's an ongoing PipeWire capture when they are put in the
> background?)

DRM master and input device revocation should be handled more or less
already by most if not all compositors, by closing devices, by then
going dorment until access is returned to the compositor. I don't know
if there is any compositor that can already handle continuing it's
session headless with an active PipeWire stream.

>  * A solution for input injection.
> 
> A remote desktop tool like Chrome Remote Desktop would then be
> responsible for using the new API to launch a new session without DRM
> master or revoke DRM master from an existing session (presumably
> returning the local display to the login screen), and then connecting
> to the appropriate Wayland session to initiate video capture and input
> injection.
> 
> Does that accurately reflect your suggested solution?

More or less, yes. Launching sessions without DRM master and going
headless is probably things we can add capability fields for in the
session .desktop files, and show dialogs like "Wait" or "Terminate
session" if a conflict appears (as mentioned in the linked GDM bug). All
of this would also not need be specific to a certain windowing system,
so that you we can use the same APIs for handling both Wayland sessions,
X11 sessions, and whatever more types that may eventually appear.


Jonas
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel