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

Re: Robert Reif : winecfg: Added support for auto detecting all drivers by attempting to

by Robert Reif

Eric Pouech wrote: > Robert Reif wrote: > >> Eric Pouech wrote: >> >>>> We never "load" a driver more than once. Winecfg calls winmm >>>> OpenDriver which will only ever load a single instance of the >>>> driver into memory. Subsequent OpenDriver calls will reference the >>>> existing in memory driver. Wine models the single instance device >>>> driver that supports multiple physical devices. >>> >>> >>> >>> what you end up with is a situation where: >>> - two calls to OpenDriver for the same driver will provide: >>> + a separate HDRVR (one for each call) >>> + the same driver ID at the driver level >>> + an implementation at the driver level with a single data state >>> shared across the two HDRVR instance >> >> >> >> This is true and is also how windows works with the tests I have done >> with a user installable driver. The reason this works is because I am >> only accessing the static driver configuration (GetNumDevs and >> GetDevCaps). I have no intention of actually using the drivers for >> anything else because they are not designed for that. > > Here again, I'm not saying you *will* badly use the drivers (and your > current code doesn't). But, the way you changed things can let someone > do it (or a windows app), and we have no protection for that. > > > I am opening the > >> driver, not the individual devices (WaveIn, WaveOut, ...). I agree >> that under normal circumstances, bypassing winmm and accessing the >> driver directly is the wrong thing to do because winmm is responsible >> for coordinating things, but in this case and only this case >> (accessing static driver configuration) it is OK. > > >> The real way to do this would be to have each driver register itself >> with the PnP manager and then we could interface with it. I am using >> winmm (OpenDriver) for loading and configuring the drivers which is >> perfectly legal to do. Only using LoadLibrary and xxxMessage to get >> the number of devices and their capabilities is the thing that is >> really questionable. A PnP manager would fix that in the long term. > > My concern here is that your changes require a driver to be opened > (thru OpenDriver) twice (one time by winecfg, a second time at winmm > startup). IMO, the target should be to implement the audio > configuration in winecfg without requiring to open twice a driver. > It's likely to boil down to let winmm do the core job. > >> I guess I have a terminology misunderstanding here and should >> probably reread my driver documentation. I would like to see this >> class of driver implemented so that only a single device shows up for >> a physical device (multi channel cards being the exception). Each >> wave device could be opened more than once. Each open would >> dynamically open a connection to the mixing server. In this case >> with a single physical sound card, waveOutGetNumDevs will always >> return 1 and a waveOutOpen will always succeed (within mixer server >> limitations). This is how windows works on versions that have kmixer >> (98SE up). > > yup. this is also the way to go for a unified wine audio driver by the > way. > > A+ > It is not typical for an application to bypass winmm and communicate directly with a driver. Only a control panel or device manager type application would ever even try something like this. Winecfg is one of those unusual programs. Opening a driver more than once will not cause any problems. The open functions in all the drivers are just stubs. Loading a driver is what causes a drivers state to be initialized and there is no way going through winmm to load the same driver more than once. Trying to open a specific driver's device through for example waveOutOpen more than once either through winmm or directly to the driver will only allow the first open to succeed because all attempts after the first will see that the device is already opened and fail.

Dec. 11, 2005

Re: Battlefield 1942 and the radeon driver

by Stefan Dösinger

> 1. Not done. Still marked as experimental. > 2. Not from a stable release of Xorg. > 3. Reverse engineered. > > Given those limitations I'm not sure what driver quality you were > expecting ;P If the fglrx driver works better, I doubt there's much > point trying to hack on wine to make things work better. Sorry for not mentioning this in the first place: I've a R250 chip, where Documentation was provided from ATI ;) , so 3 doesn't apply here. I decided to look at it before X.org 7.0 becomes stable, so it's easier to get bug fixes into the driver. My problem is that I am more or less between 2 groups here: It's not clearly a Wine bug, but I don't expect much from asking the X.orh OpenGL developers for help with a DirectX game. Well, I'll try to ask the dri developers too, let's hope for the best ;) Stefan

