That’s interesting, I would have though they’d use just a regular usb to serial converter but could be they use the serial port stright off the cpu. The chip on there is likely a level shifter to make it propper rs232 port or just some additional protection.
From what it looked in the video the embedded controller had to be involved at least a little bit since it rerouted keyboard and touchpad input to the device. That part is probably harder to replicated without mainboard changes in the framework. I think a software solution would be the better solution there. We’d basically just need some software that captures input like a virtual machine or kvm would and something like a rp2040 getting those and acting like a mouse and keyboard for the other device.
The thing under the shield is still very likely a generic capture card. Maybe you could learn more if you plug it in and look at the device id’s and manufacturer and stuff in device manager. The visible chips in the cutouts on the shield are flash chips, one is probably to hold the configuration for the capture card chip, not quite sure what the 2. one would be for (maybe for the thing that takes the commands from the ec and acts ad a mouse/kb?).
It is a bit hard to see scale from this but the kvm module looks a bit bigger than a framework module right? We might need to split the capture card and mouse/kb emulator part.
Edit: I just remembered the framework has an open source ec so we could technically add the kb/mouse forwarding there but we’d need some way for the ec to talk to the expansion card and it would also only work on the 13 because on the 16 the keyboard at least is not on the ec. Anyway, the software solution would allow you to use both the laptop and the external device which I imo find more useful than the way gpd did it where it apparently just grabs the kb/mouse if something is plugged in.