[PATCH:xbacklight] Use current output configuration

Do not trigger re-enumerating output devices when changing or querying the backlight. Re-enumerating output devices may stall Xorg at least on Intel GPUs when EDID is unresponsive or contains bogus data (due to retries). When working with the backlight it is safe to assume that a monitor capable

[PATCH v2] present: Fix Async swap logic

According to the spec, PresentOptionAsync should only trigger a different behaviour when the target msc has been reached. In this case if the driver is able to do async swaps, we use them to avoid a screen copy. When the target msc hasn't been reached yet, we want to use sync swaps. v2: Fix

Re: [PATCH] present: Fix Async swap logic

On 05.11.2015 01:51, davya...@free.fr wrote: > On 04/11/2015 11:01, Chris Wilson wrote: >> On Wed, Nov 04, 2015 at 10:48:40AM +0100, Axel Davy wrote: >>> >>> . Why you check for Async flips first (isn't sync flips better when >>> possible) ? >> >> The choice is between using native async flips or

Re: [PATCH] present: Fix Async swap logic

On 05.11.2015 12:05, Michel Dänzer wrote: > On 05.11.2015 01:51, davya...@free.fr wrote: >> On 04/11/2015 11:01, Chris Wilson wrote: >>> On Wed, Nov 04, 2015 at 10:48:40AM +0100, Axel Davy wrote: . Why you check for Async flips first (isn't sync flips better when possible) ? >>> >>>

Re: [PATCH v2] present: Fix Async swap logic

On 05.11.2015 02:42, Axel Davy wrote: > According to the spec, PresentOptionAsync should only > trigger a different behaviour when the target msc has been reached. > > In this case if the driver is able to do async swaps, we use > them to avoid a screen copy. > > When the target msc hasn't been

Re: [PATCH] present: Fix Async swap logic

On 04/11/2015 11:01, Chris Wilson wrote: > On Wed, Nov 04, 2015 at 10:48:40AM +0100, Axel Davy wrote: >> >> >> Could you explain: >> . Why you increase target_msc when the Async option is requested ? > > It's the fallthrough path where the client requested an async swap but > we cannot perform one

Re: [PATCH] present: Fix Async swap logic

On 04/11/2015 04:17, Michel Dänzer wrote: On 03.11.2015 17:14, Axel Davy wrote: According to the spec, PresentOptionAsync should only trigger a different behaviour when the target msc has been reached. In this case if the driver is able to do async swaps, we use them to avoid a screen copy.

Re: [PATCH] present: Fix Async swap logic

On 04/11/2015 08:26, Axel Davy wrote: On 04/11/2015 04:17, Michel Dänzer wrote: On 03.11.2015 17:14, Axel Davy wrote: +} else if (target_msc == crtc_msc && +(options & PresentOptionAsync) && +(screen_priv->info->capabilities & PresentCapabilityAsync) && +

Re: [PATCH] present: Fix Async swap logic

On Tue, Nov 03, 2015 at 09:14:51AM +0100, Axel Davy wrote: > According to the spec, PresentOptionAsync should only > trigger a different behaviour when the target msc has been reached. > > In this case if the driver is able to do async swaps, we use > them to avoid a screen copy. > > When the

Re: [PATCH] present: Fix Async swap logic

On Wed, Nov 04, 2015 at 10:48:40AM +0100, Axel Davy wrote: > On 04/11/2015 10:40, Chris Wilson wrote: > >On Tue, Nov 03, 2015 at 09:14:51AM +0100, Axel Davy wrote: > >>+if (pixmap != NULL && > >>+!(options & PresentOptionCopy) && > >>+screen_priv->info) { > >>+if

Re: [PATCH] present: Fix Async swap logic

On 04/11/2015 10:40, Chris Wilson wrote: On Tue, Nov 03, 2015 at 09:14:51AM +0100, Axel Davy wrote: +if (pixmap != NULL && +!(options & PresentOptionCopy) && +screen_priv->info) { +if (target_msc > crtc_msc && +present_check_flip (target_crtc, window,

[PATCH xserver] modesetting: Just inherit output states during PreInit

From: Daniel Martin During PreInit, we just want to inherit the output states from the kernel. If there's a connected output without an encoder assigned, there must be a reason for this. Don't try to activate it, treat it as disconnected for the moment. Because, if we