Re: [Qemu-devel] [PATCH] cocoa.m: Fix scroll wheel support

[Peter Maydell]

On 30 December 2017 at 16:30, John Arbuckle  wrote:
> When using a mouse's scroll wheel in a guest with the cocoa front-end, the 
> mouse pointer moves up and down instead of scrolling the window. This patch 
> fixes this problem.

Thanks for this patch. The code looks good to me, but
you can now also remove the entries for INPUT_BUTTON_WHEEL_UP
and INPUT_BUTTON_WHEEL_DOWN from the bmap[] array, because
we can no longer get into that code with those button types.

I think it's also worth having a comment that we send
wheel events to the guest regardless of window focus now
(which is in line with standard OSX UI behaviour, so it
seems like the right thing).

PS: can you line-wrap your commit messages, please?

> Signed-off-by: John Arbuckle 
> ---
>  ui/cocoa.m | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/ui/cocoa.m b/ui/cocoa.m
> index 330ccebf90..d2e5f80b74 100644
> --- a/ui/cocoa.m
> +++ b/ui/cocoa.m
> @@ -786,11 +786,18 @@ - (void) handleEvent:(NSEvent *)event
>  mouse_event = true;
>  break;
>  case NSEventTypeScrollWheel:
> -if (isMouseGrabbed) {
> -buttons |= ([event deltaY] < 0) ?
> -MOUSE_EVENT_WHEELUP : MOUSE_EVENT_WHEELDN;
> -}
> -mouse_event = true;
> +/* Determine if this is a scroll up or scroll down event */
> +buttons = ([event scrollingDeltaY] > 0) ?
> +INPUT_BUTTON_WHEEL_UP : INPUT_BUTTON_WHEEL_DOWN;
> +qemu_input_queue_btn(dcl->con, buttons, true);
> +qemu_input_event_sync();
> +qemu_input_queue_btn(dcl->con, buttons, false);
> +qemu_input_event_sync();
> +/*
> + * Since deltaY also reports scroll wheel events we prevent mouse
> + * movement code from executing.
> + */
> +mouse_event = false;
>  break;
>  default:
>  [NSApp sendEvent:event];
> --
> 2.14.3 (Apple Git-98)
>

thanks
-- PMM

[Qemu-devel] [PATCH] cocoa.m: Fix scroll wheel support

[John Arbuckle]

When using a mouse's scroll wheel in a guest with the cocoa front-end, the 
mouse pointer moves up and down instead of scrolling the window. This patch 
fixes this problem.

Signed-off-by: John Arbuckle 
---
 ui/cocoa.m | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index 330ccebf90..d2e5f80b74 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -786,11 +786,18 @@ - (void) handleEvent:(NSEvent *)event
 mouse_event = true;
 break;
 case NSEventTypeScrollWheel:
-if (isMouseGrabbed) {
-buttons |= ([event deltaY] < 0) ?
-MOUSE_EVENT_WHEELUP : MOUSE_EVENT_WHEELDN;
-}
-mouse_event = true;
+/* Determine if this is a scroll up or scroll down event */
+buttons = ([event scrollingDeltaY] > 0) ?
+INPUT_BUTTON_WHEEL_UP : INPUT_BUTTON_WHEEL_DOWN;
+qemu_input_queue_btn(dcl->con, buttons, true);
+qemu_input_event_sync();
+qemu_input_queue_btn(dcl->con, buttons, false);
+qemu_input_event_sync();
+/*
+ * Since deltaY also reports scroll wheel events we prevent mouse
+ * movement code from executing.
+ */
+mouse_event = false;
 break;
 default:
 [NSApp sendEvent:event];
-- 
2.14.3 (Apple Git-98)

Re: [Qemu-devel] [PATCH] cocoa.m: Adds console items to the view menu

[Programmingkid]

On Feb 13, 2015, at 2:45 AM, Gerd Hoffmann wrote:

  Hi,
 
 We're going to need to automatically create and update
 the menu entries based on which consoles get created
 if we want this to work properly, I think. Gerd, any
 suggestions?  Is there a hook for list of active
 consoles has changed?
 
 No.  consoles are not hotpluggable.
 
 What's the right way to get
 the printable name of a console?
 
 gd_vc_gfx_init() has code for gfx consoles (qemu_console_is_graphic() ==
 true).
 
 There is nothing for text consoles.
 
 Guess we should create a qemu_console_get_label() helper function in
 ui/console.c, then move the code from gd_vc_gfx_init() to that place,
 and for text consoles use QemuConsole-chr-label.
 
 cheers,
  Gerd
Thank you Gerd for your suggestion. 

Here is my suggestion:
int get_Graphics_Console_Index()
int get_Serial_Console_Index()
int get_Parallel_Console_Index()
int get_Monitor_Console_Index()

