FRC, the ultimate tearfree video solution

[vesa]

I think the way to deal with it without compromising other windowed applications is to do a temporal re-sampling. We do spatial re-sampling all the time, why not do temporal as well? GPU should be able to handle it with ease. This we we re-sample the movie to screen refresh rate and show each new frame in each refresh.

Care to explain which applications would be compromised by frame rate change? If the change is done properly one can not even notice it. Working FRC does just some very minor changes. 48 to 60 Hz jump is a bit difficult, but definitely not impossible if taken care. Temporal resampling is a very good idea, but even broadcast engineers aren't too satisfied with the results and they pay big money for the hardware. The same applies to vertical scaling of interlaced video. Processing errors like rounding in 8 bit video is horrible...

Also, when properly implemented, it's just one configuration option in ones media player. Add some intelligence and FRC is enabled only when content frame or field rate is above half the refresh rate. Like everything in FLOSS, FRC is an _option_, not 'one size fits all' system. Usually those options do their designed work next to perfect (given time to iron out bugs).

CrystalCowboy, you don't have to use 7.5 Hz refresh Just pick 8*7.5=60 (Hz) and run that synchronously... I doubt it is worth it though as eight times 'oversampling' will result in very small jitter and no strong subharmonics.

The following points to a diagram about frame rate resampling:
http://users.tkk.fi/~vsolonen/bonk/FRC.svg

If one really _really_ wants to understand and picture it all, Octave or Matlab model of square wave sampling will be needed. FFT analysis will show temporal spectrum components nicely. You more mathematically inclined will probably figure everything on paper and in brain too, but I'm not one of those

Any driver or hardware developers lurking here anymore? What do you think about the patches and what has to be done to get them included in the official driver tree? Any chances AMD would do fractional-N type clock synthesizer in GPU firmware? That would be something

[agd5f]

Any driver or hardware developers lurking here anymore? What do you think about the patches and what has to be done to get them included in the official driver tree?

The patches need to be synced up against git master and cleaned up before they could be merged upstream. They are currently pretty hacky.

Some suggestions:
- The code need to be made multi-head aware. The current patch assumes crtc 0.
- The current code only support pre-avivo chips (r1xx-r4xx). The code either needs to check and bail properly on newer chips, or support needs to be added for newer asics
- Drm version bump and checks for new ioctl
- Handle different monitor types properly. Digital monitors tend to be very picky about the mode timing. As such you'd need to be careful about adjusting the timing.

Another thing to consider is that modesetting is moving to the kernel in newer drms, so you may want to consider implementing this in the drm rather than in the ddx.

[vesa]

The patches need to be synced up against git master and cleaned up before they could be merged upstream. They are currently pretty hacky.

Ok. Currently this seems again like a manpower issue and the fact that they work well with Easyvdr distribution. I'm not the author and don't regrettably have the needed skills (yet), so my purpose was just making FRC a bit more known one man project. We'll see what future brings