From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34733) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLtp2-0006Uo-Vp for qemu-devel@nongnu.org; Wed, 20 Jan 2016 09:33:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLtoy-000662-VW for qemu-devel@nongnu.org; Wed, 20 Jan 2016 09:33:20 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42027) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLtoy-00065y-Qw for qemu-devel@nongnu.org; Wed, 20 Jan 2016 09:33:16 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 54F3DC077547 for ; Wed, 20 Jan 2016 14:33:16 +0000 (UTC) Date: Wed, 20 Jan 2016 15:33:14 +0100 From: Kevin Wolf Message-ID: <20160120143314.GC4793@noname.redhat.com> References: <1453110880.23289.7.camel@redhat.com> <569D4C69.5070304@redhat.com> <1453208507.18326.77.camel@redhat.com> <20160119133832.GG2398@work-vm> <1453212861.18326.97.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1453212861.18326.97.camel@redhat.com> Subject: Re: [Qemu-devel] RFC: running the user interface in a thread ... List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: David Airlie , =?iso-8859-1?Q?Marc-Andr=E9?= Lureau , "Dr. David Alan Gilbert" , qemu-devel Am 19.01.2016 um 15:14 hat Gerd Hoffmann geschrieben: > Hi, > > > That does feel safer, if you can find an efficient way to do the graphics. > > A lot less code running with the privs of the qemu process. > > That is where it starts to become tricky ... > > On modern linux we can simply use dma-bufs. > > On older linux and generic posix (*bsd etc) we should be able to use > sysv shared memory. > > As MacOS X is based on BSD I'd expect sysv shared memory is available > there too. Possibly we can use something more efficient there, we have > macos-specific ui code anyway. > > Windows? Hmm, no idea how to shared memory there. > > We also need a control channel, to manage the shm bufs, to send user > input (kbd/mouse), to implement some control things (machine menu in gtk > ui). One option would be to simply use the monitor for that. The other > one is to invent something limited to the stuff actually needed instead > of handing over a dangerous swiss army knife to the process running the > UI. Hmm, maybe a new monitor mode with a limited set of commands would > do too. I think you need to offer the full monitor command set anyway because a UI that is on par with SDL or GTK must provide a monitor interface to the user. Kevin