Re: winecfg: Center main window on the screen.

[Dmitry Timoshkov]

Dmitry Timoshkov  wrote:

> For bug 21645.

What is this pending for?

-- 
Dmitry.

Re: libgcrypt thread safety

[Lei Zhang]

On Wed, Feb 8, 2012 at 1:56 PM, Marcus Meissner  wrote:
> On Wed, Feb 08, 2012 at 02:48:06PM -0600, Adam Martinson wrote:
>> I've been looking into bug 27036
>>  , and it's due to the
>> lack of thread safety by default in libgcrypt (in this case via
>> libgnutls in secur32.dll).  To be thread safe, libgcrypt requires a
>> call to gcry_control(GCRYCTL_SET_THREAD_CBS) before any libgcrypt
>> initialization is done.  However, libgcrypt is used by a lot of
>> different libs, one of which is being used by some other dll that's
>> loading before secur32.dll.
>>
>> My question is, is it acceptable to do the gcry_control() call in
>> ntdll's DllMain()?  The alternative seems to be tracking down every
>> lib used by wine that uses libgcrypt and doing it in each of those
>> dlls.  What's the best way to handle this?
>
> No, this would break abstraction.
>
> Why is libgcrypt needed here? It does not seem to be linked directly
> by any Wine component, also it seems strange that gnutls pulls it in...
>
> Can you call it on DllMain() on secur32.dll?
>
> Ciao, Marcus
>
>

I don't know the exact details, but libgcrypt and gnutls are related.
If you search for "gnutls thread safety", you'll find information like
this:

http://www.manpagez.com/info/gnutls/gnutls-2.10.4/gnutls_64.php

http://www.gnupg.org/documentation/manuals/gcrypt/Multi_002dThreading.html

Re: libgcrypt thread safety

[Marcus Meissner]

On Wed, Feb 08, 2012 at 02:48:06PM -0600, Adam Martinson wrote:
> I've been looking into bug 27036
>  , and it's due to the
> lack of thread safety by default in libgcrypt (in this case via
> libgnutls in secur32.dll).  To be thread safe, libgcrypt requires a
> call to gcry_control(GCRYCTL_SET_THREAD_CBS) before any libgcrypt
> initialization is done.  However, libgcrypt is used by a lot of
> different libs, one of which is being used by some other dll that's
> loading before secur32.dll.
> 
> My question is, is it acceptable to do the gcry_control() call in
> ntdll's DllMain()?  The alternative seems to be tracking down every
> lib used by wine that uses libgcrypt and doing it in each of those
> dlls.  What's the best way to handle this?

No, this would break abstraction.

Why is libgcrypt needed here? It does not seem to be linked directly
by any Wine component, also it seems strange that gnutls pulls it in...

Can you call it on DllMain() on secur32.dll?

Ciao, Marcus

Re: Profiing windows apps

[Ralph Little]

Hi,
> Also please attach a full +ddraw log to the bug report. If it is too big 
> compress it. bzip2 should do a pretty decent job, if all fails try lrzip.

OK, done!

> If the testing doesn't reveal anything, look out for IDirectDraw::GetCaps 
> calls in the logs or IDirect3Dx::EnumZBufferFormats. IDirectDraw::GetCaps 
> returns a DDCAPS structure which has dwZBufferBitDepths containing some flags 
> for z buffer bit depths. EnumZBufferFormats calls a callback multiple times 
> with available DDPIXELFORMAT structures. The application may not like some 
> flags we set there.

The Sims calls EnumDevices and I presume calls EnumZBufferFormats within the 
callback for each device:

