From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E090421245111 for ; Tue, 12 Jun 2018 05:54:00 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0F9A277884 for ; Tue, 12 Jun 2018 12:54:00 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-239.rdu2.redhat.com [10.10.120.239]) by smtp.corp.redhat.com (Postfix) with ESMTP id 61B5E7C42; Tue, 12 Jun 2018 12:53:57 +0000 (UTC) To: Gerd Hoffmann Cc: edk2-devel@lists.01.org References: <20180608113942.17009-1-kraxel@redhat.com> <20180612092140.quczvb74jcmpxr3d@sirius.home.kraxel.org> From: Laszlo Ersek Message-ID: <8d7c55c4-bf6f-0a31-bcf7-ba030203c51d@redhat.com> Date: Tue, 12 Jun 2018 14:53:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180612092140.quczvb74jcmpxr3d@sirius.home.kraxel.org> X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Tue, 12 Jun 2018 12:54:00 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Tue, 12 Jun 2018 12:54:00 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [PATCH 0/4] Add QemuRamfbDxe driver X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 12:54:01 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/12/18 11:21, Gerd Hoffmann wrote: > Hi, > >> - What happens in the UEFI shell if you do recursive connect/disconnect >> cycles for all handles in the system? (Preferably initiated from serial.) > > Seems to work fine (tried "disconnect -a" and "connect"). Cool. > >> - What happens if you locate the parent handle (with the VenHw node) >> and/or the child handle (with the GOP on it), and try to disconnect them? > > How can I do that? Run "dh -d -v -p GraphicsOutput". The listing will include all handles (represented by hex identifiers) that carry a GOP. Each handle will also have its device path protocol instance displayed, in textual representation, so if there are multiple GOPs, you'll be able to locate the one produced by QemuRamfbDxe. The listing should also reference the parent controller handle. Knowing the hex identifiers for parent and child, experiment with the "disconnect" command. (See "help disconnect" for syntax.) >> - Have you tested mode changes with the MODE command? > > Yes, works. Nice! Thansk Laszlo