# Framework Laptop 16 upgrades and a preview of the OCuLink Dev Kit

**URL:** <https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952>\
**Category:** Blog\
**Tags:** news\
**Created:** [April 21, 2026, 6:26pm UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952 "2026-04-21T18:26:35Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![Howard](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/howard/32/16823_2.png) [@Howard](https://community.frame.work/u/Howard)\
**Post date:** [April 23, 2026, 8:39pm UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/21 "2026-04-23T20:39:50Z")

</div>

I’d even take a touchpadless single piece palm rest, I’m usually using a mouse anyway.

And honestly this modular stuff was nonsense to begin with, should have been fixed with numpad for the 16, like a big version of the 13. That’d give room for taller modules, a laptop this size needing to grow a tumor for an Ethernet port is absurd.

---

<div class="post-metadata">

**Author:** ![Per\_Magnus\_Tveten](https://avatars.discourse-cdn.com/v4/letter/p/b9bd4f/32.png) [@Per\_Magnus\_Tveten](https://community.frame.work/u/Per_Magnus_Tveten)\
**Post date:** [April 24, 2026, 4:43am UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/22 "2026-04-24T04:43:19Z")

</div>

I would not like it at all if the keyboard had a fixed number pad on the right. I like the macro pad and it’s to the left of the keyboard

---

<div class="post-metadata">

**Author:** ![Crystalyne](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/crystalyne/32/606_2.png) [@Crystalyne](https://community.frame.work/u/Crystalyne)\
**Post date:** [April 24, 2026, 11:36am UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/23 "2026-04-24T11:36:06Z")

</div>

Are there any plans for a haptic touchpad module which is the standard width (i.e. fits with the spacers)?

I use the touchpad offset from center so the single piece isn’t for me unfortunately.

---

<div class="post-metadata">

**Author:** ![jared\_kidd](https://avatars.discourse-cdn.com/v4/letter/j/91b2a8/32.png) [@jared\_kidd](https://community.frame.work/u/jared_kidd)\
**Post date:** [April 24, 2026, 1:25pm UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/24 "2026-04-24T13:25:04Z")

</div>

> [@Jacob\_Stamm](#):
>
> Unfortunately, unless you guys include a horizontally offset variant of the one piece haptic touchpad module, those of us who have num pads will have to either settle with the touchpad being placed awkwardly (not feasible for me) or pass on the one piece module altogether.

I don’t think they will make an offset version, because it prevents you from placing the keyboard modules in all supported configurations (on the far right), which will definitely cause more support calls.

---

<div class="post-metadata">

**Author:** ![Jacob\_Stamm](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/jacob_stamm/32/47613_2.png) [@Jacob\_Stamm](https://community.frame.work/u/Jacob_Stamm)\
**Post date:** [April 24, 2026, 1:36pm UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/25 "2026-04-24T13:36:01Z")

</div>

A better solution would be for them to update the firmware so that when either the keyboard or numpad’s brightness is changed, it syncs that change to the other piece.

---

<div class="post-metadata">

**Author:** ![Jacob\_Stamm](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/jacob_stamm/32/47613_2.png) [@Jacob\_Stamm](https://community.frame.work/u/Jacob_Stamm)\
**Post date:** [April 24, 2026, 1:39pm UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/26 "2026-04-24T13:39:50Z")

</div>

Unless they find a clever way to make both the left-aligned and right-aligned versions the same SKU. Rotate it 180 degrees and now it works on the other side. Probably isn’t possible, but how cool would that be?

---

<div class="post-metadata">

**Author:** ![Howard](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/howard/32/16823_2.png) [@Howard](https://community.frame.work/u/Howard)\
**Post date:** [April 24, 2026, 2:22pm UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/27 "2026-04-24T14:22:29Z")

</div>

There’s not any way to do that without adding a direct connection between them and making one a slave to the other instead of an independent device connected to the computer.

---

<div class="post-metadata">

**Author:** ![Jacob\_Stamm](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/jacob_stamm/32/47613_2.png) [@Jacob\_Stamm](https://community.frame.work/u/Jacob_Stamm)\
**Post date:** [April 24, 2026, 4:45pm UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/28 "2026-04-24T16:45:16Z")

</div>

I’m not a firmware programmer, so I’ll have to take your word for it, but at face value, that doesn’t sound correct. Is receiving a signal from device X and relaying it to device Y really outside the capabilities of motherboard firmware?

---

<div class="post-metadata">

**Author:** ![pablo-thelegend27](https://avatars.discourse-cdn.com/v4/letter/p/ac91a4/32.png) [@pablo-thelegend27](https://community.frame.work/u/pablo-thelegend27)\
**Post date:** [April 24, 2026, 5:01pm UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/29 "2026-04-24T17:01:31Z")

</div>

Looks like a great idea, I wonder if the drivers necessary to make that work will introduce much system latency if any. How well will linux recognise a connected external graphics card through this?

I think something like this will go great with maybe a 14.5-15 inches pro framework laptop (3:2) alongside a docking station where a graphics card and potentially extra storage or even an ethernet connection can be connected. I wonder if all of that would even be possible with that kind of connection, if so, it could remove the necessity for many people to have a laptop and a desktop.

---

<div class="post-metadata">

**Author:** ![Howard](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/howard/32/16823_2.png) [@Howard](https://community.frame.work/u/Howard)\
**Post date:** [April 24, 2026, 6:31pm UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/30 "2026-04-24T18:31:54Z")

</div>

Effectively, yes. They’re connected to the mainboard over USB as two separate keyboards. The only option besides making a pair which link and then present themselves as one USB keyboard and are managed by a single firmware, like a two piece keyboard (Such as [https://keeb.io/collections/iris-split-ergonomic-keyboard](https://keeb.io/collections/iris-split-ergonomic-keyboard)), is to have software running on the computer which controls the backlight settings instead of the keyboard’s firmware.

---

<div class="post-metadata">

**Author:** ![Tamara\_Ryan](https://avatars.discourse-cdn.com/v4/letter/t/f9ae1b/32.png) [@Tamara\_Ryan](https://community.frame.work/u/Tamara_Ryan)\
**Post date:** [April 24, 2026, 6:43pm UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/31 "2026-04-24T18:43:46Z")

</div>

Did the OCuLink Dev Kits already sell out, or have they just not launched yet? I’ve wanted this since I first got my 16.

---

<div class="post-metadata">

**Author:** ![FWPL](https://avatars.discourse-cdn.com/v4/letter/f/65b543/32.png) [@FWPL](https://community.frame.work/u/FWPL)\
**Post date:** [April 24, 2026, 9:12pm UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/32 "2026-04-24T21:12:57Z")

</div>

> [@Iroh](#):
>
> As far as we know, this makes Framework Laptop 16 the first laptop to have an 8-lane OCuLink interface exposed.

Just wanted to say that no, it is not, but I think it is the second one :). This one was the first I saw at least: [https://www.youtube.com/watch?v=r7VIV7S\_Aik](https://www.youtube.com/watch?v=r7VIV7S_Aik)

---

<div class="post-metadata">

**Author:** ![Klay\_Hart](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/klay_hart/32/22234_2.png) [@Klay\_Hart](https://community.frame.work/u/Klay_Hart)\
**Post date:** [April 24, 2026, 11:20pm UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/33 "2026-04-24T23:20:48Z")

</div>

I checked once the Framework site was back up after the announcement and they weren’t available yet. Here’s a snippet when looking through the coming soon section of the store.

 ![image](https://us1.discourse-cdn.com/flex001/uploads/framework3/original/3X/0/c/0c359116db5799e882efbaf7a35f1ab764f670a8.jpeg)

---

<div class="post-metadata">

**Author:** ![Liam\_Duffy](https://avatars.discourse-cdn.com/v4/letter/l/22d042/32.png) [@Liam\_Duffy](https://community.frame.work/u/Liam_Duffy)\
**Post date:** [April 25, 2026, 10:35am UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/34 "2026-04-25T10:35:16Z")

</div>

Yeah, this is the combination I’ve been chasing for years. A thin and light 13" laptop when on the go, that can also be used for workstation tasks and gaming when at the office / home.

Having this connectivity in a 16" device is obviously great too, but a little less compelling, given it is possible to fit a powerful discrete GPU into such a form factor. Whereas that is next to impossible with a 13" device.

---

<div class="post-metadata">

**Author:** ![MJ1](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/mj1/32/15519_2.png) [@MJ1](https://community.frame.work/u/MJ1)\
**Post date:** [April 25, 2026, 11:09am UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/35 "2026-04-25T11:09:46Z")

</div>

> [@Howard](#):
>
> Effectively, yes. They’re connected to the mainboard over USB as two separate keyboards. The only option besides making a pair which link and then present themselves as one USB keyboard and are managed by a single firmware, like a two piece keyboard (Such as [https://keeb.io/collections/iris-split-ergonomic-keyboard](https://keeb.io/collections/iris-split-ergonomic-keyboard)), is to have software running on the computer which controls the backlight settings instead of the keyboard’s firmware.

Arbitrary keyboard to keyboard communication is actually possible with a little trick. I use it with a qmk mouse. And a community member used it for a FWL16 keyboard firmware called altsync.

> **more details (click to show)**
>
> > [@Framework Laptop 16 inch Number pad Suggestion](https://community.frame.work/t/framework-laptop-16-inch-number-pad-suggestion/70236/10):
> >
> > Keyboard to keyboard communication is possible with a little trick using the indicators. I use it on my mouse, learned of it from an old alternative firmware I found created by Ploopy Co. There is also an example of it from a community member here. I could find links when at my PC.
> > 
> > ~edit~  
> > The one I’ve used is based on Ploopyco’s LED-Key BitMasks (lkbm).  
> > [keyboards/ploopyco/trackball\_nano/keymaps/lkbm/readme.md](https://github.com/qmk/qmk_firmware/blob/0.23.9/keyboards/ploopyco/trackball_nano/keymaps/lkbm/readme.md)
> > 
> > ```auto
> > # The keymap that takes commands as LED-Key BitMasks (lkbm)
> > Based on [maddie](../maddie), this keymap lets you send a 2-bit command by having a macro on your keyboard tap `KC_NUM_LOCK` and `KC_CAPS_LOCK` on and off within a very short window (25ms by default) to represent bits 1 and 2 respectively. The keymap uses this to allow toggling between sending mouse-movement events and scrolling events; cycling DPI presets, and resetting to the bootloader, so you can reflash without having to unscrew your Ploopy Nano.
> > 
> > ```
> > 
> > Here’s another implementation based on lkbm.
> > 
> > [github.com/nicknimchuk/qmk\_nano\_dualhand](https://github.com/nicknimchuk/qmk_nano_dualhand/blob/main/readme.md)
> > 
> > ```auto
> > # qmk_nano_dualhand: a keymap designed for two Ploopy Nano trackballs
> > This keymap configures two Ploopy Nano trackballs, one for each hand. At any given time, one will be for mouse movement, while the other is used for scrolling. This can be swapped dynamically using commands from a QMK keyboard, potentially reducing injury or strain by not restricting mouse movement to a single hand. 
> > 
> > ![Pictured: two Ploopy Nano trackballs with a ZSA Moonlander keyboard on the Platform accessory](https://imgur.com/hrQaC6u.jpg)
> > 
> > ## Inter-QMK communication
> > The primary feature this code provides is a num/caps lock communication feature based on the [lkbm](../lkbm) Nano keymap, which was itself based on [maddie](../maddie). It provides code for sending and receiving commands between QMK devices by toggling the caps lock and num lock keys for "bits" of the commands. The main advantages over the previous versions of this feature are:
> > 
> > * The feature is mostly broken out into separate files, so it's easier to apply to other devices and keymaps.
> > * The command length is an arbitrary (pre-defined) number of bits, so any number of commands can be created at the cost of slower commands.
> > * There are many timings that can be easily tweaked to try to find the right balance of speed and command reliability. These timings do not have to influence any other settings in QMK.
> > * The commands are sent asynchronously, so even if a command takes a full second to send, you can use the device while it is sent.
> > 
> > There's also some disadvantages:
> > 
> > * Commands will likely take longer to allow for two-way communication if desired.
> > * Bits are only processed if the given lock is toggled twice without the other lock toggling. This reduces misinterpreted commands, but also means that some commands that [lkbm](../lkbm) would handle due to interleaved lock commands will be ignored.
> > * The asynchronous nature means that typing could happen while caps lock or num lock is temporarily enabled (or temporarily disabled). This can be slightly mitigated by the fact that one command will only use caps lock, and another command will only use num lock (but the rest will use both).
> > * This feature is not written to minimize flash space. This is not a problem with the Nano, which has plenty of free space by default, but may cause problems with some keyboards. The older options do not require any additional code space to send commands.
> > 
> > ```
> > 
> > And the FWL16 altsync firmware by a community member, which looked to be based on nano\_dualhand.
> > 
> > [github.com/ionitor/qmk\_firmware/tree/ionitor-altsync/keyboards/framework/ansi/keymaps/altsync](https://github.com/ionitor/qmk_firmware/tree/ionitor-altsync/keyboards/framework/ansi/keymaps/altsync)
> > 
> > Using scroll-lock is also possible, as I do that on my mouse. There is also a kana indicator which should be a possibility but I had trouble getting that to work & I didn’t really have a need for it so I didn’t bother.

---

<div class="post-metadata">

**Author:** ![Klay\_Hart](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/klay_hart/32/22234_2.png) [@Klay\_Hart](https://community.frame.work/u/Klay_Hart)\
**Post date:** [April 26, 2026, 12:54am UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/36 "2026-04-26T00:54:40Z")

</div>

> [@Liam\_Duffy](#):
>
> A thin and light 13" laptop when on the go, that can also be used for workstation tasks and gaming when at the office / home.

This is what I think is probably the biggest issue I’ve seen with the OCuLink connector being used. I’ve seen quite a few people who use the FW13 and who either use an eGPU or want to use an eGPU with their FW13. There’s currently no way to use the FW16 GPU with a FW13 (or any other Framework system). Also, there’s not hot plug capability.

Although given it’s a dev kit and not a full product I expect to see people modify it.

---

<div class="post-metadata">

**Author:** ![Tealk](https://sea1.discourse-cdn.com/flex001/user_avatar/community.frame.work/tealk/32/24794_2.png) [@Tealk](https://community.frame.work/u/Tealk)\
**Post date:** [June 25, 2026, 8:10am UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/37 "2026-06-25T08:10:13Z")

</div>

Is there an approximate date for when the One Piece Touchpad Module will be available? I still need a few USB-C modules and would rather not order twice

---

<div class="post-metadata">

**Author:** ![Per\_Magnus\_Tveten](https://avatars.discourse-cdn.com/v4/letter/p/b9bd4f/32.png) [@Per\_Magnus\_Tveten](https://community.frame.work/u/Per_Magnus_Tveten)\
**Post date:** [June 25, 2026, 9:35am UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/38 "2026-06-25T09:35:47Z")

</div>

Or any news on the oculink dev kit thing?

---

<div class="post-metadata">

**Author:** ![Alan\_Pearce](https://avatars.discourse-cdn.com/v4/letter/a/2bfe46/32.png) [@Alan\_Pearce](https://community.frame.work/u/Alan_Pearce)\
**Post date:** [June 25, 2026, 9:01pm UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/39 "2026-06-25T21:01:50Z")

</div>

> [@Tealk](#):
>
> Is there an approximate date for when the One Piece Touchpad Module will be available? I still need a few USB-C modules and would rather not order twice

> [@Per\_Magnus\_Tveten](#):
>
> Or any news on the oculink dev kit thing?

Don’t expect anything on either front until they have all the 13Pro batches close to delivered.

---

<div class="post-metadata">

**Author:** ![Kenna\_M](https://avatars.discourse-cdn.com/v4/letter/k/e47774/32.png) [@Kenna\_M](https://community.frame.work/u/Kenna_M)\
**Post date:** [July 11, 2026, 12:48pm UTC](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952/40 "2026-07-11T12:48:46Z")

</div>

> [@Jacob\_Stamm](#):
>
> Unfortunately, unless you guys include a horizontally offset variant of the one piece haptic touchpad module, those of us who have num pads will have to either settle with the touchpad being placed awkwardly (not feasible for me) or pass on the one piece module altogether.

The one piece touchpad looks much better than with the little fillers! I’ll probably end up getting one as the configuration I’d really like isn’t supported. I have a numpad on the right and really wanted to have the touchpad on the right as well to stop my thumbs accidentally touching it, I was really disappointed when I discovered that this configuration isn’t supported. A version of the one piece with the touchpad on the right would be really appreciated!

[Previous page](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952.md?page=1)

[Next page](https://community.frame.work/t/framework-laptop-16-upgrades-and-a-preview-of-the-oculink-dev-kit/81952.md?page=3)
