[BUILD LOG] FW13 + Dual ASUS ZenBook Duo OLED Panels - Custom Chassis, Custom PCB, Daily Driver

Creators & Developers
1

Hey Framework community

I’m a student working on what I think might be one of the more ambitious FW13 builds attempted so far, a custom dual-screen laptop using the Framework 13 mainboard and both OLED panels from the ASUS ZenBook Duo UX8406 (panel model: ATNA40CU09-0), housed in a 3D-printed chassis I’m designing from scratch. I want to use this as my actual daily driver at school — not just a shelf piece.

I’m early in the build (planning + early prototyping) and I’m posting here to document the journey, get feedback from people smarter than me, and hopefully connect with others who’ve done similar things.

Why Framework?

The FW13 mainboard is genuinely the only platform that made this project possible for someone like me. The published CAD files, the documented eDP pinout, the open expansion card ecosystem, I’d be flying blind without that. Framework’s philosophy of making hardware hackable is exactly what this build is built on.

The Vision

A dual 14" 2880×1800 @ 120Hz OLED laptop in a custom PAHT-CF printed chassis, running off a Framework 13 Intel Core Ultra 7 385H mainboard or AMD Ryzen AI 7 350. One screen on top (standard laptop position), one on the keyboard deck (ZenBook Duo style). Meant to take a dual screen setup almost anywhere every day.

Target use cases:

  • At school/work: both displays active, no peripherals, fully self-contained

  • At home/work: docked to a TB4/5 dock with external monitors; internal panels off

The Tricky Part: Dual OLED Display Drive + Power

This is where it gets interesting (and where I’d love the most feedback).

The FW13’s internal eDP connector is LCD-only in its pinout, the backlight power pins mean it’s not directly usable with the ATNA40CU09-0, which is OLED. So both panels need to be driven externally.

Port allocation for Ryzen AI 7 350:

  • Ports 1 & 3 (USB4 UHBR20) → kept free for TB4/5 dock at home

  • Port 2 (DP 1.4a HBR3, ~25.9 Gbps) → Panel 1 via custom PCB

  • Port 4 (DP 2.0 UHBR10, ~38.7 Gbps) → Panel 2 via custom PCB

Port allocation for Core Ultra X7 385H:

  • Ports 1 & 3 (Thunderbolt 4 UHBR20) → kept free for TB4/5 dock at home/work and other expansion cards

  • Port 2 (DP 2.1 UHBR20, ~25.9 Gbps) → Panel 1 via custom PCB

  • Port 4 (DP 2.1 UHBR20, ~38.7 Gbps) → Panel 2 via custom PCB

Each panel needs ~18.7 Gbps, so both ports have plenty of headroom without DSC.

Custom PCB plan (this is the big one):

Rather than two separate off-the-shelf driver boards, I’m designing a single shared PCB that both USB-C ports feed into:

  • PD negotiation: CH224K per port (negotiates 5V/3A on port 2 as primary)

  • DP Alt Mode → eDP bridge: RTD2173N per panel (DP 1.4 in, eDP 1.4 out, up to 4K)

  • Boost converter: TPS61088 (5V → 10V VBAT for OLED panels)

  • OLED power sequencing: RC delay + MOSFET gate to ensure VDD (3.3V) stabilizes before VBAT (10V), possibly a TPS3619

Power math:

  • Each panel: ~7W typical (2W VDD + ~5W VBAT)

  • Two panels: ~14W + ~1.5W converter losses = ~15.5W

  • Available at school or on the go (no dock, ports 2+4): 15W + 7.5W = 22.5W → comfortable headroom

  • At home/work (dock on port 1 or 3): panels are off anyway

Where I Am Now

  • Port allocation and power budget worked out

  • Panel confirmed (ATNA40CU09-0 specs verified)

  • Parts list drafted (~$1,884, note that I already have some parts )

  • PCB schematic in progress (KiCad)

  • Chassis CAD started (working off Framework’s published drawings)

  • OLED power sequencing needs validation before committing to layout