Then I would be able to do this:
console_select(get_Serial_Console_Index());

The is simple and to the point. No having to have to search for a console.
If the console does not exist, the function could return -1. Then the code
would something like this:

if(get_Serial_Console_Index() != -1)
console_select(get_Serial_Console_Index());
else
printf(Sorry but Serial console does not exist\n\a);

Re: [Qemu-devel] [PATCH] cocoa.m: Adds console items to the view menu

[Programmingkid]

On Feb 11, 2015, at 10:39 PM, Peter Maydell wrote:

 On 24 January 2015 at 01:56, Programmingkid programmingk...@gmail.com wrote:
 This patch adds these consoles to the View menu:
 VGA
 QEMU Monitor
 Parallel
 Serial
 
 Signed-off-by: John Arbuckle programmingk...@gmail.com
 
 +/* Displays the VGA screen */
 +- (void)displayVGA:(id)sender
 +{
 +console_select(0);
 +}
 +
 +/* Displays the QEMU Monitor screen */
 +- (void)displayMonitor:(id)sender
 +{
 +console_select(1);
 +}
 +
 +/* Displays the parallel port screen */
 +- (void)displayParallel:(id)sender
 +{
 +console_select(3);
 +}
 +
 +/* Displays the serial port screen */
 +- (void)displaySerial:(id)sender
 +{
 +console_select(2);
 +}
 
 I'm afraid this doesn't work, because there's no guarantee
 that these consoles will be created or in this order.
 They just happen to be the set you get for the x86
 PC model. If you boot a versatilepb ARM image with the
 serial output directed to stdio, for instance, then the
 serial entry in the menu gets you the parallel
 port console, and the parallel port entry does nothing,
 because this board and config happens to end up creating
 only 3 consoles, not 4 (graphics, monitor, parallel).
 
 We're going to need to automatically create and update
 the menu entries based on which consoles get created
 if we want this to work properly, I think. Gerd, any
 suggestions? Is there a hook for list of active
 consoles has changed? What's the right way to get
 the printable name of a console?

Do you know where the code is that creates the consoles? 

Re: [Qemu-devel] [PATCH] cocoa.m: Adds console items to the view menu

[Gerd Hoffmann]

  Hi,

 We're going to need to automatically create and update
 the menu entries based on which consoles get created
 if we want this to work properly, I think. Gerd, any
 suggestions?  Is there a hook for list of active
 consoles has changed?

No.  consoles are not hotpluggable.

 What's the right way to get
 the printable name of a console?

gd_vc_gfx_init() has code for gfx consoles (qemu_console_is_graphic() ==
true).

There is nothing for text consoles.

Guess we should create a qemu_console_get_label() helper function in
ui/console.c, then move the code from gd_vc_gfx_init() to that place,
and for text consoles use QemuConsole-chr-label.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH] cocoa.m: Adds console items to the view menu

[Programmingkid]

On Feb 11, 2015, at 10:39 PM, Peter Maydell wrote:

 On 24 January 2015 at 01:56, Programmingkid programmingk...@gmail.com wrote:
 This patch adds these consoles to the View menu:
 VGA
 QEMU Monitor
 Parallel
 Serial
 
 Signed-off-by: John Arbuckle programmingk...@gmail.com
 
 +/* Displays the VGA screen */
 +- (void)displayVGA:(id)sender
 +{
 +console_select(0);
 +}
 +
 +/* Displays the QEMU Monitor screen */
 +- (void)displayMonitor:(id)sender
 +{
 +console_select(1);
 +}
 +
 +/* Displays the parallel port screen */
 +- (void)displayParallel:(id)sender
 +{
 +console_select(3);
 +}
 +
 +/* Displays the serial port screen */
 +- (void)displaySerial:(id)sender
 +{
 +console_select(2);
 +}
 
 I'm afraid this doesn't work, because there's no guarantee
 that these consoles will be created or in this order.
 They just happen to be the set you get for the x86
 PC model. If you boot a versatilepb ARM image with the
 serial output directed to stdio, for instance, then the
 serial entry in the menu gets you the parallel
 port console, and the parallel port entry does nothing,
 because this board and config happens to end up creating
 only 3 consoles, not 4 (graphics, monitor, parallel).
 
 We're going to need to automatically create and update
 the menu entries based on which consoles get created
 if we want this to work properly, I think. Gerd, any
 suggestions? Is there a hook for list of active
 consoles has changed? What's the right way to get
 the printable name of a console?
 

I was hoping the gtk.c file would have some code I could use, but it doesn't. 
My model for these menu items came from a YouTube video demonstrating the GTK 
UI in QEMU. Does QEMU still have these menu items in the GTK UI? The gtk.c file 
does not seem to indicate that. 

