<html><head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> Hello Simon, Hope you are doing well, I was helping out Aurabindo and the team with the design, so I have taken the liberty of adding some comments on behalf of the team, Inline. <div class="moz-cite-prefix">On 11/12/20 3:31 am, Simon Ser wrote: </div> <blockquote type="cite" cite="mid:MC46k2jDYAeDTZaSlv6T5iIq5ibkh2yYwW3KZ-XLXLwoRByjkWsEr6-6eQM4iZqmkiLoleyh84S290ytAub0bK-esJje1OGKIEilcz_iikY=@emersion.fr"> <pre class="moz-quote-pre" wrap="">Hi, (CC dri-devel, Pekka and Martin who might be interested in this as well.) On Thursday, December 10th, 2020 at 7:48 PM, Aurabindo Pillai <a class="moz-txt-link-rfc2396E" href="mailto:aurabindo.pillai@amd.com"><aurabindo.pillai@amd.com></a> wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">This patchset enables freesync video mode usecase where the userspace can request a freesync compatible video mode such that switching to this mode does not trigger blanking. This feature is guarded by a module parameter which is disabled by default. Enabling this paramters adds additional modes to the driver modelist, and also enables the optimization to skip modeset when using one of these modes. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Thanks for working on this, it's an interesting feature! However I'd like to take some time to think about the user-space API for this. As I understand it, some new synthetic modes are added, and user-space can perform a test-only atomic *without* ALLOW_MODESET to figure out whether it can switch to a mode without blanking the screen.</pre> </blockquote> The implementation is in those lines, but a bit different. The idea is to: - check if the monitor supports VRR, - If it does, add some new modes which are in the VRR tolerance range, as new video modes in the list (with driver flag). - when you get modeset on any of these modes, skip the full modeset, and just adjust the front_porch timing so they are not test-only as such, for any user-space these modes will be as real as any other probed modes of the list. <blockquote type="cite" cite="mid:MC46k2jDYAeDTZaSlv6T5iIq5ibkh2yYwW3KZ-XLXLwoRByjkWsEr6-6eQM4iZqmkiLoleyh84S290ytAub0bK-esJje1OGKIEilcz_iikY=@emersion.fr"> <pre class="moz-quote-pre" wrap=""> However the exact modes amdgpu adds are just some guesses. I think it would be great if user-space could control the min/max refresh rate values directly. Not only this would remove the need for the kernel to hard-code "well-known video refresh rates", but this would also enable more use-cases. For instance some users might want to mitigate flickering on their screen by reducing the VRR range. Some users might want to lower their screen refresh rate for power savings. What do you think? Would you be fine with adding min/max VRR range properties? If you're scared about the user-space code requirement, I can provide that.</pre> </blockquote> This sounds like a reasonable approach, and there is no reason why we can't do this if we have the proper userspace support as you mentioned. But what we thought would be a sensitive approach towards this feature would be: - Phase 1: Add this feature experimentally as kernel-only change, to: test out its functionality on all all supported platforms first, without going for the UAPI complexity. gain attention from UAPI stakeholders and get them involved for the UAPI design (so far so good :)). - Phase 2: Have a design discussions with user-space stakeholders, examine the use-cases possible, and then create a reasonable UAPI, and make the other solution a fallback method. So I guess we can fork out a parallel discussion for the UAPI thread too. How does this sound to you ? - Shashank <blockquote type="cite" cite="mid:MC46k2jDYAeDTZaSlv6T5iIq5ibkh2yYwW3KZ-XLXLwoRByjkWsEr6-6eQM4iZqmkiLoleyh84S290ytAub0bK-esJje1OGKIEilcz_iikY=@emersion.fr"> <pre class="moz-quote-pre" wrap=""> Thanks, Simon Ser </pre> </blockquote> </body> </html>