Re: [PATCH v3 1/2] drm/virtio: Add window server support

From: Pekka Paalanen <ppaalanen@gmail.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	David Airlie <airlied@linux.ie>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	Jason Wang <jasowang@redhat.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org, kernel@collabora.com
Subject: Re: [PATCH v3 1/2] drm/virtio: Add window server support
Date: Tue, 13 Feb 2018 09:41:22 +0200	[thread overview]
Message-ID: <20180213094122.5675d5f9@eldfell> (raw)
In-Reply-To: <20180212114540.iygbha554busy4ip@sirius.home.kraxel.org>

[-- Attachment #1.1: Type: text/plain, Size: 1849 bytes --]

On Mon, 12 Feb 2018 12:45:40 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:

>   Hi,
> 
> > >    (a) software rendering: client allocates shared memory buffer, renders
> > >        into it, then passes a file handle for that shmem block together
> > >        with some meta data (size, format, ...) to the wayland server.
> > > 
> > >    (b) gpu rendering: client opens a render node, allocates a buffer,
> > >        asks the cpu to renders into it, exports the buffer as dma-buf
> > >        (DRM_IOCTL_PRIME_HANDLE_TO_FD), passes this to the wayland server
> > >        (again including meta data of course).
> > > 
> > > Is that correct?  
> > 
> > Both are correct descriptions of typical behaviors. But it isn't spec'ed
> > anywhere who has to do the buffer allocation.  
> 
> Well, according to Pekka's reply it is spec'ed that way, for the
> existing buffer types.  So for server allocated buffers you need
> (a) a wayland protocol extension and (b) support for the extension
> in the clients.

Correct. Or simply a libEGL that uses such Wayland extension behind
everyone's back. I believe such things did at least exist, but are
probably not relevant for this discussion.

(If there is a standard library, like libEGL, loaded and used by both a
server and a client, that library can advertise custom private Wayland
protocol extensions and the client side can take advantage of them,
both without needing any code changes on either the server or the
client.)

> We also need a solution for the keymap shmem block.  I guess the keymap
> doesn't change all that often, so maybe it is easiest to just copy it
> over (host proxy -> guest proxy) instead of trying to map the host shmem
> into the guest?

Yes, I believe that would be a perfectly valid solution for that
particular case.

Thanks,
pq

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

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel