wine-devel April 2010

wine-devel@winehq.org

111 participants
263 discussions

Re: [3/3] d3dx9: Add source register modifiers (sm 2+) support to the shader assembler.
by Greg Geldorp 08 Apr '10

08 Apr '10

Hi Matteo, This causes the test to crash on Vista and Windows 2008, see http://winetestbot.geldorp.nl/JobDetails.pl?Key=1315 Ge.

1 0

Re: [PATCH 3/4] wined3d: Start moving texture format fixups to the formats table.
by Henri Verbeet 08 Apr '10

08 Apr '10

On 7 April 2010 23:12, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > @@ -236,9 +236,55 @@ struct wined3d_format_texture_info > GLint gl_format; > GLint gl_type; > unsigned int flags; > + unsigned int conv_byte_count; > GL_SupportedExt extension; > + void (*convert)(const BYTE *src, BYTE *dst, UINT pitch, UINT width, UINT height); > }; > ... > - GL_LUMINANCE_ALPHA, GL_UNSIGNED_BYTE, > + GL_LUMINANCE_ALPHA, GL_UNSIGNED_BYTE, 0, > WINED3DFMT_FLAG_FILTERING, > - WINED3D_GL_EXT_NONE}, > + WINED3D_GL_EXT_NONE, NULL}, Did you test this patch much?

2 1

Re: [PATCH 2/4] wined3d: Let d3dfmt_get_conv return a wined3d_format_desc. This required some code shuffling mostly in the SRGB area.
by Henri Verbeet 08 Apr '10

08 Apr '10

On 7 April 2010 23:12, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > --- > dlls/wined3d/device.c | 5 +- > dlls/wined3d/surface.c | 169 +++++++++++++++++++++++----------------- > dlls/wined3d/utils.c | 1 + > dlls/wined3d/wined3d_private.h | 5 +- > 4 files changed, 102 insertions(+), 78 deletions(-) > I'm not so convinced by the idea of having mutable format descriptions. What problem are you solving, and why is this the best solution? At the very least the patch looks like it could be split though.

2 1

Re: [PATCH 4/4] wined3d: Add an initial fbo_blit implementation.
by Henri Verbeet 08 Apr '10

08 Apr '10

I don't think so. Looking at cpu_blit, that "blitter" has exactly a single function that's actually used, and it might as well have been a function on its own. I've twice pointed out how to avoid that situation, but for some reason you ignored that. In the case of cpu_blit I went along with that in the assumption that later patches would fix it, but I'm not having another implementation like that.

1 0

Direct3D testing project (GSoC)
by Conrad Buck 08 Apr '10

08 Apr '10

Hello devels, I'm looking at submitting a SoC proposal to the wine project, but I'm feeling a little overwhelmed as my current coding experience is all over the place, and very little of it working with existing projects. My most recent work has been looking low-level code and algorithms behind basic OpenGL, so I thought perhaps I might be able to make relevant contributions to the project of testing and improving Direct3D support. Can anyone that knows more about whats under the hood for that sort of functionality in wine tell me what kind of magnitude of project I might be looking at? Only a limited number of bug reports have been filed, but all seem to be indicative of fairly major issues. Once I get more of an idea of what I might be dealing with (and examine some of the problems myself) I can fine-tune my proposal. Thanks, Conrad

2 1

Re: winebrowser: Fix obtaining of the ASCII strings through the DDE
by Dmitry Timoshkov 08 Apr '10

08 Apr '10

Ilya Shpigor <shpigor(a)etersoft.ru> wrote: [skipped] If it could be that easy this would be fixed already. There is a bug in bugzilla with the details about this problem. -- Dmitry.

1 0

Re: [PATCH] [Server]: correctly set the DR0..7 registers on Linux for x86_64 architecture
by Dmitry Timoshkov 08 Apr '10

08 Apr '10

