Hi,
With my latest set of patches, the Mac driver in Wine is up to speed with what's in CrossOver 12 (plus some extra goodies).
Of course, that's not to say that the Mac driver is done, but if you were holding off getting involved because you figured big chunks of already-done work were pending, that's no longer the case. From here on out, all work on the Mac driver will be new coding, so it's ready for anybody to contribute.
Testing is one excellent way of contributing. I encourage any Mac Wine users to enable the Mac driver, test your favorite programs, and file bugs for any new problems (and there _will_ be bugs to find). Please try to distinguish between general Wine bugs which also happen with the X11 driver vs. bugs which only happen with the Mac driver.
Currently, you have to set a registry key to enable the Mac driver:
[HKEY_CURRENT_USER\Software\Wine\Drivers] "Graphics"="mac,x11"
Swap the order to "x11,mac" – or just remove the "Graphics" value altogether – to revert to using the X11 driver.
Aside from bugs, the Mac driver is pretty close to complete. Here's a list of stuff that I know is incomplete. Not all of these things are hard. In fact, I expect some will be quite easy and the only reason I didn't get to them was to get broader coverage of general areas of functionality by CrossOver 12's release.
* The Quit menu item should do a graceful shutdown of the Windows process rather than abruptly terminating it. Same for requests to quit from the system such as during logout, restart, or shutdown.
* A registry setting to govern whether full-screen at full-resolution should capture the display (which will disable active screen corners but also application switching and UI overlays). Full-screen at other resolutions already captures the displays.
* A registry setting to govern whether the Option/Alt key sends an Alt keystroke instead of accessing additional characters from the Mac keyboard layout.
* Support for maximizing windows.
* Reduce or eliminate flashes of black before windows (re)draw.
* Support for Mac input methods (Asian languages, press-and-hold, keyboard and character viewers).
* Rework the Graphics tab of winecfg. Most of it doesn't apply to the Mac driver. As Mac-driver-specific registry settings are implemented, they may need to be revealed in winecfg.
* Maybe implement a Cocoa Preferences dialog for the Mac driver's settings as an alternative to putting them in winecfg.
* Activating a Wine GUI process all of whose windows are minimized should maybe unminimize one.
* Add some additional standard items to the Mac menus, such as Hide Wine, Hide Others, and Show All.
* Support for metafile clipboard formats.
* Support for mouse capture.
* Improved system tray functionality like detecting mouse moves and right-clicks and presenting notification balloons.
* Support localization of the few UI strings in the Mac driver (basically the menu item titles).
(Charles Betts has already submitted work to support disabling and reenabling the screen saver. As I understand it, Alexandre has some unspecified ideas about how he wants to change the driver interface for the SystemParametersInfo entry point.)
Cheers, Ken
I have one more of my own to add:
* Fix crash whenever an app makes a GLU call.
I suspect this is because Mesa's GLU calls Mesa's libGL--which crashes horribly because there's no Mesa/GLX context current.
I see two ways to fix that. One is to make GLU dispatch go through the driver. The other is to actually implement glu32 (i.e. not as a forwarder to the system GLU). I'm not sure how AJ will feel about the first one--and I probably won't know until next week. The second one... writing a GLU is a lot of work. We could use SGI's (as Mesa does), but SGI GLU is largely written in C++--and I *know* AJ won't like that. There's probably something I'm missing here, though. I'd be happy to have that pointed out to me.
Chip
On Mar 19, 2013, at 1:31 AM, Charles Davis wrote:
I have one more of my own to add:
- Fix crash whenever an app makes a GLU call.
Ah, yes, I forgot that one. Thanks for reminding me.
I suspect this is because Mesa's GLU calls Mesa's libGL--which crashes horribly because there's no Mesa/GLX context current.
Yes, basically.
I see two ways to fix that. One is to make GLU dispatch go through the driver.
This is what I did for CrossOver 12. The problem is that it introduced a requirement that a WGL context be current on the thread to find the driver functions. (Technically, the GLU spec requires a current GL context at the time of any GLU calls, but glu32 doesn't require that and, empirically, it seems that Mesa's library doesn't either. Because some stuff that used to work was broken by CrossOver 12.)
The other is to actually implement glu32 (i.e. not as a forwarder to the system GLU). I'm not sure how AJ will feel about the first one--and I probably won't know until next week.
Not thrilled, although willing to entertain it if it can be done in a relatively elegant and robust way. None of my proposals rose to those standards. ;)
The second one... writing a GLU is a lot of work. We could use SGI's (as Mesa does), but SGI GLU is largely written in C++--and I *know* AJ won't like that.
Implementing glu32 on top of opengl32 was Alexandre's approach. He was looking for an open-source GLU implementation to use. He could find C implementations for most parts of GLU except the NURBS stuff.
We didn't really get any further than that.
-Ken
On Mon, 18 Mar 2013, Ken Thomases wrote: [...]
Currently, you have to set a registry key to enable the Mac driver:
[HKEY_CURRENT_USER\Software\Wine\Drivers] "Graphics"="mac,x11"
An issue I ran into with the registry approach is that it causes Wine to use X11 to show the 'Updating the Wine configuration' dialog during the WINEPREFIX creation. It's pretty misleading and could easily give the wrong impression!
Wine does shift to using the Mac driver once regedit has had a chance to be run.
-
Charles Davis -
Francois Gouget -
Ken Thomases