[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Wondering about cirris and stdvga
On Fri, Nov 25, 2016 at 07:17:31PM +0100, Dario Faggioli wrote: > On Mon, 2016-11-21 at 10:04 +0100, Dario Faggioli wrote: > > On Sat, 2016-11-19 at 12:56 +0200, Pasi Kärkkäinen wrote: > > > 2) It'd good to create an upstream Wayland bugreport and > > > investigate > > > more about why cirrus is broken with Wayland. > > > > > Sure, I can do that. > > > An update. > > The discussion here has gone on a bit: > https://bugzilla.redhat.com/show_bug.cgi?id=1227770 > > The conclusion seems to be that: > "cirrus (virtual) hardware is simply to old to run wayland." > > And so this is (and will very likely remain) a 'WONTFIX' for cirrus, at > least on Fedora. > > I've also opened a thread on wayland-devel mailing list: > https://lists.freedesktop.org/archives/wayland-devel/2016-November/0318 > 56.html > > There, I learned that Wayland is not the component to blame, as Wayland > is the protocol. So, in our case, the 'bug' is most likely in > gnome-shell / Mutter. > > That's not a good thing, though. In fact, just to cite a few sentences > from the thread: > > "Packed 24bpp is going to be pain, not least because I don't know of > any clients which render in packed-24" > > "The 24bpp paths in pretty much everything are also badly untested, so > that's asking for trouble." > > "you will need to test and fix every single Wayland compositor out > there." > > "I really think you'd be far far better off trying to figure out how to > move off the legacy Cirrus emulation as soon as you can." > > So, we can try seeing if I manage to get some logs out of Mutter to > figure out the actual bug more precisely _but_, considering all that > people have said both here and in the other forums, I think it would be > better to spend that time figuring out how to switch (and document this > for 4.8 and previous version, of course). Yes. Also as there does not seem to be any supported OS that _needs_ the old Cirrus OS to boot and function. Here is what I am thinking to propose for Xen 4.9: diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in index 52802d5..f77c7ee 100644 --- a/docs/man/xl.cfg.pod.5.in +++ b/docs/man/xl.cfg.pod.5.in @@ -1669,16 +1669,16 @@ If B<videoram> is set less than 128MB, an error will be triggered. =item B<stdvga=BOOLEAN> Select a standard VGA card with VBE (VESA BIOS Extensions) as the -emulated graphics device. The default is false (0) which means to emulate -a Cirrus Logic GD5446 VGA card. If your guest supports VBE 2.0 or -later (e.g. Windows XP onwards) then you should enable this. +emulated graphics device. The default is true (1) which means to emulate +a standard VGA card. If your guest does not support VBE 2.0 or is older than +Windows XP then should should disable this and use Cirrus Logic GD5446 VGA card. stdvga supports more video ram and bigger resolutions than Cirrus. This option is deprecated, use vga="stdvga" instead. =item B<vga="STRING"> Selects the emulated video card (none|stdvga|cirrus|qxl). -The default is cirrus. +The default is stdvga. In general, QXL should work with the Spice remote display protocol for acceleration, and QXL driver is necessary in guest in this case. diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c index 25389e1..ded5ebe 100644 --- a/tools/libxl/libxl_create.c +++ b/tools/libxl/libxl_create.c @@ -225,7 +225,7 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc, if (b_info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_NONE) b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_NONE; else - b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_CIRRUS; + b_info->u.hvm.vga.kind = LIBXL_VGA_INTERFACE_TYPE_STD; } if (!b_info->u.hvm.hdtype) > > Regards, > Dario > > -- > <<This happens because I choose it to happen!>> (Raistlin Majere) > ----------------------------------------------------------------- > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |