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

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

 



> 
> On Fri, Aug 24, 2018 at 11:12:43AM +0200, Lukáš Hrázký wrote:
> > On Thu, 2018-08-23 at 22:42 +0200, Gerd Hoffmann wrote:
> > >   Hi,
> > > 
> > > > "we only support" seems to just state the use cases before adding
> > > > vGPU but we are trying to support vGPU cases.
> > > > If even we decide that for vGPU cards we always have monitor_id == 0
> > > 
> > > Yes, we want this for sure.  One channel per display.
> > 
> > For sure? This deserves a justification.
> 
> That is the way modern display architectures (including wayland) are
> working.  One framebuffer per display.  Not one huge framebuffer
> covering all heads, then defining rectangles for each display, like qxl
> handles multihead on linux (with xorg).
> 
> And the qxl way of doing multihead on linux starts to cause problems:
> https://bugzilla.redhat.com/show_bug.cgi?id=1611141
> 

Having a single frame buffer for channel is a current implementation
limit which can be relaxed.

I agree the main problem of this rework should be vdagent "mapping"
of the display_id received although honestly as we are changing the
protocol for different reasons I would remove the ugly formula and
all its subtle assumptions all the way around.

Frediano
_______________________________________________
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]