[BUG] ucsi: duplicate partner altmode — the invalid VDO wins, DP Alt Mode never works

[BUG] ucsi: duplicate partner altmode — the invalid VDO wins, DP Alt Mode never works

[Manuel Knitza]

Hi,

on a Dell XPS 16 DA16260 (Panther Lake, BIOS 1.10.1) the UCSI firmware
reports the
DisplayPort alternate mode twice with conflicting VDOs. The kernel
keeps the first entry
and discards the second — but here the first is the malformed one, and
the result is that
DisplayPort Alt Mode never works on any port when a plain USB-C→DP
adapter is hotplugged.

>     ucsi_acpi USBC000:00: con2: Firmware bug: duplicate partner altmode SVID 0xff01 at
>         offset 1, ignoring but please contact the BIOS vendor to fix this issue.
>     ucsi_acpi USBC000:00: con2: VDO mismatch: 0xff01a843 vs 0x40101407


Identical output on con3. Reproduced on 7.1.8 and 7.2.3.

The firmware is clearly at fault and the message says so. My point is
a different one: of
the two VDOs the firmware offers, one is usable and the kernel
systematically picks the
other, turning a firmware quirk into a total loss of function.

> Retained  0xff01a843 — top 16 bits are 0xff01, i.e. the SVID itself, apparently packed
>                        into the VDO field by the firmware. Parsed as a DP VDO this
>                        advertises only pin assignments D and F (2 lanes).
> Discarded 0x40101407 — well-formed DP Alt Mode VDO: DFP_D + UFP_D, DPv1.3 signalling,
>                        UFP_D pin assignments C and E (4 lanes).


The adapter itself is not the source of the duplicate. Its USB
Billboard descriptor
declares exactly one alternate mode:

>     Billboard capability: supported alt modes = 1, preferred = 0
>       [0] SVID = 0xff01
>     Billboard AltMode capability: dwAltModeVdo = 0x40101007


So the device offers a single, valid DP VDO; the duplication and the
corrupted variant are
produced on the UCSI/PPM side.

Consequences with the malformed VDO retained:

  - /sys/class/typec/portX-partner/portX-partner.0/displayport/pin_assignment
shows "D F",
    never C or E, so even a working link could not carry 4 lanes.
  - hpd stays 0; the sink is never seen.
  - Writing to .../displayport/pin_assignment fails with
      typec_displayport portX-partner.0: firmware doesn't support
alternate mode overriding
    so userspace cannot correct it either.

Interestingly the hardware path is fine: if the same adapter is
already connected at boot,
the display comes up at full 5120x2160@60, port_clock 810000 (HBR3),
lane_count 4, bpp 24.
Only the hotplug path, which goes through UCSI, fails. That reinforces
that the platform
can do 4-lane DP and only the altmode bookkeeping is wrong.

Would it be reasonable for ucsi_altmode_is_duplicate() /
ucsi_register_altmode() to prefer
a VDO that parses as valid for the given SVID over one that does not,
instead of keeping
whichever arrived first? For DP Alt Mode a cheap sanity check exists —
a VDO whose upper
bits repeat the SVID, or which advertises no pin assignment usable by
the port, is not a
plausible descriptor. Keeping the current warning would still tell the
user their firmware
is broken, while not letting it break the port.

I am happy to test patches; the machine reproduces this on every hotplug.

Relevant symbols in the module: ucsi_altmode_is_duplicate,
ucsi_register_altmode,
ucsi_register_altmodes, ucsi_check_altmodes, ucsi_dump_duplicate_altmode.

Full message text for reference:
    "con%d: Firmware bug: duplicate %s altmode SVID 0x%04x at offset
%d, ignoring but
     please contact the BIOS vendor to fix this issue."
    "con%d: VDO mismatch: 0x%08x vs 0x%08x"

--

A second, probably unrelated observation on the same machine,
mentioned only in case it
rings a bell: ucsi_acpi frequently fails at boot with

    ucsi_acpi USBC000:00: con1: failed to register alt modes
    ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed

