On Tue, Nov 29, 2016 at 03:06:17PM +0530, Nautiyal, Ankit K wrote:
> As per discussion with Chris, on IRC following were the suggestions :
>
> - Chris has suggested an event based approach to avoid using pthreads.
>
> - Avoid using kernel-specific info like transitional delays and instead use
> e
As per discussion with Chris, on IRC following were the suggestions :
- Chris has suggested an event based approach to avoid using pthreads.
- Avoid using kernel-specific info like transitional delays and instead
use either polling or wait-for-event approach. Need to focus on
user-observable b
On Mon, Nov 14, 2016 at 01:06:09PM +, Chris Wilson wrote:
> On Mon, Nov 14, 2016 at 02:44:35PM +0200, Petri Latvala wrote:
> > Chris, happy with this revision?
>
> Me? No. It still uses a thread instead of events, so I don't think it
> qualifies as a good example for anyone else wanting to do
On Mon, Nov 14, 2016 at 02:44:35PM +0200, Petri Latvala wrote:
> Chris, happy with this revision?
Me? No. It still uses a thread instead of events, so I don't think it
qualifies as a good example for anyone else wanting to do the same thing.
Lots of hardcoded expectations (specific sleep patterns,
Chris, happy with this revision?
On Fri, Oct 21, 2016 at 09:22:13AM +0530, Nautiyal Ankit wrote:
> From: Ramalingam C
>
> Idleness DRRS:
> By default the DRRS state will be at DRRS_HIGH_RR. When a Display
> content is Idle for more than 1Sec Idleness will be declared and
> DRR
From: Ramalingam C
Idleness DRRS:
By default the DRRS state will be at DRRS_HIGH_RR. When a Display
content is Idle for more than 1Sec Idleness will be declared and
DRRS_LOW_RR will be invoked, changing the refresh rate to the
lower most refresh rate supported by t
