eugenia

If it's AV1, you need both the hardware that can decode it, and the right libraries for it. x264 is not the same as AV1. AV1 requires lots of processing power, that's why you see the slow down. But with the right gfx card (and libs), it can decode it fine. What's your gfx card model exactly?

Exactly. The article says that 90% of hardware doesn't run on it, but in reality, 100% of hardware doesn't run on it. Only Qemu supports it, which is an emulator (and very slow to emulate RiscV in my experience -- latest version we tried with my husband on a very fast PC).

The Orange Pi RV2 was the perfect introductory Risc-V SBC, everyone is going gaga for it, for being a good middle of the road solution for those who want to try Risc-V, and yet, Ubuntu won't support it (and even the current implementation is done by the Chinese, not by Canonical, so I wouldn't touch it).

So I'm not sure what they're thinking. My own conspiracy theory is that EITHER Canonical, OR Raspberry Pi (which are close geographically), are preparing RV23 hardware, so they want to undercut the competition that way.

Nothing else makes sense in that decision.

My issue would be the old version of Qt it runs on, which is not maintained anymore. That itself is a bit of a problem security-wise.

You think it's the screen/hdmi at fault, but it might not be. I've had the problem with two laptops in the past (the bug was with all distros I tried), and in one case it was a BIOS that Linux didn't like, and the second one was the internal wifi that its linux driver was buggy. For the first laptop there was nothing to be done, so I disabled sleep completely in the bios, while for the second one, I disabled the wifi modules in the kernel's blacklist, and then used a usb wifi that I knew it worked better. Both cases were appearing as a dead screen, but it wasn't the screen/hdmi/gfx card to blame. In yet another case, with a thinkpad laptop, the wake up was working, but it would wake up 30 seconds later than anticipated. In that case, it was the fact that its thunderbolt was dead (hardware had gone bad), and only when I disabled it in the bios completely the laptop would wake up correctly and fast.

In all those cases, I had to look at the kernel logs to see what was the issue. There were traces of the problem of which hardware exactly was creating the problem. It might look like a screen/hdmi problem, but most of the times, it's not.

Use Talon with Cinnamon and Linux Mint, which still uses X11.

Waking up from sleep is of course part graphics card/drivers, and BIOS code. My husband had his share with his nvidia card crashing the system when coming up from sleep under Wayland, but I believe these things have been mostly ironed now. However, if you have a buggy BIOS, you're out of luck. I've had such a DELL laptop, latest firmware installed, and no matter which distro I tried, it wouldn't wake up from sleep properly. So, if that's your issue, there's not much you can do, apart from getting compatible hardware. There are hardware lists of compatible hardware in some places, including archlinux's wiki i believe.

iOS is only massive in the US, everywhere else, Android has a huge market share.

Honestly, if these laptops also have Intel gpus, just use these to do your 2D work. And if you feel adventurous, then install the 390 drivers as secondary, only for the apps that need computing (e.g. Blender). For anything else, just use Intel, they work great for both video and 2D desktop acceleration.

That's a rather expensive laptop you got there... I personally bought a used Thinkpad x280 for $160, and I run Linux on there. Another option is to get an small computer (sbc) with at least 8 gb of ram, if you already have a monitor.

It's not working properly. No AAC support either. I also used to use the Dehancer plugin for it which unfortunately has bugs under Linux.

Resolve doesn't do what Ableton does. It's more of an audio processor and editor (like Audacity), but not a real DAW for music.