8aa0625f48
Properties are uapi like anything else, with all the usual rules
regarding review, testcases, open source userspace ... Furthermore
driver-private kms properties are highly discouraged, over the past
few years we've realized we need to make a serious effort at better
standardizing this stuff.
Again this probably needs multiple pieces to solve this properly:
- To make plane configuration less surprising to userspace you
propably need to virtualize planes, and reorder which logical plane
you map to which physical one dynamically. Instead of exposing a
komeda-specific limitation to userspace and expecting them to dtrt.
I think msm and rcar-du do that already (and others), if you need
people to chat with or example code.
- If this is needed for validation, again ->atomic_print_state and the
infrastructure around that is your friend.
Fixes:
|
||
|---|---|---|
| .. | ||
| display | ||
| hdlcd_crtc.c | ||
| hdlcd_drv.c | ||
| hdlcd_drv.h | ||
| hdlcd_regs.h | ||
| Kconfig | ||
| Makefile | ||
| malidp_crtc.c | ||
| malidp_drv.c | ||
| malidp_drv.h | ||
| malidp_hw.c | ||
| malidp_hw.h | ||
| malidp_mw.c | ||
| malidp_mw.h | ||
| malidp_planes.c | ||
| malidp_regs.h | ||