Lemmy | Technology

Subscribe to our free newsletters

Our weekly newsletter Closing Arguments offers the latest about ongoing trials, major litigation and rulings in courthouses around the U.S. and the world, while the monthly Under the Lights dishes the legal dirt from Hollywood, sports, Big Tech and the arts.

We believe the future is for everyone, including America’s universities, professors, students, and the communities who benefit from their research. That’s why Meta is bringing Superintelligence models, research funding, and direct researcher collaboration to academia through partnerships with five US universities: California Institute of Technology, The Ohio State University College of Medicine, Louisiana State University, Indiana University, and UTHealth Houston. 

We’re expanding our academic partnerships by granting $2 million across these five schools to support research that uses our models to accelerate breakthroughs in medicine, physics, chemistry, biology, computer science, and mathematics. 

In medicine and healthcare, researchers will work on a diverse set of projects using Meta’s models, glasses, and mixed reality headsets to address existing gaps in medicine and healthcare. Here are a few examples of how they’re being used:

Monitoring for Infant Tracheostomies

When tracheostomy tubes become dislodged in infant patients, it’s a life-threatening emergency compounded by the fact that babies with tracheostomies can’t cry out for help. And continuous direct observation by trained staff isn’t always possible. 

Dr. Michael Dunham from Louisiana State University is leading the Eyes-On project, which is developing a computer vision system to continuously detect tracheostomy tube displacement and signs of distress in infants who cannot reliably vocalize. The system is exploring usage of our open weight SAM models for tracking and is designed for integration with bedside cameras and edge computing. A proof-of-concept has been published, with more work to come.

Conversational AI for Dementia Care

People with dementia often experience communication difficulties that standard conversational AI systems handle poorly, leading to frustration rather than support. Dr. David Crandall at Indiana University is developing a project that aims to develop multimodal AI methods for analyzing conversations involving older adults living with dementia, and to use this understanding to help conversational agents — including social robots — adapt their interactions to individual users. The research tests whether AI systems can be made sensitive to the communication patterns of people with cognitive differences.

Identifying Heart Failure Risk Earlier

Heart failure with preserved ejection fraction (HFpEF) accounts for roughly half of all heart failure cases, but it can be difficult to recognize early — its symptoms overlap with those of obesity and other common conditions, so formal evaluation often begins only after clinical suspicion has developed.

At The Ohio State University College of Medicine, AI researcher Dr. Yuan Xue is leading a project with cardiologist Dr. Yuchi Han and AI researcher Dr. Xia Ning to investigate how Meta’s open-weight models can help predict future HFpEF risk using routine abdominal CT scans, longitudinal medical records, and ECG data when available. The team is designing the model to handle missing data, since real-world clinical practice rarely provides a complete set of inputs.

You can read more on these projects on our Research Blog, and we look forward to sharing more as these projects get underway.

The412Banner

My first memories are of the Nintendo and the first Super Mario Bros. After that came the PC, on Windows NT 3.1 and then 4.0. I played Castle of the Winds, and Gorillas and The Oregon Trail in MS-DOS, loaded from 5¼-inch floppy disks. Around the same time, my father started a computer recycling business in our garage. I pieced together my own system from the parts, taught myself as I went, and got online with those free AOL CDs everyone had. A Voodoo card and a Sound Blaster got me into Quake and Half-Life. I played Counter-Strike while it was still a mod, before Valve bought it and before Steam existed.

xXJSONDeruloXx

When I was 6, my mom took me to toys-r-us and I got a red gba sp with Tony Hawk’s Underground 2. I’ve loved video games as a medium ever since!

Kimchi

Pff wow. My earliest memory of playing video games – I vaguely remember playing on a Amiga personal computer, playing Lemmings, Flashback (way too hard) and Afterburner if I remember correctly. I can't remember what age, but it was early enough to not understand what I was doing but watching the pictures move while pushing buttons was fun haha.

It wasn't until the first Game Boy and the Playstation 1 (which I later swapped for a PC with Windows 95 later on) that I started to play with real understanding – and well, gaming basically stuck.

Astro Sky

To tell you the truth, I've been playing video games since I was three years old. My mother told me that when we first got a Nintendo 64, I picked up Mario and just started playing like it came naturally. I don't remember that myself, of course, but it's interesting to think I could play before the memories I still have today.

The first games I actually remember playing were Super Mario 64 and Banjo-Kazooie. I played Mario 64 a lot. And Banjo-Kazooie, man, I love that game.

The412Banner

Both, but mostly PC. I started on the Nintendo, but the PC is where I spent my time. Back then, getting a game running meant building the machine from recycled parts, getting the right graphics and sound card working, typing commands and swapping disks. Now I'm doing the same thing with PC games on hardware they were never meant for.

Max

Yes, primarily growing up I was playing EverQuest, Quake II and III on my desktop growing up.

xXJSONDeruloXx

I was more of a Nintendo kid growing up, but in middle and high school, I gravitated more toward emulation and the tinkering side of the tech. When I got an R4 card for my DS that was a tipping point.

Kimchi

A mixture of both. Growing up I had the Game Boys up till Game Boy Advance SP, I had PSPs and then I just kept it at PCs. What influenced me getting into these kind of projects was more about developing/programming and less about games.

Astro Sky

Honestly, it was a mixture of both. My first PC was this prehistoric beige computer my dad handed down to me. I didn't care how old it was. I thought it was cool that I could play a Captain Crunch game from a cereal box and some basic PC games. I didn't get internet access until much later. Sonic R was another one I remember: that weird, trippy, low-poly racing game. Very nostalgic for me.

We had the Nintendo 64, but the first console gifted specifically to me was a Dreamcast. I played the heck out of that. Sonic Adventure, oh wow, I love that game.

Those experiences definitely gave me aspirations to make mods and my own PC games. I experimented with an old version of Blender and kept picking it up on and off as it evolved. I can't remember the version. My first YouTube channel was called Blender Bros. It doesn't exist anymore, but I was very proud of that name. I was also into visual effects and making short films, and I had some success with those.

The412Banner

Building my own PC out of the parts in my dad's garage. When a machine is put together from recycled parts, nothing works until you figure out why. Getting a Voodoo card and a Sound Blaster working for Quake taught me early that hardware, drivers and games all have to line up. That's still the whole job with DroidDeck.

Max

When playing EverQuest my brother was a mod for them, he was given a free subscription just to jump in the game and help people so many hours a week which was really cool growing up.

xXJSONDeruloXx

I got an iPod Touch 2g when I was 10, and that was my first foray into jailbreaking, modding, scripting, and emulation. I think geohot was probably my first swe hero.

Kimchi

During my time working on Turnip drivers I also dabbled in the Nintendo Switch system. But, it was largely surface level. Nothing to deep. It was interesting to see how games ran on emulators, what components influenced them.

Astro Sky

What really got me interested in how games work was Godot. I took a Udemy course and made my own version of Flappy Bird from scratch, then added my own modifications. I followed the course, but I also pretty much winged it and experimented.

That was quite a while ago. I can't remember exactly when. It was basic, but I was impressed with it at the time. That was my first coding experience. I found Godot approachable to learn.

The412Banner

Most of it happens on the devices I develop on: an Ayaneo Konkr Pocket FIT (Snapdragon G3 Gen 3, 16 GB RAM, 1 TB) and a Samsung Galaxy Fold 8 Ultra (Adreno 840 GPU). A lot of that is testing, such as DOOM Eternal and the DiRT games I use for benchmarks. For fun, I keep coming back to rally: DiRT 3, DiRT Showdown and DiRT Rally 2.0. I recently played through God of War again, which is a great series. And I've been a Half-Life fan since the original: Half-Life 1 and 2, Counter-Strike: Source, Left 4 Dead 1 and 2, Team Fortress Classic and Team Fortress 2. Some of my favourite Half-Life mods are probably long gone now: Natural Selection, Vampire Slayer and Earth's Special Forces.

Max

99% of gaming now is basically installing a game, playing for a few minutes to an hour just to bug test then uninstalling and never finishing a game.

xXJSONDeruloXx

I find I enjoy games specifically if they don’t live or fit on what I am currently developing on. Right now I am loving Star Wars Galactic Racer, mainly on my HTPC and desktop, because this game is not a great fit for the hardware I test DroidDeck with.

Kimchi

I'm actually not contributing code into this project. I have my own project going on with the hopes to fix my financial situation. Once I'm done with it I will help out the other devs with DroidDeck. That said, I actually do not game a lot these days. The project, my job and family take up most of my time.

Astro Sky

These days, I don't really sit down and game just for fun. I mod games or look for things that haven't been tapped into yet. I'm interested in pushing boundaries and seeing how far we can take what people consider limitations. I still play games, but usually as part of working on something. Essentially, I like making software.

AI has helped me take ideas further and iterate much faster than I otherwise could. My time is limited, so I value that. I approach it like working with a team on an idea, with me handling the creative direction and working to understand the engineering behind it.

The412Banner

I stepped away from computers around 2010 or 2011 and came back to gaming in 2022 with a Retroid Pocket 4 Pro. I started with retro emulation, then found out PC games could run on Android. I upgraded to a Retroid Pocket 5 to get a Snapdragon chip and see how far PC emulation could go. After that came an AYN Odin 2 Portal, and now the Pocket FIT and the Fold. What gets me is having a real PC library in something that fits in a pocket. These games were never supposed to run on a phone chip, and getting them to run anyway shows how powerful these mobile devices and SoCs really are.

Max

I never owned a handheld console beyond the Sega Game Gear in the 90’s but I did however use Steam Link with a portable controller for a while just to play games at work on breaks, at the time that was the peak of gaming on the go for me.

xXJSONDeruloXx

I think there’s something so captivating about having the game in your hands, in your pocket. It feels more like it’s “yours”.

Kimchi

Oh yes, it certainly has. I remember only a few years ago people claiming it would just be a fad. But look at it now, and it is only growing.Its also the only thing that makes sense to invest into, now with computer parts prices skyrocketing. It is almost as if the industry is attempting to pull a “Shrinkflation” like what happened with food... food for thought ;)I think most people are getting tired of being hooked at one place. Handhelds offer the flexibility to move around and carry a powerful system around. But they wouldn't appeal to me if it weren't for the power behind them.

Astro Sky

The PSP is the one I remember most clearly. I got a PSP-1000 for my birthday, the fat one, and I loved that thing. I eventually lost it. I also remember having a Game Boy Micro, but this was a long time ago, so I'm not sure which came first.

What appealed to me was having a small device I could carry around and play games I wouldn't have thought were possible on something that size.

The412Banner

A mix of both, and it grew out of the hardware. In 9th grade my high school offered a half-day vocational program in computer network engineering technology, and I stayed in it until graduation. It gave me an in-depth skill set and a love for the technical side: building and maintaining computers and networks. I also spent a year there learning Java and Visual Basic and C++.

After a couple of years off, I enrolled at the Pittsburgh Technical Institute for a two-year computer network engineering degree. Six months in, I switched to computer forensics. Just before finishing, I went through some hardships and had to learn to stand on my own two feet, so I left before completing my credits. The school has since closed and now operates under another name. Everything after that I taught myself.

Max

Initially I was coding websites and small java apps as a kid, hosting small servers, MITM things locally to debug things and understand how they work and building mods for IRC clients.

xXJSONDeruloXx

I am mostly self taught, and I got started with programming very casually as a kid to supplement my interest in console modding and playing with jailbroken ipods, but I began seriously learning to code around the time I got my first SteamDeck.

Kimchi

I got into programming school in 2012. I always wanted to learn to code. However I quickly realized I don't have it in me.AI now makes this possible. I may not know how to code, but I do possess some knowledge in the domains I work with, which helps a lot and prevents my project to made by 'vibes' a lot less.

Astro Sky

I'm self-taught. Apart from following things like that Udemy course, it was me experimenting. I was focused on school, and these were little hobbies I worked on alongside it. I never really thought about making any of this a career. I do it for fun. If it's not fun for me, I don't want to do it.

The412Banner

Around 2010 or 2011 I stepped away from computers. I was getting through some hard years and building an independent life for myself. I came back in 2022 as a player, not a developer. When I first got into PC emulation on Android I knew next to nothing and could barely set up GameHub. My public projects grew from there: the BannerHub mods for GameHub, Banners-Turnip driver builds, NewTermux (my Termux fork), and then Bannerlator, which continues Winlator Star Bionic. Was I always drawn to compatibility layers? Looking back, yes. Getting a recycled-parts PC to run Quake is the same problem as getting Steam to run on Android.

xXJSONDeruloXx

Around the time I got my Q3 SteamDeck, I began properly learning python and typescript and began publishing some projects, most notably some Decky plugins like Decky-Framegen (Optiscaler) and Decky-lsfg-vk, and also doing some scripting for Bazzite. I always liked emulation because of how accessible it makes games, and the feel of having limitless possible games on any hardware you want.

Kimchi

I first started contributing/helping out with Skyline (now Strato with TheASV) by Mark, Bylaws and Lynx. The famous nintendo switch emulator that never saw it's maturity. First as just a moderator and tester, then couched by the devs into Turnip compiling. It was very rewarding and I had a lot of fun!

Astro Sky

There were my Blender experiments and the Flappy Bird project, but the PSP was an early experience with pushing hardware beyond what it was originally meant to do. I learned about jailbreaking and the Pandora method, and I managed to get custom firmware onto my PSP.

I was a kid and wasn't particularly technically skilled. I didn't do much with it afterward because I didn't understand how far you could take it. Back then, I only knew about a small part of what was possible.

The412Banner

