Signed-off-by: Francois Gouget fgouget@free.fr --- dlls/wined3d/adapter_gl.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/dlls/wined3d/adapter_gl.c b/dlls/wined3d/adapter_gl.c index 87418e1e44e..80ba61414eb 100644 --- a/dlls/wined3d/adapter_gl.c +++ b/dlls/wined3d/adapter_gl.c @@ -433,11 +433,11 @@ static BOOL match_apple(const struct wined3d_gl_info *gl_info, struct wined3d_ca * * Detecting this isn't really easy. The vendor string doesn't mention * Apple. Compile-time checks aren't sufficient either because a Linux - * binary may display on a MacOS X server via remote X11. So try to detect + * binary may display on a macOS X server via remote X11. So try to detect * the OpenGL implementation by looking at certain Apple extensions. Some * extensions like client storage might be supported on other * implementations too, but GL_APPLE_flush_render is specific to the - * MacOS X window management, and GL_APPLE_ycbcr_422 is QuickTime + * macOS X window management, and GL_APPLE_ycbcr_422 is QuickTime * specific. So the chance that other implementations support them is * rather small since Win32 QuickTime uses DirectDraw, not OpenGL. * @@ -893,11 +893,11 @@ static void quirk_no_np2(struct wined3d_gl_info *gl_info)
static void quirk_texcoord_w(struct wined3d_gl_info *gl_info) { - /* The Intel GPUs on MacOS set the .w register of texcoords to 0.0 by + /* The Intel GPUs on macOS set the .w register of texcoords to 0.0 by * default, which causes problems with fixed-function fragment processing. * Ideally this flag should be detected with a test shader and OpenGL - * feedback mode, but some OpenGL implementations (MacOS ATI at least, - * probably all MacOS ones) do not like vertex shaders in feedback mode + * feedback mode, but some OpenGL implementations (macOS ATI at least, + * probably all macOS ones) do not like vertex shaders in feedback mode * and return an error, even though it should be valid according to the * spec. * @@ -906,8 +906,8 @@ static void quirk_texcoord_w(struct wined3d_gl_info *gl_info) * instruction slots which should be available to the Direct3D * application. * - * ATI Radeon HD 2xxx cards on MacOS have the issue. Instead of checking - * for the buggy cards, blacklist all Radeon cards on MacOS and whitelist + * ATI Radeon HD 2xxx cards on macOS have the issue. Instead of checking + * for the buggy cards, blacklist all Radeon cards on macOS and whitelist * the good ones. That way we're prepared for the future. If this * workaround is activated on cards that do not need it, it won't break * things, just affect performance negatively. */
On 27 September 2018 at 10:55, Francois Gouget fgouget@free.fr wrote:
Signed-off-by: Francois Gouget fgouget@free.fr
dlls/wined3d/adapter_gl.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
I don't necessarily want to block this going in if you really care about this, but I also think the name-change is completely ridiculous.
On Fri, 28 Sep 2018, Henri Verbeet wrote:
On 27 September 2018 at 10:55, Francois Gouget fgouget@free.fr wrote:
Signed-off-by: Francois Gouget fgouget@free.fr
dlls/wined3d/adapter_gl.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
I don't necessarily want to block this going in if you really care about this, but I also think the name-change is completely ridiculous.
You mean Apple's decision to change the name or the patch ;-)
The thing is that "MacOS X" is a misspelled form of "Mac OS X", the former OS name, so my script reports it as a typo[1]. And it is with spelling issues as with warnings or test failures: if you let them accumulate you soon cannot tell what's new from what's not[2].
So I can either change that to one of the official names or disable this specific check for Wine. So even though it's a minor issue I typically prefer to just send a patch once in a while. But I can disable this check if you prefer.
[1] Although the X is part of 'X server' the script is still right: it's my understanding that the OS name is either 'Mac OS X' or 'OS X' or now 'macOS', but cannot be 'MacOS'.
[2] And people also copy / paste the bad spelling or get influenced by it; both cases leading to the spread of the misspelled form.
On 28 September 2018 at 04:02, Francois Gouget fgouget@free.fr wrote:
On Fri, 28 Sep 2018, Henri Verbeet wrote:
I don't necessarily want to block this going in if you really care about this, but I also think the name-change is completely ridiculous.
You mean Apple's decision to change the name or the patch ;-)
Apple's decision.
The thing is that "MacOS X" is a misspelled form of "Mac OS X", the former OS name, so my script reports it as a typo[1]. And it is with spelling issues as with warnings or test failures: if you let them accumulate you soon cannot tell what's new from what's not[2].
So I can either change that to one of the official names or disable this specific check for Wine. So even though it's a minor issue I typically prefer to just send a patch once in a while. But I can disable this check if you prefer.
I guess what I'm saying is that I'm fine with this going in, but have reservations about endorsing it with a Signed-off-by.
-
Francois Gouget -
Henri Verbeet