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

Re: PulseAudio as a sound output?

by Jan Zerebecki

On Wed, Oct 10, 2007 at 06:22:19PM -0500, King InuYasha wrote: > While PulseAudio can work through ALSA, it makes you lose the finer grains > of control over audio when it is sent through ALSA to PulseAudio. Then it seems that is a limitation of the alsa plugin pulseaudio provides. Fixing that plugin would not only benefit Wine when it uses pulseaudio through alsa but every application which might do this. Implementing a winepulseaudio would only bring that benefit to Wine and it would have to be duplicated for every other alsa application which pulseaudio would want to support. > It is also > redundant in most cases, since PulseAudio generally will be connected to > localhost to ALSA on localhost, so it is not very smart to rely on winealsa > to connect to PulseAudio. > Sending audio output through ALSA/OSS to > any audio server is basically redundant and pointless. Sending to the Audio > Server to ALSA/OSS is better. I guess you didn't want to say that the audio is sent over ip. Though I don't know how pulseaudio does things specifically, I do know what is technically possible. Passing data from one process to another on the same computer can be done without copying the data. Also passing the data into the alsa library which passes it into the hardware or dmix or the pulseaudio plugin does not involve two steps as you seem to suggest, but only one. Yes alsa->pulseaudio is an additional layer but you could think of it as a replacement of pulsaudio-api->pulseaudio. > That way, there isn't a conflict between audio > streams to send to audio output. Any mixing resolves this conflict, the only thing that does not support this is bare oss. Jan

Oct. 11, 2007

Re: Window decorations missing on Compiz/Debian Etch

by King InuYasha

Compiz has made a workaround available in git for this issue. http://gitweb.opencompositing.org/?p=fusion/plugins/workarounds;a=commit;h=… On 10/9/07, Alexandre Julliard <julliard(a)winehq.org> wrote: > > Michael Jung <mjung(a)iss.tu-darmstadt.de> writes: > > > It seems that the added "data->whole_window" check in the expression > > used to decide if a window has to be switched to managed mode causes > > this problem for me. > > > > data->whole_window is set in create_whole_window at window.c:1002 > > create_whole_window is called from X11DRV_CreateWindow at window.c:1292 > > > > data->whole_window is tested in X11DRV_SetWindowPos at winpos.c:251 > > X11DRV_SetWindowPos is called form X11DRV_CreateWindow at window.c:1287 > > > > Thus, it seems to me that this check happens before > > "data->whole_window" is initialized. Removing this check (as in the > > attached patch) resolves the issue for me. But this does not seem to > > be the correct solution, since the root desktop window is now flagged > > as "managed", which does not have any impact (at least for me), but > > which seem logically incorrect. > > That's just hiding the problem. If the window manager doesn't > reevaluate the wm hints when the window is mapped, many things won't > work. That's really a Compiz bug IMO. > > -- > Alexandre Julliard > julliard(a)winehq.org > > >

Oct. 10, 2007

Re: PulseAudio as a sound output?

by King InuYasha

While PulseAudio can work through ALSA, it makes you lose the finer grains of control over audio when it is sent through ALSA to PulseAudio. It is also redundant in most cases, since PulseAudio generally will be connected to localhost to ALSA on localhost, so it is not very smart to rely on winealsa to connect to PulseAudio. the wineesd component could be replaced with a winepulse component (just made up the name, winepulse) that would support the finer grains of control in the audio server. Stuff like the application based mixer could be handled through winepulse and allow Wine to control only its own audio stream. That way, there isn't a conflict between audio streams to send to audio output. Sending audio output through ALSA/OSS to any audio server is basically redundant and pointless. Sending to the Audio Server to ALSA/OSS is better. On 10/9/07, Jan Zerebecki <jan.wine(a)zerebecki.de> wrote: > > I agree that wineoss needs to remain. > > I don't remember anymore if there was still some reason for > keeping wineesd. > > Both jack and pulseaudio can provide alsa support for > applications. So in principle there is no reason for direct > support in wine for either of them. > > We might be able to get trough with also removing winejack and > winenas. winejack could be replaced with either wineasio (which > uses jack directly) or with winealsa -> jacks alsa plugin. The > main use case for winenas is network audio in a thin client > environment which I assume is also supported by pulseaudio where > we again can use winealsa -> pulseaudios alsa plugin. > > > Jan > > >

Oct. 10, 2007

Re: defining and revamping our bugzilla categories

by Jan Zerebecki

