wine-devel December 2015

wine-devel@winehq.org

50 participants
169 discussions

Re: user32/tests: Use 'start' and 'end' variables in test comparisons
by Dmitry Timoshkov 17 Dec '15

17 Dec '15

Hugh McMaster <hugh.mcmaster(a)outlook.com> wrote: > - INT start,end; > + unsigned short start, end; This can't work. -- Dmitry.

2 4

Re: user32: Select/deselect edit field text when a combo box gets/loses focus
by Dmitry Timoshkov 17 Dec '15

17 Dec '15

Hugh McMaster <hugh.mcmaster(a)outlook.com> wrote: > --- a/dlls/user32/combo.c > +++ b/dlls/user32/combo.c > @@ -1215,7 +1215,7 @@ static LRESULT COMBO_Command( LPHEADCOMBO lphc, WPARAM wParam, HWND hWnd ) > case (EN_SETFOCUS >> 8): > > TRACE("[%p]: edit [%p] got focus\n", lphc->self, lphc->hWndEdit ); > - > + SendMessageW( lphc->hWndEdit, EM_SETSEL, 0, -1 ); > COMBO_SetFocus( lphc ); > break; > > @@ -1228,7 +1228,7 @@ static LRESULT COMBO_Command( LPHEADCOMBO lphc, WPARAM wParam, HWND hWnd ) > * notification (only when it happens to be a part of > * the combo). ?? - AK. > */ > - > + SendMessageW( lphc->hWndEdit, EM_SETSEL, -1, 0 ); > COMBO_KillFocus( lphc ); > break; These changes require tests to confirm their correctness, and the tests need to cover the cases when a control is part of a dialog and when it's not. -- Dmitry.

2 2

Re: [PATCH 2/2] user32/tests: Add tests for WM_DEVICECHANGE message. (try 2)
by Marvin 17 Dec '15

17 Dec '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=19005 Your paranoid android. === w1064 (32 bit msg) === msg.c:6139: Test failed: Update region shouldn't be empty msg.c:6373: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6375: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6145: Test failed: Regions are different msg.c:6145: Test failed: Regions are different msg.c:6145: Test failed: Regions are different === w1064 (64 bit msg) === msg.c:4644: Test failed: ShowWindow(SW_RESTORE):overlapped: 18: the msg sequence is not complete: expected 0000 - actual 001a

1 0

Re: [PATCH 2/2] user32/tests: Add tests for WM_DEVICECHANGE message.
by Marvin 17 Dec '15

17 Dec '15

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=19004 Your paranoid android. === w1064 (32 bit msg) === msg.c:6135: Test failed: Update region shouldn't be empty msg.c:6369: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6371: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6141: Test failed: Regions are different msg.c:6141: Test failed: Regions are different msg.c:6141: Test failed: Regions are different

1 0

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture.
by Stefan Dösinger 16 Dec '15

16 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Cool to see that you're still working on this :-) . Am 2015-12-15 um 16:41 schrieb Aaryaman Vasishta: > + * Copyright 2015 Aaryaman Vasishta I think you can make this 2014-2015. > +static char *create_testbitmap(const char *filename, LPCSTR resource) LPCSTR -> const char * is better IMO. > +{ > + static char path[MAX_PATH]; > + DWORD written; > + HANDLE file; > + HRSRC res; > + void *ptr; > + > + GetTempPathA(sizeof(path)/sizeof(WCHAR), path); Why sizeof(WCHAR)? > + lstrcatA(path, filename); > + > + file = CreateFileA(path, GENERIC_READ|GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0); > + ok(file != INVALID_HANDLE_VALUE, "file creation failed, at %s, error %d\n", path, > + GetLastError()); > + > + res = FindResourceA(GetModuleHandleA(NULL), resource, (LPCSTR)RT_RCDATA); const char * > + ok( res != 0, "couldn't find resource\n" ); > + ptr = LockResource( LoadResource( GetModuleHandleA(NULL), res )); > + WriteFile( file, ptr, SizeofResource( GetModuleHandleA(NULL), res ), &written, NULL ); > + ok( written == SizeofResource( GetModuleHandleA(NULL), res ), "couldn't write resource\n" ); > + CloseHandle( file ); You have inconsistent style here. ok(foo, "bar\n"); vs ok( foo, "bar\n" ); > +static BOOL test_bitmap_data1(unsigned char *buffer1, unsigned char *buffer2, D3DRMIMAGE *img, int w, int h, int depth) afaics you can make buffer1 and buffer2 const, probably applies to img as well. > + if (img->palette) > + { > + if (depth == 8) > + { > + for (i = 0; i < size; i++) > + { > + if (buffer1[i] != buffer2[i]) > + return FALSE; > + } > + } > + else > + { > + /* d3drm aligns the 24bpp texture to 4 bytes in the buffer, with one bype padding from 24bpp texture. */ > + /* The image is palettized if the total number of colors used is < 256. */ Does this ever happen? A palettized image with != 8 bpp? > + for (i = 0, j = 0; i < w * h; i += 3, j++) > + { > + val1 = img->palette[buffer1[j]].blue == buffer2[i]; > + val2 = img->palette[buffer1[j]].green == buffer2[i + 1]; > + val3 = img->palette[buffer1[j]].red == buffer2[i + 2]; > + if (!(val1 && val2 && val3)) > + return FALSE; > + } > + } Your indentation is wrong here. > + for (i = 0, j = 0; i < w * h; i += 4, j += 3) > + { > + val1 = buffer1[i] == buffer2[j]; > + val2 = buffer1[i + 1] == buffer2[j + 1]; > + val3 = buffer1[i + 2] == buffer2[j + 2]; > + if (!(val1 && val2 && val3)) > + return FALSE; > + } I think you're supposed to use img->bytes_per_line to advance from one line to another. See e.g. how lPitch is handled in ddraw tests. > +static void test_load_texture1(void) > +{ > + HRESULT hr; > + IDirect3DRM *d3drm1 = NULL; > + IDirect3DRMTexture *texture1 = NULL; > + D3DRMIMAGE *d3drm_img = NULL; > + HWND window; > + HBITMAP hbm = NULL; > + BITMAP bm; > + BITMAPFILEHEADER *bmp_header = NULL; > + BITMAPINFO *bmp_info = NULL; > + HANDLE hfile, hmapping = NULL; > + BOOL check; > + DWORD size; > + char *file = NULL; > + unsigned char *buffer = NULL, *buffer1 = NULL, *buffer2 = NULL; > + HDC mem_dc = NULL; > + > + window = CreateWindowA("static", "d3drm_test", WS_OVERLAPPEDWINDOW, 0, 0, 300, 200, 0, 0, 0, 0); > + file = create_testbitmap("8bpp.bmp", (LPCSTR)MAKEINTRESOURCE(IDD_BITMAPDATA_8BPP)); > + > + hbm = LoadImageA(NULL, file, IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE); > + ok(hbm != NULL, "Cannot load image %s (error = %x).\n", file, GetLastError()); > + > + mem_dc = CreateCompatibleDC(NULL); > + ok(mem_dc != NULL, "Cannot create memory device context.\n"); > + > + SelectObject(mem_dc, hbm); > + GetObjectA(hbm, sizeof(bm), &bm); > + > + > + /* Test if image information matches that from the header by loading the bitmap seperately. */ Two newlines. > + hfile = CreateFileA(file, GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0); > + ok(file != INVALID_HANDLE_VALUE, "Failed to open file at %s, error %d\n", file, > + GetLastError()); > + if (hfile == INVALID_HANDLE_VALUE) > + goto cleanup; > + > + size = GetFileSize(hfile, NULL); > + ok(size != INVALID_FILE_SIZE, "Failed to get file size, error %d\n", GetLastError()); > + if (size == INVALID_FILE_SIZE) > + goto cleanup; > + > + hmapping = CreateFileMappingA(hfile, NULL, PAGE_READONLY, 0, 0, NULL); > + ok(hmapping != NULL, "Cannot create file mapping (error = %x).\n", GetLastError()); > + if (hmapping == NULL) > + goto cleanup; > + > + buffer = MapViewOfFile(hmapping, FILE_MAP_READ, 0, 0, 0); > + ok(buffer != NULL, "Cannot create map view of file (error = %x).\n", GetLastError()); > + if (buffer == NULL) > + goto cleanup; > + > + bmp_header = (BITMAPFILEHEADER *)buffer; > + bmp_info = (BITMAPINFO *)((unsigned char *)buffer + sizeof(BITMAPFILEHEADER)); > + buffer1 = ((unsigned char *)buffer + bmp_header->bfOffBits); This seems a bit unelegant to me, but I don't have a better solution available right now. I guess something along the lines of copying the image into a DIB section with BitBlt may work. > + hr = Direct3DRMCreate(&d3drm1); > + ok(hr == D3DRM_OK, "Cannot get IDirect3DRM interface (hr = %x)\n", hr); > + > + hr = IDirect3DRM_LoadTexture(d3drm1, file, &texture1); > + ok(SUCCEEDED(hr), "Failed to load texture (hr = %x).\n", hr); > + d3drm_img = IDirect3DRMTexture_GetImage(texture1); > + todo_wine ok(d3drm_img != NULL, "Could not get a D3DRMIMAGE struct from texture.\n"); > + if (d3drm_img == NULL) > + goto cleanup; > + ok(bmp_info->bmiHeader.biWidth == d3drm_img->width, "Expected texture width == %d, got %d.\n", bmp_info->bmiHeader.biWidth, d3drm_img->width); > + ok(bmp_info->bmiHeader.biHeight == d3drm_img->height, "Expected texture height == %d, got %d.\n", bmp_info->bmiHeader.biHeight, d3drm_img->height); > + buffer2 = (unsigned char *)d3drm_img->buffer1; > + check = test_bitmap_data1(buffer2, buffer1, d3drm_img, bm.bmWidth, bm.bmHeight, bmp_info->bmiHeader.biBitCount); > + ok(check, "Buffer contents do not match that of bitmap.\n"); > + > +cleanup: > + UnmapViewOfFile(buffer); > + CloseHandle(hmapping); > + CloseHandle(hfile); > + DeleteDC(mem_dc); > + DeleteObject(hbm); > + IDirect3DRMTexture_Release(texture1); > + IDirect3DRM_Release(d3drm1); > + check = DeleteFileA(file); > + ok(check, "Cannot delete image stored in %s (error = %x).\n", file, GetLastError()); > + DestroyWindow(window); > +} > + > +static BOOL test_bitmap_data2(unsigned char *buffer1, unsigned char *buffer2, D3DRMIMAGE *img, int w, int h, int depth) If I understand it right and remember it properly from our chat, the difference is that version 2 is upside down. I think that can be handled via a parameter and without duplicating the function. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWcIZjAAoJEN0/YqbEcdMw2ZcP/3h4HmIjK2ENd0nhkj4Zae34 XgMQe9gXTRtdmsjIHgcFRDwIfxbjA0XX5CazCFAsL0cz58zzNtMUuugXBeraDzeR 7CTUNPdivsHzVm3V8hRjCDWuGSGZmVHiBNJE2OL0GKVdzYOmRWC3FOMy5ICD/ZdR GDrut5zr59vTieRZieov0Mx3jfAtWkeHLU/MVEFFljCBcUVRj1FIvClrGZDXk3Xn DW82LQrv8QXRtPh8ruLySFgeBDG0iTZ+4N6iIJwWPvd6qbg5Ku0MQOx3K8VsnQi8 7OlcQ8wzIvX8QxXsu1zBQwVNbJBQCup3zC8rqeqg27EoEYPZvQLwIAL/U7xd83Ul s8tFatOV9WD/sBmSa4XY4A1hMkgDqyhNIWrcOd6mm4hUaAbLac60NwNG6cAPtj0w fxlhIegqJ9B7Cs7xhGjFtsO5TqIeLUd0f5k6IWsgEAKv4KVz6pVYKGlrB5PM9jLw Xv8b3usjk9c3eoB5KExb/VhU6ea+sacc6XBGkEJEyu2b5r4gFNfrBRrxvOzKHJ1x xkvle6mmHSn3lxZXmvuEKHZBZPvRNDszvLX4BCuGPRRCpU4JNLY3/aF1kXpX3ks1 RwHYJU/ufJgDvLtYRnBeQOjK4cNdkZyhbH0lrkkcBig38F4xPcjjym+jdPro0X1N voYrN8i/7cKq/ASKNWAD =3KSr -----END PGP SIGNATURE-----

2 1

Re: [PATCH] d3drm/tests: Add tests for IDirect3DRM*::LoadTexture.
by Henri Verbeet 16 Dec '15

16 Dec '15

On 15 December 2015 at 17:41, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > dlls/d3drm/tests/24bpp.bmp | Bin 0 -> 195894 bytes > dlls/d3drm/tests/8bpp.bmp | Bin 0 -> 2142 bytes > dlls/d3drm/tests/Makefile.in | 4 +- > dlls/d3drm/tests/d3drm.c | 400 +++++++++++++++++++++++++++++++++++++++++++ > dlls/d3drm/tests/d3drmrs.rc | 28 +++ > dlls/d3drm/tests/palette.bmp | Bin 0 -> 30054 bytes > dlls/d3drm/tests/resources.h | 26 +++ > 7 files changed, 457 insertions(+), 1 deletion(-) > create mode 100644 dlls/d3drm/tests/24bpp.bmp > create mode 100644 dlls/d3drm/tests/8bpp.bmp > create mode 100644 dlls/d3drm/tests/d3drmrs.rc > create mode 100644 dlls/d3drm/tests/palette.bmp > create mode 100644 dlls/d3drm/tests/resources.h > I suppose I'm missing something subtle, but these bitmaps look like it would take considerably less bytes to just generate them in the test.

2 1

Re: [PATCH 2/5] wined3d: Limit the number of multisample levels reported by wined3d_check_device_multisample_type().
by Henri Verbeet 15 Dec '15

15 Dec '15

On 14 December 2015 at 23:37, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -4426,7 +4428,7 @@ HRESULT CDECL wined3d_check_device_multisample_type(const struct wined3d *wined3 > if (quality_levels) > { > if (multisample_type == WINED3D_MULTISAMPLE_NON_MASKABLE) > - *quality_levels = gl_info->limits.samples; > + *quality_levels = wined3d_log2i(gl_info->limits.samples); > else > *quality_levels = 1; > } I'm not sure this really makes sense. It may make sense to limit the number of non-maskable quality levels to 8, similar to how we limit e.g. shader constants and render targets for d3d9, although that would need a test and a comment. I don't see how you can justify the wined3d_log2i(). As an aside, note that we don't actually support maskable multi-sampling and would need ARB_texture_multisample for that, although applications don't seem to do a lot of masking in practice. D3d10+ only has maskable multi-sampling.

2 2

Re: [PATCH 2/2] d3dx9_36: Make DDS header the same as native. (try 5)
by Matteo Bruni 15 Dec '15

15 Dec '15

2015-12-15 9:13 GMT+01:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > From: Christian Costa <titan.costa(a)gmail.com> > > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> The subject isn't quite right given that the caps field is still different from native. Something like "d3dx9: Improve generated DDS file header." would be better. Again, just deferring until the release, looks good enough otherwise.

1 0

Re: [PATCH 1/2] d3dx9_36/tests: Add D3DXSaveSurfaceToFileInMemory D3DXIFF_DDS tests (try 5)
by Matteo Bruni 15 Dec '15

15 Dec '15

2015-12-15 9:13 GMT+01:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: With the summary changed to "d3dx9/tests: Add D3DXSaveSurfaceToFileInMemory DDS header tests." or something like that this would be fine to me. Not signing off just because of the code freeze, please resend after the 1.8 release.

1 0

Re: Fwd: Patch for https://bugs.winehq.org/show_bug.cgi?id=39759 (Add support for Nvidia GTX TITAN Black card)
by Nikolay Sivov 15 Dec '15

15 Dec '15

On 15.12.2015 20:23, SpinFlo wrote: > Hi > > As said in https://bugs.winehq.org/show_bug.cgi?id=39759#c5 > > here a patch to add Support for Nvidia GTX TITAN Black card in wine, > this patch include 3 modifications: > > - Add the info for Nividia GTX TITAN Black card > - Remove a ',' in a Vram column in NVIDIA GeForce4 Ti 4200 (none of > all cards have this ',', then, i think is a typo) > - Add some spaces between columns, because the string > 'CARD_NVIDIA_GEFORCE_GTXTITANBLACK},' is too long and breaks the > look&feel code. some other intel cards have a similar problem in their > descriptions, then apply spaces un all cards to keep the equality > I can't speak for the maintainer, but it looks easier to use a shorter name than rearranging everything. > Greetings >

2 1

← Newer
1
...
8
9
10
11
12
13
14
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel December 2015