[vdsm] Modeling graphics framebuffer device in VDSM

Frantisek Kobzik fkobzik at redhat.com
Wed Apr 2 13:18:50 UTC 2014


AFAIK the conclusion was that the graphics should be modeled as a device, which is approach of my patch. Nothing more specific was discussed.

----- Original Message -----
From: "Saggi Mizrahi" <smizrahi at redhat.com>
To: "Frantisek Kobzik" <fkobzik at redhat.com>
Cc: vdsm-devel at lists.fedorahosted.org
Sent: Tuesday, April 1, 2014 1:53:36 PM
Subject: Re: [vdsm] Modeling graphics framebuffer device in VDSM

I remember there was a discussion about this.

https://lists.fedorahosted.org/pipermail/vdsm-devel/2013-November/002727.html

I don't remember what came of it in the end though.

----- Original Message -----
> From: "Frantisek Kobzik" <fkobzik at redhat.com>
> To: vdsm-devel at lists.fedorahosted.org
> Sent: Friday, March 28, 2014 3:06:17 PM
> Subject: [vdsm] Modeling graphics framebuffer device in VDSM
> 
> Dear VDSM devels,
> 
> I've been working on refactoring graphics devices in engine and VDSM for some
> time now and I'd like know your opinion of that.
> 
> The aim of this refactoring is to model graphics framebuffer (SPICE, VNC) as
> device in the engine and VDSM. This which is quite natural since libvirt
> treats
> graphics as a device and we have some kind of devices infrastructure in both
> projects. Another advantage (and actually the main reason for refactoring)
> is
> simplified support for multiple graphics framebuffers on a single vm.
> 
> Currently, passing information about graphics from engine to VDSM is done via
> 'display' param in conf. In the other direction VDSM informs the engine about
> graphics parameters ('displayPort', 'displaySecurePort', 'displayIp' and
> 'displayNetwork') in conf as well.
> 
> What I'd like to achieve is to encapsulate all this information in specParams
> of the new graphics device and use specParams as a place for transfering data
> about graphics device between engine and vdsm. What do you think?
> 
> the draft patch is here:
> http://gerrit.ovirt.org/#/c/23555/ (it's currently marked with '-1' but it
> puts
> some light on what the solution looks like so feel free to take a look).
> 
> Thanks,
> Franta.
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 


More information about the vdsm-devel mailing list