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

Re: bcrypt: Add semi-stub implementation of BCryptGenRandom (try 2)

by Alexandre Julliard

Bruno Jesus <00cpxxx(a)gmail.com> writes: > + > + /* Zero sized buffer should work too */ > + ret = pBCryptGenRandom(NULL, buffer, 0, BCRYPT_USE_SYSTEM_PREFERRED_RNG); > + ok(ret == STATUS_SUCCESS, "Expected success, got 0x%x\n", ret); > + > + /* Test random number generation - It's impossible for a sane RNG to return 8 zeros */ > + rnd[0] = 0; > + rnd[1] = 0; > + ret = pBCryptGenRandom(NULL, buffer, sizeof(DWORD) * 2, BCRYPT_USE_SYSTEM_PREFERRED_RNG); > + ok(ret == STATUS_SUCCESS, "Expected success, got 0x%x\n", ret); > + ok(rnd[0] || rnd[1], "Expected a random number, got 0\n"); > + trace("BCryptGenRandom : %08X%08X\n", rnd[0], rnd[1]); There's no reason to work with DWORDs, the function returns bytes, just use that directly. -- Alexandre Julliard julliard(a)winehq.org

Feb. 10, 2014

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

by Dmitry Timoshkov

Andrew Eikum <aeikum(a)codeweavers.com> wrote: > > Jerome Leclanche <adys.wh(a)gmail.com> wrote: > > > What is the reasoning behind that, really? What is the point of having > > > a version field that tells the developers absolutely nothing? > > > > One need to be a developer to comment on this I'd guess, but telling an > > exact used Wine version in the bug report is already a very good start. > > > > I don't know. As a developer, I've never used that field for anything, > and I find the "user changed version, admin changed it back" dance to > be a distraction in my Bugs mailbox. Just add a e-mail filter? > I'd be fine if we just eliminated the field entirely. You probably don't follow bugzilla close enough if the version field is not important to you. Quite often precise Wine version could be a sign of a known bug/fix/regression. -- Dmitry.

Feb. 10, 2014

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

by Andrew Eikum

On Mon, Feb 10, 2014 at 04:28:48PM +0900, Dmitry Timoshkov wrote: > Jerome Leclanche <adys.wh(a)gmail.com> wrote: > > What is the reasoning behind that, really? What is the point of having > > a version field that tells the developers absolutely nothing? > > One need to be a developer to comment on this I'd guess, but telling an > exact used Wine version in the bug report is already a very good start. > I don't know. As a developer, I've never used that field for anything, and I find the "user changed version, admin changed it back" dance to be a distraction in my Bugs mailbox. I'd be fine if we just eliminated the field entirely. Andrew

Feb. 10, 2014

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

by Rosanne DiMesio

> > Reports for too old versions could be avoided by not listing old versions > at all, and telling a user that if he/she can't find his/her version in > the list to upgrade. > > -- The AppDB already does that, so I can tell you from experience that users who cannot find their version on the list will simply choose one arbitrarily and then explain in a comment that they are really using version x, but it wasn't on the list. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Feb. 10, 2014

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

by Stefan Dösinger

