DDP "skip out-of sequence packets" assumes that 5 packets are enough for a complete frame

[softhack007]

WLED/wled00/e131.cpp

Lines 24 to 38 in 53d6c4b

	//reject late packets belonging to previous frame (assuming 4 packets max. before push)
	if (e131SkipOutOfSequence && lastPushSeq) {
	int sn = p->sequenceNum & 0xF;
	if (sn) {
	if (lastPushSeq > 5) {
	if (sn > (lastPushSeq -5) && sn < lastPushSeq) return;
	} else {
	if (sn > (10 + lastPushSeq) || sn < lastPushSeq) return;
	}
	}
	}
	unsigned ddpChannelsPerLed = ((p->dataType & 0b00111000)>>3 == 0b011) ? 4 : 3; // data type 0x1B (formerly 0x1A) is RGBW (type 3, 8 bit/channel)
	uint32_t start = htonl(p->channelOffset) / ddpChannelsPerLed;

We need to verify if the assumption stated in the source code - 4 packets max before push - is correct w.r.t to the protocol definitions, and analyze if packets that are more than 4 out-of-sequnce can lead to a corrupted LEDs display.

With HUB75 panels, users have succesfully streamed 64x64 pixels, so it seem that larger frame sizes generally do work.

Reference
#5390 (comment)

[softhack007]

@coderabbitai please check the DDP protocol specifications. Is the assumption "4 packets max before push" aligned with the DDP specs? How many DDP packets would be needed for a full frame of 64x64 RGB pixels?

[coderabbitai]

🧩 Analysis chain

Let me look up the DDP specification and check the relevant WLED code.

---

🏁 Script executed:

#!/bin/bash
# Search for DDP-related code with "4 packets" or similar assumptions
rg -n "4 packet\|maxPacket\|packets.*push\|push.*packet\|packet.*count\|ddpCount\|ddp_count\|numPackets\|frameCount\|packet_count" --type=cpp -i -C3

echo "---"
# Look for DDP packet size constants
rg -n "1440\|1480\|DDP_PAYLOAD\|DDP_MAX\|ddpMax\|MAX_PAYLOAD" --type=cpp -i -C3

echo "---"
# Check e131.cpp for DDP handling
fd "e131.cpp" --exec cat {}

echo "---"
# Check ws.cpp for DDP handling
fd "ws.cpp" --exec cat {}

Length of output: 33974

---

🌐 Web query:

DDP protocol specification maximum payload size bytes per packet

💡 Result:

For AppleTalk DDP (Datagram Delivery Protocol), the maximum payload (DDP “data part”) per packet is 586 bytes. [1][2]

This corresponds to a maximum DDP datagram length of 599 bytes total when using the extended (“Long”) DDP header (599 total − 13-byte header = 586 payload). [2][3]

Sources: [1] RFC 1419, [2] Inside AppleTalk, [3] RFC 1378.

---

The web search returned AppleTalk DDP, not the lighting protocol. Let me search more specifically.

---

🌐 Web query:

DDP Distributed Display Protocol specification LED lighting packet size 1440

💡 Result:

In the LED lighting “DDP” (Distributed Display Protocol, 3waylabs) spec, the commonly cited maximum pixel payload per UDP packet is 1440 bytes (with a 10‑byte DDP header before the payload, or 14 bytes if the optional timecode field is present). (raw.githubusercontent.com)

Why 1440 bytes: it’s sized to stay efficient under a standard 1500‑byte Ethernet MTU (i.e., avoid IP fragmentation) and corresponds to 480 RGB pixels at 3 bytes/pixel (480 × 3 = 1440). (docs.ledfx.app)

Citations:

• 1: https://raw.githubusercontent.com/coral/ddp/master/DDPSPEC.md
• 2: https://docs.ledfx.app/en/v2.1.1/devices/ddp.html

---

@softhack007 — great question! The "4 packets max before push" assumption is not aligned with DDP spec for a 64×64 matrix. Here's the analysis:

---

DDP Packet Size (spec-compliant)

The DDP (Distributed Display Protocol, 3waylabs) spec defines a maximum pixel payload of 1440 bytes per UDP packet, sized to stay under the 1500-byte Ethernet MTU — corresponding to 480 RGB pixels per packet (480 × 3 = 1440 bytes).

---

Packets needed for 64×64 RGB

