Dapper, git, and version-stamp pain again
On one of my dapper boxes (an old laptop), I got the error main.o: In function `check_command_line':/home/dank/wine-git/loader/main.c:89: undefined reference to `wine_version' today. Turns out the version-stamp rule in loader/Makefile is misbehaving; I had to hack that rule to not invoke git at all. Hmm. I remember having to do that before. Oh, yeah, it's coming back to me now: Dapper's "git --version" reports 1.1.3, and http://wiki.winehq.org/GitWine#head-f90aa63f963ccd6f1b34f59e4fdaafaecc72ad18 says that's too old. Grr. I guess I should submit a patch that checks git's version and doesn't break the build if it's only 1.1.3... it'd save me fifteen minutes next time I forget about this... - Dan
re: New list subscriber - Question about gdi:widenpath
Hi Laurent! You wrote: I'm trying make a french software called Navigation, used by airplane pilots and created using visual basic, work on linux using wine. Can you provide a URL to a page describing the software you're trying to port? The point is this software needs gdi:widenpath to work. I'd just like to know if this function is planned for the next release or if I will have to wait a little more. It's not planned, as far as I know. If your business really needs it, and you're not comfortable trying it yourself, you might consider contracting with a Wine developer to implement it. What's your schedule? For anyone curious about WidenPath(), here are a couple links on the subject: http://msdn2.microsoft.com/en-us/library/ms535195.aspx http://edais.mvps.org/Tutorials/GDI/DC/DCch7.html http://www.tek-tips.com/viewthread.cfm?qid=524165 Thanks & good luck! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Re: Paul Vriens : mshtml/tests: Cast-qual warning fix.
Alexandre Julliard wrote:
> Module: wine
> Branch: master
> Commit: 6338caa9eda8eda98dad9a89a8e71c6ea37bd168
> URL:
> http://source.winehq.org/git/wine.git/?a=commit;h=6338caa9eda8eda98dad9a89a8e71c6ea37bd168
>
> Author: Paul Vriens <[EMAIL PROTECTED]>
> Date: Fri Jan 12 14:26:05 2007 +0100
>
> mshtml/tests: Cast-qual warning fix.
This breaks compilation with older gcc versions. At least with gcc-3.1.1
used by Smatch.
dlls/mshtml/tests/htmldoc.c: In function `test_Load':
dlls/mshtml/tests/htmldoc.c:1806: invalid initializer
make[2]: *** [htmldoc.o] Error 1
>
> ---
>
> dlls/mshtml/tests/htmldoc.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/dlls/mshtml/tests/htmldoc.c b/dlls/mshtml/tests/htmldoc.c
> index ac26ca8..0815c01 100644
> --- a/dlls/mshtml/tests/htmldoc.c
> +++ b/dlls/mshtml/tests/htmldoc.c
> @@ -1803,11 +1803,12 @@ static void test_Load(IPersistMoniker *p
> {
> IBindCtx *bind;
> HRESULT hres;
> +static WCHAR sz_html_clientsite_objectparam[] =
> SZ_HTML_CLIENTSITE_OBJECTPARAM;
Making that 'static const WCHAR sz_html_clientsite_objectparam[]' fixes
the compilation error but renders the exercise moot.
>
> test_readyState((IUnknown*)persist);
>
> CreateBindCtx(0, &bind);
> -IBindCtx_RegisterObjectParam(bind,
> (LPOLESTR)SZ_HTML_CLIENTSITE_OBJECTPARAM,
> +IBindCtx_RegisterObjectParam(bind, sz_html_clientsite_objectparam,
> (IUnknown*)&ClientSite);
>
> SET_EXPECT(GetDisplayName);
>
>
>
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
Sr. Network EngineerFax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
Re: Paul Vriens : secur32/tests: Cast-qual warning fixes.
Alexandre Julliard wrote: > Module: wine > Branch: master > Commit: 6c3efd1c32b1f9054e82a684da6ab54a599f252d > URL: > http://source.winehq.org/git/wine.git/?a=commit;h=6c3efd1c32b1f9054e82a684da6ab54a599f252d > > Author: Paul Vriens <[EMAIL PROTECTED]> > Date: Fri Jan 12 14:01:16 2007 +0100 > > secur32/tests: Cast-qual warning fixes. This breaks compilation with older gcc versions. At least with gcc-3.1.1 used by Smatch. dlls/secur32/tests/schannel.c: In function `testAcquireSecurityContext': dlls/secur32/tests/schannel.c:119: invalid initializer make[2]: *** [schannel.o] Error 1 > > --- > > dlls/secur32/tests/schannel.c | 11 ++- > 1 files changed, 6 insertions(+), 5 deletions(-) > > diff --git a/dlls/secur32/tests/schannel.c b/dlls/secur32/tests/schannel.c > index ca870f4..0bbd96b 100644 > --- a/dlls/secur32/tests/schannel.c > +++ b/dlls/secur32/tests/schannel.c > @@ -116,12 +116,13 @@ static void testAcquireSecurityContext(v > PCCERT_CONTEXT certs[2]; > HCRYPTPROV csp; > static CHAR unisp_name_a[] = UNISP_NAME_A; > +static WCHAR ms_def_prov_w[] = MS_DEF_PROV_W; Making that 'static const WCHAR ms_def_prov_w[]' fixes the compilation error but renders the exercise moot. > BOOL ret; > HCRYPTKEY key; > CRYPT_KEY_PROV_INFO keyProvInfo; > > -keyProvInfo.pwszContainerName = (LPWSTR)cspNameW; > -keyProvInfo.pwszProvName = (LPWSTR)MS_DEF_PROV_W; > +keyProvInfo.pwszContainerName = cspNameW; > +keyProvInfo.pwszProvName = ms_def_prov_w; > keyProvInfo.dwProvType = PROV_RSA_FULL; > keyProvInfo.dwFlags = 0; > keyProvInfo.cProvParam = 0; bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network EngineerFax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: Paul Vriens : crypt32/tests: Cast-qual warning fixes.
Alexandre Julliard wrote:
> Module: wine
> Branch: master
> Commit: 259c06ffc93d690fa5105b1451e519aa1c92b72e
> URL:
> http://source.winehq.org/git/wine.git/?a=commit;h=259c06ffc93d690fa5105b1451e519aa1c92b72e
>
> Author: Paul Vriens <[EMAIL PROTECTED]>
> Date: Fri Jan 12 15:51:02 2007 +0100
>
> crypt32/tests: Cast-qual warning fixes.
This breaks compilation with older gcc versions. At least with gcc-3.1.1
used by Smatch.
dlls/crypt32/tests/cert.c:312: invalid initializer
make[2]: *** [cert.o] Error 1
> @@ -309,8 +308,8 @@ static void checkHash(const BYTE *data,
> propID);
> }
>
> -static const WCHAR cspNameW[] = {
> 'W','i','n','e','C','r','y','p','t','T','e',
> - 'm','p',0 };
> +static WCHAR cspNameW[] = {
> 'W','i','n','e','C','r','y','p','t','T','e','m','p',0 };
> +static WCHAR ms_def_prov_w[] = MS_DEF_PROV_W;
Making that 'static const WCHAR ms_def_prov_w[]' fixes the compilation
error but renders the exercise moot.
>
> static void testCertProperties(void)
> {
>
>
> ---
>
> dlls/crypt32/tests/cert.c | 113
> ++---
> 1 files changed, 56 insertions(+), 57 deletions(-)
>
> Diff:
> http://source.winehq.org/git/wine.git/?a=commitdiff;h=259c06ffc93d690fa5105b1451e519aa1c92b72e
>
>
--
Michael Stefaniuc Tel.: +49-711-96437-199
Sr. Network EngineerFax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
GreenVille font, is it still available? I have a question about it.
Markus Amsler wrote: >I neither fully understood it, but here my opinion. It >looks like the >"only" problem he has is the TrueType hinting, which >affects small font >sizes. As long as the kerning (=width of a glyph) is >correct, and the >font looks somehow similar, it should be suitable for >wine's need. So it >should be possible to convert Larry's TTF version with >fontforge to SDF, >and you're done. Adding hinting is IMO a second step. This is incorrect. The metric EM size per point size is also 'Hintable' with real TrueType instructions, and Tahoma DOES do this. (I can tell, because I ran this test case just today-- Notice how the fonts start being pretty much identically kerned and spaced after about 15pt. Since wine is STUCK using Type-1 hints with FontForge, I built a Type-1 hinted .OTF with Postscript formatted outlines for the test.) http://lunacy-inc.dyndns.org:88/ahhah/TahomaVS%20Greenville%20Type1%20(7%20through%2010).png http://lunacy-inc.dyndns.org:88/ahhah/TahomaVS%20Greenville%20Type1%20(11%20through%2013).png http://lunacy-inc.dyndns.org:88/ahhah/TahomaVS%20Greenville%20Type1%20(14%20through%2016).png As you can see, there is a VERY LARGE discrepency between greenville (without TTF instructions) and MS Tahoma (Which does use TTF instructions). Type-1 hinting system does not have a mechanism to overcome this incongruity, because the glyphs have been arbitrarily resized using TTF instructions in MS Tahoma, and Type-1 hinting system does not have a mechanism for this. Depending on how far you want to go, you have 3 options as I see them: 1) (Best,but unlikely, due to the intense effort required) You fix FontForge to support TTF instructions natively, so that it can build a suitable TTF hinted font file, then scream at FreeType to support them more "Sanely." 2) Use the Type-1 font that is correct at sizes 15 and up, and use a bitmapped font for sizes below that and have WINE perform the substitution. 3) Adapt FontForge to inject SBIT record data (Basically bitmapped font data) directly into a generated OTF, and trump the rasterizer totally for these point sizes. The last one seems the most workable, but I am unsure if .OTF files can support SBIT data records, although they are a part of the ".ttf wrapper" spec used by OTF files.--- More research would need to be performed to determine the viability of this option. Theoretically, the rasterizer should check for the existance of SBIT records, and if it finds one, simply pull the bitmap from the record, and pass it on through, totally skipping the rasterizer. I would check with Freetype's documentation to see if SBITs are supported with OTF under freetype. MS Typography has this to say concerning SBITs and OTF files: http://www.microsoft.com/typography/otspec/recom.htm Embedded Bitmaps Three tables are used to embed bitmaps in OpenType fonts. They are the 'EBLC' table for embedded bitmap locators, the 'EBDT' table for embedded bitmap data, and the 'EBSC' table for embedded bitmap scaling information. OpenType embedded bitmaps are also called 'sbits'. The behavior of sbits within an OpenType font is essentially transparent to the client. A client need not be aware whether the bitmap returned by the rasterizer comes from an sbit or from a scan-converted outline. The metrics in 'sbit' tables overrule the outline metrics at all sizes where sbits are defined. Fonts with 'hdmx' tables should correct those tables with 'sbit' values. 'Sbit only' fonts, that is fonts with embedded bitmaps but without outline data, are permitted. Care must be taken to ensure that all required OpenType tables except 'glyf' and 'loca' are present in such a font. Obviously, such fonts will only be able to return glyphs and sizes for which sbits are defined. 1. These metrics are returned as part of the logical font data structure by the GDI CreateLogFont() API. 2. These metrics are returned by the Apple Advanced Typography (AAT) GetFontInfo() API. Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
Re: wine kills X
Hi, On Fri, Jan 12, 2007 at 02:04:21PM +1000, Edward Savage wrote: > Also I've had a number of odd problems with directx and wine over the last > two weeks. Including a very strange one where the second time I run the > application it's speed is slower than an ant in the range of 0.7fps instead > of the normal 10fps - furthermore it's ability to grab data seems to also be > slowed. This is all while using the same resources that the application > does at full speed. I'm forced to restart my xserver every time I wish to > play it (which is twice a day) and if I don't I can kill X or even lock up > my system. Though I've been unable to work out the cause beyond 'it's > probably some thing to do with the nvidia driver'. If some one could offer > a some debugging advice on what I should be looking for it'd be very nice. Run a diff on glxinfo and xdpyinfo logs from before and after running that app? Maybe something changes, and this might hint at the problem. /var/log/Xorg.0.log doesn't display anything relevant either, I assume? Andreas Mohr
Re: GreenVille font, is it still available? I have a question about it.
Louis. Lenders wrote: Hi, i finally got response from Larry Snyder (aka wierd_w ), who created Greenville font. (appeared he was on holiday). Below is the mail he sent me, and i talked to him on irc about it. To summarize, he's willing to license this LGPL, but reading his mail it seems to me this won't be a one day fix ;) What he writes further is quite a bit beyond my knowledge of fonts, so i really hope on of the wine developers who know something about fonts could read the mail and tell what could be done, or how things should be done. Thanks in advance,Louis I neither fully understood it, but here my opinion. It looks like the "only" problem he has is the TrueType hinting, which affects small font sizes. As long as the kerning (=width of a glyph) is correct, and the font looks somehow similar, it should be suitable for wine's need. So it should be possible to convert Larry's TTF version with fontforge to SDF, and you're done. Adding hinting is IMO a second step.
Wine-cvs time-stamp timezone
Hi, I just thought I should mention that the timestamps for "Last message date:" and "Archived on:" at http://www.winehq.org/pipermail/wine-cvs/2007-January/ are currently given as CDT times, whereas those of the individual patches are correctly shown as CST. Thanks, -- Andy.
New list subscriber - Question about gdi:widenpath
Hi, My name is Laurent. I'm french, 23 year old, software designer for a huge european company. I'm trying make a french software called Navigation, used by airplane pilots and created using visual basic, work on linux using wine. The point is this software needs gdi:widenpath to work. I'd just like to know if this function is planned for the next release or if I will have to wait a little more. I'd like to provide a patch for this particular function but unfortunatly, my development skills are far to low to do it without any help. Does anyone have informations about this function ? Thank you for your help. Laurent
Re: Implement SQLGetInstalledDrivers in odbccp32
Detlef Riekenberg wrote: At first: Congratulations for the commit of your Patches. On Do, 2007-01-11 at 09:29 -0800, Bill Medland wrote: Bill Medland ([EMAIL PROTECTED]) Implement GetInstalledDrivers in odbccp32 BOOL WINAPI SQLGetInstalledDriversW(LPWSTR lpszBuf, WORD cbBufMax, WORD *pcbBufOut) +else if ((reg_ret = RegOpenKeyExA (HKEY_LOCAL_MACHINE /* The drivers does not depend on the config mode */, +"Software\\ODBC\\ODBCINST.INI\\ODBC Drivers", 0, KEY_READ /* Maybe overkill */, +&hDrivers)) == ERROR_SUCCESS) We want to eleminate all CrossCalls: http://wiki.winehq.org/CrossCallsWtoA Please convert RegOpenKeyExA and the string to UNICODE. Thanks Hi, when running the command as shown on the wiki '.../winapi', that above one is not shown. Is there something wrong with this winapi check? Cheers, Paul.
Re: configure: add ncursesw detecting [try 2]
"Anatoly Lyutin" <[EMAIL PROTECTED]> wrote With This patch you will be able to see cyrillic symbols in wineconsole. Please send it to wine-patches. And obviously once your patch is committed both places it fixes will need another fix to support multibyte encodings. -- Dmitry.
Re: Implement SQLGetInstalledDrivers in odbccp32
On Fri, 2007-12-01 at 13:45 +0100, Detlef Riekenberg wrote: > At first: > Congratulations for the commit of your Patches. > > > On Do, 2007-01-11 at 09:29 -0800, Bill Medland wrote: > > > Bill Medland ([EMAIL PROTECTED]) > > Implement GetInstalledDrivers in odbccp32 > > > BOOL WINAPI SQLGetInstalledDriversW(LPWSTR lpszBuf, WORD cbBufMax, > > WORD *pcbBufOut) > > > +else if ((reg_ret = RegOpenKeyExA (HKEY_LOCAL_MACHINE /* The drivers > > does not depend on the config mode */, > > +"Software\\ODBC\\ODBCINST.INI\\ODBC Drivers", 0, KEY_READ /* > > Maybe overkill */, > > +&hDrivers)) == ERROR_SUCCESS) > > We want to eleminate all CrossCalls: > http://wiki.winehq.org/CrossCallsWtoA > > Please convert RegOpenKeyExA and the string to UNICODE. > Thanks > The wiki doesn't say but I presume we accept the space penalty and inconvenience of specifying each character one by one? (I had been doing the debate, not realising that we had a standard, and decided to go with the ASCII version because the key is static well- defined pure ASCII so there would be no loss) Bill
Re: Test case for Bug 50 [Was: Bug 50]
Update... I thought I had managed to get Keith's idea and make up a patch, but, to great grief -- and not so great a surprise --, I have just discovered that my patch for bug 50 is not as effective on Lotus Notes 6.5.3 as it was in Notes R5 and the Petzold justify1 example. Well, I'm checking some traces here, and noticed that version 6.5.3 uses a rather odd -- at least to me -- method for justifying a paragraph... below is a section of the trace grepped to show only the relevant calls. Here Notes is trying to justify the first paragraph of a message, being the first line Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Etiam tellus pede, semper id, convallis a, tincidunt ut, augue. That's a single line -- or rather extent --, but here is what the log says (ignore the excess of repetitions, I was trying to be thorough): LOG SECTION STARTS HERE trace:font:SetTextJustification (hdc=0xaa60, breakExtra=7, breakCount=7) trace:font:GetTextExtentPoint32W (0xaa60 L"Lorem ipsum dolor sit amet, consectetuer adipiscing elit" 56 0x34c1c4): returning 3457528 x 0 trace:font:GetTextExtentExPointW (0xaa60, L"Lorem ipsum dolor sit amet, consectetuer adipiscing elit", 0) trace:font:GetTextExtentExPointW hdc=0xaa60, cx=3457528, cy=0 trace:font:WineEngGetTextExtentExPoint 0x2de6e90, L"Lorem ipsum dolor sit amet, consectetuer adipiscing elit", 56, 0, 0x34c1c4 trace:font:WineEngGetTextExtentExPoint return cx=333, cy=19, nfit=56 trace:font:GetTextExtentExPointW returning cx=333, cy=19, nFit=0 trace:font:SetTextJustification (hdc=0xaa60, breakExtra=0, breakCount=0) trace:font:GetTextExtentPoint32W (0xaa60 L"." 1 0x34c1c4): returning 3457528 x 0 trace:font:GetTextExtentExPointW (0xaa60, L".", 0) trace:font:GetTextExtentExPointW hdc=0xaa60, cx=3457528, cy=0 trace:font:WineEngGetTextExtentExPoint 0x2de6e90, L".", 1, 0, 0x34c1c4 trace:font:WineEngGetTextExtentExPoint return cx=4, cy=19, nfit=1 trace:font:GetTextExtentExPointW returning cx=4, cy=19, nFit=0 trace:font:SetTextJustification (hdc=0xaa60, breakExtra=1, breakCount=1) trace:font:GetTextExtentPoint32W (0xaa60 L" " 1 0x34c1c4): returning 3457528 x 0 trace:font:GetTextExtentExPointW (0xaa60, L" ", 0) trace:font:GetTextExtentExPointW hdc=0xaa60, cx=3457528, cy=0 trace:font:WineEngGetTextExtentExPoint 0x2de6e90, L" ", 1, 0, 0x34c1c4 trace:font:WineEngGetTextExtentExPoint return cx=4, cy=19, nfit=1 trace:font:GetTextExtentExPointW returning cx=4, cy=19, nFit=0 trace:font:SetTextJustification (hdc=0xaa60, breakExtra=0, breakCount=0) trace:font:SetTextJustification (hdc=0xaa60, breakExtra=13, breakCount=9) trace:font:GetTextExtentPoint32W (0xaa60 L"Etiam tellus pede, semper id, convallis a, tincidunt ut, augue" 62 0x34c1c4): returning 3457528 x 0 trace:font:GetTextExtentExPointW (0xaa60, L"Etiam tellus pede, semper id, convallis a, tincidunt ut, augue", 0) trace:font:GetTextExtentExPointW hdc=0xaa60, cx=3457528, cy=0 trace:font:WineEngGetTextExtentExPoint 0x2de6e90, L"Etiam tellus pede, semper id, convallis a, tincidunt ut, augue", 62, 0, 0x34c1c4 trace:font:WineEngGetTextExtentExPoint return cx=355, cy=19, nfit=62 trace:font:GetTextExtentExPointW returning cx=355, cy=19, nFit=0 trace:font:SetTextJustification (hdc=0xaa60, breakExtra=0, breakCount=0) trace:font:GetTextExtentPoint32W (0xaa60 L"." 1 0x34c1c4): returning 3457528 x 0 trace:font:GetTextExtentExPointW (0xaa60, L".", 0) trace:font:GetTextExtentExPointW hdc=0xaa60, cx=3457528, cy=0 trace:font:WineEngGetTextExtentExPoint 0x2de6e90, L".", 1, 0, 0x34c1c4 trace:font:WineEngGetTextExtentExPoint return cx=4, cy=19, nfit=1 trace:font:GetTextExtentExPointW returning cx=4, cy=19, nFit=0 trace:font:GetTextExtentPoint32W (0xaa60 L" " 1 0x34c1c4): returning 3457528 x 0 trace:font:GetTextExtentExPointW (0xaa60, L" ", 0) trace:font:GetTextExtentExPointW hdc=0xaa60, cx=3457528, cy=0 trace:font:WineEngGetTextExtentExPoint 0x2de6e90, L" ", 1, 0, 0x34c1c4 trace:font:WineEngGetTextExtentExPoint return cx=4, cy=19, nfit=1 trace:font:GetTextExtentExPointW returning cx=4, cy=19, nFit=0 trace:font:GetTextExtentPoint32W (0xaa60 L" " 1 0x34c184): returning 3457464 x 0 trace:font:GetTextExtentExPointW (0xaa60, L" ", 0) trace:font:GetTextExtentExPointW hdc=0xaa60, cx=3457464, cy=0 trace:font:WineEngGetTextExtentExPoint 0x2de6e90, L" ", 1, 0, 0x34c184 trace:font:WineEngGetTextExtentExPoint return cx=4, cy=19, nfit=1 trace:font:GetTextExtentExPointW returning cx=4, cy=19, nFit=0 LOG SECTION ENDS HERE Btw, that last period was *not* painted. I'm having some ideas here, but they don't seem very nice right now... what about you? Keith? TIA, - Pedro.
Re: (Cross)Compile failure for dsound/tests and shlwapi/tests
On Friday 12 January 2007 12:54, Paul Vriens wrote: > glad to hear the problems are fixed. I don't need the patches as I > will wait for the RPM's that Hans provides. > > So Hans, what about it ? :-) Sure, I'll find some time this weekend. -Hans
Re: Implement SQLGetInstalledDrivers in odbccp32
At first: Congratulations for the commit of your Patches. On Do, 2007-01-11 at 09:29 -0800, Bill Medland wrote: > Bill Medland ([EMAIL PROTECTED]) > Implement GetInstalledDrivers in odbccp32 > BOOL WINAPI SQLGetInstalledDriversW(LPWSTR lpszBuf, WORD cbBufMax, > WORD *pcbBufOut) > +else if ((reg_ret = RegOpenKeyExA (HKEY_LOCAL_MACHINE /* The drivers > does not depend on the config mode */, > +"Software\\ODBC\\ODBCINST.INI\\ODBC Drivers", 0, KEY_READ /* > Maybe overkill */, > +&hDrivers)) == ERROR_SUCCESS) We want to eleminate all CrossCalls: http://wiki.winehq.org/CrossCallsWtoA Please convert RegOpenKeyExA and the string to UNICODE. Thanks -- By by ... Detlef
Re: (Cross)Compile failure for dsound/tests and shlwapi/tests
On 1/10/07, Stefan Leichter <[EMAIL PROTECTED]> wrote: Am Wednesday 10 January 2007 19:10 schrieb Paul Vriens: > Hi, > > three failures currently prevent winetest.exe from being build. The > first one was ole32/tests/marshal.c (where Stefan Leichter sent a MinGW > patch for): > [snip] > > Volunteers ? > The patches are already send to Hans and Paul Millar. Do you like to get them too? Anyone else like to get the patches? Bye Stefan Hi Stefan, glad to hear the problems are fixed. I don't need the patches as I will wait for the RPM's that Hans provides. So Hans, what about it ? :-) Cheers, Paul.
Re: [dinput][joystick_linuxinput] make axes work, that are "not in a row"
On Thu, Jan 11, 2007 at 10:25:51AM -0700, Vitaliy Margolen wrote:
attached a patch with all the suggestions for Vitaliy.
> Christoph Frick wrote:
> > with Vitaliy's patches i tried my games yesterday and everything seemed
> > ok (RBR works again). but my clutch on the wheel did not work and also
> That's a good news. I was hopping not to brake too many things while
> reorganizing the dinput.
>
> > @@ -128,11 +122,20 @@ struct JoystickImpl
> > /* The 'parent' DInput */
> > IDirectInputImpl *dinput;
> >
> > + /* autodetecting ranges per axe by following movement */
> > + LONGhavemax[8];
> > + LONGhavemin[8];
> I could never understood why we need these? In other joystick_linux the
> range assumed to be 0 - 0x.
>
> > /* joystick private */
> > /* what range and deadzone the game wants */
> > - LONGwantmin[ABS_MAX];
> > - LONGwantmax[ABS_MAX];
> > - LONGdeadz[ABS_MAX];
> > + LONGwantmin[8];
> > + LONGwantmax[8];
> > + LONGdeadz[8];
> Can we move these into separate struct like it's done in joystick_linux?
> It's much cleaner end eventually will allow a better integration of two.
>
> And can you use spaces instead of tabs please?
>
> > @@ -395,19 +373,29 @@ static JoystickImpl *alloc_device(REFGUID rguid,
> > const void *jvt, IDirectInputIm
> > /* Supported Axis & POVs should map 1-to-1 */
> > for (i = 0; i < 8; i++)
> > {
> > -if (!test_bit(newDevice->joydev->absbits, i)) continue;
> > +if (!test_bit(newDevice->joydev->absbits, i)) {
> > + newDevice->axes[i] = -1;
> > + continue;
> > +}
> Can you please don't brake the good readable style? Please put that
> curly bracket into separate line, and use 4 space indentation.
>
>
> > +fake_current_js_state(newDevice);
> > +
> Can you explain what this suppose to do? Why do we need to "fake current
> state" everywhere?
>
> > +int axe = This->axes[ie.code];
> It's an "axis" not an "axe" :)
--
diff --git a/dlls/dinput/joystick_linuxinput.c
b/dlls/dinput/joystick_linuxinput.c
index e2f77f8..640c8d9 100644
--- a/dlls/dinput/joystick_linuxinput.c
+++ b/dlls/dinput/joystick_linuxinput.c
@@ -70,8 +70,8 @@ WINE_DEFAULT_DEBUG_CHANNEL(dinput);
/* Wine joystick driver object instances */
#define WINE_JOYSTICK_AXIS_BASE 0
-#define WINE_JOYSTICK_POV_BASE6
-#define WINE_JOYSTICK_BUTTON_BASE 8
+#define WINE_JOYSTICK_POV_BASE8
+#define WINE_JOYSTICK_BUTTON_BASE 12
typedef struct EffectListItem EffectListItem;
struct EffectListItem
@@ -111,12 +111,15 @@ struct JoyDev {
/* data returned by the EVIOCGABS() ioctl */
int axes[ABS_MAX][5];
- /* LUT for KEY_ to offset in rgbButtons */
- BYTEbuttons[KEY_MAX];
+};
- /* autodetecting ranges per axe by following movement */
- LONGhavemax[ABS_MAX];
- LONGhavemin[ABS_MAX];
+struct ObjProps
+{
+LONG havemin;
+LONG havemax;
+LONG wantmin;
+LONG wantmax;
+LONG deadzone;
};
struct JoystickImpl
@@ -128,11 +131,13 @@ struct JoystickImpl
/* The 'parent' DInput */
IDirectInputImpl *dinput;
- /* joystick private */
- /* what range and deadzone the game wants */
- LONGwantmin[ABS_MAX];
- LONGwantmax[ABS_MAX];
- LONGdeadz[ABS_MAX];
+struct ObjProps props[8];
+
+/* LUT for the mapping of used axes */
+int axes[ABS_MAX];
+
+ /* LUT for KEY_ to offset in rgbButtons */
+ BYTEbuttons[KEY_MAX];
int joyfd;
@@ -177,7 +182,7 @@ static void find_joydevs(void)
struct JoyDev joydev = {0};
int fd;
int no_ff_check = 0;
-int j, buttons;
+int j;
snprintf(buf,MAX_PATH,EVDEVPREFIX"%d",i);
buf[MAX_PATH-1] = 0;
@@ -246,7 +251,7 @@ static void find_joydevs(void)
for (j=0;jff_state = FF_STATUS_STOPPED;
#endif
- for (i=0;iwantmin[i] = newDevice->joydev->havemin[i];
-newDevice->wantmax[i] = newDevice->joydev->havemax[i];
-/* TODO:
- * direct input defines a default for the deadzone somewhere; but as long
- * as in map_axis the code for the dead zone is commented out its no
- * problem
- */
-newDevice->deadz[i] = 0;
- }
- fake_current_js_state(newDevice);
/* Create copy of default data format */
if (!(df = HeapAlloc(GetProcessHeap(), 0, c_dfDIJoystick2.dwSize))) goto
failed;
@@ -395,19 +375,31 @@ static JoystickImpl *alloc_de
Re: [dinput][joystick_linuxinput] make axes work, that are "not in a row"
On Thu, Jan 11, 2007 at 01:10:21PM -0700, Vitaliy Margolen wrote: > What you described is SetProperty(DIPROP_RANGE). What I'm talking about > is the range we get from device itself. In the map_axis we have: > > if (val > hmax) This->joydev->havemax[axis] = hmax = val; > if (val < hmin) This->joydev->havemin[axis] = hmin = val; to my knowledge this code is useless. it got copied over from the /dev/js branch. > We either need to query the device for what it's ranges are, or use > default range (as it's done in joystick_linux). we allready query it. see the code in alloc_device where the have(min|max) is set. > Right. But can we query device for the current axes position? They are > analog devices, and should provide absolute position. well instead of using ...[AXE_ABS] (another axe) we could use the current value from the device. what it is worth for is this: i bet nearly all apps just call alloc_device and SetProperty in the beginning or when some config is involved. so AXE_ABS is for sure between MIN/MAX (kernel should assert that) and in nearly all cases represent the "null"-state of the device. so if someone fiddles with this input device between find_joydevs and alloc/setprop the value in DJOYSTATE2 would be wrong. IMHO its not worth the hastle there. -- cu pgpUO8nG79M4C.pgp Description: PGP signature
Re: [PATCH 1/1] msi: MsiGetPropertyA return wrong length when called from a custom action.
Dmitry Timoshkov wrote: Does behaviour of MsiGetPropertyA and MsiGetPropertyW differ in that case? I'd be interested to have a look at the test case. I've put the test case up here: http://mandoo.dyndns.org/msitest.zip +TlsSetValue( tls_slot, (void*) 1 ); Shouldn't this be reset to 0 once a custom action has finished? The thread running the custom action terminates immediately after the custom action finishes, so there shouldn't be any need to reset the tls value. Mike
