291–297 of 297 posts
Earlier quoted context omitted.
If it's open source you can make money by selling managed services to companies. They don't want to deal with it really.
How is Red Hat's revenue compared to Microsoft's?
Earlier quoted context omitted.
> latency should be identical Should be, but very clearly isn't.
The results show it's identical. Only XWayland suffered any significant degradation, and even then we're talking <5ms which is imperceptible.
Earlier quoted context omitted.
Sure Wayland works fine. What you're not seeing is the hours and hours of volunteer labor wasted to get it to that point. Time that could have been spent working on features users actually cared about, now wasted "adding wayland support" to your favorite applications. If you could quantify it, the waste would be borderline criminal: - Effort spent writing sway that could have been spent improving i3 - Effort spent wr…
How incredibly arrogant of you. Its their time to spend as they see fit. You get no say in that and complaining they didn't do what YOU wanted them to when YOU wanted them to do it is peak entitlement. Grow up
Robbert van der Helm has a very popular (in the Linux music editing world) program, yabridge, which enables DAW plugins written for Windows/Mac (aka most of them) to run in Linux DAWs. It leverages Wine and a cascade of transparent window layers that position mouse clicks, menu positions, and graphics updates. It's crude, it's clever, it works. Musicians who love Linux rejoice!
Enter Wayland.
Mouse clicks no longer land where they're supposed to. Reparenting a window doesn't work like it did on X11. Edits to the yabridge source code are a moving target because WINE devs (who are largely paid professionals, which occasionally keeps out a handful of useful merge requests; these maintainers DO need to balance the needs of ALL Wine users with every edit) keep editing winex11.drv (which has all the display and input functionality touched by yabridge), and robbert-vdh shares in some issues that he doesn't have much time to make changes, especially when they might break again later.
For over a year, yabridge is broken.
Advice is given to pin wine-staging 9.21. (Wine 11.0, released 7 months ago, is the current stable version.) Yabridge users share tips on how to install/build Wine 9.21 long after their package manager has deprecated it. You can still run yabridge on newer Wine, mostly; one workaround is to always drag your plugins to the upper-left corner (if the window allows it; I couldn't do this with REAPER in Fedora KDE without disabling snapping, which I want; for months, I used the non-GUI plugin panel in REAPER). A few plugins just stopped working. Sometimes users will log what happens and upload this and it even eventually gets explained---for that specific case---but often not solved right away.
One maintainer of Wine made edits both in Wine and yabridge specifically to get yabridge working again. I don't know if he did it for a CodeWeavers user or just out of the kindness of his CodeWeavers-paid heart. This pull request covered 90% of users, but a few still complained it didn't work in X DAW with Y plugin on Z distro. Because it doesn't always work, it becomes a branch; technical users will be able to manually get their DAW/plugins (often paid, sometimes a subscription, so there's an incentive to use them) to hopefully work and hopefully for the long term.
A few DAWs even change their plugin code to support, say, keyboard passthrough, which should theoretically be handled by Wine or/and yabridge but still has issues. These DAWs could be getting new features or addressing USB interface latency/throughput/routing, but instead they're dealing with fractional scaling, plugin support, themes, and a bunch of other graphical details that worked previously.
It absolutely wastes developer time because now the rules of "who handles what" (in every major distro and DE) have changed for anyone with a GUI and because developers are often users who have no choice in the changes and don't have the background to just know---or the free time to learn---how Windows and Wine and VST and Linux graphics work, and even if they did, the MR/PR they write and submit might not get merged at all in the chain of programs needed to get FabFilter to run in Bitwig on Ubuntu 26.04, because it doesn't also let Auto-Tune run in Ardour on Fedora. (This is contrived, but you can read through the 100+ open yabridge issues yourself to find the actual problems being experienced.)
By the way, the "ya" in yabridge is an abbreviation, "yet another," because it worked where other VST bridges did not. It wasn't the first compatibility layer for VST and won't be the last. Either robbert-vdh will change his codebase to work with the new methods Wine uses to handle Wayland windows, or there will be a new bridge. If you're wondering why there are 20+ actively maintained and reasonably well-known terminal emulators (How many could I rattle off without looking it up? Alacritty, Ptyxis, Foot, Wexterm, Terminator, xterm, Konsole, Guake, Kitty, ghostty, xfce4-terminal, and does Putty count?) it's because of situations like this, where the new paradigm forces old devs to keep up and implement popular feature requests or get replaced.
All of this doesn't even consider whether a DAW is Flatpak or not. (Hint: the failure modes are different.)
-----
Users can't always get old hardware to support the old software that worked. Users can't always get every version of old software they knew to work six/eight/ten years ago. Users on old software have to figure out vulnerability patches and how to handle subscription and dongle-based plugins.
(Windows 11 is a bad experience, I don't even count this as a fallback.)
If the decision makers of Linux are going to make changes that break workflows, they absolutely should get [productive, kind] pushback. We shouldn't have to downgrade our OS UX and free cash reserves to a Mac Studio just to be able to do the things we already could do in 2018.
-----
I suspect video has the same problems. DaVinci Resolve exclusively supports Rocky Linux 8.6 on kernel 4.18. Why would BMD have qualms about targetting a more recent version... unless there's some friction building this support?
Earlier quoted context omitted.
It is absolutely not the DE/WM devs driving this, it's the wayland folks saying that xorg would no longer be maintained. They literally just dumped an Ikea box of protocols on the table without even bothering to provide a decent sample implementation and said 'good luck!'
1. There is/was a sample implementation. 2. There are currently many high-quality implementations, Kwin being the best IMO. 3. X11 devs didn't want to maintain it, nobody "made them" stop. You or I could maintain it, but I also don't want to, so, here we are. 4. Yeah the wayland transition was rough but I think there's basically no universe where that transition would be perfect. They're architecturally different thi…
2. Yeah, the major projects like gnome and kde had enough developers to dedicate to porting over to wayland. Most existing DEs and WMs found the porting process to be very difficult and didn't even bother. This would have been solved had they released an implementation with feature parity. See #1.
3/4. I don't care. I consider xorg to be 'feature complete'. There are few benefits to the end user switching to wayland beyond some niche use cases like multi-display scaling, and HDR. The small benefit of those is nowhere near worth the headache they forced on users when the major DEs started going wayland only.
Overall, I am happy sticking with xfce since it's taking the slow road on moving from xorg to wayland.
Earlier quoted context omitted.
Wrong framing. I would need a reason to go above 60Hz, since it doesn't look any better to me and just wastes energy.
Are you sure you've ever gone above 60hz and 60fps? It is unequivocally agreed to look much better
Earlier quoted context omitted.
I use gamescope on a separate TTY that directly launches either steam or heroic launcher. I find this works exceptionally well. No window manager needed as you are playing a game full screen anyway. It fixed some other things like HDR too but at a loss of the volume and brightness keys no longer working.
That sounds very interesting, do you have any links or references on how you set it up?
Gamescope replaces X or Wayland so you just run it and then the app you want it to open
This hits a very soft spot for me. My beloved Spelunky 2 has huge input lag "on Linux", which makes it unplayable for me. It's pretty much the reason I keep my Windows 10 install around. I could not come up with a configuration on Linux that avoids the lag. It's extra infuriating that online sources report the game running flawlessly but seem to ignore input lag.
DXVK_CONFIG="dxgi.syncInterval = 0; dxgi.maxFrameLatency = 1; dxgi.maxFrameRate = 60" gamescope -f --immediate-flips -- %command%
I also manually disabled vsync in the game's `local.cfg` XML file.
I love where "gaming on Linux" is going. But I have the feeling the hype on Youtube etc. is in part created by content creators, and doesn't faithfully represent the actual situation (surprise!).