I would like to interject for a moment. This statement is technically true but disingenuous and facetious.

While it’s true that Linux is just the kernel, what most people refer to as Linux is actually the Operating System GNU/Linux, or, as RMS would now call it, GNU plus Linux, or sometimes, a less GNU depended, but mostly GNU/Linux compatible OS, or, as I have literally just now come to call it */Linux.

Moreover, a modern */Linux system is expected to be based on SystemD, unless explicitly avoiding it due to some technical constraint or some desired feature of another init system. One could come to call this SystemD/Linux.

And lastly, this kind of use case would be the perfect match for a Wayland shell, as opposed to an X11 shell. Which would be more efficient, and would give the shell more freedom in the management of windows.

As a result, when asking about a Linux phone, we could expect one is talking about a phone running a SystemD+Wayland/Linux OS, or at least a mobile-focused */Linux OS.

The Android kernel is a, largely downstream, fork of the Linux kernel, but the Android OS is in almost no way compatible with any */Linux OS, and it’s instead its own completely different OS.

The server in question is a raspberry with 4 gigabytes of ram, so I will need to use containers very sparingly. Basically I’m using podman quadlets only for those services that really only comes in containers (which for now means only codimd, overleaf, and zigbee2mqtt), and I’m running everything else on metal. But even with containers, I would still need to manage container configurations, network, firewall, file sharing permissions, etc. just like I did without containers.

I think that someone already tried (and failed) to make a wrist band thingy in the past, so they probably can’t patent it. That is, unless they went out of their way to patent the sensor technology itself, or the UX, instead of the concept of a wristband thingy

I haven’t read the article yet, but I just wanted to say a couple of things.

First of all, I keep noticing people around me with bulky glasses that look like they came out of the DEVO peek a Boo video, and all I can think is that if I where Facebook I would use my power to influence fashion towards bulky glasses and make my glasses look sleek by comparison.

Second, it sucks that the wrist band thing is being tied with bullshit ai glasses. I would love to see that as a regular input device for PCs and smartphones.

Pissing is a scam to make you drink more, let it go

It’s digital audio, not analog, I doubt the GPU could ever be an issue. I suspect either there was a bug in the interaction between pipewire and the drivers (on one side or the other), or an update changed the default sampling rate of pipewire

I have yet to read this, but. But the first part is like the internals of systemd, you won’t immediately need it.

If you want to make use of systemd, you can skip directly to where it explains unit files. You’ll soon see just how much it can do for you

Have you tried gnome connections? It’s more on the “quick and easy” rather than “professional” side, but maybe it does the job.

Tho I wonder whether it’s more of a windows-side issue… maybe windows 11 requires some kind of online authentication that cannot be implemented by other clients, and maybe this authentication can be turned off. I’m merely speculating here, but I know that remmina works for windows 10 so it’s suspicious.

AMD has an nvdec/nvenc equivalent called AMF, on Linux it’s going to be deprecated in months in favour of va-api.

To my knowledge, it does not have an nvfbc equivalent. Which anyway, Nvidia has deprecated on windows in favour of a windows-native screen capture with a name I don’t remember.

For what is worth, va-api encoding + kmsgrab works pretty well for me, it does have some latency, but nothing too unacceptable. Probably less than the one caused by the Bluetooth controller. And none of this is vendor specific, you can get it working on Intel, AMD and Nvidia (Nvidia needs a compatibility layer, but it works). Also, it works on Wayland, but sunshine needs some privileges to work.

Sunshine supposedly supports nvfbc with patched Nvidia drivers, even on Linux, I haven’t tried it, so I don’t know if it works on Wayland. I don’t see why it shouldn’t, as long as you give sunshine privileged permissions (like you need for kmsgrab). Even without nvfbc you can use nvenc, so you don’t need the va-api compatibility layer.

Supposedly, since this Nvidia driver release nvfbc is used as backend for pipewire screen capture, so it should just work for apps like OBS, I don’t know if sunshine has intention to move to it.

In general, screen capture on Linux pretty much works, even on Wayland. The general sentiment that it’s broken is actually old news.

There’s a caveat though. Proprietary apps tend to use outdated stuff (e.g. electron builds from 5 years ago) and thus don’t support screen sharing on Wayland.

Did you solve this in the end?

Try checking the sampling rate in your pipewire config. It should be 48000. I don’t remember exactly how to set it, check on the arch wiki.

Last time I had issues with digital audio that was it.

I still use virtual desktops, just a lot less because I can just minimize windows instead of banishing them to a different desktop, and that’s how you quickly end up using too many desktops, the problem is that then you need to remember where every window is when you need it back. With regular wm you can just press the icon to go back to the window regardless of where it is.

Splitting the thread here. I personally used i3wm for more than a year and became white fast with it, then I had to use windows for a month and when I went back to i3 it was a pain, I couldn’t do shit. It was at that moment I decided “why can’t I just stop forcing myself to this PITA and just use the mouse faster?” And I never used a tiling VM again, personally I use kde on desktop and gnome on laptop.

But, I can see the appeal of automatic tiling, so I raise you this: scrollable compositors. You get both the benefits of automatic positioning and oc moving things in and out of the way, without keeping track and managing 10 virtual desktops

A couple years ago it could never have worked properly, Nvidia drivers didn’t support Wayland. Because Nvidia refused to implement drivers that followed the Linux semantic (which admittedly was outdated). About a year ago, after many years of work, they published a new semantic that Nvidia was willing to implement. Alongside that, a new Wayland protocol was added so that compositors could opt-in the new semantic when the driver supports it. So, to use Wayland with Nvidia you need both a recent enough Nvidia driver (I think anything after last July) and a compositor that implement the linux_drm_syncobj_v1 protocol. I’m not even sure hyperland supports it, so you should also look into that before continuing.

P.s.: gnome’s mutter, and kde’s kwin (which are the name of their compositors) both supported that protocol since the very day after it was released, so those are guaranteed to work if they are recent enough, unless if you are on Ubuntu lts which stripped it out for a pet peeve about adding features to lts releases.

I don’t have such a laptop, so I can’t really speak for experience, but I can tell you what I know.

You definitely can use prime to render a program on the dgpu and display it on the igpu, this requires basically no configuration at all on wayland, I even did it on my desktop computer when Wayland didn’t run on Nvidia. But I don’t know if you can or why you would use the dgpu for everything instead of only selected programs (games).

What you really need is a compositor that properly uses both GPUs and can use the ports of both at the same time, hyperlaneld might just be bad at that. Gnome should be in a better position so you can start from here and see if gnome behaves better.

Also, are you sure you want to use a tiling compositor on a gaming laptop? Wouldn’t it be a better experiment to just go with gnome? It’s visually polished and goes well with trackpads.

Is this supposed to replace bluez?

I think Hellwig understands everything very well, he just wants things done his way, for whatever (possibly valid) reason he might have.

Literaly from your quotation: “I assume that we’re good with maintaining the DMA Rust abstractions separately […] No, I’m not” He understands the abstractions would not be in his domain and maintained by someone else, he does not want abstraction at all.

Maybe you are not familiar with the proposal but these “separate rust abstractions” would be a separate module that depends on DMA mapping as a client and deals with cross-language issues, rust drivers would then be clients of this module, it would not be part of the DMA mapping module, it would not be mixed with the DMA code. But Hellwig doesn’t want an abstraction module at all, Instead he want’s you to “do that [the abstraction] in your driver so that you have to do it [maintain a cross-language codebase]”.

Please notice that the abstraction module would not add any more burden on him than the drivers themselves would, because as of now C code is allowed to break Rust code. It would only remove burden from maintainers of Rust drivers, and even if it weren’t it would be easier to fix just the abstraction instead of every driver.

He also refuses to have other people maintain the abstraction, this too for whatever reason, which accredits his request to not add abstraction he would have to maintain. If the abstraction were part of the core dma mapping code, I think it would be a reasonable request, but it wouldn’t be.

Now, we do not know the reason why he opposes it so much. From his words it looks like he doesn’t want Linux to be a cross-language codebase, which would be a valid reason in itself, but dealing with abstractions in drivers instead of a module doesn’t make it any less cross-language, unless the drivers are out of tree, which they wouldn’t be. Some people (e.g. Hector Martin) think that he’s hoping the Rust for Linux project to fail altogether, and fore rust code to be removed from the kernel, and this obstruction would partake in that. I do not think it is that drastic, I think he just fears that those abstraction would eventually become part of what he has to maintain, and no amount of reassurance or new maintainers would change his mind.

I also don’t think Martin’s brigading is anything productive, and I hope that doesn’t become the reason that rust code gets obstructed from being merged into the kernel, but it sure does focus the attention on these matters.

What they are asking is not to change the c code to suit rust, but to leave the C code as is, and have a single Rust-written wrapper that links into the C DMA code so that other Rust drivers can link into the wrapper. Additionally, said wrapper is not to be maintained by Hellwig, but by the maintainers of the drivers that will use the wrapper, so without overhead for Hellwig.

He is not asking to not make his work harder, he’s explicitly asking to make it harder to write rust drivers that use DMA.

Celluloid does much less than vlc, why not just using mpv (which celluloid uses as backend) so you have a full player

Lenovo might have intentionally reduced the performance in Windows by default to enhance battery life, because it is a gaming laptop they probably have a lot of performance options in the vendor’s control center to sacrifice battery life for performance, are you sure you activated every performance option?

Also mesa drivers often have better performance than Radeon official drivers, but they are less consistent (more stuttering).