July 2008 - Wine-Devel - list.winehq.org

Re: d3d9: fix device crashing on Vista.

by Paul Vriens

H. Verbeet wrote: > 2008/7/30 Reece Dunn <msclrhd(a)googlemail.com>: >> SetMaterial crashes when passed a NULL argument. >> > If you're going to do that, you might as well remove the entire test. > I think this test has caused trouble before. > > > There is even a bug report for this: http://bugs.winehq.org/show_bug.cgi?id=13646 It looks like the SetMaterial with a NULL argument is only permitted (read, doesn't crash) on ddraw. Some patches were sent for this in the past as well but that was before 1.0 and were held back because of that. -- Cheers, Paul.

July 31, 2008

Re: ole32: don't crash when running the marshal tests on Vista.

by Rob Shearman

2008/7/30 Reece Dunn <msclrhd(a)googlemail.com>: > When running the ole32:marshal tests on Vista, the call to > CoUnmarshalInterface fails. This results in pProxy being NULL which > then causes the crash on the QueryInterface call. > > This patch makes sure that the pProxy-dependant tests are only called > when pProxy is valid. We need to work out why the test is failing - possibly it requires more implementation of the object we are marshalling than in previous versions of Windows. Also, the typical way of detecting failure in our COM code in Wine is to check the return value rather than whether a output object is NULL or not. -- Rob Shearman

July 31, 2008

Re: d3d9: fix device crashing on Vista.

by H. Verbeet

2008/7/30 Reece Dunn <msclrhd(a)googlemail.com>: > SetMaterial crashes when passed a NULL argument. > If you're going to do that, you might as well remove the entire test. I think this test has caused trouble before.

July 31, 2008

Re: dinput: the DIK_ keycode is not the same as the scancode.

by Michael Karcher

Am Mittwoch, den 30.07.2008, 18:12 -0600 schrieb Vitaliy Margolen: Disclaimer: I didn't thoroughly read the thread, but if I understood the problem area correctly, the following comments apply: > And even if Wine returns different DIKs on different keyboard layouts for > some questionable keys. Why is it a problem? In all the programs and games > I've seen one can remap their keys to whatever they want. It is a problem, because Wine should be compatible to Windows. Also, I wouldn't understand why the key containing minus and underscore would be called "slash" in the game. > The reason I'm so against adding extra X calls - it dramatically affects > latency of the input. We already have horrid latency with mouse. All because > thread that talks to X is busy doing other things. Thats why you should not look up what DIK code to use on each key event, but once on DirectInput initialization you should create a map from vkey do DIK. SDL uses something like the DIK codes seem to be with their SDLK constants. As SDL is also LGPL one might take a look into SDL how it is implemented there. Regards, Michael Karcher

July 31, 2008

Re: X11, ATI and GDI Error

by Chris Ahrendt