Re: [Qemu-devel] [PATCH] cocoa.m: Adds console items to the view menu

[Peter Maydell]

On 24 January 2015 at 01:56, Programmingkid programmingk...@gmail.com wrote:
 This patch adds these consoles to the View menu:
 VGA
 QEMU Monitor
 Parallel
 Serial

 Signed-off-by: John Arbuckle programmingk...@gmail.com

 +/* Displays the VGA screen */
 +- (void)displayVGA:(id)sender
 +{
 +console_select(0);
 +}
 +
 +/* Displays the QEMU Monitor screen */
 +- (void)displayMonitor:(id)sender
 +{
 +console_select(1);
 +}
 +
 +/* Displays the parallel port screen */
 +- (void)displayParallel:(id)sender
 +{
 +console_select(3);
 +}
 +
 +/* Displays the serial port screen */
 +- (void)displaySerial:(id)sender
 +{
 +console_select(2);
 +}

I'm afraid this doesn't work, because there's no guarantee
that these consoles will be created or in this order.
They just happen to be the set you get for the x86
PC model. If you boot a versatilepb ARM image with the
serial output directed to stdio, for instance, then the
serial entry in the menu gets you the parallel
port console, and the parallel port entry does nothing,
because this board and config happens to end up creating
only 3 consoles, not 4 (graphics, monitor, parallel).

We're going to need to automatically create and update
the menu entries based on which consoles get created
if we want this to work properly, I think. Gerd, any
suggestions? Is there a hook for list of active
consoles has changed? What's the right way to get
the printable name of a console?

thanks
-- PMM

[Qemu-devel] [PATCH] cocoa.m: Adds console items to the view menu

[Programmingkid]

This patch adds these consoles to the View menu:
VGA
QEMU Monitor
Parallel
Serial

Signed-off-by: John Arbuckle programmingk...@gmail.com

---
 ui/cocoa.m |   34 ++
 1 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/ui/cocoa.m b/ui/cocoa.m
index d37c29b..c88c0d0 100644
--- a/ui/cocoa.m
+++ b/ui/cocoa.m
@@ -801,6 +801,10 @@ QemuCocoaView *cocoaView;
 - (void)toggleFullScreen:(id)sender;
 - (void)showQEMUDoc:(id)sender;
 - (void)showQEMUTec:(id)sender;
+- (void)displayVGA:(id)sender;
+- (void)displayMonitor:(id)sender;
+- (void)displayParallel:(id)sender;
+- (void)displaySerial:(id)sender;
 @end
 
 @implementation QemuCocoaAppController
@@ -943,6 +947,31 @@ QemuCocoaView *cocoaView;
 [[NSWorkspace sharedWorkspace] openFile:[NSString 
stringWithFormat:@%@/../doc/qemu/qemu-tech.html,
 [[NSBundle mainBundle] resourcePath]] withApplication:@Help Viewer];
 }
+
+/* Displays the VGA screen */
+- (void)displayVGA:(id)sender
+{
+console_select(0);
+}
+
+/* Displays the QEMU Monitor screen */
+- (void)displayMonitor:(id)sender
+{
+console_select(1);
+}
+
+/* Displays the parallel port screen */
+- (void)displayParallel:(id)sender
+{
+console_select(3);
+}
+
+/* Displays the serial port screen */
+- (void)displaySerial:(id)sender
+{
+console_select(2);
+}
+
 @end
 
 
@@ -1006,6 +1035,11 @@ int main (int argc, const char * argv[]) {
 // View menu
 menu = [[NSMenu alloc] initWithTitle:@View];
 [menu addItem: [[[NSMenuItem alloc] initWithTitle:@Enter Fullscreen 
action:@selector(toggleFullScreen:) keyEquivalent:@f] autorelease]]; // 
Fullscreen
+[menu addItem:[NSMenuItem separatorItem]]; //Separator
+[menu addItem: [[[NSMenuItem alloc] initWithTitle:@VGA 
action:@selector(displayVGA:) keyEquivalent:@] autorelease]]; // VGA
+[menu addItem: [[[NSMenuItem alloc] initWithTitle:@QEMU Monitor 
action:@selector(displayMonitor:) keyEquivalent:@] autorelease]]; // QEMU 
Monitor
+[menu addItem: [[[NSMenuItem alloc] initWithTitle:@Parallel 
action:@selector(displayParallel:) keyEquivalent:@] autorelease]]; // Parallel
+[menu addItem: [[[NSMenuItem alloc] initWithTitle:@Serial 
action:@selector(displaySerial:) keyEquivalent:@] autorelease]]; // Serial
 menuItem = [[[NSMenuItem alloc] initWithTitle:@View action:nil 
keyEquivalent:@] autorelease];
 [menuItem setSubmenu:menu];
 [[NSApp mainMenu] addItem:menuItem];
-- 
1.7.5.4

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Alexander Graf]