-----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. 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. > @@ -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 :-\ . > + 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 :-( -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+MA3AAoJEN0/YqbEcdMw434P/36l/R7vl7k3mx24+cYw1mll DOqx4yov+V+I3ERFbQjWmzwvAKoxFbo2+Qn7AaEAegGk1x5G3cuw4jZmo+C4bUb0 uvePY9WbvZptGFdavLAEgYWaBtY6M9pNJkp1PuIehqeq9D3XP98AUH4awzWFbfcD /dQQGVow1D8hkp57iATzUpEwDZBGttAePxyYR/gj7r1FnqPpVD0NW/zWoLJBWMrq 4YQSZBmJQK3xq5mcVlajNUg0Ylh82fp0bzxCie8Zw1jNuahmbGEAaht87fzxWCMc DgdcCS19aZEa39kNT/0ft/vybIPNyHVA+Mon+JgYmEVQRxhJMCl6gYbEKYCWcs0f OZc6d5B8Z4PX9FiPTnofs49SRq2+Gh6YggJdjToY2YZ2iOGgD4A87EIj2iZQc+6w 9jz2SLIZPl4zrjBY5Ji31qyKy8c+emOO9KC1OdnkFPo6eUeIussjrCfX7r2mNyRs 2qNHLz2yrd8aG0+swYvHocZ/wnUeOtgaTYJef8BTEut0+iBsDJ/eQom1/84orhxJ oHmdTbfepXMEoQvhkMSu79gZBMnwvFERZngzOPjKuw0KS3XM+KIFOy1nFeVAMGvb AoVa39jkByIcF0tN6vuf12LdWtdMqkwKeNuF36iEwVAgzkr8pAU6xHL5QqY1QhuB zsCB0PSX3QSmNC/4s7k8 =r3du -----END PGP SIGNATURE-----

Feb. 10, 2014

Re: configure: Avoid nesting cat calls.

by Alexandre Julliard

Nicolas Le Cam <niko.lecam(a)gmail.com> writes: > @@ -3453,9 +3453,7 @@ fi > AC_CONFIG_COMMANDS([Makefile], [wine_fn_output_makefile Makefile], > [wine_fn_output_makefile () > { > - cat Make.tmp - <<\_WINE_EOF >\$tmp/makefile && mv -f \$tmp/makefile \$[]1 && rm -f Make.tmp && return > -`cat $wine_rules_file` > -_WINE_EOF > + cat Make.tmp $wine_rules_file >\$tmp/makefile && mv -f \$tmp/makefile \$[]1 && rm -f Make.tmp && return This doesn't do the same thing at all, it can't possibly work. -- Alexandre Julliard julliard(a)winehq.org

Feb. 10, 2014

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

by Dmitry Timoshkov

Jerome Leclanche <adys.wh(a)gmail.com> wrote: > > Reports for too old versions could be avoided by not listing old versions > > at all, and telling a user that if he/she can't find his/her version in > > the list to upgrade. > > I'd be in favour of dropping old versions, unfortunately I believe > this involves thousands of existing bugs losing their current version > field. Not listing old Wine versions at the bug reporting time and actually removing those versions from bugzilla altogether are two separate things. -- Dmitry.

Feb. 10, 2014

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

by Michael Stefaniuc

On 02/10/2014 08:47 AM, Jerome Leclanche wrote: > On Mon, Feb 10, 2014 at 7:28 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: >> >> Reports for too old versions could be avoided by not listing old versions >> at all, and telling a user that if he/she can't find his/her version in >> the list to upgrade. > > I'd be in favour of dropping old versions, unfortunately I believe > this involves thousands of existing bugs losing their current version > field. The best solution would be to keep the old versions but filter them out from the drop down that is presented to the users. > Then again, I hate bugzilla and the new bug page is a UX disaster. The > minuscule scroll areas for component/version, the attachment size > limit which gives no warning at that point (and simply disappears once > the bug is filed)... > While we're talking about changes to the new bug UI, I'd like to > suggest dropping Component from there altogether and put it in > advanced fields (if editable by users at all - you need a pretty deep > understanding of wine/windows APIs to pick one). The Component field is useful though I would prefer if we could drop the "directx-" prefix from the components that have it. The "Comp" field in the bug listings is too short and shows only "directx-". bye michael

Feb. 10, 2014

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

by Frédéric Delanoy

On Mon, Feb 10, 2014 at 3:10 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Feb 9, 2014, at 8:00 PM, Dmitry Timoshkov wrote: > >> Version field should be never changed and left at the original version >> that the user had reported the problem for. There is no point in changing >> it to an earlier or a later one IMHO. > > Well, if that's the consensus that develops, then perhaps we could either: a) rename it to Originally Reported Version, or b) disable editing that field by non-admin users. (We might also disable non-admin users from setting or editing the Severity field, too.) (b) would be best IMO. BTW the Version field explanation can be found when hovering the "Version" field in bug creation form ("The version field defines the version of the software the bug was found in"). That sentence seems clear enough, although one could maybe replace "software" by "Wine". -- Frédéric Delanoy

Feb. 10, 2014

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

by Jerome Leclanche

On Mon, Feb 10, 2014 at 7:28 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > Reports for too old versions could be avoided by not listing old versions > at all, and telling a user that if he/she can't find his/her version in > the list to upgrade. I'd be in favour of dropping old versions, unfortunately I believe this involves thousands of existing bugs losing their current version field. Then again, I hate bugzilla and the new bug page is a UX disaster. The minuscule scroll areas for component/version, the attachment size limit which gives no warning at that point (and simply disappears once the bug is filed)... While we're talking about changes to the new bug UI, I'd like to suggest dropping Component from there altogether and put it in advanced fields (if editable by users at all - you need a pretty deep understanding of wine/windows APIs to pick one). J. Leclanche

Feb. 10, 2014