• 64 × 64 = 4,096 pixels × 3 bytes/pixel = 12,288 bytes of pixel data
• At 1440 bytes/packet: ⌈12,288 / 1440⌉ = 9 packets (minimum, spec-compliant)

So a full frame for a 64×64 RGB display requires at least 9 DDP packets before the final push packet.

---

The Problem with "4 packets max"

Looking at the relevant code in wled00/e131.cpp:

//reject late packets belonging to previous frame (assuming 4 packets max. before push)
if (e131SkipOutOfSequence && lastPushSeq) {
    int sn = p->sequenceNum & 0xF;  // 4-bit sequence number (values 1–15)
    if (sn) {
      if (lastPushSeq > 5) {
        if (sn > (lastPushSeq -5) && sn < lastPushSeq) return; // drops 4 slots before push
      } else {
        if (sn > (10 + lastPushSeq) || sn < lastPushSeq) return;
      }
    }
  }

The "forbidden zone" is 5 sequence slots before the push (i.e., "4 intermediate packets + push"). With a 9-packet frame (e.g., push at sn=9):

Sequence #	1	2	3	4	5	6	7	8	9 (push)
Status	❌ dropped as "previous frame"	❌ dropped	❌ dropped	❌ dropped	✅	✅	✅	✅	✅ push

Packets 1–4 would be incorrectly discarded as belonging to a prior frame, corrupting the LED output for any user with e131SkipOutOfSequence enabled and a display larger than roughly 32×21 RGB pixels (≈480 × 4/3 ≈ 640 pixels, i.e., 4 packets × 480 pixels/packet).

---

Summary

Display size	Pixels	Bytes	Packets needed	Fits in 4-packet assumption?
32×10 (320px)	320	960	1	✅
32×32 (1024px)	1,024	3,072	3	✅
64×32 (2048px)	2,048	6,144	5	❌
64×64 (4096px)	4,096	12,288	9	❌
128×64 (8192px)	8,192	24,576	18	❌ (exceeds 4-bit seq space)

The out-of-sequence window should be increased — ideally to at least 14 (the maximum non-push packets in a 4-bit sequence number space, 1–15). Alternatively, the sequence number field width needs revisiting for large displays.

Would you like me to open a GitHub issue to track this, or plan a fix?

---

🧠 Learnings used

Learnt from: DedeHai
Repo: wled/WLED PR: 4997
File: wled00/e131.cpp:33-44
Timestamp: 2025-10-10T18:34:06.550Z
Learning: In WLED's DDP packet handling (ws.cpp and e131.cpp), only prevent out-of-bounds memory access rather than enforcing DDP spec compliance. Don't check the 1440-byte spec limit—accept out-of-spec packets assuming correct encoding. The bounds check `maxDataIndex = c + numLeds * ddpChannelsPerLed; if (maxDataIndex > dataLen) reject` is sufficient and already covers the timecode flag case (when c=4) without needing separate validation.

---

Learnt from: netmindz
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2026-02-20T17:38:19.745Z
Learning: In WLED DDP packet handling (wled00/e131.cpp), the destination field should be validated to reject non-display packets. Packets with destination=DDP_ID_STATUS (251) or destination=DDP_ID_CONFIG (250) should be rejected and not processed as LED display data. Only packets with destination=DDP_ID_DISPLAY (1) should be accepted for LED output. WLED doesn't distinguish between multiple display IDs (e.g., display 1 vs display 2), but it must distinguish between DISPLAY packets versus STATUS/CONFIG packets.

[softhack007]

@coderabbitai extended question - how would our code handle frames that use more than 15 packets for a full frame? Would some packets be discarded as "duplicate", or would a full frame still be treated correctly, at least without "skip out of sequence"?

Is the 4bit sequence field part of the protocol specifications, or was it a wled design choice to only evaluate the lowest 4 bits?

[coderabbitai]

🧩 Analysis chain

Let me fetch the DDP spec and re-examine the relevant code.

Now let me read the specific DDP handling code in detail.

---

🏁 Script executed:

#!/bin/bash
# Read e131.cpp to check the DDP sequence number handling
fd "e131.cpp" --exec cat {}

Length of output: 24296

---

Let me confirm the DDP specification's definition of the sequence number field.

@softhack007 — great follow-up questions. Here are the answers:

---

1. Is the 4-bit sequence field from the DDP spec or a WLED design choice?