trace:ddraw:d3d3_EnumDevices Enumerating WineD3D D3DDevice interface.
trace:ddraw:d3d3_EnumZBufferFormats iface 0x13d04c, device_iid 
{a4665c60-2673-11cf-a31a-00aa00b93356}, callback 0x586a7d, context 0xabc198.
trace:ddraw:d3d7_EnumZBufferFormats iface 0x13d048, device_iid 
{a4665c60-2673-11cf-a31a-00aa00b93356}, callback 0x586a7d, context 0xabc198.
trace:ddraw:d3d7_EnumZBufferFormats Asked for SW device.
trace:ddraw:PixelFormat_WineD3DtoDD Converting wined3d format 0x52 to DDRAW.
trace:ddraw:PixelFormat_WineD3DtoDD Returning: ( DDPF_ZBUFFER , Z bits : 16)
trace:ddraw:d3d7_EnumZBufferFormats Enumerating wined3d format 0x52.
trace:ddraw:d3d7_EnumZBufferFormats Format enumeration cancelled by application.
trace:ddraw:d3d3_EnumDevices Enumerating HAL Direct3D device.
trace:ddraw:d3d3_EnumZBufferFormats iface 0x13d04c, device_iid 
{84e63de0-46aa-11cf-816f-c020156e}, callback 0x586a7d, context 0xabc198.
trace:ddraw:d3d7_EnumZBufferFormats iface 0x13d048, device_iid 
{84e63de0-46aa-11cf-816f-c020156e}, callback 0x586a7d, context 0xabc198.
trace:ddraw:d3d7_EnumZBufferFormats Asked for HAL device.
trace:ddraw:PixelFormat_WineD3DtoDD Converting wined3d format 0x52 to DDRAW.
trace:ddraw:PixelFormat_WineD3DtoDD Returning: ( DDPF_ZBUFFER , Z bits : 16)
trace:ddraw:d3d7_EnumZBufferFormats Enumerating wined3d format 0x52.
trace:ddraw:d3d7_EnumZBufferFormats Format enumeration cancelled by application.
trace:ddraw:d3d3_EnumDevices End of enumeration.

I don't know if this looks sensible, though.
I see from the code that there are a lot of "gotchas" (both in 
d3d7_EnumZBufferFormats and d3d3_EnumDevices) for a number of games expecting 
things to happen in specific sequences and containing specific responses.
I wonder if the Sims is going to turn out to be another.

Cheers,
Ralph

libgcrypt thread safety

[Adam Martinson]

I've been looking into bug 27036 
 , and it's due to the 
lack of thread safety by default in libgcrypt (in this case via 
libgnutls in secur32.dll).  To be thread safe, libgcrypt requires a call 
to gcry_control(GCRYCTL_SET_THREAD_CBS) before any libgcrypt 
initialization is done.  However, libgcrypt is used by a lot of 
different libs, one of which is being used by some other dll that's 
loading before secur32.dll.


My question is, is it acceptable to do the gcry_control() call in 
ntdll's DllMain()?  The alternative seems to be tracking down every lib 
used by wine that uses libgcrypt and doing it in each of those dlls.  
What's the best way to handle this?

Re: OpenGL child windows (SketchUp)

[Roderick Colenbrander]

