On Sat, Oct 26, 2019 at 1:07 PM Daniel Stone <daniel@xxxxxxxxxxxxx> wrote: > > Hi Thierry, > > On Fri, 25 Oct 2019 at 12:36, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > > On Thu, Oct 24, 2019 at 01:45:16PM -0700, Rajat Jain wrote: > > > I did think about having a state variable in software to get and set > > > this. However, I think it is not very far fetched that some platforms > > > may have "hardware kill" switches that allow hardware to switch > > > privacy-screen on and off directly, in addition to the software > > > control that we are implementing. Privacy is a touchy subject in > > > enterprise, and anything that reduces the possibility of having any > > > inconsistency between software state and hardware state is desirable. > > > So in this case, I chose to not have a state in software about this - > > > we just report the hardware state everytime we are asked for it. > > > > So this doesn't really work with atomic KMS, then. The main idea behind > > atomic KMS is that you apply a configuration either completely or not at > > all. So at least for setting this property you'd have to go through the > > state object. > > > > Now, for reading out the property you might be able to get away with the > > above. I'm not sure if that's enough to keep the state up-to-date, > > though. Is there some way for a kill switch to trigger an interrupt or > > other event of some sort so that the state could be kept up-to-date? > > > > Daniel (or anyone else), do you know of any precedent for state that > > might get modified behind the atomic helpers' back? Seems to me like we > > need to find some point where we can actually read back the current > > "hardware value" of this privacy screen property and store that back > > into the state. > > Well, apart from connector state, though that isn't really a property > as such, there's the link_state property, which is explicitly designed > to do just that. That has been quite carefully designed for the > back-and-forth though. connector state is an immutable property, which is a hilarious way to say that "only the driver can update it, userspace only reads it". So not a good template here. But yeah link_state is a good example of what we need here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
