Re: BUG: drm_crtc_helper_set_config does not work

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 9, 2012 at 5:28 PM, Yufeng Shen <miletus@xxxxxxxxxxxx> wrote:
> On Fri, Mar 9, 2012 at 3:15 AM, Maarten Maathuis <madman2003@xxxxxxxxx> wrote:
>> On Fri, Mar 9, 2012 at 2:50 AM, Yufeng Shen <miletus@xxxxxxxxxxxx> wrote:
>>> So a simple case of  disabling a CRTC and then re-enabling it.
>>>
>>> Disabling:
>>>
>>> CRTC X is originally connected to output Y
>>>
>>> 1. XRRSetCrtcConfig()    is called to disable CRTC  X
>>>
>>> 2. drm_helper_connector_dpms()   then gets called on the connector
>>> connected to CRTC X,
>>>    in the function,
>>>    the  connector->encoder  is set to DPMS OFF,   and the
>>> encoder->crtc  set to DPMS OFF
>>>    but the  encoder->crtc   is still CRTC X
>>>
>>> Re-enabling:
>>>
>>> 3. XRRSetCrtcConfig()    is called to to enable CRTC  X  on output Y
>>>
>>> 4. drm_crtc_helper_set_config ()  is now called,
>>> suppose   fb is not changed,  mode is not changed, encoder is not changed
>>> and the   encoder->crtc  is not changed,
>>> then we have   mode_changed == false    and  the mode is not reset
>>>
>>> So the CRTC X won't be connected to output Y.
>>>
>>> What I don't understand the code is that why  XRRSetCrtcConfig()  ends
>>> up only calling  drm_helper_connector_dpms()  ?
>>> I think it should do more than that, at least it should set the
>>> related  encoder->crtc = NULL
>>>
>>> any comments ?
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@xxxxxxxxxxxxxxxxxxxxx
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>> As far as i know DPMS designed is a simple switch, meaning that the
>> mode remains active, so if you do DPMS ON it should come back. If for
>> some reason the driver is disconnecting the encoder from the crtc,
>> then it is the drivers responsibility to reconnect it when DPMS ON
>> happens.
>>
>> But don't take my word for it, others may have more/other information.
>>
>
> Yes, I was thinking ideally DPMS call should enable/disable DPMS state, and
> XRRSetCrtcConfig call should enable/disable CRTC.
>
> But it seems that, when using XRRSetCrtcConfig to disable CRTC,
> the CRTC itself is disabled, the DPMS is disabled (DPMS OFF),
> and then when using XRRSetCrtcConfig to re-enable the CRTC,
> it only checks whether the CRTC that connected to the encoder is
> changed (whether a new crtc is assigned), but does not check whether
> the CRTC itself is previously disabled or not.  So it considers the encoder
> is connected to the same CRTC and does no thing to re-enable the CRTC.
>
>
>> --
>> Far away from the primal instinct, the song seems to fade away, the
>> river get wider between your thoughts and the things we do and say.

What i meant is that you should get a DPMS ON call somewhere in the
driver. The driver should then re-enable things. If the driver
disconnects the encoder for DPMS OFF, then it will also have to
reconnect it for DPMS ON.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux