OSHW Framework Laptop Expansion Hides Dongles

If you’ve got a wireless keyboard or mouse, you’ve probably got a receiver dongle of some sort tucked away in one of your machine’s USB ports. While modern technology has allowed manufacturers to shrink them down to the point that they’re barely larger than the USB connector itself, they still stick out enough to occasionally get caught on things. Plus, let’s be honest, they’re kind of ugly.

For owners of the Framework laptop, there’s now a solution: the DongleHider+ by [LeoDJ]. This clever open source hardware project is designed to bring these little receivers, such as the Logitech Unifying Dongle, into one of the Framework’s Expansion bays. The custom PCB is designed with a large notch taken out to fit the dongle’s PCB, all you need to do is solder it in with four pieces of stiff wire.

That would be a neat enough project, but [LeoDJ] went one better by adding a CH334 USB hub chip and a female USB connector to the board. So not only does this module hide that unsightly dongle, it gives you back the USB port that it would otherwise be taking up. Since the CH334 still had extra ports available, [LeoDJ] put some additional USB pads on the back of the PCB — so assuming you can physically fit it in the 3D printed enclosure, you could tack on a second receiver dongle or some other tiny gadget.

As slick as the DongleHider+ is, it’s not a perfect solution. According to the project’s README, while USB 2.0 seems to work pretty well, plugging a USB 3.0 device into the port temporarily knocks out the internal dongle. It’s not a deal breaker, but something to keep in mind. It also looks like the DongleHider+ has only been tested under Windows so far, though we’d be surprised if there was actually anything that would keep it from working under Linux.

While there are plenty of reasons for hardware hackers to be excited about the Framework laptop, we think the Expansion Cards have to be near the top of the list. If you don’t have any dongles you want hidden, maybe you’d be interested in a microcontroller development board that you can slap into the side of your laptop?

16 thoughts on “OSHW Framework Laptop Expansion Hides Dongles

  1. I’d bet it goes ‘oh new USB 3.0’ better check out the USB PD stuff and brown out everything else on the hub in the process. Seems to be the way everything that supports USB-PD and is a USB hub works when a new device is plugged in…
    Still like the idea and a momentary reset isn’t a big problem – its not like you were actively needing the keyboard and mouse at the precise moment you are plugging in another USB device. Though I think I’d add an external reset button for the inbuilt dongle – USB devices do seem to often enough need a deliberate power cycle with all this PD negotiation, higher speed signalling and hub upon hub making them flake out more than they used to in the USB2.0 days. Be annoying to have to pull the module or invoke a reset of the controller in the PC.

    1. No, the dongle *stops working*. It isn’t a momentary reset, and it has nothing to do with the PD stuff because the downward-facing port is a Type A. It’s probably more like the hub driver powers down the USB 2.0 port when a device that only uses USB 3.0 is connected or something.

      It’s not really a standards-compliant link, since it’s peeling off the USB 2.0 and just routing the USB3.0 straight through. Not really surprising things act weird.

      1. The git and article claims its got a USB hub chip on the PCB – its treating that USB port on the framework in the conventional fashion, and just not actually exposing the extra USB-A ports of the hub.

        Doesn’t matter what the port is I’ve seen in many USB chipsets now plug in any device and the entire lot gets reset. Doesn’t matter if its a USB2.0 only port in one of the bigger dock/hubs that has lots of IO the entire lot is always seems to be power cycled by a device insertion. (plus PD does exist and work over USB-A connectors anyway).

        1. CH334 is just USB2 hub.

          This project tries to take advantage of the fact that the USB2 and USB3 bus are independent even though they are on the same connector. Unfortunately the root hub (on framework motherboard) acts too smart and turns of the USB2 bus when the USB3 device doesn’t need it.

          Using USB3 hub IC would probably solve it, though I wouldn’t be surprised if the root hub registers would have some bit to configure this behavior.

          1. Ah interesting, and shows what happens when you don’t know the part number or look into it deeply so assume its doing the seemingly logical thing of using a USB hub chip as a USB hub for the two devices involved.

            I stand corrected. In this case its not failing for the most annoying but constant failure of USB since PD crap started getting everywhere. (There is nothing more annoying than a corrupt USB drive because you plugged something else into the hub and it got browned out mid action).

          2. I suspected this was the issue! I got a USB 3.0 -> USB 3.0 + 2x USB 2.0 dongle forever ago and was wondering what the hell it was doing, it uses the exact same trick and hub chip!

            A proper USB 3.0 hub chip would be a much better solution. They should do a v2.0 version of the adaptor.

          3. > Unfortunately the root hub (on framework motherboard) acts too smart and turns of the USB2 bus when the USB3 device doesn’t need it.

            Doing that would break USB 3.0 hubs. They’re effectively two separate USB hubs in a box with one handling USB 1.2/2.0 and the other USB 3.0. It is one of the hidden gotchas for USB hubs as upgrading to a USB 3.x hub doesn’t help with increasing the number of USB 2.0 devices.

            > Using USB3 hub IC would probably solve it

            A USB 3.0 hub chip wouldn’t help with USB 2.0 devices. USB 2.0 to 3.0 transaction translators are forbidden in the USB specs and no USB hub chip has support for it. That said, VIA did make VL670/671 which does do this forbidden translation but its buggy, compatibility is poor and its a separate chip.

          4. @MCorgano

            > I suspected this was the issue! I got a USB 3.0 -> USB 3.0 + 2x USB 2.0 dongle forever ago and was wondering what the hell it was doing, it uses the exact same trick and hub chip!

            It isn’t a trick. That is how you’re meant to implement a USB 3.0 hub. The USB 1.2/2.0 and USB 3.0 sides are separate.

          5. “Doing that would break USB 3.0 hubs. They’re effectively two separate USB hubs”

            Yeah, but a USB 3.0 hub reports itself as a USB 3.0 hub on the SS side, not Random USB3 Device.

        2. “its treating that USB port on the framework in the conventional fashion”

          Uh, no, it’s not. It’s pulling off the SS pairs and passing them directly while putting the USB 2.0 pair through a hub. I’m not sure there’s anything in the spec *disallowing* it but it sure as heck isn’t referenced.

          “now plug in any device and the entire lot gets reset.”

          Again, it’s not a reset, the whole 2.0 link drops off. A reset would be fine. It disconnects and doesn’t reconnect. PD over type A requires a PD plug with the required switch contact. Which this isn’t. PD plugs are *super* rare anyway.

  2. Far as I recall the framework ports are all PCIe available ports aren’t they? So surely the solution here is to replace the baby USB2 hub chip with a PCIe USB3 host controller – those will have to support USB2 and USB3 properly and simultaneously.

    1. The Framework ports are all USB type C, period. The more recent ones are technically Thunderbolt 4, but that’s just USB4 on steroids mostly anyway (well, more properly USB4 is just a modified Thunderbolt 4).

      You want a USB3.2 hub IC, but those are a *massive* step up complexity-wise from the CH334.

      1. Can’t really say ‘type C, period.’ like it means anything – as it doesn’t, could still be just USB2 in a fancy new coat etc. If they are all Thunderbolt 4 compliant then they should work with PCIe chips as I understand it.

        From my quick looking around the hub IC seem much harder to get and use while also being more expensive than the PCIe host controller. (but far from an exhaustive look – too many options to look through and no personal need to look right now – looking only because this comment section peaked my interest enough).

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.