February 2012 - Wine-Devel - list.winehq.org

Re: [PATCH] winepulse: Add pulse driver, v8

by Charles Davis

On Feb 28, 2012, at 10:58 PM, Chris Robinson wrote: > On Tuesday, February 28, 2012 5:32:13 PM Maarten Lankhorst wrote: >> + * This is basically the same as the pa_threaded_mainloop implementation, >> + * but that cannot be used because it uses pthread_create directly >> + * >> + * pa_threaded_mainloop_(un)lock -> pthread_mutex_(un)lock >> + * pa_threaded_mainloop_signal -> pthread_cond_signal >> + * pa_threaded_mainloop_wait -> pthread_cond_wait > > I'm curious why you're using pthreads. Doesn't WinAPI have anything comparable > to pthread_cond_wait? It does: http://msdn.microsoft.com/en-us/library/ms686301(v=vs.85).aspx For some reason, the condition variable API just hasn't been implemented in Wine yet. Chip

Feb. 29, 2012

Re: [PATCH] winepulse: Add pulse driver, v8

by Chris Robinson

On Tuesday, February 28, 2012 5:32:13 PM Maarten Lankhorst wrote: > + * This is basically the same as the pa_threaded_mainloop implementation, > + * but that cannot be used because it uses pthread_create directly > + * > + * pa_threaded_mainloop_(un)lock -> pthread_mutex_(un)lock > + * pa_threaded_mainloop_signal -> pthread_cond_signal > + * pa_threaded_mainloop_wait -> pthread_cond_wait I'm curious why you're using pthreads. Doesn't WinAPI have anything comparable to pthread_cond_wait? > +static void pulse_probe_settings(void) { ... > + ret = pa_stream_connect_playback(stream, NULL, &attr, > + PA_STREAM_START_CORKED|PA_STREAM_FIX_RATE|PA_STREAM_FIX_FORMAT|PA_S > TREAM_FIX_CHANNELS|PA_STREAM_EARLY_REQUESTS, NULL, NULL); Is it necessary to fix the format? MSDN says that the audio service always works with floating-point, and GetMixFormat always specified floating-point in my dealings with it. I don't think it should blindly return whatever PulseAudio does, unless it can be shown that Windows doesn't always give floating-point. > +static WAVEFORMATEX *clone_format(const WAVEFORMATEX *fmt) > +{ > + WAVEFORMATEX *ret; > + size_t size; > + > + if (fmt->wFormatTag == WAVE_FORMAT_EXTENSIBLE) > + size = sizeof(WAVEFORMATEXTENSIBLE); > + else > + size = sizeof(WAVEFORMATEX); > + > + ret = HeapAlloc(GetProcessHeap(), 0, size); This should probably use CoTaskMemAlloc, as it's used for IsFormatSupported. I'm also curious if IsFormatSupported should always return a WAVE_FORMAT_EXTENSIBLE object. > +static enum pa_channel_position pulse_map[] = { This should probably be const. > + if (fmt->wFormatTag == WAVE_FORMAT_IEEE_FLOAT) > + This->ss.format = PA_SAMPLE_FLOAT32LE; ... > + if (IsEqualGUID(&wfe->SubFormat, &KSDATAFORMAT_SUBTYPE_IEEE_FLOAT)) > + This->ss.format = PA_SAMPLE_FLOAT32LE; You likely should check that the format specifies 32 bits, and not 64 or something different like that. This isn't an all-inclusive lookover, just some things that caught my eye. Also, does this driver fail to load if it can't connect to a pulse server?

Feb. 29, 2012

Re: [PATCH] README: updated Linux and FreeBSD kernels

by Marcus Meissner

On Wed, Feb 22, 2012 at 10:44:31AM +0100, Francois Gouget wrote: > On Wed, 22 Feb 2012, Marcus Meissner wrote: > > > --- > > README | 13 ++++++------- > > 1 files changed, 6 insertions(+), 7 deletions(-) > > > > diff --git a/README b/README > > index baa6ab3..0cbb047 100644 > > --- a/README > > +++ b/README > > @@ -29,7 +29,7 @@ especially the wealth of information found at http://www.winehq.org. > > To compile and run Wine, you must have one of the following: > > > > Linux version 2.0.36 or above > > - FreeBSD 6.3 or later > > + FreeBSD 8.0 or later > [...] > > FreeBSD info: > > - Wine will generally not work properly on versions before FreeBSD > > - 6.3 or 7.0, and FreeBSD 6.3 has additional patches available. See > > - http://wiki.freebsd.org/Wine for more information. > > + Wine will generally not work properly on versions before FreeBSD 8.0. > > + See http://wiki.freebsd.org/Wine for more information. > > Is there a reason why Wine won't work right on FreeBSD 7.0? > Winetest seems mostly ok. > http://test.winehq.org/data/f43f37d3613db57c732196f88e1225191cd62c30/index_… I followed the note on http://wiki.freebsd.org/Wine who does not mention older versions than 8.0. I have no other information. Ciuao, Marcus

Feb. 29, 2012

Re: doc: Update Italian README

by Frédéric Delanoy

2012/2/28 Luca Bennati <lucak3(a)gmail.com>: > I tried converting README.it to UTF8, instead of the current Extended ASCII, > which works really bad on my system. > However, it does not seems like Git caught this change: could this be done > manually? I applied the patch manually and it seems the conversion went fine. Maybe there were some accentuated letters already. (hint: 'iconv' can be useful for those kind of conversions, or a save with your favorite editor) BTW, -6. ESEGUIRE I PROGRAMMI +6. RUNNING PROGRAMS seems wrong... Frédéric

Feb. 28, 2012

Re: Web based translation tool

by Yaron Shahrabani

OK, I came up with something. We can lock up the wiki registration and the Admin will have to approve each and every translator manually (TranslateWiki works that way when you want to contribute to MediaWiki). That way the user will have to provide his/her real name upon registration. There's also a possibility that the registration will remain open but the main coordinator will have to approve each translator manually, just like what Siebrand does. Well, there are plenty of possibilities... Having a distinct TranslateWiki instance is not such a bad idea... (This way the current rules won't be applied). What else can I check for you guys? Kind regards, Yaron Shahrabani <Hebrew translator> On Tue, Feb 28, 2012 at 3:03 PM, Aric Stewart <aric(a)codeweavers.com> wrote: > Hi, > > I have had quite a long discussion with the TranslateWiki people. They > are great and while what we need would require a bit of PHP development > they expressed that they would be happy to do the work. > > The main sticking block is that our requirement for Real Names and e-mail > for all contributors runs contrary to their privacy policy. So we would not > be able to get that information in our patches. > > They are currently exploring that idea and we are in continued discussion > about this. If we can get around that road block then they may be our best > option. > > Transifex's Dimitris Glezos has also been very communicative with me, and > very helpful, however Transifex does not actually do PO management > converting the POs into their own database format and requiring developers > to have a client tool to be able to get and push the translations. That > could be done by a translation manager who would then generate all the > patches and mail them with the proper credit. However he still has not > answered my basic question of if we would be able to get that information. > > So I am still actively following up on these leads and hopefully something > will work out. > > -aric > > > On 2/28/12 1:42 AM, Yaron Shahrabani wrote: > >> Hi guys! >> >> If I understand correctly the wanted solution is the translation >> attribution will be per string basis meaning that we can attribute a >> certain author to a string. >> >> The only system I'm aware of that is capable of such thing is >> TranslateWiki, which is a little overkill because we will have to use a >> full wiki system in order to implement gettext (which can be done using >> a much less sophisticated system). >> >> Since the Wine project already has a Wiki, maybe we can utilize this >> wiki in order to install TranslateWiki. >> >> There are several advantages: >> 1. The strings are saved just like wiki pages meaning that there's a >> full history and diff of all strings including dates and authors. >> 2. The statistics are great (The current statistics is nice as well but >> contains less info). >> 3. It's a full wiki system (Both advantage and disadvantage). >> >> None of the other systems can attribute a certain translation to a >> certain author AFAICT. >> >> Kind regards, >> YaronShahrabani >> >> <Hebrew translator> >> >> >> >> >> 2012/2/27 Miroslav Suchý <msuchy(a)redhat.com <mailto:msuchy(a)redhat.com>> >> >> Hi, >> I just read: >> http://www.winehq.org/news/__**2012022001<http://www.winehq.org/news/__2012022001> >> <http://www.winehq.org/news/**2012022001<http://www.winehq.org/news/2012022001> >> > >> and then >> http://wiki.winehq.org/__**Translating<http://wiki.winehq.org/__Translating> >> >> <http://wiki.winehq.org/**Translating<http://wiki.winehq.org/Translating> >> > >> especially: >> >> The Wine project would be very interested in making its PO files >> available on web-based community translations systems such as >> Pootle or Launchpad. Our hope is that this would make >> translating Wine even easier and engage new translators. >> >> The reason why it has not happened yet is that all Wine >> contributions, including for translations, must be attributable >> to a specific author and that these tools don't make that >> possible yet. For more details see the wine-devel discussion >> here and here. Any contributions that would solve this issue >> would be very welcome. >> >> >> which refer: >> http://www.winehq.org/__**pipermail/wine-devel/2012-__** >> January/093908.html<http://www.winehq.org/__pipermail/wine-devel/2012-__January/093908.html> >> >> <http://www.winehq.org/**pipermail/wine-devel/2012-** >> January/093908.html<http://www.winehq.org/pipermail/wine-devel/2012-January/093908.html> >> > >> >> I would like to point you to: >> https://www.transifex.net/ >> which can do the tracking. >> >> Latest version is probably not what you want, because it just add at >> the top of the file: >> # Translators: >> # Martin Minar <skulliq(a)gmail.com <mailto:skulliq(a)gmail.com>>, 2011 >> <tel:2011>. >> # Milan Kerslager <kerslage(a)linux.cz <mailto:kerslage(a)linux.cz>>, >> 2002 <tel:2002>, 2007 <tel:2007>. >> # Miloslav Trmac <mitr(a)volny.cz <mailto:mitr(a)volny.cz>>, 2002 >> <tel:2002>. >> # Miroslav Suchý <msuchy(a)redhat.com <mailto:msuchy(a)redhat.com>>, >> 2011 <tel:2011>. >> >> msgid "" >> msgstr "" >> "Project-Id-Version: Spacewalk\n" >> "Report-Msgid-Bugs-To: \n" >> "POT-Creation-Date: 2011-12-21 13:07+0100\n" >> "PO-Revision-Date: 2011-12-14 09:21+0000\n" >> "Last-Translator: Miroslav Suchý <msuchy(a)redhat.com >> <mailto:msuchy(a)redhat.com>>\n" >> "Language-Team: Czech >> (http://www.transifex.net/__**projects/p/fedora/team/cs/<http://www.transifex.net/__projects/p/fedora/team/cs/> >> <http://www.transifex.net/**projects/p/fedora/team/cs/<http://www.transifex.net/projects/p/fedora/team/cs/> >> >)\n >> >> >> So you had overview of contributors, but you could not tell which >> one contributor done which string. >> >> But version 0.7 (IIRC) sent each contribution immediately to git. >> Under login (and email) of that contributor. That contributor was >> "Author" and commiter was some transifex user. So this way you allow >> git commit access to those contributors directly to git, but since >> it goes via that web interface, they could commit only to /po/ >> directory and even only to language, for which they had been granted. >> >> You can download it here: >> http://trac.transifex.org/__**files/<http://trac.transifex.org/__files/>< >> http://trac.transifex.org/**files/ <http://trac.transifex.org/files/>> >> >> and setup your own instance. >> >> If is sufficient for you only tracking name of contributors, you can >> use that hosted solution at: https://www.transifex.net/ >> >> >> -- >> Miroslav Suchy >> Red Hat Satellite Engineering >> >> >> >> >> >> >> > >

