Hi,
> 1. Focus on only decoder/encoder functionalities first.
>
> As Tomasz said earlier in this thread, it'd be too complicated to support
> camera
> usage at the same time. So, I'd suggest to make it just a generic mem-to-mem
> video processing device protocol for now.
> If we finally
On 03.12.2019 10:00, Gerd Hoffmann wrote:
...snip...
PCM_MSG -- I would drop the feature bit and make that mandatory, so we
have a common baseline on which all drivers and devices can agree on.
Then we need to inform device what "transport" will be in use (I assumed it
would be feature
On 02.12.2019 14:55, Mark Brown wrote:
On Mon, Dec 02, 2019 at 02:30:44PM +0100, Anton Yakovlev wrote:
On 28.11.2019 13:19, Mark Brown wrote:
If you're talking about compressed as opposed to PCM audio here (you say
decompression) I think you probably want a different spec there, the
flow
Hi,
> > > For example, in case
> > > of GUEST_MEM the request could be followed by a buffer sg-list.
> >
> > I'm not convinced guest_mem is that useful. host_mem allows to give the
> > guest access to the buffers used by the hosts sound hardware, which is
> > probably what you need if the MSG
On Wed, Dec 4, 2019 at 1:16 AM Gerd Hoffmann wrote:
>
> Hi,
>
> > 1. Focus on only decoder/encoder functionalities first.
> >
> > As Tomasz said earlier in this thread, it'd be too complicated to support
> > camera
> > usage at the same time. So, I'd suggest to make it just a generic
On Thu, Nov 28, 2019 at 5:20 AM Gerd Hoffmann wrote:
>
> This patch adds a new virtio feature for shared resources.
>
> Shared resources are allocated by the guest from normal ram, like
> traditional resources. They can be used by the guest almost like
> traditional resources, the only exception
Hi,
> If the following scenario happens:
>
> 1) Driver sends RESOURCE_CREATE_2D shared request
> 2) Driver sends ATTACH_BACKING request
> 3) Device creates a shared resource
> 4) Driver sends SET_SCANOUT request
> 5) Device sends shared resource to display
> 6) Driver sends DETACH_BACKING
