Atomic driver and old remove FB behavior

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

 



Hi, all!

I am working on a para-virtualized frontend DRM driver for Xen [1]
which implements display device I/O interface for Xen guest OSes [2].

At the moment I am rebasing the existing implementation from 4.9 kernel
to recent and found that when user-space DRM application exits then CRTC's
.set_config callback is not called to reset CRTC's mode to NULL.

I tracked the change down to commit 846c7dfc1193eb2f9866fe2fa0ae7d45c72f95b9
"drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

    This introduces a slight behavioral change to rmfb. Instead of
    disabling a crtc when the primary plane is disabled, we try to
    preserve it.
<snip>
    If the atomic commit is rejected by the driver then we will still
    fall back to the old behavior and turn off the crtc.
"
which per my understanding is ok for real hardware, but in my case I still
need .set_config to be called with NULL: this way I can tell the backend

driver that it can release resources for this connection on its end.


I tried to implement drm_mode_config_funcs's .atomic_commit returning -EINVAL
on tear down, but at best it made CRTC's atomic state change to NOCRTC, but
still no .set_config callback seen.

Can anyone please tell me the right sequence to implement old remove FB
behavior for atomic drivers? Or what could be the problem on my side?

Thank you,
Oleksandr

[1] https://xenproject.org
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/xen/interface/io/displif.h

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://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