From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34773) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rrs3I-0000rU-Hq for qemu-devel@nongnu.org; Mon, 30 Jan 2012 09:17:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rrs38-0000WC-6l for qemu-devel@nongnu.org; Mon, 30 Jan 2012 09:17:48 -0500 Received: from moutng.kundenserver.de ([212.227.17.8]:50511) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rrs37-0000W1-Ux for qemu-devel@nongnu.org; Mon, 30 Jan 2012 09:17:38 -0500 Date: Mon, 30 Jan 2012 15:17:36 +0100 (CET) From: Erik Rull Message-ID: <628842726.26312.1327933056168.JavaMail.open-xchange@email.1und1.de> In-Reply-To: <4F269FBE.9040307@siemens.com> References: <1354816477.730358.1327923250151.JavaMail.open-xchange@email.1und1.de> <4F268471.6040803@siemens.com> <1412799439.18464.1327929457713.JavaMail.open-xchange@email.1und1.de> <4F269FBE.9040307@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] git bisect results Reply-To: Erik Rull List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: "qemu-devel@nongnu.org" On January 30, 2012 at 2:48 PM Jan Kiszka wrote: > On 2012-01-30 14:17, Erik Rull wrote: > > > > > > > > On January 30, 2012 at 12:52 PM Jan Kiszka wrote: > > > >> On 2012-01-30 12:34, Erik Rull wrote: > >>> Hi Jan, > >>> > >>> I'm sorry, but this does not solve my issue. I applied the patch and > >>> crosschecked that the resulting file looks fine. > >>> > >>> The final function looks like: > >>> > >>> static void sdl_grab_start(void) > >>> { > >>> /* > >>> * If the application is not active, do not try to enter grab state. > > This > >>> * prevents 'SDL_WM_GrabInput(SDL_GRAB_ON)' from blocking all the > >>> * application (SDL bug). > >>> */ > >>> if (!(SDL_GetAppState() & SDL_APPINPUTFOCUS)) { > >>> return; > >>> } > >>> if (guest_cursor) { > >>> SDL_SetCursor(guest_sprite); > >>> if (!kbd_mouse_is_absolute() && !absolute_enabled) > >>> SDL_WarpMouse(guest_x, guest_y); > >>> } else > >>> sdl_hide_cursor(); > >>> SDL_WM_GrabInput(SDL_GRAB_ON); > >>> gui_grab = 1; > >>> sdl_update_caption(); > >>> } > >> > >> That makes no sense as gui_grab must be 1 now. Please retry your > >> previous instrumentation. > >> > >> Thanks, > >> Jan > >> > > > > You're right. So I added the instrumentation again. > > > > Still looks strange. > > > > So I added into the sdl_grab_start() a printf. > > Wow - a lot of output! > > This pointed me to all other sdl_grab_start() calls (and in additon to that > > all sdl_grab_end() calls). > > > > And here are the results of the qemu voting :-) > > > > I already assigned a usable name to the printf output that is directly one > > line above the corresponding sdl_grab_*() call, so you should be able to > > find this easily in your code as well. > > > > The huge number of recurring printf's are: > > > > sdl_grab_start() called from absolute_mouse_grab() > > sdl_grab_end() called from handle_activation() > > sdl_grab_start() called from absolute_mouse_grab() > > sdl_grab_end() called from handle_activation() > > sdl_grab_start() called from absolute_mouse_grab() > > sdl_grab_end() called from handle_activation() > > sdl_grab_start() called from absolute_mouse_grab() > > sdl_grab_end() called from handle_activation() > > sdl_grab_start() called from absolute_mouse_grab() > > sdl_grab_end() called from handle_activation() > > sdl_grab_start() called from absolute_mouse_grab() > > sdl_grab_end() called from handle_activation() > > sdl_grab_start() called from absolute_mouse_grab() > > sdl_grab_end() called from handle_activation() > > > > Any idea how to proceed? > > > > Maybe the first two if-statements in handle_activation() cause the problem? > > Because there the two given functions are called in sequence if both > > if-clauses are valid one after the other. Maybe the first one sets the > > state so that the second if is valid, too. Maybe a simple else if solves > > the issue? > > ev->active.gain makes both clauses mutually exclusive - unless someone > messes with the memory of the event object. > > > I'm not familiar with the variables that are checked here, so > > it's just a guess. > > So handle_activation() is called directly after absolute_mouse_grab(), > and the reported event contains > > state = SDL_APPINPUTFOCUS > gain = 0 > (please validate!) > > That would mean we are constantly losing the input focus again after > trying to gain it via SDL_WM_GrabInput. Weird. > > What's the call chain for absolute_mouse_grab()? > > Jan > > -- > Siemens AG, Corporate Technology, CT T DE IT 1 > Corporate Competence Center Embedded Linux Here the results: Handle Activation 0: at function start (before the first if) Handle Activation 1: between the first and the second if Handle Activation 2: after the second if The output is formatted like: printf("Handle Activation 0: %d %d %d %d\n",gui_grab,(ev->active.state == SDL_APPINPUTFOCUS),ev->active.gain,gui_fullscreen); Handle Activation 0: 0 1 1 0 Handle Activation 1: 0 1 1 0 absolute_mouse_grab() called from handle_activation() sdl_grab_start() called from absolute_mouse_grab() Handle Activation 2: 1 1 1 0 Handle Activation 0: 1 1 0 0 sdl_grab_end() called from handle_activation() Handle Activation 1: 0 1 0 0 Handle Activation 2: 0 1 0 0 Handle Activation 0: 0 1 1 0 Handle Activation 1: 0 1 1 0 absolute_mouse_grab() called from handle_activation() sdl_grab_start() called from absolute_mouse_grab() Handle Activation 2: 1 1 1 0 Handle Activation 0: 1 1 0 0 sdl_grab_end() called from handle_activation() Handle Activation 1: 0 1 0 0 Handle Activation 2: 0 1 0 0 Handle Activation 0: 0 1 1 0 Handle Activation 1: 0 1 1 0 absolute_mouse_grab() called from handle_activation() sdl_grab_start() called from absolute_mouse_grab() Handle Activation 2: 1 1 1 0 The gain seems to toggle between the successive calls of handle_activation... Next steps? Best regards, Erik