Re: [RFC PATCH v2 00/20] Monitor ID rework

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > > Ok, that makes some sense. You do however need some synchronization
> > > mechanism between the different framebuffers? (Imagine a video playing
> > > across two displays)
> > 
> > The linux kernel kms drivers support atomic page flips for both
> > displays, and wayland actually uses that.
> 
> Ok, what about the SPICE case? If we use one surface per display, we
> also need some sort of synchronization mechanism.
> 
> Now I'm mostly guessing here, but from what I understand, we could send
> the frames of multiple monitors in sync over a single display channel,
> but if we use multiple channels, they are not synchronized and would
> arrive rather arbitrarily on the client?

With a single channel it is easier to syncronize them, yes.

Right now qxl has two types of surfaces.  Primary (the actual display)
and non-primary (basically pixel data storage).  Spice ops can (among
other 2d ops) blit data from one surface to another.  So you can store
the content of a window in a surface, then blit it to primary to draw
the window.  This was state of the art roughly 15 years ago, when qxl
was designed.

These days nobody uses 2d ops any more.  Compositors use the 3d engine
(or llvmpipe in case there is no 3d hardware) to render the desktop to a
framebuffer.  Then they ask the gpu to flip to that framebuffer on the
next vblank interval.  While the first framebuffer is shown they render
the next frame to second framebuffer, then flip again so the two
framebuffer swap roles.

I think we can support this in spice/qxl this way:

  (1) Drop the concept of a "primary" surface (except for backward
      compatibility of course).
  (2) Allow to map any surface to any monitor (i.e. "please display
      surface 17 on monitor 1").

Workflow would look like this then:

  (1) userspace creates a drm framebuffer
  (2) qxl driver defines a surface for it.
  (2) userspace renders into the framebuffer.
  (3) userspace asks qxl to show that framebuffer.
  (4) qxl will send updates for that framebuffer to spice-server.
  (5) qxl will send monitor map request for that framebuffer to
      spice-server.

The same will work just fine for two monitors.  And given that qxl will
first send the bulky updates for both framebuffers and then flip both
with a small map request command syncronization should not be a big
issue.  If needed it should be possible to explicitly group the map
requests, or have a single message which sets the map for all monitors
of the channel.

cheers,
  Gerd

_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux Virtualization]     [Linux Virtualization]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]