Hi Frediano
El lun, 23-10-2017 a las 07:31 -0400, Frediano Ziglio escribió:
HiEl lun, 23-10-2017 a las 06:57 -0400, Frediano Ziglio escribió:Hello list,Recently, we updated the Qemu version being used by flexVDI. We were using a pre-3.3 QXL device, so it did not provide the client_monitors_config callback and that message was getting through to the VDAgent, which in turn changed the resolution of the guest. This was working flawlessly both on Windows and Linux guests.With the new version (we are using qemu v2.6.0 from RHEV 7.3 and spice-server v0.12.8 from RHEL 7.4, with a couple of small changes), the client_monitors_config callback gets called. This works correctly on Windows guests, but on Linux guests (tested mainly with Fedora 25, stock vdagent and QXL Xorg driver, which are quite up to date) the following happens when a resolution change is requested by the client:- The new resolution is detected by the Xorg server, it can be seen with xrandr.- If the old resolution was a custom one, the display changes to the new one.- If the old resolution was a standard one (like 640x480, 1024x768, 1920x1080, etc), the display DOES NOT change to the new one.I have read quickly through the list archive but found nothing about this problem. Is there something we are missing? Something else we should be upgrading too?Possible solutions we are considering:- Change to virtio-vga for Linux guests. However, we'd rather use the same graphics device for all guest types.this is more a workaround of the problem- Do not filter the monitors config message and let the vdagent change the resolution.Sorry, not clear which component is filtering this message out.I have some remembrance that the path is a bit different from Windows to Linux.This message is captured by the Spice server. If the QXL device (provided by Qemu) implements a client_monitors_config callback, then the message is filtered out and the callback is called instead. This does not depend on whether the guest is Windows or Linux.For QXL guest can set int_mask in order to filter the message or not (just checked),and I think Windows and Linux behave different in this. If I remember on Windowsthe message is handled by the agent which talk to the driver to set the resolution.
I cannot find this int_mask you are talking about. Maybe we are not talking about the same component. I am looking at the spice server. In file agent-msg-filter.c, function agent_msg_filter_process_data, which gets called when a new message arrives at the main channel. It checks the message type, and calls red_dispatcher_use_client_monitors_config if the type is VD_AGENT_MONITORS_CONFIG. There is no mask there. If that function returns FALSE, the message is sent to the agent. Otherwise, the function reds_on_main_agent_monitors_config is called and the message is not sent.
- Fix whatever needs to be fixed in order to make this work. However, we are not sure where the problem is. Spice server? Xorg? Qemu?Do you have any comments on this?From your description and the fact that work on Windows guest looks like is a problem with the guest, either the agent or the kernel qxl driver.That's what I think, too. And since the message is not received by the guest agent, I would say it is the qxl driver, either in the kernel or in Xorg. I'll try to see if there is something in there.Thanks in advance.Frediano
--
|
Javier Celaya Chief Technology Officer |
|
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel