February 2014 - Wine-Devel - list.winehq.org

Re: [PATCH 1/2] wined3d: Add support for NV12 textures

by Martin Storsjö

On Mon, 10 Feb 2014, Stefan Dösinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > The shader looks ok to me. Please add a test - see yuv_color_test in > dlls/d3d9/tests/visual.c as an example, although it might not be > feasible to integrate a NV12 test into the UYVY / YUY2 test loop. > > Since the UYVY / YUY2 test already covers the color space conversion > parts I think a NV12 test should make sure that the coordinate > selection works properly. Test that e.g. a 4x4 or 8x8 texture produces > the correct color pattern. Ok, I've made such a test, will resend the full patchset soon. > Am 2014-02-10 12:08, schrieb Martin Storsjo: >> This fixes video playback with the sample app from OpenH264. >> --- >> I haven't been able to test the GL_TEXTURE_RECTANGLE_ARB codepath >> here - if I explicitly disable >> gl_info->supported[ARB_TEXTURE_NON_POWER_OF_TWO] the same app >> crashes. Similarly for YV12 (which already exists and works), >> if I disable ARB_TEXTURE_NON_POWER_OF_TWO there, the app crashes >> and the video output is also garbled (the luma channel seems to >> be right but chroma is handled incorrectly). > I don't know what could be wrong with the texture rectangle codepath. > I tested it when I wrote it for other formats, but it's quite possible > that it has suffered from bitrot in the years since then. Also keep in > mind that wined3d assumes limited ARB_TEXTURE_NON_POWER_OF_TWO support > if OpenGL 2.0 is supported. Yeah, I might have a look later if I can figure it out. It's probably not of highest priority at the moment anyway. >> @@ -6772,6 +6772,7 @@ struct arbfp_blit_priv { >> GLenum yuy2_rect_shader, yuy2_2d_shader; >> GLenum uyvy_rect_shader, uyvy_2d_shader; >> GLenum yv12_rect_shader, yv12_2d_shader; >> + GLenum nv12_rect_shader, nv12_2d_shader; >> GLenum p8_rect_shader, p8_2d_shader; >> GLuint palette_texture; >> }; > It might be a good idea to replace those 10 shaders and the poorly > scaling search for them with a rbtree. Yeah, I know, I started this > mess, but back then it was just 4 shaders and we've been too lazy to > clean this up since then :-\ . Ok, I made a patch that does this, on top of the NV12 patch. If requested I can reorder them but it's a bit of work. >> + switch(textype) { >> + case GL_TEXTURE_2D: tex = "2D"; break; >> + case GL_TEXTURE_RECTANGLE_ARB: tex = "RECT"; break; >> + default: >> + FIXME("Implement nv12 correction for non-2d, non-rect textures\n"); >> + return FALSE; >> + } > Regarding the code style please use the style found in > dlls/wined3d/cs.c. We're migrating the code style of wined3d to this > style, but since style-only changes are frowned upon we're doing this > as we go. I'm sorry for the mess :-( Ok, I've tried to make the newly added code match this as well as possible. // Martin

Feb. 11, 2014

Re: [PATCH 2/2] draw: Return the D3D identifier when GetDeviceIdentifier is called with no flags.

by Henri Verbeet

On 11 February 2014 06:54, Erich E. Hoover <erich.e.hoover(a)gmail.com> wrote: > + memset(&adapter_id, 0x0, sizeof(adapter_id)); > + adapter_id.driver = DriverName; > + adapter_id.driver_size = sizeof(DriverName); > + adapter_id.description = DriverDescription; > + adapter_id.description_size = sizeof(DriverDescription); I think you can just write that as: + adapter_id.driver = DDDI->szDriver; + adapter_id.driver_size = sizeof(DDDI->szDriver); + adapter_id.description = DDDI->szDescription; + adapter_id.description_size = sizeof(DDDI->szDescription); + adapter_id.device_name_size = 0; > + /* check how strings are copied into the structure */ > + ok(pdddi2->szDriver[MAX_DDDEVICEID_STRING - 1]==0, "szDriver not cleared\n"); > + ok(pdddi2->szDescription[MAX_DDDEVICEID_STRING - 1]==0, "szDescription not cleared\n"); I don't think there anything in the code that guarantees this.

Feb. 11, 2014

Re: [2/2] shell32: Supply a module name to CreateProcess

by Dmitry Timoshkov

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > --- a/dlls/shell32/shlexec.c > +++ b/dlls/shell32/shlexec.c > @@ -315,6 +315,8 @@ static UINT_PTR SHELL_ExecuteW(const WCHAR *lpCmd, WCHAR *env, BOOL shWait, > WCHAR curdir[MAX_PATH]; > DWORD dwCreationFlags; > const WCHAR *lpDirectory = NULL; > + WCHAR module_path[MAX_PATH] {0}; Does this really compile? -- Dmitry.

Feb. 11, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Vincent Povirk

> A potential other option..two fields: > First known buggy version: > Last tested version: > > (not necessarily a fan of it, just brainstorming) I don't think there's a need for a compromise that makes it even more complicated. If we're not going to change the policy, making the version field write-once for most users is fine for enforcing it imo, and as long as we have the original reported version I don't think it's worth adding a field for the last tested one.

Feb. 11, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Austin English

On Mon, Feb 10, 2014 at 9:35 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Vincent Povirk <madewokherd(a)gmail.com> wrote: > > > > Probably, but it saves quite a bit of time and hair for a tester and > > > avoids inspecting the whole bug history and all the comments to find > out > > > an exact version that an original reporter had used. There are bug > reports > > > where somebody comes and says "The bug is back!", so in order to test > whether > > > this is a regression or the bug was never fixed one needs to test using > > > an original Wine version. > > > > In a situation like that you should be inspecting the comments anyway. > > The only difference if we change the version field is that you have to > > open the bug history, search for Version, and read the first entry to > > find out what the original reported version was (if that first entry > > is wrong, there will be a comment explaining what it actually is and > > why). > > For instance the Regression SHA1 field was introduced exactly to avoid > searching through all the comments and filtering the wrong ones. > > > And inspecting the comments will be faster because they won't be > > cluttered with "still present in x.y.z". > > I wouldn't be so sure about both of these statements :). > > -- > Dmitry. > A potential other option..two fields: First known buggy version: Last tested version: (not necessarily a fan of it, just brainstorming) -- -Austin

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > Probably, but it saves quite a bit of time and hair for a tester and > > avoids inspecting the whole bug history and all the comments to find out > > an exact version that an original reporter had used. There are bug reports > > where somebody comes and says "The bug is back!", so in order to test whether > > this is a regression or the bug was never fixed one needs to test using > > an original Wine version. > > In a situation like that you should be inspecting the comments anyway. > The only difference if we change the version field is that you have to > open the bug history, search for Version, and read the first entry to > find out what the original reported version was (if that first entry > is wrong, there will be a comment explaining what it actually is and > why). For instance the Regression SHA1 field was introduced exactly to avoid searching through all the comments and filtering the wrong ones. > And inspecting the comments will be faster because they won't be > cluttered with "still present in x.y.z". I wouldn't be so sure about both of these statements :). -- Dmitry.

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Vincent Povirk

> Probably, but it saves quite a bit of time and hair for a tester and > avoids inspecting the whole bug history and all the comments to find out > an exact version that an original reporter had used. There are bug reports > where somebody comes and says "The bug is back!", so in order to test whether > this is a regression or the bug was never fixed one needs to test using > an original Wine version. In a situation like that you should be inspecting the comments anyway. The only difference if we change the version field is that you have to open the bug history, search for Version, and read the first entry to find out what the original reported version was (if that first entry is wrong, there will be a comment explaining what it actually is and why). And inspecting the comments will be faster because they won't be cluttered with "still present in x.y.z".

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Dmitry Timoshkov

Austin English <austinenglish(a)gmail.com> wrote: > > > > The original version is useful to test the original bug, it may be the > > > > difference between resolving it as FIXED (was able to reproduce and no > > > > longer happens) or WORKSFORME (could not reproduce in the reported > > > > version and nowadays). > > > > > > Why is the original version better for this purpose than a later > > > version that was tested and known to be affected by the bug? > > > > It's always better to test using exact version that the user had in order > > to avoid any side effects of patches applied after that point, possible > > another regression, something else that may happen after that (like > > introducing new compiler optimization in default flags, changed config.h > > dependency, added/removed MS_HOOK/WINAPI/CDECL thing, etc.,etc.) > > > > Testing using a later Wine version may reproduce something that looks > > like an original bug but be not the same thing in reality. > > > > -- > > Dmitry > > > > I think the number of cases where this would matter is trivial (compared to > the overall problem of what the version field means/keeping that value > meaningful). Probably, but it saves quite a bit of time and hair for a tester and avoids inspecting the whole bug history and all the comments to find out an exact version that an original reporter had used. There are bug reports where somebody comes and says "The bug is back!", so in order to test whether this is a regression or the bug was never fixed one needs to test using an original Wine version. -- Dmitry.

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Austin English

On Mon, Feb 10, 2014 at 4:40 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Vincent Povirk <madewokherd(a)gmail.com> wrote: > > > > The original version is useful to test the original bug, it may be the > > > difference between resolving it as FIXED (was able to reproduce and no > > > longer happens) or WORKSFORME (could not reproduce in the reported > > > version and nowadays). > > > > Why is the original version better for this purpose than a later > > version that was tested and known to be affected by the bug? > > It's always better to test using exact version that the user had in order > to avoid any side effects of patches applied after that point, possible > another regression, something else that may happen after that (like > introducing new compiler optimization in default flags, changed config.h > dependency, added/removed MS_HOOK/WINAPI/CDECL thing, etc.,etc.) > > Testing using a later Wine version may reproduce something that looks > like an original bug but be not the same thing in reality. > > -- > Dmitry > I think the number of cases where this would matter is trivial (compared to the overall problem of what the version field means/keeping that value meaningful). -- -Austin

Feb. 10, 2014

Re: Rename "Version" field to "Earliest Affected Version" in Bugzilla?

by Dmitry Timoshkov

Vincent Povirk <madewokherd(a)gmail.com> wrote: > > The original version is useful to test the original bug, it may be the > > difference between resolving it as FIXED (was able to reproduce and no > > longer happens) or WORKSFORME (could not reproduce in the reported > > version and nowadays). > > Why is the original version better for this purpose than a later > version that was tested and known to be affected by the bug? It's always better to test using exact version that the user had in order to avoid any side effects of patches applied after that point, possible another regression, something else that may happen after that (like introducing new compiler optimization in default flags, changed config.h dependency, added/removed MS_HOOK/WINAPI/CDECL thing, etc.,etc.) Testing using a later Wine version may reproduce something that looks like an original bug but be not the same thing in reality. -- Dmitry.

Feb. 10, 2014