With Friday's release, I am interested in making the Mac Driver wine's default on OS X. My own immediate motivation is largely so we at CodeWeavers can start testing it as a default internally (which obviously we can do on our own, regardless, if needed), but I figured I'd ask the wider community to see whether it's time in winehq also.
My question is how it should be configured from a user perspective. Right now one can set a registry key in
HKCU/Software/Wine/Drivers/Graphics
with a comma-separated list specifying the driver load order, and the first one successfully loaded will be used. Absent the key, there is a hardcoded load order in user32/driver.c. Right now that is just "x11."
Discussing with Alexandre the other day I believe his thought is to make the hardcoded default "x11,mac" in all cases (including Linux). I believe (and I don't mean to put words in his mouth) that his thought is that a user should never have to edit the registry to switch between drivers. The thought would be that in order to switch between drivers, a user must instead create an environment in which all drivers which are ahead of the desired driver in the hardcoded load order will fail to load. I think that in the specific case of "x11,mac" on an OS X box, the thought was to unset DISPLAY if you want to run with the Mac Driver on, forcing X11 to fail and therefore getting the fallback.
I just now realized, though, that OS X 10.8 ships with stub X11 libraries which behave badly. If you try to load X11 on a brand-new OS X 10.8 machine, the user sees a dialog box with directions on downloading XQuartz, and the process which tried to load X11 is killed. I hadn't thought of that earlier, but it seems to weigh against using a fallback mechanism where x11 is attempted first in all cases. It means that to get good behavior from the fall-through, a Mac user would be required to download and install real X libraries, then unset DISPLAY.
It seems broadly incorrect to me to attempt to load X11 first everywhere and force the user to make sure loading that fails if they want a different driver. I think that if the Mac Driver is to be the default on a Mac, rather than assume the environment will be such that other drivers will fail, it should really just be the first thing wine tries to load. The case of OS X's bad X11 stub libraries is one where it seems fairly onerous for a user to ensure X11 won't load. Wayland isn't here now, but it seems like when it comes it may bring similar issues.
I propose an environment variable, WINEDRIVERLOADORDER. I would think we would first use the registry value, then the value of WINEDRIVERLOADORDER, then the hardcoded fallback. I would also propose making the hardcoded fallback differ on OS X and linux, so that a user who does nothing on OS X can have the Mac Driver, but someone who wants X11 can set WINEDRIVERLOADORDER and switch to that without editing the registry.
Is that an acceptable approach?
Of course, Ken may abhor the idea of having the Mac Driver the default in winehq at this point, anyway. ;)
Maybe we could just skip loading the x11 driver is DISPLAY is unset. It brings some logic into the driver logic that doesn't really belong there, but it seems like a reasonable optimization and in practice would work the way Alexandre wants even when the x11 libraries are as spectacularly broken as they are on OS X 10.8.
Wayland isn't here now, but it seems like when it comes it may bring similar issues.
For the record, I would argue that wayland should be ahead of x11 in the default load order, once it's decided that a wayland driver is ready. Usually, a rootless X server will be available in wayland for compatibility reasons, and the reverse is not true. And one could use a similar approach to X11 to make loading the wayland driver fail.
That said, I'm not sure controlling this with an environment variable that's going to impact other programs is a good idea. Unsetting the wayland display would mean that any other processes Wine starts couldn't use that display either. So the only way to do this for Wine only is still to mess with the registry. If this is just to make a quick/temporary change from the command line then that's OK, but if so we shouldn't be using it to implement settings in our Mac product.
On Sat, Mar 2, 2013 at 7:20 PM, Josh DuBois duboisj@codeweavers.com wrote:
With Friday's release, I am interested in making the Mac Driver wine's default on OS X. My own immediate motivation is largely so we at CodeWeavers can start testing it as a default internally (which obviously we can do on our own, regardless, if needed), but I figured I'd ask the wider community to see whether it's time in winehq also.
Is it really ready yet? As far as I can tell, the OpenGL fixes are not yet committed.
My question is how it should be configured from a user perspective. Right now one can set a registry key in
HKCU/Software/Wine/Drivers/Graphics
with a comma-separated list specifying the driver load order, and the first one successfully loaded will be used. Absent the key, there is a hardcoded load order in user32/driver.c. Right now that is just "x11."
Discussing with Alexandre the other day I believe his thought is to make the hardcoded default "x11,mac" in all cases (including Linux). I believe (and I don't mean to put words in his mouth) that his thought is that a user should never have to edit the registry to switch between drivers. The thought would be that in order to switch between drivers, a user must instead create an environment in which all drivers which are ahead of the desired driver in the hardcoded load order will fail to load. I think that in the specific case of "x11,mac" on an OS X box, the thought was to unset DISPLAY if you want to run with the Mac Driver on, forcing X11 to fail and therefore getting the fallback.
I don't think this is a good idea. Consider this case:
User is happily using wine with mac driver. User installs XQuartz for reasons unrelated to wine. Suddenly wine is using X11 driver instead of mac driver. User is now unhappy (maybe).
I propose an environment variable, WINEDRIVERLOADORDER. I would think we would first use the registry value, then the value of WINEDRIVERLOADORDER, then the hardcoded fallback. I would also propose making the hardcoded fallback differ on OS X and linux, so that a user who does nothing on OS X can have the Mac Driver, but someone who wants X11 can set WINEDRIVERLOADORDER and switch to that without editing the registry.
Is that an acceptable approach?
I agree that the default on mac should be mac,x11, but I don't really see the reason an override can't be set in registry. Is it just because registry is considered too complicated to modify? I'd suggest making a setting in winecfg in that case. Virtual desktop is already there and has a similarly large impact.
Environment variables feel a bit too volatile to be depended upon. Launching from terminal or through desktop very well might have different variables set. If global configuration is needed, it should be through a configuration file, IMO. wine.inf could handle it, except it's overwritten when upgrading.
Regards,
On 3/4/13 4:28 AM, Per Johansson wrote:
I agree that the default on mac should be mac,x11, but I don't really see the reason an override can't be set in registry. Is it just because registry is considered too complicated to modify?
I think one concern is not forcing people to mod the registry in order to run remote X. It's true that if you're in a situation where one display driver flatly won't work, a requirement that one change the registry to switch to another is onerous because you can't run any graphical utility (winecfg, regedit) to change the setting in that case. That's why an environment variable is useful. Of course, if we have ENVVAR --> registry --> hardcoded default, you have the ability to control things via the registry or the environment, depending what you want to do.
Josh DuBois duboisj@codeweavers.com writes:
On 3/4/13 4:28 AM, Per Johansson wrote:
I agree that the default on mac should be mac,x11, but I don't really see the reason an override can't be set in registry. Is it just because registry is considered too complicated to modify?
I think one concern is not forcing people to mod the registry in order to run remote X. It's true that if you're in a situation where one display driver flatly won't work, a requirement that one change the registry to switch to another is onerous because you can't run any graphical utility (winecfg, regedit) to change the setting in that case. That's why an environment variable is useful. Of course, if we have ENVVAR --> registry --> hardcoded default, you have the ability to control things via the registry or the environment, depending what you want to do.
The goal should be to automatically do the right thing, as far as possible. Adding an environment variable that the user needs to know about isn't going in the right direction.
My feeling (like Josh's and Per's) is that the Mac driver should be what you get by default, in most cases, without taking any special steps.
If the concern is what you get when you're ssh'd into a remote system, then it's probably possible for the Mac driver to detect when it doesn't have GUI console access and fail. Then, Wine could fall back to X11.
We can't rely on DISPLAY being unset. It's set by default. That's true on Snow Leopard and Lion. I believe it's also true on stock Mountain Lion (whether or not XQuartz has been installed).
(The question of when to make this switch so that the Mac driver is the default is separate. OpenGL is my next major patch set. I hoped to submit it yesterday, but got tripped up by some changes in Wine since the CrossOver 12 base.)
-Ken
Ken Thomases ken@codeweavers.com writes:
My feeling (like Josh's and Per's) is that the Mac driver should be what you get by default, in most cases, without taking any special steps.
I think we all agree on that. My point is that you shouldn't have to take special steps even when the Mac driver is not appropriate (like with remote logins).
If the concern is what you get when you're ssh'd into a remote system, then it's probably possible for the Mac driver to detect when it doesn't have GUI console access and fail. Then, Wine could fall back to X11.
If that can be made to work, it would certainly be a nice solution.
On Mon, Mar 4, 2013 at 8:36 PM, Alexandre Julliard julliard@winehq.org wrote:
Ken Thomases ken@codeweavers.com writes:
If the concern is what you get when you're ssh'd into a remote system, then it's probably possible for the Mac driver to detect when it doesn't have GUI console access and fail. Then, Wine could fall back to X11.
If that can be made to work, it would certainly be a nice solution.
The current session type can be queried by the command
launchctl managername
It'll say Aqua for GUI console and either Background or StandardIO for ssh. It seems to be using a private API to fetch this though: http://www.opensource.apple.com/source/launchd/launchd-442.26.2/support/laun...
Regards,
-
Alexandre Julliard -
Josh DuBois -
Ken Thomases -
Per Johansson -
Vincent Povirk