On 06/18/2010 08:32 AM, Gerd Hoffmann wrote:
>Hi,
>
>> For some reason, the display is extremely slow when using vnc and
>> fbdev at the same time.
>
> Gotcha. Didn't notice, but it probably depends on the hardware. Very
> likely the reason is that graphic cards usually are optimized for w
Hi,
For some reason, the display is extremely slow when using vnc and
fbdev at the same time.
Gotcha. Didn't notice, but it probably depends on the hardware. Very
likely the reason is that graphic cards usually are optimized for write
access and reads might be slow as hell. vnc must re
On 06/17/2010 03:29 PM, Julian Pidancet wrote:
>
> Hi,
>
> Thanks for spotting these errors. Here is a respin of my patch to address you
> concerns.
> (The munmap call is included).
>
> Cheers,
>
> Julian
>
Oh, I actually tested the last patch only with the -nographic switch. There's
still
On 06/17/2010 11:43 AM, Gerd Hoffmann wrote:
>Hi,
>
> You register the display allocator, but don't unregister in
> fbdev_display_uninit().
>
> You are just lucky that fbdev_cleanup() forgets to unmap the framebuffer.
>
> Apply the attached fix, start qemu with vnc, then do "change fbdev on
Hi,
+static void fbdev_free_displaysurface(DisplaySurface *surface)
+{
+if (surface == NULL)
+return;
+
+if (surface->flags& QEMU_ALLOCATED_FLAG) {
+qemu_free(surface->data);
+}
+
+surface->data = NULL;
This is pretty pointless ...
+qemu_free(surface);
On 06/16/2010 01:44 PM, Stefano Stabellini wrote:
>
> the patch still doesn't use the display allocator interface, but it
> shouldn't be difficult to implement support for it on top of this patch,
> so it is fine by me.
>
This patch adds display allocator support in the fbdev driver.
This way we
On Tue, 15 Jun 2010, Gerd Hoffmann wrote:
> Display works, requires truecolor framebuffer with 16 or 32 bpp on the
> host. 32bpp is recommended. The framebuffer is used as-is, qemu
> doesn't try to switch modes. With LCD displays mode switching is pretty
> pointless IMHO, also it wouldn't work a
