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

CSS changes to the Wiki

by Kai Blin

Hi folks, I seem to remember that someone posted a patch to the wiki's CSS that will stop the lists from looking ugly. I can't find that patch, though. Can someone point me at it? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Oct. 10, 2007

Re: make test drill

by Stefan Dösinger

Am Mittwoch, 10. Oktober 2007 10:07:58 schrieb Steven Edwards: > On 10/10/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > > But isn't introducing bad or good lists the same as using the the Windows > > version? I though the general idea is to have tests that act on behavior? > > We already do some detection of > certain devices via PCI id's somewhere in the Wine DirectX code for certain > features and I think this should be extended somehow to the drivers and > present a warning to the user or some such. Just fyi, the PCI id stuff in WineD3D is the other way: It finds a PCI id from the features the card has to report a proper id to the game. It doesn't read the real PCI id to tell which features the card has.

Oct. 10, 2007

Re: make test drill

by Steven Edwards

On 10/10/07, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > But isn't introducing bad or good lists the same as using the the Windows > version? I though the general idea is to have tests that act on behavior? I don't think so, a buggy driver is outside of the scope of something we can fix or care to workaround in Wine. We already do some detection of certain devices via PCI id's somewhere in the Wine DirectX code for certain features and I think this should be extended somehow to the drivers and present a warning to the user or some such. The more I think about it, blacklisting really seems to be the only way given the timing of the driver releases. This issue goes beyond just the testing framework. Let say user has a buggy ATI or Nvidia driver installed and it works for OpenGL demos and the like under Linux but when the user runs Wine it hangs the system because we are stressing the driver in ways beyond the normal eye-candy the WM pushes. The user is going to think its a problem in Wine and not in the driver. I see this day in and day out at CodeWeavers and every single time the users blame us even when its fairly obvious that the hang or crash only affects 3D applications. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Oct. 10, 2007

Re: make test drill

by Paul Vriens

Steven Edwards wrote: > On 10/10/07, H. Verbeet <hverbeet(a)gmail.com> wrote: >> 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. > > Conversely couldn't you write a test that detects known good > drivers via the loaded kernel module and make the test dependent > on their presence? Rather than running the test and not knowing > if it will pass or fail, it makes more since to only run the test when > we know it SHOULD pass and then if it fails we have identified > a regression. > But isn't introducing bad or good lists the same as using the the Windows version? I though the general idea is to have tests that act on behavior? -- Cheers, Paul.

Oct. 10, 2007

Re: make test drill

by Steven Edwards

On 10/10/07, Steven Edwards <winehacker(a)gmail.com> wrote: > On 10/10/07, H. Verbeet <hverbeet(a)gmail.com> wrote: > > 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. > > Conversely couldn't you write a test that detects known good > drivers via the loaded kernel module and make the test dependent > on their presence? Rather than running the test and not knowing > if it will pass or fail, it makes more since to only run the test when > we know it SHOULD pass and then if it fails we have identified > a regression. Just to be clear, what I mean is a whitelist rather than a blacklist. I am not sure if it would really work in practice as much as the vendors update the drivers but it provides a stable reference point with which to work from. The overall goal being stability when seeking to identify what is really a regression. It seems obvious some sort of detection will have to be done or else we will never have a stable framework. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Oct. 10, 2007

Re: make test drill

by Steven Edwards

On 10/10/07, H. Verbeet <hverbeet(a)gmail.com> wrote: > 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. Conversely couldn't you write a test that detects known good drivers via the loaded kernel module and make the test dependent on their presence? Rather than running the test and not knowing if it will pass or fail, it makes more since to only run the test when we know it SHOULD pass and then if it fails we have identified a regression. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Oct. 10, 2007

Re: x11drv: don't consume Expose events when filter contains QS_PAINT

by Alexandre Julliard

Clinton Stimpson <cjstimpson(a)utwire.net> writes: > Clinton Stimpson wrote: >> Fix for bug 9875 (There are more details in that bug report if you want). >> Existance of update regions in the wine server correspond with WM_PAINT >> existing in queue. Existance of Expose events in the X event queue don't >> correspond with update regions in the wine server, which can result in a loss >> of painting some regions. >> >> Don't consume Expose events when filtering with QS_PAINT. >> > > Anything wrong with this patch? Yes, this will break redraws in many cases. Because of the async nature of X we have to check for Expose events before doing a repaint. -- Alexandre Julliard julliard(a)winehq.org

Oct. 10, 2007

Re: make test drill

by H. Verbeet

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.

Oct. 10, 2007

Re: PulseAudio as a sound output?

by Jan Zerebecki

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: wined3d: Make sure GL context is created before binding FBO.

by Allan Tong

On 10/9/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Am Dienstag, 9. Oktober 2007 04:18:29 schrieb Allan Tong: > > This patch moves the call to ActivateContext ahead of the opengl > > calls. This fixes a crash I was getting in the Bioshock demo where a > > newly created thread was calling glBindFramebufferEXT before a > > rendering context was established for the thread. > The patch is correct in spirit, ActivateContext has to be called before other > gl stuff is done, but I have found that it causes some problems for an > unknown reason. So perhaps other bugfixes are needed before this works > properly. One of the problems was a major rendering problem in half life 2 > lost coast. I filed bug #9973 and attached the patch there in case it's useful to anyone else. In the meantime, though, perhaps a comment should be added to the code detailing the above reasons, lest someone else tries to make the same fix. - Allan

Oct. 10, 2007