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

Re: Do we need a forum?

by Tom Wickline

On Sat, Feb 23, 2008 at 1:13 AM, L. Rahyen <research(a)science.su> wrote: > > > As for registration, every forum ive ever visited asked for registration, > > sorry but I don't understand what your asking for? > > > > Tom > > Well, there is some forums which provides "quick reply" form at the bottom of > the thread (on any of its pages). If you are logged in, you can type text > there and then submit it as usually. If you are not logged in, you will be > able to enter your nickname, protection code and text with your reply. > Protection code is intended as protection from "spam bots". Usually, > protection code provided as somewhat noisy image with few digits and user > should recognize them and enter correctly in the "protection code" field. > Sometimes additional optional fields with password is provided so user can > login and send an answer simultaneously. If he/she leave password field blank > then reply is posted anyway with provided nickname but with "guest" settings > (such as default avatar for all guests or not avatar at all, etc.) and guest > privileges. Sometimes nickname collisions are allowed, sometimes not. > Typically it is good idea to make "guest" settings in the way that clearly > marks all guest posts as such. > However, depending on the code base of a forum, it may be simple to integrate > such a feature, or hard. > > But registration is one-time problem, especially for people who just want to > ask one question or answer to some topic (that was found using Google for > example) and don't plan to use the forum frequently. And many people can > consider this as "minor" issue. > More important problem is lack of ability to subscribe for all messages from > the forum as as well as inability to answer via standard mail client. These > problems are most important. wine-forum.org doesn't provide such > functionality. It would be great if this is fixed. > *At least* there should be possibility to subscribe to all messages from the > forum and possibility to answer by clicking on the link (to the reply form on > the forum) in each e-mail message from the forum (direct processing of the > e-mail answers is even better but can be harder to implement). It is also > important that after you logged in you don't need to login every time again > and there is no short timeout (use of cookies is necessary for this to work). > But I have no idea how hard/easy will be to implement these features on > wine-forum.org because I know very little about vBulletin used by wine-forum. > > I think that recently created http://forum.winehq.org/ seems to be the best > solution. Registration there isn't a problem because anyone can write a > message directly to the mailing list without registration on the forum. This > is exactly what I imagine as a perfect solution suitable for all users: > everyone can post answers without logging in (via the mailing list), > everybody can use forum or mailing list (depending on personal choice), and > it is possible to receive and answer using any e-mail client you like. So I > think winehq.org now have very good forum with nice sync with wine-users > mailing list! I really like it. In fact it solves all major problems that I > mentioned in my previous messages! > http://forum.winehq.org/viewtopic.php?t=52 I sincerely wish you guys the best fighting off the spam assault :D Cheers, Tom P.S. Hows that song go?....... You ain't seen nothing yet!

Feb. 24, 2008

Re: d3dx9: Add stubs for the ID3DXFont functions [PATCH 5/9, try 2]

by tony.wasserka＠freenet.de

> You have fixed object to *object, what about other places with > a similar problem? Also, the stubs have to use FIXME not TRACE, > and if you do nothing with a passed in parameter, don't assign > it to an internal variable. There is no need to cast NULL either. > If you allocate memory on object creation, you must free it on > object destruction. There is no need to initialize 'object' to > NULL if on the next line you are doing an attempt to allocate it. > What's the point of adding all those includes to d3dx9_36_private.h > if you are not using them? Thanks for that detailed response :) I have fixed what you said and have attached the fixed patch to this mail. The added includes prevented the compilation from failing, but some of them were really not needed as you pointed out. If there won't be any criticisms until tomorrow afternoon I'll resend it to wine-patches.

Feb. 24, 2008

Re: Wine and PulseAudio

by Tomas Carnecky

