Re: [Qemu-devel] [PATCH] Fixes several full screen issues on Mac OS X

[Programmingkid]

On Jan 14, 2015, at 1:29 PM, Peter Maydell wrote:

> On 14 January 2015 at 18:18, Programmingkid <address@hidden> wrote:
>> 
>> On Jan 14, 2015, at 12:19 PM, Peter Maydell wrote:
>>> (2) Having done this I find that all my other application windows
>>> have been squashed down into a corner of my screen, presumably because
>>> we've told MacOSX "the screen is 640x480" and it's rearranged the
>>> app windows to suit. We mustn't mess things up like this.
>> 
>> This can't be avoided. When the screen resolution changes, all the
>> applications usually adjust to the new size. It is the same thing
>> that happens when you use a full screen game.
> 
> No, when I use other full screen programs this doesn't happen at all.
> QEMU with this patch is the first time I've ever seen this from
> any OSX app.

How long have you been a Mac user? I am shocked you have never seen this 
before. I'm guessing full screen gaming was never your thing. 

> 
>>> (3) I managed to get at the underlying "QEMU" window with its title
>>> bar somehow even when in full screen mode: I could move it about the
>>> screen with the mouse...
>> 
>> Really? I think you said you had Mac OS 10.7. I don't have that, but
>> I do have access to Mac OS 10.9. Just send me the instructions on how
>> to reproduce this.
> 
> I run 10.9.5. I don't know exactly how I got to that window,
> and I don't really want to mess about with this patch because
> behaviour (2) above is so obnoxious.
> 
>>> (4) I get a lot of compile warnings for this patch:
>>> 
> 
>> Disabling the depreciation warning would eliminate these errors.
> 
> Not all of them are deprecation warnings. Also I would prefer not
> to disable deprecation warnings, as then we'll have no notice
> of what might break on future OSX versions.

I'm sure we will know exactly when a depreciated function isn't implemented 
anymore. We will probably see some message in the Console. Or a backtrace to a 
crash will show us where and when QEMU crashed. I guess I could also use 
non-depreciated functions in the patch. The thing is QEMU will determine what 
to use at runtime, so the depreciation messages might not go away. 

> 
>>>>    int w = surface_width(surface);
>>>>    int h = surface_height(surface);
>>>> -    /* cdx == 0 means this is our very first surface, in which case we 
>>>> need
>>>> -     * to recalculate the content dimensions even if it happens to be the 
>>>> size
>>>> -     * of the initial empty window.
>>>> -     */
>>>> -    bool isResize = (w != screen.width || h != screen.height || cdx == 
>>>> 0.0);
>>>> -
>>>> +    bool isResize = (w != screen.width || h != screen.height);
>>> 
>>> (6) This looks like you've just dropped a bug fix. How are you
>>> dealing with this case if not by the method described in the
>>> now-deleted comment?
>> 
>> If the guest does change its resolution, then we try to match it
>> in the host. When I eliminated this code, it made the guest look
>> so much better. I was actually able to read documents in the guest
>> at full screen.
> 
> The point is that you've dropped a bugfix which isn't related to
> full screen at all -- if this is the first call to switchSurface
> we *must* display it, which is what the cdx check does. See
> commit 381600dad.

This bugfix does change the appearance of full screen mode. Have you seen a 
guest at full screen? The cdx and cdy variables make the guest OS look very 
distorted.