All of lore.kernel.org
 help / color / mirror / Atom feed
From: Deepak Singh Rawat <drawat@vmware.com>
To: Pekka Paalanen <ppaalanen@gmail.com>
Cc: "lukasz.spintzyk@displaylink.com"
	<lukasz.spintzyk@displaylink.com>,
	Thomas Hellstrom <thellstrom@vmware.com>,
	linux-graphics-maintainer <linux-graphics-maintainer@vmware.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: RE: [PATCH 01/14] drm: add new plane property FB_DAMAGE_CLIPS to send damage during plane update
Date: Tue, 11 Sep 2018 04:33:25 +0000	[thread overview]
Message-ID: <BYAPR05MB41817C807D93F294E09DFAF5BA040@BYAPR05MB4181.namprd05.prod.outlook.com> (raw)
In-Reply-To: <20180907122642.38588540@eldfell>


> 
> On Thu, 6 Sep 2018 21:36:51 +0000
> Deepak Singh Rawat <drawat@vmware.com> wrote:
> 
> > >
> > > - Why no input validation on the damage clips against the framebuffer
> > >   size? Ime not validating just leads to funny driver bugs down the road,
> > >   so what's the use-case you have in mind here?
> >
> > My motivation behind not informing user-space if damage is outside plane
> > src, sent during modeset(where it should be provided) or damage is outside
> > framebuffer coordinate (simply put damage clips are invalid) is that it's a
> > hint. The contract between kernel and user-space is simple, if damage
> > clips are valid, kernel might use them (but not always) otherwise they
> > will be ignored. Damage can be ignored deep in the stack (like network),
> > so all the input validation for nothing.
> >
> > Also, what all to consider in input validation ?
> > * clips are outside plane src
> > * damage clips sent during modeset should error ?
> > * any other properties.
> >
> > This will lead to a complex input validation during modeset check like
> > if some drivers are OK with damage while scaling whereas others
> > cannot support, should this error?
> >
> > However I am alright doing input validation if this becomes clear what
> > kind of validation to actually do. My understanding of drm core is limited.
> 
> Hi,
> 
> I think validating that the area of any clip rectangle does not extend
> beyond the framebuffer size would be good. A userspace violating that
> is arguably broken, so it would help catch userspace bugs.
> 
> I also would not assume that damage is irrelevant on modeset. Userspace
> does not always know if an update will be a modeset or not: drivers vary
> there, and userspace that just wants the update through will allow
> modesets always while still providing damage. Userspace could also
> change video mode timings or pixel format while keeping the resolution
> the same, and in that case damage could be meaningful to a driver.
> 
Thanks Pekka, for explanation. I agree clips outside framebuffer should
be errored and also it's not a lot for drm core. Also, will look into the
cases where drm core should clear the damage clips, like resolution
change, etc.

May be the better approach would be drm core just provide the helper
and driver takes care of driver specific scenarios.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2018-09-11  4:33 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-05 23:38 [PATCH 00/14] plane update with damage Deepak Rawat
2018-09-05 23:38 ` [PATCH 01/14] drm: add new plane property FB_DAMAGE_CLIPS to send damage during plane update Deepak Rawat
2018-09-06  7:42   ` Daniel Vetter
2018-09-06 21:36     ` Deepak Singh Rawat
2018-09-07  9:27       ` Pekka Paalanen
2018-09-11  4:33         ` Deepak Singh Rawat [this message]
2018-09-06  8:00   ` Daniel Vetter
2018-09-06 11:59   ` Ville Syrjälä
2018-09-06 22:32     ` Deepak Singh Rawat
2018-09-07 14:23       ` Ville Syrjälä
2018-09-11  4:43         ` Deepak Singh Rawat
2018-09-05 23:38 ` [PATCH 02/14] drm: add helper iterator functions for plane fb_damage_clips blob Deepak Rawat
2018-09-06  7:51   ` Daniel Vetter
2018-09-06 21:44     ` Deepak Singh Rawat
2018-09-07 19:41       ` Daniel Vetter
2018-09-05 23:38 ` [PATCH 03/14] drm: clear plane damage during full modeset Deepak Rawat
2018-09-06  7:56   ` Daniel Vetter
2018-09-06 21:47     ` Deepak Singh Rawat
2018-09-06 12:02   ` Ville Syrjälä
2018-09-06 14:12     ` Daniel Vetter
2018-09-06 14:29       ` Ville Syrjälä
2018-09-05 23:38 ` [PATCH 04/14] drm: add helper to implement legacy dirtyfb Deepak Rawat
2018-09-06  8:21   ` Daniel Vetter
2018-09-05 23:38 ` [PATCH 05/14] drm/vmwgfx: add a new interface for plane update on a display unit Deepak Rawat
2018-09-10  8:09   ` Thomas Hellstrom
2018-09-10  8:21     ` Jani Nikula
2018-09-05 23:38 ` [PATCH 06/14] drm/vmwgfx: implement STDU plane update for surface backed fb Deepak Rawat
2018-09-05 23:38 ` [PATCH 07/14] drm/vmwgfx: implement STDU plane update for BO " Deepak Rawat
2018-09-05 23:38 ` [PATCH 08/14] drm/vmwgfx: use the new interface for STDU plane update Deepak Rawat
2018-09-10  8:18   ` Thomas Hellstrom
2018-09-05 23:38 ` [PATCH 09/14] drm/vmwgfx: enable FB_DAMAGE_CLIPS property for STDU primary plane Deepak Rawat
2018-09-10  8:20   ` Thomas Hellstrom
2018-09-05 23:38 ` [PATCH 10/14] drm/vmwgfx: implement SOU plane update for surface backed fb Deepak Rawat
2018-09-05 23:38 ` [PATCH 11/14] drm/vmwgfx: implement SOU plane update for BO " Deepak Rawat
2018-09-05 23:38 ` [PATCH 12/14] drm/vmwgfx: use the new interface for SOU plane update Deepak Rawat
2018-09-05 23:39 ` [PATCH 13/14] drm/vmwgfx: enable FB_DAMAGE_CLIPS property for SOU primary plane Deepak Rawat
2018-09-05 23:39 ` [PATCH 14/14] drm/vmwgfx: use atomic helper function for dirty fb IOCTL Deepak Rawat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BYAPR05MB41817C807D93F294E09DFAF5BA040@BYAPR05MB4181.namprd05.prod.outlook.com \
    --to=drawat@vmware.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-graphics-maintainer@vmware.com \
    --cc=lukasz.spintzyk@displaylink.com \
    --cc=ppaalanen@gmail.com \
    --cc=thellstrom@vmware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.