Eric Pouech <eric.pouech(a)orange.fr> wrote: > + case CPU_x86_64: > + context->debug.x86_64_regs.dr0 = data[0]; > + context->debug.x86_64_regs.dr1 = data[1]; > + context->debug.x86_64_regs.dr2 = data[2]; > + context->debug.x86_64_regs.dr3 = data[3]; > + context->debug.x86_64_regs.dr6 = data[6]; > + context->debug.x86_64_regs.dr7 = data[7]; > + default: > + set_error( STATUS_INVALID_PARAMETER ); > + goto done; > + } You forgot 'break'. > + case CPU_x86_64: > + if (ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(0), context->debug.x86_64_regs.dr0 ) == -1) goto error; > + if (thread->context) thread->context->debug.x86_64_regs.dr0 = context->debug.x86_64_regs.dr0; > + if (ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(1), context->debug.x86_64_regs.dr1 ) == -1) goto error; > + if (thread->context) thread->context->debug.x86_64_regs.dr1 = context->debug.x86_64_regs.dr1; > + if (ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(2), context->debug.x86_64_regs.dr2 ) == -1) goto error; > + if (thread->context) thread->context->debug.x86_64_regs.dr2 = context->debug.x86_64_regs.dr2; > + if (ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(3), context->debug.x86_64_regs.dr3 ) == -1) goto error; > + if (thread->context) thread->context->debug.x86_64_regs.dr3 = context->debug.x86_64_regs.dr3; > + if (ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(6), context->debug.x86_64_regs.dr6 ) == -1) goto error; > + if (thread->context) thread->context->debug.x86_64_regs.dr6 = context->debug.x86_64_regs.dr6; > + if (ptrace( PTRACE_POKEUSER, pid, DR_OFFSET(7), context->debug.x86_64_regs.dr7 ) == -1) goto error; > + if (thread->context) thread->context->debug.x86_64_regs.dr7 = context->debug.x86_64_regs.dr7; > + default: > + set_error( STATUS_INVALID_PARAMETER ); > + } Same here. -- Dmitry.

1 0

Re: (try2)[PATCH 3/4] d3d10: Implement ID3DEffectVariable::GetInputSignatureElementDesc().
by Henri Verbeet 07 Apr '10

07 Apr '10

2010/4/7 Rico Schüller <kgbricola(a)web.de>: > + /* Check desc for NULL, this crashes on W7/DX10 */ > + if (!desc) > + { > + WARN("This should crash on W7/DX10!\n"); > + return E_FAIL; > + } It's perfectly fine to require a parameter to be non-NULL, and just crash if it isn't. You'll get a nice backtrace, or at least an exception, which helps debugging as well. > + /* Check shader_index, this crashes on W7/DX10 */ > + if (shader_index >= This->effect->used_shader_count) > + { > + WARN("This should crash on W7/DX10!\n"); > + return E_FAIL; > + } Similar as above. In general if Windows doesn't check something, we don't either. However, it's worth noting that if we'd be writing to that index we sometimes do check those, because there's the potential for memory corruption in those cases.

1 0

Mac OS X technologies
by C.W. Betts 07 Apr '10

07 Apr '10

There is a long list of technologies in Mac OS X that could be used to improve Wine on OS X. One of them is ColorSync. ColorSync is a color management software that is HEAVILY integrated into the Mac OS. For instance, you can calibrate your monitor and when OS X starts up, it will read the color profile file and adjust the graphics card output. It will also do color correction automatically in, e.g. Preview to get the best out of an image. However, I do not know how ColorSync influences Mac OS X's X11 system. It is possible that in order to take full advantage of ColorSync, a Mac OS X native front-end will need to be developed. Another interesting Mac OS X technology is Image Capture. This technology is used by the OS to scan images from a scanner as well as import images from a camera (iPhoto). It provides a wrapper around TWAIN drivers so they can be used by applications that don't support TWAIN. This is a purely C Framework. Although a sub-framework of the Carbon Framework, the functions are available in 64-bit code. This should not be confused with the ImageCaptureKit framework, which is most likely an Objective-c wrapper around the main Image Capture framework.

1 0

Re: [PATCH 2/4] d3d10: Move the effect shader input signature into a separate struct.
by Henri Verbeet 07 Apr '10

07 Apr '10

2010/4/6 Rico Schüller <kgbricola(a)web.de>: > +struct d3d10_effect_shader_signature { That isn't going to apply. Did you edit the patch? (And please keep the formatting consistent with the existing code.)

2 2

← Newer
1
...
18
19
20
21
22
23
24
...
27
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 April 2010