From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37839) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tv8In-0003p0-KX for qemu-devel@nongnu.org; Tue, 15 Jan 2013 10:19:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tv8If-0004Pk-7z for qemu-devel@nongnu.org; Tue, 15 Jan 2013 10:19:49 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29306) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tv8Ie-0004PY-Ul for qemu-devel@nongnu.org; Tue, 15 Jan 2013 10:19:41 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0FFJeC7023348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 15 Jan 2013 10:19:40 -0500 Message-ID: <50F5738A.7080904@redhat.com> Date: Tue, 15 Jan 2013 16:19:38 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <50C86E8B.5020705@redhat.com> <1355398603-22186-1-git-send-email-alevy@redhat.com> <1355398603-22186-2-git-send-email-alevy@redhat.com> <50C9C49C.10400@redhat.com> <20121223203138.GB7485@garlic> <20130115133423.GH21732@garlic.redhat.com> In-Reply-To: <20130115133423.GH21732@garlic.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] qxl: change rom so that 4096 < size < 8192 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alon Levy Cc: qemu-devel@nongnu.org Hi, >>>> #define QXL_MODE_EX(x_res, y_res) \ >>>> QXL_MODE_16_32(x_res, y_res, 0), \ >>>> - QXL_MODE_16_32(y_res, x_res, 1), \ >>>> - QXL_MODE_16_32(x_res, y_res, 2), \ >>>> - QXL_MODE_16_32(y_res, x_res, 3) >>>> + QXL_MODE_16_32(x_res, y_res, 1) >>> >>> Why do you leave orientation = 1 in? Just to keep the size above 4K? >>> Shouldn't we just hardcode the rom size to 8k instead? Then assert that >>> everything fits into 8k? Or even better add a compile time check? >>> >>> While being at it it might be a good idea to move the mode table to a >>> fixed, large enougth offset (say 0x4096), so it doesn't move around >>> again in case we extend QXLRom one more time. >> >> This solution is breaking backward compatibility like Yonit pointed >> out. The fact that I can't produce a user that would break because of >> this doesn't prove there is no such user. I suggest we go back to the >> original patch I posted, breaking it into two like you requested. What >> do you say? > > Ping? I think I've answered this one already. It is still not clear to me how this orientation thing is supposed to work and what exactly we loose when we drop those modes from the list. I havn't found a way to activate a portrait mode (orientation == 1,3) in the windows guest. Orientation isn't used anywhere in qxl (other than rom initialization), so in case the guest activates a mode with orientation != 0 spice server (and thus spice client) isn't notified about that. So spice client wouldn't rotate the display according to the guests orientation. Hmm? And finally only prehistorical 0.4.x spice guests (which use SET_MODE) can pick modes with orientation != 0. The QXLSurfaceCreate struct has no orientation field ... cheers, Gerd