Re: New xrandr multi-mon / arbitrary resolution support issues

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

 



> Hi,
> 
> On 08/27/2012 12:09 PM, Alon Levy wrote:
> > On Mon, Aug 27, 2012 at 11:20:09AM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> So I've been playing around with this more, and except for the
> >> issues
> >> when going fullscreen with multiple monitors (the one where the 2
> >> windows end up
> >> on the same monitor), things look good.
> >>
> >> There are some issues with the agent which need some looking into
> >> though IMHO:
> >>
> >> 1) Sometimes messages like this one show up in the logs:
> >> Aug 27 10:52:50.318895 spice-vdagent[1064]: err: delete_mode of in
> >> use mode, setting crtc to NULL mode
> >
> > You cannot delete an in use mode, that's all the message is about -
> > It
> > should be a warning, not an "err:".
> 
> In that case it should not even be a warning but a debug message.
> 
> I must say even with that said, that I'm still not thrilled by the
> existing behavior
> though. The setting of the crtc to NULL feels like a hack to me.
> 
> To me a better solution would be to:
> 
> 1) Use <width>x<height> as name for the mode

I didn't like that option since it can lead to blowing up the number of resolutions - so either I let it blow and assume / verify X can handle 1M resolutions |[500,1500)x[500,1500)| or we have to add code to trim the last ones. Ok, actually simply deleting the previous one should do.

> 2) This won't cause conflicts if the same mode is used on multiple
> monitors, since
> find_mode_by_size will find it, avoiding it getting added twice

Right.

> 3) When changing to a new mode, don't delete the current mode before
> creating the new
> one, but delete it after changing the mode to the new mode. Note this
> requires tracking
> of modes added by the agent, so as to not delete standard modes, as
> well as refcounting
> of the tracked modes, as one mode can be used by multiple monitors

Yes, clearly you have given this option more thought then I have :)

> 4) Even delete the custom previously in use mode, when the new mode
> is a standard mode,
> something which we currently don't do.
> 
> >> 2) Some weird vdagent-# modes show up in xrandr output (may be
> >> related to 1):
> >> qxl-0 connected 1712x962+0+0 0mm x 0mm
> 
> >>     1712x962       60.0*+
> >>     2560x1600      60.0
> >>     <snip>
> >>     vdagent-0       0.1
> >
> > The wierd thing is that there are two modes, one named 1712x962 and
> > another named vdagent-0. I don't remember writing code to create
> > the
> > first.
> 
> 
> Yeah, that is weird, and I cannot find anything in the code
> explaining the vadagent-0
> mode showing up twice. Anyways conclusions:
> 
> 1) What we have now works, but could do with some improvements
> 2) Since that what we have now works, I'll go and do a new upstream
> spice-vdagent release
> soon (likely tomorrow) and use that for F-18, etc. for now.
> 
> Then later when things are a bit more quiet wrt other things needing
> our attention.
> we can try to improve things.

I like this plan. +1.

> 
> Regards,
> 
> Hans
> 
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]