after which /sys/class/typec/ is empty for the rest of the session.
Reloading the module
("modprobe -r ucsi_acpi && modprobe ucsi_acpi") brings all three ports
up. UCSI_GET_PDOS
also fails persistently with -5 and occasionally -95. Same firmware,
same platform. I can
send that as a separate report with full logs if it is of interest.

Re: [BUG] ucsi: duplicate partner altmode — the invalid VDO wins, DP Alt Mode never works

[Heikki Krogerus]

+Dell and Guilhem

On Wed, Sep 09, 2026 at 03:25:11PM +0200, Manuel Knitza wrote:
> Hi,
> 
> on a Dell XPS 16 DA16260 (Panther Lake, BIOS 1.10.1) the UCSI firmware
> reports the
> DisplayPort alternate mode twice with conflicting VDOs. The kernel
> keeps the first entry
> and discards the second — but here the first is the malformed one, and
> the result is that
> DisplayPort Alt Mode never works on any port when a plain USB-C→DP
> adapter is hotplugged.
> 
> >     ucsi_acpi USBC000:00: con2: Firmware bug: duplicate partner altmode SVID 0xff01 at
> >         offset 1, ignoring but please contact the BIOS vendor to fix this issue.
> >     ucsi_acpi USBC000:00: con2: VDO mismatch: 0xff01a843 vs 0x40101407
> 
> 
> Identical output on con3. Reproduced on 7.1.8 and 7.2.3.
> 
> The firmware is clearly at fault and the message says so. My point is
> a different one: of
> the two VDOs the firmware offers, one is usable and the kernel
> systematically picks the
> other, turning a firmware quirk into a total loss of function.
> 
> > Retained  0xff01a843 — top 16 bits are 0xff01, i.e. the SVID itself, apparently packed
> >                        into the VDO field by the firmware. Parsed as a DP VDO this
> >                        advertises only pin assignments D and F (2 lanes).
> > Discarded 0x40101407 — well-formed DP Alt Mode VDO: DFP_D + UFP_D, DPv1.3 signalling,
> >                        UFP_D pin assignments C and E (4 lanes).
> 
> 
> The adapter itself is not the source of the duplicate. Its USB
> Billboard descriptor
> declares exactly one alternate mode:
> 
> >     Billboard capability: supported alt modes = 1, preferred = 0
> >       [0] SVID = 0xff01
> >     Billboard AltMode capability: dwAltModeVdo = 0x40101007
> 
> 
> So the device offers a single, valid DP VDO; the duplication and the
> corrupted variant are
> produced on the UCSI/PPM side.
> 
> Consequences with the malformed VDO retained:
> 
>   - /sys/class/typec/portX-partner/portX-partner.0/displayport/pin_assignment
> shows "D F",
>     never C or E, so even a working link could not carry 4 lanes.
>   - hpd stays 0; the sink is never seen.
>   - Writing to .../displayport/pin_assignment fails with
>       typec_displayport portX-partner.0: firmware doesn't support
> alternate mode overriding
>     so userspace cannot correct it either.
> 
> Interestingly the hardware path is fine: if the same adapter is
> already connected at boot,
> the display comes up at full 5120x2160@60, port_clock 810000 (HBR3),
> lane_count 4, bpp 24.
> Only the hotplug path, which goes through UCSI, fails. That reinforces
> that the platform
> can do 4-lane DP and only the altmode bookkeeping is wrong.
> 
> Would it be reasonable for ucsi_altmode_is_duplicate() /
> ucsi_register_altmode() to prefer
> a VDO that parses as valid for the given SVID over one that does not,
> instead of keeping
> whichever arrived first? For DP Alt Mode a cheap sanity check exists —
> a VDO whose upper
> bits repeat the SVID, or which advertises no pin assignment usable by
> the port, is not a
> plausible descriptor. Keeping the current warning would still tell the
> user their firmware
> is broken, while not letting it break the port.
> 
> I am happy to test patches; the machine reproduces this on every hotplug.
> 
> Relevant symbols in the module: ucsi_altmode_is_duplicate,
> ucsi_register_altmode,
> ucsi_register_altmodes, ucsi_check_altmodes, ucsi_dump_duplicate_altmode.
> 
> Full message text for reference:
>     "con%d: Firmware bug: duplicate %s altmode SVID 0x%04x at offset
> %d, ignoring but
>      please contact the BIOS vendor to fix this issue."
>     "con%d: VDO mismatch: 0x%08x vs 0x%08x"
> 
> --
> 
> A second, probably unrelated observation on the same machine,
> mentioned only in case it
> rings a bell: ucsi_acpi frequently fails at boot with
> 
>     ucsi_acpi USBC000:00: con1: failed to register alt modes
>     ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed
> 
> after which /sys/class/typec/ is empty for the rest of the session.
> Reloading the module
> ("modprobe -r ucsi_acpi && modprobe ucsi_acpi") brings all three ports
> up. UCSI_GET_PDOS
> also fails persistently with -5 and occasionally -95. Same firmware,
> same platform. I can
> send that as a separate report with full logs if it is of interest.

