Tech Over Tea - The State Virtual Reality On Linux | Vixea

Episode Date: July 19, 2024

Most of you are probably aware of VR and maybe you've even used it but are you aware of the current support for the tech under Linux as it currently stands and what pieces are in place to make it work. ==========Support The Channel========== ► Patreon: https://www.patreon.com/brodierobertson ► Paypal: https://www.paypal.me/BrodieRobertsonVideo ► Amazon USA: https://amzn.to/3d5gykF ► Other Methods: https://cointr.ee/brodierobertson ==========Guest Links========== Github: https://github.com/Vixea Monado Website: https://monado.dev/ ALVR Github: https://github.com/alvr-org/ALVR ==========Support The Show========== ► Patreon: https://www.patreon.com/brodierobertson ► Paypal: https://www.paypal.me/BrodieRobertsonVideo ► Amazon USA: https://amzn.to/3d5gykF ► Other Methods: https://cointr.ee/brodierobertson =========Video Platforms========== 🎥 YouTube: https://www.youtube.com/channel/UCBq5p-xOla8xhnrbhu8AIAg =========Audio Release========= 🎵 RSS: https://anchor.fm/s/149fd51c/podcast/rss 🎵 Apple Podcast:https://podcasts.apple.com/us/podcast/tech-over-tea/id1501727953 🎵 Spotify: https://open.spotify.com/show/3IfFpfzlLo7OPsEnl4gbdM 🎵 Google Podcast: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xNDlmZDUxYy9wb2RjYXN0L3Jzcw== 🎵 Anchor: https://anchor.fm/tech-over-tea ==========Social Media========== 🎤 Discord:https://discord.gg/PkMRVn9 🐦 Twitter: https://twitter.com/TechOverTeaShow 📷 Instagram: https://www.instagram.com/techovertea/ 🌐 Mastodon:https://mastodon.social/web/accounts/1093345 ==========Credits========== 🎨 Channel Art: All my art has was created by Supercozman https://twitter.com/Supercozman https://www.instagram.com/supercozman_draws/ DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase we may receive a small commission or other compensation.

Good morning, good day, and good evening. I'm, as always, your host, Brodie Robertson. And today, we have a generic GitHub profile picture. But they have something important to say that is more important than the profile picture. Welcome to the show, Vixia, who actually sent me an email saying they want to do the show. And, as you can probably tell from the title it's going to be about vr on linux and just the sort of state of things how all this works and just yeah give you an idea about what's actually going on so welcome to the show welcome i'm glad to be talking to you uh

oh you're gonna say something it's gonna be one of these episodes where we're not sure when the other person's gonna stop speaking yeah it's gonna be one of those okay so um before that happens again how about you just give a brief introduction of who you are what you've been involved with and yeah just give an idea of what you're doing. Yeah, so I've worked on LVR for, I think it's been about three or two years now. I originally came to the project by me owning a Quest 2 coming from Windows. I did try Linux previously, but I did the, I chose badly for my distro choice.

I chose an infamous distro called Manjaro. As you can imagine, I ran into some issues and I went back to Windows. some issues and I went back to Windows. I did want to try Linux Scan after I think, finding your channel and just getting really into it. I watched a little bit of your your links from scratch as you as you did a recent podcast on that. Yeah, that was certainly interesting. I don't think I'm at that. Yeah. That was certainly interesting. I don't think I'm at that level yet. Look, it's not a good use of your time.

You don't need to be at that level. That's simply true. So I decided to settle on Arch, Arch by the way, specifically in Endeavor OS just because it's easier to install. You don't have to get your columnarized installer, nice UI. I did do a little bit of vanilla Arch, but I just ran into some issues with Arch install. And so I chose Endeavor OS and of course found LVR. I was currently on NVIDIA at the time. There was some definite issues. For example, during that time,

the common parameter for mode setting wasn't very, you know, not many distros defaulted when you had a NVIDIA card, so you would have to add it yourself at that time. So I was trying Raylan because I was like, oh, yeah, that's cool. And I ran into some issues with that. I eventually figured that out and got Rayland working. And yeah, that was that. I realized I went on a rabbit hole. I skipped past the part of LVR. So basically at the time LVR had no NVIDIA support. We did have a fallback software renderer using FFmpeg. FFmpeg is both amazing and a little bit of pain

when you're dealing with a project like LVR. So this dude that came in, I wish I remember his name. I know it starts with a T. I'm sorry, dude, if you're listening to this. He added Linux support for the encoder. And man, for VR, standalone VR, you need a hardware encoder. It just makes a world of a difference. Software encoding is just too heavy. And especially when you're doing stuff

with VR applications, which tend to be CPU heavy, especially VRChat, which I'll get into later, you can run into some issues with software encoding. No, no, no. I've been rambling on. I was like, huge. Okay, I was just going to ask you, for anyone unaware, to clarify what ALVR is and what the goal of the project is because I'm sure there's going to be a lot of people who have just never heard of it. Yes, people haven't heard of ALVR.

Yes, so ALVR is a standalone headset PC to standalone headset streamer application. So basically we use OpenVR currently to the OpenVR API to capture images and post from the SteamVR runtime and send that over to the standalone headset so you can view on the standalone headset. There's some issues with that. I'll get into that a little later, but that's the basic idea of the application of AOVR.

The most obvious question with doing that is wouldn't latency be an issue? Latency can be an issue. It depends on how bad of a setup you have in terms of Wi-Fi and your PC hardware. For example, currently because of the way we have to interface with SteamVR. If you exceed a certain, if your frame time exceeds more than half of your, the limit to reach half of the FPS of the streaming application or headsets to frustrate, SteamVR starts missing frames. Yeah, that doesn't sound good. Because of a missing feature that

was originally getting discussed in, I think it was 2016 or 15 and just died. The discussion died. And that discussion was on how to give the compositor preference over the application, which can also

be helpful for your desktop compositor. Like if your application is, your regular desktop application is like really heavy and like it's- Right, I would imagine that would make a lot of sense for just a regular video game. Mm-hmm. And that missing piece is called Compute Tone,

at least on AMD. I'm not sure what the NVIDIA term is. Do you say compute tone? Compute tunneling. Tunneling, tunneling, okay. Yeah, tunneling. So, basically, you have to be running a compute queue. So, you can't be running a graphics queue for this. And you have to have proper a high privileged queue, too. There's Vulkan documentation you can find on the specifics of that. And if you don't have it, well, let's just say your compositor isn't going to be – doesn't have preference over the application.

And so if the application exceeds the vSync limit or the vSync time that it has allotted to it, like let's say you need a frame every, like let's say 16 milliseconds. If your application takes 18 milliseconds to complete, you're going to get frame misses. So you may have stuttering. In terms of the applications, you may notice that it's like the image is jittery um and yeah that doesn't sound pleasant because i i've i've been someone

who i've never really been able to get into VR because I've always been pretty bad with VR sickness. Motion sickness, yeah. Yeah, yeah, yeah. And that could have just been the early headsets and the early ways that applications were being designed. I know that there has been a lot of research into this problem and methods to deal with it. methods to deal with it because as I was saying before we started recording my last experience with VR was the Vive 2 and before that it was the Oculus dev kits like the earlier like pre-release dev kits which were obviously nowhere near as good as what we have today. So anything where there's any sort of mismatch, frames skipping, anything like that,

