[Spice-devel] Fedora 25 guest no changing resolution correctly

[Javier Celaya]

Hi Frediano
El lun, 23-10-2017 a las 07:31 -0400, Frediano Ziglio escribió:
> Hi
> 
> El 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 Windows
> the 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
        
    
    
      
      
        
        javier.celaya at flexvdi.com
      
      
       
        
        +34 696 969 959 
      
      
      
         
        @j_celaya
      
      
        
        Legal Information and Privacy Policy
      
    
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20171023/e767c692/attachment.html>