On Wed, Feb 8, 2012 at 6:31 PM, Matteo Bruni  wrote:
> Il 08 febbraio 2012 18:19, Brian Bloniarz  ha 
> scritto:
>> Hi all,
>>
>> I could use a little help fixing a window lag and screen corruption
>> issue in SketchUp:
>> http://bugs.winehq.org/show_bug.cgi?id=25912
>> Long story short, I think the implementation of OpenGL child rendering
>> needs a small update.
>>
>> As a reminder, this is how an OpenGL child window is setup:
>>
>> static BOOL set_win_format( HWND hwnd, XID fbconfig_id ) {
>>    gl_drawable = XCreateWindow(...); // offscreen window
>>    XCompositeRedirectWindow(..., gl_drawable, CompositeRedirectManual);
>> }
>>
>> Here XComposite extension is render into an offscreen window.
>> When it's time to display, the contents of that window are copied into
>> the visible onscreen parent window (physDev is the onscreen window,
>> gl_drawable is the offscreen window):
>>
>> BOOL X11DRV_SwapBuffers(PHYSDEV dev)
>> {
>>    ...
>>    glXSwapBuffers(gdi_display, gl_drawable);
>>
>>    ...
>>    /* The GL drawable may be lagged behind if we don't flush first, so
>>     * flush the display make sure we copy up-to-date data */
>>    XFlush(gdi_display);
>>    XCopyArea(gdi_display, gl_drawable, physDev...);
>> }
>>
>> The XFlush() is the problem; the buffer swap must happen
>> before the copy, and accelerated renderers wouldn't guarantee to do
>> that on an X queue flush.
>>
>> So how do you wait for a buffer swap? I wrote a test program,
>> can you say "undefined behavior"? I tested on a few drivers:
>>
>> 1) ATI fglrx binary driver:
>> glXSwapBuffers is instantaneous, existing code works fine.
>>
>> 2) NVidia binary driver:
>> glXSwapBuffers is asynchronous, neither XFlush() nor XSync()
>> is enough. Calling glXWaitGL or glFinish works.
>>
>> 3) Mesa DRI driver (Intel i915):
>> glXSwapBuffers is asynchronous. None of
>> XFlush/XSync/glXWaitX/glXWaitGL is enough. glFinish works.
>>
>> 4) r600g (Open Source accelerated ATI) driver:
>> glXSwapBuffers is asynchronous. None of the flush calls
>> wait for it (XFlush/XSync/glXWaitGL/glXWaitX/glFinish).
>>
>> The last one is the tricky part -- this driver is also
>> based on the DRI, so I'm guessing it may appear on other
>> open-source accelerated drivers (looking at
>> http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt
>> suggests that this is new behavior as of 1.99.2)
>>
>> So how to come up with a common fix? I could think of 3
>> possibilities:
>>
>> 1) Use the GLX_OML_sync_control extension, it has an explicit
>> call to wait for a buffer swap. Not supported by NV or fglrx,
>> but we could fallback to glXWaitGL on those drivers. Probably
>> simplest.
>>
>> 2) Use the X Damage extension, wait for an XDamageNotify
>> event before copying. This should work everywhere, all
>> drivers probably implement damage so that compositing window
>> managers can use it.
>>
>> 3) Talk to the DRI people, maybe glXWaitGL should't return
>> when there's a pending a buffer swap. The GLX spec seems to
>> say it should wait, but it's a grey area and the Composite extension
>> was designed much later. Not a quick fix.
>>
>> Any ideas or thoughts? If I hear nothing, I can code up a patch
>> that does (1), but it'd be great to hear from some people who
>> know this area well.
>>
>> Thanks,
>> Brian Bloniarz
>>
>>
>
> Nice analysis.
> I'm not really such an expert in the area, but I think both (1) and
> (2) make sense. I'm not sure in (1) case about the glXWaitGL call, as
> technically glXSwapBuffers is not a GL call, but given that it works
> for you (while XSync doesn't) on Nvidia, I guess it's fine... Make
> sure it works correctly on all the drivers you mentioned, or even that
> e.g. it doesn't cause excessive slowdowns.
>
>

The offscreen X11 window code is a bit questionable and we knew that
when added it. I have to think a bit and need to look closely at the
GLX specs again. My gut feeling is that vsync related functions may
not work for our purpose since we are well in undocumented territory
by using offscreen Windows (pbuffers also don't have vsync defined).

glXWaitGL and friends were intended for syncing GLX and X, so this may
be the most reliable way. As you pointed out there may be bugs in DRI,
but this needs a careful read of the specs (will try to look at it).
As you said the damage extension can be used as well, but I think I
would lean to using the classic glX/X synchronization features first.

I hope to have some time tonight to look at this.

Roderick

Re: gdi32: Consider whether the logical font face is vertical when selecting.

[Marvin]

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
http://testbot.winehq.org/JobDetails.pl?Key=16876

Your paranoid android.


=== WINEBUILD (build) ===
Patch failed to apply

Re: OpenGL child windows (SketchUp)

[Matteo Bruni]

Il 08 febbraio 2012 18:19, Brian Bloniarz  ha scritto:
> Hi all,
>
> I could use a little help fixing a window lag and screen corruption
> issue in SketchUp:
> http://bugs.winehq.org/show_bug.cgi?id=25912
> Long story short, I think the implementation of OpenGL child rendering
> needs a small update.
>
> As a reminder, this is how an OpenGL child window is setup:
>
> static BOOL set_win_format( HWND hwnd, XID fbconfig_id ) {
>    gl_drawable = XCreateWindow(...); // offscreen window
>    XCompositeRedirectWindow(..., gl_drawable, CompositeRedirectManual);
> }
>
> Here XComposite extension is render into an offscreen window.
> When it's time to display, the contents of that window are copied into
> the visible onscreen parent window (physDev is the onscreen window,
> gl_drawable is the offscreen window):
>
> BOOL X11DRV_SwapBuffers(PHYSDEV dev)
> {
>    ...
>    glXSwapBuffers(gdi_display, gl_drawable);
>
>    ...
>    /* The GL drawable may be lagged behind if we don't flush first, so
>     * flush the display make sure we copy up-to-date data */
>    XFlush(gdi_display);
>    XCopyArea(gdi_display, gl_drawable, physDev...);
> }
>
> The XFlush() is the problem; the buffer swap must happen
> before the copy, and accelerated renderers wouldn't guarantee to do
> that on an X queue flush.
>
> So how do you wait for a buffer swap? I wrote a test program,
> can you say "undefined behavior"? I tested on a few drivers:
>
> 1) ATI fglrx binary driver:
> glXSwapBuffers is instantaneous, existing code works fine.
>
> 2) NVidia binary driver:
> glXSwapBuffers is asynchronous, neither XFlush() nor XSync()
> is enough. Calling glXWaitGL or glFinish works.
>
> 3) Mesa DRI driver (Intel i915):
> glXSwapBuffers is asynchronous. None of
> XFlush/XSync/glXWaitX/glXWaitGL is enough. glFinish works.
>
> 4) r600g (Open Source accelerated ATI) driver:
> glXSwapBuffers is asynchronous. None of the flush calls
> wait for it (XFlush/XSync/glXWaitGL/glXWaitX/glFinish).
>
> The last one is the tricky part -- this driver is also
> based on the DRI, so I'm guessing it may appear on other
> open-source accelerated drivers (looking at
> http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt
> suggests that this is new behavior as of 1.99.2)
>
> So how to come up with a common fix? I could think of 3
> possibilities:
>
> 1) Use the GLX_OML_sync_control extension, it has an explicit
> call to wait for a buffer swap. Not supported by NV or fglrx,
> but we could fallback to glXWaitGL on those drivers. Probably
> simplest.
>
> 2) Use the X Damage extension, wait for an XDamageNotify
> event before copying. This should work everywhere, all
> drivers probably implement damage so that compositing window
> managers can use it.
>
> 3) Talk to the DRI people, maybe glXWaitGL should't return
> when there's a pending a buffer swap. The GLX spec seems to
> say it should wait, but it's a grey area and the Composite extension
> was designed much later. Not a quick fix.
>
> Any ideas or thoughts? If I hear nothing, I can code up a patch
> that does (1), but it'd be great to hear from some people who
> know this area well.
>
> Thanks,
> Brian Bloniarz
>
>