I imagine that would just make it so much worse. Yeah. Because of the way we experience VR, skipping frames or having the view lag behind you is very sickening so we have technologies like tracking predictions so basically it uses velocity to predict where your head is going to be in the future and it helps reduce motion sickness and we have uh re-projection um motion sickness and we have uh reprojection um i'm sure you've seen um it was in the headline maybe like a few months ago but there's uh this uh demo a unity demo of implementing uh reprojection in uh flat screen games and how that would uh how you can um uncap uh input from the games um refresh rate and how

that improves responsiveness and i actually missed that one but that does sound really cool and uh vr because if you lag your frame behind because we use our eyes as a frame of reference for where you're on the world if your view lags behind and your ears and your eyes aren't in sync uh in sync making obviously cause motion sickness as you probably have experienced before yeah i've never let uh like let it get really bad or actually like you know you know throw up or anything usually when i start feeling a little bit off i just i i'm just done for the day which made my um in university i had a vr game development class which made that class very fun um 10 minutes of work and then put the headset down.

10 minutes of work, put the headset down. It was not pleasant. I had to do a lot of testing just on a flat screen to get anywhere with that class. Yeah, it sounds incredibly painful. Especially the headset I was lent at the time wasn't even a nice headset. It was one of the cheap cheap Microsoft media headsets.

I don't know what it was called, but it was just not suitable for any gaming applications. It was, you are on a couch watching a movie and anything else. It's just, it just doesn't work for. Yeah. Speaking of other things that are distracting and possibly motion sickness-inducing, in

VR, persistence. So, as you know, display technology is a hold frame. So, you hold a frame and then you hold another frame and then you hold another frame. And how long that frame is displayed on the monitor is lit on the monitor. That is persistence. And you want really low persistence for VR to reduce motion sickness. So that's another thing that I'm not sure at the time when you were doing the VR courses that that was figured out at the time that you need really low persistence displays.

So that could also contribute to motion sickness that you felt. Well, how is the persistence problem resolved? Because the most logical thing that comes to mind is increasing the frame rate, but I'm imagining there's probably some other way that's also dealt with. Yeah, so you do black frame insertion. It's another technology. You just keep the backlit on less.

That's another thing that you can do. you just keep the backlit on less. That's another thing that you can do. So you just, so when you're displaying a frame, like the pixels are, the liquid crystals plate, it's basically always like in a certain state,

but the backlit can, backlight can be turned on and off. And what you want to do is you want to keep the backlight turned off as long as possible. And the reason why you can't just flash it on and off as shortly as possible is because lenses, which are an important part of VR, because it helps increase your FOV and stuff like that that and distorts the actual display. The lenses causes light to be lost and so you have to have this trade-off between how long you keep

your display on and how much light you want hitting your user's eyes. Most VR displays, from what I understand, only produce like maybe 100 nits, and that's like lower than most SDR displays, which usually reach 200 nits of brightness. I would imagine that with it being a much lower brightness, that also helps to counteract issues with people who are very

photosensitive, because if you're inserting black frames, I could imagine that with a certain displays could induce a seizure in certain people. Well, you're doing it so fast, you're doing it so fast. You're turning off the display light so fast that you can't really notice it. Right, right.

Because your eyes just can't update as fast as the light's reducing. You kind of have this persistence to your eyes, too. Like, if you're ever in a dark room and you wave your hand around, you see that motion blur that gets. So you don't need to be really in a dark room, but it definitely makes the effect more noticeable. It's because your eyes take time to absorb light,

and it takes time to um get rid of that information and that creates a lot of work uh in real life so how did you get yourself involved in like wanting to do vr stuff i assume you had interest in vr before you started working on ALVR? Oh, yeah. I just wanted a more immersive experience with every game and stuff. And because VR mimics how your eyes see with parallax, basically because your eyes are slightly to the right and slightly to the left, you have this slightly different view of the world in both eyes and your eyes can read depth from that information. There's also a little bit more to that, like there's this technology in VR called VeroFocal, which basically changes the focal point

of your eyes. So your eyes don't have like, if you start an object like your hand, you notice how the background is a little bit blurred. That's because your eyes can only focus at certain distances at a time. And that's because it has lens. Your eyes actually have a lens that it stretches and contracts

to focus on different distances, objects, you know, objects at different distances. I just went to the Wikipedia page for Verifocal, and I don't know why this is the picture that's there, but the demo used is a picture of Tux, like the Linux penguin. Yeah, that's interesting. I didn't actually know that.

I didn't know it either. I just wanted to find some information on Verifocal while you were talking about it. I didn't know it either. I just wanted to find some information on Verifocal while you were talking about it. So how long have you had an interest in VR and how long have you had an interest in actually working on this problem?

So I've had an interest for VR since I was probably in high school. Probably around 2020, a long time ago. And I really only got interested in developing for VR applications once I discovered an open-source a open source streaming app like LVR because you can't really work on a closed source runtime or VR streaming application like you have on Windows with Oculus software,

the official Oculus software. Right, right. You have to go get a job working at the company to be able to work on that. Mm-hmm. So when did you become aware of ALVR? I think I was browsing Reddit for open source alternatives because I kind of just always have an interest in figuring out how things work. Back when i was a child i i my uh my parents and my

grandparents would like buy me how it is made like movie disc and i would watch it and i was always fascinated with it and so i've always been kind of fascinated with how things work. Okay. Okay. So did you have any background with programming before you started getting involved in LVR or did you very much learn just from the start when you got there? I did have some experience on other open source projects, and I was currently taking programming classes at my high school at the time.

So I did have a little bit of experience. I wouldn't say I'm the best dev in the world, but I do know a few things. Right, right. Tell me about those programming classes, because I know a lot of people just don't get that experience, right. What, tell me about those programming classes, because I know a lot of people just don't get that experience, sadly. So it starts with, so you get like electives, and you can select electives that you want to take. And because I was interested in tech and I built my own PC, I'm like, huh, coding classes, that would be fun to take. And so I just signed up for it.

And the first year you learn Java. Okay. I didn't really enjoy Java. It has like- I know that feeling. It has a lot of boiler flakes where it's like- It does, yes. The main function and classes.

At the time, I was like, I feel like there's something better than Java. Because I just didn't like classes. Right, right. classes. After doing some research on 20i, OPP is bad and creates bad abstractions.

That kind of led me to Rust, which is what a lot of LBR uses, but not all of LBR uses. I know GitHub's numbers are a bit weird and they count C and C++ weirdly, but according to GitHub,

it says 52% Rust, 30% C++, 16% C, but sometimes they mix up C and C++ code. Yeah. It is C++. There is no C because there's a reason why there's no C.

It's because, from what I understand, the OpenVR bindings in C are kind of busted. So, yeah, they don't work. Okay, so it's about like half and half Rust and C++ then. I mean, there's some bash shifting. Yeah, it says 1% other, so I would assume that's part of the other.

Mm-hmm. Okay, so how long have you been doing Rust stuff then? You learned that, like, when you started getting involved in ALVR? Yeah. Originally, I guess I worked on other projects. I originally came from Minecraft. I did a little bit of shader dev there. And I went into an open source application, a mod called Iris.

It was fun for a while. There's some drama and I'll leave that at that. And yeah, I left. And then I went to LVRVR and I've been there ever since. Okay. Happily working on it. So for anyone who hasn't done any Rust development, because I've just started myself actually, like very recently, I was like, so I've been aware of Rust for a long, long time.

I have had friends who have been shilling Rust to me since the Rust beta, telling me how Rust is going to change the world, Rust is going to be this massive language. I didn't bother to learn it way back then. But for anyone who hasn't used Rust, I guess give like a brief rundown on the experience using it, what you like about the language, maybe what you don't like about the language and things like that so one thing I like about it is

well, by default your memory is safe obviously you have the unsafe keyword as a little escape hatch one thing I don't like about it is async. Async sometimes. There are, async is a little bit of a mess in Rust right now.

Cause you got Tokyo and you got these, you got small and have these compatibility layers between them. And certain libraries use Tokyo and then other libraries need small and you have to introduce the compatibility layers between the two runtimes and it's it's a mess and those bugs that come with it. For example, Tokyo really, really likes to spam a lot of threads and so it makes debugging applications a pain because the stack trace is just a bunch of threads and so it makes the bugging applications a pain because the stack trace is just a bunch of threads yeah that sounds like a um not a pleasant way to deal with it especially when the

just dealing with dealing with additional threads just one extra thread makes everything harder. Adding anything more there and... Yeah, I can't imagine that any of that debugging is fun, especially for any complex issues where you're not entirely sure on the replication conditions yet. Mm-hmm. Another thing that comes with that is we're kind of mixing synchronous code with async. The connection code was asynchronous at the time. It's now synchronous.

Thank God. Um, and because the C C plus plus code was synchronous and you did, uh, data copying over, uh, the two sides using a foreign function and faces, uh, in LVR. Sometimes you would get interesting bugs that would appear and would be very painful to bug. Don't mix a sync with synchronous, that's my recommendation. So you said that when I brought up the C++ and C, you mentioned that you wouldn't want to use C in something like ALVR. Why would that be the case? Yeah, you don't want to see because the, like I said the bindings in OpenVR and C are kind of-

Oh, okay, no, you did, okay, right, right, sorry. I completely forgot about that. My bad. Yeah, and the only reason why. Okay, okay. I thought I, we skipped over that. No, no, no, yeah, we covered that. The only reason why we have C++ code is because, you know, there are

some open VR bindings for us, but they don't cover the things that we need and they're not that great, honestly. And make interfacing with the encoders on Linux kind of a pain, uh, cause you have to go through FFI and, um, I'll get into the hacks that we have to do on Linux now. Yeah, go ahead. Yeah, for sure. That's all, all on there. It'll be all right now. We have to fake that word during release display on Linux,

because there was no Direct Mode support, at least there was no Direct Mode support. Direct Mode is basically when instead of displaying, you know, just sending the image to a release display, you instead send a Vulkan image to a driver, and that driver encodes it and then or doesn't encode it, does whatever it wants with that Vulkan image and sends it off to the VR display to be displayed, of course. It was made for Windows, so its API on the Falcon isn't exactly the best, but it's manageable.

And it was made for the Oculus runtime, so you can run SteamVR games on your crest by streaming it to the crest, of course, not actually physically running it on the crest. And the problem with the Vulkan DRM leasing layer is it requires disabling a few things and also requires basically overriding a WR compositor wrapper and making your own that disables a few things like the, I think it's called

fossil something, fossilizer, and it's basically a valve technology to create Vulkan shader binaries that you can just when the VR application runs again, you just load up those cached shaders rather than having to recompile that shader again. You have to disable that. It just doesn't work.

And you don't get overlays. So, for example, Manglehead doesn't work. We need to disable that. And a few other things that we need to disable. And we also, here's what even the more hacky side, We also, here's what even the more hacky side than pretending that you're a DRM-less display. We have to stack walk the VR compositor's stack to find the poses. Okay.

Because without a direct mode API support, we can't exactly get the poses. So just sent as a image to the headset. Can you expand upon that? What do you mean by that? What do you mean by that? So stack walking is basically when you look at the currently running process memory and find some bytes in that application's memory. Generally you look for functions and then in that function you look for offset to that memory location that stores that and then you

grab it so there's two different functions that we look at we look at the async version and then the non-async version so the async version is like when you're running like the compute compute queue version backend of SteamVR and the synchronous is when you don't run the compute and

you're not running asynchronous reprojection. And yeah. Okay. Was there And yeah. Okay, okay. Was there more you had to say on the hacks there? Or was that pretty much it? That's pretty much it on the hacks. It doesn't sound like there's a lot of hacks,

but the fact that you have to stackRack, StingRaw's internal memory is should be enough to to scare away basically any normal developer. Well, I guess, to put it in perspective how much work has gone into

like, actually implementing these hacks? Um years years actually implementing these hacks? Years. Years. So there was a person who originally wanted Zolvatol, I think that's how you pronounce his name, wanted to add Linux support for LBR. I don't know how long it took him, but I would guess it would take a while and you have to either look at Gija or use a new tool called NM that shows you all the function symbols in a given binary.

And you have to look through, like, I think there's, like, hundreds or maybe a thousand functions, and you have to find the correct one. And once you find the correct one, you need to offset the memory until you find the right one. Then once you find the correct one, you need to offset the memory until you find the right one. Then you have to verify that that's actually a pose. And then you have to kind of pose match. It's a little tricky what LVR currently does, and it actually produces some issues. what LVR currently does and it actually produces some issues.

We're working on tracking your eyes for that. But you have to pose match. And the problem with pose matching when you're doing that is you're not given a untranslated pose. Before we keep going on with that, sorry, can you just explain what a pose is and then pose matching? on with that um sorry can you just explain what a pose is and then pose matching so a pose is basically the position of either your controllers or headset into the space okay okay so you know translation rotation you know stuff like that um and and it's uh based off of a space. So you have like a stage and you have local space. So local space would be like, let's say like relative to something and stage is like it's stationary. It's like, I'm trying to think of the best way to explain it. It's like the box, like you're in a box,

and that's your stage space. Right, right, right, right. And that box is stable, and the headset moves in that space. Mm-hmm, mm-hmm. Yeah. Okay, okay, awesome. Cool, I just want to make sure people were aware of that one, Yeah. Okay. Okay. Awesome. Cool.

I just want to make sure people were aware of that one. Because you kept bringing up the term pose, but we hadn't actually gone over that yet. Discussed what, yeah, what pose is. And pose matching is basically, it was done because you need to, so you get a pose from Steam viewer, and you don't know if that pose is the pose to this matching frame on the headset.

And so you want to match them. I forget the exact algorithm that LVR uses for doing that. But you want to match it and make sure that they're the same. The problem is they're not. They're basically never the same. And that introduces problems like drifting. So basically, your headset's view is X and your and your single view is Y, but you want them to be the same.

And if they're not the same, then also you can cause issues with like it's not lined up properly and stutters when the pose, like for example, if you move slow because of how the pose matching algorithm works, because of the timestamps of the pose, they're more close together and so the pose is more accurate. But when you move move rapidly the pose matching algorithm kind of breaks down and i'm and i'm pretty sure the pose is on steam vr is actually slightly behind the wheel the pose of the headset and that causes a huge like stuttering, which is very bad. You don't want stuttering in VR, you want a nice smooth pace for obvious reasons like motion sickness like we talked about before. Yeah.

Okay, I kind of derailed you from what you were saying before. If you remember where you were going, then continue with that. Otherwise we can move on from that. I sadly didn't know. It was something about it was something about pose matching and

poses off the stack. Sorry, I don't remember where you were. Oh yeah, stack walking. Sorry, I don't remember where you... Oh, yeah. Stack walking. Yes, yes. So, stack walking, like I said previously, is a very hacky method.

And we want to get rid of it. But the problem with that is we're currently kind of stuck with whatever Valve gives us because SteamVR of course isn't open source. So you can't just go in and implement it yourself. Same reason why I kind of moved away from Windows and Oculus software in general. from Windows and Oculus software in general.

And so we're going to move to a runtime called Monado. I think that's how you pronounce it. And the cool thing about Monado is it's open source. Woo. I really love open source. So you can see how it behaves. Because StingVR is kind of a black box. You kind of just give it information and hope it does what you would expect it to do. For example, it breaking expectations that you would normally assume. Like you would assume that you give StingRAR a resolution

of your headset, that StingRAR would just give you an image of that exact resolution. It does not. It does not give you. And it gives you different sizes, depending on your

GPU clock speed. And if it goes under a threshold, it just sets it to the index as a resolution and completely ignores the resolution you set. Yeah, that's great. And so when implementing direct mode, you need to add a whole bunch of extra steps. Like you have to resize the image, scale it.

And it's lovely. It's great. Oh, and also another thing. This is another thing that is a problem. Let's say you expect your image to be a certain format because you want to get that format to the encoder. Like a shader that expects an image to be in a certain format. And CBR is just like, nah, you can have this format and you gotta deal with it. Right, right.

So the benefit of Monado is if there are cases where things are behaving weirdly, at least you can see internally why they're behaving weirdly. And preferably address them if that's something that the project is interested in addressing. Yes.

Okay, so when I go to the Monado website, it describes itself as an open-source XR platform. What does it mean by XR? So there's two APIs. Well, there's two APIs. Well, there's actually

multiple APIs, but the two biggest ones are OpenVR, which obviously is SteamVR specific, unless if you're talking about OpenComposite, which I'll talk about later. And

there's OpenXR, which is obviously what Monado implements. And SteamVR implements both an OpenVR runtime and an OpenXR runtime. And the difference between OpenVR and OpenXR is OpenXR is a Kronos standard supported by many, many different manufacturers and projects. OpenVR is really only supported by Valve. It's not very open, if you would say that

it's open if you work at Valve yeah yeah um okay so right so OpenXR is just basically the open source approach of doing this effectively?

Mm-hmm. Okay, okay. It has a little bit of a difference. Sure. It's like, for example, you have extensions and it's like the Vulkan, OpenGL, type of bonus things. And OpenGL doesn't really have that. There's no such thing as extensions. Also it's slightly different on how it does poses and stuff like that and timing.

For anyone who may have heard the name Kronos and recognize that, that is because basically all of the open graphics standards that you know about for the most part are by Kronos, like OpenCL, OpenGL, Vulkan, WebGL, things like that. All of that is managed under the Kronos banner. Okay, okay. So what is Monado? How does Monado fit into the stack here?

So, like I said, Monado is an open source competitor to SteamVR. So, for one thing, it's a little bit more friendly to projects like

us that tend to be very small. For example, there's another project that I've kind of been waiting on how I can introduce them called Riven. Riven. They, Riven, yes. That's what Zabital currently works on

because LBR's infrastructure wasn't really made for Monado at the time, so it wouldn't be a good fit. And it was also made by another dude, I'm not sure how to pronounce his name though, so he's on Zyrepo and Repository and he you know contributes to it but i don't really know him on a uh online basis right right right okay so if we're looking at it like a the high level right how do all of these pieces of vr fit together like alvr monado all this stuff like if you were looking at it like from the outside right like if you

ordered them in the stack of how things fit together like how does this how does it look if that question is worded in a way that made any sense? Yeah, that makes sense. So probably the most important stack is the runtime. The runtime view is basically the thing that implements the standards that applications talk to. And obviously that's a very important stack. For example, any standalone headset has a runtime. Obviously, CineVR is a runtime. And, yeah, it's the most important part of the stack.

And then you got LVR, which basically just is like a middleman between your PC and your headset that is standalone. And then of course you got your applications, which you run. So that'd be like games or like open brush for painting and 3D space. for painting and 3D space. Those are probably... I don't know where to put them in the stack because they're both important because without applications,

you don't really have an ecosystem. But without... I guess I would put them on equal footing streaming applications, slash drivers and you know regular open XR and VR applications okay

okay I don't I don't know if we talked about this or you brought this up when we were actually recording or if you brought this up beforehand but you brought up at some point hardware support on Linux and I don't have any clue what VR hardware support is like on Linux. As I said, my experience with VR is very out of date.

So you did mention there were issues, and I'm sure there's more issues than just the one you mentioned. Oh, yeah. For example, standalone, it's probably the, in terms of SteamVR, the least supported headset type. It's, you know, because of all the hacks and the lack of the Direct Mode API, Monado is is a little bit better, but it's basically both runtimes are kind of made for your wired HMD or head-mounted display, because that's what basically it is. It's just a display with a few sensors to get poses from that point of view.

to get poses from that point of view. And then you also got, so basically for trackers, like full body trackers, you have vibes and you have slimes. Those are both really, both have very good support on my standalone headsets. Then you have Face Tracking and that's where you hit problems because unlike the previous Vive stuff, because Vive is kind of like the accessory provider for VR basically, you run into issues because they change their approach. Instead of writing open VR drivers, they have this own little application that kind of communicates and you have this own little SDK and it's only really works on Windows and kind of run into files. But luckily, there's solutions that I can enough for this problem called i track VR or Babel, I think it's called or

bubble. It was an open source face tracking solutions. Then basically they use cameras and AI, the good type of AI, not the bad type like, you know, like your art AI or your co-pilot that steals, you know, stuff like that. like that to basically take an image, a grayscale image, and build a expression model off of that image. So then you can translate it onto a model, a character, avatar, whatever you want to call it, in the video space and basically have lifelike

expressions and sort of gestures, which is what we currently most people use, which basically requires you pressing buttons on the controller to control how your expressions on your face,

whether you smile or frown or angry or stuff like that. Or you can still solve your applications like VR chat. Yeah, especially for those cases, being able to actually express what you're trying to express would make that a much more immersive experience. 100%, yeah. It is a... Just having gestures is... It's better than nothing, right?

It's better than just having a static face, but it's clearly... That was a stop gap that's not supposed to be the end goal. The end goal is, like, you know, you've probably seen all the, like, all the massive improvements happening. I think the biggest improvements you can see, like, without even being involved in the development of this stuff, if you want to just see what's happening in the world of face tracking, is go look at some VTubers, right?

Look at some of the people that have... They have these models where it's... Thanks to what Apple has done with their face tracking stuff, things have gotten really good in that space. But of course, open source is... Open source development always tends to lag behind things. When you're a multi-trillion dollar company,

you can spend a lot of money on getting things working perfectly in your proprietary solution. Hmm. Okay, so... You did bring up um vr chat before i you did say you wanted to like talk a bit about that i i don't know where you wanted to go with that really but um yeah if there's anything you want to say there um feel free to bring that up yeah so as i said vrChat is a social VR application with a few major breakthroughs that have recently happened, like video player support.

And there's also a huge brave scene in VRChat. And that also recently got support. It needs a Windows protocol called RTSC, I think it's called. And basically, Proton didn't support it up until recently but you do need I think

a girl made I forget who exactly created it but they created patches for in Wine to add support for that and now you can enjoy your

waves in VRChat which you couldn't do before I've honestly never messed around with VRChat I've seen YouTube videos of it and all that but I've never used VRChat myself YouTube videos of it and all that, but I've never, I've never used VRChat myself.

It does seem, uh, it does seem really cool. Um, but also that involves me talking to people and I talk too much to when I'm doing these videos and when I'm, when I'm not doing the videos, I kind of just want to chill. Um, my, uh, my, my social battery is very drained from talking all day. Yeah. I get with that. I get with that.

I work in a, in an industry where you talk to a lot of people and at the end of the day, you're just done. Yeah. Yeah. Okay. So, yeah, yeah. Okay, so let's see. Where can we go from here? Actually, was there anything more you wanted to say

about hardware support? Because I don't know if you were done with the topic. No, it's basically I would like to bring up projects that I think could use a little bit of help from the community. So there's Open Composite, which I previously mentioned briefly. Basically it is a translation layer that translates OpenVR application API calls to open XR application API calls.

And it allows you to play open VR games like, excuse me, VRChat and on Monado, which is obviously only implements open XR. It's only maintained by one guy. That is the case with so many really, really cool projects. Give them some love and support, you know. And it's still, I forget what's its progress on the total OpenVR API, but it recently has received skeletal hand model support, which some OpenVR applications need to run at all, which, you know, it's kind of important. You want as many applications as possible. And it also needs to translate... I think it... problems with shutdown startup or something. I don't exactly remember

how to go look at it, but if someone wants to figure that out and solve it, I'm sure they'll be happy. Okay, that sounds like a really cool project. You mentioned that, was that the only one you wanted to call out, or were there other ones you wanted to bring attention to as well? Yes. Riven, of course. I feel like... I don't think it was a slightly bigger project than the prize room. But both of us need more developers.

Developing a streaming application is complicated because you have to deal with the encoder, APIs missing, for example. APIs missing, for example. And another issue specific to Monado is headset, even though it can achieve, it's hitting 90. And that's because I think the pacer, which basically paces the application, so you're always getting frames when you need them has this feedback loop. I think it's the exact way that I think either goes negative or positive. And when it does that, it kind of trips up the the pacer and causes it to basically end up locking itself to

half of the refresh rate of the headset and it will not get out of that lock. That sounds fun. Yeah, it's fun. Yeah, I... Look, that would make my issues even worse. Less frame rate, hey, maybe a couple of stutters here and there, a bit of latency. You know, very pleasant VR experience. Yeah.

So when it comes to refresh rate, at what point is it generally accepted that that's a good refresh rate to be hitting? You want to at least be hitting, I would say, 45 with the headsets native being 90. You don't want to really go lower than that um obviously the higher the better um in terms of refresh rate um but you really don't want to be going below 45 i would say especially if you're very sensitive to motion sickness.

Right, right, right. Yeah, 45 sounds really low, but maybe it's... It's not that bad, and that's because of another technology called Reprediction. That basically synthesizes new frames out of old data. Okay. Hmm. So it sounds like there's been a lot of work in trying to just deal with the problem

in more ways than just brute forcing more numbers. Mm-hmm. deal with the problem in more ways than just brute forcing more numbers. Because I guess there's always going to be, like, obviously your best experience is going to be on the highest of high-end hardware, but I guess if you want this to be something that people actually adopt, you need to make it so, like, middling and lower-end hardware is actually viable to play most things yeah essentially with um uh not being able to compute tunnel right because if you need like a if you need a 4090 for your experience to be good,

you know, yeah. Yeah. Yeah. So you've brought up the idea of direct mode and display leasing. Can you explain for anyone who's not aware what display leasing is? And we're obviously going to lead into the DRM leasing discussion after this. Oh yeah so DRM leasing is basically a protocol that needs to exist because VR headsets are special little snowflakes that need to bypass the system compositor and go directly to the runtime's compositor

and skip all the steps of a regular desktop compositor step because the players need to have very low latency and they have special needs. Like they need to be very consistent on pacing with a desktop display. If a frame takes one minute to update, that's no problem. Obviously, I'm exaggerating, but in a VR application, if a frame takes a little bit more reasonable amount of time, a 100 milliseconds to update, you're going to get sick. compositor that may have other applications that it needs to render and go directly to the runtimes compositor which has a very very narrow focus on VR applications for example it needs to

do lens distortion correction mirror correction and a few other things that just are a side effect of having lenses in front of a display. And obviously that's not fit for a system compositor. I guess a good way to put it is a stutter on a flat display is an annoyance, but a stutter on a VR display is an annoyance, but a stutter on a VR display is a health risk. Yes. Okay.

So when the conversation of DRM leasing comes up, no one really brings up what happens on the X11 side. So on that side, like what happens? I assume, I haven't heard any issues about it. So I assume you can just make it work without any problem. Yeah, that's because it's in the XORG server. So you really don't have to worry about that as a compositor.

It's kind of like just write your compositor, and you get Leeson. On Rayland, obviously, the walls are set up a little bit, and the compositor needs to actually implement that protocol. And if it doesn't, well, then your display either is not going to turn on or it's just going to be treated as a normal display and your runtime, which is expecting a you know to receive a direct signal to that.

Display is not going to see one, so it's just going to be like there isn't a headset and just say there isn't a headset because we can't see So what is this I know the answer to this, but anyone who's not aware what is the state of DRM leasing

under Weyland? The state of DRM leasing under Weyland? The state of DRM leasing? Hold on just a moment. It's a very short list of things that don't support DRM leasing. Could you repeat your question? Okay, okay. It's all good. I'll just cut that bit out.

The state of DRM leasing on Weyland. I know the answer to this, but for anyone who's unaware, give people a brief rundown. It's great. Unless you use, you know, you know, because you know things. I don't use Gnome,

and that's all I'm going to say about it. What are you actually using as your desktop right now? It depends. Sometimes I use KDE, sometimes I use Cosmic. You know, the RSD that System76 is making. I do want to bring up Cosmic a bit later I did see that you have made a couple of commits to it because I'm very excited for Cosmic

as well I haven't had a chance to test it just yet but I am very excited for what I'm seeing with it yeah it's definitely coming together it's going to be great okay so what needs to be said about DRM leasing right be great. Okay, so...

What needs to be said about DRM leasing, right? Like, from your perspective as someone who actually is involved, because I can look at this from the outside, right, and I see there are people from Valve, there are people from other desktops, there are application developers who are saying we need DRM leasing support on GNOME. You are holding back the development of this technology by not supporting this protocol, but

that's just what I've seen. What is your perspective on this? My perspective is I agree with those people. It does affect LVR because we do kind of use that protocol without having the direct mode driver support in SteamVR. But now that they have implemented it recently, it's not perfect by any means. But it's workable.

That's no longer a concern for us. So, you know, I still wouldn't recommend using GNOME if you're going to be doing VR, but it's workable now. It's workable. If you happen to have standalone headsets, only standalone headsets. Only standalone. Okay, what is the difference between having a standalone headset

and one that's not then in this case? So a standalone headset is basically a whole entire system with a wired headset or HMD. It's basically just a display with sensors. Okay. a wired headset or HMD, it's basically just display with sensors. Um, and so with that, um, you actually need to send display information to that over the, a display protocol, which a normal system compositor, like I said previously, would usually just immediately grab it and not

give it to any other program. But for sound learning headsets, you can communicate over any protocol you really want. It could be display, you know, like DisplayPort, HDMI, or you could communicate over USB, or you could communicate over USB or you could communicate over Wi-Fi. So you don't really have to deal with the problems that come with people not supporting a certain protocol. So you can sort of just like, I guess, ignore the whole issue and just work around it in those cases.

