Re: Making wine default to the Mac Driver on OS X

2013-03-05 Thread Per Johansson
On Mon, Mar 4, 2013 at 8:36 PM, Alexandre Julliard  wrote:
> Ken Thomases  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/launchctl.c

Regards,
-- 
Per Johansson




Re: Making wine default to the Mac Driver on OS X

2013-03-04 Thread Alexandre Julliard
Ken Thomases  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.

-- 
Alexandre Julliard
julli...@winehq.org




Re: Making wine default to the Mac Driver on OS X

2013-03-04 Thread Ken Thomases
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





Re: Making wine default to the Mac Driver on OS X

2013-03-04 Thread Alexandre Julliard
Josh DuBois  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.

-- 
Alexandre Julliard
julli...@winehq.org




Re: Making wine default to the Mac Driver on OS X

2013-03-04 Thread Josh DuBois

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.






Re: Making wine default to the Mac Driver on OS X

2013-03-04 Thread Per Johansson
On Sat, Mar 2, 2013 at 7:20 PM, Josh DuBois  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,
-- 
Per Johansson




Re: Making wine default to the Mac Driver on OS X

2013-03-02 Thread Vincent Povirk
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.




Making wine default to the Mac Driver on OS X

2013-03-02 Thread Josh DuBois
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. ;)