Jan Zerebecki wrote: > On Sun, Feb 24, 2008 at 12:05:46PM +0100, Tomas Carnecky wrote: >> All wine apps are identified as 'ALSA plug-in [wine-preloader]' in the >> PA daemon, so you can't set per-app volume and sinks since all wine apps >> show up under the same name. That is a technical limitation of the alsa >> plugin and can't be fixed (well, unless the plugin does some /proc/self >> voodoo to extract the true name). However that does not make the plugin >> unusable, but per-app settings is a major functionality of PA, so it's >> kind of bad if that doesn't work. > > I'm not sure if /proc/self is the right way to implement this but > in some way it should be made possible with the alsa->PA plugin. > > (Why isn't the changed process name used, that is also shown by > ps? Perhaps it should be implemented by using a environment > variable and/or argument to the alsa->PA plugin, that would also > allow the following feature?) http://www.pulseaudio.org/browser/trunk/src/pulse/util.c#L160 Basically uses readlink("/proc/self/exe") and if that fails the falls back to prctl(PR_GET_NAME). > Does PA (when used "directly") also always use the original > process name? I imagine I'm not the only one who would want to > have a bit more configurability there (some processes with the > same executable should probably not share the same settings and > the other way around). When a PA client connects to the daemon it can specify the context name (a name identifying the application) and each stream also has a name (the alsa pulse plugin sets that to "PCM Playback" for playback streams). Each client can choose its own name, the alsa pulse plugin extracts the name like described above, applications that use PA natively usually choose a fixed name: mplayer uses "MPlayer", netscape flash uses "Adobe Flash" etc. >> I have gotten winealsa to work with a patched alsa pulse plugin, but >> whether my patch will be accepted remains uncertain. There are some >> fundamental differences between ALSA and PA, for example ALSA uses >> frames and PA uses microseconds and I suspect there are rounding issues >> involved that make winealsa hang in certain situations. I'll need some >> help from the PA developers to fix that, but so far it's been quite >> difficult to get hold of them. > > We should really get those things that are wrong in either > winealsa or PA fixed. (Assuming the PA developers are interested...) > > AFAIK bug #10942 and at least the part of bug #10910 about "Could > not find 'PCM Playback Volume' element" are things that need > fixing in winealsa. See http://www.pulseaudio.org/ticket/198 what the pulse devs think of that issue. tom

Feb. 24, 2008

Re: Wine and PulseAudio

by Jan Zerebecki

On Sun, Feb 24, 2008 at 12:05:46PM +0100, Tomas Carnecky wrote: > All wine apps are identified as 'ALSA plug-in [wine-preloader]' in the > PA daemon, so you can't set per-app volume and sinks since all wine apps > show up under the same name. That is a technical limitation of the alsa > plugin and can't be fixed (well, unless the plugin does some /proc/self > voodoo to extract the true name). However that does not make the plugin > unusable, but per-app settings is a major functionality of PA, so it's > kind of bad if that doesn't work. I'm not sure if /proc/self is the right way to implement this but in some way it should be made possible with the alsa->PA plugin. (Why isn't the changed process name used, that is also shown by ps? Perhaps it should be implemented by using a environment variable and/or argument to the alsa->PA plugin, that would also allow the following feature?) Does PA (when used "directly") also always use the original process name? I imagine I'm not the only one who would want to have a bit more configurability there (some processes with the same executable should probably not share the same settings and the other way around). > I have gotten winealsa to work with a patched alsa pulse plugin, but > whether my patch will be accepted remains uncertain. There are some > fundamental differences between ALSA and PA, for example ALSA uses > frames and PA uses microseconds and I suspect there are rounding issues > involved that make winealsa hang in certain situations. I'll need some > help from the PA developers to fix that, but so far it's been quite > difficult to get hold of them. We should really get those things that are wrong in either winealsa or PA fixed. (Assuming the PA developers are interested...) AFAIK bug #10942 and at least the part of bug #10910 about "Could not find 'PCM Playback Volume' element" are things that need fixing in winealsa. Jan

Feb. 24, 2008

Re: d3dx9: Add stubs for the ID3DXFont functions [PATCH 5/9, try 2]

by Dmitry Timoshkov

<tony.wasserka(a)freenet.de> wrote: > Replaced the S_OKs with D3D_OKs, moved the QueryInterface TRACE out of the if condition > and replaced object by *object. You have fixed object to *object, what about other places with a similar problem? Also, the stubs have to use FIXME not TRACE, and if you do nothing with a passed in parameter, don't assign it to an internal variable. There is no need to cast NULL either. If you allocate memory on object creation, you must free it on object destruction. There is no need to initialize 'object' to NULL if on the next line you are doing an attempt to allocate it. What's the point of adding all those includes to d3dx9_36_private.h if you are not using them? -- Dmitry.

