From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YC8Su-0001EG-N4 for qemu-devel@nongnu.org; Fri, 16 Jan 2015 10:05:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YC8Sr-0006RP-H2 for qemu-devel@nongnu.org; Fri, 16 Jan 2015 10:05:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48268) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YC8Sr-0006RH-7y for qemu-devel@nongnu.org; Fri, 16 Jan 2015 10:05:33 -0500 Message-ID: <54B928B8.6080006@redhat.com> Date: Fri, 16 Jan 2015 10:05:28 -0500 From: Max Reitz MIME-Version: 1.0 References: <1421066126-25737-1-git-send-email-kraxel@redhat.com> <1421066126-25737-3-git-send-email-kraxel@redhat.com> <54B8270A.8050007@redhat.com> <1421400077.21318.31.camel@nilsson.home.kraxel.org> In-Reply-To: <1421400077.21318.31.camel@nilsson.home.kraxel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/4] console: add opengl rendering helper functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org, Anthony Liguori On 2015-01-16 at 04:21, Gerd Hoffmann wrote: > Hi, > >>> +bool console_gl_check_format(DisplayChangeListener *dcl, >>> + pixman_format_code_t format) >>> +{ >>> + switch (format) { >>> + case PIXMAN_x8r8g8b8: >>> + case PIXMAN_a8r8g8b8: >>> + case PIXMAN_r5g6b5: >>> + return true; >>> + default: >>> + return false; >>> + } >>> +} >> What is this function supposed to be used for? > Inflight change, there is a patch series on the list adding a > check_format callback to DisplayChangeListenerOps, for format > negotiation. OK. >>> + >>> +void surface_gl_create_texture(DisplaySurface *surface) >>> +{ >>> + switch (surface->format) { >>> + case PIXMAN_x8r8g8b8: >>> + case PIXMAN_a8r8g8b8: >>> + surface->glformat =3D GL_BGRA; >> Why does the format code seem to imply ARGB order but you're using the >> exact opposite? I could imagine something like endianness being the >> reason, but you're using RGB below where the format code says exactly = that. > endianness indeed. pixman formats are native endian, so this actually > is bgra ordering in memory. While looking at it: I guess GL_BGRA is > fixed byte ordering? Yes, I think so. > So this probably needs fixing to work correctly on > bigendian machines ... Probably, right. >> Discarding the alpha channel is intentional, I suppose? > Yes. > >>> + surface_width(surface), >>> + surface_height(surface), >>> + 0, surface->glformat, surface->gltype, >>> + surface_data(surface)); >> Is surface_stride(surface) specified to be surface_width(surface) * >> bytes_per_pixel (I don't know pixman so I don't know)? > Usually this is the case, but there can be exceptions. Hmm, can I > explicitly pass the stride? The internet=E2=84=A2 tells me about glPixelStorei(GL_UNPACK_ROW_LENGTH,=20 $pixels_per_row) and glPixelStorei(GL_UNPACK_ALIGNMENT,=20 $row_alignment_in_bytes) (which need to be called before using=20 glTexImage2D() or glTexSubImage2D()). You may want to use it for=20 surface_gl_update_texture(), too (if that isn't too much work). Max