Yeah. I guess ignore the whole issue and just work around it in those cases. Yeah. So are you aware of the more recent discussions about DRM leasing on GNOME? Like as of a couple of weeks ago, some merge requests have been opened? Yes, I was aware of that. I'm not sure what the current status of them is, but I do know that they've been happy. Yes, yes, this is the one by Blake Batson I believe is the one No, maybe this is a different one Wait, is this a different merge request?

Wait I think this might be a different one Why are there two open merge requests about this? Like... I don't know. I don't know. That's why.

Yeah. That sums it up. Like, I can... You know, I was going to say I can understand why there is this issue on GNOME, but, like, I think that the main issue that I have is that there was this agreement to implement the protocol back during the discussion.

I think that's the worst part about it, right? It would be one thing if the entire discussion got stalled because there was just nothing happening whatsoever. if we were still in the state that we're in like three or so years ago but the fact that there was an act and they were like hey yeah let's actually implement this let's go ahead with it like implement this, let's go ahead with it. Like, it, it's just, it,

for me, outside, it's annoying, right? But I can only imagine how much worse it is for someone who just has to say if you want to make use of this solution. Like, in, um, in, in Valve's documentation for SteamVR, their

solution for running Gnome Wayland, one of the solutions is install KDE. Yeah, it's great. Like I... I don't know, like I'm happy that something is being worked on and progress is being made here, but... It's just... It's better late than never, right? But I really wish that this entire whole DRM leasing saga just never happened, and... This just got resolved years ago. It would be one thing if GNOME was this small desktop that no one had to care about,

but GNOME is the face of Linux. It is the first thing that a lot of people see and they see VR just not working in the case of, with the exception of the standalone headsets. But I don't know. If there's anything you want to add to that, go ahead. There's a lot of things I'm just sick of dealing with when it comes to issues on GNOME.

Yeah, it's frustrating. I would put it on the same level of frustration of having to deal with all the hacks that LVR has for years and having Valve finally taking things serious for Steam Beyond Minutes and actually working on things now. Because it was hell for about two years in the project of having to deal with issue after issue after issue, especially with like... So like, you know, SLR, the Steam Linux runtime, it's great and all. Except for when you can't use it because you're missing APIs. And so you have to implement workarounds that don't work with that runtime. Because it's too old.

And you need modern features I think I might have come across that discussion you were having I didn't save the link though as I said I went back through your entire history on GitHub trying to

find things to add to the list of topics. So I think I might have actually saw that one. Yeah, I was really hoping it could be solved. But, you know, it just can't. That's the state of a lot of things with LVR, with StingVR. It just can't be solved because we're waiting on valve to do things right. And valve is slow. I guess that's why you have this interest in

Yes, yes. Because Monano, you don't have to write on this low company to actually get a working product out. I mean, SteamVR is a product and it's horrible. Okay. Can you expand upon that please like what besides any of the stuff you said like what what do you not like about steam vr well they basically they have so many issues. One I already discussed, they have this weird dynamic image stuff where it can be any size that they decide. If they have to use a fallback, they use a fallback rather than just of their own hardware.

So it's like they only care about themselves. So at the same time, they don't try to make it usable for anybody else. And the just lack of interest, the amount of times they've broken things, the lack of testing that they do. Like, for example, there was at least, I think, three separate times when they've messed up a

bash script. They bash up everything, which is awful to start with, but I can kind of understand why they do it. That seems to have a very bad history with bash scripts. Um, yeah.

And they basically, like, update, they basically just completely deleted the script and made it reference this internal script that they never committed. And Steam.io broke the limits, and you have to use workarounds like going to the old version and then I think you had to do

a few edits. And the reprojection is a mess. They've recently done some improvements to it. Obviously, I can't tell you what improvements are there

other than the changelog of experimental improvements to async reproduction so hopefully they get the stuff together but it's going to be a painful road for the

you know maybe the next few weeks or how long it takes. The last, you know, this goes with software development, this goes with road trips, but like the last few moments are the most painful. moments are the most painful. Okay, well... Let's sort of put this in a different light, right? Since the time that you've been working

on AOVR, have things been getting better, at least? One step forward, two steps back is how I would put it. Okay. Okay. That was not the answer I had hoped for. Yeah. We're having to introduce more and more workarounds as we get closer to removing all those workarounds.

So that's how I would put it. For example, they added Rayland. When they got the arm lacing, they added a Rayland backend. And so you would either, depending on if you're running NVIDIA, because NVIDIA didn't have support for that just yet. So you'd have to force it to run under x-ray win. And then we introduced another wrapper that wraps the Raylan protocol.

But the problem with wrapping the Raylan protocol is, well, now you have the GNOME problem. And then they introduced the runtime. And so we solved that by asking users to install Sting Play None and then setting the runtime to use that in the compatibility drop-down menu thing that you'd usually use to select proton versions. And then that broke recently. And so now we're having to tell our users to add a – there's launch options that you can add. And so you have to have the specific launch options

because we're using Steam Play None broke in 2.5, which introduced direct mode support, kind of. And that's because they forgot to include certain APIs that you need as the driver to access the image. There's this internal VR core API called ReceiveSharedFD because Vulkan has a API that allows you to turn a file descriptor into a Vulkan image. But that wasn't, you know, exposed in the API. And it's not like you can just add i put the so file the symbol is private so if you add it to a header

file it just say that's not found because the function itself isn't exposed to uh any public interface. So you have to do more hacks. More hacks. And that being you have to use a GNU function. Let me forward up. This new guy that came in. Let's not apply a demon or a duck, depending on how it wants to go by. He's adding one at a split. Thank you. I got a scroll so far. Let's look. I have to... Trying to find it. This is good.

I think I'd find it better if I do this. Yeah, it's called dl-iterate-phdr. It's a new function that allows you to iterate a object file and find private functions and then do a few more things to get a pointer to that function and then be able to call it. And the problem with doing it that way is if they update that program, the offset to that function changes. And so if they don't... If we happen to get things working before they finally release that API,

because there's a few other problems that we have to work out, specifically with the present call, we have to re-import images, which you shouldn't do, and the API guarantee isn't actually upheld by the runtime. It didn't check that. Thank you.

They're working on that. That's the good thing, though. Okay. Wow. And so you have to basically at runtime, you have to look at that and then analyze it and then figure out the new offset to that and it's it's a mess

it's very much a mess maybe this is a much shorter answer is there anything that you have worked on that hasn't been a hack and hasn't been a mess and has just been pleasant there's nothing I've mess and has just been pleasant. There's nothing I've worked on that's been pleasant.

Okay. Okay. The good guys, like the people who work on it it's just it's a mess I wanted to throw a rope there see if you could find something but nope nope no there's nothing well it sounds like

it sounds like it definitely occupies quite a bit of your time then oh yeah we get like i think on average maybe one two support questions a day which doesn't sound like a lot but i have a life outside of LBR. So, yeah. Well, let's move to something that actually is pleasant. Let's talk a bit about Cosmic. Because, as I said, I'm super excited for it. It sounds like you're interested in it.

You're making some commits to it. So I presume that you're also fairly interested in it as well yeah I am very interested in it I am I'm a little bit of a Rust fanboy I really like Rust so I really like when I see

components written in Rust but that's not the only thing like obviously So I really like when I see components within Rust. But that's not the only thing. Obviously, I like. So the problem with KDE is it's sometimes a little bit crashy. Yep. When you run it with especially especially with SteamVR

which is for example there was a bug a while ago it was a plasma shell bug it wasn't really a SteamVR bug but SteamVR triggered it and when you're developing for applications, you constantly run that program.

