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

XEMBED Implementation

by Cloudor Pu

Hi, I find discussion about XEMBED implementation in this mailing list and that was 3 years ago. Is there now any usable implementation or examples for wine XEMBED plug? What I am doing is to embed IE into a GtkSocket. I wrote a standalone program compiled using winelib that can CreateWindow and embed IE. Can I CreateWindow using the XEMBED Id if there is already XEMBED implementation or can I just CreateWindow as a child of a GtkPlug which is a gtk-embeddee? Any advices or suggestions would be highly appreciated. Thank you! Regards, cloudor

Dec. 2, 2006

Re: msi 2: Remove redundant NULL checks before x_Release

by Mike McCormack

James Hawkins wrote: > Changelog: > * Remove redundant NULL checks before x_Release. obj->Release() will read the vtable pointer from the object, and that will crash if obj is NULL, so these checks are needed. The following code will crash: IUnknown *obj = NULL; IUnknown_Release(obj); You can see this looking at the definition of the IUnknown_Release macro: include/unknwn.h:#define IUnknown_Release(p) (p)->lpVtbl->Release(p) Mike

Dec. 2, 2006

Wined3d State management again

by Stefan Dösinger

Hi, I've done some more work on my state management, and I uploaded an updated patch to http://stud4.tuwien.ac.at/~e0526822/wined3d-statemgmt-2.tar.bz2 . Ok, so what's updated: * Pixel shaders: Should work now * GLSL shaders: Working too. Henris shader backend stuff is integrated in a messy way. * Offscreen rendering: Works with back buffer and pbuffer rendering, fbos not yet. * Stateblocks: Brute force integration by just scheduling all modified states for a reset. No display list yet * Blitting, render target unlocking: Enabled again, sets new gl states and schedules a reapplication of the modified states. Not a nice solution yet What is still missing: * Nv register combiners. I haven't found a way yet to build a texture stage -> texture unit mapping which I like. All the ways I could think of could potentially cause lots of unneccessary state changes. One nice thing I have noticed is that this changes give a huge performance gain in Half-Life 2(dxlevel 80, and 90). Dxlevel 80 is accelerated to approximately 150-200% of the former performance, and especially slow parts are faster now. This makes a really huge playability difference :-) There are some regressions too, especially related to texture loading(3Dmark2000), and some glsl crashes. The good part about this change is that I can send it in in very small patches, making regression testing much easier, contrary to the huge ddraw rewrite. Where to go from here? As long as nobody screams I'd start sending patches now. Its easier to catch regressions while sending small patches instead of hunting them on the blob I have here(and my messy patch history in my git tree). I'm also afraid that I get too far away from the main wined3d code(See the shader backend integration). We can discuss the code based on the small changes I'll send. Stefan

Dec. 2, 2006

Re: Concerning the separate OpenAL32.dll thunk patch and OpenALwinmm driver patch

by Nick Burns

>From: Alexandre Julliard <julliard(a)winehq.org> >To: "Nick Burns" <adger44(a)hotmail.com> >CC: wine-devel(a)winehq.org >Subject: Re: Concerning the separate OpenAL32.dll thunk patch and >OpenALwinmm driver patch >Date: Fri, 01 Dec 2006 13:49:52 +0100 > >"Nick Burns" <adger44(a)hotmail.com> writes: > > > Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE > > I would like to have a choice. > >Why? What does it do that you cannot do with the CoreAudio driver? True the coreaudio driver can be made awesome -- but as it stands it has problems with many games on my machine (currently hard for me to test due to fullscreen detection changes in ogl) Problems range from deadlocking -- to crackling sound There are a few games that run flawlessly under coreaudio My openal driver also has crackling sound in some games (but i have not yet seen deadlocking -- its possible it could) Also the coreaudio driver is not testable and wont help linux ppl -- just Mac ppl An openal driver would be multi-platform -- testable under windows/mac/linux, would add a 2nd built-in driver to Mac OSX. > > Yes my wineopenal patch is not perfect (based on broken code does not > > help) -- I know that -- but thats why i want to get it into wine -- so > > other people who know more about audio can add to it and make it > > better > >Judging from past experience, people for whom it doesn't work right >will simply go out and implement yet another driver, with yet another >set of bugs... True -- it has its own set of bugs -- but I cannot iron them out myself -- I would need help from people to do so -- thats why I would like to give it as an option to you wine people (who can test it on linux) (its possible i could try and start a side project in sf.net or something -- no clue what other options there are) In a perfect world we could make an awesome cross-platform openal driver that does ... everything (winmm/dsound/dsound3d/...) everywhere (Linux/Windows/MacOSX) ---------- So, thats all the good stuff about it... The bad stuff is that its another driver in the tree another option to confuse people another point of failure ... (there is more badness here probably) >-- >Alexandre Julliard >julliard(a)winehq.org - Nick

Dec. 1, 2006

Re: Concerning the separate OpenAL32.dll thunk patch andOpenALwinmm driver patch

by Nick Burns

