mbox series

[v2,0/9] drm: Add privacy-screen class and connector properties

Message ID 20210421204804.589962-1-hdegoede@redhat.com (mailing list archive)
Headers show
Series drm: Add privacy-screen class and connector properties | expand

Message

Hans de Goede April 21, 2021, 8:47 p.m. UTC
Hi All,

Here is v2 of my series to add a privacy-screen class and connector
properties. The only significantly changed patch in this v2 is:
[2/9] drm: Add privacy-screen class (v2)
which was modified to fix the dependency issues which the lkp kernel test
robot, see the patches changelog for details.

Here is the v1 cover-letter which is still up2date:

Here is the privacy-screen related code which I last posted in August
of last year. To the best of my knowledge there is consensus about /
everyone is in agreement with the new userspace API (2 connector properties)
this patch-set add (patch 1 of the series).

The blocker the last time was that there were no userspace users of
the new properties and as a rule we don't add new drm userspace API
without users.

There now is GNOME userspace code using the new properties:
https://hackmd.io/@3v1n0/rkyIy3BOw

The new API works as designed for this userspace user and the branches
mentioned at the above link add the following features to GNOME:

1. Showing an OSD notification when the privacy-screen is toggled on/off
   through hotkeys handled by the embedded-controller
2. Allowing control of the privacy-screen from the GNOME control-panel,
   including the on/off slider shown there updating to match the hw-setting
   when the setting is changed with the control-panel open.
3. Restoring the last user-setting at login

This series consists of a number of different parts:

1. A new version of Rajat's privacy-screen connector properties patch,
this adds new userspace API in the form of new properties

2. Since on most devices the privacy screen is actually controlled by
some vendor specific ACPI/WMI interface which has a driver under
drivers/platform/x86, we need some "glue" code to make this functionality
available to KMS drivers. Patches 2-4 add a new privacy-screen class for
this, which allows non KMS drivers (and possibly KMS drivers too) to
register a privacy-screen device and also adds an interface for KMS drivers
to get access to the privacy-screen associated with a specific connector.
This is modelled similar to how we deal with e.g. PWMs and GPIOs in the
kernel, including separate includes for consumers and providers(drivers).

3. Some drm_connector helper functions to keep the actual changes needed
for this in individual KMS drivers as small as possible (patch 5).

4. Make the thinkpad_acpi code register a privacy-screen device on
ThinkPads with a privacy-screen (patches 6-8)

5. Make the i915 driver export the privacy-screen functionality through
the connector properties on the eDP connector.

I believe that it would be best to merge the entire series, including
the thinkpad_acpi changes through drm-misc in one go. As the pdx86
subsys maintainer I hereby give my ack for merging the thinkpad_acpi
changes through drm-misc.

There is one small caveat with this series, which it is good to be
aware of. The i915 driver will now return -EPROBE_DEFER on Thinkpads
with an eprivacy screen, until the thinkpad_acpi driver is loaded.
This means that initrd generation tools will need to be updated to
include thinkpad_acpi when the i915 driver is added to the initrd.
Without this the loading of the i915 driver will be delayed to after
the switch to real rootfs.

Regards,

Hans



Hans de Goede (8):
  drm: Add privacy-screen class (v2)
  drm/privacy-screen: Add X86 specific arch init code
  drm/privacy-screen: Add notifier support
  drm/connector: Add a drm_connector privacy-screen helper functions
  platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey()
    helper
  platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI
    handles only once
  platform/x86: thinkpad_acpi: Register a privacy-screen device
  drm/i915: Add privacy-screen support

Rajat Jain (1):
  drm/connector: Add support for privacy-screen properties (v4)

 Documentation/gpu/drm-kms-helpers.rst        |  15 +
 Documentation/gpu/drm-kms.rst                |   2 +
 MAINTAINERS                                  |   8 +
 drivers/gpu/drm/Kconfig                      |   4 +
 drivers/gpu/drm/Makefile                     |   1 +
 drivers/gpu/drm/drm_atomic_uapi.c            |   4 +
 drivers/gpu/drm/drm_connector.c              | 214 +++++++++
 drivers/gpu/drm/drm_drv.c                    |   4 +
 drivers/gpu/drm/drm_privacy_screen.c         | 468 +++++++++++++++++++
 drivers/gpu/drm/drm_privacy_screen_x86.c     |  86 ++++
 drivers/gpu/drm/i915/display/intel_display.c |   5 +
 drivers/gpu/drm/i915/display/intel_dp.c      |  10 +
 drivers/gpu/drm/i915/i915_pci.c              |  12 +
 drivers/platform/x86/Kconfig                 |   2 +
 drivers/platform/x86/thinkpad_acpi.c         | 131 ++++--
 include/drm/drm_connector.h                  |  56 +++
 include/drm/drm_privacy_screen_consumer.h    |  63 +++
 include/drm/drm_privacy_screen_driver.h      |  84 ++++
 include/drm/drm_privacy_screen_machine.h     |  46 ++
 19 files changed, 1173 insertions(+), 42 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_privacy_screen.c
 create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c
 create mode 100644 include/drm/drm_privacy_screen_consumer.h
 create mode 100644 include/drm/drm_privacy_screen_driver.h
 create mode 100644 include/drm/drm_privacy_screen_machine.h