On Jan 30, 2008, at 9:30 PM, Mike Kronenberg wrote:



On 30.01.2008, at 19:59, Alexander Graf wrote:



On Jan 21, 2008, at 5:18 PM, Mike Kronenberg wrote:


This is a complete rewrite of cocoa.m to support Core Graphics.

As mentioned in earlier threads, the QuickDraw API is depreciated  
starting with OS X 10.4.

Now with OS X 10.5 it won't even compile QuickDraw code on x86_64.


This implementation of cocoa.m has the following features:

[new] partial drawing of the window as needed, implemented with CG.
[new] fullscreen support
[new] tablet support
[new] View menu and item to enter Fullscreen (cmd-f)
[new] Help menu and items to show qemu-doc.html (cmd-?) and qemu- 
tec.html in the OS X Help Viewer

[new] -name is shown in Title-bar of window
[fix] Application menu creation for 10.4+ (API is private as of  
10.4)
[fix] Mouse-clicks on the guests window widgets are no longer  
intercepted
[fix] apple keyboard shortcuts forwarded (minimize (cmd-m), hide  
QEMU (cmd-h), quit QEMU (cmd-q))


It should compile on ppc/intel starting form 10.3 (10.2 with the  
known workarounds).


Please test and comment


I'm sorry that I didn't find the time to test this implementation  
before.


It's damn slow.

I ran it using my x86_64 on 10.5.1, targetting x86_64-softmmu and  
booting a linux kernel. I could literally see every like getting  
repainted (which btw did not happen with my quick hacky version I  
sent to the list some time ago).


I think the major problem is that too much is being done during  
drawRect. If I understand the code correctly, you create CGImage  
objects on every repaint, which is prone to be slow.


Why not simply reuse the framebuffer qemu provides anyway and leave  
everything else to CG?


Alex





Hi Alex,

yes, as stated earlyer, it is slower than Quickdraw, especially if  
the whole screen is redrawn. Overal emulation speed for GUI apps is  
faster, dough, as only small portions of the screen are redrawn.


That's good to hear. I tend to use Linux in command line mode in qemu  
quite often though, so for me the most important thing is full screen  
update, which apparently became slower. Merely running an SDL targeted  
qemu (did this on x86_64 linux) vs a cocoa one shows that something  
feels wrong on cocoa. Maybe there is no other way around this, but I  
still don't like seeing the screen scroll line for line ;-).


Unfortunately I don't have the time right now to investigate this in  
detail and I am really not into graphics programming usually. So for  
the time being it is still _way_ better than a solution that doesn't  
even compile.


The one thing I want to stress here is that maybe it might be worth  
looking into alternatives. If I find the time to do it, I will do so.  
I somehow like the idea of having a GL based video output.


Alex

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Jamie Lokier]

Anthony Liguori wrote:
 VGA framebuffer operations come in as memory operations.  They're 
 tracked by watching what memory gets dirtied.  This can only operate at 
 a page-granularity so this results in scan-line granularity updates.  
 The VNC front-end goes to great lengths to keep a shadowed framebuffer 
 and reduce these updates to a smaller update region.  You could possibly 
 look at refactoring that code.  However...

That update region code should probably be moved to something generic
and made into a generic display option.

Reducing update region is logically orthogonal, and could work with
any update method (e.g. local X11, remote X11, local X11-OpenGL,
remote X11-OpenGL, SDL etc.).  With some of those, for some people
(especially some but not all remote setups) it might be worth it.

 I would be amazed if screen updates on OS X are so slow that it would 
 make a difference if updates are in scanline granularities.  The copying 
 latency is nothing compared to the other latencies in QEMU.  A modern 
 processor can move memory at an extremely high speed.
 
 At a refresh rate of 30 times per second, this is only ~4MB of data for 
 mouse movements.  A typical processor can easily handle many GB of data 
 per second.

That's 16MB/frame on an Apple Cinema display at 32bpp, which is
0.5GB/sec.  Not too much, but not free either :-)

-- Jamie

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Anthony Liguori]

Jamie Lokier wrote:

Anthony Liguori wrote:
  
VGA framebuffer operations come in as memory operations.  They're 
tracked by watching what memory gets dirtied.  This can only operate at 
a page-granularity so this results in scan-line granularity updates.  
The VNC front-end goes to great lengths to keep a shadowed framebuffer 
and reduce these updates to a smaller update region.  You could possibly 
look at refactoring that code.  However...



That update region code should probably be moved to something generic
and made into a generic display option.

