I recently got quite interested in having a portable external monitor, after using a ThinkVision M14 for a while (Dell has a very similar product too). It’s connected through a single Type-C cable, but unfortunately just 1080p at 16:9, which kinda pales in comparison to the Framework’s internal display. There’s a newer M14d (16:10, 2K), but I quickly realized this would be a great usecase for re-using a Framework’s Display Kit, Top Cover and possibly hinges, with supporting electronics hidden away in a (3d-printed) base.
Browsing around the Community forum the idea isn’t exactly new, especially since the recent DIY Perks video. I’m still in the research phase, compiling existing info and looking at options for a new design. Hoping this can serve as a useful overview from 3 days of trawling the forum, AliExpress, and P/D controller datasheets, and with (community) feedback, hopefully resulting in A USB-C to eDP board to interface the Display Kit.
Going through Framework - HDMI controller board for display panel
and AliExpress myself I started with an overview of the existing options here:
Existing driver boards / dongle solutions
Framework LCD: NE135FBM-N41 (13.5", 3:2, 2256×1504)
Laptop / display kit comes with custom eDP cable (different pinout), needs to be removed on the LCD panel side.
Framework Display Kit (€195.00)
Includes LCD panel, custom eDP cable, and aluminium mounting brackets for Framework top covers
AliExpress has (‘compatible’) LCD panels from ~ €70 euros. Same panel is used for the Acer Swift 3 and Acer Chromebook CP713-2W.
Screen needs 0.5mm pitch eDP cable. Lots of different driver boards, not everything supports 2K/4K, USB-C is only used for power
ESP-All Store dp edp 4k 120hz PD DIY driver board For portable display screen (€38.05)
Power: Type-C socket, Video: DisplayPort
Slightly smaller, separate board with ribbon cable for control buttons
! does not include eDP cable !
Nvarcher mini 4K EDP driver board with screen (€49.21)
Power, Video: Type-C plug
Smallest board, OLED that displays P/D power for some reason, reported to get very hot which possibly also breaks it
Nvarcher Audio Store
Framework is looking for this too, and happy to provide some funding + display kits link
- IPEX 20879-040E connector instead of ‘normal’ 40 pin eDP so you can use the cable that comes with the Display kit
- Open source firmware
- USB-C receptacle instead of plug, which is also the biggest issue with current driver options. Plug is either attached to driver or splitting dock, having a socket would make integration into a base much nicer
Unfortunately I can’t find any options with Type-C socket, only Type-C plug as attached cable. Both types available from various sellers.
Type-C to DisplayPort Smart docking station, 100W (€12.95)
Type-C Dock Station 3 in 1, 60W (€6.10) USB 2.0 port at 90 degree angle
For use with my desktop I’m considering adding a DP splitter (2 sources, LCD as sink), so my Framework can use the screen through just Type-C (power and video), and have a dedicated DisplayPort socket for my desktop (still using the Type-C for power).
Needs 5V power (Type-C socket), probably easiest to get from the other splitter’s USB 2.0 port.
Not really satisfied with cobbling together a driver board and various adapters, and realizing Framework was also looking for a better driver board I decided to do more research in that direction.
I’m kinda out of my depth here, having designed simpler USB-C boards in KiCad before (5v, USB2.0) but not familiar with all the added complexity of P/D signalling for more power (not technically needed here) and DisplayPort negotiation (definitely needed here).
Any driver board design I end up with should be useable for other people’s projects (Open Hardware), and serve as the internals for my external portable monitor.
The Framework display is connected through an IPEX 20879-040E with a custom pinout [edit: fixed pinout info link].
LCD Panel datasheet (NOTE: LCD-panel-side pinout is different from Framework’s cable pinout on the driver side!)
To drive it we need:
- 4 lanes of (normal) DisplayPort signal (so can’t be combined with USB3.0 unfortunately)
- DisplayPort AUX / Hotplug detection lines
- 5-21 V for the backlight (12V typical)
- 3.3v ~202mA power for the LCD controller
- (optionally?) a PWM driver for backlight brightness control.
The hard part is USB-C P/D negotation for the DisplayPort alt-mode. Needs something to talk the P/D protocol over the CC lines, more on this later. Given the backlight runs fine on 5V, and the most common use-case where the display driver connects directly to a (Framework) laptop, there’s not much need for negotiating a higher voltage power profile.
Note: the ThinkVision M14 has 2 Type-C ports and can do power passthrough to the laptop when connected to an external power adapter, but it’s not too useful in practice, easier to charge the laptop directly, and everything is much easier when only dealing with a single Type-C port.
Backlight power is very flexible along the whole P/D PDO range, needs 2.9W at 12V (LED driver efficiency at other voltages unknown). As the LCD default state is ‘transparent’, we need to make sure the backlight only turns on after the LCD controller is ready (LCD datasheet section 8.0 POWER SEQUENCE).
3.3v can be a simple buck converter from whatever the USB-C VBUS voltage turns out to be. Some P/D controller chips already use one internally and expose it, have to check ratings though.
PWM signal is used for brightness control, haven’t looked too much into this yet.
Framework mainboard schematics references G516A1Y51U_TSOT23-8 but I haven’t been able to find more information on that chip. The Adafruit Qualia LCD driver uses an ATtiny85 with basic code for this which also nicely stores the settings in EEPROM, so it’s restored on power-on. Could be used with tiny adaptation as our LCD max PWM frequency is 2Khz instead of 4.
This is really the crux of the project, and what makes it different from existing driver boards.
There’s a whole mess of different approaches, with various divisions of responsibility between hardware, firmware and software.
DisplayPort is an alternate mode of the Type-C standard, which means both the DFP host (laptop) and UFP (driver board) have to actively communicate over the CC lines, to figure out they both support the specific alt-mode ‘DisplayPort’, and want to switch to it. Once negotiated, multiple pins on the USB-C connector are re-purposed to DisplayPort lanes.
So on the driver board we need: (insert block-diagram sometime)
USB Type-C receptacle
Cable plugs in and connects to laptop on the other end
Type-C P/D PHY port controller
Manages low-level P/D protocol communication, which has sensitive timing.
Usually controlled through I2C with the standardized Type-C Port Controller interface (TCPCi) specification.
Data MUX / Crosspoint switch
Since the connector is reversible, the data pins (DP lanes) have to be swapped when the cable is in ‘flipped’ orientation. As @Arya mentions:
what’s the difference between USB and SBU anyway
Nice to haves:
Accounts for signal loss/degradation on the cable and the board.
If the cable/DFP doesn’t support DisplayPort or any of the USB3.1 lines at all, this chip can communicate as a USB 2.0 device, informing the host, and in turn the user, that this UFP supports DisplayPort, but they have to use a different cable or port on their device (the latter is not an issue on the Framework, since all Type-C ports support DP there).
@Arya started on a specific implementation for Mainboard replacement purposes post.
This design uses her Altmode Friend module which in turn uses a FUSB302 P/D PHY, controlled by a RP2040 microcontroller. Basic software is available for PDO negotiation, but seemingly no alt-modes yet (although this is planned). A VL170 (HD3SS460 clone?) alt-mode capable MUX.
Firmware: RP2040 Python I2C code for TCPCi communication (power only)
Basically does what’s needed here, and is of course known to be compatible with the Framework.
From photo reference it uses an Infineon CCG3 CYPD3120-40LQXI, which seems to come pre-programmed for the ‘Dongle’ application, and has a reference design for Type-C to DP adapters.
New firmware can be generated with their “EZ-PD” software. Unclear if the Expansion Card uses this pre-flashed firmware, but there is a beta firmware flashing exe for better power management Thread.
Firmware: EZ-PD Configuration Utility
FUSB302 seems quite popular in P/D related designs,
STM32 has X-CUBE blocks (X-CUBE-USB-PD) for P/D related tasks, including DisplayPort alt-modes. These can be used all-in-one with STM32 microcontrollers that have an integrated ‘UCPD controller’ bit, or combined with any other TCPCi-compatible PHY.
Firmware: STM32Cube ecosystem, X-CUBE-USB-PD
TI has a wide selection of Type-C related chips and reference designs, with TCPCi controllable PHY’s (TUSB422, TUSB320) and more stand-alone controllers that have a PHY and built-in digital core (TPS65987D). The latter can usually also directly control an attached MUX.
TPS65987D can be configured through I2C at runtime (external microcontroller), or flashed with their own tooling (TPS6598X-CONFIG), enabling DP alt mode and other behavior.
Firmware: TCPCi, TPS6598X-CONFIG Windows GUI
GitHub - MicrochipTech/usb-pd-software-framework: Microchip's Lightweight USB Power Delivery Software Stack, DisplayPort In development, designed for UPD350/UPD301C both of which are not recommended for new designs.
Unfortunately most (open source) implementations of TCPCi only focus on power, with no support for alt-mode switching.
Chromium EC code (dingdong)
https://www.chromium.org/chromium-os/dingdong/ uses the Chromium OS EC for DisplayPort alt-mode on an STM32F072
graycatlabs/usb-c-arduino, based on Chromium EC code, actual Arduino code example is very limited but might be useable when cross-referenced with dingdong.
It’s unclear how much FUSB302 libraries differ from the plain TCPCi protocol, datasheet only mentions PD2.0 and no TCPC.
Altmode Friend software in Python for the RP2040, currently no alt-mode but is planned.
I’d prefer a (combination) of IC’s that just works for this purpose, without additional software/firmware configuration. I haven’t been able to find anything like this though,
so the next best thing is an open source software stack to run on a generic microcontroller. FUSB302 seems most commonly used for this, but a generic TCPCi implementation would work with a broader range of PHY’s.
I’d also like to get as much of the board as possible assembled through JLCPCB SMT, but the IPEX 20879-040E already seems hard to source in general (Digi-Key). The on-going chip shortages are fun too…