Thanks for the report. There are now a lot of issues with the altmodes
on these Dell XPS laptops. These problems have been reported also on
earlier Dell XPS 13 and on some other Dell systems too.

Hopefully Dell fixes their EC/PPM firmware at some point, but for now,
I'm removing the alternate mode details UCSI feature flag from all
Dell XPS systems. That means the alternate modes are not going to be
registered at all on these laptops.

thanks,

-- 
heikki

Re: [BUG] ucsi: duplicate partner altmode — the invalid VDO wins, DP Alt Mode never works

[Manuel Knitza]

Thanks Heikki, and thanks for looping in Dell.

Tested on both kernels. Short version: the DMI match is right, the quirk
does exactly what it is meant to do, nothing regresses -

Tested-by: Manuel Knitza <manuel.knitza@googlemail.com>

- but it does not fix the loss of function, and I think that part is
what needs to reach Dell.

DMI match
---------

Confirmed here:

    DMI_SYS_VENDOR   = "Dell Inc."
    DMI_PRODUCT_NAME = "XPS 16 DA16260"

Both DMI_MATCH substrings hit, so the quirk applies.

Build note
----------

The patch does not build on 7.1.x: there ucsi_sync_control_common() and
the .sync_control callback still take 5 arguments; msg_out/msg_out_size
arrived in 7.2. Against 7.2.x it compiles clean, no warnings. Mentioning
it only so nobody wastes time trying it on an older stable kernel.

Test result, unmodified patch on 7.2.3-arch1-3
----------------------------------------------

Before, with the stock module:

    Alt modes registered: 1
    port1-partner.0  svid=8087  vdo=0x8087a043  active=no
    ucsi_acpi USBC000:00: con2: Firmware bug: duplicate partner
altmode SVID 0x8087 ...
    ucsi_acpi USBC000:00: con2: VDO mismatch: 0x8087a043 vs 0x00000001

After loading the patched module:

    ucsi_acpi USBC000:00: Firmware bug: broken altmode details
reporting, disabling
    Alt modes registered: 0
    duplicate-altmode messages: 0
    all three connectors register normally

The already running DisplayPort link was not disturbed by the module
swap at any point: 5120x2160@60, port_clock 810000, lane_count 4, bpp 24
throughout. I also ran the same change backported to the 5-argument
signature on 7.1.8, with the same result.

One practical note for anyone repeating this: swap the module with
"rmmod ucsi_acpi", not "modprobe -r" - the latter also drops the then
unused typec_ucsi, and the new module fails with "Unknown symbol
ucsi_create".

What it does not fix
--------------------

With the unmodified patch loaded on 7.2.3 I unplugged and re-plugged the
monitor. The USB side comes back completely - hub, HID, cdc_acm all
re-enumerate - and DP-1 stays "disconnected". Zero UCSI messages this
time. Same outcome with the backport on 7.1.8. So not querying the alt
mode details does not change the functional result.