The hardware in my hands. The Retroid Pocket 5 showed me what a Snapdragon chip could do with PC games, and every handheld since has been more capable. There's a technical reason too: Snapdragon's Adreno GPUs are supported by Mesa's open Turnip driver, which makes them unusually good targets for real Linux graphics.

Max

The powerful the chips are that are in our phones and tablets, just knowing the potential they have and what they're capable of.

xXJSONDeruloXx

In highschool I had a Galaxy S4, and playing PPSSPP during class or Drastic waiting for the bus was the coolest thing to me. The fact that we have come so far that now many PC games will run on Android on day 1 of their release would have blown my mind back then.

Kimchi

Because ARM is the future.Power is the bottleneck now. Once watts are capped, performance per watt is the metric that matters, and Arm cores have been designed from the low-power end up for over 30 years. It also already owns most other markets.

Astro Sky

When I got into Android, I discovered Termux. Being able to run Linux tools on my phone was impressive to me. I already liked Linux, but I hadn't realised how much you could turn your phone into a computer.

Then I discovered Winlator and ExaGear, and now I was looking at running PC games on my phone. Honestly, my experience back then was rough. Compatibility was hit or miss, and I had to figure a lot out manually. I wasn't finding ready-made profiles, so I relied on small communities and experimentation.

I think I was using a OnePlus 8, though I can't remember for sure. Getting a game to run well was rare for me. Often it was something like 20 FPS with a lot of stuttering. Of course, the phone I was using was part of that too.

The412Banner

Learning how emulation works at all. I had been away from PC gaming for more than ten years, and when I came back it wasn't on a PC. It was on Android devices, and I went in blind. I knew next to nothing and could barely use GameHub.

So there wasn't one project that taught me the most. It was learning the whole field from zero, mostly by things not working and me figuring out why. Everything I've built since, from BannerHub to Bannerlator to DroidDeck, sits on top of that.

xXJSONDeruloXx

I think generally I have learned the most when contributing to other’s projects, rather than when maintaining my own work. One PR that comes to mind was getting the Miyoo Mini Flip’s hinge to trigger sleep/wake on Onion OS. That was a very difficult PR to get merged for several reasons, but I learned a lot from the process, and it set me on the path to dive deeper into compiled languages and lower level programming.

Kimchi

All the projects I was involved in taught me a lot about development. But it wasn't just Android related projects. I also did some Game development several times.So far none had worked out...knocks on wood

Astro Sky

Working with Winlator and the modder CoffinColors taught me a lot. He influenced me to push the boundaries. I had this idea of turning your phone into a Steam Deck, and I called it Android Deck. My thinking was, man, if we could get compatibility good enough, you could really do that.

That pushed me to experiment with software that wouldn't normally work, optimisations and drivers. Later, rooting my phones opened up things I couldn't do on unrooted Android.

One big challenge was bringing together the Steam, Proton and FEX software stack. I unlocked my bootloader and rooted my phone to experiment with Gamescope and Steam's ARM64 client. Work getting that client running on a modified Nintendo Switch gave me somewhere to start. Sharing an ARM architecture didn't make it straightforward, but it made me want to try.

Through DroidSpace, I worked on a native Arch Linux ARM64 container with Wayland alongside Android, using DRM leasing for an external display through DisplayPort Alt Mode. That was where I started having the most success. The DroidDeck developers explored ideas from those experiments and did their own research and development. That's where I feel my earlier work helped.

The412Banner

Coming back after more than ten years away, I started out just wanting my own games to run. What keeps me going now is other people using it. I remember knowing next to nothing and barely getting GameHub working, so making this easier for the next person matters to me. I also don't believe in gatekeeping anything. If I figured something out, it should be out there for anyone to use and learn from.

Max

The motivation behind working on open-source projects has changed a good bit since I started working on projects, mainly the positive feedback and developers I've met that are very easy to work with and have turned (Organizations) more into a (Family).

xXJSONDeruloXx

I think the problem-solving aspect has always appealed to me, but lately I’ve also found a lot of motivation in seeing people enjoy what we’ve created and in seeing them contribute their own fixes and features. A couple of people have even told me they appreciated the mentorship I provided through PR reviews and design discussions, which has been especially rewarding.

I clearly remember the guidance I received when I first started contributing to Bazzite and submitting plugins to Decky Loader. It feels like a real full-circle moment when I realize I’m now able to offer that same kind of guidance to someone else.

Kimchi

It's the social interactions with the communities for me. I like helping out, especially projects I believe in.

Astro Sky

For me, it's all about having fun. If it's not fun, I don't give a crap about it. That's just me, though. Other people have different priorities. Open source or not, if I'm not enjoying it, I'm going to move on.

What's changed for the better is the experience of developing. AI lets people iterate on ideas much faster. There are things I wouldn't have been able to do without that assistance. To me, it feels like the age of the people: more people can take ideas and build them instead of being held back by gatekeeping or being locked into a platform.

The412Banner

Bannerlator is my continuation of Winlator Star Bionic. It's a Windows-games-on-Android app: Wine and Box64/FEX inside containers, with my own Turnip driver builds and fixes. Bannerlator is also where our Wayland support was born: a full Wayland session on Android that doesn't need root. It was built from the inspiration and work of astrosky, who ran Wayland in Termux using root; I set out to do it without root. That became a gamescope runtime inside Bannerlator, with a real Arch Linux ARM rootfs under PRoot and an in-app Wayland compositor. DroidDeck was lifted out of that runtime. WinNative is Max's personal project, and it was solving many of the same problems on its own path.

Max

With WinNative the whole goal of it was taking the best of Winlator Ludashi (Performance) along with the best of GameNative (Stores) and turning it into the powerhouse emulator with custom drivers that maximized GPU clocks and forced performance. Basically I wanted to squeeze every inch of performance out of my device and allow the community to also benefit from those gains.

xXJSONDeruloXx

Before DroidDeck, I was a heavy contributor to GameNative. I worked on the performance HUD, suspend and resume policies, FPS caps and scaling modes, LSFG-VK integration, Amazon Games support, and many other features.

A lot of the problems I found myself solving were things that Steam and SteamOS already handle as part of the core experience. That made me feel that the more sustainable approach wasn’t to keep recreating those systems independently, but make better use of the infrastructure and conventions that already exist.

That became one of the ideas behind DroidDeck: instead of treating each feature as an isolated implementation, build toward a more integrated handheld experience by connecting Android, Linux, Steam, and the existing compatibility layers more deliberately.

Kimchi

I was not involved in these projects besides some testing.

Astro Sky

Banner and the rest of the team work together in different ways, almost like a spider web. I see my work as a separate spider web that happened to cross paths with theirs. I wouldn't call myself a direct developer of Bannerlator or WinNative. I helped along the way through my own work and experiments. Knowing some of that benefited other people is something I'm proud of.

The412Banner

Most Android PC-gaming apps run Windows games one at a time inside a Wine container. You lose everything Steam gives you: the real library, cloud saves, achievements, Steam Input and Proton updates from Valve. I wanted the real client, unchanged and fetched from Valve, rather than a front end that imitates it.

Max

Steam Client refusing to launch and work properly in full, this was always a goal of mine and a limitation on all emulators but sometimes we could make steam work with special versions and commands to launch steam along with specific proton versions (it was a nightmare).

Kimchi

Limitations? These guys are bosses. They overcome anything lol.

Astro Sky

Software compatibility, definitely. A lot of the software I wanted to run wasn't designed for Android. Figuring out how to get it working on a different platform was the limitation I most wanted to overcome.

The412Banner

I first met Max in his own Discord server, as a user. I was using his work and his techniques to get better myself. As my knowledge and basic skills grew, I started helping out where I could, and eventually I earned a mod role to take some of the load off him in the server. From there it has grown into a friendship and a partnership in the community.

The repos show how quickly that turned into DroidDeck. I started the DroidDeck repo on 2026-09-19. By 2026-09-22 I had already ported Max's NetworkManager stand-in from WinNative, and an audit of our shared shims found no functional difference from WinNative. So it wasn't really independent: from the start, we were working on launching gamescope and the Steam client together, privately.

Max

AstroSky actually was posting his work that he had Steam working on Wayland using GameScope with a rooted device through chroot, he handed his research over and asked for us to continue working on it to help the emulation community and try to get a non root method. The412Banner was able to get the rootless Wayland working and I got GameScope and Steam working which turned us into talking with xXJSOMDeruloXx and tying all of this together into what is now known as DroidDeck. Basically it was a project that was laughed about on Reddit originally by AstroSky and now everyone loves it.

xXJSONDeruloXx

I joined the project a bit after that reddit post, so pass on this one I guess?

Astro Sky

I met them through Discord, including the Winlator community. A lot of us were in the same circles. As far as I knew, they weren't working on Steam's ARM64 client at that point. Their focus seemed to be more on compatibility, which is why I think my experiments were useful.

People were starting to discover Valve's ARM64 Steam work through betas, depots and different client releases. My understanding was that people getting it running on the Switch had pieced things together that way too.

The412Banner

It was a team project from the start. DroidDeck came from combining my Wayland work with Max's gamescope work, and that combination is what became the standalone app we now call DroidDeck. The Droid-Deck GitHub org, created on 2026-09-24, gave it a shared home. 0.2.0 on 2026-09-28 was the first release from the org, with Max, Kurt and me all credited.

Max

We all worked on our own projects, we determined instead of copying everything into our own versions we might as well go all in on one project together and just make it the best that we could giving the community the absolute best experience instead of splitting the community into different projects.

xXJSONDeruloXx

I reached out to Banner pretty much immediately after that initial Reddit post expressing interest in the stand alone application that at the time was called “steamdeck”. Before that, the emphasis was more on the added “Steam mode” for Bannerlator and WinNative. I wanted to bring my experience working with Steam OS, Decky plugins, Bazzite, and Armada to help inform what the app needed to properly capture the Steam OS experience.

Kimchi

Breakthrough conversations happens all the time, as discoveries of new systems, patches, methods do. You never know how far you can get because project like these rely on the development of components that other parties work on. This keeps it exciting.

Astro Sky

It was gradual. It's hard to pinpoint one conversation or moment. I ended up stepping away from my own version after getting a lot of negative reactions to the work. I was enthusiastic about where Android could go if these ideas worked, but some people felt I was overhyping it. A lot of the developers around me were focused on the Winlator approach at the time.

Seeing the direction DroidDeck eventually took made me feel there was something worthwhile in what I'd been exploring. But I digress.

The412Banner