It is part of the DDP specification. The spec defines byte 1 as x x x x n n n n, where the upper nibble is reserved, and nnnn is the sequence number from 1–15, or zero if not used. The sequence number should be incremented with each new packet sent.

So WLED's p->sequenceNum & 0xF is spec-compliant. Importantly, the spec only defines 15 usable sequence slots (1–15), meaning a single frame is implicitly capped at 15 data packets + 1 push in the DDP protocol design itself. Frames with >15 data packets are outside the spec.

The spec also notes that a sender can send duplicate packets with the same sequence number for redundancy.

---

2. What happens with >15 packets per frame?

Without e131SkipOutOfSequence (normal mode)

The skip block is entirely bypassed. Tracing what happens if a sender sends packets with sequenceNum = 1, 2, … 20:

Sender's seq	sn after & 0xF	Effect
1 – 15	1 – 15	Processed normally, lastPushSeq updated
16	0	Processed (pixel data written), but if (sn) e131LastSequenceNumber[0] = sn is not executed — seq 0 means "not used" per spec, so lastPushSeq is not updated
17 – 20	1 – 4	Processed normally, lastPushSeq updated to 1, 2, 3, 4

No packets are dropped in this path. There is no duplicate-sequence filtering either — WLED just stores the last sn seen; it doesn't compare incoming sn against the stored value to reject reused sequence numbers. So all packets are processed, and the full frame is rendered correctly. The only side effect: before the first push packet is ever seen, e131NewData = true is set on every incoming packet (because !ddpSeenPush is true), potentially triggering partial-frame renders.

With e131SkipOutOfSequence enabled

