I find that even if you get a touch primary device, make sure to get one with a keyboard, Ubuntu, Fedora, doesn’t matter, KDE, Gnome doesn’t matter, the touch only experience on linux is simply not great. Make extra sure to get the keyboard with it if its optional.
I fell for the lie of flatpak not being bloated, I just nuked flatpak from my PC since I just run arch anyways. Im not sure if repo is safe to remove. You might be able to run rmlint -g and see how much data can be deduplicated on an FS level, I never checked myself since I run f2fs, but if you run an FS with dedupe capabilities it may work for you.
For sure try out olive You can’t do automatic stabilization but manual works fine, However I will always use gyroflow whenever possible anyways. If needed you can easily script motion tracking data from 3rd party sources.
but it is properly color managed throughout the entire editor so doing color correction works properly and accurately. the node system is really powerful despite it’s early nature, and as far as I know olive is the only FOSS editor with proper OCIO integration, which means you get industry standard color management tooling including things like ACES support. You also have OTIO support for importing and exporting editorial cutting information.
before anyone gets too excited, this doesn’t seem like it applies to DG2 gaming cards, ATSM and PVC are compute cards
<span style="color:#323232;">+SR-IOV Capability
</span><span style="color:#323232;">+=================
</span><span style="color:#323232;">+
</span><span style="color:#323232;">+Due to SR-IOV complexity and required co-operation between hardware, firmware
</span><span style="color:#323232;">+and kernel drivers, not all Xe architecture platforms might have SR-IOV enabled
</span><span style="color:#323232;">+or fully functional.
</span><span style="color:#323232;">+
</span><span style="color:#323232;">+To control at the driver level which platform will provide support for SR-IOV,
</span><span style="color:#323232;">+as we can't just rely on the PCI configuration data exposed by the hardware,
</span><span style="color:#323232;">+we will introduce "has_sriov" flag to the struct xe_device_desc that describes
</span><span style="color:#323232;">+a device capabilities that driver checks during the probe.
</span><span style="color:#323232;">+
</span><span style="color:#323232;">+Initially this flag will be set to disabled even on platforms that we plan to
</span><span style="color:#323232;">+support. We will enable this flag only once we finish merging all required
</span><span style="color:#323232;">+changes to the driver and related validated firmwares are also made available.
</span><span style="color:#323232;">+
</span><span style="color:#323232;">+
</span><span style="color:#323232;">+SR-IOV Platforms
</span><span style="color:#323232;">+================
</span><span style="color:#323232;">+
</span><span style="color:#323232;">+Initially we plan to add SR-IOV functionality to the following SDV platforms
</span><span style="color:#323232;">+already supported by the Xe driver:
</span><span style="color:#323232;">+
</span><span style="color:#323232;">+ - TGL (up to 7 VFs)
</span><span style="color:#323232;">+ - ADL (up to 7 VFs)
</span><span style="color:#323232;">+ - MTL (up to 7 VFs)
</span><span style="color:#323232;">+ - ATSM (up to 31 VFs)
</span><span style="color:#323232;">+ - PVC (up to 63 VFs)
</span><span style="color:#323232;">+
</span><span style="color:#323232;">+Newer platforms will be supported later, but we hope that enabling will be
</span><span style="color:#323232;">+much faster, as majority of the driver changes are either platform agnostic
</span><span style="color:#323232;">+or are similar between earlier platforms (hence we start with SDVs).
</span>
I am, very hesitantly, optimistic for the new smithay based compositors. Cosmic doesn’t have touch support yet, but it’s super light weight, I get better perf then I do even with KDE. I plan on swapping to it full time on my tablet when it gets touch support. (and when some touch friendly gui stuff is available). you also have catacomb which is an actual mobile compositor. Very promising stuff, but still very far out
I myself am currently using a Chuwi Hi10X. I don’t have too many major complaints about it other than its quite underpowered. It does perform decently well until you need something graphics related then just kinda sucks. However I can use Firefox with it without any major gripes aisde from video playback, then I need to use chromium.
The desktop environment you use can actually play a massive part in its usability. I have found that GNOME is pretty much useless. KDE isn’t bad but it’s still heavy. I have been testing Cosmic DE and it has been pretty good. Definitely the best performing of the bunch so when that releases I’ll probably be using that full time.
Intel A350, can’t say I have many complaints now. a lot of the issues have been ironed out. I’m not sure if the sparse work has landed for i915 yet, but once it does I don’t think I will have too many super major issues left. Im getting some artifacts when using gamescope, but that’s not a major issue for me since I don’t really need gamescope
I think having separate standard APIs for screenshots, screen capture, and video capture that aren’t married to one implementation makes sense.
The idea of a using a separate thing for it is fine, in itself, but necessitating it is an issue to me. There are a LOT of wayland compositors now, for all sorts of systems, each one also new needs a compatible xdg portals implementation (or whatever third party tool you like), in the case of xdg portals this also means pulling in things like dbus. It actually becomes a lot to build a “Minimal but fledged out” ecosystem. something which should otherwise be possible.
we’re talking about standalone desktop apps, they need some common building blocks no matter if they’re containerized or not, right?
sure but then you have xdg-portals denying actually useful a11y protocols because they “don’t want to expose it to containers” -_- apparently they never heard of a permissions system? but this also highlights why the wayland ecosystem right now is so poor for select individuals (and why they get heated when told that they need to swap to wayland)
I have a couple of issues with portals. One is that we’re putting too much eggs in the basket of something that is designed for containers. XDG portals Have rejected features that people have requested because they don’t want to expose that functionality to a container and they are allergic to permission prompts apparently.
I also have other issues with the portals for instance video capture. It requires you to have a camera portal. It requires you to have a desktop capture portal. It also requires you to have an app to app, video, portal, which doesn’t exist yet. All of these things require pipewire pretty much in most cases, so why can’t we just have a single pipewire portal? It may not scale well in the future, but it doesn’t scale well now anyways. If you want just a generic pipe wire stream, you’re not gonna be able to have it, you’re going to have to conform to one of the standards anyways. For a case in point example, the OBS pull request for Game Scope Capture is the perfect example of this over reliance in XDG portals.
I’m showcasing this just to highlight the fact that the XDG portals are incredibly poorly thought out, and I don’t think that it’s a reliable method for the future going forwards.
PS. Please pardon any oddities in this, I had to use speech to text, since my RSI is acting up.
I did and quite frankly it’s trash, XDG portals are a clunky and quite frankly terrible and poorly thought out api. I’m not the only one that disagrees with this sentiment as multiple people are trying to get protocols like ext-screencopy-v1 for screen recording and ext-foreign-toplevel-* for window management upstreamed into wayland so that xdg portals aren’t necessary for these use cases. I don’t mind the reliance on pipewire too much, but I too think that It shouldn’t be necessary for screen capture.
IMO It is one of nate’s worst takes of all time if not the worst. Usually I agree with most things he writes, but not this, xdg-portals is a travesty, pipewire is nice and all, but I don’t see why we should need an entire media system for basic screen capture capabilities. and clearly im not alone on this sentiment
woops my bad, I mean to link this github.com/…/wayland-x11-compat-protocols it’s a repo of going to be protocols, to fill in the gap instead of pretending the issue doesn’t exist