On Fri, 8 Apr 2022 at 23:30, Kuogee Hsieh <quic_khsieh@xxxxxxxxxxx> wrote:
It's of no concern to the driver. It is completely the userspace
On 4/8/2022 5:27 AM, Dmitry Baryshkov wrote:
On 07/04/2022 00:28, Kuogee Hsieh wrote:yes, driver is function correctly by setting up main link. but it does
dp_hpd_plug_handle() is responsible for setting up main link and sendHmm, how does userpsace 'respond' to the uevent? The driver should
uevent to notify user space framework to start video stream. Similarly,
dp_hdp_unplug_handle is responsible to send uevent to notify user space
framework to stop video stream and then tear down main link.
However there are rare cases, such as in the middle of system
suspending,
that uevent could not be delivered to user space framework. Therefore
some kind of recover mechanism armed by timer need to be in place in the
case of user space framework does not respond to uevent.
send hotplug notifications to userspace, but it must not expect any
particular reaction. The userspace might be as simple, as fbdev
emulation, but the driver still should function correctly.
not know which resolution to display.
It send hotplug notification through uevent to framework after main link
is ready.
Framework is responsible to set up MDP timing engine to start video stream.
However it does not know which
problem. After resuming, it should reread available video output
properties. The display could have been changed while the system is
suspended.
From your description I still do not understand why you need the
'recovery' mechanism.