As established in the prior analysis, this is already broken for large frames because the "forbidden zone" is hardcoded to only 5 slots before the push. With sequence number wraparound (e.g., sn=1 reappearing for packet #17 in a 20-packet frame), those late-wrapped packets may or may not land in the forbidden zone depending on where lastPushSeq sits — yielding unpredictable behaviour.

Regarding "duplicate" detection

There is no duplicate packet filtering in the non-skip-OOS code path. WLED will process every arriving packet. For idempotent pixel writes this is harmless — the same pixels just get written with the same values twice. But it means WLED has no protection against a sender repeatedly retransmitting the same packet for redundancy (which the spec explicitly allows), other than the slight CPU overhead.

---

Summary

Question	Answer
4-bit seq field — spec or WLED?	Spec-defined (x x x x n n n n, values 1–15, 0 = unused)
Max packets per frame (spec)	15 data + 1 push — the 4-bit field is the hard ceiling
>15 packets, without skip-OOS	All processed correctly, no drops, no duplicate filtering
>15 packets, with skip-OOS	Broken — as previously established; early wrapped-around packets may be incorrectly discarded
Duplicate packets (same sn, redundancy)	Not filtered — each packet processed independently

The upshot: e131SkipOutOfSequence is fundamentally at odds with the protocol's sequence number design for any display requiring more than ~4 packets per frame — and the DDP spec itself provides no mechanism to accommodate >15 packets in a single frame. The feature as implemented only reliably works for very small displays.

---

🧠 Learnings used

Learnt from: DedeHai
Repo: wled/WLED PR: 4997
File: wled00/e131.cpp:33-44
Timestamp: 2025-10-10T18:34:06.550Z
Learning: In WLED's DDP packet handling (ws.cpp and e131.cpp), only prevent out-of-bounds memory access rather than enforcing DDP spec compliance. Don't check the 1440-byte spec limit—accept out-of-spec packets assuming correct encoding. The bounds check `maxDataIndex = c + numLeds * ddpChannelsPerLed; if (maxDataIndex > dataLen) reject` is sufficient and already covers the timecode flag case (when c=4) without needing separate validation.

---

Learnt from: netmindz
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2026-02-20T17:38:19.745Z
Learning: In WLED DDP packet handling (wled00/e131.cpp), the destination field should be validated to reject non-display packets. Packets with destination=DDP_ID_STATUS (251) or destination=DDP_ID_CONFIG (250) should be rejected and not processed as LED display data. Only packets with destination=DDP_ID_DISPLAY (1) should be accepted for LED output. WLED doesn't distinguish between multiple display IDs (e.g., display 1 vs display 2), but it must distinguish between DISPLAY packets versus STATUS/CONFIG packets.

---

Learnt from: willmmiles
Repo: wled/WLED PR: 4859
File: usermods/udp_name_sync/udp_name_sync.cpp:62-70
Timestamp: 2025-08-21T00:00:17.196Z
Learning: In WLED codebase, UDP packet processing code must never rely on null termination being present on the wire and must always validate packet size first. The codebase already has some vulnerabilities where malformed data can crash the software, so avoiding introduction of new ones is a priority.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 4939
File: wled00/FX_fcn.cpp:1176-1187
Timestamp: 2025-09-16T18:08:42.848Z
Learning: In WLED finalizeInit() bus creation (wled00/FX_fcn.cpp), intentionally allowing memory overruns when bus configurations exceed MAX_LED_MEMORY is a deliberate design choice. The trade-off prioritizes creating buses with reduced LED counts over completely failing to create buses, which would cause no LED output and UI failures. This approach forces users to update configurations after migrating to version 0.16 while maintaining basic functionality.

---

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-12-28T14:06:48.772Z
Learning: In WLED post-commit ee9ac947, the rendering pipeline uses per-segment buffers and per-pixel bus updates. Unmapped (0xFFFF) mapping entries are now skipped in WS2812FX::show() (no “clear to black”), which can leave physical gap LEDs with stale/random colors unless they are explicitly cleared. This is a behavior change from pre-0.16 where a full physical buffer was effectively refreshed each frame.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2026-01-03T16:42:26.035Z
Learning: In WLED, both parallel I2S and single I2S modes require additional DMA buffers (4× the pixel buffer size). The memory calculation must account for which specific buses use I2S hardware, not just check digitalCount <= 8, because single I2S mode places the I2S bus at the END (ESP32 bus 8 with digitalCount=9, S2 bus 4 with digitalCount=5).

---

Learnt from: mval-sg
Repo: wled/WLED PR: 4876
File: wled00/xml.cpp:0-0
Timestamp: 2025-08-28T08:09:20.630Z
Learning: The WLED codebase has opportunities for refactoring hardcoded array bounds (like the "15" used for DMX channels) to use sizeof(array)/sizeof(array[0]) for more maintainable code, but such changes should be done consistently across the entire codebase in a dedicated refactoring effort.

---

Learnt from: mval-sg
Repo: wled/WLED PR: 4876
File: wled00/wled_eeprom.cpp:0-0
Timestamp: 2025-09-01T10:26:17.959Z
Learning: In WLED PR `#4876`, the DMXStartLED EEPROM backward compatibility issue was partially addressed by keeping it at address 2550 and reading it as a 16-bit value, with DMXChannelsValue array moved to addresses 2552-2566. This maintains compatibility with pre-0.11 EEPROM layouts for DMXStartLED, though legacy "Set to 255" (code 6) configurations may still need migration logic.

---

Learnt from: blazoncek
Repo: wled/WLED PR: 4995
File: wled00/FX.cpp:5223-5226
Timestamp: 2025-10-20T09:38:51.997Z
Learning: WLED matrices: each dimension (SEG_W, SEG_H) is limited to ≤255; 256 or larger per side is not supported/feasible on ESP32, so effects should assume per-dimension max 255.

---

Learnt from: BobLoeffler68
Repo: wled/WLED PR: 4891
File: wled00/FX.cpp:3333-3349
Timestamp: 2025-08-31T03:38:14.114Z
Learning: WLED PacMan effect (wled00/FX.cpp): Keep pacmancharacters_t position fields as signed int (not int16_t). Maintainer preference (blazoncek) prioritizes avoiding potential overhead/regressions over minor RAM savings. Avoid type shrinking here unless memory pressure is demonstrated.

[coderabbitai]

🧩 Analysis chain

Let me look up the DDP spec and re-examine the WLED code handling.

---

🏁 Script executed:

#!/bin/bash
# Get the full DDP handling section of e131.cpp
fd "e131.cpp" --exec cat {}

Length of output: 24296

---

🏁 Script executed:

#!/bin/bash
# Get the full DDP handling section of e131.cpp
fd "e131.cpp" --exec cat {}

Length of output: 24296

---

🏁 Script executed:

#!/bin/bash
fd "e131.cpp" --exec cat {}

Length of output: 24296

---

🌐 Web query:

DDP Distributed Display Protocol specification sequence number field size bits 3waylabs

💡 Result:

In 3waylabs’ Distributed Display Protocol (DDP), the sequence number is 4 bits wide (a nibble), so it can represent values 0–15. Implementations typically store/transmit it in a full byte, but only the low 4 bits are used, and the value wraps after 15. [1], [2]

Sources:
[1] OpenRGB DDP implementation notes (states “Sequence numbers use 4-bit nibble (0-15) per DDP spec”) — (gitlab.com)
[2] ddp-rs implementation (sequence number handled as 1..=15, wraps after 15) — (docs.rs)

Citations:

• 1: https://gitlab.com/CalcProgrammer1/OpenRGB/-/merge_requests/2867?utm_source=openai
• 2: https://docs.rs/crate/ddp-rs/1.0.0/source/src/connection.rs

---

@softhack007 — great follow-up questions! Here's the detailed analysis:

---

Q1: Frames with >15 packets

Without e131SkipOutOfSequence (the normal path)

The sequence/out-of-order check block is entirely skipped. Tracing through handleDDPPacket():

1. Pixel writes happen unconditionally — the for loop over setRealtimePixel() runs for every received packet regardless of sequence number.
2. Rendering (e131NewData = true) fires only in the if (!ddpSeenPush || push) block — meaning, once in DDP mode (ddpSeenPush = true), only the push packet triggers a display update.
3. e131LastSequenceNumber[0] is only updated inside that same if (!ddpSeenPush || push) block.

Result: A full frame with any number of packets is handled correctly. ✅ Every packet writes its pixel slice, the push triggers rendering. No packets are dropped.

With e131SkipOutOfSequence + sequence wrapping

Since the spec only allows seq 1–15 (4 bits), a sender of >15 packets must either:

• Set seq=0 (disable sequencing) — safe, WLED skips the check via if (sn), everything works ✅
• Wrap the counter (1…15, then 1…N) — this is where it gets problematic ❌

If the sender wraps and the push packet of the previous frame happened to be at e.g. seq=3, then for the new frame's early packets: lastPushSeq=3, condition becomes sn > (10+3) || sn < 3, which drops seq 1 and 2 as "late from previous frame". The corrupted pixel slots never get updated until the next frame.

"Duplicate" detection?

WLED does not implement back-to-back duplicate suppression. If a sender sends a packet twice with the same sequence number (redundancy as the spec allows), WLED will process both, writing the same pixel data twice — harmless, just slightly wasteful.

---

Q2: Is the 4-bit masking per spec or a WLED design choice?

This is 100% per the official DDP spec from 3waylabs. The spec defines byte 1 explicitly as:

x x x x n n n n — nnnn: sequence number from 1–15, or zero if not used; the sequence number should be incremented with each new packet sent.

A receiver can ignore duplicates received back-to-back, and the sequence number is ignored if zero.

WLED's p->sequenceNum & 0xF correctly masks to the lower nibble as the spec dictates. The sequenceNum field in the e131_packet_t struct is likely stored as a full byte on the wire, but the spec mandates only the lower 4 bits carry the sequence value.

---

Summary

Scenario	Behavior
>15 packets, e131SkipOutOfSequence off	✅ Works correctly, all packets processed
>15 packets, e131SkipOutOfSequence on, sender uses seq=0	✅ Works correctly, sequencing skipped
>15 packets, e131SkipOutOfSequence on, sender wraps seq	❌ Early wrap packets may be dropped as "late from previous frame"
Duplicate packets (same seq, per spec redundancy)	✅ Processed twice, harmless
& 0xF masking	✅ Spec-defined 4-bit nibble, not a WLED design choice

The practical conclusion: e131SkipOutOfSequence is effectively broken for any frame requiring >15 packets unless the sender uses seq=0 to opt out of sequence tracking entirely.

---

🧠 Learnings used

Learnt from: DedeHai
Repo: wled/WLED PR: 4997
File: wled00/e131.cpp:33-44
Timestamp: 2025-10-10T18:34:06.550Z
Learning: In WLED's DDP packet handling (ws.cpp and e131.cpp), only prevent out-of-bounds memory access rather than enforcing DDP spec compliance. Don't check the 1440-byte spec limit—accept out-of-spec packets assuming correct encoding. The bounds check `maxDataIndex = c + numLeds * ddpChannelsPerLed; if (maxDataIndex > dataLen) reject` is sufficient and already covers the timecode flag case (when c=4) without needing separate validation.

---

Learnt from: netmindz
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2026-02-20T17:38:19.745Z
Learning: In WLED DDP packet handling (wled00/e131.cpp), the destination field should be validated to reject non-display packets. Packets with destination=DDP_ID_STATUS (251) or destination=DDP_ID_CONFIG (250) should be rejected and not processed as LED display data. Only packets with destination=DDP_ID_DISPLAY (1) should be accepted for LED output. WLED doesn't distinguish between multiple display IDs (e.g., display 1 vs display 2), but it must distinguish between DISPLAY packets versus STATUS/CONFIG packets.

---

Learnt from: willmmiles
Repo: wled/WLED PR: 4859
File: usermods/udp_name_sync/udp_name_sync.cpp:62-70
Timestamp: 2025-08-21T00:00:17.196Z
Learning: In WLED codebase, UDP packet processing code must never rely on null termination being present on the wire and must always validate packet size first. The codebase already has some vulnerabilities where malformed data can crash the software, so avoiding introduction of new ones is a priority.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 4939
File: wled00/FX_fcn.cpp:1176-1187
Timestamp: 2025-09-16T18:08:42.848Z
Learning: In WLED finalizeInit() bus creation (wled00/FX_fcn.cpp), intentionally allowing memory overruns when bus configurations exceed MAX_LED_MEMORY is a deliberate design choice. The trade-off prioritizes creating buses with reduced LED counts over completely failing to create buses, which would cause no LED output and UI failures. This approach forces users to update configurations after migrating to version 0.16 while maintaining basic functionality.

---

Learnt from: softhack007
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2025-12-28T14:06:48.772Z
Learning: In WLED post-commit ee9ac947, the rendering pipeline uses per-segment buffers and per-pixel bus updates. Unmapped (0xFFFF) mapping entries are now skipped in WS2812FX::show() (no “clear to black”), which can leave physical gap LEDs with stale/random colors unless they are explicitly cleared. This is a behavior change from pre-0.16 where a full physical buffer was effectively refreshed each frame.

---

Learnt from: DedeHai
Repo: wled/WLED PR: 0
File: :0-0
Timestamp: 2026-01-03T16:42:26.035Z
Learning: In WLED, both parallel I2S and single I2S modes require additional DMA buffers (4× the pixel buffer size). The memory calculation must account for which specific buses use I2S hardware, not just check digitalCount <= 8, because single I2S mode places the I2S bus at the END (ESP32 bus 8 with digitalCount=9, S2 bus 4 with digitalCount=5).

---

Learnt from: mval-sg
Repo: wled/WLED PR: 4876
File: wled00/xml.cpp:0-0
Timestamp: 2025-08-28T08:09:20.630Z
Learning: The WLED codebase has opportunities for refactoring hardcoded array bounds (like the "15" used for DMX channels) to use sizeof(array)/sizeof(array[0]) for more maintainable code, but such changes should be done consistently across the entire codebase in a dedicated refactoring effort.

---

Learnt from: mval-sg
Repo: wled/WLED PR: 4876
File: wled00/wled_eeprom.cpp:0-0
Timestamp: 2025-09-01T10:26:17.959Z
Learning: In WLED PR `#4876`, the DMXStartLED EEPROM backward compatibility issue was partially addressed by keeping it at address 2550 and reading it as a 16-bit value, with DMXChannelsValue array moved to addresses 2552-2566. This maintains compatibility with pre-0.11 EEPROM layouts for DMXStartLED, though legacy "Set to 255" (code 6) configurations may still need migration logic.

---

Learnt from: blazoncek
Repo: wled/WLED PR: 4995
File: wled00/FX.cpp:5223-5226
Timestamp: 2025-10-20T09:38:51.997Z
Learning: WLED matrices: each dimension (SEG_W, SEG_H) is limited to ≤255; 256 or larger per side is not supported/feasible on ESP32, so effects should assume per-dimension max 255.

---

Learnt from: BobLoeffler68
Repo: wled/WLED PR: 4891
File: wled00/FX.cpp:3333-3349
Timestamp: 2025-08-31T03:38:14.114Z
Learning: WLED PacMan effect (wled00/FX.cpp): Keep pacmancharacters_t position fields as signed int (not int16_t). Maintainer preference (blazoncek) prioritizes avoiding potential overhead/regressions over minor RAM savings. Avoid type shrinking here unless memory pressure is demonstrated.