March 2010 - Wine-devel - list.winehq.org

winmm/midi tests and VMware
by Paul Vriens 03 Mar '10

03 Mar '10

Hi Alexandre, Just wanted your opinion on the following: VMware Workstation officially only supports MIDI output via the synthesizer device. The problem I'm having with several of my VMware boxes (and from the looks, Francois' boxes have the same issues) is that the midi tests hang (not on all OS's btw!). There are 2 ways (I can see) to fix this issue: 1. Get rid of (or disable) the sound device on the failing boxes. This means of course far less coverage of tests. 2. There is an option in the Audio control panel to only use the default devices. This doesn't prevent the 'enumeration' from listing the failing device but we could have the tests skip 'non default' devices. The attached patch is a first attempt and does work on my XP box. I've discussed this issue already with Jörg but as said VMware says it's not supported but there is no way you can tell by looking at what the driver returns (it's a normal Creative driver not intercepted in some way by VMware AFAIK). -- Cheers, Paul.

6 22

Re: wined3d: Don't crash when opengl is not available.
by Roderick Colenbrander 03 Mar '10

03 Mar '10

In what situation does it exactly crash for you? Is it crashing because there is no libGL around? I'm not sure what the right thing to do is. Due to it our wglGetProcAddress won't function because it relies on glXGetProcAddress. Our use of wglGetProcAddress isn't correct (but it works on WINE :)) in the sense that officially an OpenGL context must be around. Perhaps I should fix this behavior in gdi32 and in wined3d. It would allow for a nicer fix than adjusting the USE_GL_FUNC macro. I'm not sure about the shader backend part of the patch (I don't know that code well), so I'm leaving that to Henri and Stefan. Roderick On Tue, Mar 2, 2010 at 5:51 PM, Kusanagi Kouichi <slash(a)ac.auone-net.jp> wrote: > Signed-off-by: Kusanagi Kouichi <slash(a)ac.auone-net.jp> > --- > dlls/wined3d/directx.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c > index 457cb85..cb64319 100644 > --- a/dlls/wined3d/directx.c > +++ b/dlls/wined3d/directx.c > @@ -4677,7 +4677,7 @@ BOOL InitAdapters(IWineD3DImpl *This) > goto nogl_adapter; > } > #else > -#define USE_GL_FUNC(pfn) pfn = (void*)pwglGetProcAddress(#pfn); > +#define USE_GL_FUNC(pfn) pfn = (void*)pwglGetProcAddress(#pfn); if (!pfn) goto nogl_adapter; > /* To bypass the opengl32 thunks load wglGetProcAddress from gdi32 (glXGetProcAddress wrapper) instead of opengl32's */ > mod_gl = GetModuleHandleA("gdi32.dll"); > #endif > @@ -4950,6 +4950,9 @@ nogl_adapter: > > initPixelFormatsNoGL(&This->adapters[0].gl_info); > > + This->adapters[0].shader_backend = &none_shader_backend; > + This->adapters[0].fragment_pipe = &ffp_fragment_pipeline; > + > This->adapter_count = 1; > return FALSE; > } > -- > 1.7.0 > > > >

5 5

GetKeyboardLayout: actual keyboard or locale-dependent?
by Joerg-Cyril.Hoehle＠t-systems.com 03 Mar '10

03 Mar '10

Hi, I believe either user32/input.c erroneously skips some tests, or the wording of the skip message is misleading. It says: input.c:897: Tests skipped: Skipping Input_blackbox test on non-US keyboard It bases its choice on GetKeyboardLayout(0) == 0x04090x0409. However, GetKeyboardLayout's value does not depend on the actual keyboard (set with setxkbmap in X11). It depends solely on the LANG (or LC_xyz) variables. For instance, on a machine running a German locale, I can switch to the US keyboard, yet the above message still appears. Conversely, with LANG=C and using the German keyboard layout again, the tests are run. The keyboard in use does not affect whether the tests are run or not, despite what the message says. BTW, I get 0 failures in all 4 combinations (and either 1 or 6 todos, depending on the skip). Now when should these tests be run? Thanks for your help, Jörg Höhle

1 0

Re: [PATCH 01/14] include: Added IHTMLPrivateWindow declaration.
by Alexandre Julliard 03 Mar '10

03 Mar '10

Jacek Caban <jacek(a)codeweavers.com> writes: > Following patch series implements changes in MSHTML needed to change > navigation in MSHTML/WebBrowser control. WebBrowser should reuse > existing document if it declares that it can handle navigation (via > another almost undocumented method that is mentioned: > http://msdn.microsoft.com/en-us/library/aa770042%28VS.85%29.aspx ). > This will allow us to support properly many more features, mainly > javascript protocol that was my main motivation to implement > it. shdocvw part will follow as soon as I will clean it up. > > --- > dlls/uuid/uuid.c | 1 + > include/Makefile.in | 1 + > include/wine/mshtml_ifaces.idl | 35 +++++++++++++++++++++++++++++++++++ I think it would be OK to define it in a public header like mshtml.idl, since it's an exported interface. Presumably it will get documented sooner or later. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: 3/2 wined3d: move palette uploading code over to blit_shader
by Henri Verbeet 03 Mar '10

03 Mar '10

On 3 March 2010 13:51, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > - HRESULT (*set_shader)(IWineD3DDevice *iface, const struct GlPixelFormatDesc *format_desc, > + HRESULT (*set_shader)(IWineD3DDevice *iface, IWineD3DSurfaceImpl *surface, > GLenum textype, UINT width, UINT height); If you're passing the surface, you don't need textype, width and height either. > +void d3dfmt_p8_init_palette(IWineD3DSurfaceImpl *This, BYTE table[256][4], BOOL colorkey); This is wined3d internal, it should be DECLSPEC_HIDDEN. > context = context_acquire(device, NULL, CTXUSAGE_RESOURCELOAD); > - d3dfmt_p8_upload_palette(iface, convert); > + IWineD3DSurface_LoadLocation(iface, SFLAG_INDRAWABLE, NULL); > context_release(context); LoadLocation() will acquire its own context. > +static void upload_palette(IWineD3DSurfaceImpl *surface) >+void d3dfmt_p8_init_palette(IWineD3DSurfaceImpl *This, BYTE table[256][4], BOOL colorkey) These require an active context, please document that in a comment. > + glBindTexture(GL_TEXTURE_1D, device->palette_texture); > + > + GL_EXTCALL(glActiveTextureARB(GL_TEXTURE1)); Is that right, binding the texture before switching to GL_TEXTURE1? Also, what happens to any previous textures bound on that unit?

1 0

Re: [PATCH 1/2] user32: Fix return value of EDIT_EM_Scroll. (try 2)
by Alexandre Julliard 03 Mar '10

03 Mar '10

David Hedberg <david.hedberg(a)gmail.com> writes: > Brings the return value in line with msdn and test results. > > This time without the skips. Return values other than 0 are somewhat > unlikely, but strictly speaking only one value is wrong (and important > for the tests here). I wouldn't expect it to ever return something other than 0 here, but even if it does there are many other possible wrong values. It's better to make the test as strict as you can to catch more potential problems, rather than limiting yourself to the specific value that you encountered. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Change Journal and VSS analog in Wine
by Michael Stefaniuc 03 Mar '10

03 Mar '10

Hello Dmitry, Dmitry Konnov wrote: > MS> what do you try to do? Porting a Windows backup software to MacOSX using > MS> Wine? > > yes. > > MS> That won't work if the intent is to backup the whole MacOSX > MS> system. The native filesystems have their peculiarities that Wine > MS> doesn't expose nor translate to the Win32 API. > > thank you Michael. so only standalone dll will help to > make software crossplatform. well I would phrase that differently: the backend that collects and restores the data from the filesystem needs to be a native application. > any links to Mac OS file system Change Log appreciated. I have no clue at all about MacOSX. bye michael

1 0

Re: [PATCH 1/2] user32: Fix return value of EDIT_EM_Scroll.
by Alexandre Julliard 03 Mar '10

03 Mar '10

David Hedberg <david.hedberg(a)gmail.com> writes: > +static void test_edit_control_scroll(void) > +{ > + static const char *single_line_str = "a"; > + HWND hwEdit; > + LONG ret; > + > + /* Check the return value when EM_SCROLL doesn't actually scroll > + * anything. Should not return true if 0 lines were scrolled. */ > + hwEdit = CreateWindow( > + "EDIT", > + single_line_str, > + WS_VSCROLL | ES_MULTILINE, > + 1, 1, 100, 100, > + NULL, NULL, hinst, NULL); > + > + assert(hwEdit); > + > + ret = SendMessage(hwEdit, EM_SCROLL, SB_PAGEDOWN, 0); > + if(LOWORD(ret)) > + skip("Scrolled lines not 0.\n"); > + else > + ok(!ret, "Returned %x, expected 0\n", ret); > + > + ret = SendMessage(hwEdit, EM_SCROLL, SB_PAGEUP, 0); > + if(LOWORD(ret)) > + skip("Scrolled lines not 0.\n"); > + else > + ok(!ret, "Returned %x, expected 0\n", ret); > + > + ret = SendMessage(hwEdit, EM_SCROLL, SB_LINEUP, 0); > + if(LOWORD(ret)) > + skip("Scrolled lines not 0.\n"); > + else > + ok(!ret, "Returned %x, expected 0\n", ret); > + > + ret = SendMessage(hwEdit, EM_SCROLL, SB_LINEDOWN, 0); > + if(LOWORD(ret)) > + skip("Scrolled lines not 0.\n"); > + else > + ok(!ret, "Returned %x, expected 0\n", ret); The skips aren't right. If you expect some other values they should be handled directly in the ok() check. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: 1/2 wined3d: prepare yuv code for 8-bit palette support
by Henri Verbeet 03 Mar '10

03 Mar '10

On 2 March 2010 20:24, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > Hi, > > This patch is the first of two patches which will start a cleanup of > the surface code which is a big mess due to the 8-bit palette code. > The 8-bit code will be moved to the blit_shader code in a way similar > as is done for YUV. This first patch renames yuv data types / > structures to 'complex', to make it more clear that the code is not > just for yuv-fixups. > I think you should rename CHANNEL_SOURCE_YUV0 and CHANNEL_SOURCE_YUV1 as well then, and possibly gen_yuv_shader().

1 0

Re: 2/2 wined3d: start cleanup of 8-bit palette code
by Henri Verbeet 03 Mar '10

03 Mar '10

On 2 March 2010 20:28, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > + idx = getFmtIdx(WINED3DFMT_P8_UINT); > + gl_info->gl_formats[idx].color_fixup = create_complex_fixup_desc(COMPLEX_FIXUP_P8); Strictly speaking this should be behind the extension check for paletted textures. Also, you have a couple of trailing spaces.

1 0