On Mon, Nov 12, 2012 at 3:25 PM, Rob Clark wrote:
> On Mon, Nov 12, 2012 at 8:17 AM, Daniel Vetter wrote:
>> On Mon, Nov 12, 2012 at 3:11 PM, Rob Clark wrote:
>>> I do prefer that, at least on lastclose, that we revert properties
>>> back to default/initial state, so that userspace unaware of so
On Mon, Nov 12, 2012 at 3:11 PM, Rob Clark wrote:
> I do prefer that, at least on lastclose, that we revert properties
> back to default/initial state, so that userspace unaware of some new
> or driver specific properties doesn't get confused.
>
> But dpms is a bit of an odd-duck property. Probab
On Fri, Nov 09, 2012 at 10:26:52PM +0100, Daniel Vetter wrote:
> On Thu, Nov 08, 2012 at 08:01:57PM +0100, Thierry Reding wrote:
> > On Thu, Nov 08, 2012 at 12:48:18PM -0500, Alex Deucher wrote:
> > > On Wed, Nov 7, 2012 at 5:06 PM, Thierry Reding
> > > wrote:
> > > > When running the xf86-video-m
On Mon, Nov 12, 2012 at 8:29 AM, Daniel Vetter wrote:
> On Mon, Nov 12, 2012 at 3:25 PM, Rob Clark wrote:
>> On Mon, Nov 12, 2012 at 8:17 AM, Daniel Vetter wrote:
>>> On Mon, Nov 12, 2012 at 3:11 PM, Rob Clark wrote:
I do prefer that, at least on lastclose, that we revert properties
b
On Mon, Nov 12, 2012 at 8:17 AM, Daniel Vetter wrote:
> On Mon, Nov 12, 2012 at 3:11 PM, Rob Clark wrote:
>> I do prefer that, at least on lastclose, that we revert properties
>> back to default/initial state, so that userspace unaware of some new
>> or driver specific properties doesn't get conf
On Mon, Nov 12, 2012 at 3:04 AM, Ville Syrj?l?
wrote:
> On Fri, Nov 09, 2012 at 10:26:52PM +0100, Daniel Vetter wrote:
>> On Thu, Nov 08, 2012 at 08:01:57PM +0100, Thierry Reding wrote:
>> > On Thu, Nov 08, 2012 at 12:48:18PM -0500, Alex Deucher wrote:
>> > > On Wed, Nov 7, 2012 at 5:06 PM, Thierr
On Mon, Nov 12, 2012 at 8:29 AM, Daniel Vetter wrote:
> On Mon, Nov 12, 2012 at 3:25 PM, Rob Clark wrote:
>> On Mon, Nov 12, 2012 at 8:17 AM, Daniel Vetter wrote:
>>> On Mon, Nov 12, 2012 at 3:11 PM, Rob Clark wrote:
I do prefer that, at least on lastclose, that we revert properties
b
On Mon, Nov 12, 2012 at 3:25 PM, Rob Clark wrote:
> On Mon, Nov 12, 2012 at 8:17 AM, Daniel Vetter wrote:
>> On Mon, Nov 12, 2012 at 3:11 PM, Rob Clark wrote:
>>> I do prefer that, at least on lastclose, that we revert properties
>>> back to default/initial state, so that userspace unaware of so
On Mon, Nov 12, 2012 at 8:17 AM, Daniel Vetter wrote:
> On Mon, Nov 12, 2012 at 3:11 PM, Rob Clark wrote:
>> I do prefer that, at least on lastclose, that we revert properties
>> back to default/initial state, so that userspace unaware of some new
>> or driver specific properties doesn't get conf
On Mon, Nov 12, 2012 at 3:11 PM, Rob Clark wrote:
> I do prefer that, at least on lastclose, that we revert properties
> back to default/initial state, so that userspace unaware of some new
> or driver specific properties doesn't get confused.
>
> But dpms is a bit of an odd-duck property. Probab
On Mon, Nov 12, 2012 at 3:04 AM, Ville Syrjälä
wrote:
> On Fri, Nov 09, 2012 at 10:26:52PM +0100, Daniel Vetter wrote:
>> On Thu, Nov 08, 2012 at 08:01:57PM +0100, Thierry Reding wrote:
>> > On Thu, Nov 08, 2012 at 12:48:18PM -0500, Alex Deucher wrote:
>> > > On Wed, Nov 7, 2012 at 5:06 PM, Thierr
On Fri, Nov 09, 2012 at 10:26:52PM +0100, Daniel Vetter wrote:
> On Thu, Nov 08, 2012 at 08:01:57PM +0100, Thierry Reding wrote:
> > On Thu, Nov 08, 2012 at 12:48:18PM -0500, Alex Deucher wrote:
> > > On Wed, Nov 7, 2012 at 5:06 PM, Thierry Reding
> > > wrote:
> > > > When running the xf86-video-m
On Thu, Nov 08, 2012 at 08:01:57PM +0100, Thierry Reding wrote:
> On Thu, Nov 08, 2012 at 12:48:18PM -0500, Alex Deucher wrote:
> > On Wed, Nov 7, 2012 at 5:06 PM, Thierry Reding
> > wrote:
> > > When running the xf86-video-modesetting driver on top of a KMS driver,
> > > leaving X causes the acti
On Thu, Nov 08, 2012 at 08:01:57PM +0100, Thierry Reding wrote:
> On Thu, Nov 08, 2012 at 12:48:18PM -0500, Alex Deucher wrote:
> > On Wed, Nov 7, 2012 at 5:06 PM, Thierry Reding
> > wrote:
> > > When running the xf86-video-modesetting driver on top of a KMS driver,
> > > leaving X causes the acti
On Thu, Nov 08, 2012 at 12:48:18PM -0500, Alex Deucher wrote:
> On Wed, Nov 7, 2012 at 5:06 PM, Thierry Reding
> wrote:
> > When running the xf86-video-modesetting driver on top of a KMS driver,
> > leaving X causes the active encoder's DPMS mode to be set to off by the
> > drm_crtc_helper_disable
On Wed, Nov 7, 2012 at 5:06 PM, Thierry Reding
wrote:
> When running the xf86-video-modesetting driver on top of a KMS driver,
> leaving X causes the active encoder's DPMS mode to be set to off by the
> drm_crtc_helper_disable() function. This doesn't set the connector's
> DPMS mode to off, howeve
On Thu, Nov 08, 2012 at 12:48:18PM -0500, Alex Deucher wrote:
> On Wed, Nov 7, 2012 at 5:06 PM, Thierry Reding
> wrote:
> > When running the xf86-video-modesetting driver on top of a KMS driver,
> > leaving X causes the active encoder's DPMS mode to be set to off by the
> > drm_crtc_helper_disable
On Wed, Nov 7, 2012 at 5:06 PM, Thierry Reding
wrote:
> When running the xf86-video-modesetting driver on top of a KMS driver,
> leaving X causes the active encoder's DPMS mode to be set to off by the
> drm_crtc_helper_disable() function. This doesn't set the connector's
> DPMS mode to off, howeve
When running the xf86-video-modesetting driver on top of a KMS driver,
leaving X causes the active encoder's DPMS mode to be set to off by the
drm_crtc_helper_disable() function. This doesn't set the connector's
DPMS mode to off, however, which results in subsequent calls to the
drm_helper_connecto
When running the xf86-video-modesetting driver on top of a KMS driver,
leaving X causes the active encoder's DPMS mode to be set to off by the
drm_crtc_helper_disable() function. This doesn't set the connector's
DPMS mode to off, however, which results in subsequent calls to the
drm_helper_connecto
20 matches
Mail list logo