Feb. 28, 2012

Re: [PATCH] winepulse: Add pulse driver, v8

by Dmitry Timoshkov

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > >From 8aa5903b1ee75a6c538d7e1d99560bcb39a47ed2 Mon Sep 17 00:00:00 2001 > From: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> > Date: Thu, 28 Apr 2011 09:45:18 +0200 > Subject: [PATCH 10/10] winepulse: Add pulse driver, v8 You forgot to fix the date, 1 Apr would be more appropriate I'd guess. -- Dmitry.

Feb. 28, 2012

Re: [PATCH] winepulse: Add pulse driver, v8

by Maarten Lankhorst

Hey Dmitry, Op 28-02-12 18:42, Dmitry Timoshkov schreef: > Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > >> >From 8aa5903b1ee75a6c538d7e1d99560bcb39a47ed2 Mon Sep 17 00:00:00 2001 >> From: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> >> Date: Thu, 28 Apr 2011 09:45:18 +0200 >> Subject: [PATCH 10/10] winepulse: Add pulse driver, v8 > You forgot to fix the date, 1 Apr would be more appropriate I'd guess. > I'm surprised it used that date, but I'm no less serious about my intentions to get it included into wine. If you have any technical concerns I would be glad to hear them. ~Maarten

Feb. 28, 2012

Re: Major mmdevapi and winmm audio bugs

by Juan Lang

Hi Andrew, one small contribution: > Winmm's timer functions use poll() with a timeout value, subtracting > the time elapsed curing the callback. This works quite well in dsound. > > The Win32 API also provides the SetTimer API. But that depends on a > message queue, which is a hassle I don't know if we want to bother > with in the drivers (plus, it may be no more reliable than the > TimerQueues). Using SetTimer is not the way you want to go. Its timing is unpredictable and its interface strange. I'd stay away from it. --Juan

Feb. 28, 2012

Re: Major mmdevapi and winmm audio bugs

by Andrew Eikum

On Tue, Feb 28, 2012 at 08:24:37AM -0600, Andrew Eikum wrote: > I'm investigating native TimerQueue's operation now. If it turns out > that TimerQueue isn't sufficient, we'll probably just switch over to > using poll() like winmm's timer stuff does. > And, not too surprisingly, TimerQueue isn't sufficient. I've attached my tests here. The tests ask to execute the callback every 12 ms. On my Windows 7 VM, I found that it executed with intervals like: 20, 10, 10, 10, 10, 20, 10, 10, 10, 10, ... With an 11 occasionally interspersed. So, forget that. Winmm's timer functions use poll() with a timeout value, subtracting the time elapsed curing the callback. This works quite well in dsound. The Win32 API also provides the SetTimer API. But that depends on a message queue, which is a hassle I don't know if we want to bother with in the drivers (plus, it may be no more reliable than the TimerQueues). Since we're already using poll() in winmm and it seems to work well, that would be my suggestion. Any thoughts? Andrew

Feb. 28, 2012

Re: [PATCH 1/4] ddraw: Make D3DVBCAPS_WRITEONLY vertex buffers dynamic

by Stefan Dösinger

Am Dienstag, 28. Februar 2012, 14:51:06 schrieb Henri Verbeet: > Yes, but that's the other way around. If anything, that pdf suggests > that buffers are dynamic by default in ddraw. Making buffers dynamic by default in ddraw will disable rhw vertex and color conversion for ddraw apps. We could create non-dynamic buffers by default and destroy and recreate the wined3d buffer with the dynamic flag when the app uses DISCARDCONTENTS or NOOVERWRITE the first time.

Feb. 28, 2012