It kind of gets annoying. And just like, and also sometimes it would crash other programs with the shell too, which is like, yay yay thank you i would i don't like to lose in my work um with other applications because um you know there's still no um protocols for saving application state and stuff like that so yeah that's a very long long work in progress yeah hopefully that happens at some point hopefully my hope is it happens sometime during plasma 6 yeah i've got like nine years to work on that so we'll see obviously like a composite crash isn't going to say that but just the more the more and more modularized it is. And I've seen a few crashes, but obviously it's alpha. And as long as it's not a composite crash,

I've never seen applications get brought down when a program crashes. For example, I remember this one crash where you move a point a year closer outside of some point and your panel will just crash. That was a bug at one point.

That was fun. That's how you produce it. I'll just make sure not to do that. But yeah, that's, that's, that's awful for you. Obviously, that's not an issue anymore. And it's been very stable so far. It's just ever since that bugs been solved, there's been a few Smithy, as you know, that's their library that they use. It has some regressions with XWayland,

which is because, from what I understand, Cosmic is really the only DE that is kind of focused on getting XWayland applications working well. I know that a few other compositors that use Smithy kind of focused on getting X-Rayland applications working well. I know that a few other compositors that use MIPI have started implementing support a few months ago, I think, for X-Rayland, but really only Cosmic was doing that, so there's a lot of regressions like for example there was a refactor that broke um broke i think the geometry calculations for it and so you would like move a window to uh

underneath another window and you just couldn't click on the window that was above that previous window. Well, the whole Smithy ecosystem is still relatively new. Like, Smithy's been around for a bit, but as for things actually using it, as for things being sort of kind of ready to use as a regular person. That's a relatively new thing. So I'm not surprised there are still these regressions that

happen. Yeah. But it's like in terms of the theming, I know you... It's amazing. I know you don't like the light theme, but I actually like it. Okay. Sell me on the light theme. I want to see how it works., okay, sell me on the light theme.

I want to see how you do it. It doesn't blind you. That's true. So, the problem with modern light themes is they're literally just blasting you with the hex code of FFFFF. Like, full bright, right? Yes, they think light means

as bright as the display goes. Yeah, and that's... and Cosmic actually reasonably understands that that's a bad design pattern and doesn't do that. Which one of their blog posts talks about light theme? Here it is. That's, okay, I'll give you that, right? I just I I don't know what it is about the theme I think it's that the dark accents around the outside instead of the the light accents so if they like my main issue is they if they swapped the light and dark parts around

I think it would look better but I do understand what you're saying there with it just simply not blinding you and that being it's much nicer than how Lividwaiter does it where it's I don't know if it's FFFFF but it definitely

feels like it yeah but I'm a dark themed person anyway so honestly it doesn't look FFFFF, but it definitely feels like it. Yeah. But I'm a dark theme person anyway, so honestly it doesn't... Look, if their light theme is bad, I'm never going to look at it after the first 30 seconds of opening up Cosmic anyway,

so it doesn't really affect me. Also, while you were talking about how you didn't like how they inverted it, I actually think I like the inversion because it actually... So the more... The darker parts of the theme are more space than the lighter part of the theme. And I think that just helps even on top of the not using full rights right uh to make it less

of a blinding theme okay that's fair that's that's that's definitely fair i think it would bother me more if they didn't have a theming system right right? Like the fact that they are... Not like a... You know, whatever GTK's nonsense theming it had the entire time, it was just CSS, but... Actually building a theming API from day one, where... I... I haven't seen someone do this, but I imagine you probably could... Swap it the way that I would like it as a light theme anyway. So it probably isn't that big of a deal. It's just the default.

I think the fact that they have a theming API there from the start honestly just deals with all of my issues, right? Because if you just don't like something, you can just recolor it. So what... Besides it being a little buggy because it's you know it's not even the alpha right now you're pre alpha like if they haven't even got the alpha out yet what is the experience being like it's been very good if you ignore the bugs. I love the applications. I think they're improving the UX in terms

of what Plasma has. And I forget the exact reason why Plasma, but one of my friends in LVR brought this up about how the Plasma theme isn't exactly consistent across all their applications, and they don't follow the same style. And so you go from one application to another, and you're not sure you're going to have the same workflow. And GNOME doesn't have that problem, and neither does Columnic. Yeah, I think that has to do with the way

they're doing widgets in KDE. I know KDE has a widget library called Kirigami, but I don't know what is and is not using it. So I would imagine that probably would lead to some of those issues as well. Mm-hmm. But, okay. With Cosmic, are you

a floating or a tiling user? I am floating, and that's just because that's what I'm used to fair enough fair enough I would love to try tiling it's just it's a hurdle for me to it's a big hurdle for me to get over right no I I'm totally fine like someone's used floating like that's fine but one of the things I like about cosmic is it clearly has like the developers clearly wanted to make both experiences actually good from what i'm seeing like when i've spoken to jeremy uh and when i spoke uh spoke to carl as well like they were both like yeah tiling it's not

the thing the majority of our users use when they were still doing the whole like gnome pop shell thing um but it was still something that enough of their users cared about that they wanted to make sure it was going to be a good experience in this as well and whilst i whilst i'm on kde right now and i i i'm i'm doing things floating because i polonium doesn't work uh it's the main reason actually it crashed my entire compositor. I think it was because of a vertical monitor bug. I don't remember the exact reason. But whilst I'm on floating right now,

I am... I prefer tiling. I've been using tiling window managers since I started using Linux. i3, AwesomeWM, BSPWM, Sway, Hyperland. And... That's the better experience for me. But there are very specific cases where I prefer floating windows. Like, I usually have my notes when I'm doing this in a floating window,

or if, like my browser window, I usually have it floating over the video call because I put it over my face so I don't have to stare at my face the entire time. And just little things like that where I want my floating experience to actually try out tiling, because what I find as the reason a lot of people don't want to do it, is they're scared away from the configuration process, they see, like, the i3, they see, like, i3, and it's like, okay, I have to write a config file to make my window manager work the way I want it to work. Like, that just seems overwhelming. Whereas Cosmic, you know, it's a desktop environment. So it's got all that GUI tooling there. And I think a lot more people are going to realize that maybe they do like tiling.

And the issue they actually had was they just didn't know how to or where to start with actually, like, configuring a Tyler. Yeah, I can see that definitely being an issue. Like, it's not a specific problem with me with Tyler. It's more of, like want, like for me, like I sometimes want to have a little bit of overlap over applications.

For example, like maybe I want to, like if I have like my music application open and I have like disco open, maybe I want like the audio section of the, of the audio, the audio streaming music streaming applications be slightly exposed. So I can just quickly, you know, move my mouse over and I know exactly where the ui is and you can just you

know quickly do that but i do understand there was some organization um that you lose with that is just a compromise that i'm willing to make right right right no i get what you're saying there that actually does sound pretty useful um i do all of my media control on my keyboard. So like for me, that's not really a big deal. But I guess if you don't have that set up, like, yeah, I can see the value there. Like as much as I like tiling, I understand that people have their other workflows

and they have things that work for them. I also understand there are people that don't have workflows and they just open 50 windows on the same monitor and have no idea where things are. But, you know, it's your computer. You can ultimately do what you want with it. I just want the...

I just want there to be the opportunity for people who want to try out something new to actually be able to do that in a way where it's not like crazy intimidating right like that's that's my point where most window managers even something like i3 which is relatively well configured out of the box is still fairly intimidating for someone who has always done everything from a desktop environment. Yeah.