On Wed, Oct 10, 2007 at 03:52:36PM -0500, James Hawkins wrote: > On 10/10/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > > > > > > E.g. there is wine-quartz (one dll dlls/quartz/ ) and > > > > wine-directx-dshow (includes dlls/{quartz,msdmo,qcap}/ ). > > > > Well, the common (newbie) user probably won't know anything about dshow (neither > > do i ;) ), nor will he know what quartz stands for. That is why I suggest to add something like dlls/{quartz,msdmo,qcap}/ to the description of the component. > That's why wine-misc should be selected by default, and honestly it's > the responsibility of bugzilla maintainers/triagers to set and fix > components if the user doesn't know (which most don't). I agree, in the end we usually need to verify anyway that the component is correct. Jan

Oct. 10, 2007

Re: defining and revamping our bugzilla categories

by James Hawkins

On 10/10/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > James Hawkins <truiken <at> gmail.com> writes: > > > > > Currently we have some categories that exactly fit to one dll and > > > some categories that include multiple dlls that are related. Also > > > there is overlap between those two. (And perhaps some that fit in > > > neither.) > > > > > > E.g. there is wine-quartz (one dll dlls/quartz/ ) and > > > wine-directx-dshow (includes dlls/{quartz,msdmo,qcap}/ ). > > > > > > Well, the common (newbie) user probably won't know anything about dshow (neither > do i ;) ), nor will he know what quartz stands for. > That's why wine-misc should be selected by default, and honestly it's the responsibility of bugzilla maintainers/triagers to set and fix components if the user doesn't know (which most don't). -- James Hawkins

Oct. 10, 2007

Re: defining and revamping our bugzilla categories

by Louis Lenders

James Hawkins <truiken <at> gmail.com> writes: > > Currently we have some categories that exactly fit to one dll and > > some categories that include multiple dlls that are related. Also > > there is overlap between those two. (And perhaps some that fit in > > neither.) > > > > E.g. there is wine-quartz (one dll dlls/quartz/ ) and > > wine-directx-dshow (includes dlls/{quartz,msdmo,qcap}/ ). > > Well, the common (newbie) user probably won't know anything about dshow (neither do i ;) ), nor will he know what quartz stands for. The only thing he will see in his console is something like: fixme:quartz: blablabla So for example if he was about to search for duplicates before filing a bug, it's really better to have a per dll component. > One component per dll is ideal for development. > There are some situations where a group component works best, e.g. > directX. In most cases though, per dll is best. We can have both > types of components. The following is a list of components that need > to get the boot or be renamed: > > wine-rebar (this is comctl32, no need for this component) > wine-binary (what does that even mean?) > wine-gdi-(printing) -> gdi > wine-gui (per dll) > wine-multimedia (per dll) > wine-net (needs to be per dll) > wine-patches (what was this for?) > wine-user -> user32 > wine-usp10.dll -> usp10 > bug list, comments, login (what are these for?) > totally agree with James. I'll await the changes.....

Oct. 10, 2007

Wine at Systems in Munich

by David M. Gümbel

Hi everybody, it seems there ist still some space left for a Wine booth at the "Systems" exhibition in Munich[1], from october 23 to 26. They asked me, but I won't be able to make it this year. Nor will Kai. Would anybody be interested to represent the Wine project down there? Thanks && Cheers, David

Oct. 10, 2007

Re: defining and revamping our bugzilla categories

by James Hawkins

On 10/10/07, Jan Zerebecki <jan.wine(a)zerebecki.de> wrote: > I agree the wine- prefix should be removed. > > Currently we have quite some categories where I don't really know > how they are defined, so the description should be enhanced so > there is no confusion over what goes in them. > > Currently we have some categories that exactly fit to one dll and > some categories that include multiple dlls that are related. Also > there is overlap between those two. (And perhaps some that fit in > neither.) > > E.g. there is wine-quartz (one dll dlls/quartz/ ) and > wine-directx-dshow (includes dlls/{quartz,msdmo,qcap}/ ). > > The best is probably to have no overlap and have multi-dll/path > categories contain the shell-glob of path/files that it contains. > > I think in some cases multi-dll categories are preferable to > single-dlls ones. A even better example for this than dshow is > wine-directx-d3d, where before the bug is fixed it might not be > easily known if it is in d3d9 or wined3d and a bug might exist in > the same way in more than one d3d version. > > From previous discussions on irc I know some people want to have > a radical one category per dll approach, please speak up now. > > What do you guys think? > One component per dll is ideal for development. When we identify what dll a particular bug is in through triage, it helps any other developer that decides to pick up the bug and fix it. wine-gui is a terrible component. gui can mean any number of places to hunt down a bug. It would be great if people could help triage wine-gui bugs and fix the components. Eventually we should be at a point where we can get rid of the wine-gui component. wine-misc is the general place-holder component, and really should be selected as default in bugzilla for new reports. Concerning using one component per dll versus broad/group components, the way we have it now works fine. There are some situations where a group component works best, e.g. directX. In most cases though, per dll is best. We can have both types of components. The following is a list of components that need to get the boot or be renamed: wine-rebar (this is comctl32, no need for this component) wine-binary (what does that even mean?) wine-gdi-(printing) -> gdi wine-gui (per dll) wine-multimedia (per dll) wine-net (needs to be per dll) wine-patches (what was this for?) wine-user -> user32 wine-usp10.dll -> usp10 bug list, comments, login (what are these for?) -- James Hawkins

Oct. 10, 2007

Re: gdi32: Try to load Wine's TrueType fonts from the build directory.

by Alexandre Julliard

Huw Davies <huw(a)codeweavers.com> writes: > --- a/dlls/gdi32/freetype.c > +++ b/dlls/gdi32/freetype.c > @@ -2109,6 +2109,7 @@ BOOL WineEngInit(void) > > /* load the system truetype fonts */ > data_dir = wine_get_data_dir(); > + if(!data_dir) data_dir = wine_get_build_dir(); This causes a bunch of test failures here: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so font.c && touch font.ok font.c:174: Test succeeded inside todo block: 32 != 32 font.c:175: Test succeeded inside todo block: 26 != 26 font.c:176: Test succeeded inside todo block: 6 != 6 font.c:177: Test succeeded inside todo block: 21 != 21 font.c:182: Test succeeded inside todo block: 32 != 32 font.c:174: Test succeeded inside todo block: 48 != 48 font.c:175: Test succeeded inside todo block: 39 != 39 font.c:176: Test succeeded inside todo block: 9 != 9 font.c:182: Test succeeded inside todo block: 48 != 48 font.c:385: Test failed: MS Sans Serif(13): tm.tmInternalLeading 0 != 2 font.c:392: Test failed: MS Sans Serif(13): tm.tmMaxCharWidth 4 != 11 font.c:383: Test failed: MS Sans Serif(16): tm.tmAscent 14 != 13 font.c:384: Test failed: MS Sans Serif(16): tm.tmDescent 2 != 3 font.c:385: Test failed: MS Sans Serif(16): tm.tmInternalLeading 0 != 3 font.c:392: Test failed: MS Sans Serif(16): tm.tmMaxCharWidth 5 != 14 font.c:383: Test failed: MS Sans Serif(20): tm.tmAscent 17 != 16 font.c:384: Test failed: MS Sans Serif(20): tm.tmDescent 3 != 4 font.c:385: Test failed: MS Sans Serif(20): tm.tmInternalLeading 0 != 4 font.c:392: Test failed: MS Sans Serif(20): tm.tmMaxCharWidth 6 != 16 font.c:386: Test failed: Courier(13): tm.tmExternalLeading 1 != 0 font.c:392: Test failed: Courier(13): tm.tmMaxCharWidth 4 != 8 font.c:385: Test failed: System(16): tm.tmInternalLeading 0 != 3 font.c:386: Test failed: System(16): tm.tmExternalLeading 90 != 0 font.c:385: Test failed: Small Fonts(11): tm.tmInternalLeading 0 != 2 font.c:386: Test failed: Small Fonts(11): tm.tmExternalLeading 90 != 0 font.c:392: Test failed: Small Fonts(11): tm.tmMaxCharWidth 3 != 9 make: *** [font.ok] Error 26 -- Alexandre Julliard julliard(a)winehq.org

Oct. 10, 2007

Re: make test drill

by Alexandre Julliard

"H. Verbeet" <hverbeet(a)gmail.com> writes: > On 10/10/2007, Jeremy White <jwhite(a)codeweavers.com> wrote: >> I think a test that fails, or crashes a system because of a driver bug is a broken test. >> It's admittedly hard to write a test that will detect a vmware situation or driver >> bug and work around it, but I think that is what we should do. >> > At that point the only real option is keeping a list of blacklisted > video drivers (which some applications actually sort of do), but I'm > not sure we really want to go there. I do think we should investigate > native failures, and fix them if possible, but if tests fail because > eg. vmware has a broken d3d implementation, I think the test is > essentially doing what it should do. Yes, if the code is going to break in normal use too, then it's OK for the test to fail. It simply means the platform is useless both for regression testing and for normal apps that use the functionality. If we really have to add workarounds for broken drivers, this has to be done in the code, not in the tests. -- Alexandre Julliard julliard(a)winehq.org

Oct. 10, 2007