Nice analysis.
I'm not really such an expert in the area, but I think both (1) and
(2) make sense. I'm not sure in (1) case about the glXWaitGL call, as
technically glXSwapBuffers is not a GL call, but given that it works
for you (while XSync doesn't) on Nvidia, I guess it's fine... Make
sure it works correctly on all the drivers you mentioned, or even that
e.g. it doesn't cause excessive slowdowns.

Re: winecfg: Center main window on the screen.

[Austin English]

On Wed, Feb 8, 2012 at 07:13, Michael Stefaniuc  wrote:
> Vitaliy Margolen wrote:
>> Please don't! I want my window manager decide based on how I configured
>> it where to position new windows. And not every program open in the
>> middle of the screen just because it things it's the most important
>> thing on my screen.
> Uh? At the moment it always opens in the top right corner. There doesn't
> seems to be a way in Win32 land to not specify a position where to open
> the window.

top left* :)

-- 
-Austin

Re: winmm: TRACE unhandled messages

[Andrew Eikum]

On Wed, Feb 08, 2012 at 11:22:42AM +0100, joerg-cyril.hoe...@t-systems.com 
wrote:
> Your rewrite no more maps WOD_XYZ* messages to waveOut functions.
> I believe that it is possible that an old app entirely uses the generic 
> SendDriverMessage function
> (esp. in the mciavi/msvfw area, cf. ICSendMessage) instead of the specific 
> wave/midi* ones.
> Can you be sure that this is not supported by native, esp. w9x?
> 

Good question. All of the following is on my Win 7 VM. I tested both
with no compatibility and with WinXP SP3 compatibility.

I tried using OpenDriver with "wave", "wavemapper", "wdmaud.drv", and
"msacm32.drv" (last two found in Win 7 registry), all of which return
NULL (ie, error). So I think SendDriverMessage() is unlikely to be
interesting.

I wasn't able to get any useful results with WODM_* or WOD_* through
waveOutMessage. Interestingly, WOD_OPEN returns NOTSUPPORTED, while
WODM_OPEN crashes. I tried passing various combinations of
WAVEOPENDESC, MMDRV_MESSAGE_PARAMS (not in the PSDK or Wine's
include), and NULL to the function, but everything crashes. It's
possible there's something useful there, but I can't figure out how to
get at it.

Using the simpler case of WODM_GETNUMDEVS also failed in every case.

> If Wine does not map these, all we'll get to "hear" in AppDB is that attentive
> people miss sound or music that they remember listening to 10 years ago on 
> native.
> 

Well, hopefully they would also file bugs :)

Andrew

OpenGL child windows (SketchUp)

[Brian Bloniarz]

Hi all,

I could use a little help fixing a window lag and screen corruption
issue in SketchUp:
http://bugs.winehq.org/show_bug.cgi?id=25912
Long story short, I think the implementation of OpenGL child rendering
needs a small update.

As a reminder, this is how an OpenGL child window is setup:

