On Wed, Oct 23, 2019 at 10:34:05AM +0300, Pekka Paalanen wrote:
On Tue, 22 Oct 2019 20:48:02 +0530 "Sharma, Shashank" shashank.sharma@intel.com wrote:
Hello Ville,
Thanks for the comments, mine inline.
On 10/22/2019 5:50 PM, Ville Syrjälä wrote:
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
This patch adds a scaling filter mode porperty to allow:
- A driver/HW to showcase it's scaling filter capabilities.
- A userspace to pick a desired effect while scaling.
This option will be particularly useful in the scenarios where Integer mode scaling is possible, and a UI client wants to pick filters like Nearest-neighbor applied for non-blurry outputs.
There was a RFC patch series published, to discus the request to enable Integer mode scaling by some of the gaming communities, which can be found here: https://patchwork.freedesktop.org/series/66175/
Signed-off-by: Shashank Sharma shashank.sharma@intel.com
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++++ include/drm/drm_crtc.h | 26 ++++++++++++++++++++++++++ include/drm/drm_mode_config.h | 6 ++++++ 3 files changed, 36 insertions(+)
...
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 5e9b15a0e8c5..94c5509474a8 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -58,6 +58,25 @@ struct device_node; struct dma_fence; struct edid;
+enum drm_scaling_filters {
- DRM_SCALING_FILTER_DEFAULT,
- DRM_SCALING_FILTER_MEDIUM,
- DRM_SCALING_FILTER_BILINEAR,
- DRM_SCALING_FILTER_NN,
Please use real words.
Yes, I saw that coming. It was getting difficult with the 80 char stuff, it was even more difficult while using it :). But let me see how better can I do here.
- DRM_SCALING_FILTER_NN_IS_ONLY,
Not a big fan of this. I'd just add the explicit nearest filter and leave the decision whether to use it to userspace.
Agree, that's also one option. I was thinking to make it convenient for userspace, For example if a compositor just want to checkout NN only when its beneficial (like old gaming scenarios) but doesn't have enough information (or intent), it can leave it to kernel too. But I agree, this can cause corner cases. Let's discuss and see if we need it at all, as you mentioned.
Hi,
how could the kernel have more information or knowledge of intent than a display server? I cannot see how, because everything the kernel gets comes through the display server.
The only exception is due to that annoying scaling mode property. Currently userspace just tells the kernel "center vs. fullscreen vs. aspect" so in theory only the kernel knows the actual output size (though userspace should be able to calculate it as well).
But maybe we can just avoid that little issue by also exposing the "TV" margin properties on local panels, at which point userspace can be more explicit about what it wants.