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.
this post was submitted on 22 Jan 2025
104 points (100.0% liked)
Linux
49183 readers
591 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
Not yet. Still too many broken and unusable things in Wayland. Sadly.
Xfce is still wholly in xorg territory.
Iirc there's work being done for Wayland support, but last I checked, it's not nearly far enough along.
- xfce is really not an important project IMHO, it's an interface from the 00's that doesn't have a clear usecase to me at all. It's a strictly worse version of KDE in my eyes. The only reason to use it seems to be if you're already used to it and don't want to have to change anything.
- they're actually almost completely done: https://wiki.xfce.org/releng/wayland_roadmap
so, i don't think it'd matter if it were true, and it's also false.
an interface from the ’00s*
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
I thought shaping the windows allowed for removing the borders.
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.