Questions for the Community

  1. Has anyone successfully driven an OLED panel (specifically one that uses ELVDD/ELVSS rails) from a custom eDP board? The full ATNA40CU09-0 datasheet is NDA-locked. Any tips on inferring the power sequencing from similar Samsung OLED panels or does someone happen to have it?

  2. Does anyone know a way for one port to deliver around 20W, that way I would be able have three free ports rather than

  3. For the chassis: anyone printed structural laptop parts in PAHT-CF on a Bambulab Printer? Curious about real-world rigidity for a hinged dual-screen form factor.

  4. Is there anyone here with hardware or sponsorship connections who’d be interested in supporting a documented, fully open build log? Happy to credit and post all CAD + KiCad files publicly when done.

Why I’m Doing This

I want to build something real that I actually use, not just a demo. I think the best way to show I can work in hardware is to make hardware work. Framework’s ethics of repairability and openness is exactly what I want to be part of someday. I want to create a dual screen laptop that only Lenovo and ASUS have made and add the repairability/upgradability of a Framework Laptop

I’ll keep this thread updated (Hopefully) as the build progresses. All files will be posted publicly when ready.

Thanks for reading, any feedback, warnings, or “don’t do that” advice is very welcomed.

(Sorry for the long read)

IMG_8261
IMG_8261480×640 60.4 KB

7 Likes
4k HDR display?
2

From what I’ve seen stated in the past from Framework staff, you can’t get that much. Haven’t run across anyone finding a way to get more out of the ports beyond their set limits.

Since you’re already doing a custom board and boosting voltages there, have you considered trying to tap into the battery power?

3

Thanks for the suggestion. I actually did consider tapping the battery early on, but ran into a couple of problems.

First, the output regulation, the FW13 pack is a 2S Li-ion, so the voltage swings from ~8.4V at full charge down to ~6V when depleted. I’d still need a boost converter to hit the panel’s stable 10V VBAT rail regardless, which adds circuitry on top of an already complex custom PCB. Second, and more practically, the battery connector on the FW13 is recessed into the chassis, running a tap cable off it is physically awkward, and more importantly, I’m worried about affecting the power delivery to the mainboard itself. Splitting current from that connector without proper isolation could cause instability I really don’t want to debug.

That said, the two-port USB PD approach actually solves the headroom problem already. At school (no dock), ports 2 and 4 are the only PD negotiators active, one wins 3A, the other gets 1.5A, giving me 15W + 7.5W = 22.5W total. My two OLED panels need ~15.5W including boost converter losses, so there’s ~7W of headroom without touching the battery at all. Then again, it takes up one more port.

The only scenario where battery power would genuinely help (and safely) is running both panels while docked, but in that use case the panels are off anyway, so it’s a non-issue.

4

It is 4s not 2s.

If you are allready doing custom stuff probably best to grabb whatever power you need from the edp connector and regulate as needed.

That is a really big flat pert to print, there may be warping issues. Also you may want to consider cf-core filaments are fiber filled filaments are not awesome for skin contact.

1 Like
5

Painting it to seal any exposed fiber bits?

6

Or that, but fiber core filaments give you the best of both sides at the cost of well cost. You get the better layer adhesion and no fibers on the surface of fiber-less filaments with the anti warping properties of having fibers.

2 Likes
7

Really appreciate the corrections and advice!

@Adrian_Joachim good catch on the 4S, that was my mistake. 16.8V-> ~12V range actually makes a battery tap more appealing than I thought, a buck converter to 10V VBAT would be cleaner and more efficient than boosting from 5V. On top of that, looking at the published eDP pinout, Pins 36–39 are BL_POWER rated 5–21V, which actually covers the 10V VBAT rail directly, and pins 18–21 supply 3.3V for VDD. The open question is current capacity on those BL_POWER pins, do you know if that’s documented anywhere? If it’s sufficient, that frees up a port which would be free for day to day use.

