qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Booting Raspbian on RPi emulation


From: BALATON Zoltan
Subject: Re: [Qemu-devel] Booting Raspbian on RPi emulation
Date: Mon, 28 Jan 2019 16:30:46 +0100 (CET)
User-agent: Alpine 2.21.9999 (BSF 287 2018-06-16)

On Mon, 28 Jan 2019, Peter Maydell wrote:
On Sun, 27 Jan 2019 at 23:13, BALATON Zoltan <address@hidden> wrote:
On Sun, 27 Jan 2019, Peter Maydell wrote:
Unfortunately I'm not sufficiently familiar with how OSX
event handling works to figure out how to plumb it back in
again. It ought to be a fairly simple matter of "implement
whatever method OSX sends events to on whatever of our
various classes is the right one, and make it call handleEvent
with the NSEvent", but I've tried a few things and haven't
been able to actually get any event handling methods to
fire at all :-(

I think you need to implement keyDown: and keyUp: methods in QemuCocoaView
to get keyboard events and there are similar methods for mouse events,
see:

https://developer.apple.com/documentation/appkit/nsview?language=objc

Yeah, I got something working later last night. You also need
to implement acceptsFirstResponder or you don't get any events.

Yes, I remembered it also has something to do with FirstResponder but did not recall what you need for it.

So I have something that at least works for key events in the
monitor window now. I need to check whether we do the right
thing for things like cmd-key hotkeys which need to be handled
by the stock OSX event handling. (In the old scheme we deal with
these by having handleEvent pass them on to sendEvent, but in
the new setup that's an infinite recursion.)

But these are a lot of methods which are supposedly called from the
sendEvent: method of the NSWindow containing this view so maybe a better
place to catch all events is there. For this we need an NSWindow subclass
implementing sendEvent: which is then used to hold QemuCocoaView. I may be
wrong though, haven't tested it and don't know what you've tried.

Yeah, we could also do something like that, or another approach
I found by searching around is to use addLocalMonitorForEventsMatchingMask
to catch events. I'd kind of prefer to do whatever is the "expected"
setup for OSX apps, though, and I get the impression that completely
overriding sendEvent is a bit outside the normal path.

Event monitor is also an option on 10.6+ (which we already require I think). Not sure if it's simpler. Overriding sendEvent: is mentioned in the docs so probably it should be OK and as long as you pass all unhandled events to the super method it also should not break to much. I think command key actions are handled at the NSApp level so if we override at the NSWindow level then probably we don't have to care about those but I'm not completely sure.

Regards,
BALATON Zoltan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]