Linux Patch Sparks Differing Views Over External Monitor Handling With iGPU vs. dGPU

[user1]

Hmmm, that will definitely depends on which distro you are using.
For debian/ubuntu/centos, my experience with them is that they are stable but old and most of the time updating don't break anything, though TBF, I haven't use desktop debian/ubuntu/centos for a long time.

After years of daily driving Linux and trying many different distros, I'm lately more and more inclined towards Stable / LTS grade distros. I just happen to run into less issues with these distros. For example, I recently installed Fedora Workstation 36 and after I set up everything, I wanted to install wine-stable because I need it for some software. But then, I found out that for some reason wine-hq decided to not ship wine-stable package for Fedora 36. So I installed the latest Wine from Fedora repo and hoped that it will be stable.. but it just crashes with anything I launch with it , even winecfg. Then, I tried some other recent wine version via Lutris, but it also had some weird errors.
At the end, I just lost my patience and installed Ubuntu Mate 22.04.1.

[piotrj3]

No, my comment still stands. You have fun stuff like KB4532693 that deletes user data out of nowhere. That's effectively a change in how user folders are handled, or more precisely a hidden clean-up of something that should have been migrated already. Not clearly communicated and certainly not well tested. That's what you risk getting from MS these days. I can't be bothered with finding an article on it now, but a while back changes in Windows Search also broke part of Outlook. So there certainly are issues on Windows when it comes to dependencies and broken interfaces. Depending on what you run and how long you wait with applying updates, you may or may not be seeing these issues in practice.

This update in windows 10:
- introduced issues to 0.5% of users who installed it,
- introduced only issues to people who manually pressed check for updates (in very short time frame it was availiable) and actually installed it.

So we talk about 0.01% of windows users.

This seems far more impactful.

Anyway, the issue i would say is very theoretical in commited patch, but it managed to break:

-arm64 with vmwgfx (tracked and hopefully fixed when patch was committed),
-amdgpu propertiary,
-nvidia propertiary.

Perhaps just giant/impactful patches shouldn't be mainlined straight all the way without some QA? It got mainlined in less then 1 month from initial commit. Yes i know internal API is not stable and open source developers can't know always what breaks with some propertiary modules, but reality is not shining and rainbows and there always will be propertiary modules that are restricted either by law or patents or copyright that cannot be opensourced. And here stuff have to be pragmatic unless you want to remain as niche OS for desktop users.

[AHSauge]

I know about all the WIndows shenanigans as well, but have you ever heard about a case when Windows software suddenly stopped working because Windows changed something in its component/dependency? I didn't. That's what I was talking about. Don't know about that search breaking outlook story, they're both Microsoft products, hence they might work tightly together, but I never heard about something that just breaks third party software.

I really don't understand what you're trying to say here. Trying to find an article on the issue I'm met with a forest of issues related to Windows search. These are spanning years, making it hard to find the exact issue I hit. In any case, given it's possible to integrate the search into third party software, I would be quite surprised if this isn't breaking non-Microsoft applications as well.

Sadly it's been quite a few years since I did any development targeting Windows itself, but I remember updates back when I used Windows 7 breaking things too. Going from Windows 7 to Windows 10 also had it's fun adventures as far as I remember.

[NobodyXu]

After years of daily driving Linux and trying many different distros, I'm lately more and more inclined towards Stable / LTS grade distros. I just happen to run into less issues with these distros. For example, I recently installed Fedora Workstation 36 and after I set up everything, I wanted to install wine-stable because I need it for some software. But then, I found out that for some reason wine-hq decided to not ship wine-stable package for Fedora 36. So I installed the latest Wine from Fedora repo and hoped that it will be stable.. but it just crashes with anything I launch with it , even winecfg. Then, I tried some other recent wine version via Lutris, but it also had some weird errors.
At the end, I just lost my patience and installed Ubuntu Mate 22.04.1.

Anything not in the official repo can be a pain to install and I recommend you to use proton provided by stream, it works quite well for me.

[NobodyXu]

Perhaps just giant/impactful patches shouldn't be mainlined straight all the way without some QA? It got mainlined in less then 1 month from initial commit. Yes i know internal API is not stable and open source developers can't know always what breaks with some propertiary modules, but reality is not shining and rainbows and there always will be propertiary modules that are restricted either by law or patents or copyright that cannot be opensourced. And here stuff have to be pragmatic unless you want to remain as niche OS for desktop users.

I doubt that will work, because proprietary means you cannot leak any information of that module, otherwise it will be an infringement of the IP.
So I don't think any dev can review these patches and says "hey this LGTM since it does not affect the APIs used by nvidia proprietary driver" or "no this change breaks the nvidia proprietary GPU driver" because now all people know roughty what API/ABI your proprietary driver is using and that might result in a law suit to that dev.

[Quackdoc]

Im certainly not a fan of the approach the patch takes myself.

[mdedetrich]

Jesus, just make a toggle switch

Yeah thats what I am thinking, regardless if the dedicated GPU is proprietary (i.e. NVidia) or not, either way this behaviour can make sense either way. Also there are other dedicated mobile GPU's that aren't just NVidia, i.e. AMD and soon we will also have mobile ARC gpu's as well.

[birdie]

Seriously, Linux kernel only guarantees the stability of the syscall, not its internal APIs.
This is not to alienate anyone, but this is how software dev works.
You set up a scope, define what is the public API/ABI and which part you want to keep stable.

The only way to fix this is to upstream the nvidia driver.

Have you read the issue? It's not about API, it's about a drastic change in behavior.

[user1]

Anything not in the official repo can be a pain to install and I recommend you to use proton provided by stream, it works quite well for me.

Except in my case, the pain was not installing, but finding out that winehq-stable is not even available in the repo after I already added it. The fact that it's not available wasn't even mentioned in the Fedora installation page in winehq website.

[DRanged]

Hmmm, that will definitely depends on which distro you are using.
For debian/ubuntu/centos, my experience with them is that they are stable but old and most of the time updating don't break anything, though TBF, I haven't use desktop debian/ubuntu/centos for a long time.

Before switching to macbook air, I was using gentoo and it was a lot of fun using that distro.
A lot of features that I can configure and I can also pick the cflags.
The experience with it is mostly ok, except for swaywm constantly breaking on nvidia software, even when using noveau.

Than it should be about time you try again. Have been using Debian testing (sort of semi rolling release) now for 10 years without to much hassle.
Last ones I ran into was that prusa-slicer was removed from testing solved it by downloading/installing the package from sid and it works as intended. Same with mplayer and mencoder also solved that by downloading/installing the packages from sid.
Nice sideline is that mplayer have ther own debian packages repo now since 2021-04-03, https://mplayerhq.hu/design7/news.html, and with the latest version. As a test I just copied mplayer from there own repo over the one from sid all still works as intended and mencoder also works without the bugs mentioned on debians bug tracker. By the way still using gnome-mplayer and that still works fine. For Wine I use wine-staging and if need be dxvk.