- cross-posted to:
- technology@lemmy.world
- cross-posted to:
- technology@lemmy.world
You must log in or register to comment.
Should be wayland by default, finally.
The wayland transition is almost over. JFC it took forever.
All that’s left is steam itself, wine/proton, and i’d say we’re basically done.
wine is pretty much there with its latest release. it’ll take a couple of years for LTS distros to phase it out
I’m still waiting for this: https://gitlab.winehq.org/wine/wine/-/merge_requests/6025
I believe that’ll make it so that windows actually use my SSD’s instead of CSD’s, i’m on hyprland and the double bordering is super annoying.
This PR does not look like it has anything to do whith SSD
sdl2-compat is gonna be doing a LOT of heavy lifting
Fantastic. It’s my understanding that SDL is responsible for why we can connect generic controllers to Linux without having to download specific drivers.
In my experience… not really. I would say SDL makes the task of writing controller support code within your own applications easier and higher-level, but in reality it still has not much to do with “drivers” (I assume you mean kernel modules), which the kernel and OS stack already provide multiple unified interfaces for with things like jsdev/evdev/udev/hidapi, regardless of how you access those subsystems (via SDL or otherwise).
Kind of. It’s the Linux kernel that manages all of the controller drivers and makes them available to userspace, mostly via the evdev interface. SDL is a library for managing graphics, sounds and events in a generic way on multiple platforms and devices. It’s overwhelmingly the most common library used for Linux games - Steam used it for all of their Linux-native ports of Source engine games, for instance. But it also presents all gamepad events in a consistent way regardless of their “true source”, so generic devices tend to work with every game.
SDL3 mostly clears out all the clutter from the previous versions of SDL. It’s a mature library and gamedev has come a long way in that time. Getting rid of all the weird stuff that the API accumulated makes it easier to use and maintain. Plus there were things like managing audio generally, and pen-and-touch gestures mobile phones and tablets, that were quite the head-scratchers before. That’s all a bit easier now.
SDL is kind of the equivalent to DirectX. It provides a standard interface for multimedia applications regardless of underlying mechanisms. Except the 3D acceleration part I think which is handled by OpenGL / Vulkan.
SDL3 has a new “GPU” API, which is some kind abstraction over Vulkan/DirectX12/Metal. I imagine it hides a bunch of boilerplate as well. With this, I think, one could do a 3D render engine without having to directly use the Vulkan API (or OpenGL, …). However, the shaders need to be in whatever format the backend expects it seems.
Ah cool, that’s interesting.
this is the Ronald’s universal number kounter of graphics libraries
Coolio, but I won’t be using it at least until it hits Debian Testing. Hopefully this can be in Trixie - looks like the freeze hasn’t happened yet.
I just checked and SDL3 and SDL3_image are in unstable, and it looks like even the release candidates were in unstable for a while.
It’s almost impossible it won’t end up in trixie. They just closed the bug too that prevents it from migrating to testing:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086720
So this could be in testing in a like a week or so.
