December 2014 - Wine-Devel - list.winehq.org

Re: [PATCH] winealsa: support up to 6 channels

by Chris Robinson

On 12/31/2014 01:34 PM, Mark Harmstone wrote: > Needed for surround sound. ALSA uses a different channel mapping for 5.1 than Windows. Windows wants: front-left, front-right, front-center, lfe, back-left*, back-right* while ALSA wants: front-left, front-right, back-left*, back-right*, front-center, lfe So you can't just pass the samples through without swapping them. * This is complicated by the fact that some 5.1 setups use the side channels instead of the back channels, and with the side channels the mappings are the same for both: front-left, front-right, front-center, lfe, side-left, side-right Technically 5.1 is supposed to use the side channels according to Dolby, but until recently Windows has used back and many speakers are color-coded to match the surround speakers to the back speaker jacks. The newer enumerant DSSPEAKER_5POINT1_SURROUND indicates it's using side channels, while the older DSSPEAKER_5POINT1 (aka DSSPEAKER_5POINT1_BACK) indicates the back channels.

Dec. 31, 2014

Re: po: Update Portuguese translation

by Bruno Jesus

On Wed, Dec 31, 2014 at 5:11 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > On Wed, Mar 5, 2014 at 9:48 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: >> > > Sorry, the subtitle is wrong. Please prefer the update version. Oops... Sorry, my bad, I didn't notice the email date. I thought I had the wrong subject for the translation email I sent a some minutes ago. I guess I should go party instead of writing patches.

Dec. 31, 2014

Re: po: Update Portuguese translation

by Bruno Jesus

On Wed, Mar 5, 2014 at 9:48 PM, Bruno Jesus <00cpxxx(a)gmail.com> wrote: > Sorry, the subtitle is wrong. Please prefer the update version.

Dec. 31, 2014

Re: Unicode Support in wine-devel

by Gediminas Jakutis

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014.12.31 20:14, 中川祥 wrote: > This mailing list does not support any chinise and japanese character, so > we cannot help feeling discriminated. > I can see those working fine on this mailing list both through my mail client and through both of the online mailing list browsers ( https://www.winehq.org/pipermail/wine-devel/ && http://news.gmane.org/gmane.comp.emulators.wine.devel ) So, are You sure there is an actual problem? - -- Gediminas Jakutis LDK Varčiai www.varciai.lt -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUpEAHAAoJELhjTCLWLhIFpcYP/RP6BWgQNJ1vo+lnT3lnalNr ts+xtTfDhpEw7A/dhx+Kc2UjmUsWqAx89Qg4HiXEEeq1P4ySTKZUlp0/ovy3d8Qa EigZ+uubQmJGwSMuPP+h43kYARhVhv6G/hLyLFz8okT6vij7b83mKdtnw0iCRrtF tkR2OH70HDBAx8AhfwzWPd2VyjlZZvICkvFxniOutMLFEnYFdlDmez0h2eBPYr7m fsiIUoT2gN83tw3lCcLsurQkAGaSM1o2JkI7frLolb3XL0uYT9NQZ5m9dKpATfJH 77LPsdBg7moX71Dg0Z2Fx6mezNh476YDjROQg013H89pQFEuWan8bX79QdMr0eJo bvjKIgH6OP3LYpLWyNqYT/VfCHFXt0ue4iphPivbIxEsMykW5bqnaPlUcJ9mPNtX O+4pKHRBl6iMGuP5WZliI6tSExc98Uvr3bytVTNX4D/fd5fgx8q8ldfMDfMiA2iU c4njZrSpKjMUmX27oAgXJGM5erW1bNVxej2l2Mz4lhZwIBBgejkQuyqb8OqLb5I+ QoepnPr+R2UV//XCGu9B+ZJdbs7D2jmngcgxnNfp00akSHYDlhXO0pTLy8wBW1na KDvSpFaNJHC9Ypm9INAjk2mdkL7ovaXaB55FjW7O5VmNXtzPoxggHV5v382tzeSA 6Qc2mbVxQHPCQO2hv/bM =7YMS -----END PGP SIGNATURE-----

Dec. 31, 2014

Unicode Support in wine-devel

by 中川祥

This mailing list does not support any chinise and japanese character, so we cannot help feeling discriminated.

Dec. 31, 2014

Re: FOSDEM 2015

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-12-29 um 18:12 schrieb Jeremy White: > How about if we appoint Stefan in charge of coordinating this? > > Stefan, when you have a more clear idea of who/what/when/how much, > how about if you drop a private line to me, Michael, Marcus, > Austin, and Alexandre for us to decide on the funding. I don't quite understand what you mean with "who/what/when/how much". I guess the "when" is clear - FOSDEM is on January 31st and February 1st. With "who", do you mean who will go, or who I plan to talk to on FOSDEM. If it's the former I guess mails sent to wine-devel or to me stating interest (or lack thereof) should answer this. I can try to actively ask some people, but I expect that those who are interested are reading the list anyway. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUpB5eAAoJEN0/YqbEcdMw8jkP/Ao8LDo4VZkf/f990Ptx7kvV WQSJDPo4KeoZg64KxsKP8isbNKB1IOumzKhAccutQudIthxYC2C3UG3xppunBIFd 0C3Kxu3gcRg9g9rnqCibMICAd98v+Vc5SQDRKKjVERd+VVL69PQZJ60+SEZqDZVl LWqQa2FX/rjvZCGmpGoSW22xjXoIuH5+tY39sSzEnx0BY8qptSv6lrSqi0G3auQc tAC76RmrizHL4FNAjOC/cbiXolh5hEPZ1BvpQ3VkZzxrLAJP2WUnYZEgqPFnX83u Jb9JvICWpLz/P15lsHa2gUZP5F+FyqVhP6zOn1Y/YWVtjlvgpAcmPKqtkXO7Z7ua 6/IUeOO4/OiEUUo2oNqaMNBB1S9SM1MGUyf2fCpM38hx+A7vp+6aHzBpy30LcwsW gKHBG/wC+Nu+d8FvkNkTrAqVOdIyuVleWkS5w1P5ZA5tIKeUL1D1Re3n7Vw0Q9q/ 1V0jR+fBc1zh3B8er5U8lBA1ZVUIR531w7T3madVE9xBuWSWOdgDcyhFPAeTLAr6 YDp3I5Pzg/K8SJOvEuuT8C2o4Uw6q3MkatZTMTNJWPVbkEmqONrEACEvgRW3z1zg P7k6bYxM9kUFx/bPGhYPkMqkrXCAhcKusNPic7WrGWfY3Hx0l73E1nEV9QwFTABW kCkYh2LiycXkHVslOjwu =eAnU -----END PGP SIGNATURE-----

Dec. 31, 2014

Re: [PATCH] msvcr120: Fixed a race condition in Concurrency::critical_section.

by Piotr Caban

On 12/31/14 00:45, Yifu Wang wrote: > @@ -380,11 +393,18 @@ void __thiscall critical_section_lock(critical_section *this) > memset(&q, 0, sizeof(q)); > last = InterlockedExchangePointer(&this->tail, &q); > if(last) { > + /* If last == &this->unk_active, the current thread might be racing setting > + * unk_active.next with another thread calling cs_set_head(). If the current > + * thread sets unk_active.next first, the data structure would be left in an > + * inconsistent state and causes hang. Spin waiting until unk_active.next > + * becomes NULL solves the race condition. > + */ > + if(last == &this->unk_active) > + spin_wait_for_next_null(&this->unk_active); > last->next = &q; > NtWaitForKeyedEvent(keyed_event, &q, 0, NULL); > } > > - this->unk_active.next = NULL; > if(InterlockedCompareExchangePointer(&this->tail, &this->unk_active, &q) != &q) > spin_wait_for_next_cs(&q); > cs_set_head(this, &q); There's still a race with your patch. There's no guarantee that this->unk_active.next != NULL before cs_set_head(this, &q) is called. Changing the place where cs_set_head is called should fix the issue in cleaner way: diff --git a/dlls/msvcrt/lock.c b/dlls/msvcrt/lock.c index 328b5b5..e2ebef3 100644 --- a/dlls/msvcrt/lock.c +++ b/dlls/msvcrt/lock.c @@ -384,10 +397,11 @@ void __thiscall critical_section_lock(critical_section *this) NtWaitForKeyedEvent(keyed_event, &q, 0, NULL); } - this->unk_active.next = NULL; - if(InterlockedCompareExchangePointer(&this->tail, &this->unk_active, &q) != &q) - spin_wait_for_next_cs(&q); cs_set_head(this, &q); + if(InterlockedCompareExchangePointer(&this->tail, &this->unk_active, &q) != &q) { + spin_wait_for_next_cs(&q); + this->unk_active.next = q.next; + } } /* ?try_lock(a)critical_section@Concurrency@@QAE_NXZ */ There's also similar race in critical_section_try_lock and critical_section_try_lock_for function. Could you please also fix it there? Thank you, Piotr