Reducing update region is logically orthogonal, and could work with
any update method (e.g. local X11, remote X11, local X11-OpenGL,
remote X11-OpenGL, SDL etc.).  With some of those, for some people
(especially some but not all remote setups) it might be worth it.

  
I would be amazed if screen updates on OS X are so slow that it would 
make a difference if updates are in scanline granularities.  The copying 
latency is nothing compared to the other latencies in QEMU.  A modern 
processor can move memory at an extremely high speed.


At a refresh rate of 30 times per second, this is only ~4MB of data for 
mouse movements.  A typical processor can easily handle many GB of data 
per second.



That's 16MB/frame on an Apple Cinema display at 32bpp, which is
0.5GB/sec.  Not too much, but not free either :-)
  


But your guest isn't displaying to the entire screen...  I was assuming 
a 32-pixel height, 1024 pixel wide region.


Regards,

Anthony Liguori


-- Jamie


  

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Jamie Lokier]

Anthony Liguori wrote:
 That's 16MB/frame on an Apple Cinema display at 32bpp, which is
 0.5GB/sec.  Not too much, but not free either :-)
   
 
 But your guest isn't displaying to the entire screen...  I was assuming 
 a 32-pixel height, 1024 pixel wide region.

I don't know about you; I quite like running Qemu in full screen mode
on my biggest screen when I want to do some work in another OS.  (I
don't have a Cinema display, though, it was just to make the point).

But this is not an important thing, let's leave it.

-- Jamie

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Alexander Graf]

On Jan 30, 2008, at 7:59 PM, Alexander Graf wrote:



On Jan 21, 2008, at 5:18 PM, Mike Kronenberg wrote:


This is a complete rewrite of cocoa.m to support Core Graphics.

As mentioned in earlier threads, the QuickDraw API is depreciated  
starting with OS X 10.4.

Now with OS X 10.5 it won't even compile QuickDraw code on x86_64.


This implementation of cocoa.m has the following features:

[new] partial drawing of the window as needed, implemented with CG.
[new] fullscreen support
[new] tablet support
[new] View menu and item to enter Fullscreen (cmd-f)
[new] Help menu and items to show qemu-doc.html (cmd-?) and qemu- 
tec.html in the OS X Help Viewer

[new] -name is shown in Title-bar of window
[fix] Application menu creation for 10.4+ (API is private as of 10.4)
[fix] Mouse-clicks on the guests window widgets are no longer  
intercepted
[fix] apple keyboard shortcuts forwarded (minimize (cmd-m), hide  
QEMU (cmd-h), quit QEMU (cmd-q))


It should compile on ppc/intel starting form 10.3 (10.2 with the  
known workarounds).


Please test and comment


I'm sorry that I didn't find the time to test this implementation  
before.


It's damn slow.

I ran it using my x86_64 on 10.5.1, targetting x86_64-softmmu and  
booting a linux kernel. I could literally see every like getting  
repainted (which btw did not happen with my quick hacky version I  
sent to the list some time ago).


I think the major problem is that too much is being done during  
drawRect. If I understand the code correctly, you create CGImage  
objects on every repaint, which is prone to be slow.


Why not simply reuse the framebuffer qemu provides anyway and leave  
everything else to CG?


I just reread my mail again and realized that I didn't say anything  
positive. Sorry about that.


It's great to see someone working on Mac OS X support and thanks a lot  
for writing a compatible implementation of cocoa.m that works with  
every Mac OS X version out there.


Alex

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Alexander Graf]

On Jan 21, 2008, at 5:18 PM, Mike Kronenberg wrote:


This is a complete rewrite of cocoa.m to support Core Graphics.

As mentioned in earlier threads, the QuickDraw API is depreciated  
starting with OS X 10.4.

Now with OS X 10.5 it won't even compile QuickDraw code on x86_64.


This implementation of cocoa.m has the following features:

[new] partial drawing of the window as needed, implemented with CG.
[new] fullscreen support
[new] tablet support
[new] View menu and item to enter Fullscreen (cmd-f)
[new] Help menu and items to show qemu-doc.html (cmd-?) and qemu- 
tec.html in the OS X Help Viewer

[new] -name is shown in Title-bar of window
[fix] Application menu creation for 10.4+ (API is private as of 10.4)
[fix] Mouse-clicks on the guests window widgets are no longer  
intercepted
[fix] apple keyboard shortcuts forwarded (minimize (cmd-m), hide  
QEMU (cmd-h), quit QEMU (cmd-q))


It should compile on ppc/intel starting form 10.3 (10.2 with the  
known workarounds).


Please test and comment


I'm sorry that I didn't find the time to test this implementation  
before.


It's damn slow.

I ran it using my x86_64 on 10.5.1, targetting x86_64-softmmu and  
booting a linux kernel. I could literally see every like getting  
repainted (which btw did not happen with my quick hacky version I sent  
to the list some time ago).