Dec. 11, 2005

RFC: D3D7 and WineD3D

by Stefan Dösinger

Hello, In the past weeks, I've worked on a re-write of the Direct3D7 implementation with WineD3D. Well, I've managed to get some games running, but I have also encountered a few problems. Before I continue with this, I'd like to ask for your opinions. I have uploaded a patch to http://doesi.gmxhome.de/d3d7.patch.bz2, it's a diff against Wine CVS from December, 11th 2005. It's not really meant to be used, but rather to have something to look at. I don't know how long I can keep the patch there, because I am limited in space. I've sent the patch to Oliver some days ago to upload it to his sourceforge website, it will be available there when he uploads it. So what's the point of this mail? While a D3D7->WineD3D wrapping can be done by wrapping D3D7 only and leave DirectDraw in ddraw.dll, it has a few ugly drawbacks: -> Device initalisation: In D3D7, the first step is to create a IDirectDraw Device, set up the device, create a surface and then create a Direct3D Device. When creating the WineD3DDevice in the last step, I have to do some ugly things to wrap the allready existing Surface to a newly created WineD3DSurface. The same applies in reverse order for the device removal. I also don't know what to do if a game changes the screen setup after D3DDevice creation. -> Surfaces: In D3D7 surfaces are children of IDirectDraw, while in WineD3D they are children of WineD3DDevice. Because the D3D7Device can be created and destroyed without modifying surfaces, I have to manage the surface's properties and memory areas for both DirectDraw and WineD3D. Overrides for the Lock() and Unlock() functions are used to access the WineD3D surface if it exists. I think that everything would be much cleaner if the DirectDraw functionality was also moved to WineD3D. My suggestion is the follwing. -> WineD3D would be initialised in the D3D7 way, using a new interface WineDDrawDevice. D3D8 and D3D9 could easily manage this in their create functions -> Surfaces are created with WineDDrawDevice, and they survive the release of WineD3DDevice. This makes surface creation easier for D3D7, and it's easy to adopt it for D3D9 and D3D8. -> The IWineD3DSurface interface gets additional functionality for DirectDraw operations. I'd suggest 3 versions of the 2D functions: One based on plain X11(for compatiblity) calls, one that uses DGA(speed without 3D acceleration), and one that uses OpenGL(For fast rendering without /dev/mem access). For DXVersion > 7 the OpenGL version is used, and for DX7 it can be decided when the primary surface is created. What's the drawback? First, it's much more work, and it's a really invasive change to WineD3D, which becomes more complex. Because of this I'd like to know your opinion before I spend a lot of time for this. Stefan

Dec. 11, 2005

Re: Battlefield 1942 and the radeon driver

by Joseph Garvin

Stefan Dösinger wrote: >I guess it's a driver bug. It works sort of with the fglrx driver, but this >driver is horrible. > The driver is: 1. Not done. Still marked as experimental. 2. Not from a stable release of Xorg. 3. Reverse engineered. Given those limitations I'm not sure what driver quality you were expecting ;P If the fglrx driver works better, I doubt there's much point trying to hack on wine to make things work better. > Any suggestions how to debug this? A +d3d log shows that >the program is doing almost normal rendering. Other directx games also work >fine. > >Stefan > > > > >

Dec. 10, 2005

Battlefield 1942 and the radeon driver

by Stefan Dösinger

Hello, Did anyone of here get Battlefield 1942 with the radeon driver going? I just tried with X.org 7.0-rc3, and the game blocks at the loading screen with ~65% sys cpu usage and ~35% cpu idle. This happens with the current CVS version, as well as with Olivers d3d8 patch. I guess it's a driver bug. It works sort of with the fglrx driver, but this driver is horrible. Any suggestions how to debug this? A +d3d log shows that the program is doing almost normal rendering. Other directx games also work fine. Stefan

Dec. 10, 2005