Comments

Simon Ser April 22, 2021, 8:51 a.m. UTC | #1
Hi,

On Wednesday, April 21st, 2021 at 10:47 PM, Hans de Goede <hdegoede@redhat.com> wrote:

> There now is GNOME userspace code using the new properties:
> https://hackmd.io/@3v1n0/rkyIy3BOw

Thanks for working on this.

Can these patches be submitted as merge requests against the upstream
projects? It would be nice to get some feedback from the maintainers,
and be able to easily leave some comments there as well.

Thanks,

Simon
Hans de Goede April 22, 2021, 8:54 a.m. UTC | #2
Hi,

On 4/22/21 10:51 AM, Simon Ser wrote:
> Hi,
> 
> On Wednesday, April 21st, 2021 at 10:47 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> 
>> There now is GNOME userspace code using the new properties:
>> https://hackmd.io/@3v1n0/rkyIy3BOw
> 
> Thanks for working on this.
> 
> Can these patches be submitted as merge requests against the upstream
> projects? It would be nice to get some feedback from the maintainers,
> and be able to easily leave some comments there as well.

I guess Marco was waiting for the kernel bits too land before submitting these,
but I agree that it would probably be good to have these submitted now, we
can mark them as WIP to avoid them getting merged before the kernel side
is finalized.

Marco, can you take care of submitting WIP merge-reqs for these?

Regards,

Hans
Simon Ser April 22, 2021, 8:58 a.m. UTC | #3
On Thursday, April 22nd, 2021 at 10:54 AM, Hans de Goede <hdegoede@redhat.com> wrote:

> I guess Marco was waiting for the kernel bits too land before submitting these,
> but I agree that it would probably be good to have these submitted now, we
> can mark them as WIP to avoid them getting merged before the kernel side
> is finalized.

Yes, this is how it should be done, see [1]. In particular:

> The userspace side must be fully reviewed and tested to the standards
> of that userspace project.

And yeah, the user-space side still can't be merged before the kernel
side:

> The kernel patch can only be merged after all the above requirements
> are met, but it must be merged to either drm-next or drm-misc-next
> before the userspace patches land.

[1]: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
Marco Trevisan April 27, 2021, 5:03 p.m. UTC | #4
Hi,

>>> There now is GNOME userspace code using the new properties:
>>> https://hackmd.io/@3v1n0/rkyIy3BOw
>> 
>> Thanks for working on this.
>> 
>> Can these patches be submitted as merge requests against the upstream
>> projects? It would be nice to get some feedback from the maintainers,
>> and be able to easily leave some comments there as well.

FYI, I've discussed with other uptream developers about these while
doing them, and afterwards on how to improve them.

> I guess Marco was waiting for the kernel bits too land before
> submitting these,
> but I agree that it would probably be good to have these submitted
> now, we
> can mark them as WIP to avoid them getting merged before the kernel side
> is finalized.

I'll submit them in the next days once I'm done with the refactor I've
in mind, and will notify the list.

And for sure we can keep them in WIP till the final bits aren't completed.

Cheers
Rajat Jain July 13, 2021, 7:25 p.m. UTC | #5
Hello Hans, Marco, et al,

On Tue, Apr 27, 2021 at 10:03 AM Marco Trevisan
<marco.trevisan@canonical.com> wrote:
>
> Hi,
>
> >>> There now is GNOME userspace code using the new properties:
> >>> https://hackmd.io/@3v1n0/rkyIy3BOw
> >>
> >> Thanks for working on this.
> >>
> >> Can these patches be submitted as merge requests against the upstream
> >> projects? It would be nice to get some feedback from the maintainers,
> >> and be able to easily leave some comments there as well.
>
> FYI, I've discussed with other uptream developers about these while
> doing them, and afterwards on how to improve them.
>
> > I guess Marco was waiting for the kernel bits too land before
> > submitting these,
> > but I agree that it would probably be good to have these submitted
> > now, we
> > can mark them as WIP to avoid them getting merged before the kernel side
> > is finalized.
>
> I'll submit them in the next days once I'm done with the refactor I've
> in mind, and will notify the list.

Any updates on the privacy-screen patchset? Can Hans' patchset be
accepted upstream now?

Thanks,

Rajat

>
> And for sure we can keep them in WIP till the final bits aren't completed.
>
> Cheers