Re: wined3d: print the architecture when showing driver problems
On Mon, Jun 24, 2013 at 12:20 AM, Henri Verbeet wrote:
> On 23 June 2013 07:10, Austin English wrote:
>> Please consider applying before the release of 1.6. It has no
>> functional changes, but would really help when diagnosing user
>> problems.
>>
> This is not really a wined3d patch. That said, while I agree that
> printing the architecture would be useful here, you can probably avoid
> the #ifdef by using something along the lines of sizeof(void *) == 8 ?
> "64-bit" : "32-bit", although ideally we'd probably get the actual
> architecture from somewhere like ntdll.
My understanding was that using the _WIN64 macro was preferred. I can
certainly do that instead. How's this?
--
-Austin
From 0cc848b88f98f7da67671bbedb0a28c16cad2d66 Mon Sep 17 00:00:00 2001
From: Austin English
Date: Tue, 25 Jun 2013 18:52:02 -0700
Subject: [PATCH] wined3d: print the architecture when showing driver problems
(try 2)
---
dlls/winex11.drv/opengl.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c
index cd24575..a3199cb 100644
--- a/dlls/winex11.drv/opengl.c
+++ b/dlls/winex11.drv/opengl.c
@@ -464,7 +464,8 @@ static BOOL X11DRV_WineGL_InitOpenglInfo(void)
if(pglXMakeCurrent(gdi_display, win, ctx) == 0)
{
-ERR_(winediag)( "Unable to activate OpenGL context, most likely your
OpenGL drivers haven't been installed correctly\n" );
+ERR_(winediag)( "Unable to activate OpenGL context, most likely your
%s OpenGL drivers haven't been "
+"installed correctly\n", sizeof(void *) == 4 ?
"32-bit":"64-bit" );
goto done;
}
gl_renderer = (const char *)opengl_funcs.gl.p_glGetString(GL_RENDERER);
@@ -506,9 +507,10 @@ static BOOL X11DRV_WineGL_InitOpenglInfo(void)
* Detect a local X11 server by checking whether the X11 socket is a
Unix socket.
*/
if(!getsockname(fd, (struct sockaddr *)&uaddr, &uaddrlen) &&
uaddr.sun_family == AF_UNIX)
-ERR_(winediag)("Direct rendering is disabled, most likely your
OpenGL drivers "
+ERR_(winediag)("Direct rendering is disabled, most likely your %s
OpenGL drivers "
"haven't been installed correctly (using GL
renderer %s, version %s).\n",
- debugstr_a(gl_renderer),
debugstr_a(WineGLInfo.glVersion));
+ sizeof(void *) == 4 ? "32-bit":"64-bit",
debugstr_a(gl_renderer),
+ debugstr_a(WineGLInfo.glVersion));
}
else
{
@@ -522,9 +524,10 @@ static BOOL X11DRV_WineGL_InitOpenglInfo(void)
* it shows 'Mesa X11'.
*/
if(!strcmp(gl_renderer, "Software Rasterizer") || !strcmp(gl_renderer,
"Mesa X11"))
-ERR_(winediag)("The Mesa OpenGL driver is using software
rendering, most likely your OpenGL "
+ERR_(winediag)("The Mesa OpenGL driver is using software
rendering, most likely your %s OpenGL "
"drivers haven't been installed correctly (using GL
renderer %s, version %s).\n",
- debugstr_a(gl_renderer),
debugstr_a(WineGLInfo.glVersion));
+ sizeof(void *) == 4 ? "32-bit":"64-bit",
debugstr_a(gl_renderer),
+ debugstr_a(WineGLInfo.glVersion));
}
ret = TRUE;
--
1.8.2.1
Re: widl: Do not generate empty Vtbl structure for empty interfaces.
On 2013-06-25 21:11, Alexandre Julliard wrote: > Thomas Faber writes: > >> An alternative solution would be not to generate a vtable structure at all, >> and instead add a dummy member to the class directly. That would be in line >> with what the defined(__cplusplus) && !defined(CINTERFACE) case results in, >> but require a slightly larger change to widl. > > I'm not sure it makes sense to even define a C structure at all, since > there's nothing you can do with it. Hmm. The only thing I could think of would be someone making a pointer to such an object, to later cast to a derived class. Since there's a typedef generated earlier in the file, the struct should already be known (as an incomplete type), so that scenario would work even without the struct definition. So... I agree. I'll send an updated patch that won't generate the structure at all.
Re: widl: Do not generate empty Vtbl structure for empty interfaces.
Thomas Faber writes: > An alternative solution would be not to generate a vtable structure at all, > and instead add a dummy member to the class directly. That would be in line > with what the defined(__cplusplus) && !defined(CINTERFACE) case results in, > but require a slightly larger change to widl. I'm not sure it makes sense to even define a C structure at all, since there's nothing you can do with it. -- Alexandre Julliard julli...@winehq.org
Bug 24018 which appears to be a showstopper for running Cygwin on Wine
Andrey Turkin has stated at http://bugs.winehq.org/show_bug.cgi?id=24018 that this is really a Cygwin bug. I frankly don't understand the technical details but his current test (an infinite loop with Cygwin fork calls) may need some beefing up to convince the Cygwin developers they have introduced a regression. The reason why I mention a Cygwin regression is the winetricks script mentions bug 24018 and works around it by downloading an old version of the Cygwin installer. I haven't tried that myself yet, but if that workaround still works, then this is evidence that the issue is a Cygwin regression which is an important consideration when reporting this issue to the Cygwin developers. Andrey Turkin was asked at http://bugs.winehq.org/show_bug.cgi?id=24018 to report the issue to Cygwin, but my search of the Cygwin mailing list archive didn't find any post from him and only found one extremely casual (an aside to a completely different thread) mention (http://sourceware.org/ml/cygwin/2013-06/msg00471.html) from a different wine developer of bug 24018 with no response to that mention. I currently have no experience with Cygwin and my only real interest in Cygwin on Wine is it theoretically provides an alternative build platform to my present successful work with the combination of MinGW, MSYS, and Wine as a Windows build platform. But I haven't even been able to get started with Cygwin on Wine because of this showstopping bug. Therefore, I am mentioning the situation here in the hope that some wine developer on this list with some knowledge of Cygwin will take the responsibility of making a proper bug report to the Cygwin mailing list (which according to http://cygwin.com/problems.html is the correct place to report Cygwin bugs) including the evidence that the issue is a Cygwin regression (assuming investigation of older Cygwin versions with Turkin's test supports that conclusion). Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __
Re: [PATCH] wined3d: Implement per-stage constant in glsl fixed fonction pipeline.
Thanks Stefan! No problem with me. I don't take it personnally. :) I'm not statisfied with the submission/review with some criterias which are sometimes rules, sometimes tastes, with patches (not necessarily mine) that remain in the new state without any comments while another with a missing dot would have more attention. I live with that, I'm used to enough, but I'm wondering how newcomers that are not paid could contribute. Fortunately there are cool guys. Not necessary overskilled but who try to do their humble best. This is what gives some fun for me. :) BTW, "fonction" is the french word for "function". Probably a wrong locale. ;) 2013/6/25 Stefan Dösinger > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Am 2013-06-25 18:08, schrieb Christian Costa: > > Are we really discussing about a typo in the subject line? > > "Implement" just comes naturally from the fixme when I create an > > empty patch. It turned out after coding that "Fix" is more > > appropriate. I forgot to updated it. This will be fix. > I think the typo Henri refers to is "fonction", which should be > "function". > > While I agree with Henri's statement to some extend - patch reviewing > is a terribly exhausting task - I think the statement was a bit harsh > to say to someone who donates his personal time to the project. > > I'll try to do a better job looking at patches myself to help weed out > the most obvious mistakes - right now he's doing all the d3d reviewing > work. > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.20 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRycSuAAoJEN0/YqbEcdMwOHwP/R98Fs+ZunKuRIPnenvXFEat > hP3C1JCrGhxANiYIggkdcvfjPxCSbgz+LM4nfZC4qARSHnYzvxhcQxALN2je/lwb > 1iWx/xZ0Czy2yR3rHqJCEW0jXkV53O/Lkqbs/Nf2ue0I7vJWuhaA3Tl+P1esE3m8 > rdeRQY89SyXuvfZGtO1tPnGwsYMU/NuSoIffKkLjjWpBhScvJmcSUYOL9RuFk6Tj > +r7zGp9niSfVO9N8JY7BTAlXTcAK9p0gKaWzAuCXYFr8gcbOaGB3kDSsbIhtHe57 > 8oWEDA9pn3tO7l1fXGZdbyfamIPyjg5boh1yHireDze9eefGHrd/WQqEu1xqVd95 > BVlFUt2nMPZoR9A0MUT3/0kbq/sfJ05ytCTZ5AlbNAO8msA0fTX58gw6UA9QXrET > 1dpE+tjGHzN49qjcBtUmFUII6zc+m8B91Xlhplupda2v/TZv+tzQvrsMIuwRvLvP > hTzxaZo/kFr2Pnlx8Sgk0ImNUfi9AIXpLo/h7geLgMi0kMTzkHY4qW2LGf74GNhU > NtBgN+4Y1iFLeK6dbKIenD75MN/JGOp6eOHK53E2++RykLxJLyqCTPqplShE/Zz7 > hnt80SQTR0jYttA9KsHGE3GnqKPc8RndMnjGnMCyNhLj9Jm27te2VMGLbw4mK0yD > C+nOcltXE3Hu3AYpzEXd > =C1yJ > -END PGP SIGNATURE- >
Re: server: Update German translation of manpage.
Julian Rüger writes: > I'm unsure about the second line. Is that supposed to be the "last > modified" date of the manpage, the wineserver or what? The English > version says October 2005. In general, it would be the last time there were changes to the program that required a manpage update. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] wined3d: Implement per-stage constant in glsl fixed fonction pipeline.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2013-06-25 18:08, schrieb Christian Costa: > Are we really discussing about a typo in the subject line? > "Implement" just comes naturally from the fixme when I create an > empty patch. It turned out after coding that "Fix" is more > appropriate. I forgot to updated it. This will be fix. I think the typo Henri refers to is "fonction", which should be "function". While I agree with Henri's statement to some extend - patch reviewing is a terribly exhausting task - I think the statement was a bit harsh to say to someone who donates his personal time to the project. I'll try to do a better job looking at patches myself to help weed out the most obvious mistakes - right now he's doing all the d3d reviewing work. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRycSuAAoJEN0/YqbEcdMwOHwP/R98Fs+ZunKuRIPnenvXFEat hP3C1JCrGhxANiYIggkdcvfjPxCSbgz+LM4nfZC4qARSHnYzvxhcQxALN2je/lwb 1iWx/xZ0Czy2yR3rHqJCEW0jXkV53O/Lkqbs/Nf2ue0I7vJWuhaA3Tl+P1esE3m8 rdeRQY89SyXuvfZGtO1tPnGwsYMU/NuSoIffKkLjjWpBhScvJmcSUYOL9RuFk6Tj +r7zGp9niSfVO9N8JY7BTAlXTcAK9p0gKaWzAuCXYFr8gcbOaGB3kDSsbIhtHe57 8oWEDA9pn3tO7l1fXGZdbyfamIPyjg5boh1yHireDze9eefGHrd/WQqEu1xqVd95 BVlFUt2nMPZoR9A0MUT3/0kbq/sfJ05ytCTZ5AlbNAO8msA0fTX58gw6UA9QXrET 1dpE+tjGHzN49qjcBtUmFUII6zc+m8B91Xlhplupda2v/TZv+tzQvrsMIuwRvLvP hTzxaZo/kFr2Pnlx8Sgk0ImNUfi9AIXpLo/h7geLgMi0kMTzkHY4qW2LGf74GNhU NtBgN+4Y1iFLeK6dbKIenD75MN/JGOp6eOHK53E2++RykLxJLyqCTPqplShE/Zz7 hnt80SQTR0jYttA9KsHGE3GnqKPc8RndMnjGnMCyNhLj9Jm27te2VMGLbw4mK0yD C+nOcltXE3Hu3AYpzEXd =C1yJ -END PGP SIGNATURE-
Re: [PATCH] wined3d: Implement per-stage constant in glsl fixed fonction pipeline.
2013/6/25 Henri Verbeet > On 25 June 2013 11:05, Christian Costa wrote: > > 2013/6/25 Henri Verbeet > >> At least try to pretend you put > >> some effort into making sure the patch is as good as it can be before > >> submitting it. > > > > > > I could have send the patch to wine-devel first but would I get something > > longer that "several issues" as feedback? > No, you're missing the point. Why do you expect me to even look at a > patch if you clearly didn't even check for obvious typos yourself? > Bottom line, if you want me to spend time reviewing a patch and giving > feedback, make sure it's worth that time. > Are we really discussing about a typo in the subject line? "Implement" just comes naturally from the fixme when I create an empty patch. It turned out after coding that "Fix" is more appropriate. I forgot to updated it. This will be fix. According to the feedback I got, altough the patch is not correct, it doesn't seem it does not worth looking at. And now there is materials to make it better.
Re: Czech language for Wine
Pavel VlÄek writes: > @@ -1415,19 +1400,19 @@ > > #: crypt32.rc:74 > msgid "Title" > -msgstr "Titul" > +msgstr "" > > #: crypt32.rc:75 > msgid "Given Name" > -msgstr "Jm©no" > +msgstr "" > > #: crypt32.rc:76 > msgid "Initials" > -msgstr "Inici¡ly" > +msgstr "" > > #: crypt32.rc:77 > msgid "Surname" > -msgstr "Pjmen" > +msgstr "" Why are you removing all these existing translations? -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] wined3d: Implement per-stage constant in glsl fixed fonction pipeline.
On 25 June 2013 11:05, Christian Costa wrote: > 2013/6/25 Henri Verbeet >> At least try to pretend you put >> some effort into making sure the patch is as good as it can be before >> submitting it. > > > I could have send the patch to wine-devel first but would I get something > longer that "several issues" as feedback? No, you're missing the point. Why do you expect me to even look at a patch if you clearly didn't even check for obvious typos yourself? Bottom line, if you want me to spend time reviewing a patch and giving feedback, make sure it's worth that time.
Re: [PATCH] wined3d: Implement per-stage constant in glsl fixed fonction pipeline.
2013/6/25 Henri Verbeet > On 24 June 2013 16:44, Matteo Bruni wrote: > > @@ -1673,6 +1673,8 @@ struct texture_stage_op > > unsignedaarg2 : 8; > > unsignedaarg0 : 8; > > > > +DWORD constant; > > + > > struct color_fixup_desc color_fixup; > > unsignedtex_type : 3; > > unsigneddst : 1; > > > > You don't need this if you use uniforms. > > Also adding a test would be nice probably. > > > Yeah, that's the main issue. We don't want a shader for every possible > set of per-stage constant values. The one you missed is that if we > implement this, we should also set the appropriate caps bit. > Spin Tires does not seem to check this caps. That's why I missed it first. > > The most obvious issue is of course the subject line. Sure, typos > happen, but it's just plain sloppy. It's a typo yes. You can easy deduced this with the patch description. > At least try to pretend you put > some effort into making sure the patch is as good as it can be before > submitting it. > I could have send the patch to wine-devel first but would I get something longer that "several issues" as feedback? I can certainly improve my patches and you can certainly improve your way of giving feedback but that would be great if you could avoid this kind of commentary. This is not usefull. At least for me. For technical stuff you can be as verbose as you want. I'm full open.
Re: [PATCH] ole32: LeaveCriticalSection in one exit case (Coverity)
On Sun, Jun 23, 2013 at 08:43:18PM +0900, Dmitry Timoshkov wrote:
> Marcus Meissner wrote:
>
> > > > --- a/dlls/ole32/ifs.c
> > > > +++ b/dlls/ole32/ifs.c
> > > > @@ -217,6 +217,8 @@ static LPVOID WINAPI IMalloc_fnRealloc(LPMALLOC
> > > > iface,LPVOID pv,DWORD cb) {
> > > > IMallocSpy_Release(Malloc32.pSpy);
> > > > Malloc32.SpyReleasePending = FALSE;
> > > > Malloc32.pSpy = NULL;
> > > > + /* cb == 0 case will release it some lines below. */
> > > > + if (cb) LeaveCriticalSection(&IMalloc32_SpyCS);
> > > > }
> > > >
> > > > if (0==cb) {
> > >
> > > Why not unconditionally release the lock before the '0==cb' check?
> >
> > That would cause LeaveCriticalSection be called twice with a race window
> > inbetween.
>
> Of course you'd need to remove a redundant LeaveCriticalSection under
> 'if (0==cb)' case, and I don't see a race there.
I resubmitted a slightly improved fix, but I do not think it can be made as
simple as you think it can.
Ciao, Marcus
