[vbox-dev] MacOs Native Fullscreen

Sergey Dubov Sergey.Dubov at oracle.com
Mon Apr 29 07:02:02 PDT 2013


Lucas Dupin <oi at lucasdup.in> писал(а) в своём письме Mon, 29 Apr 2013  
16:20:26 +0400:

> Hi Sergey,

Hi.


>> I just have a few words to tell about native MacOS X fullscreen feature:
>> 1. Within the current Runtime UI architecture having native MacOS X  
>> fullscreen support is not something easy (if possible at all).
>> Fullscreen-mode is not just "an arrow at the right corner", its  
>> internal mechanism which takes into account different aspects of  
>> VirtualBox GUI behavior.
>> When GUI changes mode representation (from normal to fullscreen,  
>> seamless or scale) through the menu action it recreates internal  
>> Runtime UI logic >>and finally machine-window(s), so entering  
>> fullscreen "the true Mac way" is not quite possible in such case.
>> Note: The VirtualBox Runtime UI architecture was developed in 2010,  
>> before the MacOS X Lion (2011) and ML (2012) was introduced, so such  
>> things >>like "animated fullscreen support" was not taken into account  
>> at all.
> Maybe we could just not change to UiMachineFullscreenWindow if you click  
> the arrow and keep the legacy fullscreen support if the user prefers to  
> use it.
> It would work like this:
> 1. OSX 10.8 user clicks on the arrow of press cmd+shift+F to go native  
> fullscreen
> 2. All OSX users would still be able to press cmd+F

As I said, VirtualBox fullscreen mode is not just "an arrow at the right  
corner".
On entering fullscreen UI session recreates UIMachineLogic to  
UIMachineLogicFullscreen child, which recreates UIMachineWindow(s) to  
UIMachineWindowFullscreen(s) children and so on to the UIMachineView(s)  
children. Fullscreen logic takes into account multi-screen layout (the  
possibility to map and reorder guest screens among the host screens) and a  
lot of other things related to fullscreen mode only. The thing which you  
are proposing is to keep GUI in previous mode (normal and/or scale) and  
just to enlarge it to fullscreen size using animated Lion/ML mechanism. It  
will creates much more problems and even weird bugs than resolve.



>
>> 2. Moreover, iirc we are still supporting build on MacOS X SDK 10.5 and  
>> wish to do so for now.
> I agree we must support 10.5. I think some simple respondsToSelector  
> calls would solve the problem, maybe we'll need a define somewhere.
>
>> 3. And finally MacOS X Lion which supports "native fullscreen mode"  
>> doesn't have possibility to enter fullscreen on other than primary  
>> screen (multi->>screen fullscreen support appeared in MacOS X Mountain  
>> Lion) which is totally unacceptable.
> Ok, here we have a issue but what if we keep the legacy fullscreen  
> support on Lion and implement the native only for mountain Lion? Someday  
> you'll have to do it, >right?

Well, as you know Oracle management determines the current priorities for  
our project.
if there will be a paying customer request or other important reason to  
have exactly native MacOS X fullscreen support for Mountain Lion I'll  
implement it but not quite the way you are proposing, its more like a hack  
as you said :) For now its not something extremely urgent and/or important.