That matches an accidental experiment from a few days earlier: setting
ThunderboltPorts=Disabled in the BIOS stops the firmware offering the
Thunderbolt SVID, after which the kernel registers no partner alt modes
at all - and DisplayPort still works perfectly when the cable is attached
at boot, and still fails on hotplug.

Which means I should correct my own original report: I claimed the
retained malformed VDO caused the failure. It does not. While a 4-lane
HBR3 link was running I read

    port2-partner.0  vdo=0xff01a843 (the malformed one)  active=yes
    displayport/     configuration=[USB]  pin_assignment=A  hpd=0

On this platform the typec alt mode bookkeeping never described reality
in the first place. Your patch removes data that was actively
misleading, which is worth doing on its own - but the bug underneath is
elsewhere.

The remaining bug, for Dell
---------------------------

DP Alt Mode is never entered again once the machine is running:

    cold boot with cable attached   always works
    hotplug                         never works
    resume from s2idle              never works
    hibernate (S4)                  always works   <- full POST

It is not limited to suspend. Merely blanking the screen is enough. The
lock screen issues a DPMS off on all outputs, the monitor deep-sleeps,
drops the link, and it never returns:

    xe [drm] *ERROR* [CONNECTOR:521:DP-1] Invalid DPCD with no link rates
    xe [drm] *ERROR* [CONNECTOR:521:DP-1] Invalid DPCD max lane count (0)

with the machine awake throughout - no PM: suspend entry in the log,
uptime continuous. The USB-C connection never drops; only the DP link
inside it dies.

Nothing on the OS side brings it back. Tried and failed, all of them:

  - power-cycling the monitor
  - modprobe -r ucsi_acpi && modprobe ucsi_acpi, in both orders relative
    to re-plugging the cable
  - echo 1 > /sys/kernel/debug/dri/0/DP-1/i915_dp_force_link_retrain
  - echo detect / echo on > /sys/class/drm/card0-DP-1/status
    ("on" yields only VESA fallback modes, no EDID - AUX does not answer)
  - echo device > /sys/class/typec/port1/data_role  -> EACCES
  - echo source > /sys/class/typec/port1/power_role -> EIO, plus
    "ucsi_acpi: unknown error 0"

A reboot is the only way back, which is hard to live with on a docked
laptop. My workaround is a small service that re-enables DPMS on external
outputs whenever anything turns them off, so the link is never dropped in
the first place.

Hardware: Dell XPS 16 DA16260, BIOS 1.10.1. Identical behaviour with a
plain USB-C-to-DP adapter and with a direct USB-C cable to the monitor,
so it is not the adapter.

Happy to test patches or firmware and to collect any traces that help -
the machine reproduces all of this on demand.