On the PAHT-CF concerns, the warping on a large flat chassis piece is something I was already nervous about, and the skin contact issue honestly hadn’t crossed my mind. Fiber-core filament sounds like exactly the right call. Do you have a brand/product you’d recommend for something this structural?

8

BL_POWER is likely just straight vbus. Doubt there is any official documentation on how much you can draw from there but you could look up how much current that connector is rated for per pin and calculate from there. You need less than 2A at worst for your 20w but the pins are really small so idk. Either way vbus is not a constant voltage so you are going to need regulators behind it anyway. Still probably easier than needing to figure out which port got the 3a limit and which the 1.5A and doing the limiting per port based on that.

I have been trying to get my hands on the sirayatech stuff but have not actually tried it myself. According to the mytechfun tests the core version are pretty much universally better than full fiber or no fiber.

9

Good to know on the VBUS point, so I’d still need a buck regulator behind it to stabilize at 10V, but I dug into the per-pin current rating on the IPEX 20455-040E, at AWG 40 the connector is rated 0.3A per pin, so 4 BL_POWER pins in parallel gives a 1.2A ceiling = 12W max at the connector level, before Framework’s backlight driver IC imposes its own limit. That’s actually less than my worst-case USB PD scenario (7.5W + 7.5W = 15W), so the USB PD approach wins on both power and certainty, the eDP path just isn’t rated highly enough to make it worth the added unknowns. Worth noting too that the display data ports 4 are also the power source via PD negotiation, both functions run over the same USB-C connection, so no extra ports are consumed just for power.

And thanks for the Sirayatech tip, I’ll check out the mytechfun comparison before ordering. Fiber-core it is.

10

I am 90% sure there is no backlight driver on the mainboard. Afaik, the backlight driver is part of the display, all the mainboard provides is power, enable and a pwm signal to tell it how bright it should be, the led driver is on the display. With oleds it can be both, there are some that have it on the display and some that expect the mainboard to do it (cause oleds themselves can be thin enough that the circuitry would actually increase the thickness to it makes sense to offload it to the mainboard)

1 Like
11

Good correction on the backlight driver, that actually simplifies things on the eDP side. So the BL_POWER ceiling is just the connector rating: 0.3A × 4 pins = 1.2A = 12W at 10V, no hidden IC limiting it.

That said, factoring in PCB overhead has actually made me reconsider the overall power budget. The two RTD2173N bridge chips add roughly 1.5–2W on top of the ~15.5W the panels need, pushing the real requirement to around 17–17.5W. At worst case USB PD (7.5W + 7.5W = 15W), that’s no longer enough, I’d be depending on winning the 3A negotiation to get 22.5W, which is likely but not guaranteed.

I’m now thinking a combined approach might be the cleanest solution ,draw from both USB PD and the eDP connector simultaneously. USB PD handles VBAT and PCB logic, while the eDP VDD pins (3.3V, 4 pins, up to ~4W) supplement the budget and take pressure off the PD side. Together that’s a comfortable margin even at worst-case PD, without depending on winning the 3A negotiation. The BL_POWER path could also contribute on top of that if needed. Would that be worth the added complexity of managing two power inputs on the PCB, or is there a cleaner solution I’m missing?

12

Not betting on getting the 3A port is certainly a good idea. You could also cap the max brightness wit decreasing vbus to stay in the envelope of the 7W (I would de-rate the usb a bit because ocp on framework usb ports is extremely twitchy) + whatever you get from ~1A off the edp connector (and maybe a little bit from 3.3 but I would not go too hard there).

Since you kinda have to use at least one of the usb port for the second display (don’t think mst hubs work with edp but I may be wrong. may not be enough bandwidth even if it did anyway) it would be a waste not to use the power you get from there.

13

The OCP warning is really useful, I’ll de-rate the USB side and not design right up to the 7.5W limit. The combined approach is looking like the right call then: de-rated USB PD for VBAT and PCB logic, ~1A from BL_POWER as a supplement, and just a touch from VDD without pushing it. That should give comfortable headroom without gambling on the 3A negotiation.

