WARNING LONG POST I AM DESPERATE

Why is it so hard to get clarification on a hub and its capability to pass through DisplayPort compression / high-bandwidth USB-C video?

I am trying to build a DIY lapdock setup, and I know my use case is extremely niche, but this is the exact thing I need:

Phone → compact USB-C DP Alt Mode hub → downstream USB-C video/data/power → portable USB-C monitor

The goal is one single cable going from the hub to the monitor that carries:

- video

- touchscreen/data

- enough power for the monitor

- ideally 1080p 120Hz

- while still keeping USB 3 speeds available for other devices

The monitor needs around 12W to 18W depending on brightness. I can technically get it running at lower power, but for actual usable brightness I need somewhere around that range. This is why normal little USB-C hubs are annoying. A lot of them either do video but not enough power, or power but not video/data the way I need.

So far, I have been through two hubs, and each one has its own set of issues.

The first one was kind of my fault because I did not look into the listing deeply enough. It basically gave me one USB-C video output, but there was no useful data passed through with it. That is fine for a basic monitor, but the goal here is to drive a single USB-C monitor with both video and touch/data.

Then my research led me to focus on Thunderbolt 4 capable hubs, because as far as I can tell, they are one of the only hub types that commonly support around 15W downstream power on their USB-C/TB ports.

In theory, that is perfect.

A Thunderbolt 4 style hub gives me one downstream USB-C cable to the monitor. That cable can power the monitor, pass video, and pass touch. My monitor only needs USB 2.0 for touch, so I do not need crazy data going to the monitor itself. But I still need the hub to keep USB 3 available for other ports/devices.

Of course, here is the annoying part: I am not using a Thunderbolt capable device.

I am using a phone that supports USB 3.2 Gen 2 + DisplayPort Alt Mode.

So I know I am in fallback mode. I am not expecting real Thunderbolt tunneling. I am trying to figure out which hub can handle this fallback mode properly.

I went ahead and bought a UGREEN Thunderbolt 4 8-in-1 hub.

And it worked perfectly… until it didn’t.

It powers the monitor just fine. Touch works. Everything about it would have been perfect for my DIY lapdock setup.

But I am limited to 1080p 75Hz.

After digging into my phone’s kernel/debug info with root, I figured out what is happening. The UGREEN path is negotiating as:

- DP 1.4 identity

- HBR x2

- 2 DP lanes

- no DSC

- no FEC

- 1080p 75Hz exposed

- 1080p 120Hz rejected

The actual live bad state was basically:

link_rate = 270000

num_lanes = 2

bw_code = 10

resolution = 1920x1080@75Hz

bpp = 18

dsc_en = 0

fec_en = 0

So I originally kept thinking “why can’t I just get DSC working?” because on paper that would be perfect. Display Stream Compression would let me keep USB 3 lanes and still hit the refresh rate.

But the issue is that my phone can support DSC on the source side, while the actual downstream route through the hub is not advertising DSC/FEC back to the phone.

My phone clearly has DSC/FEC enabled on the source side. The kernel/debug files show it. But the dock/display route is saying no DSC and no FEC, so the phone is not going to send DSC.

So I do not think the issue is simply “phone cannot do DSC.”

It is more like:

Phone can do DSC → but the hub/fallback path is not advertising DSC/pass-through → driver refuses to use it → 1080p120 does not fit over the current HBR x2 link.

The monitor itself can run 1080p120 fine. I tested an older generic Chinese HDMI hub that converts the phone’s DisplayPort Alt Mode output into HDMI, and with that hub I can get:

link_rate = 810000

num_lanes = 2

bw_code = 30

resolution = 1920x1080@120Hz

pclock = 297000KHz

bpp = 30

So the phone can absolutely do HBR3 x2 and 1080p120.

That was actually a huge clue.

The problem is the older HDMI hub is not the setup I need. It technically works, and it keeps USB 3 working for other high-speed devices, which is great, but now I have too many cables:

- power for the hub/phone

- HDMI/video path

- separate USB power for the monitor

- touch/data complexity

That defeats the whole lapdock goal.