Dec. 31, 2014

Re: wininet: Handle CERT_TRUST_IS_NOT_SIGNATURE_VALID in netconn_verify_cert()

by 中川祥

Yes.it will fix, but the function is not implemented yet,too. On 2014年12月31日(水) PM2:47 Bruno Jesus <00cpxxx(a)gmail.com> wrote: > The application hits a CERT_TRUST_IS_NOT_SIGNATURE_VALID, and only > passes the flag SECURITY_FLAG_IGNORE_UNKNOWN_CA. Currently wine is not > able to ignore this error and aborts. > > This is an extension to the work added by commit > http://source.winehq.org/git/wine.git/commitdiff/ > e2a9511b30e5b68eb328c08ffecf56dcc91bce0b > > Fixes https://bugs.winehq.org/show_bug.cgi?id=36785 > >

Dec. 31, 2014

Re: 答复: zh_CN Translation Submittion

by Juan Lang

Hi Jactry, I'll comment on the one I know something about: On Sat, Dec 20, 2014 at 7:43 AM, Jactry Zeng <jactry92(a)gmail.com> wrote: > #: crypt32.rc:41 > msgid "Enhanced Key Usage" > -msgstr "" > +msgstr "高级键值使用" > > I'm not sure is 'key' here same as 'key'(秘钥) in 'Public Key', or 'key > value'(键) in Registry. > Key here is as in "Public Key" in this instance. --Juan

Dec. 30, 2014

Re: secur32: Add support for ECDHE algorithms using gnutls

by Jacek Caban

Hi Sean, On 12/30/14 00:08, Sean Burke wrote: > diff --git a/dlls/secur32/schannel_gnutls.c b/dlls/secur32/schannel_gnutls.c > index 638b3c5..810c598 100644 > --- a/dlls/secur32/schannel_gnutls.c > +++ b/dlls/secur32/schannel_gnutls.c > @@ -328,6 +328,8 @@ static ALG_ID schannel_get_kx_algid(gnutls_kx_algorithm_t kx) > switch (kx) > { > case GNUTLS_KX_RSA: return CALG_RSA_KEYX; > + case GNUTLS_KX_ECDHE_ECDSA: Shouldn't this case use CALG_ECDSA? > + case GNUTLS_KX_ECDHE_RSA: return CALG_ECDH; > case GNUTLS_KX_DHE_DSS: > case GNUTLS_KX_DHE_RSA: return CALG_DH_EPHEM; > default: Cheers, Jacek

Dec. 30, 2014