- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
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.
They day I leave X11!.. Is the day I buy a decent graphics card Seriously my GT 710 is suffering
Nvidia should be good now actually!
Not yet. Still too many broken and unusable things in Wayland. Sadly.
I see freerdp. Does it have multi monitor support for wayland yet?
Such as
Multi Monitor support on a remote session for one. In fact as of right now the situation is even worse and causes the application to crash altogether instead of dropping back to a single screen. Yes, I probably could force a x11 backend and it might work. But I shouldnt have to.
I am assuming this is the same security issue that has been there for a while. So many applications that could interact with other screens become broken. Maybe some of that is fixed, I suppose I should try again. But until I can multi-monitor with a remote session, I don’t bother trying.
I am all for Wayland though, don’t get me wrong.
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.
could absolutely be wrong
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.
