This should sidestep that and timeout pretty quickly: https://jshtab.github.io/guide/gvfs-autmount/

Not sure you’re getting it…

SteamOS runs KDE desktop. Frame will also have KDE Desktop, be use it’s just running the ARM build of the same SteamOS that will be on all of these devices.

Making a VR-reaey compositor display for this is fairly simple after this point, you just need to hook all the sensors into camera movement for the screen, and that screen can show many composite views…like the desktop, or a media screen, or the Steam Library.

It’s a basic function of VDD. It will definitely be in there.

Try going into your BIOS settings and disabling IOMMU for the USB and Chipset settings. Boot and see if it works then.

Your North and South (if you have one )bridge chip?

Open your machine and look at these ports.

Are they directly connected to the motherboard, or on the front of a case extended by a cable?

It’s not “trouble” if you’re already familiar with Linux. It’s not the way I would go as a user of 20+ years, but it’s not just for desktop use.

If you’re looking to build a platform for something, it’s perfect. Look at why Valve switched to use to for SteamOS. You have an underlying framework of a stable system, and you just create automation to slap it all together into the base layer of all the things you want without having to worry about specific things breaking the stack you’re building on top of it.

It’s like a blank page instead of a notebook with line guides.

It helps make more sense if you think of everything you’ve got to build on it already existing in a git repo. Merge > Build > Release. Makes perfect sense, and you save yourself creating an entire distro to maintain from scratch.

99% of all Windows games running Proton, and most perform better than on Windows, depending othe game.

For the specific games you mentioned, they all have Platinum rating in Proton, meaning flawless. You can see here in ProtonDB.

I’m not sure what your experience was in the past, but I write tons of Proton patches for games, and the only ones I’ve seen that don’t play well are the pre-DirectX9 games, which can’t plan on Windows XP or later anyway. Proton will soon be able to play these games without issue thanks to some Vulkan patches coming up.

That’s slightly different. That is mapping controllers to already existing inputs for a game, which steam-input already does.

Mapping all the sensors of a VR headset for motion and tracking is an entirely different thing, though kinda similar in some sense.

They’ve already said they’ll be using FEX: https://www.pcgamer.com/hardware/vr-hardware/steamos-launching-for-arm-fex-translation-layer/

Well it’s not going to suddenly be all VR’d up or anything 🤣

Part of the reason I would imaging they implementing a new kind of steam-input layer for VR is for things like a theater mode and desktop. I could see them making some sort of a simple hook for view controls in games for your exact scenario, but that would be heavily dependent on the game having something like free look already be possible, and then the developers just write a quick patch of a couple lines to hook the steam-vr-input hook into their code, and BAM.

It wouldn’t need to. They would just need to include a virtual desktop manager or interface to render the usual compositor in a VR sort of way. That’s why I put it in the list. Same thing that would make a theater mode would also allow a desktop to render in a space on a VR compositor.

Desktop is a built-in feature of SteamOS. They’d have to actually work to remove that by default. No reason for it not to be there.

You don’t read much, eh? Valve has confirmed it, people have seen it, and multiple artists and devs have confirmed working on the finishing touches in the past year.

They released Alyx with the Valve Index, which also confirmed to be a drop-in VR engine for the Half-Life games. Valve likes releasing their IP games as surprises, and no better way to sell out millions of units than releasing HL3 along with this new hardware.

Seems like a pretty safe bet.

I’ll drop what I said about this in another thread:

I think you probably need to understand the underpinnings of what Valve accomplished over the past few years to understand why the Frame is useful.

Essentially, it’s a Deck strapped to your face. Same OS, same everything, just different hardware platform.

Valve spent the time to revamp SteamOS in order to make it more portable to various devices, which are now launching. Couple that with their efforts on Proton, and you have an entire ecosystem with very little in the way of preventing people from adopting these devices with their ease of use.