>
>
> Can you help me with this vmmr0.r0 problem? It's hard to guess what to  
> do without being able to test.
>
> Best,
> Sent from my iPad
>
> On 29/04/2013, at 07:08, "Sergey Dubov" <Sergey.Dubov at oracle.com> wrote:
>
>> Lucas Dupin <oi at lucasdup.in> писал(а) в своём письме Sun, 28 Apr 2013  
>> 18:22:19 +0400:
>>
>>> Hey guys,
>>> I'm working on Mac OS native fullscreen support for VirtualBox.
>>> It's my first time hacking the source, so I'll need some help. Ok?
>>>
>>> I've already found the class where you call showFullscreen() and  
>>> modified the UIMachineWindow to show the arrow on the right corner of  
>>> the title >>>bar.
>>> The code is self contained so I don't think we're going to have  
>>> compatibility issues, even with older versions of MacOs, like 10.6.
>>>
>>> One minor caveat is that you'll need MacOS SDK 10.7 to compile the  
>>> source. I don't think it's a problem since you'll still be able to  
>>> target older >>>versions, like 10
>>> What I really need to do now is to test the code I've written in a  
>>> proper way but I can't manage to turn my Virtual Machines on.
>>> I ran the loadall.sh script, so I don't think it's a kernel module  
>>> problem.
>>>
>>> Could you give me some directions on what to do? The error I receive  
>>> is:
>>> 	Failed to load VMMR0.r0 (VERR_GENERAL_FAILURE)
>>>
>>> And the details say:
>>> 	Result Code:	NS_ERROR_FAILURE (0x80004005)
>>> 	Component:	Console
>>> 	Interface:	IConsole {db7ab4ca-2a3f-4183-9243-c1208da92392}
>>>
>>>
>>> In debug mode, this is the stacktrace:
>>> 	Thread 11 Crashed:: EMT-0
>>> 	0   VBoxRT.dylib                  	0x000000011082ba0d  
>>> rtkldrConvertError(int) + 973 (ldrkStuff.cpp:197)
>>> 	1   VBoxRT.dylib                  	0x000000011082bf8a rtldrkLdrOpen +  
>>> 762 (ldrkStuff.cpp:880)
>>> 	2   VBoxRT.dylib                  	0x0000000110724f9c  
>>> rtldrOpenWithReader + 1052 (ldrEx.cpp:160)
>>> 	3   VBoxRT.dylib                  	0x000000011072763d RTLdrOpen + 541  
>>> (ldrFile.cpp:278)
>>> 	4   VBoxRT.dylib                  	0x0000000110871614  
>>> supLoadModule(char const*, char const*, char const*, void**) + 1204  
>>> >>>(SUPLib.cpp:1854)
>>> 	5   VBoxRT.dylib                  	0x0000000110873a00 SUPR3LoadModule  
>>> + 160 (SUPLib.cpp:1606)
>>> 	6   VBoxVMM.dylib                 	0x00000001101fd14e  
>>> pdmR3LoadR0U(UVM*, char const*, char const*, char const*) + 830  
>>> >>>(PDMLdr.cpp:673)
>>> 	7   VBoxVMM.dylib                 	0x00000001101fc3dc  
>>> PDMR3LdrLoadVMMR0U + 44 (PDMLdr.cpp:82)
>>> 	8   VBoxVMM.dylib                 	0x0000000110305b16  
>>> vmR3CreateU(UVM*, unsigned int, int (*)(UVM*, VM*, void*), void*) + 38  
>>> >>>(VM.cpp:586)
>>> 	9   VBoxVMM.dylib                 	0x0000000110312113  
>>> vmR3ReqProcessOneU(UVM*, VMREQ*) + 643 (VMReq.cpp:1254)
>>> 	10  VBoxVMM.dylib                 	0x000000011031327e VMR3ReqProcessU  
>>> + 1262 (VMReq.cpp:1170)
>>> 	11  VBoxVMM.dylib                 	0x000000011030fab8  
>>> vmR3EmulationThreadWithId(RTTHREADINT*, UVMCPU*, unsigned int) + 856  
>>> >>>(VMEmt.cpp:123)
>>> 	12  VBoxVMM.dylib                 	0x000000011030bce4  
>>> vmR3EmulationThread + 52 (VMEmt.cpp:62)
>>> 	13  VBoxRT.dylib                  	0x00000001107754d9 rtThreadMain +  
>>> 473 (thread.cpp:698)
>>> 	14  VBoxRT.dylib                  	0x00000001108648ec  
>>> rtThreadNativeMain(void*) + 444 (thread-posix.cpp:312)
>>> 	15  libsystem_c.dylib             	0x00007fff95ed47a2 _pthread_start  
>>> + 327
>>> 	16  libsystem_c.dylib             	0x00007fff95ec11e1 thread_start +  
>>> 13
>>>
>>>
>>> Best,
>>> Lucas Dupin
>>
>>
>> Hi Lucas.
>>
>> I just have a few words to tell about native MacOS X fullscreen feature:
>> 1. Within the current Runtime UI architecture having native MacOS X  
>> fullscreen support is not something easy (if possible at all).
>> Fullscreen-mode is not just "an arrow at the right corner", its  
>> internal mechanism which takes into account different aspects of  
>> VirtualBox GUI behavior.
>> When GUI changes mode representation (from normal to fullscreen,  
>> seamless or scale) through the menu action it recreates internal  
>> Runtime UI logic >>and finally machine-window(s), so entering  
>> fullscreen "the true Mac way" is not quite possible in such case.
>> Note: The VirtualBox Runtime UI architecture was developed in 2010,  
>> before the MacOS X Lion (2011) and ML (2012) was introduced, so such  
>> things >>like "animated fullscreen support" was not taken into account  
>> at all.
>> 2. Moreover, iirc we are still supporting build on MacOS X SDK 10.5 and  
>> wish to do so for now.
>> 3. And finally MacOS X Lion which supports "native fullscreen mode"  
>> doesn't have possibility to enter fullscreen on other than primary  
>> screen (multi->>screen fullscreen support appeared in MacOS X Mountain  
>> Lion) which is totally unacceptable.
>>
>> Taking into account these facts I'd say implementing and maintaining  
>> something *only* for MacOS X Mountain Lion is not our way.
>>
>> --With Best Regards,
>> [Oracle/VirtualBox] Sergey Dubov
>>
>>
-- 
With Best Regards,
[Oracle/VirtualBox] Sergey Dubov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20130429/284488b6/attachment.html 


More information about the vbox-dev mailing list