And yeah, two separate USB-C ports for the displays was always the plan, one port per panel, each carrying both signal and power. Good to have confirmation that MST to eDP isn’t a viable shortcut.

14

You could done of the edp and one off usb, wasting 2 of the ports just for displays seems a bit excessive.

This was just a guess, I have no idea if it actually doesn’t work it’s just not very likely imo.

1 Like
15

The eDP + one USB idea was actually my first instinct too, but the FW13’s internal eDP connector has an LCD-specific pinout, the backlight power and PWM control pins don’t map to what an OLED expects, so I can’t drive a display signal through it directly. That’s why both display signals need to go over USB. That said, I’m still planning to tap the eDP connector’s BL_POWER and 3V_EDP pins for supplemental power to the PCB, so it’s not going to waste entirely, just not carrying a display signal.

And fair enough on the MST clarification, good to know it’s an open question rather than a hard no. Probably not worth chasing given the bandwidth constraints anyway.

16

It’s less lcd speciffic and more just not oled speciffic, not like usb-c gives you the oled power rail driver fro free eiter. Again with lcds they put the backlight drivers on the display because that amde them more versatile and it didn’t hurt as the display itself was thicker than the required pcb but with oleds that is not the case anymore so newer oleds that weren’t designed as drop in replacements for lcd panels expect something else to do power conversion for them.

The edp connector still gives you more than usb-c though like a direct signal for the desired internal display brightness (I would use that for both displays) and enable pins (make sure to check about 1.8 vs 3.3V signals though but level shifting is easy). You also get the displayport lines without any negotiation.

You’ll have to provide the +/- bl supply yourself either way, neither edp or usb-c are going to give you those but you can probably share them between the displays if you are ok with them being the same brightness all the time (you can still have separate enables if you want to turn off one of them sometimes).

17

Good correction, “not OLED-specific” is the more accurate framing, fair point. The brightness sharing idea is actually really elegant for this use case, same brightness on both panels is fine, and having separate enables is all I’d need to manage them independently. I’ll check the 1.8V vs 3.3V signal levels before assuming compatibility, but level shifting is straightforward enough.

The DP lines without negotiation is the part I want to think about more, if I can drive one panel directly from the eDP signal path it would simplify half the PCB significantly. That would mean one RTD2173N instead of two. Is there anything specific I should watch out for going that route?

18

The dp stuff is the easy part, apart from the whole signal integrity bit. Just connect the differential pairs.

Imo providing the oleds with all their weird power rails is probably going to be the hardest part cause that is the most exotic bit.

My oled pannel didn’t survive me just straight plugging it into an lcd cable so I never got much further than that (the t480s survived with some somewhat repairable injuries XD)

19

That’s a sobering real-world warning, really appreciate you sharing it. The OLED power rails are definitely what I’m most nervous about too, especially since the full ATNA40CU09-0 datasheet is NDA-locked. Without knowing the exact ELVDD/ELVSS requirements and power-on sequencing I’m essentially inferring from similar Samsung OLED panels that i don’t have, which leaves room for expensive mistakes.

My current plan is to get the datasheet from Panelook before I finish the PCB layout. Only problem is that the display I have is the same model (ATNA40CU09-0), mine is touchscreen and the one on panelook isn’t. Do you know if there’s any good community documentation on OLED power rail requirements for panels like this, or is it mostly trial and error without the datasheet?

Dual Screen Framework 13 in our near future?
20

Some parts of how you write make my ai senses tingle even if I am relatively sure you are not.

My plan was using a chinesium breakout board for my panel and reverse engineer how the power rails work from there, turns out the panel took the whole plugging into my t480s operation even less well than the laptop so that was a bust. The datasheet alone may not be the best as the one I found for my samsung panel looked like it was full of copy paste errors and conflicting information, seeing one no wonder they only give them out under nda XD