Steam Deck was just sort of the appetizer and test launch to gauge interest and build a fully functional hardware development and support vertical in the company, and it was wildly successful. I guarantee (if they can get the price right) that the Frame will sell WAY more units than the awful Vision Pro. I honestly think people might adopt this over buying another version of the Deck if it’s comfortable.

Some things I expect to happen with the Frame launch:

• A more expanded integration of Desktop features. If Valve doesn’t do it, the community will.
• Virtual screen management
• Theater mode for viewing media
• Virtualized VR input (like steam-input but VR)
• Pairing capabilities for multiplayer
• Half-Life 3 release (not joking)

Depending on how this all was built and configured while Tailscale was running, you may need to take some steps to “undo” some things, like re-mounting your network mounts with the proper IPs (auto discovery may have messed things up).

What are the errors you’re getting?

Now it looks correct. If you have a Gigabit capable switch/router, and 100Mbps seems wrong, you should check your negotiated link speed on your Ethernet interface with something like ethtool [your_interface] | grep Speed

100Mbps is obviously low if you have a Gigabit router. Either way, you should have your jellyfin setup working without issue now.

Tailscale is for point-to-ooint connections between locations, so yes a VPN. That doesn’t mean two machines on a local network should be using it to talk to each other. Let me explain a bit:

Say you have two machines on two different networks 100 miles apart. You put those two on Tailscale, that virtual interface sends traffic through their servers and figures out the routing, and then they can talk to each other…cool.

Now move those two machines to the same network and what happens? Tailscale sends their traffic out of that same virtual interface and THEN brings it back into the network. Sure they can still talk to each other sort of, but you’re just skipping using your local network. Doesn’t make any sense.

This is because of “default routes”. Whenever you plug a machine into network with a router, that router sends along information on where this machine needs to send it’s traffic to get routed properly. Usually whatever your home router is. This is the default route.

Once you bring up the Tailscale interface without proper routing for your local networks taken into account, it sets your default route for Tailscale endpoints, meaning all of your traffic first goes out through Tailscale, and you get what you’re seeing here.

Regardless of what you read around and on Reddit, Tailscale is not as simple as it seems, especially if you don’t know networking basics. It’s meant to be used with exit node endpoints that route to a larger number of machines to prevent issues like this, NOT as a client in every single machine you want to talk to each other. I see A LOT of foolish comments around here where people say they install it on all of their local machines, and they don’t know what they are doing.

To my point: read this issue to see someone with similar problems, but make sure to read through the dupe issue linked for a longer discussion over the past number of years.

Extra thread here explaining some things.

This blog goes deeper into a possible solution for your setup.

The simplest solution for Linux is usually just making sure to NOT run Tailscaled as root, just as your local user. This should prevent the global override of your machines default routes in most cases, but not all.

The proper and more permanent solution is running Tailscale on your router and letting that single device act as an exit node and handle advertising the proper routes to clients through the DERP server translation.

Also, see the netcheck docs as it can help quickly debug if things are working properly or not.

Well a 6-7X improvement is something, but you still see the Tailnet running there.

Honestly, if you don’t know networking and routing, don’t mess with Tailscale. It breaks shit like this for all these people who don’t know what they’re doing who are doing things like installing it on all their local machines because they have no idea how it’s used or it’s purpose, and it’s clearly your problem right here because both you, and your tailnet are confused.

I know for a fact your containers are ALSO running Tailscale or something equally not good, because you’ve definitely got a polluted routing table from local route loops, and you’re confused as to what that is, how to prevent it, and why it’s broken.

1. Shut it down EVERYWHERE ON YOUR LOCAL NETWORK.
2. Make sure your default routes only point to LOCAL ADDRESSES
3. Recheck your transfer speeds which should be 100MBytes/s+

Why is your iperf run referencing a local 100.X address then?

That doesn’t look right. What are the two IP’s of the machines on your network?

Edit: you must be using containers or something. Don’t use bridge networking if you’re unsure of the performance issues there.