What I need is not just “any hub that can do 1080p120.”

What I need is specifically:

Phone

→ compact USB-C DP Alt Mode hub that preserves HBR3 x2 + USB3

→ downstream USB-C video/data/power to monitor

Basically, I need a hub that can do the 2-lane DisplayPort + USB3 split properly, but with the DP side running at HBR3 x2, not falling back to HBR x2.

From my understanding:

- 4-lane DP Alt Mode can give plenty of video bandwidth, but usually kills USB 3 because all high-speed lanes are used for video.

- 2-lane DP + USB3 is the lane split I want.

- HBR x2 is not enough for my 1080p120 mode.

- HBR3 x2 is enough, and I have already proven my phone can do it.

- DSC would also be amazing, but only if the hub/route actually advertises DSC/FEC properly.

- The UGREEN TB4 hub powers everything perfectly, but in my phone’s fallback mode it negotiates the bad HBR x2 path.

So in theory, I am very close, yet so far.

The frustrating thing is that in the world of USB-C, DisplayPort Alt Mode, USB4, and Thunderbolt hubs, a lot of the actual capabilities are not clearly stated by manufacturers. Listings will say things like “8K,” “4K60,” “Thunderbolt compatible,” “USB-C display support,” etc., but they rarely say what actually happens in fallback mode from a non-Thunderbolt USB-C DP Alt Mode host.

I can settle for USB4 or Thunderbolt style hubs if they happen to support this correctly in fallback mode. There are a few that look possible. But downstream power is usually lackluster, and I need at least around 12W to 15W to drive this display at acceptable brightness.

I picked this portable screen because it is bright, IPS, large, and 120Hz. I also intentionally did not go for 2K or 4K because I did not want to run into bandwidth limitations. But somehow I am still running into bandwidth limitations at 1080p because the hub is negotiating the wrong DP link.

So my question for people who understand USB-C / DP Alt Mode / USB4 / Thunderbolt hubs better than I do:

Does anyone know of a compact hub that can actually do this?

What I need:

- USB-C upstream from a non-Thunderbolt phone

- USB 3.2 Gen 2 + DisplayPort Alt Mode fallback support

- downstream full-feature USB-C port for monitor

- USB-C video + touch/data + power on that downstream port

- at least 12W, ideally 15W, downstream power

- 1080p120 support

- ideally HBR3 x2 while keeping USB3 alive

- or DSC/FEC pass-through that actually advertises correctly to the phone

I am not asking for a normal HDMI hub.

I only know as much as I know because I have dug way too deep into my phone’s kernel/debug output, used root to inspect the DP negotiation, and confirmed that I am hitting a real bandwidth/negotiation limit.

So what should I be searching for?

Should I be looking for specific chipsets? Intel JHL8140? USB4 hubs with downstream DP Alt Mode?Something else?

am I asking something that cant exist? It doesn't seem possible 1080 120hz shouldn't work even with hubs that utilize backwards compatible pathways..i ordered one more hub that MIGHT work but im worried ill face this issue again.

SABRENT Thunderbolt 4 Hub, 60W Charging USB-C Dock for Laptops, 3X TB4 + 1x USB-A is the next one on my list and the only reason im considering it is it mentions in its own listing it can do DSC with 144 he 1080p. So this clearly has some fallback yes?

Returning products is getting pretty annoying

Sorry the rant guys...asking the actual enthusiasts and potential experts here.

​

I need to say this clearly because I think some people are missing the actual point.

​

I’m not just making another launcher.

I’m not making a cute frontend.

I’m not making a shortcut wrapper with extra steps.

​

I’m building an Android Wayland bridge so Linux games/apps can render through Android using a real GPU path.

​

YES. ON A PHONE.

​

The goal is basically:

​

Linux Wayland app / Gamescope

-> dmabuf

-> Android bridge

-> AdrenoTools / Turnip Vulkan import

-> GPU composite/blit

-> AHardwareBuffer / SurfaceControl

-> Android display

​

That is the actual magic trick.

​

Not “stream it.”

Not “CPU copy every frame and pray.”