• From Bannerlator: the rootless in-app Wayland compositor (inspired by astrosky's rooted Wayland-in-Termux work), the PRoot + Arch rootfs runtime with gamescope, the Turnip driver handling, my DirectAudio PulseAudio sink, and the file manager (ported whole into 0.1.4).
• From WinNative: the runtime shims, input and controller work, the NetworkManager stand-in, and Max's port of LSFG frame generation.
• The README credits both projects for "runtime, shim, input, and controller work."

Max

Wayland, Gamescope and the Linux Arm Steam Client

Astro Sky

For my own experiments, it was DroidSpace and getting a native Arch Linux ARM64 container with Wayland running alongside Android. Using DRM leasing to drive an external screen through DisplayPort Alt Mode was where I started having the most success with the idea of turning my phone into a Steam Deck. The team can speak to which parts of their own earlier projects became DroidDeck's foundations.

The412Banner

It was planned. Max put together the original gamescope runtime and shared it with me. At first neither of us could get the Steam client to boot, so we each went to work on it in our own emulators, Bannerlator and WinNative, trying to reach a login screen. The first successful login screen was in my Bannerlator repo, on 2026-09-17. After that we both kept building it into our emulators, sharing the work back and forth as we made progress. Then we decided a standalone app would be better, both for the community and for us: all the work in one place, with a new interface we built ourselves to make things easier for new users and the community.

On 2026-09-19 I created that first standalone app in my personal repo. It was called SteamDeck at first: one screen and one button. Install the runtime, press Play, and Big Picture comes up. Kurt was brought onto the team on 2026-09-22, and on 2026-09-23 the app was renamed DroidDeck.

Max

It sparked excitement when we were launching Steam inside a Linux Runtime on Android, it was a completely new way to run PC games vs the old fashion Winlator methods and it was groundbreaking, we seen the potential and the future of emulation and decided it needed to be a new emulator.

xXJSONDeruloXx

I became a strong advocate for doubling down on a standalone app because it was clear how powerful it could be to boot directly into a real Steam environment.

I also felt that moving away from a Winlator-style approach where compatibility depends on separate glibc/Bionic Wine containers, and instead letting Steam manage compatibility tools and Proton prefixes would help DroidDeck stand apart from existing solutions. It could be more integrated and make Android PC gaming accessible to an entirely new audience.

Astro Sky

I wasn't involved in those discussions. I knew they were working on it, and they sent me a message when DroidDeck first released. I checked it out and was impressed. They did a really good job on the interface. Honestly, I think it's one of the best attempts at bringing that PC gaming experience to Android. I can see why it got so big.

The412Banner

I was sitting on my couch at home, talking to Max and reporting each small step of progress. On 2026-09-17 it finally booted to a Steam login screen in Bannerlator, and I almost jumped right through the ceiling. Two days later, the standalone app's second runtime build reached the same Big Picture sign-in screen on my Ayaneo Pocket FIT.

Max

We were excited sending pictures / videos back and forth and helping each other debug and bring it to life over several days/weeks until we had the foundation for DroidDeck.

Kimchi

I thought to myself: “We are here. The future is now” with my arm hairs standing up.

Astro Sky

Just getting it to launch was a challenge. I ran into problems with Chromium Embedded Framework, or CEF, and the Mesa drivers needed changes and patching. When I finally got it working, I was really happy.

With that setup, some games that hadn't worked for me before started working without me modifying the games themselves. My earlier experience with the x86 Steam client had been slow, buggy and resource-heavy. Getting the ARM64 client working felt like a big step forward.

The412Banner

FlatOut. It's one of my simple DirectX 9 benchmark games. I test new things with it first, before I move up to DirectX 11 and to extras like multiplayer or online sign-in. On 2026-09-20 the 0.1 notes record a full loop on hardware: sign-in, Proton ARM64 fetched by Steam itself, FlatOut installed from the store and running at 144 Hz. The same build ran LSFG 2× frame generation in FlatOut, from 60 fps to 118.

Max

Final Fantasy VII Rebirth, it was my ultimate goal to run as it was never ran on Android before, it took about a weeks worth of debugging, logs and testing until we could get the game running properly with new patches that made it to upstream at Mesa.

Kimchi

One game I particularly wanted to make work so badly was Burnout Paradise Remastered.Because this game required support for the EA app, which DroidDeck supports. Other emulators do as well, but they missed a part of the compatibility to make the game boot. That and the fact that this game also possess Denuvo DRM, one of the things that still stand in our way.

And it works btw!

Astro Sky

Garry's Mod. It's a lightweight game, but raw performance wasn't the challenge. In my setup, getting its Chromium-based interface working properly was the difficult part. Launching a map manually wasn't the same as having the menu and the rest of the experience working.

When I finally worked around those problems, I showed it off a lot. Some people didn't find it impressive because it isn't a demanding game, and they were right about that. But to me, the exciting part was compatibility, not FPS. It made me think about how many other things might become possible.

The412Banner

It started feeling real once we had games running, and running fairly smoothly, even through PRoot. It felt even more real after our first announcement, when we saw the community's feedback and support, and when Kurt joined the team. On paper, 0.2.0 on 2026-09-28 marks the shift: the first org release, labelled beta, with a launcher built for handhelds, home-screen mode, controller navigation everywhere, and no Linux knowledge needed to reach a game.

Kimchi

User Interface friendliness and compatibility. Those are the two foundations that users may decide whether the app is worth using or not.

Astro Sky

A lot of people like the Steam Deck, but they already have a phone in their pocket. I envisioned pulling that phone out, attaching a gamepad, and having that kind of handheld PC gaming experience without buying a separate gaming device. That was the vision I saw.

The412Banner

No, neither Max nor I expected it. We were already grateful for the small following and support we had from our past projects. But the positive feedback we got at the start left us in awe, and we're still extremely grateful for it today as the project keeps growing. The pace is in the record:

The org repo now has about 13,800 stars and 711 forks (GitHub API, 2026-10-24).

Max

The community took to it so fast, it was remarkable on how much love the community was giving DroidDeck, we thought it would do well but never expected it to do this well so fast.

xXJSONDeruloXx

I think I first contributed on 0.1.6 or 0.1.7, but I consider 0.2.0 (which was the first on the Droid-Deck Github org) to be the real “launch” of DroidDeck.

For those releases, I was still learning my way around the codebase, and adding fixes or functionality wherever I felt friction. Small things like not having steam Guide/QAM buttons accessible were detrimental to navigation at that stage, and that even led to the feature to set DD as your home app, so the home and back buttons could be just like the Steam and QAM button on a real deck. Other things like getting the startup to a reasonable length and QoL expectations like Decky loader and easily accessible proton prefixes were a big focus to making the app familiar to Steam OS users.

I always expected there to be a demand for what we were building, but the amount this project has grown and caught on in such a short time is nothing I could have ever predicted.

Kimchi

I had people Dming me to stop updating so fast hahaha

Astro Sky

I can't speak for the team's initial development period, but I expected this direction to get big. Months earlier I was telling people, “Guys, get ready.” I believed the compatibility work Valve was doing would create opportunities for Android too. I didn't know exactly which project would bring it together, but I felt something like this was coming.

The412Banner

There are three maintainers in the Droid-Deck GitHub org, plus Kimchi (K11MCH1), whose Adreno driver work goes back much further than any of ours. Counting merged pull requests on the main repo as of 2026-10-24:

The repo has 628 merged PRs in total from 58 contributors, so a large share comes from outside the core team.

xXJSONDeruloXx

I’m more or less the frontend guy, and the one who works toward aligning things to Steam OS proper where possible. Things like ensuring MangoHud is fed the correct values from Android’s device tree for various chipsets, making sure gamescope sessions and xWayland servers behave the same way they do upstream, and fixing framepacing to not conflict with Android’s surfaceflinger.

I also work on features that broaden what DroidDeck can do and which devices it can support: Steam Deck-style controller input, second-screen controls, VR, and GPU driver automation for different chipsets, for example. I like connecting the visible experience to the lower-level work it depends on, and I often end up following a feature from its interface down to the runtime and back onto a real device.

Kimchi

I'm not a developer yet but I do plan in contributing in the future. Right now I'm helping out with ideas, tests and managing the community.Max, is an eccentric guy. I think he just absolutely loves making things. He is a multitasker to a fault. Always on the move, always fixing bugs and implementing new features.The412Banner is a resourceful ideas-man. He's always got ideas and things he finds through contacts or projects he follows that develop certain things with the possibility to implement into DroidDeck.

I didn't meet xXJSONDeruloXx before DroidDeck so I'm just learning to know him. However, he is friendly, chill and seems competent with what he does on this project.

An amazing bunch and I'm blessed to be part of the team!

Astro Sky

I go by Astro Sky. I'm an independent experimenter, not someone who can speak for the whole team's responsibilities. I'm just a dude who likes projects and pushing hardware beyond what it was meant to do.

The412Banner

Mostly defined areas, as the table shows, with overlap when a bug crosses lines. The stores in 0.4.0 are an example: Kurt, Max, Gustash and I all have PRs in that one feature.

Max

This project has actually been an amazing one to work on with such great people, everyone has contributed so much time, effort and has worked very easily with everyone, we communicate every big decision with each other and vote on big changes. It's been a very smart system for us as we've all agreed on fundamental items that will never be put into DroidDeck such as pay walls or ads as well as items that will always be in DroidDeck since as 100% Open-Source will always be available and never hiding any code in pre-built binaries including our drivers.

xXJSONDeruloXx

I think put simply, Banner does a lot of the innovative experimental work, Max specializes in performance and optimizations, and I pride myself on polish and user experience. Beyond those niches we all contribute to bug fixes, issue triage, PR reviews/merges, and CICD.

Kimchi

So far from what i've seen they just contribute wherever needs attention.No particular guidelines.

Astro Sky

Honestly, I mostly yap their heads off about whatever I'm working on, even when it's completely unrelated to what they're doing. It's a gesture of friendship. I'm sharing things I love and hoping they'll love them too.

The412Banner

DroidDeck fits around my real-life job. My day starts at 4:00 a.m., when I wake up to work a 12-hour shift from 6:00 a.m. to 6:00 p.m., six days a week, Monday to Saturday. First I check what feels like 100 pings on Discord alone, then the support requests and bug reports. Then I slowly pick up where I left off the day before. Along the way I collect feedback, whether users send it to me directly in DMs or it comes from social media posts that are getting attention, good or bad. I bring all of it to the team so we can go over it together, pick it apart, and brainstorm how to tackle it.

The structure that lets us move fast:

• Every pull request gets its own signed test APK, published as a pr-<N> prerelease.
• Every push to main produces a signed Preview build.
• Testers install either from the app's Updates page without waiting for a release.
• I usually build features on branches in my own fork first, then open the org PR.
• CodeRabbit reviews PRs automatically before a human does.
• Coordination happens on Discord.

Max

A lot of time goes into bug testing PR’s and reviewing issues as well as trying to reproduce issues to fully understand what is going on so we can fix issues without creating more.

xXJSONDeruloXx

We all have a good sense of who is taking on what, and we all develop in the open. We all typically use an open pull request as a way of building a signed apk for testing, so that makes a clear signal of who is touching what. This also helps us rapidly iterate and validate with testers, as in the app we have update channels that let users immediately run a build from a maintainer’s PR push without leaving DroidDeck or having to log into Github.

We also have a general approach to outside contributions, where for the most part we don’t request changes, rather we push the changes we want on the PR branch and then merge it when it’s in good shape. We also have manual and label based triggers to sign PR builds from outside contributor PRs to facilitate testing that way.

Our process and pipeline is built in such a way that the bottleneck is never person to person communication, and that has been huge for our output

Kimchi

Usually someone starts with an idea of a feature or a fix to a bug; or show their progress on something they have been working on, and we just nod and approve.When there are no ideas, devs just spend their time squashing bugs.It is more exciting than explained though haha.

Astro Sky

I get up, drink a coffee, and obsess over whatever project has my attention. Right now, that's VR and making the PSVR2 usable more like a standalone headset, with an Android phone in my pocket providing the computing power.

In my setup, I've got hand and controller tracking working, with games running on the phone or streaming from a PC when needed. The idea is a lower-cost OLED alternative to that Quest-style experience, without being tethered to a PC. The headset still connects to the portable setup. I've got it working and I'm still developing it. The DroidDeck team can explain their own day-to-day release coordination.

The412Banner

We generally agree, and that's a big part of why we work together so smoothly and get so much done. When we don't, we brainstorm further, figure out what we each agree on, and meet somewhere in the middle. To this day I don't think we've had a flat-out disagreement about anything. If we ever can't reach a simple agreement, we take it to the community and hold a vote in our Discord server to get users' feedback.

Max

We do a simple vote, we will see if the other devs agree or disagree with a major change and if we can get majority vote then we don't pursue the change.

Kimchi

There haven't been any incidents concerning disagreements yet. Most of the decisions we make we vote on. Decisions need to make sense for the project scope and make sure they do not affect the user negatively.

Astro Sky

I'm not involved in the team's internal decisions, so that's best answered by them.

The412Banner

Kimchi's, and it predates DroidDeck. His AdrenoToolsDrivers repo has been one of the go-to sources of Turnip drivers for Android emulation since 2022. When I first got into PC emulation on Android, I knew next to nothing and could barely set up GameHub, and his drivers were part of what made any of it work. Having him on the team now is a full-circle moment for me. Others from the record: Kurt's Steam Deck controller emulation, which gives games Steam Input exactly as on a Deck. Kurt's cut of Steam startup from about 31 seconds to about 6. Max's PRoot fast-path work, up to 57% faster in measured workloads.

Max

AstroSky laid the foundation for what DroidDeck is, a lot of the initial features came from his chroot work with Wayland and GameScope.

Keegan is a trooper too, he's working hard answering questions and holding down the Q&A’s in discord while we're being hammered with new users at rapid rates throughout the day.

Kimchi has been an amazing help with debugging and finding solutions to issues that we didn't have in front of us.

Everyone of them are basically family and help/support in their own ways to DroidDeck.

xXJSONDeruloXx

Max’s work on the AR glasses to work in Steam VR, and his huge gains on proot with fastpath! And Banner with the rust download engines for non steam stores!

Kimchi

I can't really think of any. I admire it all!I tested 2 mockup versions before DroidDeck that only very briefly saw the light of day. If the world had seen them, they would be even more amazed with DroidDeck.

Astro Sky

I admire the whole team for taking these ideas, making them look good and making them approachable. That was something I felt was missing from a lot of earlier projects. Getting software running is one thing, but turning it into something people want to download and use is another. They deserve a lot of credit for that.

The412Banner

The app is a normal Android app. When you press Play it starts a full Arch Linux ARM system inside PRoot, with no root needed. Inside that it starts gamescope and Valve's native ARM64 Linux Steam client. Steam is downloaded from Valve on first launch, and we don't redistribute any of it. When you launch a Windows game, Steam hands it to Valve's ARM64 Proton. Only at that last step does FEX come in, to translate the game's own x86-64 code.

What runs when you press Play and launch a Windows game · 6 layers

Audio goes from PulseAudio through my DirectAudio sink to Android. Your controller is presented to Steam as a Steam Deck controller.

Astro Sky

What I appreciate is how much work is already done for the user. DroidDeck brings together earlier projects and compatibility work so you don't have to figure out every piece yourself. The team works on testing games, addressing problems and providing the components you need.

From the user's side, the idea is simple: install it, download the required components, check compatibility information and choose a supported game. For the detailed breakdown of their implementation, I'd let the team explain it. I'm not the person to explain all the internals of Proton and FEX. There's Valve, the Wine developers, the FEX team and many other contributors behind this. It's built on the shoulders of giants.

The412Banner

It was the whole basis. Before it existed, the Steam client itself had to be emulated, which is slow and fragile. With a native ARM build, the client, its browser-based UI, downloads and Steam Input all run at full speed, and translation is left to the game. Valve also ships an ARM64 Proton, so Steam picks the right compatibility tool for us.

Max

It was very useful to help make this possible, although without it we would of proceeded down the x86-64 path which then steam would have to be ran through FEX which luckily isn't the case and we have the Arm Client at our disposal.

Astro Sky

For me, getting that setup working meant playing games I never thought I'd play on my phone. Other software too, but at the end of the day, games. Lots of different games. It opened up possibilities I hadn't had before.

The412Banner

For me it was PRoot and Android's sandbox. Android blocks syscalls that ordinary Linux takes for granted, such as rseq, faccessat2 and openat2. Stock glibc gets killed on its first new thread without something answering for them. PRoot does that answering, but every trapped call costs 15–60 µs against about 0.5 µs natively, all through one thread. That's why startup and loading were slow, and why Max and Kurt's fast-path work mattered so much. Graphics was the other hard part: Android has no normal Linux DRM device. Our compositor and a patched wlroots had to work through a stand-in GPU node.

Max

Drivers for sure, there are so many devices out there that have different system drivers and different games that require different extensions and fixes for their drivers to work properly, the same GPU in one device doesn't mean the same GPU in another is going to work the same with the same Turnip driver especially if the system drivers are different.

xXJSONDeruloXx

I'd say a combination of PRoot and FEX, both of which have pretty severe CPU overhead. Figuring out how to mitigate that through FastASM, caching, and configuring FEX flags more intelligently has been one of our biggest efforts to preserve performance and keep us competitive with other PC emulation solutions.

Astro Sky

Wayland, definitely. Getting the environment my Wayland setup expected working on Android was the hardest part. It wasn't just a matter of launching it. Getting those pieces to work together took a lot of effort.

The412Banner

The client running was day two. Everything after that is the real work:

• Controllers: a true Steam Deck controller over uinput/hidraw, with gyro and the Quick Access button.
• Audio: the DirectAudio sink, so sound doesn't lag.
• Downloads: they keep going while Android sleeps.
• Sleep: native Steam sleep and wake.
• Networking: Steam's Internet page shows real Android Wi-Fi.
• Speed: Steam startup cut from about 31 s to about 6 s, which is what made offline mode usable.
• Recovery: crash-safe logs.

xXJSONDeruloXx

Getting MangoHud to behave was a big one, and then there's controller integration, both the on-screen controller and the physical controls on Android handhelds.

The extra buttons on these devices are usually forced to be bound to something on XInput, and then you have Android's Back and Home buttons. We needed ways to expose the Steam Guide and Quick Access Menu buttons, whether through software buttons or optional on-screen controls.

I added double-clicking Back to open the Quick Access Menu, which also led me to adding the ability to use the device's Home button as the Steam Guide button when DroidDeck is set as your home launcher.

Those were all challenges because these buttons aren't traditionally exposed to Android applications in the ways we needed. But setting DroidDeck as the home launcher, for example, lets us make the Home button behave like Guide, which plays a surprisingly large role in your moment-to-moment perception that this is a native Steam experience.

Astro Sky

CEF was a big obstacle. I was running into compatibility problems with the Mesa drivers in my setup. Driver fixes were being worked on, but a lot of my progress came from exploring, changing things and experimenting until I found a combination that worked.

The412Banner

We don't replace Android or install an operating system. DroidDeck is an app. Inside it runs a Linux userland with Valve's real Steam client in the same Deck mode SteamOS uses. You get the SteamOS experience, not SteamOS. Android stays in charge of the hardware, and you can switch back to your Android apps at any time.

Max

It's not really “SteamOS” on Android but it is Steam and Steam Big Picture Mode on Android running natively.

xXJSONDeruloXx

I think we take a little creative liberty there. One of our taglines on GitHub is "Bringing the SteamOS Experience to Android," because even though we're not using the exact upstream packages or filesystem images, when people talk about SteamOS or the SteamOS experience, they're really talking about booting into a session, with gamescope as the micro-compositor, and Steam running in Big Picture Mode with specific flags for the ten-foot interface, Steam Deck-style performance menus, there's no traditional windowing and games are scaled through steam itself, Decky loader works (sometimes), and so on.

Kimchi

What people recognize as “SteamOS” is mostly the Steam client’s Big Picture interface. DroidDeck runs that interface, but not the operating system underneath it.

Astro Sky

It's not replacing Android with SteamOS. Android is still there, but you're bringing together familiar pieces of that Linux gaming stack, like Gamescope, Wayland and the Steam client. That's why people make the comparison. I mean a Steam-style gaming experience on Android, rather than literally installing SteamOS.

The412Banner

• x86-64 Steam sign-in: the x86-64 Steam client refused the ARM64 client's sign-in. We found out why by reading Steam's saved token format.
• Game hooks under FEX: some games write hooks into their own code with WriteProcessMemory. Under FEX, Android's kernel refused the normal call, so we fall back to /proc/<pid>/mem, the way older Wine did it.
• A display that isn't a DRM device: Android's GPU node is not a DRM device, so a check that should have said "no" said "you're in charge of the display". We had to stop trusting that answer.
• Steam Deck controller: the Steam Deck controller only worked once we emulated real uinput and hidraw devices. Neither Bannerlator nor WinNative had done that.

Max

Yes, we've had to modify proot to run better and faster with new fast paths and other optimizations to fix performance issues initially.

Astro Sky

Lots and lots of crashing. The Wayland setup would crash, CEF would fail to start, and the phone would get hot. When graphics acceleration wasn't working, I'd see software rendering hammering a CPU core.

Software fallback could get something running, but in my setup it came with significant heat and CPU usage. Getting GPU acceleration working was the whole point. I didn't want the interface eating up CPU resources the game needed.

The412Banner

Until this project came along, the only way to run the full Steam client, and run it smoothly, was on an actual Steam Deck or a PC. The community projects offer something close to what the real Steam client and its ecosystem can do, but they're all hacked together in a sense. The community has done fantastic work, but every project has its own interface, methods and menus that take time to learn.

This project brings the real, legit Steam client to anyone with an Android device and a Snapdragon chip, with more support coming. It doesn't hurt your bank account, and it runs on the same device you carry in your pocket every day. Everyone who plays Steam games already knows this ecosystem, and if they don't, it's well known and easy to learn.

Launching a game is the easy part to show off. What makes a Steam Deck pleasant is everything around the game: your library, cloud saves, achievements, Steam Input layouts and the Quick Access menu. Steam updates Proton for you, and you never see a config file. If we only launched games we would be another Wine front end.

Max

The Steam Deck was one of the big first pushes of mobile gaming for PC gamers. It really provides one of the best experiences for gamers on the go especially with big picture mode and almost everyone's dream has always been (I want to run steam on my phone). So turning your device into basically a steam deck experience is ideal here.

xXJSONDeruloXx

I think it's important in the same way that Steam as a platform is important, because it's more than the sum of its parts.

If I'm in a game and I want to hit the Guide button to read a write-up someone made in the articles section, quickly glance at my achievements, see that a friend went online, check the store page and reviews to see if I really want to power through a boring part of the game’s intro, or pull up a Decky plugin that does something unique, that's all part of the SteamOS experience. And it's something you can engage with while you're still playing a game.

When you're just launching an executable inside a Windows container on Android, that's pretty far removed from what makes Steam special.

Astro Sky

Valve had already done so much work on that experience. Big Picture gives you an interface built for a controller and a TV, and the Steam Deck showed what that could mean for portable gaming.

I wanted that on Android, not just a front end that looks like Steam. Having the actual client and software behind it working together mattered to me, both for compatibility and making it easier to use.

The412Banner

The line for me is that Android still owns the device: drivers, power, Wi-Fi, other apps. DroidDeck owns the experience on top. Since 0.2.0 it can be your Android Home app. Your Android apps sit in its launcher and in the session menu, so you can open one without leaving a game. Settings are reached from the controller, and a session keeps running in a foreground service when you leave it.

xXJSONDeruloXx

One thing we try to focus on is not duplicating effort that's already being handled by the Steam client or upstream components. That's pretty counterintuitive to how a lot of Android launchers and PC emulation solutions have traditionally approached things. We want to stay out of your way, but give you enough options and recourse that going the extra mile when something doesn't just work isn't unnecessarily painful.

And we want to be beautiful while we do it. That's where you'll see a lot of our unique designs and fluid motion transitions. It's one way we communicate that DroidDeck has its own personality and style. We want it to feel distinctly like DroidDeck.

But once you jump into Steam, we want all of that to melt away.

The fluidity of our transitions, the unique way focus moves with the cursor and borders, all of that is in service of communicating that you're in DroidDeck right now. That's completely different from how focus moves and how the design language is conveyed within the Steam client.

That's how we draw the line and communicate to the user where DroidDeck stops and the Steam experience begins.

Astro Sky

I don't have criticism of the direction they've taken. What impresses me is how much they've done without requiring people to root their phones. From my experiments, I know Android puts constraints on what you can access and change. The team deserves credit for working within those limits. Their exact design philosophy is something they can explain better than I can.

The412Banner

Not from day one, but very early. Kurt brought the idea to us, and it's a unique and creative concept: in his words, to "Deck-ify" any older device lying around that nobody uses anymore. It arrived in 0.2.0, nine days after the first commit. Yes, I can see people using it as the main interface on a gaming handheld, the way a Deck boots into Gaming Mode.

xXJSONDeruloXx

I added that one mainly as a workaround for Steam Guide and QAM not being easily mappable and making DroidDeck a home app let me address home button/gesture in Android. After having used it that way extensively though, I do think many people will “set it and forget it” and use DD as their primary way of interacting with their handheld, or reclaimed phone rotting in a desk drawer, whose primary purpose is now to be a makeshift steam deck.

Astro Sky

Oh yeah, for sure, especially on an Android handheld. That's the appeal: getting the gaming experience while keeping Android and being able to use the device normally. I've experimented with Linux on my phone, but most people don't want to go through all that. I dislike restrictions on what I can do with my own hardware. DroidDeck gives people a more approachable option.

The412Banner

That's the goal: sensible defaults first, with the knobs still there for anyone who wants them. Examples that ship today:

• GPU drivers → Auto detects your GPU and keeps a matched pair of drivers installed (0.3.0).
• Windows components are picked automatically from each game's Steam, GOG, Epic or Amazon dependency data, without running the old installers. That's my area (0.3.2, 0.4.0).
• Per-game profiles for Proton, FEX, DXVK and VKD3D inherit from your defaults (0.4.0).
• Updates install from inside the app, with every download checked against our release key.

xXJSONDeruloXx

Yes, we want to abstract that away as much as possible. One mantra we have is “if the user had to fiddle with settings or drivers, we have failed them in some way”

Astro Sky

It should be both. A lot of people don't want to fiddle around. They want their games to work, so compatibility and accessibility need to come first. Personally, I want those settings available too, so people who enjoy experimenting can get into them.

DroidDeck does a lot of setup for you but lets you fiddle around if you want. I think making games and platforms accessible can encourage more developers to get involved.

The412Banner

The variety. One app has to work on phones with no controller, foldables that change shape mid-game, and dual-screen handhelds. It also has to cover screens narrower than 16:9 and different Android versions. Android 14+ even needs a developer option turned on before Steam can launch. Touch had to work as both a touchpad and direct input. On foldables, Steam and the game now resize when you fold or rotate (0.4.0, @SG3xHERO).

Astro Sky

That's best answered by the developers doing the interface work. I can’t offer a device-by-device comparison. What I admire is the effort to make the result approachable rather than leaving users to assemble everything themselves.

The412Banner

One word: Turnip. Mesa's open-source Vulkan driver for Adreno is mature, actively developed, and built for desktop Linux workloads like DXVK and VKD3D. It also builds both as an Android driver and as a Linux driver from the same source, which is exactly what we need. Most other GPUs ship only the vendor's closed Android driver, and that driver can't be loaded inside a Linux userland.

Mali isn't hopeless, though. I run an experimental side project, droiddeck-nonadreno-drivers, with a test build for Mali, Samsung Xclipse and PowerVR. It uses PanVK and a Venus bridge for Mali, and RADV for Xclipse. Results from community testers so far:

• Salt and Sanctuary and Skyrim play on a Galaxy A15 (Mali-G57).
• Need for Speed Most Wanted runs at 50–60 fps on a Redmi Note 14 Pro 5G (G615).
• Brotato runs at 60 fps on a Pixel 10 Pro XL (PowerVR).

It's experimental and not an official release, but it shows the wall is the driver, not the app. Credit to Charan for the PanVK G615 builds.

Max

Having open source drivers has made this a lot easier for Qualcomm, now for Mali we don't have open source drivers so this makes things difficult to provide support for, we do however have experimental Mali support between the other devs and other contributors we're actually seeing Mali chips run games on DroidDeck but not in the same capacity as Qualcomm.

xXJSONDeruloXx

The simplest answer is Turnip and Mesa drivers, and the kind of proper open-source support that Mali and PowerVR currently lack.

There's some promising, very early work happening with PanVK, and we're encouraging testing with that.

Kimchi

Well, Qualcomm is supported not because Snapdragon is uniquely fast. It’s the only Android GPU with a mature open-source Vulkan driver that can run inside a Linux container and talk to the phone’s stock kernel. No driver that speaks the phone’s kernel interface. Mesa’s Mali Vulkan driver, PanVK, targets the upstream Linux kernel drivers (panfrost/panthor). Android phones ship Arm’s own kbase kernel driver, and mainline PanVK has no kbase backend. On a stock Mali phone, a glibc PanVK build has nothing to talk to. There’s no Mali equivalent of what KGSL support gives Turnip. But that might change soon.

Astro Sky

I can speak to how much drivers mattered in my own experiments, but not give a complete comparison of DroidDeck's supported GPU architectures. I ran into Mesa compatibility issues and had to experiment with changes and patches. The team and driver developers are the right people to explain the current hardware support limits.

The412Banner

Mainly the Retroid Pocket 5, with its Snapdragon 865. Then again, I own one and use it with my own overclock method, so I'm not entirely surprised. It's a very capable device from a fantastic, budget-friendly company that brings quality hardware to anyone.

My own path went through a Retroid Pocket 4 Pro, a Retroid Pocket 5 and an AYN Odin 2 Portal. Now I test on an Ayaneo Konkr Pocket FIT (G3 Gen 3) and a Samsung Galaxy Fold 8 Ultra (Adreno 840). The AYN Thor is a heavy test target for the team, especially for dual-screen work.

Astro Sky

I don't have a comparative handheld test list to offer. Most of what I've discussed here comes from my own phone experiments, rather than testing a range of dedicated handhelds.

The412Banner

The Snapdragon 8 Gen 2 is the closest chip below Valve's Steam Frame, which uses the Snapdragon 8 Gen 3. So it only makes sense to use the first step under what Valve's own development and hardware will use and support as our baseline. Its Adreno 740 is also in many current handhelds, such as the AYN Thor and Odin 2, and Turnip supports it well.

Newer chips, the Snapdragon 8 Elite and above, clearly bring much more power and a smoother gaming experience. That's especially true with the amazing work upstream Mesa is doing on the Turnip drivers, which makes PC gaming through emulation that much more possible. Our PRoot measurements were taken on an 8 Elite Gen 5.

xXJSONDeruloXx

I can really only speak for the 8 Gen 2 itself, as I've never owned a device more powerful than it.

But I'd say the 8 Gen 2 was a bit of a watershed moment for Android-based handhelds with the Odin 2. I specifically remember Russ from Retro Game Corps making a video about the Odin 2 where he pointed out that its hardware had surpassed the most challenging software available for it on Android.

I keep thinking about that now, because with things like DroidDeck and some of the more challenging seventh-generation emulators starting to find their footing, the 8 Gen 2 is almost minimum spec, and the 865 is ultra-minimum spec in a lot of respects.

I think that's pretty encouraging.

I've seen some amazing things with devices like the Odin 3 and the 8 Elite, and the announced 8 Elite Gen 6 looks pretty insane on the GPU side, which is exciting. But I don't have firsthand experience with that hardware.

I think the 8 Gen 2 has a really unique balance. It's cheap, it's old, the drivers are really seasoned, and it's good enough for Xbox 360-era games to run extremely well while just barely punching above its weight with some PS4-era games on the PC side.

It's a really good target for the kinds of experiences people want to pick up and play, or for grinding through decade-old games in their backlog while waiting in line or whatever.

Kimchi

The Snapdragon 8 Gen 2 has likely held the baseline for most Android projects longer than any other chipset. Its long run was largely a matter of timing: it had time to mature fully before a successor arrived to replace it. That baseline has now moved to the Snapdragon 8 Elite Gen 5. Although the chip is nearly a year old, it has received strong Mesa support, as Qualcomm’s collaboration helped bring Turnip support, compatibility and graphics feature exposure up to speed quickly.

Of course, newer chipsets offer substantial raw power over their predecessors. Especially with Turnip support.

Astro Sky

I haven't done the controlled comparisons needed to give a reliable generational performance answer. The team can explain its testing baseline.

The412Banner

A lot of it is drivers. A game that crashes, renders black or runs at half speed is often a driver issue rather than an app bug. That's why we built DD-Turnip: our own Turnip builds from Mesa main plus our patch set. Each build produces matching Android and Linux drivers from one Mesa commit, built daily when Turnip changes. Every release ships its full source (GPL-3.0). The app's GPU drivers tab picks a matched pair automatically. The latest is DD-Turnip v0.3.3 (2026-10-21).

Max

Driver development provides new optimizations and performance features to devices that cannot be rooted, an example is we can make the driver tell the system it's starving for power and the system will turn the clocks up and allow more power draw on the GPU which in turns increases performance. This normally would of requires root but these little tricks inside the driver allows a lot of optimizations that generally are not available elsewhere.

Astro Sky

Drivers made a huge difference in my own work. Getting something to open with software fallback wasn't enough if it hammered the CPU and heated the phone. Getting hardware acceleration working was an important part of making the experience usable. I wasn't responsible for DD-Turnip, so its developers should explain those builds and the remaining issues.

The412Banner

Yes, but it moves at the speed of open drivers. PanVK for Mali is improving fast, and RADV already runs on Xclipse. Venus can bridge Vulkan to the vendor's own driver in the meantime. Where a chip has no open driver and the vendor won't help, we're limited to bridges and workarounds.

Max

Yes, I do believe there is enough attention and contributors to really fight the compatibility issues until they're solved.

Kimchi

I think with Mesa support we can achieve compatibility parity across Android hardware.It all depends on the OEMs cooperation. Good news is that companies like MediaTek are finally starting to open up towards FOSS in particular Mesa.

Astro Sky

I want people to have more freedom with the hardware they own. My own experience showed how much access and driver compatibility can affect what's possible. I wouldn't promise universal support, but exploring those limits is exactly what interests me.

The412Banner

That's Kurt's work in 0.3.0. The difference from normal mapping is this. Normal mapping turns your buttons into a generic Xbox pad, and each game sees that pad. We emulate the actual Steam Deck controller at the device level, using uinput and hidraw. The Steam client then believes it's talking to a Deck. You get the real Quick Access button, your handheld's own gyro, back grips and trackpads, and Steam Input's full layout system, community layouts included. Bannerlator and WinNative never emulated uinput or hidraw; that missing piece is why my old Deck mode in Bannerlator never got its virtual pad. Since 0.4.0 the built-in controls can also be a Steam Controller, Xbox 360, DualShock 4 or DualSense, switchable live.

xXJSONDeruloXx

The tricky part was that Steam Input normally creates its own virtual controllers through Linux's uinput interface, which isn't available to us in the Android sandbox. I ended up emulating both sides of that interaction: presenting Steam with a virtual Steam Deck HID device, then implementing the missing uinput functionality so games receive Steam Input's output rather than the raw Android controller inputs.

I took a similar approach with our Steam Link touch controls, which was another pretty interesting rabbit hole. We're emulating the actual Mobile Touch controller protocol used by Steam Link, so we can use Steam's own per-game touch layouts, community configurations, and cloud syncing without actually streaming anything.

It's a lot of effort to make something feel like it's just working normally, but that's kind of the point. We want all the flexibility of Steam Input without making the user think about how any of it works (even though I just made you think about it right now).

Astro Sky

I wasn't involved in implementing DroidDeck's controller integration, so I'll leave the technical explanation to the team.

The412Banner

The second screen of a dual-screen handheld is unused real estate that sits right under your thumbs. The Deck has trackpads and back grips that Android handhelds lack, so putting them on the second screen was natural. Since 0.2.0 you can also put a keyboard and trackpad there, a Linux terminal, or an Android app while Steam keeps the top screen. If I'm not mistaken, the idea came directly from Kurt, who mostly uses and develops on his AYN Thor.

xXJSONDeruloXx

Developing and testing on the Thor really made it obvious that the second screen could be put to good use here. Once I got Steam recognizing our emulated Steam Deck controller, it seemed natural to use that bottom display for things Android handhelds typically lack, like Steam Input trackpads and back grips without cluttering the actual game.

But I also like that we're not limited to replicating the Steam Deck. I think the most exciting part is figuring out what we can do with that extra screen that even a real Steam Deck can't. We just recently got a request to have a second screen that would be arrow keys, in the style of a DDR dance pad! I am considering implementing it just cause of how fun that sounds.

Astro Sky

Those ideas and their implementation belong to the team. I wasn't involved in the design discussions.

The412Banner

I think it's a bit of a mixture: recreating Steam Deck features, plus new ways to play games and handle specific game features, while using the full potential of a user's device in a way that makes the game more enjoyable. So far it's both: Deck features we lacked (grips, trackpads), and things a Deck can't do, like a terminal or a guide app open beside the game.

Astro Sky

I haven’t worked on those second-screen features, so I’d leave that design question to the team rather than speak for them.

The412Banner

Foldables change shape while you're playing, so the hard part is resizing. Since 0.4.0, Steam and games follow the screen when you fold, unfold or rotate, and an optional touch gamepad sits below the game when unfolded. Both are by @SG3xHERO, a community contributor. Since 0.6.0, the unfolded controls can also stay while a controller is connected, for people who use a telescopic controller and still want the trackpads and back buttons (@ovurrsl). A dual-screen handheld has two fixed displays, so the work there is deciding what goes where. Honestly, building for any and all devices is exciting, since all of this was only ever meant to run on the official Steam Deck. Seeing lower-tier devices and everyday phones fluidly running and playing games with and through the Steam client in a Linux environment, and even devices with no Snapdragon chipset starting to run games in our experimental test builds, is just an amazing thing to me. Then when you add the desktop experience, that takes things to a whole new level: not only what's possible now, but what new doors can open up for the future.

xXJSONDeruloXx

That was almost all from an outside contributor, I don’t have a foldable myself, but it speaks to the amazing community involvement the project has curated to expand utility to new devices and form factors.

Astro Sky

I can’t offer firsthand development comparisons for those form factors, so that's better answered by the people implementing them.

The412Banner

Up to four controllers have worked independently since 0.4.0, through Steam Input, for local co-op and split-screen. The 2025 Steam Controller also works over Bluetooth LE (@SG3xHERO). Connect a handheld to a TV with a few pads and it's a small Steam console. Since 0.6.0, a session on an external display or DeX keeps running while the phone's screen is off, and the built-in controller can be turned off so a connected pad becomes player 1. Remote Play from DroidDeck now streams video as well, encoded by the phone's hardware encoder. We intend to make DroidDeck enjoyable not only on the go, on all kinds of devices, but also at home in the living room with family or friends, with multiple controller support, recently VR, and much more to come.

xXJSONDeruloXx

SteamDeck does it, Steam OS does it, so DroidDeck should be able to do it too. Regardless of the practicality of split screen on a handheld, it’s correct when it is able to match the features of the client in its natural environment.

That said, it’s kinda cool eh?

Astro Sky

That’s a question for the core team’s plans. I wasn’t involved in developing those features.

The412Banner

So far, I find that games that don't need Steam running alongside them launch and run more fluidly than games that need the client running, or games that need a third-party launcher: for example EA Desktop for select titles, or Rockstar's Social Club and Rockstar Games Launcher for Grand Theft Auto and Red Dead Redemption. The general pattern: older and lighter DirectX 9–11 games, indies, and anything with a native Linux ARM or x86 build do best. The trouble spots are kernel-level anti-cheat, which can't work here (since 0.6.0, Easy Anti-Cheat games with an offline mode start without it, but their online modes stay unavailable), and very heavy DirectX 12 games on weaker chips. Missing Windows components used to be one too, which is why I built automatic component detection. Adreno 6xx is the weakest case: DirectX 11 through DXVK 2 may run, DirectX 12 can crash.

Max

Games like RDR2 it had an issue which refused to boot which was a pathing issue to one dll, small bugs like this can cause games to refuse to boot or crash, but when we test games and see they don't work we fix them and it usually fixes a bunch of other games with it, currently 99% of the games I throw at DroidDeck run and play great.

Astro Sky

I can't provide a current DroidDeck-wide compatibility survey. In my experiments, Garry's Mod was a good example of why compatibility isn't simply about how demanding a game is. A relatively lightweight game can still depend on parts of the software environment that are difficult to get working. That's why getting the full setup right interested me so much.

The412Banner

Examples from the release notes: Red Dead Redemption 2 failed to launch until Max fixed it in 0.4.0. Slay the Spire 2 needed .NET/Godot launch fixes under FEX (0.3.1, @magarto). In 0.6.0, Red Dead Redemption 2's Story mode from an SD card library went from still loading after 16 minutes to the opening scene in about 2 minutes 10 seconds, and Ubisoft games that stopped with "Error at hooking API", such as Immortals Fenyx Rising, were fixed (both Max).

Astro Sky

Garry's Mod is the example that stands out. People saw a lightweight game and wondered why I was excited. But the challenge wasn't raw performance; it was getting the Chromium-based interface and the surrounding experience working in my setup. That was the breakthrough for me.

The412Banner

Mostly they make everything around the game faster, not the game's frame rate. During gameplay, PRoot already costs almost nothing: GPU submits, futexes, reads and writes all run at native speed. What PRoot taxed was file-path syscalls, process creation, and loading. The fix was a fast path: a small library inside each process answers common path calls itself instead of trapping into PRoot. On our test chip, stat went from 25 µs to 0.6 µs, and eight threads went from 89k to 3.6 million calls per second. Max and Kurt expanded that in 0.4.0 (up to 57% faster in measured workloads). Separately, Kurt cut Steam's startup from about 31 s to about 6 s. In 0.6.0, Max extended the fast path to SD-card libraries and skipped Steam's install-script step once it has finished for a game (Moonlighter went from 10.5 s to 7.7 s from Play to the game window). Steam is also ready 36% sooner after a session starts (5.57 s to 3.57 s). You feel it at launch, in loading screens and in asset streaming.

Max

The initial proot implementation was very rough, it worked but it was slow. Basically every system call would repeat over and over so many times burning usage up for no reason and we made some changes to proot with fast paths and fixed other issues where certain calls would repeat which led to huge performance gains.

Astro Sky

I wasn't involved in those optimisations or their benchmarks, so I wouldn't want to claim where the gains came from. That's a question for the developers who did the work.

The412Banner

The LSFG work comes from Camille LaVey and the Eden emulator project, following lsfg-vk. Max ported it to WinNative and then to DroidDeck. It runs inside our compositor on the final image, so it works with any game, and it reads the shaders from your own copy of Lossless Scaling. We ship none of them. In the first build, LSFG 2× took FlatOut from 60 to 118 fps. The trade-off is added latency and artifacts, so it works best when the base frame rate is already steady around 30–60.

Max

When Camille LaVey pushed a nightly build with their LSFG which basically converted the shaders into Vulkan and used them that way, it was then ported to WinNative and I personally spoke to Camille about using their work which they ended up telling me they were fine with it as long as I credited them directly. The LSFG built in is truly remarkable and works only if you own Lossless from steam, this is important as we want to ensure everyone using any product is paid for and supporting the developer of that program.

Astro Sky

I wasn't involved in that collaboration and can't speak for how it came about or its measured trade-offs.

The412Banner

We measured this on an AYN Thor on 2026-10-04. Two things hurt:

• The FUSE layer: Android's view of the SD card is much slower for directory access than the native mount, so we now use the native path where we can.
• exFAT metadata writes: the card is formatted exFAT and mounted with dirsync, so every file creation and size change waits on the card.

A fresh 1000xRESIST install preallocated 2,216 files in 6 m 44 s, 16 m 36 s in total. It's better than it was, but SD still doesn't match internal storage. It matters a lot on handhelds with small internal storage, so it's still open work.

Max

Initially this was the issue with proot where it would burn 50x the calls needed per file in a folder for a game, this has been fully optimized and is no longer a problem.

Astro Sky

I haven't investigated those particular DroidDeck reports. The team can give a better account of their causes and what is being done.

The412Banner

Following some of the incredible work Max has done finding bottlenecks, and adding ntsync as an option for playing games (it wasn't there from the start; it came in 0.3.1), I've certainly noticed FPS improvements in my games, along with lower memory use, less heat and lower CPU usage. What the app gives you: a per-mode frame limiter, a resolution cap, the performance overlay with temperatures and battery, and Force SSBS for ARM64 games. Capping the frame rate is the simplest way to trade a little smoothness for battery and heat. Since 0.6.0, the overlay can also show a frame-time graph and the battery temperature. A suspended session now lets the device really sleep (before, a Thor did not suspend once in 13 minutes), and the session is moved to zRAM first, so Android is less likely to close it overnight.

Astro Sky

Heat was definitely a problem in my experiments. When acceleration wasn't working and the interface fell back to software rendering, I saw heavy CPU usage and significant heat. A game launching isn't the whole story. In my setup, getting the display and interface accelerated properly was part of making it practical. I don't have battery-life or sustained-performance figures to quote here.

The412Banner

It already does in places. GPU drivers pick themselves (since 0.6.0 from a manifest we can change without an app update, and a trial driver that crashes at startup rolls back automatically), Windows components come from each game's dependency data, and Steam's Proton recommendation is the default. Per-game profiles inherit from your defaults. As we progress through our roadmap and hit our milestones and goals, one of the things we hope to achieve is something equal to recommending settings automatically. What we actually have an idea and a plan for is something even better, but I really can't go into it much further yet.

Max

We are actually aiming at full automation when it comes to compatibility with devices and games as well as Valve upstream are fixing a lot of the issues for games and we have Mesa upstream fixing issues as well as they fix issues they also fix them for DroidDeck.

Astro Sky

My preference is both accessibility and control. A lot of people don't want to fiddle with settings; they want to play. I want the setup work handled where possible, while keeping settings available for those of us who like experimenting. I can't speak to the team's roadmap for automatic recommendations.

The412Banner

Yes, from the very first release. 0.1 on 2026-09-20 shipped Steam and an LXQt desktop side by side, because the runtime is a real Linux system, and hiding that would waste it. Kurt replaced LXQt with a SteamOS-style KDE Plasma 6.7 in 0.4.0, including Return to Gaming Mode, so it now feels like a Deck's desktop mode. 0.6.0 moved it to KWin 6.8.0, and desktop mode can now be uninstalled while games, Steam and settings are kept.

Max

It was always intended to be a part of the project, we all discussed that since we're running a Linux Runtime the users should be allowed to make the most out of it and have a full desktop experience which could be the new “DeX”.

Astro Sky

I wasn't part of that decision, but Linux on a phone was what first caught my attention through Termux. I hadn't realised how much a phone could do beyond its usual apps. That curiosity carried into my container experiments. The team can explain when its desktop plans took shape.

The412Banner

Equally both. I grew up in the '90s, and I still find myself playing a lot of old classics: Donkey Kong, Mario, Excitebike, Mike Tyson's Punch-Out!!, Crash Bandicoot and Sonic. And having a little or all of everything available in one place makes things so much easier for a user: no keeping track of different apps, just one single game library with a built-in launcher that is simple to use and navigate. The useful part is what Linux opens up. Some emulators have no Android version, or a weaker one. PCSX2, Dolphin and Cemu had no ARM64 Linux build upstream, so we compiled them from source against the runtime's glibc. RPCS3, DuckStation and melonDS use their projects' own ARM64 builds, and ARMSX2, PPSSPP and RetroArch are there too. The Flathub store adds any ARM64 Linux app.

Astro Sky

My gaming history goes back to Mario 64, Banjo-Kazooie, the Dreamcast and the PSP, so older games are a big part of my memories. But I can't speak for the team's emulator integration strategy. Personally, the appeal of Linux software on Android was discovering things I hadn't thought a phone could do.

The412Banner

That's one of my main areas. Plenty of people own games on more than one store, and a handheld shouldn't make you choose. The goal was that a GOG or Epic game behaves like a Steam game: it launches through Steam, so you get Steam Input, the overlay and the same Proton. GOG and Epic also sync cloud saves. It builds on Phobos's adaptation of Legendary and heroic-gogdl. GOG install scripts are read the way Heroic reads them. Credentials are encrypted with Android Keystore. The hard part is that each store packages games differently: installers, dependencies, registry entries and launch rules. In 0.5.0, Max added Epic's own Linux launcher running under FEX, so Epic games get the same sign-in and online services as on a PC. 0.6.0 added experimental Xbox and PC Game Pass (Kurt and @moronigranja) and itch.io (@kingokksa), and redesigned every store page with Library and Store tabs and a capsule view.

Astro Sky

I wasn't involved in those storefront integrations. The team should explain their motivation and implementation.

The412Banner

Gaming is absolutely the focus. The desktop and apps are a significant bonus that unlocks more creative ideas and ways to use some of these games, or a user's device, that people would never have anticipated. And that's without needing root or flashing a completely separate operating system, all while still enjoying their phone or device the way it was meant to be used out of the box. Everything beyond Steam is an optional download, so someone who only wants Steam never installs the 1.1 GB of desktop and emulators.

Max

We aim at making both the Linux experience and gaming experience (on Android) second to none. For those who don't wish to install a new OS we want this to be exactly what they need.

Astro Sky

My own experiments have included games and other software. What interests me is pushing the hardware beyond what people expect it to do. DroidDeck's scope is a decision for its developers, though, not something I set.

The412Banner

This is my other main area. In 0.5.0 I added an optional x86-64 Steam client: Valve's normal Linux client running under FEX beside the ARM64 one. Games with a Linux version, like Team Fortress 2 and Half-Life, can run their Linux builds there. Since 0.3.1, Max's work also lets Linux-only x86 Steam titles run through FEX with Steam's Linux runtime. Native ARM64 Linux games would be the best case of all, with no translation layer. That needs developers to ship ARM builds, and that will follow the hardware: more ARM PCs and ARM handhelds.

Max

Native Arm Linux games would be able to run without any translation layers and get peak performance, this would truly be a game changer for performance, heat and battery usage.

Astro Sky

The possibility of running more software on ARM is exciting to me, but I’m not the right person to give a detailed forecast of that ecosystem.

The412Banner

The attention has certainly been overwhelming, exciting and humbling, and scary at the same time.

What surprised me is the range of people. We get users from all across the spectrum, from people brand new to Android all the way up to veteran emulation gamers. That includes developers and contributors from across the community we never anticipated.

For scale: about 13,800 GitHub stars and 711 forks on the org repo in its first month (created 2026-09-24), with 452 open issues and PRs combined, 628 merged PRs and 58 code contributors on 2026-10-24. 0.6.0 alone had 153 pull requests from 23 contributors, 73% of them from the community.

Kimchi

Anti-AI users xDJokes aside, it was great to be in the spotlight again.It's no surprise to me since many people have been waiting for this a long time now.Many know this is the future.

Astro Sky

I expected this kind of project to attract interest. I had been talking about the possibilities for months. But I'm not part of the core team managing DroidDeck's sudden attention. From my side, knowing that some of my experiments benefited other people is something I'm proud of.

The412Banner

By being specific in writing. Our release notes say what was proven on a device and what wasn't. The README lists exactly which GPUs are supported, experimental, or unsupported, and its Limits section says plainly that hardware validation is limited. 0.2.0 was labelled beta on purpose. Preview and test builds are opt-in channels, so people who want the bleeding edge can have it without everyone else getting it. The app itself stays in beta until an official 1.0 is released, so everything is a work in progress, now and going forward.

Astro Sky

I can only speak for my own experience. Some people thought I was overenthusiastic about what Android could become, and those reactions contributed to me stepping away from my own version. Seeing the ideas developed further was encouraging. The team should speak for how it communicates experimental support to its users.

The412Banner

There have been so many that it's hard to pick. As a collective, it's deeply impressive to see so much contribution and interest in our project at the same time, and I remain deeply humbled by it all. Everything together is bringing a masterpiece together, like a puzzle being built.

A few examples from the release notes:

• @SG3xHERO: foldable resizing, the touch gamepad on unfolded screens, and Bluetooth Steam Controller (2025) support.
• @jmarti326 and @unbelievableflavour: per-game compatibility profiles and Adreno 6xx support, which brought in devices like the Retroid Pocket 5.
• @kmnkv1: fixed the Odin 3 rebooting when its Wi-Fi went into low-latency mode, a bug we couldn't have found without the device.
• ribbit384: mmap ring-buffer controller input, from WinNative #345.

Astro Sky

CoffinColors was an important influence on me learning to push boundaries in Winlator. More broadly, I admire the DroidDeck team for making complicated work approachable. I don't have a specific DroidDeck bug report or outside patch to single out.

The412Banner

It's hard, and we rely heavily on testers. The app has a Share logs button that packs the latest session, store and tool logs into one zip, with credentials scrubbed. Bug reports go to the Discord #bug-reports forum with that zip attached. Swapping the driver is the first test: if a different Turnip pair fixes it, it was the driver. My Mali/Xclipse work depends entirely on community testers, since I don't own those phones.

Max

We actually have a very well logging system that helps us identify what the user was doing and what exactly happened to cause the issue. This has been a tremendous help for most of the issues we've worked on.

Kimchi

Its not that difficult. Especially surrounding drivers. Qualcomm proprietary driver's are no longer as bad as they were 2 years ago. Compatibility layer emulators also don't necessarily require Turnip drivers for them to work. Proprietary drivers work fine.But everything else we do have to rely on users a lot.

Astro Sky

My experiments involved trying different pieces together until I found a working combination. Driver and environment problems could stop progress even when the idea made sense. I wasn't part of DroidDeck's wider device-testing process, so the team can explain how it handles reports.

The412Banner

Those projects have years of per-game tuning, and we're about a month old. What we offer is different: the real Steam client, with its library, cloud saves, achievements and Steam Input, rather than a container per game. Compatibility will keep closing the gap. The Steam experience is the part others don't have.

Max

It pushes us to find and fix any issues if there was an issue, we also are very excited to see these comparisons especially with all of the new optimizations and work that has gone into DroidDeck.

Kimchi

Because DroidDeck is built on components developed by reputable sources such as Valve, we expect it to keep improving. The main current limitation is proot, which may be adding some overhead. For that reason, we plan to focus on dedicated handhelds, such as those from AYANEO, AYN and Retroid, and to encourage users toward them, since getting the full performance out of DroidDeck requires a more open environment.

Astro Sky

What I appreciate about DroidDeck is the integrated experience. It's not just whether one game can launch. It's how much work has been done to make the whole thing approachable. I wouldn't use my own experiments as evidence that it beats every alternative in performance or compatibility.

The412Banner

Staying open source and completely transparent to our users is something we hold as a very high value in this project. It shares our work back to the community, so other contributors can continue or improve on it. It also gives users peace of mind: they know exactly what they're running, and we hide absolutely nothing. That goes hand in hand with knowing where their information goes and where it's stored. There's no telemetry, no ads and no hidden spyware.

Everything we build on is open: Mesa, FEX, Wine, Proton's open parts, gamescope, PRoot, Legendary, gogdl, and WinNative and Bannerlator themselves. Keeping DroidDeck GPL means whatever we add goes back to the same pool. In practice it shapes how we ship. Every DD-Turnip release carries its full source. Nothing is uploaded to a release by hand; CI builds and publishes it, so anyone can trace a binary back to a commit.

Max

We want everyone who wants to contribute to have the opportunity to contribute, we also want to ensure nothing is ever hidden and everything remains free.

xXJSONDeruloXx

One frustration I’ve had with PC gaming on Android is how much of the software stack can be closed source or only partially open source, with closed source binaries peppered throughout. That’s something we wanted DroidDeck to approach differently.

We have a pretty straightforward philosophy: 100% open source, no ads, no telemetry, and no proprietary components in the software we develop and distribute. Obviously Steam itself is proprietary, but that’s downloaded directly from Valve rather than bundled with DroidDeck.

I think that commitment is massively important for establishing trust, especially when users are signing into accounts containing their game libraries. But it also encourages community engagement and contributions. When no source is withheld, everything is on the table for us to solve and improve together as a community!

Astro Sky

The team chose DroidDeck's licence, so I can't speak for that decision. For me, enjoyment is still the reason I work on projects. But I value people being able to build on ideas instead of being locked into one platform. Knowing that my work helped someone else is something I'm proud of.

The412Banner

For me it's Claude Code, Anthropic's coding agent, which I run in a terminal on the device itself. It speeds up the mechanical work: reading large codebases, writing first drafts of code, CI workflows, digging through logs. It also keeps a detailed engineering log. Where it needs me: deciding what to build and what ships, knowing what a game or a device actually does, and testing on real hardware. AI will happily say something works when it doesn't. My rule is that nothing counts as done until it's proven on a device. Along with proving things on a device throughout the process, I go through the code to see what is being done. I push back on areas I think could be improved, and ask why connections were made in specific places or written in certain ways. I also use it to understand things I don't know yet, so I keep educating myself along the way.

Astro Sky

I've used tools including Codex and Claude in my projects, and I've built a harness around how I work. I've spent a significant amount of money on it because this is a hobby I love. I wouldn't call myself a vibe coder. I call myself a vibe engineer.

I use AI like a paid team. I bring the vision, the architecture and the domain knowledge I have, and I use the tools to do the repetitive work. I'm also learning as I go. We figure things out together. I love AI, honestly. I see a good future with it because I think it benefits people and lets them do more with their ideas.

The412Banner

The same way as any contribution, because the risk is the same: code that looks right and isn't. The pipeline:

• Work happens on a branch. Every PR gets an automatic CodeRabbit review and a signed test APK.
• CI has to pass, and we read the logs, not just the green tick.
• The change gets tested on real devices, and we check logcat for crashes, not just the result we hoped for.
• A maintainer merges. Only then does it reach the Preview channel, and later a stable release.

On top of that, when one of us opens a PR, another developer or maintainer looks it over before it's merged. Nothing goes into main, Preview or a stable release without a second human eye on it.

The repo also has a rule file for AI agents: comments must be rare and factual. Releases are signed, and the app checks every update against our release key.

Astro Sky

I check that what I'm getting actually works and hasn't broken things. I don't just put code in without checking it. Getting an interface or a proof of concept is one thing, but crashes, compatibility and performance still take debugging.

People worry about AI slop. To me, a big part of that is whether you care about the work or you're just trying to get any result. I care about whether it works. A proof of concept isn't the same as something that holds up when you use it. I'm describing my own process here, not DroidDeck's release or security review procedures.

The412Banner

They've changed it a lot: 58 people have contributed code, and many features in the release notes came from outside the core team. In 0.6.0 alone, 73% of the 153 pull requests came from the community. Contributors are always welcome. We want the community to be part of this project, not only by using it but in its creation too, with work and ideas that make sense and are logical.

Areas where help is especially welcome:

• Device testing: especially phones we don't own.
• Translations: the app ships in 31 languages as of 0.6.0, and more are welcome.
• Drivers: Mali, Xclipse and PowerVR.
• Game reports: good ones, with the Share logs zip attached.

Max

We encourage anyone who wants to contribute to DroidDeck to open Pull Request’s so we can review and test them as well as help and guide them.

Astro Sky

The core team should answer where they need contributions and how they integrate them. My connection has been much more informal: sharing experiments and talking about things I'm excited about.

The412Banner

With everything being open source, the general practice is to credit the work of others, and we do. The README credits section names the projects and people behind each piece. Release notes credit every change with the author's handle and PR number.

Bannerlator and WinNative belong to Max and me. They're successful projects, so it only makes sense to pull from them, without conflicting with other projects or developers.

It also goes the other way. We're not gatekeeping fixes or patches; they make it into the main work distributed by the original developers, for everyone to benefit from. Two Turnip driver fixes Max and I found and shipped first are now in Mesa itself. One stopped a zero-timeout wait from blocking, which held back D3D12 games: a D3D12 demo on an Adreno 750 went from 378 to 1,422 fps. The other fixed a crash that hit Cemu on its first frame. I shared the fix with Hugo on 2026-09-30, who took it upstream for us. The next day Turnip developer Danylo Piliaiev opened a set of KGSL fixes that includes both, in Mesa !44838, merged 2026-10-08, and we dropped our own patches. A bug found through DroidDeck has also been fixed in DXVK (#5967).

Astro Sky

It's built on the shoulders of giants. Valve, the Wine developers, the FEX team, Mesa contributors and the other projects deserve recognition for the work that makes this possible. I also want to keep my own role clear: I did independent experiments, and the DroidDeck team did its own research and development. I don't want to take credit for their implementation.

The412Banner

A star on GitHub isn't a support contract. Most of us do this in our spare time, and the most helpful thing a user can do is send a good bug report with logs.

Kimchi

Users often assume high download numbers, a polished website, or a large number of GitHub stars implies a dedicated support team, a QA department, and round-the-clock incident response. In reality, a massively popular library or tool is frequently maintained by a single developer or a tiny group of volunteers working in their spare time.

Astro Sky

I can only explain my own motivation. This is a hobby for me, not a career plan or a paid support job. I do it because it's fun. Other people have different priorities, but if I'm no longer enjoying a project, I may move on. Knowing people benefit from the work matters to me, but that doesn't change why I started.

The412Banner

We take security very seriously to protect our users' information. Steam credentials are handled entirely by the original, official Steam client. You sign in inside Valve's own client, which your device downloads straight from Valve's update servers, checking every file against Valve's checksums. DroidDeck doesn't build its own Steam login screen or ship a modified client, so Steam's login stays Steam's.

Logs go through thorough scrubbing that we put in place, because logs tend to get shared publicly and loosely. That way users' tokens and credentials don't end up in them. Saved session logs are scrubbed when a session ends. They stay in the app's private storage (the last three sessions) and only leave the device when you press Share logs, which scrubs every file again as it builds the zip.

The same goes for the other stores in the app. Their credentials and other sensitive information are encrypted with a key locked in Android Keystore, the phone's hardware-backed key store, using its StrongBox security chip where the phone has one.

Max

We’ve ensured that no account information is ever logged or stored on the device that way there is no risk of it ever being leaked. This is critical to keep users safe and secure.

xXJSONDeruloXx

The biggest distinction is that you're signing into Valve's actual Steam client, not a login system we've recreated. Steam itself is downloaded directly from Valve's servers, and we verify the downloaded components against the hashes in Valve's manifests. We're not asking users to hand their Steam credentials over to some separate service we operate.

We've also put a lot of effort into making sure diagnostic logs don't inadvertently expose sensitive information. We scrub authentication tokens, Steam IDs, account names, Steam Guard codes, and other identifying data, including when users export logs for troubleshooting. We also leverage Android Keystore encryption for the other stores to ensure things are as secure as possible.

I think this is another area where being truly and fully open source is especially important. Users shouldn't have to take our word for how their accounts are handled. They should be able to inspect exactly what the application is doing.

Astro Sky

I'm not responsible for DroidDeck's credential handling or security implementation. The core developers need to explain that directly; I wouldn't want to give assurances on their behalf.

The412Banner

As more people used it, it moved up the list.

Max

Safety and Security of our users are the #1 priority when it comes to keeping their accounts safe, we want to ensure that everything the user is using is absolutely 100% open source and that we take every step into keep our users safe.

Astro Sky

I wasn't involved in those protections or their review. This is best answered by the team implementing them.

The412Banner

No. droiddeck.app isn't ours, and neither is any other DroidDeck website; as the README warns, DroidDeck has no standalone website. Genuine releases come from three places: the GitHub releases page at github.com/Droid-Deck/DroidDeck, the in-app Updates page, and our Discord. If a site offers a DroidDeck download, don't use it.

Max

We do not have any official websites beyond GitHub, we do not work with anyone else and we do not host any files beyond the official GitHub organization. It is very important to use only the official GitHub to download and install DroidDeck.

Astro Sky

I can't confirm website affiliations on the team's behalf. The core team should identify its official distribution channels and clarify which sites are associated with it.

The412Banner

We haven't had any contact with Valve. What I can say on the record: we don't redistribute the Steam client; it downloads itself from Valve's servers. To speed up the first start, the app places a copy of Valve's ARM64 Proton Experimental, which Steam then takes over and keeps updated itself. We're not affiliated with Valve. Yes, a change to how Steam is distributed for ARM could affect us. But we use the client exactly as Valve ships it, which is the most robust position we could be in.

Astro Sky

I can’t speak for any contact between the DroidDeck team and Valve, or give assurances about future changes to Steam. The core team should answer that directly.

The412Banner

Working offline doesn't mean working online, and we say so. For Easy Anti-Cheat games that support offline play, there's an option, on by default, that starts the game without its anti-cheat for offline modes. Turn it off and the game launches through Easy Anti-Cheat as usual. Kernel-level anti-cheat and online modes that require it won't work, and we don't try to bypass them. Whether a publisher allows a game to run in this environment is the publisher's call.

For some online multiplayer games, we've also made an optional x86-64 Steam client available (since 0.5.0): Valve's own Linux client, running under FEX beside the default ARM64 one. It lets people play Steam VAC-secured games online.

Max

If the game is compatible with “Valve’s Steam Arm Linux Client” then it’s compatible with DroidDeck for the most part minus a few games we stumble into and have to fix, for the most part Valve is doing the heavy lifting for us when it comes to Online gaming, DRM and we hope Valve will get Anti-Cheat systems working with Arm soon as it will benefit them greatly as well.

Kimchi

DroidDeck exists as an open-source execution layer (utilizing FEX, Proton, and custom graphics translation) to make x86/Linux game binaries run on ARM64 Android hardware. We distinguish heavily between single-player rendering capability and online service authorization. DroidDeck does not patch, disable, or tamper with anti-cheat drivers. If a game’s anti-cheat flags the environment as untrusted, the game will not connect to live servers. We do not attempt to bypass detection, as doing so would compromise user account safety and violate developer Terms of Service. Client-side DRM (such as Denuvo or Steam DRM) verifies platform signatures, hardware IDs, and online tokens.

Astro Sky

I can’t offer an assessment of those systems or publisher permissions. My experiments getting a game to run shouldn't be treated as a guarantee about online support or account safety. The relevant developers and publishers need to address those questions.

The412Banner

I come from that world. Bannerlator continues Winlator Star Bionic, and I've made the BannerHub mods for GameHub, so I have a lot of respect for those apps. They run Windows games in a Wine container you set up per game. DroidDeck runs Valve's actual Steam client in a real Linux system, with Valve's own Proton and the full Deck experience around it, inside an Android app, without replacing the OS.

Max

After working on WinNative and now working on DroidDeck, it’s truly put WinNative in a position that is almost pointless to continue beyond the fact there are some devices that are not compatible with DroidDeck yet which we are working on still. DroidDeck has basically laid the foundation to an endless imagination to develop and work on.

Kimchi

At the top lol.The other projects have very capable developers, and their focus on performance shows. Our focus is different: an interface that anyone can pick up and use is the first half of the battle.From the users I have met, I've found that most would compromise a little of performance as long as it means to have a feature complete and easy to use application.

I'm on that same boat.Besides, we also offer builds that run the device at maximum performance, with results comparable to other projects. However, we don’t consider the trade-off worthwhile, as it comes at the cost of battery life and higher device temperatures.

Astro Sky

For me, what stands out is how the team brings the pieces together. My early experiences with PC games on Android involved a lot of manual experimentation. DroidDeck puts effort into making that experience approachable and giving people something they actually want to install and use.

The412Banner

It's the identity, yes. Library management, cloud saves, achievements, Steam Input, Proton updates from Valve, and other stores launched through Steam are what make it DroidDeck. Performance matters a great deal too, which is why so much work has gone into PRoot, drivers and DroidDeck-Proton. But if I had to choose, I'd rather people get the whole Steam experience at good performance than one game at a few more frames.

Kimchi

I'm not sure if the others in the team think this way.Personally, I think so yes.

Astro Sky

Compatibility and the complete experience were central to what interested me. My Garry's Mod experiment was exciting because I got things working, not because it was the most demanding game. Having the real Steam experience matters to me, rather than only a launcher that resembles it. I can't set the team's priorities for them.

The412Banner

Different approaches, and the code moves between them. DroidDeck itself is built from Bannerlator and WinNative. Our input ring buffer came from a WinNative PR, and the same Turnip and Proton work feeds several apps.

As far as I know, nobody on our side is in contact with GameHub. I believe some of our team members still talk with developers of other projects, mostly indirectly. I also think our work is inspiring those projects to build their own versions of what we've done. They mostly run on Android's own Bionic libraries, while DroidDeck needs a real Linux system and its components, so they can't take our approach as is. For example, I think my Wayland work and Max's gamescope have driven another project to build its own version of gamescope. Very well done! The difference is that our work remains completely open source and available to everyone, while some others' doesn't.

Kimchi

I'm not sure about the others, but I regard them as competition.We do not collaborate after all. At least haven't yet.

Astro Sky

A lot of us cross paths in the same communities. I think of it like spider webs crossing: people working on different things and sharing discoveries. That's how my work connected with theirs. I wouldn't claim to know every collaboration happening between projects.

The412Banner

From the player's side, it's getting thin: the same Steam library, Big Picture and controller layouts on either. Underneath they're still different, with x86 vs ARM, open drivers vs vendor drivers, and a desktop OS vs Android. That's the gap projects like this are trying to bridge.

Now that Valve is officially shipping hardware with an ARM chip, I believe they're recognizing not only the capability but also the value in this community.

Kimchi

The user experience is converging, but the underlying architectural and philosophical divide remains distinct.

While the gap in what games you can play is narrowing thanks to modern translation layers and high-end ARM silicon, the two categories are defined by fundamental technical trade-offs that keep them separate.

Astro Sky

The vision that excited me was taking a phone you already own, attaching a gamepad and getting that handheld PC gaming experience. That possibility is what made me want to experiment. I wouldn't claim the hardware and software limitations have all disappeared.

The412Banner

My honest view today: it's still for people who enjoy tinkering, and it's still a 0.x release. The aim is install, press Play, sign in, play, and for many games on supported devices that already works.

Max

Yes, I feel like if a user has a powerful android handheld and they have a friend or family member who plays online games with in game voice chat, they can load up a game and talk with them while they play without any hassle, this is a huge step forward in Mobile Gaming on the go.

Kimchi

We’re open to partnering with any handheld manufacturer that’s interested. Partner devices would receive full, official support, and shipping DroidDeck preinstalled could make an attractive arrangement. I’ve already had initial conversations with AYANEO about this, and we’ll see how things develop.

Astro Sky

What makes DroidDeck interesting to me is that it makes the work more approachable. Not everyone wants to root a device or assemble a Linux setup. Making it something people can install while keeping their normal Android experience is a big part of its appeal. How broadly it gets adopted is something we'll see.

The412Banner

My list from the open work:

• SD-card install and load speed: it matters most on handhelds with small internal storage.
• GPU support beyond Adreno: getting Mali, Xclipse and PowerVR to a supported state.
• First-run setup: for example, the Android 14+ developer-option step before Steam can launch.
• Separating app, driver and firmware problems: making it easier to tell which one a bug is, so fewer reports need back-and-forth.
• Steady compatibility gains: in DroidDeck-Proton and the Windows-component coverage.

Max

We would really like to expand the amount of devices that are compatible and not limit to strictly “Adreno” this is a large hurdle that is being tackled but the community daily.

Astro Sky

From my perspective, compatibility and accessibility are the priorities. People want games to work without having to fiddle with everything, while enthusiasts still want control. The team should set the actual technical milestones for calling its project mature.

The412Banner

Three of the four pull requests that were still open on 2026-10-21 shipped in 0.6.0 (2026-10-22): the Steam Remote Play host with hardware encoding (Kurt, #1139), Adreno 850 recognized as experimental (#1249), and the frame-time graph and battery temperature in the overlay (#1256). Still open:

• Native DualSense and DualSense Edge support (ovurrsl, #1150).

On my side: DroidDeck-Proton 11-10.1 and 11-11.1 are both released, and 11-11.1 has been the org's Latest since 2026-10-23. The non-Snapdragon test build keeps improving with tester feedback.

Max

Very excited for the ( VR and Epic Games Launcher ) experience that we’re pushing in 0.5.0, likely this article will be out after 0.5.0 lands but the VR experience is huge, you can use “Google Cardboard, VR Glasses like Viture or other brand or even Quest 2 or 3” and launch SteamVR and get into VR games without needing to have a desktop or a dedicated VR machine if you don’t own one or can’t afford one. These options being added basically allows a lot more users to play games they couldn’t have ever played before. Epic Games Launcher being integrated also enables future updates from Epic to instantly add features into DroidDeck such as “EAC” when they port that and enable it to run Fortnite you’ll also get that capability on DroidDeck!

xXJSONDeruloXx

Everything we build is publicly available around the same time we ourselves test it, but we have a few things in PRs and on main that have not made it to release at time of writing. One I am very excited to see get into more hands is Xbox/GamePass integration and itch.io integration to our extended stores! Itch was a contribution from the community that I cleaned up a bit then merged, and Xbox is leveraging the Xodus project to let users download and locally run GDK based games from the Xbox app. Initial tests have had a lot of success, and it feels like we are collecting all the game library infinity stones!

Something I have not developed yet but am excited to bring to the project is LAN over wireless and wired connections, so two devices connected with a usb C to C cable can game together!

Kimchi

Our release cycle moves quickly, so there’s nothing I can single out right now. Next up is the new Epic Games launcher integration, though it will likely be out by the time this article is published lol.

Astro Sky

I can't announce features on the team's behalf. My own current focus is the phone-powered PSVR2 work, which is separate from DroidDeck.

The412Banner

My guess is that more hardware brings in the most new users, while performance is what keeps the ones we have. Both depend on open drivers, which is why DD-Turnip and the non-Adreno work matter.

Max

Considering that we basically are using “Valve’s FEX & Proton” as well as “Mesa Drivers” as they fix issues and add compatibility or performance we directly benefit as well not to mention the additional fixes/patches were are discovering and pushing upstream while our users get to benefit from these fixes as soon as we find them.

Astro Sky

I'm excited by the direction and the opportunities that upstream compatibility work can create for Android. I don't have a measured one-year forecast or a DroidDeck roadmap to share.

The412Banner

We're already in talks with Retroid to help develop on their hardware with developer units. Thank you, Retroid! We would absolutely love to do the same with AYANEO, AYN, and any of the other manufacturers in the community, known and unknown.

That could mean device profiles, controller integrations, and access to test hardware. Community fixes like the Odin 3 Wi-Fi reboot show how much device-specific work there is. Shipping it by default would be up to the manufacturer and Valve's terms.

Max

Yes, we actually have discussed this together and tossed around amazing plans for device manufacturers that would allow performance benefits for partnerships that install “DroidDeck” as a system app, basically there is things we can do as a system app to enhance performance that you can’t do as a normal app. We want to bring the best experience to all users and working with manufacturers is the best way of doing that.

Astro Sky

The core team should speak for any manufacturer plans or partnerships. I’m not involved in those discussions.

The412Banner

Definitely getting rootless Wayland working: Wayland running on Android without root, first in Bannerlator, and it's the piece DroidDeck stands on. Beyond that, I'm proud of all the creative solutions we've come up with to make a working system as easy as possible to use, whether you're new or advanced.

Max

The fact that a user can open an app on their phone and instantly launch into Steam or a Linux Desktop experience, these are features we’ve all dreamed of and even “DeX” falls short so we are very proud of DroidDeck as a whole user experience.

xXJSONDeruloXx

Getting the Quest 3 to run arm SteamVR locally was quite the challenge, but I am pretty happy with how everything turned out. It still has lots of rough edges but I love the idea that the headset I got off FB Marketplace for $250 is managing to run the same software a $1000+ Steam Frame does.

Kimchi

Slightly unrelated to the project, I'm happy of the bridges I have built with EMUCORE (my discord server)I managed to bring big players from all sorts of projects, Mesa, FEX into one place for them to work together. It is one place where developers consistently help and share information, which DroidDeck benefited from.

Astro Sky

Knowing that some of my work benefited other people. My own experiments weren't always something an ordinary user could pick up and use. Seeing ideas cross over into work that other people develop further means a lot to me. I'm also proud of the persistence it took to get things working that weren't designed for this setup in the first place.

The412Banner

It has taught me a lot of Linux, which I never got the chance to tinker with in the past. It also taught me that teamwork really can be successful and productive, with the right team and the right mindset, everyone working together smoothly. And I've learned that I don't have to do everything on my own anymore. I can trust others to do things right.

One thing the record shows: we ended up writing down every rule we learned the hard way, in a "Lessons learned" list in the progress log. Working in a team of three maintainers and dozens of contributors makes you write things down and test on real devices before you claim anything.

Max

I’ve learned a lot especially working with other developers and ensuring that we have a close group of like minded people who want to see the community grow with positivity and helping others as it has helped us all develop very important fixes.

Kimchi

Not yet.

Astro Sky

My experience has been about experimenting and learning as I go. I’m not claiming to know every part of the stack in depth. I work on what interests me, figure things out, and share what I find. Seeing other people take ideas further is something I’m proud of.

The412Banner

The kid swapping 5¼-inch floppies to play Oregon Trail and Gorillas would think it's magic that the same kind of fiddling now puts a whole Steam library on a handheld that fits in a pocket. That kid also wouldn't be surprised that I'm still the one figuring out why a game won't start.

Kimchi

I honestly try to not dwell in the past. But I think they would be impressed. I hope.

Astro Sky

I can’t really say what my younger self would think. But there’s a connection between being that kid experimenting with a PSP and what I enjoy now: finding out how far the hardware can go.

The412Banner

Success would be seeing our app on the Play Store, and also shipped by most of the main Android gaming handheld manufacturers in the community. Beyond that, it would mean we keep making people's gaming better and their favourite games and libraries easier to reach. And it would mean the active, ongoing development that makes all of this possible keeps going.

Max

I want DroidDeck to mean the difference between not being able to game based on work, affordability or on the go to allowing those users who can’t game to have the opportunity to game, we’re basically seeing our childhood dreams come true.

xXJSONDeruloXx

I just want people to have fun with the devices they already have, and not have to get a PhD in tinkering to get there.

Kimchi

Ultimately, DroidDeck shouldn't be thought of as just an emulation tool or a technical trick, it should represent frictionless accessibility and device freedom.

When someone picks up an Android handheld, DroidDeck should mean that their hardware isn't constrained by its operating system or processor architecture. It should mean that high-end, efficient ARM hardware can seamlessly access their existing PC game libraries without needing to re-purchase games, rely on unstable cloud streaming, or manage overly complex, fragmented translation setups manually.

For me its 3 steps:The highest praise for a translation tool is that users stop thinking about how it works. Success means extending the useful lifespan of Android handhelds. Success means the project has built a resilient open-source foundation that doesn't depend on any single person.

I rest my case :)Thank you for your interest!Yours,KIMCHI

Astro Sky

To me, it’s already succeeding. Everyone’s eating, everyone’s benefiting. I can already see these ideas influencing the industry, and knowing that some of my work helped people is something I’m proud of. I don’t feel like I need to wait a few years to call that a success. The future is now.

Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.

In August 2025, the Trump administration raised eyebrows by making a $8.9 billion investment in US chipmaker Intel, as part of a massive $100 billion drive to boost semiconductor supplies.

At first, it looked like an excellent investment as the AI race heated up as Intel saw shares shoot up, reaching just over $92 a share by Thursday of last week, more than quadrupling the government’s initial investment, as Yahoo Finance reports.

But by Friday, the situation looked dramatically different. Intel experienced its worst one-day stock performance since 1974, with shares cratering almost 30 percent on Friday alone. According to Yahoo, that means the value of the government’s 9.9 percent equity stake crashed from almost $40 billion to well under $30 billion, slicing over $11 billion in taxpayer-funded investment off its stake.

Intel’s shares are currently hovering at just over $60, well short of the “NOW $95” displayed in an AI slop image president Donald Trump shared of himself as a day trader in September.

The dramatic swing perfectly encapsulated why the government taking a major stake in a publicly traded company could result in investors being taken on a rollercoaster ride as the value of the Trump administration’s portfolio swings wildly.

Intel’s bruising Friday came after its shares had risen some 150 percent since the beginning of the year, cashing in on the seemingly limitless appetite for AI investments. But the company’s reported Q4 revenue outlook fell short of Wall Street expectations, triggering the major $150 billion market value wipeout.

Nonetheless, the chipmaker still managed to beat expectations in its third-quarter earnings report. The big elephant in the room was the personal computing industry, which has largely collapsed thanks to AI causing prices to skyrocket, suppressing consumer demand. Compounding its PC market woes are supply side production problems, as CNBC points out.

Investors are now divided on whether it’s time to buy the dip or wait it out as the stock swings drag on. Intel isn’t alone in feeling the hurt, with Google parent company Alphabet incurring massive losses and wiping out over half a trillion dollars in market value last week.

Zooming out, Big Tech is navigating a major point of reckoning as investors continue to ask hard questions about its ability to keep the party going and sustain its massive data center investments.

With existing supply woes, Intel is trapped between a rock and a hard place: either pursue a declining PC sector or make a major pivot to data center-friendly server processors, neither of which are a guarantee of future success.

Meanwhile, US taxpayers are along for the ride as the value of the Trump administration’s major investments in Intel continue to fluctuate wildly.

More on the AI industry: Investors Are Getting Palpably Nervous About the AI Industry’s Financial Situation

Michigan is set to deploy a major new AI system to prisons across the state, meant to classify incarcerated people based on “how dangerous they are.”

That’s according to Detroit channel Fox2, which reports that the Michigan Department of Corrections is plowing ahead with an inmate categorization algorithm that will sort people into various housing levels.

In Michigan, incarcerated people are separated into five housing levels according to their security classification. In the past, screenings were performed by a committee of staff appointed by the Warden at each facility. Now, it seems the state wants to outsource that decision — or at least have it be heavily informed by — a non-profit tech company called Recidiviz.

Recidiviz began as a data organization project at Google, meant to “uncover how technology could standardize criminal justice data and improve the system nationwide.” Its AI-integrated software platform is said to perform features like identifying individuals eligible for state-offered programs, reclassification, or release, and coordinate access to resources like transitional housing and employment.

In a press release, MDOC said the Recidiviz software will be used to “optimize placement of incarcerated individuals” starting with a pilot program in a number of men’s facilities beginning in December. The state agency notes that the AI tool is expected to “improve MDOC’s ability to more accurately predict incarcerated individuals’ risk of future violence by approximately 30 percent,” though how the state arrived at that vague figure is unclear.

For incarcerated people, housing designations are extremely consequential, determining which programming and resources they’ll be eligible for, and what kind of population they’ll be housed with for the duration of their sentence.

Setting the state’s rationale aside, the MDOC-Recividiz partnership leaves some major questions unanswered.

What kind of data will be collected, for example, will matter a great deal with regard to the AI system’s accuracy. As a ProPublica investigation into a similar risk-analysis program in Louisiana found, the kind of data being used to classify incarcerated people contained inherent racial and socioeconomic bias.

As a result, Louisiana’s carceral system has become even more cruel and harmful to those earnestly working toward rehabilitation. In one case reported by ProPublica, a blind and wheelchair bound 70-year-old was determined to be a “moderate risk” of reoffending despite having a clean disciplinary record — a classification which results in an automatic loss of eligibility for parole.

While Michigan’s system is geared toward housing assignments rather than parole decisions, it seems highly unlikely that software alone will solve the state’s ongoing corrections crisis — and if Louisiana’s embrace of AI is any example, it could very well make matters far, far worse.

Michigan Department of Corrections was contacted for comment.

More on incarceration: What Are the Ethics of Strapping VR Headsets on Inmates in Solitary Confinement?

💡 TL;DR

• US senators warned Meta that its smart glasses may capture and use intimate bystander images for AI training without consent.
• The concern centers on passive data collection from people who did not agree to be recorded or included in datasets.
• Lawmakers are calling for stronger safeguards to prevent surveillance abuse and protect bystander privacy rights in public spaces.