Am Fr., 11. Sept. 2026 um 12:15 Uhr schrieb Heikki Krogerus
<heikki.krogerus@linux.intel.com>:
>
> +Dell and Guilhem
>
> On Wed, Sep 09, 2026 at 03:25:11PM +0200, Manuel Knitza wrote:
> > Hi,
> >
> > on a Dell XPS 16 DA16260 (Panther Lake, BIOS 1.10.1) the UCSI firmware
> > reports the
> > DisplayPort alternate mode twice with conflicting VDOs. The kernel
> > keeps the first entry
> > and discards the second — but here the first is the malformed one, and
> > the result is that
> > DisplayPort Alt Mode never works on any port when a plain USB-C→DP
> > adapter is hotplugged.
> >
> > >     ucsi_acpi USBC000:00: con2: Firmware bug: duplicate partner altmode SVID 0xff01 at
> > >         offset 1, ignoring but please contact the BIOS vendor to fix this issue.
> > >     ucsi_acpi USBC000:00: con2: VDO mismatch: 0xff01a843 vs 0x40101407
> >
> >
> > Identical output on con3. Reproduced on 7.1.8 and 7.2.3.
> >
> > The firmware is clearly at fault and the message says so. My point is
> > a different one: of
> > the two VDOs the firmware offers, one is usable and the kernel
> > systematically picks the
> > other, turning a firmware quirk into a total loss of function.
> >
> > > Retained  0xff01a843 — top 16 bits are 0xff01, i.e. the SVID itself, apparently packed
> > >                        into the VDO field by the firmware. Parsed as a DP VDO this
> > >                        advertises only pin assignments D and F (2 lanes).
> > > Discarded 0x40101407 — well-formed DP Alt Mode VDO: DFP_D + UFP_D, DPv1.3 signalling,
> > >                        UFP_D pin assignments C and E (4 lanes).
> >
> >
> > The adapter itself is not the source of the duplicate. Its USB
> > Billboard descriptor
> > declares exactly one alternate mode:
> >
> > >     Billboard capability: supported alt modes = 1, preferred = 0
> > >       [0] SVID = 0xff01
> > >     Billboard AltMode capability: dwAltModeVdo = 0x40101007
> >
> >
> > So the device offers a single, valid DP VDO; the duplication and the
> > corrupted variant are
> > produced on the UCSI/PPM side.
> >
> > Consequences with the malformed VDO retained:
> >
> >   - /sys/class/typec/portX-partner/portX-partner.0/displayport/pin_assignment
> > shows "D F",
> >     never C or E, so even a working link could not carry 4 lanes.
> >   - hpd stays 0; the sink is never seen.
> >   - Writing to .../displayport/pin_assignment fails with
> >       typec_displayport portX-partner.0: firmware doesn't support
> > alternate mode overriding
> >     so userspace cannot correct it either.
> >
> > Interestingly the hardware path is fine: if the same adapter is
> > already connected at boot,
> > the display comes up at full 5120x2160@60, port_clock 810000 (HBR3),
> > lane_count 4, bpp 24.
> > Only the hotplug path, which goes through UCSI, fails. That reinforces
> > that the platform
> > can do 4-lane DP and only the altmode bookkeeping is wrong.
> >
> > Would it be reasonable for ucsi_altmode_is_duplicate() /
> > ucsi_register_altmode() to prefer
> > a VDO that parses as valid for the given SVID over one that does not,
> > instead of keeping
> > whichever arrived first? For DP Alt Mode a cheap sanity check exists —
> > a VDO whose upper
> > bits repeat the SVID, or which advertises no pin assignment usable by
> > the port, is not a
> > plausible descriptor. Keeping the current warning would still tell the
> > user their firmware
> > is broken, while not letting it break the port.
> >
> > I am happy to test patches; the machine reproduces this on every hotplug.
> >
> > Relevant symbols in the module: ucsi_altmode_is_duplicate,
> > ucsi_register_altmode,
> > ucsi_register_altmodes, ucsi_check_altmodes, ucsi_dump_duplicate_altmode.
> >
> > Full message text for reference:
> >     "con%d: Firmware bug: duplicate %s altmode SVID 0x%04x at offset
> > %d, ignoring but
> >      please contact the BIOS vendor to fix this issue."
> >     "con%d: VDO mismatch: 0x%08x vs 0x%08x"
> >
> > --
> >
> > A second, probably unrelated observation on the same machine,
> > mentioned only in case it
> > rings a bell: ucsi_acpi frequently fails at boot with
> >
> >     ucsi_acpi USBC000:00: con1: failed to register alt modes
> >     ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed
> >
> > after which /sys/class/typec/ is empty for the rest of the session.
> > Reloading the module
> > ("modprobe -r ucsi_acpi && modprobe ucsi_acpi") brings all three ports
> > up. UCSI_GET_PDOS
> > also fails persistently with -5 and occasionally -95. Same firmware,
> > same platform. I can
> > send that as a separate report with full logs if it is of interest.
>
> Thanks for the report. There are now a lot of issues with the altmodes
> on these Dell XPS laptops. These problems have been reported also on
> earlier Dell XPS 13 and on some other Dell systems too.
>
> Hopefully Dell fixes their EC/PPM firmware at some point, but for now,
> I'm removing the alternate mode details UCSI feature flag from all
> Dell XPS systems. That means the alternate modes are not going to be
> registered at all on these laptops.
>
> thanks,
>
> --
> heikki

