lkml.org 
[lkml]   [2018]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 1/4] drm: Add writeback connector type
On Fri, Feb 23, 2018 at 04:48:58PM +0000, Liviu Dudau wrote:
> On Fri, Feb 23, 2018 at 11:43:29AM -0500, Sean Paul wrote:
> > On Fri, Feb 23, 2018 at 11:25:11AM -0500, Rob Clark wrote:
> > > On Fri, Feb 23, 2018 at 10:59 AM, Sean Paul <seanpaul@chromium.org> wrote:
> > > >
> > > > Have we considered hiding writeback behind a client cap instead?
> > >
> > > It is kinda *almost* unneeded, since the connector reports itself as
> > > disconnected.
> > >
> > > I'm not sure what the reason was to drop the cap, but I think it would
> > > be better to have a cap so WB connectors don't show up in, for ex,
> > > xrandr
> >
> > Yeah, the disconnected hack is kind of gross, IMO. I hate to introduce churn in
> > the patch series given that it was initially introduced with the client cap.
>
> Haha, that's the reverse of Daniel's position:
>
> https://lists.freedesktop.org/archives/dri-devel/2016-October/120519.html

Yeah, it happens :(. I don't think it's a dealbreaker either way, it just seems
awkward to expose a connector which is "disconnected", but available for use. I
don't think we have any other connectors which are supposed to be used in this
state.

>
> >
> > There are also cases where we might want to make writeback unavailable, such as
> > when content protection is enabled. In those cases, it's conceivable that we
> > might want to use disconnected as a signal to u/s. I suppose we could also just
> > fail the check, so most of this is just academic.
>
> Not sure what other hardware out there does, but on Mali DP's case you
> would be outputing the protected content by putting the display
> processor in secure mode, which automatically disables writeback for us.
> Or to put in another way, you don't need a writeback framebuffer if you
> are in non-secure mode as you can get access to the framebuffer used for
> the plane anyway.

Yeah, I was mostly thinking about the case where you might have HDCP enabled on
the HDMI connector and be able to slurp up the content via a writeback. However
if the buffer is not secure in the first place, then it's already accessible in
userspace so I don't think that writeback presents a new security hole.

/me needs to get HDCP out of his head.

Sean


>
> Best regards,
> Liviu
>
> >
> > Sean
> >
> >
> > >
> > > BR,
> > > -R
> >
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
>
> --
> ====================
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---------------
> ¯\_(ツ)_/¯

--
Sean Paul, Software Engineer, Google / Chromium OS

\
 
 \ /
  Last update: 2018-02-23 18:04    [W:0.053 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site