Michel Dänzer writes:
> With variable refresh rate, it could certainly be useful for the kernel
> to have this information as early as possible. It shouldn't make any
> difference with fixed refresh though, since the kernel should always be
> able to hit the next refresh in that case as long as
Hi list,
Sorry for the late -rc2, it's my fault. I was out of the office Monday and
Tuesday and kinda lost track of time :/
Anyway, There's a lot of stuff in here, as is typical for -rc2. We've got a ton
of intel related fixes from Jason, and then a bunch of stuff touching every bit
of the tree.
Seems like you missed zink
On February 5, 2020 9:36:26 PM GMT+01:00, James Jones
wrote:
>Rather than hard-code a list of all the format
>modifiers supported by any gallium driver in
>the dri state tracker, add a screen proc that
>queries the number of auxiliary planes required
>for a given
On 2020-02-04 8:12 p.m., Keith Packard wrote:
> Michel Dänzer writes:
>
>> Hmm, I didn't fully realize this in my reading of the draft, thanks
>> Matias for pointing it out!
>>
>> That the timing of frame N+1 has to be specified when submitting frame
>> N for presentation is odd to me TBH. While