Re: [BUG] ucsi: duplicate partner altmode — the invalid VDO wins, DP Alt Mode never works

[Heikki Krogerus]

On Sat, Sep 12, 2026 at 02:43:14PM +0200, Manuel Knitza wrote:
> Thanks Heikki, and thanks for looping in Dell.
> 
> Tested on both kernels. Short version: the DMI match is right, the quirk
> does exactly what it is meant to do, nothing regresses -
> 
> Tested-by: Manuel Knitza <manuel.knitza@googlemail.com>
> 
> - but it does not fix the loss of function, and I think that part is
> what needs to reach Dell.

Thanks. Let's hope the guys from Dell take a look at this.

Br,

> DMI match
> ---------
> 
> Confirmed here:
> 
>     DMI_SYS_VENDOR   = "Dell Inc."
>     DMI_PRODUCT_NAME = "XPS 16 DA16260"
> 
> Both DMI_MATCH substrings hit, so the quirk applies.
> 
> Build note
> ----------
> 
> The patch does not build on 7.1.x: there ucsi_sync_control_common() and
> the .sync_control callback still take 5 arguments; msg_out/msg_out_size
> arrived in 7.2. Against 7.2.x it compiles clean, no warnings. Mentioning
> it only so nobody wastes time trying it on an older stable kernel.
> 
> Test result, unmodified patch on 7.2.3-arch1-3
> ----------------------------------------------
> 
> Before, with the stock module:
> 
>     Alt modes registered: 1
>     port1-partner.0  svid=8087  vdo=0x8087a043  active=no
>     ucsi_acpi USBC000:00: con2: Firmware bug: duplicate partner
> altmode SVID 0x8087 ...
>     ucsi_acpi USBC000:00: con2: VDO mismatch: 0x8087a043 vs 0x00000001
> 
> After loading the patched module:
> 
>     ucsi_acpi USBC000:00: Firmware bug: broken altmode details
> reporting, disabling
>     Alt modes registered: 0
>     duplicate-altmode messages: 0
>     all three connectors register normally
> 
> The already running DisplayPort link was not disturbed by the module
> swap at any point: 5120x2160@60, port_clock 810000, lane_count 4, bpp 24
> throughout. I also ran the same change backported to the 5-argument
> signature on 7.1.8, with the same result.
> 
> One practical note for anyone repeating this: swap the module with
> "rmmod ucsi_acpi", not "modprobe -r" - the latter also drops the then
> unused typec_ucsi, and the new module fails with "Unknown symbol
> ucsi_create".
> 
> What it does not fix
> --------------------
> 
> With the unmodified patch loaded on 7.2.3 I unplugged and re-plugged the
> monitor. The USB side comes back completely - hub, HID, cdc_acm all
> re-enumerate - and DP-1 stays "disconnected". Zero UCSI messages this
> time. Same outcome with the backport on 7.1.8. So not querying the alt
> mode details does not change the functional result.
> 
> That matches an accidental experiment from a few days earlier: setting
> ThunderboltPorts=Disabled in the BIOS stops the firmware offering the
> Thunderbolt SVID, after which the kernel registers no partner alt modes
> at all - and DisplayPort still works perfectly when the cable is attached
> at boot, and still fails on hotplug.
> 
> Which means I should correct my own original report: I claimed the
> retained malformed VDO caused the failure. It does not. While a 4-lane
> HBR3 link was running I read
> 
>     port2-partner.0  vdo=0xff01a843 (the malformed one)  active=yes
>     displayport/     configuration=[USB]  pin_assignment=A  hpd=0
> 
> On this platform the typec alt mode bookkeeping never described reality
> in the first place. Your patch removes data that was actively
> misleading, which is worth doing on its own - but the bug underneath is
> elsewhere.
> 
> The remaining bug, for Dell
> ---------------------------
> 
> DP Alt Mode is never entered again once the machine is running:
> 
>     cold boot with cable attached   always works
>     hotplug                         never works
>     resume from s2idle              never works
>     hibernate (S4)                  always works   <- full POST
> 
> It is not limited to suspend. Merely blanking the screen is enough. The
> lock screen issues a DPMS off on all outputs, the monitor deep-sleeps,
> drops the link, and it never returns:
> 
>     xe [drm] *ERROR* [CONNECTOR:521:DP-1] Invalid DPCD with no link rates
>     xe [drm] *ERROR* [CONNECTOR:521:DP-1] Invalid DPCD max lane count (0)
> 
> with the machine awake throughout - no PM: suspend entry in the log,
> uptime continuous. The USB-C connection never drops; only the DP link
> inside it dies.
> 
> Nothing on the OS side brings it back. Tried and failed, all of them:
> 
>   - power-cycling the monitor
>   - modprobe -r ucsi_acpi && modprobe ucsi_acpi, in both orders relative
>     to re-plugging the cable
>   - echo 1 > /sys/kernel/debug/dri/0/DP-1/i915_dp_force_link_retrain
>   - echo detect / echo on > /sys/class/drm/card0-DP-1/status
>     ("on" yields only VESA fallback modes, no EDID - AUX does not answer)
>   - echo device > /sys/class/typec/port1/data_role  -> EACCES
>   - echo source > /sys/class/typec/port1/power_role -> EIO, plus
>     "ucsi_acpi: unknown error 0"
> 
> A reboot is the only way back, which is hard to live with on a docked
> laptop. My workaround is a small service that re-enables DPMS on external
> outputs whenever anything turns them off, so the link is never dropped in
> the first place.
> 
> Hardware: Dell XPS 16 DA16260, BIOS 1.10.1. Identical behaviour with a
> plain USB-C-to-DP adapter and with a direct USB-C cable to the monitor,
> so it is not the adapter.
> 
> Happy to test patches or firmware and to collect any traces that help -
> the machine reproduces all of this on demand.
> 
> Am Fr., 11. Sept. 2026 um 12:15 Uhr schrieb Heikki Krogerus
> <heikki.krogerus@linux.intel.com>:
> >
> > +Dell and Guilhem
> >
> > On Wed, Sep 09, 2026 at 03:25:11PM +0200, Manuel Knitza wrote:
> > > Hi,
> > >
> > > on a Dell XPS 16 DA16260 (Panther Lake, BIOS 1.10.1) the UCSI firmware
> > > reports the
> > > DisplayPort alternate mode twice with conflicting VDOs. The kernel
> > > keeps the first entry
> > > and discards the second — but here the first is the malformed one, and
> > > the result is that
> > > DisplayPort Alt Mode never works on any port when a plain USB-C→DP
> > > adapter is hotplugged.
> > >
> > > >     ucsi_acpi USBC000:00: con2: Firmware bug: duplicate partner altmode SVID 0xff01 at
> > > >         offset 1, ignoring but please contact the BIOS vendor to fix this issue.
> > > >     ucsi_acpi USBC000:00: con2: VDO mismatch: 0xff01a843 vs 0x40101407
> > >
> > >
> > > Identical output on con3. Reproduced on 7.1.8 and 7.2.3.
> > >
> > > The firmware is clearly at fault and the message says so. My point is
> > > a different one: of
> > > the two VDOs the firmware offers, one is usable and the kernel
> > > systematically picks the
> > > other, turning a firmware quirk into a total loss of function.
> > >
> > > > Retained  0xff01a843 — top 16 bits are 0xff01, i.e. the SVID itself, apparently packed
> > > >                        into the VDO field by the firmware. Parsed as a DP VDO this
> > > >                        advertises only pin assignments D and F (2 lanes).
> > > > Discarded 0x40101407 — well-formed DP Alt Mode VDO: DFP_D + UFP_D, DPv1.3 signalling,
> > > >                        UFP_D pin assignments C and E (4 lanes).
> > >
> > >
> > > The adapter itself is not the source of the duplicate. Its USB
> > > Billboard descriptor
> > > declares exactly one alternate mode:
> > >
> > > >     Billboard capability: supported alt modes = 1, preferred = 0
> > > >       [0] SVID = 0xff01
> > > >     Billboard AltMode capability: dwAltModeVdo = 0x40101007
> > >
> > >
> > > So the device offers a single, valid DP VDO; the duplication and the
> > > corrupted variant are
> > > produced on the UCSI/PPM side.
> > >
> > > Consequences with the malformed VDO retained:
> > >
> > >   - /sys/class/typec/portX-partner/portX-partner.0/displayport/pin_assignment
> > > shows "D F",
> > >     never C or E, so even a working link could not carry 4 lanes.
> > >   - hpd stays 0; the sink is never seen.
> > >   - Writing to .../displayport/pin_assignment fails with
> > >       typec_displayport portX-partner.0: firmware doesn't support
> > > alternate mode overriding
> > >     so userspace cannot correct it either.
> > >
> > > Interestingly the hardware path is fine: if the same adapter is
> > > already connected at boot,
> > > the display comes up at full 5120x2160@60, port_clock 810000 (HBR3),
> > > lane_count 4, bpp 24.
> > > Only the hotplug path, which goes through UCSI, fails. That reinforces
> > > that the platform
> > > can do 4-lane DP and only the altmode bookkeeping is wrong.
> > >
> > > Would it be reasonable for ucsi_altmode_is_duplicate() /
> > > ucsi_register_altmode() to prefer
> > > a VDO that parses as valid for the given SVID over one that does not,
> > > instead of keeping
> > > whichever arrived first? For DP Alt Mode a cheap sanity check exists —
> > > a VDO whose upper
> > > bits repeat the SVID, or which advertises no pin assignment usable by
> > > the port, is not a
> > > plausible descriptor. Keeping the current warning would still tell the
> > > user their firmware
> > > is broken, while not letting it break the port.
> > >
> > > I am happy to test patches; the machine reproduces this on every hotplug.
> > >
> > > Relevant symbols in the module: ucsi_altmode_is_duplicate,
> > > ucsi_register_altmode,
> > > ucsi_register_altmodes, ucsi_check_altmodes, ucsi_dump_duplicate_altmode.
> > >
> > > Full message text for reference:
> > >     "con%d: Firmware bug: duplicate %s altmode SVID 0x%04x at offset
> > > %d, ignoring but
> > >      please contact the BIOS vendor to fix this issue."
> > >     "con%d: VDO mismatch: 0x%08x vs 0x%08x"
> > >
> > > --
> > >
> > > A second, probably unrelated observation on the same machine,
> > > mentioned only in case it
> > > rings a bell: ucsi_acpi frequently fails at boot with
> > >
> > >     ucsi_acpi USBC000:00: con1: failed to register alt modes
> > >     ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed
> > >
> > > after which /sys/class/typec/ is empty for the rest of the session.
> > > Reloading the module
> > > ("modprobe -r ucsi_acpi && modprobe ucsi_acpi") brings all three ports
> > > up. UCSI_GET_PDOS
> > > also fails persistently with -5 and occasionally -95. Same firmware,
> > > same platform. I can
> > > send that as a separate report with full logs if it is of interest.
> >
> > Thanks for the report. There are now a lot of issues with the altmodes
> > on these Dell XPS laptops. These problems have been reported also on
> > earlier Dell XPS 13 and on some other Dell systems too.
> >
> > Hopefully Dell fixes their EC/PPM firmware at some point, but for now,
> > I'm removing the alternate mode details UCSI feature flag from all
> > Dell XPS systems. That means the alternate modes are not going to be
> > registered at all on these laptops.
> >
> > thanks,
> >
> > --
> > heikki

-- 
heikki