On 4/3/20 2:16 AM, Daniel Vetter wrote:
On Fri, Apr 3, 2020 at 8:54 AM Daniel Dadap wrote:
On 4/2/20 6:39 AM, Lukas Wunner wrote:
On Fri, Mar 27, 2020 at 04:25:19PM -0500, Daniel Dadap wrote:
A number of hybrid GPU notebook computer designs with dual (integrated plus
discrete) GPUs
On 4/2/20 1:25 PM, Lukas Wunner wrote:
On Thu, Apr 02, 2020 at 12:56:04PM -0500, Daniel Dadap wrote:
I'll check one of the eDP-based systems I've been experimenting on to see if
setting the VGA_SWITCHER_NEEDS_EDP_CONFIG capability in the handler is
sufficient to make i915 avoid poking the AUX
On 4/2/20 6:39 AM, Lukas Wunner wrote:
External email: Use caution opening links or attachments
On Fri, Mar 27, 2020 at 04:25:19PM -0500, Daniel Dadap wrote:
A number of hybrid GPU notebook computer designs with dual (integrated plus
discrete) GPUs are equipped with multiplexers (muxes
On 3/30/20 10:11 AM, Jani Nikula wrote:
On Fri, 27 Mar 2020, Daniel Dadap wrote:
A number of hybrid GPU notebook computer designs with dual (integrated
plus discrete) GPUs are equipped with multiplexers (muxes) that allow
display panels to be driven by either the integrated GPU
ant exists already.
-Daniel
On Mon, Mar 30, 2020 at 9:12 AM Daniel Dadap wrote:
A number of hybrid GPU notebook computer designs with dual (integrated
plus discrete) GPUs are equipped with multiplexers (muxes) that allow
display panels to be driven by either the integrated GPU or the di
A number of hybrid GPU notebook computer designs with dual (integrated
plus discrete) GPUs are equipped with multiplexers (muxes) that allow
display panels to be driven by either the integrated GPU or the discrete
GPU. Typically, this is a selection that can be made at boot time as a
menu
On 4/1/20 3:14 AM, Pekka Paalanen wrote:
On Tue, 31 Mar 2020 20:59:39 -0500
Daniel Dadap wrote:
On 3/30/20 10:11 AM, Jani Nikula wrote:
On Fri, 27 Mar 2020, Daniel Dadap wrote:
A number of hybrid GPU notebook computer designs with dual (integrated
plus discrete) GPUs are equipped
On 4/1/20 1:46 AM, Daniel Vetter wrote
On Wed, Apr 1, 2020 at 3:58 AM Daniel Dadap wrote:
On 3/31/20 2:32 AM, Daniel Vetter wrote:
Since I see no mention of this anywhere in your mail ... have you
tried looking at drivers/gpu/vga/vga_switcheroo.c? This also supports
switching of just
On 4/3/20 2:59 PM, Daniel Vetter wrote:
On Fri, Apr 3, 2020 at 8:06 PM Daniel Dadap wrote:
On 4/3/20 2:16 AM, Daniel Vetter wrote:
On Fri, Apr 3, 2020 at 8:54 AM Daniel Dadap wrote:
On 4/2/20 6:39 AM, Lukas Wunner wrote:
On Fri, Mar 27, 2020 at 04:25:19PM -0500, Daniel Dadap wrote
Hi all,
Some time ago, I asked some questions about how to handle issues with
DRM drivers attempting to touch eDP while muxed away, due to implicit
assumptions about eDP being permanently connected. I've proposed some
changes which prevent eDP access on switched-away eDP outputs for at
to be updated if
designs are developed using the same interfaces which utilize GPUs
from other vendors.
v2,v3: misc. fixes suggested by Barnabás Pőcze
v4: misc. changes suggested by Lukas Wunner
Signed-off-by: Daniel Dadap
---
MAINTAINERS | 6 +
drivers/platform/x86
below.
Signed-off-by: Daniel Dadap
---
MAINTAINERS | 6 +
drivers/platform/x86/Kconfig | 9 ++
drivers/platform/x86/Makefile| 2 +
drivers/platform/x86/mxds-gmux.c | 265 +++
...
+config MXDS_GMUX
+ tristate "ACPI MXDS
On 8/10/20 10:43 PM, Lukas Wunner wrote:
On Mon, Aug 10, 2020 at 01:44:58PM -0500, Daniel Dadap wrote:
Would it be clearer to write it out as something like 0 << 4 & 1 << 0 for
MUX_STATE_SET_IGPU and 1 << 4 & 1 << 0 for MUX_STATE_SET_DGPU?
BIT(4) | BIT(0)
On 8/10/20 3:37 AM, Lukas Wunner wrote:
External email: Use caution opening links or attachments
On Wed, Jul 29, 2020 at 04:05:57PM -0500, Daniel Dadap wrote:
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General
to be updated if
designs are developed using the same interfaces which utilize GPUs
from other vendors.
v2,v3: misc. fixes suggested by Barnabás Pőcze
Signed-off-by: Daniel Dadap
---
MAINTAINERS | 6 +
drivers/platform/x86/Kconfig | 9 ++
drivers/platform/x86
Add a vga-switcheroo callback for reprobing displays. Use this new
callback to retrain the link on all DP encoders after a mux switch.
Signed-off-by: Daniel Dadap
---
drivers/gpu/drm/i915/i915_switcheroo.c | 27 +-
1 file changed, 26 insertions(+), 1 deletion(-)
diff
Attempting to commit a modeset while mux-switched away can cause
problems due to DisplayPort links being unavailable while they are
physically disconnected. In order to avoid this, bail out of atomic
commit early if attempted while a display mux is switched away.
Signed-off-by: Daniel Dadap
Add a new vga-switcheroo client callback to allow clients to register
for receiving notifications when a mux switch is pending, completed,
or failed. This allows individual client drivers to prepare for or
respond to mux switches to and from the registered client device.
Signed-off-by: Daniel
is eDP-specific, as normal DP (e.g. for external
displays) should be able to detect that the link is not physically
connected, while eDP is usually assumed to be always connected.
Signed-off-by: Daniel Dadap
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 9 +
1 file changed, 9
ment hooks, but still calls
the reprobe hook. This switch event type uses 'I' as a prefix for its
commands, similar to the existing 'D' pefix for the deferred commands
and 'M' for the mux-only commands.
Signed-off-by: Daniel Dadap
---
drivers/gpu/vga/vga_switcheroo.c | 86 +-
vga-switcheroo clients may wish to know whether they are currently
active, i.e., whether the mux is currently switched to the client
in question. Add an in-kernel API to test whether a vga-switcheroo
client, as identified by PCI device, is actively switched.
Signed-off-by: Daniel Dadap
which switches immediately while still calling
client driver callbacks, and updates the i915 DRM-KMS driver to reprobe
eDP outputs after switching the mux to an i915-driven GPU, and to avoid
using eDP links (which i915 always assumes to be connected) while the
mux is switched away.
Daniel Dadap (6
Sorry for letting this stagnate. I have some patches ready for
discussion which I'll send shortly, but wanted to follow up on some of
the previous conversation:
On 4/28/20 5:14 AM, Daniel Vetter wrote:
On Wed, Apr 22, 2020 at 05:04:54PM -0500, Daniel Dadap wrote:
On 4/3/20 2:59 PM, Daniel
for the introduction. I believe we have corresponded in the past
regarding other issues. Thank you for following up on this patch set.
On 9/2/20 7:38 PM, Daniel Dadap wrote:
Some upcoming notebook designs utilize display muxes driven by a
pair of ACPI methods, MXDM to query and configure
do the same, just in case some crazy machine stores the EDID somewhere
else.
Thanks, I wouldn't have thought of this. It seems Daniel Dadap did a
patch series to do just that, in a generic way:
https://lore.kernel.org/amd-gfx/20200727205357.27839-1-dda...@nvidia.com/
I've tried patch 1 &am
On 3/17/22 12:35, Alex Deucher wrote:
Sorry for jumping in here, but I can't seem to find the original
thread with this comment. amdgpu_atombios_encoder_init_backlight() is
not applicable to these systems. That is the old pre-DC code path.
You want amdgpu_dm_register_backlight_device() for
On 3/17/22 11:42, Hans de Goede wrote:
Hi Daniel,
On 3/17/22 14:28, Daniel Dadap wrote:
On Mar 17, 2022, at 07:17, Hans de Goede wrote:
Hi,
On 3/16/22 21:33, Daniel Dadap wrote:
Some notebook systems with EC-driven backlight control appear to have a
firmware bug which causes the system
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
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/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
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
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
> 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/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 relies
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
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
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
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
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
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
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 native
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/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
Many dual-GPU notebook systems are equipped with a multiplexer ("mux")
to switch the signal source for the internal display panel between the
discrete and integrated GPUs. The vga-switcheroo infrastructure in the
Linux kernel can expose mux switch functionality to userspace via a
simple debugfs
46 matches
Mail list logo
