Thanks, Lukas. I've incorporated your feedback into my local tree, but
will wait for additional feedback from the individual DRM driver
maintainers before sending out a series v2.
On 8/8/20 5:11 PM, Lukas Wunner wrote:
On Mon, Jul 27, 2020 at 03:53:54PM -0500, Daniel Dadap
Fall back to retrieving the EDID via the ACPI _DDC method, when present
for notebook internal panels, when retrieving BIOS-embedded EDIDs.
Signed-off-by: Daniel Dadap
---
drivers/gpu/drm/radeon/radeon_combios.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers
Fall back to retrieving the EDID via the ACPI _DDC method, when present
for notebook internal panels, when EDID retrieval via the standard EDID
paths is unsuccessful.
Signed-off-by: Daniel Dadap
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 6 ++
1 file changed, 6 insertions(+)
diff
Fall back to retrieving the EDID via the ACPI _DDC method, when present
for notebook internal panels, when EDID retrieval via the standard EDID
paths is unsuccessful.
Signed-off-by: Daniel Dadap
---
drivers/gpu/drm/i915/display/intel_dp.c | 8 +++-
drivers/gpu/drm/i915/display
es, but in order to do so, it will first be necessary
to develop a way to correlate individual DRM outputs with their
corresponding entities in ACPI.
Signed-off-by: Daniel Dadap
---
drivers/gpu/drm/drm_edid.c | 161 +
include/drm/drm_edid.h | 1 +
2 files ch
phics systems with muxed display output, when the display is muxed
away, as well as on a small number of non-muxed and/or non-hybrid
systems where ACPI _DDC is the only means of accessing the EDID for
the internal panel.
Daniel Dadap (4):
drm: retrieve EDID via ACPI _DDC method
i915: fall back to ACPI
On 7/28/20 1:50 AM, Christian König wrote:
Am 27.07.20 um 22:53 schrieb Daniel Dadap:
Fall back to retrieving the EDID via the ACPI _DDC method, when present
for notebook internal panels, when retrieving BIOS-embedded EDIDs.
Signed-off-by: Daniel Dadap
---
drivers/gpu/drm/radeon
On 8/29/22 06:41, Hans de Goede wrote:
Hi,
On 8/26/22 00:21, Daniel Dadap wrote:
On 8/25/22 9:37 AM, Hans de Goede wrote:
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness
Thanks, Hans:
On 7/12/22 14:38, Hans de Goede wrote:
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness contr
I'll ask around to see if there's some DMI property we can match in
order to detect whether a system is expected to use the EC backlight
driver: if so, maybe we can avoid the WMI interactions in patch 16/29 of
this series. Although I suppose even if there were a DMI property, we'd
still need to
> On Jul 15, 2022, at 06:59, Hans de Goede wrote:
>
> Hi Daniel,
>
>> On 7/12/22 22:13, Daniel Dadap wrote:
>> Thanks, Hans:
>>
>>> On 7/12/22 14:38, Hans de Goede wrote:
>>> On some new laptop designs a new Nvidia specific WMI inter
On 7/12/22 14:38, Hans de Goede wrote:
ATM on x86 laptops where we want userspace to use the acpi_video backlight
device we often register both the GPU's native backlight device and
acpi_video's firmware acpi_video# backlight device. This relies on
userspace preferring firmware type backlight d
On 7/21/22 16:24, Daniel Dadap wrote:
On 7/12/22 14:38, Hans de Goede wrote:
ATM on x86 laptops where we want userspace to use the acpi_video
backlight
device we often register both the GPU's native backlight device and
acpi_video's firmware acpi_video# backlight device. This
On 8/2/22 06:31, Hans de Goede wrote:
Hi Daniel,
On 7/21/22 23:30, Daniel Dadap wrote:
On 7/21/22 16:24, Daniel Dadap wrote:
On 7/12/22 14:38, Hans de Goede wrote:
ATM on x86 laptops where we want userspace to use the acpi_video backlight
device we often register both the GPU's n
On 8/17/22 10:05 AM, Hans de Goede wrote:
Hi Daniel,
On 8/2/22 18:49, Daniel Dadap wrote:
On 8/2/22 06:31, Hans de Goede wrote:
Hi Daniel,
On 7/21/22 23:30, Daniel Dadap wrote:
On 7/21/22 16:24, Daniel Dadap wrote:
On 7/12/22 14:38, Hans de Goede wrote:
ATM on x86 laptops where we want
On 8/17/22 7:22 AM, Hans de Goede wrote:
Hi Daniel,
On 7/15/22 13:59, Hans de Goede wrote:
Hi Daniel,
On 7/12/22 22:13, Daniel Dadap wrote:
Thanks, Hans:
On 7/12/22 14:38, Hans de Goede wrote:
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about
On 8/18/22 1:42 PM, Hans de Goede wrote:
Move the WMI interface definitions to a header, so that the definitions
can be shared with drivers/acpi/video_detect.c .
Suggested-by: Daniel Dadap
Signed-off-by: Hans de Goede
---
MAINTAINERS | 1 +
.../platform
-detect code check for nvidia-wmi-ec-backlight in
drivers/acpi/video_detect.c already checks that the WMI advertised
brightness-source is the embedded controller, this new check makes it
unnecessary for nvidia_wmi_ec_backlight_probe() to check this itself.
Suggested-by: Daniel Dadap
Signed-off-by
On 8/18/22 1:42 PM, Hans de Goede wrote:
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness control.
When t
On 8/18/22 1:42 PM, Hans de Goede wrote:
On x86/ACPI boards the acpi_video driver will usually initialize before
the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
to show up and then the kms driver registers its own native backlight
device after which the drivers/acpi/v
Thanks, Hans.
Reviewed-by: Daniel Dadap
On 8/25/22 9:37 AM, Hans de Goede wrote:
Move the WMI interface definitions to a header, so that the definitions
can be shared with drivers/acpi/video_detect.c .
Changes in v2:
- Add missing Nvidia copyright header
- Move WMI_BRIGHTNESS_GUID to nvidia
On 8/25/22 9:37 AM, Hans de Goede wrote:
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness control.
When thi
On Wed, Dec 07, 2022 at 10:32:05PM +0100, Hans de Goede wrote:
> Hi,
>
> On 12/7/22 22:21, Limonciello, Mario wrote:
> > On 12/7/2022 15:04, Hans de Goede wrote:
> >> Hi All,
> >>
> >> Mario, thank you for working on this.
> >
> > Sure
> >
> >
> >>
> >> Note that the problem of the creating a n
On Thu, Dec 08, 2022 at 10:42:05AM -0600, Mario Limonciello wrote:
> The current logic for the ACPI backlight detection will create
> a backlight device if no native or vendor drivers have created
> 8 seconds after the system has booted if the ACPI tables
> included backlight control methods.
>
>
On 5/17/22 10:23, Hans de Goede wrote:
On x86/ACPI boards the acpi_video driver will usually initializing before
the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
to show up and then the kms driver registers its own native backlight
device after which the drivers/acpi/v
On 5/20/22 16:41, Daniel Dadap wrote:
On 5/17/22 10:23, Hans de Goede wrote:
On x86/ACPI boards the acpi_video driver will usually initializing
before
the kms driver (except i915). This causes
/sys/class/backlight/acpi_video0
to show up and then the kms driver registers its own native
On 5/18/22 03:44, Jani Nikula wrote:
On Tue, 17 May 2022, Hans de Goede wrote:
Hi All,
As mentioned in my RFC titled "drm/kms: control display brightness through
drm_connector properties":
https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/
The first step toward
27 matches
Mail list logo
