| Message ID | 20210421204804.589962-1-hdegoede@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm: Add privacy-screen class and connector properties | expand |
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
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
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
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
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
Hi Rajat, The merge proposals are now in place after discussing a bit more with upstream: - https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/49 - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952 - https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1032 This is all implemented and working for the wayland backend, for X11 I'm looking at it right now, even though it seems that we don't get any RRScreenChangeNotify on hotkey changes, and monitoring udev directly seems overkill. Anything should be adjusted at lower levels? Cheers On lug 13 2021, at 9:25 pm, Rajat Jain <rajatja@google.com> wrote: > 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 >
Hello DRM / GPU maintainers, On Tue, Aug 3, 2021 at 8:20 AM Marco Trevisan <marco.trevisan@canonical.com> wrote: > > Hi Rajat, > > The merge proposals are now in place after discussing a bit more with upstream: > > - https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/49 > - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952 > - https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1032 It seems that the subject kernel patch series (privacy screen support) from Hans, has now satisfied all the requirements that were needed for it to be accepted upstream, and there aren't any open comments that need to be addressed. I was wondering when would it be applied to the upstream kernel? Thanks, Rajat > > This is all implemented and working for the wayland backend, for X11 I'm > looking at it right now, even though it seems that we don't get any > RRScreenChangeNotify on hotkey changes, and monitoring udev directly > seems overkill. Anything should be adjusted at lower levels? > > Cheers > > On lug 13 2021, at 9:25 pm, Rajat Jain <rajatja@google.com> wrote: > > > 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 > >
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