Feb. 24, 2008

Re: Wine and PulseAudio

by Tomas Carnecky

Jan Zerebecki wrote: > On Fri, Feb 22, 2008 at 01:50:09AM +0100, Tomas Carnecky wrote: >> nifty features, like per-app volume, transparent sink switching >> etc, some of which are impossible to emulate through the alsa >> pulse plugin. > > Which features can't be used through the alsa->pulse plugin? And > is there any technical reason for that or just missing > functionality in that plugin? All wine apps are identified as 'ALSA plug-in [wine-preloader]' in the PA daemon, so you can't set per-app volume and sinks since all wine apps show up under the same name. That is a technical limitation of the alsa plugin and can't be fixed (well, unless the plugin does some /proc/self voodoo to extract the true name). However that does not make the plugin unusable, but per-app settings is a major functionality of PA, so it's kind of bad if that doesn't work. I have gotten winealsa to work with a patched alsa pulse plugin, but whether my patch will be accepted remains uncertain. There are some fundamental differences between ALSA and PA, for example ALSA uses frames and PA uses microseconds and I suspect there are rounding issues involved that make winealsa hang in certain situations. I'll need some help from the PA developers to fix that, but so far it's been quite difficult to get hold of them. tom

Feb. 24, 2008

Re: Wine and PulseAudio

by Tomas Carnecky

Stefan Dösinger wrote: > Am Freitag, 22. Februar 2008 01:50:09 schrieb Tomas Carnecky: >> I switched my desktop to PA yesterday, got most apps working, and to my >> surprise even flash (netscape 32bit plugin in a 64bit browser). All apps >> that I need use PA natively, only Wine doesn't have a PA sound driver. > The point was and is that we don't want yet another half working sound backend > in Wine. We will have to maintain the Alsa one because there are things PA > won't be able to give us by design, like HW mixing and lowest-latency direct > access which is needed for gaming. HW mixing is overrated :) Current CPUs can do the mixing just as well, if not with a even better quality. I don't say it's useless as I'm sure professionals have a good reason to use high-end cards with high-quality mixers (but they should use wineasio or winejack anyway). Also, PA ideally only adds less then 1ms of latency, that's hardly an issue, even in gaming. Mind you, I don't say winealsa should go away, I'm just saying PA isn't as bad as it looks. > Of course, as you said, if someone has patches and intends to maintain it > we're happy to accept it. But I think none of the current Wine sound > developers(aka Maarten) has any intentions to spend time on a PA backend. Wineasio is maintained as an external component, so I guess winepulse could be too. There are enough free git repo providers around. tom

Feb. 24, 2008

Re: d3dx9: Add stubs for the ID3DXRenderToSurface functions [PATCH8/9]

by H. Verbeet

<tony.wasserka(a)freenet.de> wrote: > Thank you very much for pointing that out :) > Is there anything else wrong with it or can I resend the patches? A minor issue could be that you're returning S_OK in most of the stubs. For the IUnknown stuff that's correct, but D3D stuff typically returns D3D_OK. Although S_OK and D3D_OK have the same value, using D3D_OK would be a bit more consistent once you start returning eg. D3DERR_INVALIDCALL on error conditions.

Feb. 24, 2008

Re: d3dx9: Add stubs for the ID3DXRenderToSurface functions [PATCH8/9]

by Dmitry Timoshkov

<tony.wasserka(a)freenet.de> wrote: > Thank you very much for pointing that out :) > Is there anything else wrong with it or can I resend the patches? You may try with smaller patches first, and send them one by one, waiting for the previous one being committed. -- Dmitry.

Feb. 24, 2008

Re: d3dx9: Add stubs for the ID3DXRenderToSurface functions [PATCH 8/9]

by tony.wasserka＠freenet.de

> Shouldn't that be a n (here and in the other patches)? > Setting object to NULL here doesn't do a whole lot, you should set > *object to NULL (also goes for the other QueryInterface > implementations). Also, you'll probably want to put the TRACE before > the if block. Thank you very much for pointing that out :) Is there anything else wrong with it or can I resend the patches? Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

Feb. 24, 2008