I think the major problem is that too much is being done during  
drawRect. If I understand the code correctly, you create CGImage  
objects on every repaint, which is prone to be slow.


Why not simply reuse the framebuffer qemu provides anyway and leave  
everything else to CG?


Alex

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Mike Kronenberg]

On 30.01.2008, at 19:59, Alexander Graf wrote:



On Jan 21, 2008, at 5:18 PM, Mike Kronenberg wrote:


This is a complete rewrite of cocoa.m to support Core Graphics.

As mentioned in earlier threads, the QuickDraw API is depreciated  
starting with OS X 10.4.

Now with OS X 10.5 it won't even compile QuickDraw code on x86_64.


This implementation of cocoa.m has the following features:

[new] partial drawing of the window as needed, implemented with CG.
[new] fullscreen support
[new] tablet support
[new] View menu and item to enter Fullscreen (cmd-f)
[new] Help menu and items to show qemu-doc.html (cmd-?) and qemu- 
tec.html in the OS X Help Viewer

[new] -name is shown in Title-bar of window
[fix] Application menu creation for 10.4+ (API is private as of 10.4)
[fix] Mouse-clicks on the guests window widgets are no longer  
intercepted
[fix] apple keyboard shortcuts forwarded (minimize (cmd-m), hide  
QEMU (cmd-h), quit QEMU (cmd-q))


It should compile on ppc/intel starting form 10.3 (10.2 with the  
known workarounds).


Please test and comment


I'm sorry that I didn't find the time to test this implementation  
before.


It's damn slow.

I ran it using my x86_64 on 10.5.1, targetting x86_64-softmmu and  
booting a linux kernel. I could literally see every like getting  
repainted (which btw did not happen with my quick hacky version I  
sent to the list some time ago).


I think the major problem is that too much is being done during  
drawRect. If I understand the code correctly, you create CGImage  
objects on every repaint, which is prone to be slow.


Why not simply reuse the framebuffer qemu provides anyway and leave  
everything else to CG?


Alex





Hi Alex,

yes, as stated earlyer, it is slower than Quickdraw, especially if the  
whole screen is redrawn. Overal emulation speed for GUI apps is  
faster, dough, as only small portions of the screen are redrawn.


Unfortunateley, there is no official direct access to the  
framebuffer anymore, since apple depreciated QuickDraw. [1]
This way, there is no sharing/direct mapping of the cg framebuffer and  
qemu screenbuffer anymore.
Every time, a section needs display, that part of the qemu  
screenbuffer is mapped to a cg image and then copied on top of the CG  
stack.
CG is fully OpenGL based, so basically, if it needs to refresh an  
area, it has to load the area as texture, hence the copy.


Offtoppic about updated regions in Windows:
While testing with Quartzdebug, I realized, that qemu is updating  
always the whole screenwidth even if only the mouse is moved... is  
this a qemu problem, or is this the default windows behaviour?


Mike

[1] http://developer.apple.com/documentation/Carbon/Conceptual/QuickDrawToQuartz2D/tq_image_data/chapter_6_section_2.html#/ 
/apple_ref/doc/uid/TP40001098-CH227-BBCFFDBB

smime.p7s
Description: S/MIME cryptographic signature

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Johannes Schindelin]

Hi,

On Wed, 30 Jan 2008, Mike Kronenberg wrote:

 Offtoppic about updated regions in Windows: While testing with 
 Quartzdebug, I realized, that qemu is updating always the whole 
 screenwidth even if only the mouse is moved... is this a qemu problem, 
 or is this the default windows behaviour?

As far as I remember, this is a QEmu problem.  It only marks lines as 
dirty, not pixels.

Ciao,
Dscho

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Pierre d'Herbemont]

On Jan 30, 2008, at 9:30 PM, Mike Kronenberg wrote:

Unfortunateley, there is no official direct access to the  
framebuffer anymore, since apple depreciated QuickDraw. [1]


Well, you can using OpenGL and Apple's Extension have a nearly direct  
VRAM access, the idea is to use


glEnable( GL_UNPACK_CLIENT_STORAGE_APPLE );
glPixelStorei( GL_UNPACK_CLIENT_STORAGE_APPLE, GL_TRUE );

and

glTexParameteri( VLCGL_TARGET, GL_TEXTURE_STORAGE_HINT_APPLE,  
GL_STORAGE_SHARED_APPLE );


On the texture on which you want to draw. See:

http://developer.apple.com/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_texturedata/chapter_10_section_2.html

Pierre.

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Mike Kronenberg]

I ran it using my x86_64 on 10.5.1, targetting x86_64-softmmu and  
booting a linux kernel. I could literally see every like getting  
repainted (which btw did not happen with my quick hacky version I  
sent to the list some time ago).