Not “hide Steam behind some frontend and hope users trust it.”

​

A real bridge.

​

What I have working so far:

​

- Android app bridge using an abstract socket

- fd passing with `SCM_RIGHTS`

- dmabuf metadata validation

- KGSL dmabuf import probes

- AdrenoTools / Turnip Vulkan import

- dmabuf-present into Android SurfaceControl

- visible fullscreen output from `vkcube`, SuperTuxKart, and `vkmark`

- Gamescope / Steam launch work in progress

- early multi-window experiments for Linux apps as Android windows

​

So when I say I’m trying to turn a phone into something closer to a Steam Deck, I mean that at the graphics stack level.

​

NOT just the UI.

NOT just the vibes.

THE ACTUAL RENDER PATH.

​

The point is compatibility.

​

Steam games run best when Steam is in an environment it understands. So the obvious move is to give Steam/Gamescope a Linux-style environment, then make Android handle the final presentation underneath.

​

That is why this matters.

​

Right now, root is part of my development setup. I’m not hiding that. But I don’t think root has to be the final forever-requirement. If the proot/container side gets solved properly, this gets way more usable for normal people.

​

And yeah, I know how I sound sometimes.

​

I get excited.

I brag.

I talk in caps.

I probably sound like someone gave a compiler error caffeine and a personal grudge.

​

BUT LOOK AT THE WORK!!! It works! This isn't a fucking trick or a me hiding anything!!

​

​

This community has a bad habit of turning technical work into personality court. Someone gets loud, someone has an ego, someone has a bad day, and suddenly the actual contribution gets ignored.

​

STOP DOING THAT! Seriously. Look at every dev who just quit and they could habe contributed something longer but the community ran them off!

​

Android is already locked down enough.

Vendors already make this hard enough.

Google already strips away enough freedom.

Driver hell already exists.

Bootloader hell already exists.

Graphics stack hell DEFINITELY exists.

​

We do not need to add “community eats its own devs” on top of that like it’s a required dependency.

​

If the work is useful, use it.

If you want to fork pieces, fork them.

If you want to improve it, improve it.

If you don’t like me personally, fine. Put that in a little box somewhere and keep moving.

​

But don’t pass me off because im passionate and crazy. Im.both. so what!.

​

Because the actual goal here is bigger than me:

​

Android phones are powerful enough to be better Linux gaming devices than they are currently allowed to be.

​

I’m trying to punch a hole through that wall.

​

So yeah.

​

I’m proud of this.

I’m going to brag a little.

I’m going to be weird about it.

That’s part of the package.

​

But the work is real.

​

LET ME COOK. Dude for real. Just give me the win because I worked very hard to get this stack working. Iv lost hair already and almost broke my phone just getting gamescope convinced its running in its native environment!

​

​

https://reddit.com/link/1tzqmsc/video/js36cuonyx5h1/player

Native ARM64 Steam Running on Android With Proton 11 ARM64, FEX, Mesa Turnip, and DroidSpaces OSS

I wanted to share what I was able to get working because I have not really seen many people doing this exact setup yet. exept on other plateforms like android handhelds (they still are not using the native beta cutting edge not well known steam arm64 client build)

Also, just to be clear upfront: this is not an ad for DroidSpaces OSS. I am not affiliated with it, and I am not trying to sell anyone on it. I just happened to use it for this project, and it made the goal a lot easier than the other Android Linux methods I tried.

I got the native ARM64 Steam client running directly on Android, inside a Linux environment on my phone. This is running on a rooted REDMAGIC 11 Pro, using DroidSpaces OSS, with a KernelSU setup and a custom kernel that has the right features for this kind of thing.

The cool part is that this is not the normal Windows Steam client running through a bunch of translation layers. The Steam client itself is running as the native Linux ARM64 Steam client. Steam opens, the library works, downloads work, Big Picture Mode works, and it actually feels smooth.

I also have Proton 11 ARM64 working with FEX under the hood for x86/x86_64 game translation. So the Steam client itself is native ARM64, but Windows/x86 games can still run through Proton/FEX when needed.

As a real test, I got Garry’s Mod working.