celticht32(a)aol.com wrote: > While looking at bug 13335 ( > http://bugs.winehq.org/show_bug.cgi?id=13335) which is An ATI and wine bug. > I noticed something in one of the updates : > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462715 > > > > Now this set me to searching as I really didn't like the idea of wrapping the libGL calls with 'winmemory' allocations > > (To many areas of corruption possibilities and just isn't an ellegant solution). The Debian post above points out something > > very interesting : > > > > " After more investigation, I was able to trace this to a bug in my OpenGL > > initialization logic. > > > > The following (psuedocode) sequence, forces fglrx to revert to indirect > > rendering: > > dpy = XOpenDisplay() > > visual = glXChooseVisual(dpy) > > XCloseDisplay(dpy) > > .. > > dpy2 = XOpenDisplay() > > ctx = glXCreateContext(dpy2, visual) <-- fglrx reverts to indirect > > rendering > > .. > > > > Changing the code to use the same display connection for glXChooseVisual > > and glXCreateContext solves this problem." > > > > So looking at that I began to Grep the latest git tree to find out where > > XOpenDisplay > > glxChooseVisual > > glxCreateContext > > XCloseDisplay > > > > are used. There are only 2 places (and yes I know they are critical places) where they are used. > > opengl.c and x11drv_attach.c both in the winex11.drv directory. So I went through and started looking > > at how they were called and discovered that the display variable (dpy and dpy2 in the above pseudocode) is not > > reused at all. It is allocated off the local stack of the subroutine it is in. later on gdi_display which is the global > > variable gets assigned display which calls the XOpenDisplay. This gdi_display is used as the global handle > > if I am reading the code correctly. > > > > Now this is where my pointer knowledge goes south and I think this is right... and this is where the problem might be: > > > > in the process_attach routine someone says gdi_display = display. Display is a local pointer to the routine and will > > go away when the function returns. > > > > Here is my theory : > > > > with the ATI card being a pig for memory and Wine allocating alot of memory itself the pointer to the driver gets invalidated > > somehow corrupted etc. and when it is used later X thinks its another display and everything happily crashes. > > > > Mind you this is a theory right now but is this possible? I think an easy fix to this would be to do the following instead: > > > > gdi_display = XopenDisplay()'; This allocates the display structure off the global heap not the local heap > > display = gdi_display; > > > > and then leave the rest of the code alone. > > > > Am I going down the right track with this? If so it would be alot simpler fix that some of the ones out there being forced around. And it should not > > effect any of the other supported cards. > > > > Chris > > > > ------------------------------------------------------------------------ > The Famous, the Infamous, the Lame - in your browser. Get the TMZ > Toolbar Now > <http://toolbar.aol.com/tmz/download.html?NCID=aolcmp00050000000014>! > > > ------------------------------------------------------------------------ > > That FIXED IT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! the open gl error is now GONE! I am not using ulimit... I am not using the comment patch in directx. Its a simple Change!!!! in x11drv_main.c change to this and I no longer get the opengl error at all: /* Open display */ if (!(gdi_display = XOpenDisplay( NULL ))) return FALSE; display = gdi_display;

July 31, 2008

Re: dinput: the DIK_ keycode is not the same as the scancode.

by Vitaliy Margolen

This is all well and good but I don't see a problem. In dinput that is. Are those scan codes match to what you are getting on windows? They should since they are hardware dependent. But might not. However v_key should stay the same. And even if Wine returns different DIKs on different keyboard layouts for some questionable keys. Why is it a problem? In all the programs and games I've seen one can remap their keys to whatever they want. The reason I'm so against adding extra X calls - it dramatically affects latency of the input. We already have horrid latency with mouse. All because thread that talks to X is busy doing other things. Vitaliy. Aric Stewart wrote: > Well the main problem is with Japanese keyboards I was testing with. > Often the scan codes, nor the vkey of the keyboards did not line up the > characters in the other keyboards. Yet dinput on windows correctly set > the DIK codes to represent the character being pressed. > An example is the key to the right of 'P'. It is scancode 0x1a on both > qwerty_us and the Japanese keyboard. However on the us keyboard it is > '[' while on the Japanese keyboard it is '@' (it is vkey VKEY_OEM_3, > which is '`' on the us keyboard) > > I saw similar problems with scan 0x1B ('[' in Japanese and ']' on > qwerty) 0x2b (']' vs '\') > > I did pretty extensive testing with shift on windows and with my code > and do not recall any specific problems though most of those tests where > with the Japanese keyboard. I can try some more. I am curious what > SHIFT+'2' (qwerty) produces as that is '@' > > I am not sure of a better way to try to solve this problem without > having a bunch of special case situations which struck me as bad. > > -aric > > Vitaliy Margolen wrote: >> Aric Stewart wrote: >>> It is mapped with the keyboard mapping to the resulting character. so >>> the key 'A' is DIK_A nomatter what its scancode or vkey would be. >>> This is relevent to Japanese keymapping where the '@' key is in the >>> '[' location the scancode for both is 0x22 but dinput generates >>> DIK_AT in japanese and DIK_LBRACKET in us_qwerty >>> >>> reworked to remove the giant case statement and hopefully be more clear. >>> remove japan specific stuff as with the proper keyboard scancodes it >>> works out. >> >> I'm still not clear why do you need to translate the v_key into char? >> This involves a round trip to the X server for each key press. >> >> Besides this will depend on the state of the num-lock, shift, etc. >> Which should not be the case for dinput. It should always return the >> same code for the key regardless of anything else. >> >> Vitaliy. >> >>

July 31, 2008

RE: [1/3] WineD3D: Use C bitfields to compact the ffp description (try 2)

by Stefan Dösinger

> You probably need to specify ~0u otherwise the constant might be > deemed to have the wrong type. This results in a warning again: ../../../dlls/wined3d/utils.c:1796: warning: large integer implicitly truncated to unsigned type

July 30, 2008

Re: [2]wined3d: rework surface Blt a bit to only lock the part of the destination surface being drawn to

by Aric Stewart

Had Stefan look over it before I submitted it this time. thanks! -aric H. Verbeet wrote: > 2008/7/30 Aric Stewart <aric(a)codeweavers.com>: >> --- >> dlls/wined3d/surface_base.c | 122 >> +++++++++++++++++++++++-------------------- >> 1 files changed, 65 insertions(+), 57 deletions(-) >> > Looks reasonable to me, although you might want to wait for Stefan to > look it over as well. > >

July 30, 2008

Re: ddraw/tests: Skip cubemap tests when cubemap isn't supported.

by H. Verbeet

2008/7/30 Stefan Dösinger <stefan(a)codeweavers.com>: > DeviceLoadTest is quite big, does splitting up make sense? Otherwise, what > you say is fair enough - I do not care too much about code beauty in the > tests as long as the tests work(since one hardly ever reads the test or does > lots of work on it, and the Windows apps we run are often crappy as well) > Please think of the poor people who are trying to fix driver bugs :-)

July 30, 2008

Re: [2]wined3d: rework surface Blt a bit to only lock the part of the destination surface being drawn to

by H. Verbeet

2008/7/30 Aric Stewart <aric(a)codeweavers.com>: > --- > dlls/wined3d/surface_base.c | 122 > +++++++++++++++++++++++-------------------- > 1 files changed, 65 insertions(+), 57 deletions(-) > Looks reasonable to me, although you might want to wait for Stefan to look it over as well.

July 30, 2008