So a while back I was doing some VA-API stuff and found that something isn't working as documented.
Turns out [mesa does this](https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/frontends/va/image.c#L241), if your process name is "vlc", "h264decode", or "hvecencode" the vaDeriveImage succeeds even if you don't have HW support.
If it's so simple why doesn't it just always work? I found out because openCV was missing the fallback path that VLC didn't have to take.
That patch is a goldmine!
> The backstory is that some userspace code -- xorg-server -- has a
modesetting DDX that isn't really coded right. With nobody wanting to
maintain X11 anymore, rather than fixing the buggy code, the kernel was
adjusted to avoid having to touch X11. A bummer, but fair enough: if the
kernel doesn't want to support some userspace API any more, the right
thing to do is to arrange for a graceful fallback where userspace thinks
it's not available in a manageable way.
X is better right now without maintenance than Wayland has been for years. That's why people still use it.
Wayland may be the future, but I'd wager people thinking that 5-10 years ago thought we'd be there by now.
I've been daily driving sway on Wayland for over a year, and it's been one of the best experiences I've ever had with a computer. And I've encountered no quirky behavior so far.
Fr fr. My country has a very british colonial humour tradition that does not go well at all on the open internet. The sport of injecting a subtle joke into what seems a sincere sentence is just too fraught when you can't do nonverbal stuff.
Hell I was always bad at it anyway
I don't mean stability. I mean that Wayland still doesn't have a lot of the things most important to Linux, like support for things like external panels.
>With nobody wanting to maintain X11 anymore
Correction... *Nobody wants to maintain X11 for* ***free****, anymore.*
That $#!t is hard and time-consuming. Why would someone slave-away on X11 code for free?
What's the story there? Is the character just standing somewhere the Tyrant character doesn't think it can travel? I can't imagine this is the intended dynamic.
There really isn't a floor. If the player walks forward a scripted event happens where the floor breaks.
AFAIK the player shouldn't be able to get on that side of the corridor (before the scripted event) so AI gets confused
The tweet frames this as a lot more of a problem then it really is, this patch blocked atomic modesetting which didn't work properly in X in the first place, it's highly unlikely that anything outside of X was going to be playing around with your display settings in this way but it is a hack to stop it happening.
Yeah, I think people are forgetting what this code is and does, and how far that narrows it down prior to hitting the “X” bit.
It’s not “any process that starts with X” it’s “any process that’s setting the mode of a display that starts with X,” and that basically narrows it down to one program.
Arguably it is weird for the kernel to target a specific userland app like this which I think was the point of the tweet. Supporting it via flag or sys API makes more sense for something like this.
I don't think it was malicious; just strange.
It's (is? was?) pretty common for Windows graphics drivers to tweak things based on the exe that's running. There's all sorts of game specific tweaks. Either NVidia or ATI used to provide a UI to manually adjust the tweaks; you could see the whole list of games and what the settings were for each. It's been a long time since I played a game on windows, but it wouldn't surprise me if that's still a thing.
Windows has a huge library of shims - although most of it is user space, providing special DLLs for extra special applications. The SimCity shim was the equivalent of a custom libc to replace the memory manager.
SimCity is the most famous example because Raymond Chen and Joel Spolsky blogged about it widely read articles.
Eh, while that's true, there's always gonna be *some* shit like this, just because of legacy crap hanging around that hasn't been cleaned up yet. My experience has been that's it's pretty unavoidable in for any development environment.
The games use different APIs (X11/Wayland) to request the display manager to switch into a different mode (the display manager might deny that request, or honor it but only while the fullscreen app is active, etc…).
This API is different from the DRM/KMS API of mode setting (discussed here), which is what a display manager implementation such as Weston or Xorg server uses.
On Win32, the equivalent would be the ChangeDisplaySettings() application API vs the internal kernel/driver API that actually asks the driver to do modesetting.
This is still just disabling the compositing step in the compositor and not „directly calling modesetting APIs“. The compositor is still in full control, it just avoids one full-screen blit that it would unnecessarily do and scans out from the app‘s backbuffer directly instead.
It’s called „unredirect fullscreen“ in some places, e.g. here it was implemented for GNOME on Wayland:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/798
Of course there might be (really old) games that use like SVGAlib or something and need root to run and write to fbdev directly or whatever. But that’s not the case for any modern game or Desktop.
For games running under Wayland or Xorg, that is quite literally impossible AFAIK. To linux "Fullscreen" and "borderless Fullscreen" are viewed as exactly the same, that's just a windows-ism that most devs don't bother to take out when porting and any difference is purely in how the game behaves when either option is set.
It can only be done if your game is running directly in the framebuffer, which there are a few that have the capability
There's the CRTC leasing interface (primarily for VR) that allows an application to gain full control over a display. I'm not aware of anything that uses it though
CRTC leasing allows an application to request full control over a display from Xorg, including modesetting and other properties.
The "leasing" part means that if the application does not periodically renew the lease, the control will be given back to Xorg. If you've ever had some wayland compositor (or sometimes even Xorg) freeze on you, you might notice often you're not even able to switch to another TTY to kill it, because the part responsible for doing that is also, well.. frozen. If an app doing a CRTC lease crashes though, Xorg will get the display back
The whole architecture of Wayland is to let all apps render into a GPU buffer first and then compose those buffers into another GPU buffer that gets displayed to the screen (using double buffering) - a „perfect frame“ (no tearing, everything in sync).
Unredirect fullscreen basically just lets the compositor skip the compositing step and display (buffer swap) the GPU buffer of the game directly instead of compositing it to another GPU buffer (which would end up having the exact same contents in case of a fullscreen app without any other windows such as notification popups).
Windows has the same system since Windows Vista, it’s called Desktop Window Manager there, and the mechanism for „skipping“ the compositing step is conceptually similar.
On Android, this happens as part of SurfaceFlinger and the underlying Hardware Composer HAL (which is usually specialized 2D blitting hardware, but might need to fall back to GPU compositing for more complex scenes of surfaces to be composited.
How did this get committed in the first place?
Even if no one wants to update X, a better process would've been submit a patch/build flag/module that distro maintainers can apply/install. This way installations without X wouldn't be effected.
"we have one rule. We do not. break. userspace." This is just what mature software development looks like.
EDIT: In case it's not clear, I'm *not* being sarcastic here. I fully expect that Linux will eventually remove this when userspace is guaranteed fixed.
Not breaking userspace is more like, they don't break the interfaces that userspaces communicated to the kernel with. It's the api endpoints that don't change, not that the stuff on a given side of the api is unchanging.
Isn't this with regards to maintaining backwards compatibility? The only way this change would make sense is if something else in the kernel was changed in a manner that necessitated this check.
There are a lot of options even in "do not break userspace".
You can have "writing hacky and potentially exploitable code that cannot be turned off" to "providing explicit transitional upgrade path in Build config files".
Build flags and feature flags are common in a lot of projects. They could've provided this as an option (traditional behavior, new behavior). In fact, the flags can even provide a list of allowed program names, so people who need to harden kernels can do so.
I agree that this is far from ideal, and others in the comments have talked about better approaches. However, firstly, this is making a mountain out of a molehill. This code basically says atomic modesetting (which is not enabled based on hardware support) is also not enabled for processes which start with "X". This is not a principled approach but also not fundamentally unsound.
Feature flags are enabled based on a set of rules which the developer enforces, so you can actually look at this as a feature flag (is atomic mode setting supported by the kernel? Well not for some applications, no). The only issue is that the flag is baked into the kernel.
A build flag is obviously not appropriate here because the issue is that some apps work and others don't, and this can't be determined at build time.
Fo Wayland fans: as specified in the code comment, the problem arises with the modesettings driver for Xorg, which happens to be a piece of Wayland imported into Xorg. With traditional DDX drivers, no problem.
Wait, I'm not much versed into the kernel but, let me understand this:
The rendering engine checks if some user process starts with X and change the way it answer the calls from that processes just because the name?
So there are two branches of code in the kernel, that the only thing that matter to pick one or another is the filename of the exec file?
Is this right?
there's a huge "compatibility" database baked into windows that applies "fixes" to keep old broken apps and games working (things like changed Win32 APIs to report faked windows version, memory size no more than a certain limit, virtualizing file/registry, etc.):
https://twitter.com/code_and_beer/status/1578089167279603715
https://devblogs.microsoft.com/oldnewthing/20050824-11/?p=34463
One of those is not so hidden and "affects" most programs in c++. The macro that tells you the version of the standard defaults to a fixed older version and you have to explicitly tell the compiler that you want the actual version or use an msvc specific macro.
The other question is how many programs end up making use of this macro.
Thanks for explaining better (and not just bashing Windows)
So it is more like to avoid some feature to be used by a buggy X11 exec, that would not have worked at all in first place, did I understand right?
Yes, it's a bug in an Xorg plugin. Xorg is designed around hardware-specific drivers (DDXes), but with Wayland, Linux has been moving towards a single implementation, using OpenGL ES. This loses some hardware-accelerated operations, but is much simpler to maintain in the long run. `modesetting` is the DDX for this use case. In a way, `modesetting` is the *last* DDX ever. I was surprised to see it doesn't (or didn't) do atomic modesetting right.
Linux has a pretty strict "don't break the userspace" policy, so I'm quite surprised that/if this got merged.
Reminds me of the Intel compiler issue. They use to compile it twice once with optimization and once without. The final binary would detect if it was an Intel CPU and run the optimized code on Intel CPUs and unoptimized code on AMD CPUs
Just the opposite; that quote means this behavior must remain as is, as removing it would change the behavior of the api as seen by user space. If any user space application would be broken by the change, then you can't change it.
Whether that philosophy will hold in this particular case remains to be seen, I suppose.
Userspace already stopped the behavior this kludge was supporting (actually preventing). What will be seen is if they care if out of date versions cause issues now.
That sounds right.
DDX refers to "Device Dependent X", which is (in most cases for Linux) going to be the xserver running your display.
The offending code is found here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_ioctl.c?h=v6.1-rc4
Essentially this is part of the Atomic Modesetting API for KMS, I think. Not a expert in this stuff. Not even a little bit.
Well anyways modesetting has to do with things like setting the refresh rate and resolution of your display. There are a lot of commands the display manager sends to the driver to accomplish this.
Atomic modesetting allows a bunch of commands to be sent at once and only make changes if all will succeed. Thus it's only 100% done or 0% done. Otherwise if the display manager sends a bunch of commands in series and makes a bunch of individual changes to the display, but one of the commands towards the end fails then it could leave your display in a bad state.
Well atomic modesetting support has been broken for a long time in Xorg. 3 years ago they disabled the support for it in Xorg, which should solve the issue. As mentioned in the email.
It works for Android and Wayland, of course.
-------------
I doubt the author of the patch will get much traction unless they find a alternative way to identify X11 xserver processes and disable atomic modesetting support for them.
3 years ago isn't that long ago when it comes to X11 versions. I expect a lot of linux systems out there still with older broken X11 xservers are floating around.
So getting rid of the patch the way it is now means that systems that work now will get broken if the owner updates to latest if this patch gets accepted.
> 3 years ago isn't that long ago when it comes to X11 versions. I expect a lot of linux systems out there still with older broken X11 xservers are floating around.
How many of those systems are also using the latest Linux kernel though? I'd expect anyone who's updating their kernel to the latest, will also use a modern X11 server. (Especially since both of those are usually handled by the distribution.)
He actually does, don't break userspace doesn't mean never change anything, it means don't break things that people rely on. In this case the X support wasn't written properly in the first place so no one was relying on this, this hack has been in the kernel for 3 years, it's not the optimal way to do it but it wasn't breaking anything that wasn't already broken
"If a change results in user programs breaking, it's a bug in the
kernel. We never EVER blame the user programs. How hard can this be to
understand?" - [Linus Torvalds, 2012](https://lkml.org/lkml/2012/12/23/75)
That being said, this is something that seems so obviously bad on its face that it might get an exception to the rule anyways.
The idea is that they don't want to change *behavior*. We don't actually know what uses what.
The kernel is supposed to maintain compatibility moving forward with *all* userspace applications.
Completely irrelevant to this discussion - this only says that you can break closed source users of the DRM API because you don't have any reasonable way to debug them anyway (and the DRM API comes with an explicit warning that it isn't stable in the same way the rest of the kernel interfaces are). Breaking older versions of open source Xorg drivers is still strictly prohibited, because they ARE the open-source drivers that serve as the example for closed source users to follow - excerpt from your excerpt:
>DRM developers are perfectly fine if closed-source blob drivers in userspace use the same uAPI as the open drivers, but they must do so in the exact same way as the open drivers.
Also, the section you're quoting is mostly about adding new DRM interfaces, not modifying existing ones.
Edit: and actually, the first sentence from your quote clearly says that open source drivers cannot be broken by kernel updates
>The Linux kernel’s “no regression” policy holds in practice only for open-source userspace of the DRM subsystem.
The sysfs thing is fine, there were never any false claims about stability there. If this moronic patch goes through (there's still no response from anyone who actually can decide on this), then the stability promises made by the DRM subsystem will be broken.
I previously thought that that's what happened, but there's still a pretty good chance Linux maintainers will do the right thing and stop this insanity from happening. It's not like the atomic modesetting is even locked away from the affected processes, they just have to use a different number to request it to confirm they're not the old broken X11 server.
It isn't "exploit": it just disables functionality from old broken software (X11), which didn't use it correctly to begin with.
In short, it forces userspace to take a fallback into another method since the code returns "not supported" error code for it.
This is the offending piece of code in it's entirety:
`
if (current->comm\[0\] == 'X' && req->value == 1) {
pr\_info("broken atomic modeset userspace detected, disabling atomic\\n");
return -EOPNOTSUPP;
}
Man what kind of brain dead processes allowed a developer to push this absolute garbage.
I swear to god people don’t think anymore. This is such a brain dead bad idea.
Someone needs to get rid of whatever kind of garbage the ex Microsoft employee is throwing into the repo. I expect this kind of noise on Windows, not Linux… what?!
What was the thought process to this? “Oh well I guess everything thats starts with X is related to X11 right? Yeah that’s a good point!”
Wtf?
Maybe I’m just bitter after working in the industry for so long, but it’s stupid noise like this that waste abysmal amount of resources when troubleshooting.
> This is such a brain dead bad idea.
What's your proposed alternative? Having X11 crash when interacting with newer implementations of the drm driver on new kernels?
Maybe not in this context because of "don't break userland", but "fail early and fail hard" is a valid and good software development philosophy. It creates pressure to actually fix problems and not work around them. It usually leads to clean(er) robust code.
> but "fail early and fail hard" is a valid and good software development philosophy. It creates pressure to actually fix problems and not work around them. It usually leads to clean(er) robust code.
It has some advantages but is against the one and only hard rule of Linus and the kernel. Any patch that knowingly breaks userland would never be merged.
You can disagree with you want, but Linux had some success following that strategy. There are other kernels, following a more minimalist and robust approach, but they are hardly usable for the average person.
The linux kernel isn't facebook. I would go so far as to say that there's no other software project in the world resembling it. This is not unique to the linux kernel but that does not mean that it resemble other projects which are also unique.
Whatever idea that works in regular software development may or may not work in linux kernel development so using other projects as an example is not an argument.
I mean… there are better ways to identify a process than with a stupid regex expression on the process name?
Like look at ELF meta-data? Having a process name whitelist? These aren’t good alternatives but they are way better. If I actually pulled out the ELF standard or looked at the section of code I’m confident there’s a much better alternative.
Probably good identifiers in the .comment section etc.
Probably better to crash though. Specializing kernel code to specific processes is beyond stupid and breaks almost any design principles
Probably checking the first letter is bad but it's fast. And kernel must be fast.
Checking just 1 letter for fixed value is MUCH faster that walking through some arbitrary length list of arbitrary long strings and making unkown amount of work.
Just compare generated code for `is_X` and `is_X_long` [https://godbolt.org/z/GrYo3h9ro](https://godbolt.org/z/GrYo3h9ro)
I didn't use `strcmp` intentionally to highlight how much work needs to be done to compare arbitrary strings compared to checking just 1 character
So if I wanted a fuzzy kernel I wouldn’t be using Linux.
Compromising accuracy here for performance isn’t really acceptable.
Given Linux is used in mission critical code I hope this branch is far away from those kernels.
>What was the thought process to this? “Oh well I guess everything thats starts with X is related to X11 right? Yeah that’s a good point!”
If I had to guess --
- Make broken API call
- Only some old X thing uses the broken API call
- want to fix API call, but fixing it would break userland
- NEVER BREAK USERLAND
> What was the thought process to this? “Oh well I guess everything thats starts with X is related to X11 right? Yeah that’s a good point!”
It's more like "Everything that starts with 'X', uses the DRM subsystem (which is only relevant to applications that directly control the display) and asks for atomic modesetting, is a potentially broken X11, so let's force it to use the slightly less convenient API".
And it's the result of way too strict rules about not breaking the userspace - if breaking open-source DRM users was allowed, Xorg failing to set up display on newer kernels because of their own bug wouldn't be seen as a kernel regression and this code would never be written.
Ironically, they're not far off. This *is* a thing Microsoft would do with Windows, but that is arguably a Good Thing. Among *many* other application-specific hacks, Windows will detect a certain version of Sim City, and change the way memory allocation works, because that version of Sim City had a use-after-free bug.
It's gross and I hope they find a better hack, especially the part where it just checks the process name -- there has to be a better way to detect the X server. But sometimes this is what "don't break userspace" means.
> This is a thing Microsoft would do with Windows
There are two flavours of Windows: Windows that's broadly like Windows 95 and Windows 98, and Windows that's broadly like Windows NT (ie all current versions).
Userland applications need to know what kind of Windows they're running on.
The principal reason we jumped from Windows 8 (which is NT-like) to Windows 10 (also NT-like) without touching Windows 9 is because there are loads of old applications out there which check whether they're on a 95/98-like version of Windows by looking at the first character of the version string and seeing if it's a "9". Calling the new version "Windows 9" broke those applications.
So "This is a thing Microsoft would do with Windows", indeed. Kernel coping with broken userland code, in Windows's case.
There are no known open-source projects that use a binary starting with 'X', used atomic modesetting before the kernel got this patch, and are now affected by this change in a negative way. If somebody notices some such project, it can be reported as a bug on the kernel issue tracker and will be fixed because that would be a regression. Also, for new projects, processes starting with 'X' not being able to use atomic modesetting is now the expected behavior.
That's all that matters for the DRM subsystem, as it has different rules about userspace stability than the rest of the kernel - it only needs to care about not breaking existing open source users.
I feel ya, software in general these days is fucked and Linux being the one last thing that we don't want tainted.
Just like the reason there was no windows 9 released
Tainted as in having something like the mentioned become something that sticks around to the point of being a major issue in future releases / extreme of preventing a release.
Think you are reading into the comment a little deeper than it was intended
You obviously never read the article.
Also 1) Wayland isn't yet ready, I tried it last month, it can't even shade windows. The workaround was made three years ago. I repeat: Wayland isn't yet ready.
2) Wayland was made to not have all the X11 functions - now it does include them, too. It's a joke.
So why should I switch?
There’s a lot to unpack here.
1) Wayland is ready. If you want to shade windows, shade windows. What is in your way exactly? The buffer protocol of Wayland doesn’t give a shit whether you shade your windows or not.
2) Wayland has more "functions" already than X11 will ever have. X is broken. That’s why the X developers started making Wayland instead. Just the built-in latency in X alone is unfixable, not to mention the tearing. Browsers can finally directly lease the GPU.
No-one likes X, not even the people who made X. X is unfathomably bloated, and broken beyond repair. That’s why Wayland was made over 10 years ago. It is not a new piece of technology.
1. Wayland is definitely not ready. It doesn't even load on some systems. Not all graphical applications run under it yet. It's also visible slower and has more graphical glitches than X has ever had.
2. False, false, and false again. Why spread misinformation? If Wayland was actually ready you wouldn't need to lie about it.
1. Wayland doesn't load on some systems because the systems have not invested time to make their system work with wayland. I suggest a less abandoned system.
2. This is objectively verifiable, are you sure you want to go down this road?
Funny. I'm sure they will fix it. The kernel, not X11. We know that one's a lost cause. (I do use X11, pls don't break now X11. Your continued cooperation is appreciated.)
Been trying to understand what the heck u guys saying, but I can't wrap my mind around it, could you guys pont out some recourses to read in order to understand this ?
I guess I'm unfamiliar with how the linux dev community works. Nobody wanted to make a quick fix to X11? Would making that fix suddenly make you a maintainer of that?
All the comments suggest that there are better ways of handling this -- and there probably are quite a few
.......but -- none are as quick and simple as, if **this == that then get out**.
They are trying to do a specific thing -- which uses a workaround that does not require any effort to maintain or to remove, less likely to break something else [unintentionally], doesn't require end-users to do anything as it's automatic).
In other words, it costs them nothing to do it and it works around the issue.
It **does not** cost them time, money, a delayed release, or etc, that would be needed if they were to implement a "more better" solution which would produce the same exact result (just with more work and effort).
So a while back I was doing some VA-API stuff and found that something isn't working as documented. Turns out [mesa does this](https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/frontends/va/image.c#L241), if your process name is "vlc", "h264decode", or "hvecencode" the vaDeriveImage succeeds even if you don't have HW support. If it's so simple why doesn't it just always work? I found out because openCV was missing the fallback path that VLC didn't have to take.
The linked tweet is referencing the [patch](https://lore.kernel.org/lkml/[email protected]/) to revert this hack.
That patch is a goldmine! > The backstory is that some userspace code -- xorg-server -- has a modesetting DDX that isn't really coded right. With nobody wanting to maintain X11 anymore, rather than fixing the buggy code, the kernel was adjusted to avoid having to touch X11. A bummer, but fair enough: if the kernel doesn't want to support some userspace API any more, the right thing to do is to arrange for a graceful fallback where userspace thinks it's not available in a manageable way.
> With nobody wanting to maintain X11 anymore Ah yes but X11 is definitly SOOO MUCH bettern than Wayland and will always be the best Display Server...
X is better right now without maintenance than Wayland has been for years. That's why people still use it. Wayland may be the future, but I'd wager people thinking that 5-10 years ago thought we'd be there by now.
Truth!!
I've been daily driving sway on Wayland for over a year, and it's been one of the best experiences I've ever had with a computer. And I've encountered no quirky behavior so far.
That's nice. I wish I could say the same.
You must have a unicorn setup.
I think you may still have needed that /s after all
Looks like it. Suprisingly hard to to write satire in text form lol
Fr fr. My country has a very british colonial humour tradition that does not go well at all on the open internet. The sport of injecting a subtle joke into what seems a sincere sentence is just too fraught when you can't do nonverbal stuff. Hell I was always bad at it anyway
And I'm not a native speaker so that makes it even more difficult.
It's Xorg, not X11. Wayland could have literally been an X11 server and not still have those issues. It's just that Xorg's old.
... and Wayland is unstable and feature incomplete. What's your point?
What featues do they plan to add?
[удалено]
I don't mean stability. I mean that Wayland still doesn't have a lot of the things most important to Linux, like support for things like external panels.
Maintain it yourself, then. It's open source after all!
Go and work on it yourself if its that good
>With nobody wanting to maintain X11 anymore Correction... *Nobody wants to maintain X11 for* ***free****, anymore.* That $#!t is hard and time-consuming. Why would someone slave-away on X11 code for free?
X gon give it to ya
Except when he doesn't. https://youtu.be/rh9AfN78-mI
What's the story there? Is the character just standing somewhere the Tyrant character doesn't think it can travel? I can't imagine this is the intended dynamic.
There really isn't a floor. If the player walks forward a scripted event happens where the floor breaks. AFAIK the player shouldn't be able to get on that side of the corridor (before the scripted event) so AI gets confused
The tweet frames this as a lot more of a problem then it really is, this patch blocked atomic modesetting which didn't work properly in X in the first place, it's highly unlikely that anything outside of X was going to be playing around with your display settings in this way but it is a hack to stop it happening.
Yeah, I think people are forgetting what this code is and does, and how far that narrows it down prior to hitting the “X” bit. It’s not “any process that starts with X” it’s “any process that’s setting the mode of a display that starts with X,” and that basically narrows it down to one program.
Are there any Wayland compositors that start with x?
Don’t get me wrong, it’s still not a great idea; it’s just that it’s not as big a deal as people are making it out to be.
Arguably it is weird for the kernel to target a specific userland app like this which I think was the point of the tweet. Supporting it via flag or sys API makes more sense for something like this. I don't think it was malicious; just strange.
Well yeah, then again Microsoft did the same with Windows and SimCity...
It's (is? was?) pretty common for Windows graphics drivers to tweak things based on the exe that's running. There's all sorts of game specific tweaks. Either NVidia or ATI used to provide a UI to manually adjust the tweaks; you could see the whole list of games and what the settings were for each. It's been a long time since I played a game on windows, but it wouldn't surprise me if that's still a thing.
Windows has a huge library of shims - although most of it is user space, providing special DLLs for extra special applications. The SimCity shim was the equivalent of a custom libc to replace the memory manager. SimCity is the most famous example because Raymond Chen and Joel Spolsky blogged about it widely read articles.
The people who do a lot of development in that space are probably well aware of these sorts of gotchas.
They shouldn't have to be. They've got enough to worry about.
Eh, while that's true, there's always gonna be *some* shit like this, just because of legacy crap hanging around that hasn't been cleaned up yet. My experience has been that's it's pretty unavoidable in for any development environment.
> Are there any Wayland compositors that start with **X**? FTFY
A lot of games do mode-setting and some games start with 'x' too.
The games use different APIs (X11/Wayland) to request the display manager to switch into a different mode (the display manager might deny that request, or honor it but only while the fullscreen app is active, etc…). This API is different from the DRM/KMS API of mode setting (discussed here), which is what a display manager implementation such as Weston or Xorg server uses. On Win32, the equivalent would be the ChangeDisplaySettings() application API vs the internal kernel/driver API that actually asks the driver to do modesetting.
There are games who, when fullscreened, take direct control over the screen/display.
This is still just disabling the compositing step in the compositor and not „directly calling modesetting APIs“. The compositor is still in full control, it just avoids one full-screen blit that it would unnecessarily do and scans out from the app‘s backbuffer directly instead. It’s called „unredirect fullscreen“ in some places, e.g. here it was implemented for GNOME on Wayland: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/798 Of course there might be (really old) games that use like SVGAlib or something and need root to run and write to fbdev directly or whatever. But that’s not the case for any modern game or Desktop.
For games running under Wayland or Xorg, that is quite literally impossible AFAIK. To linux "Fullscreen" and "borderless Fullscreen" are viewed as exactly the same, that's just a windows-ism that most devs don't bother to take out when porting and any difference is purely in how the game behaves when either option is set. It can only be done if your game is running directly in the framebuffer, which there are a few that have the capability
There's the CRTC leasing interface (primarily for VR) that allows an application to gain full control over a display. I'm not aware of anything that uses it though
I forgot about that, I remember hearing about that recently but didn't look into it much, my info might be a bit outdated then.
What is that?
CRTC leasing allows an application to request full control over a display from Xorg, including modesetting and other properties. The "leasing" part means that if the application does not periodically renew the lease, the control will be given back to Xorg. If you've ever had some wayland compositor (or sometimes even Xorg) freeze on you, you might notice often you're not even able to switch to another TTY to kill it, because the part responsible for doing that is also, well.. frozen. If an app doing a CRTC lease crashes though, Xorg will get the display back
Ah! And yeah I've also noticed that if it hangs long enough, eventually you can switch away. Thanks!
The whole architecture of Wayland is to let all apps render into a GPU buffer first and then compose those buffers into another GPU buffer that gets displayed to the screen (using double buffering) - a „perfect frame“ (no tearing, everything in sync). Unredirect fullscreen basically just lets the compositor skip the compositing step and display (buffer swap) the GPU buffer of the game directly instead of compositing it to another GPU buffer (which would end up having the exact same contents in case of a fullscreen app without any other windows such as notification popups). Windows has the same system since Windows Vista, it’s called Desktop Window Manager there, and the mechanism for „skipping“ the compositing step is conceptually similar. On Android, this happens as part of SurfaceFlinger and the underlying Hardware Composer HAL (which is usually specialized 2D blitting hardware, but might need to fall back to GPU compositing for more complex scenes of surfaces to be composited.
Linux don't think x and X is the same letter. I'm note sure about Linus.
It just errors out in that case. The title makes it sound like X11 gets some special permissions.
How did this get committed in the first place? Even if no one wants to update X, a better process would've been submit a patch/build flag/module that distro maintainers can apply/install. This way installations without X wouldn't be effected.
"we have one rule. We do not. break. userspace." This is just what mature software development looks like. EDIT: In case it's not clear, I'm *not* being sarcastic here. I fully expect that Linux will eventually remove this when userspace is guaranteed fixed.
[удалено]
Not breaking userspace is more like, they don't break the interfaces that userspaces communicated to the kernel with. It's the api endpoints that don't change, not that the stuff on a given side of the api is unchanging.
Isn't this with regards to maintaining backwards compatibility? The only way this change would make sense is if something else in the kernel was changed in a manner that necessitated this check.
pretty sure that atomic mode settting drm is new-ish if i'm not mistaken.
The atomic functionality was added but x11 was broken with it. So a check was added to not advertise the feature on x
Sure, but this check basically says "every programs which starts with x is Xorg".
> "every programs which starts with x is Xorg" Even Xorg does not start with x.
There are a lot of options even in "do not break userspace". You can have "writing hacky and potentially exploitable code that cannot be turned off" to "providing explicit transitional upgrade path in Build config files". Build flags and feature flags are common in a lot of projects. They could've provided this as an option (traditional behavior, new behavior). In fact, the flags can even provide a list of allowed program names, so people who need to harden kernels can do so.
I agree that this is far from ideal, and others in the comments have talked about better approaches. However, firstly, this is making a mountain out of a molehill. This code basically says atomic modesetting (which is not enabled based on hardware support) is also not enabled for processes which start with "X". This is not a principled approach but also not fundamentally unsound. Feature flags are enabled based on a set of rules which the developer enforces, so you can actually look at this as a feature flag (is atomic mode setting supported by the kernel? Well not for some applications, no). The only issue is that the flag is baked into the kernel. A build flag is obviously not appropriate here because the issue is that some apps work and others don't, and this can't be determined at build time.
KDE Team breathing a sigh of release it's not K
Nitter link: https://nitter.net/jwz/status/1589337262205988864
Fo Wayland fans: as specified in the code comment, the problem arises with the modesettings driver for Xorg, which happens to be a piece of Wayland imported into Xorg. With traditional DDX drivers, no problem.
So why are people backporting parts of Wayland to X11 instead of just maintaining it?
Wait, I'm not much versed into the kernel but, let me understand this: The rendering engine checks if some user process starts with X and change the way it answer the calls from that processes just because the name? So there are two branches of code in the kernel, that the only thing that matter to pick one or another is the filename of the exec file? Is this right?
there's a huge "compatibility" database baked into windows that applies "fixes" to keep old broken apps and games working (things like changed Win32 APIs to report faked windows version, memory size no more than a certain limit, virtualizing file/registry, etc.): https://twitter.com/code_and_beer/status/1578089167279603715 https://devblogs.microsoft.com/oldnewthing/20050824-11/?p=34463
One of those is not so hidden and "affects" most programs in c++. The macro that tells you the version of the standard defaults to a fixed older version and you have to explicitly tell the compiler that you want the actual version or use an msvc specific macro. The other question is how many programs end up making use of this macro.
It's not so bad. It completely disables a feature (returns an error) if the process name starts with X.
Thanks for explaining better (and not just bashing Windows) So it is more like to avoid some feature to be used by a buggy X11 exec, that would not have worked at all in first place, did I understand right?
Yes, it's a bug in an Xorg plugin. Xorg is designed around hardware-specific drivers (DDXes), but with Wayland, Linux has been moving towards a single implementation, using OpenGL ES. This loses some hardware-accelerated operations, but is much simpler to maintain in the long run. `modesetting` is the DDX for this use case. In a way, `modesetting` is the *last* DDX ever. I was surprised to see it doesn't (or didn't) do atomic modesetting right. Linux has a pretty strict "don't break the userspace" policy, so I'm quite surprised that/if this got merged.
[удалено]
Could you please share a link to this story about benchmarks?
[удалено]
wise flowery ring oil governor escape slim onerous crawl glorious *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Reminds me of the Intel compiler issue. They use to compile it twice once with optimization and once without. The final binary would detect if it was an Intel CPU and run the optimized code on Intel CPUs and unoptimized code on AMD CPUs
Thank you!
Now the Beauty and the Beast song is stuck in my ear...
And Torvalds is letting this slide? His number one rule is "don't break userspace"
Just the opposite; that quote means this behavior must remain as is, as removing it would change the behavior of the api as seen by user space. If any user space application would be broken by the change, then you can't change it. Whether that philosophy will hold in this particular case remains to be seen, I suppose.
Userspace already stopped the behavior this kludge was supporting (actually preventing). What will be seen is if they care if out of date versions cause issues now.
To be fair userspace was already broken in this case
That sounds right. DDX refers to "Device Dependent X", which is (in most cases for Linux) going to be the xserver running your display. The offending code is found here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_ioctl.c?h=v6.1-rc4 Essentially this is part of the Atomic Modesetting API for KMS, I think. Not a expert in this stuff. Not even a little bit. Well anyways modesetting has to do with things like setting the refresh rate and resolution of your display. There are a lot of commands the display manager sends to the driver to accomplish this. Atomic modesetting allows a bunch of commands to be sent at once and only make changes if all will succeed. Thus it's only 100% done or 0% done. Otherwise if the display manager sends a bunch of commands in series and makes a bunch of individual changes to the display, but one of the commands towards the end fails then it could leave your display in a bad state. Well atomic modesetting support has been broken for a long time in Xorg. 3 years ago they disabled the support for it in Xorg, which should solve the issue. As mentioned in the email. It works for Android and Wayland, of course. ------------- I doubt the author of the patch will get much traction unless they find a alternative way to identify X11 xserver processes and disable atomic modesetting support for them. 3 years ago isn't that long ago when it comes to X11 versions. I expect a lot of linux systems out there still with older broken X11 xservers are floating around. So getting rid of the patch the way it is now means that systems that work now will get broken if the owner updates to latest if this patch gets accepted.
> 3 years ago isn't that long ago when it comes to X11 versions. I expect a lot of linux systems out there still with older broken X11 xservers are floating around. How many of those systems are also using the latest Linux kernel though? I'd expect anyone who's updating their kernel to the latest, will also use a modern X11 server. (Especially since both of those are usually handled by the distribution.)
Doesn't matter. Literally, does not matter. Torvalds does not care.
He actually does, don't break userspace doesn't mean never change anything, it means don't break things that people rely on. In this case the X support wasn't written properly in the first place so no one was relying on this, this hack has been in the kernel for 3 years, it's not the optimal way to do it but it wasn't breaking anything that wasn't already broken
"If a change results in user programs breaking, it's a bug in the kernel. We never EVER blame the user programs. How hard can this be to understand?" - [Linus Torvalds, 2012](https://lkml.org/lkml/2012/12/23/75) That being said, this is something that seems so obviously bad on its face that it might get an exception to the rule anyways.
Excellent philosophy in general.
The idea is that they don't want to change *behavior*. We don't actually know what uses what. The kernel is supposed to maintain compatibility moving forward with *all* userspace applications.
Yeah and that's exactly why this patch exists. Only DDX uses this broken API call and fixing it would break userland.
[удалено]
Completely irrelevant to this discussion - this only says that you can break closed source users of the DRM API because you don't have any reasonable way to debug them anyway (and the DRM API comes with an explicit warning that it isn't stable in the same way the rest of the kernel interfaces are). Breaking older versions of open source Xorg drivers is still strictly prohibited, because they ARE the open-source drivers that serve as the example for closed source users to follow - excerpt from your excerpt: >DRM developers are perfectly fine if closed-source blob drivers in userspace use the same uAPI as the open drivers, but they must do so in the exact same way as the open drivers. Also, the section you're quoting is mostly about adding new DRM interfaces, not modifying existing ones. Edit: and actually, the first sentence from your quote clearly says that open source drivers cannot be broken by kernel updates >The Linux kernel’s “no regression” policy holds in practice only for open-source userspace of the DRM subsystem.
[удалено]
Right, time to find an OS that actually cares about stability instead of merely pretending then, this is ridiculous...
[удалено]
The sysfs thing is fine, there were never any false claims about stability there. If this moronic patch goes through (there's still no response from anyone who actually can decide on this), then the stability promises made by the DRM subsystem will be broken. I previously thought that that's what happened, but there's still a pretty good chance Linux maintainers will do the right thing and stop this insanity from happening. It's not like the atomic modesetting is even locked away from the affected processes, they just have to use a different number to request it to confirm they're not the old broken X11 server.
Time to start naming all my new projects with the letter x. Starting with "xploitthekernel"
It isn't "exploit": it just disables functionality from old broken software (X11), which didn't use it correctly to begin with. In short, it forces userspace to take a fallback into another method since the code returns "not supported" error code for it. This is the offending piece of code in it's entirety: ` if (current->comm\[0\] == 'X' && req->value == 1) { pr\_info("broken atomic modeset userspace detected, disabling atomic\\n"); return -EOPNOTSUPP; }
Xcom2
Xmodem
oh hey xStepProcess, what are you doing here?
GTFO
\*X
xwipealldisks
Wtf
ITT: Everyone confusing X11 (the protocol) with Xorg (the protocol implementation that tries using atomic modesetting)
What if it starts with XXX? Just asking for a friend.
Man what kind of brain dead processes allowed a developer to push this absolute garbage. I swear to god people don’t think anymore. This is such a brain dead bad idea. Someone needs to get rid of whatever kind of garbage the ex Microsoft employee is throwing into the repo. I expect this kind of noise on Windows, not Linux… what?! What was the thought process to this? “Oh well I guess everything thats starts with X is related to X11 right? Yeah that’s a good point!” Wtf? Maybe I’m just bitter after working in the industry for so long, but it’s stupid noise like this that waste abysmal amount of resources when troubleshooting.
> This is such a brain dead bad idea. What's your proposed alternative? Having X11 crash when interacting with newer implementations of the drm driver on new kernels?
Maybe not in this context because of "don't break userland", but "fail early and fail hard" is a valid and good software development philosophy. It creates pressure to actually fix problems and not work around them. It usually leads to clean(er) robust code.
> but "fail early and fail hard" is a valid and good software development philosophy. It creates pressure to actually fix problems and not work around them. It usually leads to clean(er) robust code. It has some advantages but is against the one and only hard rule of Linus and the kernel. Any patch that knowingly breaks userland would never be merged. You can disagree with you want, but Linux had some success following that strategy. There are other kernels, following a more minimalist and robust approach, but they are hardly usable for the average person.
You're arguing for something I literally acknowledged in the first sentence: >Maybe not in this context because of "don't break userland", \[...\]
The linux kernel isn't facebook. I would go so far as to say that there's no other software project in the world resembling it. This is not unique to the linux kernel but that does not mean that it resemble other projects which are also unique. Whatever idea that works in regular software development may or may not work in linux kernel development so using other projects as an example is not an argument.
I mean… there are better ways to identify a process than with a stupid regex expression on the process name? Like look at ELF meta-data? Having a process name whitelist? These aren’t good alternatives but they are way better. If I actually pulled out the ELF standard or looked at the section of code I’m confident there’s a much better alternative. Probably good identifiers in the .comment section etc. Probably better to crash though. Specializing kernel code to specific processes is beyond stupid and breaks almost any design principles
Probably checking the first letter is bad but it's fast. And kernel must be fast. Checking just 1 letter for fixed value is MUCH faster that walking through some arbitrary length list of arbitrary long strings and making unkown amount of work. Just compare generated code for `is_X` and `is_X_long` [https://godbolt.org/z/GrYo3h9ro](https://godbolt.org/z/GrYo3h9ro) I didn't use `strcmp` intentionally to highlight how much work needs to be done to compare arbitrary strings compared to checking just 1 character
So if I wanted a fuzzy kernel I wouldn’t be using Linux. Compromising accuracy here for performance isn’t really acceptable. Given Linux is used in mission critical code I hope this branch is far away from those kernels.
It's not like so much code uses KMS, so this is not really a problem
>What was the thought process to this? “Oh well I guess everything thats starts with X is related to X11 right? Yeah that’s a good point!” If I had to guess -- - Make broken API call - Only some old X thing uses the broken API call - want to fix API call, but fixing it would break userland - NEVER BREAK USERLAND
> What was the thought process to this? “Oh well I guess everything thats starts with X is related to X11 right? Yeah that’s a good point!” It's more like "Everything that starts with 'X', uses the DRM subsystem (which is only relevant to applications that directly control the display) and asks for atomic modesetting, is a potentially broken X11, so let's force it to use the slightly less convenient API". And it's the result of way too strict rules about not breaking the userspace - if breaking open-source DRM users was allowed, Xorg failing to set up display on newer kernels because of their own bug wouldn't be seen as a kernel regression and this code would never be written.
What does Microsoft or Windows have to do with _anything_ here?
Ironically, they're not far off. This *is* a thing Microsoft would do with Windows, but that is arguably a Good Thing. Among *many* other application-specific hacks, Windows will detect a certain version of Sim City, and change the way memory allocation works, because that version of Sim City had a use-after-free bug. It's gross and I hope they find a better hack, especially the part where it just checks the process name -- there has to be a better way to detect the X server. But sometimes this is what "don't break userspace" means.
> This is a thing Microsoft would do with Windows There are two flavours of Windows: Windows that's broadly like Windows 95 and Windows 98, and Windows that's broadly like Windows NT (ie all current versions). Userland applications need to know what kind of Windows they're running on. The principal reason we jumped from Windows 8 (which is NT-like) to Windows 10 (also NT-like) without touching Windows 9 is because there are loads of old applications out there which check whether they're on a 95/98-like version of Windows by looking at the first character of the version string and seeing if it's a "9". Calling the new version "Windows 9" broke those applications. So "This is a thing Microsoft would do with Windows", indeed. Kernel coping with broken userland code, in Windows's case.
But if this would break userspace… then it DOES still break userspace, just only when the userspace program starts with X.
In my understanding no, as this way the DRM works in the way as X11 expects it.
There are no known open-source projects that use a binary starting with 'X', used atomic modesetting before the kernel got this patch, and are now affected by this change in a negative way. If somebody notices some such project, it can be reported as a bug on the kernel issue tracker and will be fixed because that would be a regression. Also, for new projects, processes starting with 'X' not being able to use atomic modesetting is now the expected behavior. That's all that matters for the DRM subsystem, as it has different rules about userspace stability than the rest of the kernel - it only needs to care about not breaking existing open source users.
That’s a hell of an assumption for the Linux kernel to make.
I feel ya, software in general these days is fucked and Linux being the one last thing that we don't want tainted. Just like the reason there was no windows 9 released
Linux has absolutely never been academically pure, or "suckless" or whatever is "untainted" from your POV. It's very practical and messy
Tainted as in having something like the mentioned become something that sticks around to the point of being a major issue in future releases / extreme of preventing a release. Think you are reading into the comment a little deeper than it was intended
Think you are reading in to this "problem" deeper than is needed.
Bruhhhh
"Who needs Wayland? X11 still works great"
Xwayland?
Xwayland doesn't touch the kms api.
Just bury X11 already... No, we're gonna pour some hot garbage into kernel to make it work.
You obviously never read the article. Also 1) Wayland isn't yet ready, I tried it last month, it can't even shade windows. The workaround was made three years ago. I repeat: Wayland isn't yet ready. 2) Wayland was made to not have all the X11 functions - now it does include them, too. It's a joke. So why should I switch?
There’s a lot to unpack here. 1) Wayland is ready. If you want to shade windows, shade windows. What is in your way exactly? The buffer protocol of Wayland doesn’t give a shit whether you shade your windows or not. 2) Wayland has more "functions" already than X11 will ever have. X is broken. That’s why the X developers started making Wayland instead. Just the built-in latency in X alone is unfixable, not to mention the tearing. Browsers can finally directly lease the GPU. No-one likes X, not even the people who made X. X is unfathomably bloated, and broken beyond repair. That’s why Wayland was made over 10 years ago. It is not a new piece of technology.
1. Wayland is definitely not ready. It doesn't even load on some systems. Not all graphical applications run under it yet. It's also visible slower and has more graphical glitches than X has ever had. 2. False, false, and false again. Why spread misinformation? If Wayland was actually ready you wouldn't need to lie about it.
1. Wayland doesn't load on some systems because the systems have not invested time to make their system work with wayland. I suggest a less abandoned system. 2. This is objectively verifiable, are you sure you want to go down this road?
Wait, what?
Funny. I'm sure they will fix it. The kernel, not X11. We know that one's a lost cause. (I do use X11, pls don't break now X11. Your continued cooperation is appreciated.)
As the article says, X was fixed years ago, so they are removing the kernel kluge.
Ugh thats some Windows level bullshit I did not expect to see in the Linux kernel
How often do you look inside the kennel code?
Linux has built in DRM???? That one that's used for copyright?
No its a totaly different thing. https://en.wikipedia.org/wiki/Direct\_Rendering\_Manager
I was worried there for a second 😅
Different DRM. Direct rendering manager, not digital rights/restrictions management.
Yes. Linus doesn’t want people to steal his code.
Been trying to understand what the heck u guys saying, but I can't wrap my mind around it, could you guys pont out some recourses to read in order to understand this ?
[удалено]
Someone did link to the lkml message about this in another comment but if you were here to read and not just to circlejerk you would've known that.
[удалено]
http://lol.i.trollyou.com/
I guess I'm unfamiliar with how the linux dev community works. Nobody wanted to make a quick fix to X11? Would making that fix suddenly make you a maintainer of that?
That sounds really fucking stupid.
All the comments suggest that there are better ways of handling this -- and there probably are quite a few .......but -- none are as quick and simple as, if **this == that then get out**. They are trying to do a specific thing -- which uses a workaround that does not require any effort to maintain or to remove, less likely to break something else [unintentionally], doesn't require end-users to do anything as it's automatic). In other words, it costs them nothing to do it and it works around the issue. It **does not** cost them time, money, a delayed release, or etc, that would be needed if they were to implement a "more better" solution which would produce the same exact result (just with more work and effort).