You did not notice the effect with Your implementation, because the  
the whole screen is redrawn every time.

With this implementation, only the parts requested by qemu are updated.

If You take a dosprompt, every line that moves up, triggers a redraw  
(only for the specific line) - this is why you notice the redraw.

You can test this easily with the Quartz debugger.

But never the less, overall speed is much faster with partial redraw,  
than if You redraw the whole screen every time.


Mike




smime.p7s
Description: S/MIME cryptographic signature

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[andrzej zaborowski]

On 30/01/2008, Johannes Schindelin [EMAIL PROTECTED] wrote:
 Hi,

 On Wed, 30 Jan 2008, Mike Kronenberg wrote:

  Offtoppic about updated regions in Windows: While testing with
  Quartzdebug, I realized, that qemu is updating always the whole
  screenwidth even if only the mouse is moved... is this a qemu problem,
  or is this the default windows behaviour?

 As far as I remember, this is a QEmu problem.  It only marks lines as
 dirty, not pixels.

In addition lines are not marked dirty because they have a dirty pixel
in them but because they have a pixel in a dirty page. That means more
lines are updated than those containing dirty pixels.

Cheers

Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support

[Anthony Liguori]

Mike Kronenberg wrote:
While testing with Quartzdebug, I realized, that qemu is updating 
always the whole screenwidth even if only the mouse is moved... is 
this a qemu problem, or is this the default windows behaviour?


VGA framebuffer operations come in as memory operations.  They're 
tracked by watching what memory gets dirtied.  This can only operate at 
a page-granularity so this results in scan-line granularity updates.  
The VNC front-end goes to great lengths to keep a shadowed framebuffer 
and reduce these updates to a smaller update region.  You could possibly 
look at refactoring that code.  However...


I would be amazed if screen updates on OS X are so slow that it would 
make a difference if updates are in scanline granularities.  The copying 
latency is nothing compared to the other latencies in QEMU.  A modern 
processor can move memory at an extremely high speed.


At a refresh rate of 30 times per second, this is only ~4MB of data for 
mouse movements.  A typical processor can easily handle many GB of data 
per second.


Regards,

Anthony Liguori


Mike

[1] 
http://developer.apple.com/documentation/Carbon/Conceptual/QuickDrawToQuartz2D/tq_image_data/chapter_6_section_2.html#//apple_ref/doc/uid/TP40001098-CH227-BBCFFDBB

[Qemu-devel] [patch] cocoa.m - Core Graphics support

[Mike Kronenberg]

This is a complete rewrite of cocoa.m to support Core Graphics.

As mentioned in earlier threads, the QuickDraw API is depreciated  
starting with OS X 10.4.

Now with OS X 10.5 it won't even compile QuickDraw code on x86_64.


This implementation of cocoa.m has the following features:

[new] partial drawing of the window as needed, implemented with CG.
[new] fullscreen support
[new] tablet support
[new] View menu and item to enter Fullscreen (cmd-f)
[new] Help menu and items to show qemu-doc.html (cmd-?) and qemu- 
tec.html in the OS X Help Viewer

[new] -name is shown in Title-bar of window
[fix] Application menu creation for 10.4+ (API is private as of 10.4)
[fix] Mouse-clicks on the guests window widgets are no longer  
intercepted
[fix] apple keyboard shortcuts forwarded (minimize (cmd-m), hide QEMU  
(cmd-h), quit QEMU (cmd-q))


It should compile on ppc/intel starting form 10.3 (10.2 with the known  
workarounds).


Please test and comment

Mike

File as .gz
http://www.kberg.ch/qemu/091patches/cocoa.m.gz




/*
 * QEMU Cocoa CG display driver
 *
 * Copyright (c) 2008 Mike Kronenberg
 *
 * Permission is hereby granted, free of charge, to any person  
obtaining a copy
 * of this software and associated documentation files (the  
Software), to deal
 * in the Software without restriction, including without limitation  
the rights
 * to use, copy, modify, merge, publish, distribute, sublicense, and/ 
or sell
 * copies of the Software, and to permit persons to whom the Software  
is

 * furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be  
included in

 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,  
EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF  
MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT  
SHALL
 * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES  
OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,  
ARISING FROM,
 * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER  
DEALINGS IN

 * THE SOFTWARE.
 */

#import Cocoa/Cocoa.h

#include qemu-common.h
#include console.h
#include sysemu.h


//#define DEBUG

#ifdef DEBUG
#define COCOA_DEBUG(...)  { (void) fprintf (stdout, __VA_ARGS__); }
#else
#define COCOA_DEBUG(...)  ((void) 0)
#endif