static BOOL set_win_format( HWND hwnd, XID fbconfig_id ) {
gl_drawable = XCreateWindow(...); // offscreen window
XCompositeRedirectWindow(..., gl_drawable, CompositeRedirectManual);
}

Here XComposite extension is render into an offscreen window.
When it's time to display, the contents of that window are copied into
the visible onscreen parent window (physDev is the onscreen window,
gl_drawable is the offscreen window):

BOOL X11DRV_SwapBuffers(PHYSDEV dev)
{
...
glXSwapBuffers(gdi_display, gl_drawable);

...
/* The GL drawable may be lagged behind if we don't flush first, so
 * flush the display make sure we copy up-to-date data */
XFlush(gdi_display);
XCopyArea(gdi_display, gl_drawable, physDev...);
}

The XFlush() is the problem; the buffer swap must happen
before the copy, and accelerated renderers wouldn't guarantee to do
that on an X queue flush.

So how do you wait for a buffer swap? I wrote a test program,
can you say "undefined behavior"? I tested on a few drivers:

1) ATI fglrx binary driver:
glXSwapBuffers is instantaneous, existing code works fine.

2) NVidia binary driver:
glXSwapBuffers is asynchronous, neither XFlush() nor XSync()
is enough. Calling glXWaitGL or glFinish works.

3) Mesa DRI driver (Intel i915):
glXSwapBuffers is asynchronous. None of
XFlush/XSync/glXWaitX/glXWaitGL is enough. glFinish works.

4) r600g (Open Source accelerated ATI) driver:
glXSwapBuffers is asynchronous. None of the flush calls
wait for it (XFlush/XSync/glXWaitGL/glXWaitX/glFinish).

The last one is the tricky part -- this driver is also
based on the DRI, so I'm guessing it may appear on other
open-source accelerated drivers (looking at
http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt
suggests that this is new behavior as of 1.99.2)

So how to come up with a common fix? I could think of 3
possibilities:

1) Use the GLX_OML_sync_control extension, it has an explicit
call to wait for a buffer swap. Not supported by NV or fglrx,
but we could fallback to glXWaitGL on those drivers. Probably
simplest.

2) Use the X Damage extension, wait for an XDamageNotify
event before copying. This should work everywhere, all
drivers probably implement damage so that compositing window
managers can use it.

3) Talk to the DRI people, maybe glXWaitGL should't return
when there's a pending a buffer swap. The GLX spec seems to
say it should wait, but it's a grey area and the Composite extension
was designed much later. Not a quick fix.

Any ideas or thoughts? If I hear nothing, I can code up a patch
that does (1), but it'd be great to hear from some people who
know this area well.

Thanks,
Brian Bloniarz

Re: winecfg: Center main window on the screen.

[Michael Stefaniuc]

Vitaliy Margolen wrote:
> Please don't! I want my window manager decide based on how I configured
> it where to position new windows. And not every program open in the
> middle of the screen just because it things it's the most important
> thing on my screen.
Uh? At the moment it always opens in the top right corner. There doesn't
seems to be a way in Win32 land to not specify a position where to open
the window.

bye
michael

Re: winecfg: Center main window on the screen.

[Dmitry Timoshkov]

Vitaliy Margolen  wrote:

> Please don't! I want my window manager decide based on how I configured it 
> where to position new windows. And not every program open in the middle of 
> the screen just because it things it's the most important thing on my screen.

I'm surprised to see this comment here and not in the 2 years old bug report.
Besides, that's just a DS_CENTER replacement for a not existent property sheet
style. If you think that any application that uses SetWindowPos breaks your
heart then I can't help with that, sorry, I'm not a doctor.

-- 
Dmitry.

Re: winecfg: Center main window on the screen.

[Vitaliy Margolen]

Please don't! I want my window manager decide based on how I configured it 
where to position new windows. And not every program open in the middle of 
the screen just because it things it's the most important thing on my screen.


Vitaliy.

winmm: TRACE unhandled messages

[Joerg-Cyril . Hoehle]

Andrew,

it's good that you log these now.  I had a question in mind since your winmm 
rewrite:

Your rewrite no more maps WOD_XYZ* messages to waveOut functions.
I believe that it is possible that an old app entirely uses the generic 
SendDriverMessage function
(esp. in the mciavi/msvfw area, cf. ICSendMessage) instead of the specific 
wave/midi* ones.
Can you be sure that this is not supported by native, esp. w9x?

If Wine does not map these, all we'll get to "hear" in AppDB is that attentive
people miss sound or music that they remember listening to 10 years ago on 
native.

Regards,
 Jörg Höhle