I wouldn't have submitted you with that. So, in its current state, what do you feel like Cosmic still kind of needs to iron out? Besides, obviously, specific bugs, but general issues that just exist maybe across the desktop or in application design or anything like that well I do know that I've had some not like maybe application design but like maybe working on for example the cosmic store i've had a lot of problems with it almost it just doesn't want to detect any mms i have installed um that's more of a bug but it's uh it's kind of a big bug. So I would like to see,

I know they have like a pop and that's their thing, but I would like to see maybe a little bit more testing on other distros for more distro integrated software, like a store where you have to use like a package kit and stuff like that yeah i for me like i i was never going to interact with a graphical store anyway so for me like that's that is that is as non-issue as non-issue as it gets for me but i know there's a lot of people out there that you know do like to use these these graphical software managers I

like them Because it gives you more information you can see like how the application works like And you have to like search up in the browser this application open up another tab for this application search up in the browser this application open up another tab for this application um you can just have this one window and you want to look up an application you look it up and you look at how it looks and you can decide to install it usually i like i prefer to enroll for installing things but like having a store to actually view how things look like in a centralized location is incredibly helpful. And I think more DEs need to have something like that. I know Plasma has that, like they have discovered, I know GNOME has that.

I guess I should say, is there any other Ds? Well, no, I guess I should say that I would love to see maybe generic non-DE-based solutions for smaller compositors like maybe River, Hyperland, XFC, you know, stuff like that. I'm sure there's got to be something out there. I know there's some terminal-based solutions, but I don't know. Yeah, a lot of the software managers are just desktop-specific.

If someone knows about one, wait. desktop specific if someone knows about one um wait um i guess it's not uh in this case it's not distro independent but there are things like pamac which yeah that exists um but that is still like arch specific in that case um yeah i don't know of something that is still like Arch specific in that case. Mm-hmm. Yeah, I don't know of something that is both distro and desktop independent. Someone's going to tell me though. I'm sure they're going to tell me. So with Cosmic,

are you just running that like on your Arch system? Yeah. Okay, so you've installed the Cosmic Epoch Git, whatever it is? No, I've installed it using the standalone packages for each application because I like like just having the latest to experiment with. And you can't really rely on when Pop!OS or someone wants to decide to update Epoch to get new versions. And when you have a pre-alpha DE, sometimes you just want those features as fast as you can get them and you know obviously

that's the faster way to do it okay okay i didn't even thought of doing it that way i i guess that it probably takes does it how long does it take you to actually like do an update like how many how many pieces of cosmic are there at this point um there's the settings um app there's the settings daemon there's um the panel there's the outlets but they're all like grouped into one thing one package um there's a compositor one package. There's the compositor. There's the launcher. There's the greeter.

There's the notification server. There's, of course, the session manager. Cosmic session. I didn't expect you to start just listing out components. Oh, yeah, there's cosmic files. Cosmic files. There's cosmic editor. Cosmic Files. Cosmic Files.

There's Cosmic Editor. Yeah, I think that's about it. There's also Cosmic Player, but that's kind of experimental, and I don't think it's packaged yet. I'm looking at the... On Epoch, it's not listed here, so... Yeah, it's very experimental it's kind of like one of those things

where like, yeah, it's not exactly ready to be downloaded by and used by most people I'm assuming Cosmic Player is a video player? yes, it's a video player oh yeah, I forgot to mention Cosmic Screenshot 2

and Cosmic Grandeur. That's another one too. Huh. One thing... With Cosmic, right? I do want to test it, but... Testing it right now on Arch is going to be a bit of a... You know, a bit annoying.

Either I have to go and install everything independently, or do the whole Cosmic Epoch Git thing, and that's going to take quite a bit to compile. I hope, and I would imagine that it happens, I really hope that someone

on the Arch team, when things are ready, decides to make a package. I'll be very surprised if it doesn't happen, but maintaining a desktop is obviously like a big maintenance effort. So I don't know if it'll happen during the alpha or they're going to wait till later.

I'm probably just going to end up testing Cosmic in a virtual machine machine using something like... There's an image of UBlue that has Cosmic attached to it, or maybe I'll grab a Pop!OS ISO when they're shipping it on Pop!OS and test it on that. Yeah, it's going to be pretty soon, because from what I understand, Yeah, it's going to be pretty soon because from what I understand it's going to come out in 24.3... No, 24.04 or 24.10, I forget which one.

Yeah, the question is when they decide to release it. We'll have to wait and see on that. I i am i'm excited for cosmic i very much am because it's i know it's still an alpha and i know there's still going to be bugs but there's just so much about it that seems like it's coming together well. And it's come together really, really quickly. And I have a lot of faith in the System76 guys that they actually can get something

really well put together. And it seems like it seems like they are learning from the mistakes of both GNOME and KDE. And using that to sort of jump start where they are. They're not making a desktop in a vacuum, they are making a desktop in the context of what exists now and learning from what's already been done before.

Yeah, which is obviously an advantage for them you know i hope it turns out well i really do because i i i i want to try it i do i definitely do and it may end up just being the thing that i run or i go back to something else because i i don't hate KDE but I also have my own issues with KDE that I've talked about plenty on my channel my favorite one being the whole let's just not use your use your RAM as cache let's just use your driver's cache for no reason oh yeah i'm glad i have it in dot two in my pc because that definitely limits that as well well before we uh start wrapping things up is there anything you want to touch on that we didn't talk about with VR or anything else you want to talk about?

Um, no I don't think there is anything. I think we had a wonderful conversation. Okay, let me see, is there anything I want to bring up here? I think that's pretty much it actually. Yeah, it looks like it. Okay, well, I guess you already mentioned some projects before, but if you want to bring up projects you want to direct people towards again, go ahead and do that. Oh yeah, I would recommend going to the LinuxVR Discord. I'll maybe post a comment or send you a link to that. Yes, send me an email or something. All right.

Obviously, there's LVR. There's Wyvern, OpenComposite, Monado. As much as Steam Drawers are paying sometimes, you know. That's a cool project too. Give them some love, you know. Baby's just out with

looking at their issue tracker. And yeah. Awesome. You don't really have any online presence with this account, Yeah Awesome You don't really have any like online presence with this account So I was good. There's not really anything that I can direct you at awards with your stuff But um, you do have a github account. So if you want to store If you want to stalk what Vixie is doing on github

Yeah, I really only use Discord. You can find me in LVR's Discord or LinuxVR's Discord and ask questions there if you want to. If you don't have Discord, I got stuff locked. I don't have anything to say about that. Oh, I guess I do have a matrix.

You can send me. You can do. I have a matrix that I can probably do a comment to. If you don't like Discord. Yeah. Other than that, that's pretty much it. Awesome. Okay.

As for my stuff, then, the main channel is Brody Robertson. I do Linux videos there six ish days a week Go check it out. See what's there? I don't know what to be out by the time this comes out by the time you see this There'll be something Linux related probably The gaming channel is Brody on games. I stream there twice a week. I am probably still playing through It Takes Two and also Sekiro because I am very bad at Sekiro and it's going to take quite a bit of time. And if you're listening to the audio version of this, you can find the video version on YouTube at Tech Over Tea. If you want to find the audio version, there is an RSS feed. It'll be on your

favorite podcast apps. Search for Tech of a T and you will find it. I'll give you the final word. What do you want to say? I hope everyone has a good night or day whenever you're watching this. Easy enough. See you guys later.