#define cgrect(nsrect) (*(CGRect *)(nsrect))
#define COCOA_MOUSE_EVENT \
if (isTabletEnabled) { \
kbd_mouse_event((int)(p.x * 0x7FFF / screen.width), (int) 
((screen.height - p.y) * 0x7FFF / screen.height), 0, buttons); \

} else if (isMouseGrabed) { \
kbd_mouse_event((int)[event deltaX], (int)[event deltaY],  
0, buttons); \

} else { \
[NSApp sendEvent:event]; \
}

typedef struct {
int width;
int height;
int bitsPerComponent;
int bitsPerPixel;
} QEMUScreen;

int qemu_main(int argc, char **argv); // main defined in qemu/vl.c
NSWindow *normalWindow;
id cocoaView;
static void *screenBuffer;

int gArgc;
char **gArgv;

// keymap conversion
int keymap[] =
{
//  SdlImacImacHSdlH104xtH  104xtC  sdl
30, //  0   0x000x1eA   QZ_a
31, //  1   0x010x1fS   QZ_s
32, //  2   0x020x20D   QZ_d
33, //  3   0x030x21F   QZ_f
35, //  4   0x040x23H   QZ_h
34, //  5   0x050x22G   QZ_g
44, //  6   0x060x2cZ   QZ_z
45, //  7   0x070x2dX   QZ_x
46, //  8   0x080x2eC   QZ_c
47, //  9   0x090x2fV   QZ_v
0,  //  10  0x0AUndefined
48, //  11  0x0B0x30B   QZ_b
16, //  12  0x0C0x10Q   QZ_q
17, //  13  0x0D0x11W   QZ_w
18, //  14  0x0E0x12E   QZ_e
19, //  15  0x0F0x13R   QZ_r
21, //  16  0x100x15Y   QZ_y
20, //  17  0x110x14T   QZ_t
2,  //  18  0x120x021   QZ_1
3,  //  19  0x130x032   QZ_2
4,  //  20  0x140x043   QZ_3
5,  //  21  0x150x054   QZ_4
7,  //  22  0x160x076   QZ_6
6,  //  23  0x170x065   QZ_5
13, //  24  0x180x0d=   QZ_EQUALS
10, //  25  0x190x0a9   QZ_9
8,  //  26  0x1A0x087   QZ_7
12, //  27  0x1B0x0c-   QZ_MINUS
9,  //  28  0x1C0x098   QZ_8
11, //  29  0x1D0x0b0   QZ_0
27, //  30  0x1E0x1b]   

[Qemu-devel] [PATCH] cocoa.m - keymap fixes

[Joachim Henke]

The attached patch
- fixes a wrong entry in the keycode translation map (0x9c = 156, not 152)
- adds some entries to support more keys on Apple USB keyboards
- changes keymap[] to be an array of bytes (saves some space)
- fixes a typo in a warning message

Kind regards,
Jo.


-- 
Joachim Henke
http://he-jo.net/

cocoa-keycodes.diff
Description: Binary data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [PATCH] cocoa.m: fix missing type declarations

[Joachim Henke]

In the function header of 'CustomApplicationMain', the types of 
'argc' and 'argv' are not declared so gcc expects them to be int, 
which is of course wrong for 'argv'. We can safely remove these 
parameters since they are not used in the function, and are globally 
available in 'gArgc' and 'gArgv' anyway.


Regards,
Jo.

--
Joachim Henke
http://he-jo.net/


cocoa-fix-1.diff
Description: Binary data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] cocoa.m

[Mike Kronenberg]

Natalia Portillo wrote:



El 27/05/2005, a las 12:42, Mike Kronenberg escribió:



   -cocoalivethumbnail   = qemu produces a 100x75 PNG thumbnail  
every 10 sec


GREAT!!!

But, better if can be specified how many time and/or a shortcut (like  
in virtualpc)




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


I'll put that on my todo list.

btw:
The patch provides two thumbnailer: quality and fast
- quality: just grabs the whole screen and makes a downsample = slow 
but nice
- fast: just grabs the needed bits from current_ds = like pixel 
resample in PS :)

   = BUT if you use fast, half of the pic is ok, and half is garbage
   so if someone could look over it and find the bug, that would be great.
   one could even use a 32bit pointer to further reduce the cpu time 
needed for the thumb.


Mike


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [PATCH] cocoa.m

[Pierre d'Herbemont]

On 27 mai 05, at 16:51, Mike Kronenberg wrote:

Pierre would like to put the whole thing in the head tree. I would  
be ready to do so, too, if this is wanted.


I didn't realize that the Q app was a front end. It would be much  
cleaner to have it running in qemu as the cocoa qemu driver. That  
should be done with not much troubles, if we manage to get qemu  
thread safe. Did you try that way?


Pierre.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel