October 2013 - Wine-Devel - list.winehq.org

Re: ddraw/tests: Use BOOL type where appropriate

by 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 https://newtestbot.winehq.org/JobDetails.pl?Key=2682 Your paranoid android. === wxppro (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === wvista (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w2008s64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag === w7pro64 (32 bit d3d) === d3d.c:1261: Test failed: Homogeneous output was generated despite UNCLIPPED flag

Oct. 9, 2013

Re: winemac: Add registry settings to make Option keys send Alt rather than accessing additional characters from the keyboard layout.

by Ken Thomases

On Oct 9, 2013, at 4:49 PM, Phil Krylov wrote: > Thanks! You're welcome. > Do you consider adding an option to stop interpreting Command as Alt? I have not considered it. What would be gained? Do you want the Command key interpreted as the Windows key? Do you want something else to happen when Command is pressed? Cheers, Ken

Oct. 9, 2013

Re: winemac: Add registry settings to make Option keys send Alt rather than accessing additional characters from the keyboard layout.

by Phil Krylov

Thanks! Do you consider adding an option to stop interpreting Command as Alt? On Thu, Oct 10, 2013 at 1:30 AM, Ken Thomases <ken(a)codeweavers.com> wrote: > --- > dlls/winemac.drv/cocoa_window.m | 22 ++++++++++++++++++++-- > dlls/winemac.drv/macdrv_cocoa.h | 2 ++ > dlls/winemac.drv/macdrv_main.c | 7 +++++++ > 3 files changed, 29 insertions(+), 2 deletions(-) > > > > -- С уважением, Филипп Крылов.

Oct. 9, 2013

Re: [PATCH 5/5] user32: Implement better stub of OpenInputDesktop.

by Vincent Povirk

I don't think it's possible to properly implement SwitchDesktop in either the X11 or Mac driver. There's just nothing sensible for it to do. One possible strategy would be to implement SwitchDesktop in user32 and wineserver. Wineserver could logically track the input desktop, and OpenInputDesktop would return the "correct" desktop, but SwitchDesktop wouldn't really do anything. If in the future we decide there's something SwitchDesktop can do that makes sense, we can add a function for it to the user driver, and OpenInputDesktop probably won't need to change.

Oct. 9, 2013

Re: [PATCH] d3dx9: Move object initialization into a separate function.

by Matteo Bruni

2013/10/9 Rico Schüller <kgbricola(a)web.de>: > On 09.10.2013 01:12, Matteo Bruni wrote: >> >> Hi Rico, >> >> 2013/10/8 Rico Schüller <kgbricola(a)web.de>: >>> >>> Hi, >>> >>> this moves the object initialization into a separate function, so it >>> could >>> be used for strings and resources. It also removes the STATE_TYPE as we >>> could distinguish the types at the object level. >>> >>> 1. When an object has a destination, it points to another shader >>> variable. >>> This was state ST_PARAMETER. >>> >>> 2. If a variable has something in data, it is fxlc, shader (preshader) or >>> a >>> string. This was state ST_CONSTANT and ST_FXLC. >>> >>> 3. If it has both (destination and data), it points to an array of shader >>> variables. The name is in the destination, the index could be calculated >>> with the data. This will be added in a later patch. >>> >> >> There's still the issue of distinguishing between ST_CONSTANT and >> ST_FXLC, checking object_id and type might cover that though. > > I think we could distinguish between them. I forgot to add, if both are 0, > then it is a constant and the parameter data has already the correct value. > Marking the shader as ST_CONSTANT was a little bit wrong, as we would need > to set the shader/preshader variables. > > >> >>> Also saving the destination parameter in the object gains some speed when >>> we >>> need to access the variable as we don't need to run >>> get_parameter_by_name() >>> each time we need the variable ... >>> >> >> I'm not sure storing additional info into the objects is the right >> thing to do. Take a look at the D3DXFX_NOT_CLONEABLE flag from >> >> http://msdn.microsoft.com/en-us/library/windows/desktop/bb172855%28v=vs.85%…. >> Notice that GetPassDesc() doesn't return the shader data if the object >> was created with the flag. What I've been thinking is that it simply >> can't because the original shader data, stored in an object, were >> freed after parsing. > > Yeah, I'm aware of D3DXFX_NOT_CLONEABLE. But we need to hold the shader blob > or something similar (a reflection of the used preshader variables) to set > the correct values. We also need it in the case for when the parameter needs > to be calculated (fxlc) and in for strings. So imho, we could only release > the blob partially when we have a preshader, nowhere else (and in this case > we still need the "reflection" somehow). So let me conclude: We need to > store the "destination" and the "reflection" somewhere. We may release the > full shader binary. > Yeah, we need to store something for those cases, but not necessarily the original shader blob (we could store some derived information instead). So I essentially agree here. > >> While nothing forces us to do the same (except probably avoiding to >> use more memory than strictly necessary) I think it's better not to >> put additional stuff into the objects or generally assume that the >> objects are still available after parsing. That means creating the >> shaders and the strings at parse time or right after that and storing >> any additional required information (e.g. preshader) in the parameter. >> >> So, directly storing the referenced parameter is a good idea but I'd >> prefer that pointer to be in d3dx_parameter. > > I haven't put it in the parameter as there are much more parameters than > objects. Each state, each array element and each structure member has a > parameter while there are only some parameters that have objects. So we may > use some more bytes when putting it in the parameter than putting it in the > object. > True, my point is that the memory reclaimed by freeing the objects is probably more than the memory wasted by some additional pointers. I don't have any hard data though (and applications might "forget" to specify D3DXFX_NOT_CLONEABLE) so I might be wrong. > I'm fine with both ways, because each object is tight to a specific > parameter, it's mostly a matter of taste where the data is stored. > > Cheers > Rico

Oct. 9, 2013

Re: Fix text rotation problem in GM_ADVANCED graphics mode caused by incorrect implementation of GetTextExtentPointW().

by Ralf Habacker

On 01.10.2013 12:40, Alexandre Julliard wrote: > Ralf Habacker <ralf(a)habacker.de> writes: > >> On 01.10.2013 12:12, Alexandre Julliard wrote: >>> Ralf Habacker <ralf.habacker(a)freenet.de> writes: >>> >>>> With other patches i have been told to implement such stuff in the dib >>>> driver. Unfortunally this do not works in this case, because in the top >>>> level function it looks like having driver specific stuff using display >>>> coordinates. >>> It would still most likely have to be in the driver, >> which is freetype_GetTextExtentExPoint() ? >> >>> though maybe the driver would not be calling that exact entry point. >> not sure i understand right: >> >> GetTextExtentExPointW() calls get_char_positions(), which runs >> dev->funcs->pGetTextExtentExPoint(), which is mapped to >> freetype_GetTextExtentExPoint(), which is in the driver. Which entry >> point your are refering else ? > The various text rendering entry points in the graphics drivers. You mean there are more affected places ? > >>> In any case, you can't change the DC transform like this >> then a real solution requires to move the transformation to logical >> coordinates stuff in BOOL GetTextExtentExPointW() to >> freetype_GetTextExtentExPoint() and to manipulate the related matrixes >> in freetype_GetTextExtentExPoint() directly wen using GM_ADVANCED ? > No, I don't think so. The transform is only used to determine the font > scaling factor. the recent implementation of get_glyph_outline() uses in GM_ADVANCED mode a scale which depends somehow on the rotation angle. I got better results with saving the "use GM_ADVANCED case" in font->font_desc.advanced_graphics_mode and the following hunks for freetype.c @@ -6426,10 +6426,24 @@ static DWORD get_glyph_outline(GdiFont *incoming_font, UINT glyph, UINT format, worldMat.xy = -FTFixedFromFloat(font->font_desc.matrix.eM21); worldMat.yx = -FTFixedFromFloat(font->font_desc.matrix.eM12); worldMat.yy = FTFixedFromFloat(font->font_desc.matrix.eM22); pFT_Matrix_Multiply(&worldMat, &transMat); - pFT_Matrix_Multiply(&worldMat, &transMatUnrotated); pFT_Matrix_Multiply(&worldMat, &transMatTategaki); - needsTransform = TRUE; + if (font->font_desc.advanced_graphics_mode) { + worldMat.xx = FTFixedFromFloat(1.0/font->font_desc.matrix.eM11); + worldMat.xy = -FTFixedFromFloat(font->font_desc.matrix.eM21); + worldMat.yx = -FTFixedFromFloat(font->font_desc.matrix.eM12); + worldMat.yy = FTFixedFromFloat(1.0/font->font_desc.matrix.eM22); + } + else { + worldMat = identityMat; + } + + pFT_Matrix_Multiply(&worldMat, &transMatUnrotated); + needsTransform = TRUE; } and @@ -6571,35 +6590,50 @@ static DWORD get_glyph_outline(GdiFont *incoming_font, UINT glyph, UINT format, origin_y = top; } + if (font->font_desc.advanced_graphics_mode) + pFT_Vector_Transform(&vec, &transMatUnrotated); + else + pFT_Vector_Transform(&vec, &transMat); + which works except for using 90° and 270° world transformations angles. Transforming back the list of character width in the top level function GetTextExtentExPointW(). The transformation is done with static inline INT INTERNAL_XDSTOWS(DC *dc, INT width) { double floatWidth; floatWidth = (double)width * dc->xformVport2World.eM11; /* Round to integers */ return GDI_ROUND(floatWidth); } dc->xformVport2World.eM11 is zero in the mentioned angles, so it will always return zero, which means at now the submitted patch is the only working solution. >From what i can see an alternative would require to move the device to logical back transformation into get_glyph_outline() and to refactor all function get_glyph_outline() is called from. Regards Ralf

Oct. 9, 2013

Re: winspool: ERROR_INVALID_NAME in GetDefaultPrinter() ?

by Hamzat

Dears, I faced the same problem, but, unfortunally, link to answer is invalid. Please, tell me, how did you resolve situation? Thanks. -- View this message in context: http://wine.1045685.n5.nabble.com/winspool-ERROR-INVALID-NAME-in-GetDefault… Sent from the Wine - Devel mailing list archive at Nabble.com.

Oct. 9, 2013

Help / Mentoring

by Hugh McMaster

Hi everyone, I just wanted to know if anyone would mind helping/mentoring me with a few small patches. I am working primarily on wineconsole's screen buffer problems (to which I believe I have the solution), but am also looking at implementing some stub Win32 console functions found in dlls/kernel32. Obviously, my aim is to have these patches committed, as the changes will benefit the entire Wine community. I had initially thought of Eric Poeuch, a significant wineconsole developer, however he appears to be extremely busy. So I'm not sure who else to contact. If time is a consideration, please note that I won't be constantly contacting you to review patches or answer questions. Thank you, Hugh

Oct. 9, 2013

Re: [PATCH 4/5] d3drm: Compare with the correct IID in IDirect3DRMVisualArrayImpl_QueryInterface().

by Henri Verbeet

On 9 October 2013 11:26, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > >> +static HRESULT WINAPI IDirect3DRMVisualArrayImpl_QueryInterface(IDirect3DRMVisualArray *iface, REFIID riid, void **out) >> { >> - TRACE("(%p)->(%s, %p)\n", iface, debugstr_guid(riid), ret_iface); >> + TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); >> >> - if (IsEqualGUID(riid, &IID_IUnknown) || >> - IsEqualGUID(riid, &IID_IDirect3DRMFrameArray)) >> + if (IsEqualGUID(riid, &IID_IDirect3DRMVisualArray) >> + || IsEqualGUID(riid, &IID_IUnknown)) >> { >> - *ret_iface = iface; >> IDirect3DRMVisualArray_AddRef(iface); >> + *out = iface; >> return S_OK; >> } > > Although this is existing code the assignment '*out = iface' is wrong, > especially since next patch introduces impl_from_IDirect3DRMVisualArray() > helper. Looks like that file needs a bit of COM clean up. > The entire dll needs some cleanup in general, but that assignment is correct, since it's querying for the same interface that gets passed in.

Oct. 9, 2013

Re: [PATCH 4/5] d3drm: Compare with the correct IID in IDirect3DRMVisualArrayImpl_QueryInterface().

by Dmitry Timoshkov

Henri Verbeet <hverbeet(a)codeweavers.com> wrote: > +static HRESULT WINAPI IDirect3DRMVisualArrayImpl_QueryInterface(IDirect3DRMVisualArray *iface, REFIID riid, void **out) > { > - TRACE("(%p)->(%s, %p)\n", iface, debugstr_guid(riid), ret_iface); > + TRACE("iface %p, riid %s, out %p.\n", iface, debugstr_guid(riid), out); > > - if (IsEqualGUID(riid, &IID_IUnknown) || > - IsEqualGUID(riid, &IID_IDirect3DRMFrameArray)) > + if (IsEqualGUID(riid, &IID_IDirect3DRMVisualArray) > + || IsEqualGUID(riid, &IID_IUnknown)) > { > - *ret_iface = iface; > IDirect3DRMVisualArray_AddRef(iface); > + *out = iface; > return S_OK; > } Although this is existing code the assignment '*out = iface' is wrong, especially since next patch introduces impl_from_IDirect3DRMVisualArray() helper. Looks like that file needs a bit of COM clean up. -- Dmitry.

Oct. 9, 2013