[mythtv-users] nVidia driver 304.88: problems

[Paul Gardiner]

On 16/04/2013 12:35, Jean-Yves Avenard wrote:
>
>
>
> On 16 April 2013 17:52, Paul Gardiner <lists at glidos.net
> <mailto:lists at glidos.net>> wrote:
>
>
>     I meant, rather than a change in the code, that the driver was causing
>     GetVideoModes to return fresh objects (perhaps because GetVideoModes
>     used a cache and the driver was returning constantly altering info
>     that caused cache misses - something like that). In any case, I'm
>     mistaken, but the fact remains that it does fix the problem, whatever
>     the cause might be.
>
>
> Nah.. did you actually have a look at the code?
> Changing:
> -    bool chg = !(next == m_last) ||
> +    bool chg = !(next.Width() == m_last.Width()) ||
> +               !(next.Height() == m_last.Height()) ||
>
> is totally useless
>
> next and m_last are instances of DisplayResScreen. It overrides the ==
> operator with:
> inline bool DisplayResScreen::operator == (const DisplayResScreen &b) const
> {
>      return width == b.width && height == b.height;
> }

I only looked at the patch (which didn't include any changes to
DisplayResScreen), assumed the Width/Height parts must be doing something
useful and thought "Hmmm, why aren't they defining operator ==" :-)

> The patch overall is very non-elegant, it brakes totally the MV
> approach, changing the list of modes and overriding it.
>
> The only thing that is actually doing something is that bit:
> +    next.ClearRefreshRates();
> +    next.AddRefreshRate(target_rate);
>
> it pretty much discard everything done above and force only one refresh
> rate to be used...
>
> That's just not the way to do it.

I don't think Gregorio thought it was the correct solution, just a stop
gap until it can be fixed properly. He told me he wished to look at it
more to find out why it had fixed the problem, but he didn't have time.

> Now if I could reproduce the issue you are seeing, I will definitely
> have a shot at it... but the particular patch you're using is certainly
> not the way to do it.

I'm now on 313.30, so maybe I wont have the problem now (yet to
experiment), but what I was
seeing (as were others): if you activate "Separate video modes for GUI 
and TV playback", but don't set up any "Overrides for specific video
sizes" then the mode is set on every transition between GUI and
playback. The patch seemed to fix it, and not by forcing a single
refresh rate, because I'd still see a mode change if transitioning
from playback => gui =>playback if the two playbacks were for different
rates.

One quick question: when some part of MythTV wants current video mode
information, does it enquire of the system, or does it use cached
information from when it last set the mode itself? I sometimes see
signs that it does the former, and would be better doing the latter.
I wonder whether perhaps requests for mode changes don't have effect
immediately, and queries too soon after a change request come back
with the old mode rather than the new mode.

Cheers,
	Paul.