On Jun 4, 2011, at 8:02 AM, Gerald Pfeifer wrote:
> Resending: This really looks like a straightforward bug fix and the
> current code definitely wrong???
No. As others have pointed out, your logic is wrong. The existing code is
correct.
> The difference between two pointers (of the same typ
On Mon, 9 May 2011, Andrew Eikum wrote:
> Makes sense to me. Thanks. Do this patch and the float format patch
> together fix your build issues, Gerald?
The short answer is: Yes!
The long answer is that here have been three different issues around OSS
on current versions of FreeBSD where out of t
On Mon, 9 May 2011, Andrew Eikum wrote:
> Anyways this is a tiny hassle, so I'm fine with it. Perhaps you should
> consider filing a FreeBSD bug?
Sure thing, Andrew! That's sounds like a good idea (no pun intended :-).
http://www.freebsd.org/cgi/query-pr.cgi?pr=157050
Gerald
Testing 3D and Cube textures (provided they're supported) may be useful too.
On Saturday 04 June 2011 18:24:39 André Hentschel wrote:
> +case 8:
> +STRETCH_ROW(DWORD64);
> +break;
64 bit formats can be floating point formats too, like ARGB16F, or RG32F. But
Roderick's comment catch
Yup. It's being worked on, slowly;
see http://wiki.winehq.org/Performance,
especially http://wiki.winehq.org/DIBEngine
On Sat, Jun 4, 2011 at 23:50, Henri Verbeet wrote:
> Conceptually I think it makes sense to have a distinction between
> wined3d types and e.g. ddraw types. For things like D3DPOOL that's not
> strictly required since it has the same values in all d3d versions
> where it exists, but e.g. format ID
On 06/04/2011 01:32 PM, Lucas Zawacki wrote:
Sometimes apps depend on the crash. Since your change comes with a
test case, it looks reasonable to me, although you might check the
specific HRESULT rather than just FAILED.
Exactly, it's not a crash on Windows. I'll resend it with an explicit tes
2011/6/4 Frédéric Delanoy :
> BTW, there's a
> +rem warning, don't run any tests that depend on %ErrorLevel% after this line
> in your patch
>
> Is there really no way to reset ErrorLevel to a sane value?
It's more subtle than that. That section of code checks what
happens when you try to set an
2011/6/4 Dan Kegel :
> 2011/6/4 Dan Kegel :
>> https://testbot.winehq.org/JobDetails.pl?Key=11484
>> It passes on all tested platforms. Feel free to
>> submit along with your patch verbatim if it looks
>> sufficient to you.
>
> BTW it looks like cmd test suite completely ignores
> stderr, which ex
On 31 May 2011 12:50, Alexandre Julliard wrote:
> I mean using D3DPOOL in wined3d, not by including the d3d9 headers, but
> by defining it when necessary, i.e. if neither d3d8types.h nor
> d3d9types.h have been included already.
>
> This way d3d8 uses the d3d8 definition, d3d9 uses the d3d9 defini
2011/6/4 Dan Kegel :
> https://testbot.winehq.org/JobDetails.pl?Key=11484
> It passes on all tested platforms. Feel free to
> submit along with your patch verbatim if it looks
> sufficient to you.
BTW it looks like cmd test suite completely ignores
stderr, which explains why that test passes even
2011/6/4 Frédéric Delanoy :
> On Sat, Jun 4, 2011 at 19:27, Dan Kegel wrote:
>> Please add a test case, too.
>
> OK. Do I need a testbot account as well?
Yeah. The cmd test suite is touchy, so
it's worth it to use testbot to verify your
test before you send it to wine-patches.
I threw an exampl
> Sometimes apps depend on the crash. Since your change comes with a
> test case, it looks reasonable to me, although you might check the
> specific HRESULT rather than just FAILED.
Exactly, it's not a crash on Windows. I'll resend it with an explicit test.
I was thinking of this more as "janito
On Sat, Jun 4, 2011 at 19:27, Dan Kegel wrote:
> Please add a test case, too.
OK. Do I need a testbot account as well?
> I don't. I just thought that a case where Wine misbehaving causes a
> crash was worth fixing.
Sometimes apps depend on the crash. Since your change comes with a
test case, it looks reasonable to me, although you might check the
specific HRESULT rather than just FAILED.
--Juan
> Do you have an example of such application? And the bug in bugzilla?
>
I don't. I just thought that a case where Wine misbehaving causes a
crash was worth fixing.
Please add a test case, too.
Hi André,
I'm not sure if we should add this change since for a part it hides
the real problem. Sure this patch likely works, but >32bpp blits
should never enter the software rendering code in the first place. The
code used to be a huge mess and Henri cleaned it up quite a bit
already (thanks, bec
On Sat, Jun 4, 2011 at 16:51, Marcus Meissner wrote:
> On Sat, Jun 04, 2011 at 04:37:05PM +0200, Frédéric Delanoy wrote:
>> This resolves the issue from bug #27383
>> ---
>> programs/cmd/builtins.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/programs/cmd/built
On Sat, Jun 04, 2011 at 04:37:05PM +0200, Frédéric Delanoy wrote:
> This resolves the issue from bug #27383
> ---
> programs/cmd/builtins.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/programs/cmd/builtins.c b/programs/cmd/builtins.c
> index 0352e59..18e16fe 1006
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The two patches look ok
Am 03.06.2011 um 14:23 schrieb Andrew Nguyen:
> ---
> dlls/d3d8/d3d8_private.h |5 +++--
> dlls/d3d8/device.c | 29 -
> dlls/d3d8/directx.c |2 +-
> dlls/d3d8/tests/device.c | 12
2011/6/3 Łukasz Wojniłowicz :
> ---
> loader/wine.pl.man.in | 327
> +
> 1 files changed, 327 insertions(+), 0 deletions(-)
> create mode 100644 loader/wine.pl.man.in
>
> diff --git a/loader/wine.pl.man.in b/loader/wine.pl.man.in
> new file mode 1
23 matches
Mail list logo