Hi Juan,
On Tue, 2009-06-16 at 08:51 -0700, Juan Lang wrote:
> The patch is unfortunately incorrect. Hardcoding 1 as the instance
> can't work in general. I don't know what the correct fix is offhand.
> I also don't see how it's a partial revert, as the patch looks nothing
> like the code before
On Tue, 16 Jun 2009, Arthur Taylor wrote:
[...]
> This is all simple enough except for how variable it is. Applications
> usually allocate a set size of wavehdrs and then use them circularly.
> Applications usually use when a wavehdr is returned for timing
> purposes rather than waveOutGetPositi
You can find the current patchset here:
http://www.math.uni-bielefeld.de/~tjakobi/wine/np2fixup_arb/
Of course the GLSL patchset is needed as well:
http://www.math.uni-bielefeld.de/~tjakobi/wine/np2fixup_glsl/
I hope both can finally go into master, so please take a look.
Going to resend the GLS
2009/6/17 Stefan Dösinger :
>
> +struct wine_rb_functions sig_tree_functions =
> +{
> +sig_tree_alloc,
> +sig_tree_realloc,
> +sig_tree_free,
> +sig_tree_compare
> +};
Sorry for not mentioning this before, but you can just use
wined3d_rb_alloc() etc. for that.
wine_rb_init() can fa
> cursoricon.c:1039: Test failed: Overlaying Mask 0 on Color 00A0B0C0 with
> DrawIcon. Expected 3163 (modern), or 3868 (legacy). Got 20B8 from
> line 1109
> cursoricon.c:1039: Test failed: Overlaying Mask 1 on Color 00A0B0C0 with
> DrawIcon. Expected 00FFCE9C (modern), or 00FFD0A0 (
Am Wednesday 17 June 2009 21:56:14 schrieb Roderick Colenbrander:
> Have you tried: winedbg --gdb appname.exe? It will use gdb then and
> still see win32 symbols I think.
You can also start the app, put a Sleep(1) somewhere into the early
wined3d init code, then attach gdb to the running proce
Am Wednesday 17 June 2009 21:45:12 schrieb Allan Tong:
> On Wed, Jun 17, 2009 at 1:37 PM, Stefan Dösinger
wrote:
> > +if(strcmp(rel_reg, "**aL_emul**") == 0)
> > +{
> > +DWORD idx = ctx->aL + reg->idx;
> > +
Have you tried: winedbg --gdb appname.exe? It will use gdb then and
still see win32 symbols I think.
Roderick
On Wed, Jun 17, 2009 at 5:49 PM, Wang, Robin wrote:
> We also have tried using winedbg, but it cannot break into our driver either.
>
> The only way we can break into our driver before i
On Wed, Jun 17, 2009 at 1:37 PM, Stefan Dösinger wrote:
> +if(strcmp(rel_reg, "**aL_emul**") == 0)
> +{
> +DWORD idx = ctx->aL + reg->idx;
> +if(idx < 10)
Seems like this should be MAX_REG_INPU
We also have tried using winedbg, but it cannot break into our driver either.
The only way we can break into our driver before is using "gdb wine-pthread",
but now it is not available.
Do you have some suggestion on winedbg configuration to make it able to break
into graphics drivers.
Thanks
Wasn't aware that it was a buffer with a fixed size. Then you are
correct and it should work.
Roderick
On Wed, Jun 17, 2009 at 9:04 PM, Tony Wasserka wrote:
> Roderick Colenbrander schrieb:
>> Hi Tony,
>>
>> + WideCharToMultiByte(CP_ACP, 0, This->desc.FaceName, -1,
>> desc->FaceName, sizeof(de
Roderick Colenbrander schrieb:
> Hi Tony,
>
> +WideCharToMultiByte(CP_ACP, 0, This->desc.FaceName, -1,
> desc->FaceName, sizeof(desc->FaceName) / sizeof(CHAR), NULL, NULL);
>
> sizeof(desc->FaceName) / sizeof(CHAR) won't give you the length of the
> string (remember that sizeof is evaluated at
2009/6/17 Stefan Dösinger :
> That would need a shader_create callback function for the shader backend. I
> can sure add it, but I think it would defeat the purpose.
>
Why does the lookup need to happen on shader creation? I think doing
it from shader_arb_select() would work just as well.
> The ot
2009/6/17 Stefan Dösinger :
> Am Wednesday 17 June 2009 20:51:43 schrieb Henri Verbeet:
>> 2009/6/17 Stefan Dösinger :
>> > That would need a shader_create callback function for the shader backend.
>> > I can sure add it, but I think it would defeat the purpose.
>>
>> Why does the lookup need to ha
Roderick Colenbrander schrieb:
> Hi Tony,
>
> +hr = D3DXCreateFontA(device, 12, 0, FW_DONTCARE, 0, FALSE,
> DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH,
> "Arial", &font);
>
> A bunch of font tests all use Arial. On Windows this font is always
> around, what happens on W
Stefan Dösinger schrieb:
> Am Wednesday 17 June 2009 18:29:57 schrieb Tony Wasserka:
>
>
>> @@ -300,6 +301,12 @@ HRESULT WINAPI
>>
> D3DXCreateFontIndirectW(LPDIRECT3DDEVICE9 device, CONST D3DXFONT_
>
>> object->device=device;
>> object->desc=*desc;
>>
>> +object->hdc = Cr
Am Wednesday 17 June 2009 20:51:43 schrieb Henri Verbeet:
> 2009/6/17 Stefan Dösinger :
> > That would need a shader_create callback function for the shader backend.
> > I can sure add it, but I think it would defeat the purpose.
>
> Why does the lookup need to happen on shader creation? I think do
2009/6/17 Stefan Dösinger :
>> This is specific to ARB as well.
> The intention was to use it to deal with broken gl_ClipVertex support on Apple
> drivers - ie, to add the same texcoord based clipping to GLSL as a fallback
> if gl_ClipVertex does not work. Now you already said you considered this
>
Am Wednesday 17 June 2009 20:24:26 schrieb Henri Verbeet:
> 2009/6/17 Stefan Dösinger :
> > +//ERR("Using texcoord %u for clip\n", ps->clipplane_emulation);
>
> C99 features generally aren't allowed inside Wine code.
Ooops. Didn't intend to keep the commented out debug line.
> > +if(!d
Well as Henri mentioned a bug report has been posted to the
(un)official amd bugzilla for it with details on the crash. It was
just related to the enabling of FBOs by default and some FBO related
tests.
Regarding debugging I would try to use winedbg and if it isn't
sufficient winedbg offers a gdb
On Wed, Jun 17, 2009 at 1:40 PM, Paul Vriens wrote:
> Nicolas Le Cam wrote:
>>
>> 2009/6/17 Austin English :
>>>
>>> 2009/6/17 Paul Vriens :
André Hentschel wrote:
>
> WinNT4 is passing now for the first time since a long time(maybe since
> ever?).
> So special congratulat
Nicolas Le Cam wrote:
2009/6/17 Austin English :
2009/6/17 Paul Vriens :
André Hentschel wrote:
WinNT4 is passing now for the first time since a long time(maybe since
ever?).
So special congratulations to Paul Vriens, who spent much time making the
test-suite run on NT4.
This is a great step f
Am Wednesday 17 June 2009 20:24:19 schrieb Henri Verbeet:
> I don't think we want this for GLSL. ARB is your own responsibility,
> but personally I think compile errors are much nicer to debug than the
> kind of graphics glitches missing clipplanes will create.
They may be nicer to debug, but they'
2009/6/17 Austin English :
> 2009/6/17 Paul Vriens :
>> André Hentschel wrote:
>>>
>>> WinNT4 is passing now for the first time since a long time(maybe since
>>> ever?).
>>> So special congratulations to Paul Vriens, who spent much time making the
>>> test-suite run on NT4.
>>> This is a great step
Am Wednesday 17 June 2009 20:24:10 schrieb Henri Verbeet:
> Please keep this private to the ARB backend. (I.e., store these in
> struct shader_arb_priv.)
That would need a shader_create callback function for the shader backend. I
can sure add it, but I think it would defeat the purpose.
The other
2009/6/17 Stefan Dösinger :
> If I have to choose between a compile failure or disabling some clipplanes
> I'll throw the clipplanes under the bus.
>
> If the shader is using relative addressing, look at the highest directly
> addressed constant register. We know that the constant array must be at
2009/6/17 Stefan Dösinger :
> +//ERR("Using texcoord %u for clip\n", ps->clipplane_emulation);
C99 features generally aren't allowed inside Wine code.
> +if(!device->vs_clipping)
> +{
> +/* See if we can use fragment.texcoord[7] for clipplane emulation
> + *
> +
> @@ -1465,9 +1471,14 @@ struct IWineD3DDeviceImpl
> const struct fragment_pipeline *frag_pipe;
> const struct blit_shader *blitter;
>
> +struct ps_signature *pshader_signatures;
> +unsigned int num_pshader_signatures;
> +unsigned int pshader_signatures_size;
> +DWORD ps_s
2009/6/17 Paul Vriens :
> André Hentschel wrote:
>>
>> WinNT4 is passing now for the first time since a long time(maybe since
>> ever?).
>> So special congratulations to Paul Vriens, who spent much time making the
>> test-suite run on NT4.
>> This is a great step for the test-suite. Now NT4, 2K, XP
Hi Tony,
+hr = D3DXCreateFontA(device, 12, 0, FW_DONTCARE, 0, FALSE,
DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH,
"Arial", &font);
A bunch of font tests all use Arial. On Windows this font is always
around, what happens on Wine when this font isn't around? Perhaps the
André Hentschel wrote:
WinNT4 is passing now for the first time since a long time(maybe since
ever?).
So special congratulations to Paul Vriens, who spent much time making
the test-suite run on NT4.
This is a great step for the test-suite. Now NT4, 2K, XP and 2K3 are
passing partially.
Keep it
Hi Tony,
+WideCharToMultiByte(CP_ACP, 0, This->desc.FaceName, -1,
desc->FaceName, sizeof(desc->FaceName) / sizeof(CHAR), NULL, NULL);
sizeof(desc->FaceName) / sizeof(CHAR) won't give you the length of the
string (remember that sizeof is evaluated at compile time, so the
value is a constant)
Am Wednesday 17 June 2009 18:29:57 schrieb Tony Wasserka:
> @@ -300,6 +301,12 @@ HRESULT WINAPI
D3DXCreateFontIndirectW(LPDIRECT3DDEVICE9 device, CONST D3DXFONT_
> object->device=device;
> object->desc=*desc;
>
> + object->hdc = CreateCompatibleDC(NULL);
Device contexts are scarce reso
Hi Andre,
> I fixed the strange problems in try8 (
> http://www.winehq.org/pipermail/wine-patches/2009-June/074340.html ) and it
> still dont get commit.
> can you please do a review for this try? (Just say it, if it gets disturbing
> you.)
This one looks fine to me. And don't worry, you're not
WinNT4 is passing now for the first time since a long time(maybe since ever?).
So special congratulations to Paul Vriens, who spent much time making the
test-suite run on NT4.
This is a great step for the test-suite. Now NT4, 2K, XP and 2K3 are passing
partially.
Keep it up!
joerg-cyril.hoe...@t-systems.com schrieb:
Hi,
[resend, 1st message disappeared?]
since somewhere between wine-1.1.6 and 1.1.21, going to winecfg's drives tab
does not (re)scan all drives such as CD-ROMs anymore. So access to the tab is
faster, but winecfg does not display the disk label (shown
On Wed, Jun 17, 2009 at 11:01 AM, Guan, Xiao-Feng wrote:
> Hello,
>
> As we can see that, from version 1.1.23, all application fails to start on
> AMD card. We are going to investigate why it happens. If it is necessary,
> Would you please let us know a little more about the changes of this
> ver
2009/6/17 Guan, Xiao-Feng :
> Hello,
>
>
>
> I’m AMD driver developer and would like to ask a question. This issue
> blocks us from making a better driver for WINE.
>
>
>
> Recently we have difficulty in debugging our driver with WINE. We used to
> start wine-pthread in gdb to debug the applica
On Tue, Jun 16, 2009 at 7:07 PM, Zheng Che wrote:
> Screenshot attached.
The mach-o bug is fixed in git. The others, you probably need to
adjust your path/build dependencies...Have you installed freetype,
etc.?
--
-Austin
On Wed, Jun 17, 2009 at 10:16 AM, Yann Droneaud wrote:
> Le mercredi 17 juin 2009 à 04:01 +0200, Stefan Dösinger a écrit :
>> The patches seem ok to me, although I'd probably merge them into one
>> patch(there's no point in adding unused defines)
>
> In my first version, I tried to match each mode
Paul Vriens wrote:
Huw Davies wrote:
On Wed, Jun 17, 2009 at 03:58:33PM +0200, Paul Vriens wrote:
Huw Davies wrote:
---
dlls/oleaut32/tests/tmarshal.c | 53
+++-
dlls/oleaut32/tests/tmarshal.idl |6 +++
dlls/oleaut32/tests/tmarshal_dispids.h |
Huw Davies wrote:
On Wed, Jun 17, 2009 at 03:58:33PM +0200, Paul Vriens wrote:
Huw Davies wrote:
---
dlls/oleaut32/tests/tmarshal.c | 53 +++-
dlls/oleaut32/tests/tmarshal.idl |6 +++
dlls/oleaut32/tests/tmarshal_dispids.h |1 +
3 files chang
On Wed, Jun 17, 2009 at 03:58:33PM +0200, Paul Vriens wrote:
> Huw Davies wrote:
>> ---
>> dlls/oleaut32/tests/tmarshal.c | 53
>> +++-
>> dlls/oleaut32/tests/tmarshal.idl |6 +++
>> dlls/oleaut32/tests/tmarshal_dispids.h |1 +
>> 3 files change
Huw Davies wrote:
---
dlls/oleaut32/tests/tmarshal.c | 53 +++-
dlls/oleaut32/tests/tmarshal.idl |6 +++
dlls/oleaut32/tests/tmarshal_dispids.h |1 +
3 files changed, 59 insertions(+), 1 deletions(-)
--
2009/6/17 Guan, Xiao-Feng :
> As we can see that, from version 1.1.23, all application fails to start on
> AMD card. We are going to investigate why it happens. If it is necessary,
> Would you please let us know a little more about the changes of this
> version?
>
There's a bug for that specific
Hi,
[resend, 1st message disappeared?]
since somewhere between wine-1.1.6 and 1.1.21, going to winecfg's drives tab
does not (re)scan all drives such as CD-ROMs anymore. So access to the tab is
faster, but winecfg does not display the disk label (shown empty) and serial
number (always 0) any mo
Hello,
I'm AMD driver developer and would like to ask a question. This issue
blocks us from making a better driver for WINE.
Recently we have difficulty in debugging our driver with WINE. We used
to start wine-pthread in gdb to debug the applications. Or else we
cannot break into our dr
On Wed, 17 Jun 2009, Henri Verbeet wrote:
> 2009/6/16 Michael Abbott :
> > - /* The depth data is normalized, so needs to be
> > scaled, the stencil data isn't. */
> Looks like the patch got wrapped. You'll probably want to just attach
> the output of git format-patch.
Oops! T
Le mercredi 17 juin 2009 à 04:01 +0200, Stefan Dösinger a écrit :
> The patches seem ok to me, although I'd probably merge them into one
> patch(there's no point in adding unused defines)
In my first version, I tried to match each model because inside each
sub family, some are faster than the ot
2009/6/16 Michael Abbott :
> - /* The depth data is normalized, so needs to be
> scaled, the stencil data isn't. */
Looks like the patch got wrapped. You'll probably want to just attach
the output of git format-patch.
2009/6/17 Zheng Che :
> Screenshot attached.
Since the screenshot only includes text, a copy of the text would be
more appropriate.
Screenshot attached.
<>
52 matches
Mail list logo