That took a lot of file patching and messing around to get it to actually launch and behave correctly, but once it was working, it was way better than I expected. I was able to play with Mesa Turnip drivers and get almost full-speed gameplay. And this was not just single player either. Online play worked. No major delay, no unplayable input lag, and the whole thing felt shockingly usable.

To me, this feels better than GameHub or GameNative, at least for what I personally want. Those projects are cool, and I am not trying to take anything away from them, but they still feel more like frontend-heavy Android gaming solutions. With this setup, I am using the real Steam client, the real Steam library, real Big Picture Mode, and a self-contained Linux environment. It feels less like I am launching games through a pile of hacks and more like I am running a small Linux gaming system inside my phone.

The setup making this possible for me is DroidSpaces OSS.

Again, not saying it is the only way or that everyone needs to use it. It is just the method that finally made this feel realistic for me. Compared to the normal chroot-style Linux setups people usually do on Android, DroidSpaces feels like a step above. It gives you a more serious Linux container environment, with root-level benefits, hardware access options, better isolation, and a more complete Linux userspace.

The kernel side matters too. This is not something that will work properly on a normal locked phone. You need root, and ideally you need a kernel with the right flags enabled. In my case, I am using the OnePlus 15 WildKernel / SUFUS-based kernel setup on the REDMAGIC 11 Pro, and it has the important stuff working out of the box, including NTSYNC support and the other kernel features needed for this type of container/gaming setup.

That is the main catch.

This is not a “download one APK and now your phone is a Steam Deck” situation. It requires:

• Root
• KernelSU or a similar root setup
• A compatible/custom kernel
• NTSYNC support
• DroidSpaces OSS or a similarly capable Linux container setup
• Mesa Turnip drivers
• Proton 11 ARM64
• FEX for x86/x86_64 translation
• A lot of patience when a game needs patching

So yeah, this is not something most normal phones can do right now, and that sucks.

But the fact that it works at all is kind of insane.

The basic idea is:

The phone runs Android as the host. DroidSpaces creates a real Linux container environment. Inside that container, I run the native ARM64 Steam client. Steam handles the library, downloads, Big Picture Mode, and game launching. When a game needs x86/x86_64 support, Proton 11 ARM64 uses FEX underneath to translate the game code. Graphics go through Mesa Turnip so the Adreno GPU can actually be used properly instead of falling back to slow software rendering.

That is why this feels so different from the usual Android gaming setups.

The Steam client is not the broken part anymore. It is native, smooth, and usable. The game compatibility side is still where the hard work is, because games still depend on Proton, FEX, Mesa, Turnip, DXVK/VKD3D, and sometimes manual fixes. But once everything lines up, it actually works.

Getting Garry’s Mod running online on a phone like this was the point where I realized this setup is not just a random experiment. It is genuinely usable.

This feels like the direction high-end rooted Android phones should be going. Phones like the REDMAGIC 11 Pro already have the power, cooling, display, USB-C output, controller support, and RAM. The hardware is there. The missing piece has always been the software stack.

DroidSpaces OSS just happened to be the tool that made the path easier for me.

It is still rough. It is still not beginner-friendly. And it still depends heavily on root and kernel support. But this is the closest I have personally felt to having a SteamOS-style Linux gaming environment running inside Android without actually dual-booting or replacing Android

gameplay below sped up for convince just to show me messing around and playing online game play. full linux desktop too so fps is lower as i have not disabled things like gamehub and gamenative did this is basically worst case and bloated but you get the point 😄

https://reddit.com/link/1tzqmsc/video/pmct9g8ywx5h1/player

Tried out Pqq 20mg per day alongside coq10 and it genuinely works. Figured it was one of those hype supplements but energy levels has sky rocketed even if I was extremely skeptical. Before I was taking only coq10 and it didn't do much of anything. I got no science or blood work backing up my claims. I just feel more mentally alert. Changed nothing else. One week in taking it. It's not simulating. It's just clean sense of more energy capacity

Pyrroloquinoline quinone is the name. I'm going to assume most any reputable supplement brand containing this would work.

That's all I got to say