Sorry I should have reiterated more clearly... Yes you can dl jack -- but it has never worked correctly for me...(I could try Jack again -- it has been a while....) esd -- but it too did not work so well (very laggy sound) liboss -- but i dont think that the alpha version compiles under osx... (did not really try to hard there i must admit hehe) alsa -- it could be ported -- but .. I dont wish that on anyone I am referring to builtin sound drivers for Mac OSX -- We have CoreAudio and OpenAL builtin (no alsa, no oss, no esd, no jack, ...) And coreaudio cannot be tested by anyone except for Mac people... (There seems to be much fewer mac people here...) An OpenAL driver can be tested by linux people with openal (ok those #s i dont know) So, the openal driver is one that CAN work and be multi platform Coreaudio can be made to be the most awesome as well -- but that does not help linux - Nick >From: Pierre d'Herbemont <pdherbemont(a)free.fr> >To: Nick Burns <adger44(a)hotmail.com> >CC: wine-devel(a)winehq.org >Subject: Re: Concerning the separate OpenAL32.dll thunk patch >andOpenALwinmm driver patch >Date: Fri, 1 Dec 2006 17:15:30 +0100 > > >On 1 déc. 06, at 00:54, Nick Burns wrote: > >>Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE >>I would like to have a choice. > >In fact there is at least two working sound driver: you can also use the >Jack driver on Mac OS X if you've downloaded [1] at compile time which by >the way seems to have a working audio input. > >[1] http://www.jackosx.com/ > >Pierre. >

Dec. 1, 2006

Re: Video problems with FC6

by Andreas Bierfert

On Fri, 01 Dec 2006 09:13:31 -0500 gslink <gslink(a)one.net> wrote: > There is currently a bug in FC6 that affects Wine. If, with any Nvidia > driver from any source, a program attempts to use accelerated video and > the attached monitor uses digital feed the program will often crash the > user session. This has been reported and is not a problem in Wine but a > good many games that used to run under Wine now crash. Other cards were > not tested but may be affected. It is hoped RH will fix this rather > quickly. > > Could you be a bit more specific. I don't have any problems with this combination at all. - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert(a)lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred

Dec. 1, 2006

Re: [PATCH 1/9] dinput: Move acquired flag to the base device class.

by Vitaliy Margolen

Peter Oberndorfer wrote: > On Friday 01 December 2006 07:23, Vitaliy Margolen wrote: >> >> --- >> dlls/dinput/device.c | 28 ++++++++++++++++++++++++++++ >> dlls/dinput/device_private.h | 3 +++ >> dlls/dinput/joystick_linux.c | 23 ++++++++--------------- >> dlls/dinput/keyboard.c | 36 ++++++++++++++++-------------------- >> dlls/dinput/mouse.c | 23 ++++++++--------------- >> 5 files changed, 63 insertions(+), 50 deletions(-) >> > Hi, > some questions/notices about this patch: Thank you for spending time and looking over my craft :) > Previously when the device was not acquired inside JoystickAImpl_Unacquire DIERR_NOTACQUIRED was returned. > now you call IDirectInputDevice2AImpl_Unacquire, which returns DI_NOEFFECT when not acquired. That is correct. I should have added small tests to show that it should work that way. I will add it next time around. > but DI_NOEFFECT does not have high bit set so it won't trigger the FAILED macro. Oops I didn't check that one. More reasons for some tests. > Do you know if the Acquire/Unacquire functions return value the same for all device types? Tests and msdn indicate that return values are identical for all devices. > In JoystickAImpl_Acquire you don't use your new IDirectInputDevice2AImpl_Acquire function but set This->base.acquired = 1; > Is there a reason for this? > In SysKeyboardAImpl_Unacquire you seem to call IDirectInputDevice2AImpl_Acquire? Because there are few other things that's being checked before joystick can be acquired. Mouse and keyboard just acquire the device without any additional checking. There are lots of other inconsistencies all over dinput. This is one of the reasons I'm trying to unify all the common code in one place. Vitaliy

Dec. 1, 2006

Re: Concerning the separate OpenAL32.dll thunk patch and OpenALwinmm driver patch

by Pierre d'Herbemont

On 1 déc. 06, at 00:54, Nick Burns wrote: > Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE > I would like to have a choice. In fact there is at least two working sound driver: you can also use the Jack driver on Mac OS X if you've downloaded [1] at compile time which by the way seems to have a working audio input. [1] http://www.jackosx.com/ Pierre.

Dec. 1, 2006

Video problems with FC6

by gslink

There is currently a bug in FC6 that affects Wine. If, with any Nvidia driver from any source, a program attempts to use accelerated video and the attached monitor uses digital feed the program will often crash the user session. This has been reported and is not a problem in Wine but a good many games that used to run under Wine now crash. Other cards were not tested but may be affected. It is hoped RH will fix this rather quickly.

Dec. 1, 2006

Re: user32: Factorize graphics driver's WindowCreate and ShowWindowin user32.

by Pierre d'Herbemont

On 1 déc. 06, at 08:38, Dmitry Timoshkov wrote: > The problem is that for top level windows we need to route ShowWindow > actions to a Window Manager/Host Windowing System, so that actions > like minimize/maximize/restore would be properly handled. We don't > do this at the moment, but we need to. ok thanks, I got your point. Pierre.

Dec. 1, 2006