summary refs log tree commit diff stats
path: root/results/scraper/launchpad-without-comments/1777672
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-06-30 12:24:58 +0000
committerChristian Krinitsin <mail@krinitsin.com>2025-06-30 12:27:06 +0000
commit33606b41d35115f887ea688b1a16f2ff85bf2fe4 (patch)
tree406b2c7b19a087ba437c68f3dbf0b589fa1d6150 /results/scraper/launchpad-without-comments/1777672
parentadedf8771bc4de3113041ca21bd4d0d1c0014b6a (diff)
downloadqemu-analysis-33606b41d35115f887ea688b1a16f2ff85bf2fe4.tar.gz
qemu-analysis-33606b41d35115f887ea688b1a16f2ff85bf2fe4.zip
add launchpad bug reports without comments
Diffstat (limited to 'results/scraper/launchpad-without-comments/1777672')
-rw-r--r--results/scraper/launchpad-without-comments/177767267
1 files changed, 67 insertions, 0 deletions
diff --git a/results/scraper/launchpad-without-comments/1777672 b/results/scraper/launchpad-without-comments/1777672
new file mode 100644
index 000000000..aef19ba1b
--- /dev/null
+++ b/results/scraper/launchpad-without-comments/1777672
@@ -0,0 +1,67 @@
+QEMU raspi virtual/physical frame buffer not implemented
+
+I fully recognize that the error here could be mine, but the code is pretty simple and straightforward; When emulating a Raspberry PI 3 using aarch64 and allocating a virtual framebuffer larger than the physical frambuffer (for double-buffering purposes), the QEMU window shows the full size of the *virtual* framebuffer rather than the size of the *physical* framebuffer.
+
+You can replicate this with code such as:
+
+
+#define FBWIDTH 1024
+#define FBHEIGHT 768
+
+void lfb_init()
+{
+    uart_puts("Initializing Framebuffer\n");
+    mbox[0] = 35*4;
+    mbox[1] = MBOX_REQUEST;
+
+    mbox[2] = 0x48003;  //set phy wh
+    mbox[3] = 8;
+    mbox[4] = 8;
+    mbox[5] = FBWIDTH;         //FrameBufferInfo.width
+    mbox[6] = FBHEIGHT;          //FrameBufferInfo.height
+
+    mbox[7] = 0x48004;  //set virt wh
+    mbox[8] = 8;
+    mbox[9] = 8;
+    mbox[10] = FBWIDTH;        //FrameBufferInfo.virtual_width
+    mbox[11] = FBHEIGHT * 2;         //FrameBufferInfo.virtual_height
+    
+    mbox[12] = 0x48009; //set virt offset
+    mbox[13] = 8;
+    mbox[14] = 8;
+    mbox[15] = 0;           //FrameBufferInfo.x_offset
+    mbox[16] = 0;           //FrameBufferInfo.y.offset
+    
+    mbox[17] = 0x48005; //set depth
+    mbox[18] = 4;
+    mbox[19] = 4;
+    mbox[20] = 32;          //FrameBufferInfo.depth
+
+    mbox[21] = 0x48006; //set pixel order
+    mbox[22] = 4;
+    mbox[23] = 4;
+    mbox[24] = 1;           //RGB, not BGR preferably
+
+    mbox[25] = 0x40001; //get framebuffer, gets alignment on request
+    mbox[26] = 8;
+    mbox[27] = 8;
+    mbox[28] = 4096;        //FrameBufferInfo.pointer
+    mbox[29] = 0;           //FrameBufferInfo.size
+
+    mbox[30] = 0x40008; //get pitch
+    mbox[31] = 4;
+    mbox[32] = 4;
+    mbox[33] = 0;           //FrameBufferInfo.pitch
+
+    mbox[34] = MBOX_TAG_LAST;
+
+    if(mbox_call(MBOX_CH_PROP) && mbox[20]==32 && mbox[28]!=0) {
+        mbox[28]&=0x3FFFFFFF;
+        fbwidth=mbox[5];
+        fbheight=mbox[6];
+        pitch=mbox[33];
+        lfb=(void*)((unsigned long)mbox[28]);
+    }
+}
+
+I will assume, for the sake of this posting, that the reader understands the mailbox architecture and the appropriate address definitions for them.  The key point is that allocating a virtual buffer twice the height of the physical buffer results in QEMU improperly displaying a double-height window.
\ No newline at end of file