Giving this one to Mengqi so she can learn the fun of kernel development in a practical positive manner. Have fun.

The bug I see: the black cursor shows up in VM and moves like what we expect it to. The problem is with clicking: on click, the black cursor disappears (both in and out of VM window). Then have to press "ctrl+alt" to release mouse grab. 

bug behavior cont'd: we cannot see the cursor, but clicks work (by randomly moving the mouse and clicking, we can see the buttons responding). A quick workaround is add "-usbdevice tablet -show-cursor" when you start up the VM. This will show cursor and override the mouse. 

adding "-usbdevice tablet -show-cursor" to Qemu parameters is fine (ie the tablet emulation is absolute coordinates rather than relatives which is always better), I have some patches to update the qemu/kvm helpers in ChromeOS chroot, I might add these parameters at some point to avoid confusing the developers.
but is it clicking where you see the cursor ? 
If not (my own WM might also be not really Qemu friendly), we would need to root cause this.

The issue might not be related to the patches themselves, I had just opened this vague bug because the cursor was not functioning properly (on my wonky setup) and we need to investigate further.

Can we fix this problem properly? Working around it by enabling the cursor on the qemu side:
- doesn't test the actual cursor code, so VMs are less useful
- doesn't display the right cursor images, so you don't know if the cursor image is broken

I have went ahead and ran
gnawty(kernel 3.10)
amd64-generic(kernel 3.18)
amd64-generic(kernel 4.4)
in qemu kvm, and their (non-existent) cursor behavior was similar:
1. No additional command:
Cursor disappears after we click into the VM. If we move the mouse around and click, we actually can click and buttons respond. We just don’t know where the cursor is.
2. -show-cursor:
Default black cursor shows up after we click into the VM, but it is not where the real cursor is. We can move the cursor around and click, but where we click and where buttons respond on the screen are two different locations. We still don’t know where the cursor is.
3. -usbdevice tablet -show-cursor:
Default black cursor shows up after we click into the VM, and where we click and where buttons respond are the same location. These default black cursors will not change into other cursor icons. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c5b6fe3a910bd2367e82368c9d61e292976310d8

commit c5b6fe3a910bd2367e82368c9d61e292976310d8
Author: Zach Reizner <zachr@google.com>
Date: Tue Nov 15 02:19:25 2016

CHROMIUM: drm/cirrus: hardcode vram size

There is no reliable way of detecting actual VRAM size, which is
important in the case of cirrus because cursor data is always stored in
the last 16K of VRAM. Because qemu effectivaly hardcodes 4MB but reports
32MB, we hardcode 4MB in the cirrus driver to ensure the cursor works
properly.

TEST=drm_cursor_test
BUG= chromium:604922 

Change-Id: I0965f2403d7fdc159edd1462cd94dc95a29a9422
Reviewed-on: https://chromium-review.googlesource.com/411344
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

[modify] https://crrev.com/c5b6fe3a910bd2367e82368c9d61e292976310d8/drivers/gpu/drm/cirrus/cirrus_main.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c5b6fe3a910bd2367e82368c9d61e292976310d8

commit c5b6fe3a910bd2367e82368c9d61e292976310d8
Author: Zach Reizner <zachr@google.com>
Date: Tue Nov 15 02:19:25 2016

CHROMIUM: drm/cirrus: hardcode vram size

There is no reliable way of detecting actual VRAM size, which is
important in the case of cirrus because cursor data is always stored in
the last 16K of VRAM. Because qemu effectivaly hardcodes 4MB but reports
32MB, we hardcode 4MB in the cirrus driver to ensure the cursor works
properly.

TEST=drm_cursor_test
BUG= chromium:604922 

Change-Id: I0965f2403d7fdc159edd1462cd94dc95a29a9422
Reviewed-on: https://chromium-review.googlesource.com/411344
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>

[modify] https://crrev.com/c5b6fe3a910bd2367e82368c9d61e292976310d8/drivers/gpu/drm/cirrus/cirrus_main.c

Zach can you take a look?

So I tried this on a brand new samus qemu build and all I got was the cursor. UI fails to render with a lot of messages like this:

[3309:3309:0515/103834.685795:ERROR:gles2_cmd_decoder.cc(15622)] Context lost because SwapBuffers failed.
[3309:3309:0515/103834.685906:ERROR:gles2_cmd_decoder.cc(5326)] Error: 5 for Command kPostSubBufferCHROMIUM
[3309:3309:0515/103834.710364:ERROR:gles2_cmd_decoder.cc(4287)]   GLES2DecoderImpl: Trying to make lost context current.
[3309:3309:0515/103834.758425:ERROR:gles2_cmd_decoder.cc(15622)] Context lost because SwapBuffers failed.
[3309:3309:0515/103834.758508:ERROR:gles2_cmd_decoder.cc(5326)] Error: 5 for Command kPostSubBufferCHROMIUM
[3309:3309:0515/103834.781863:ERROR:gles2_cmd_decoder.cc(4287)]   GLES2DecoderImpl: Trying to make lost context current.

null_platform_test also fails with:
ERROR:bs_egl_setup():egl.c:139:EGL_KHR_fence_sync and EGL_KHR_wait_sync extension not supported
ERROR:main():null_platform_test.c:136:failed to setup egl context

Which I suspect is related to https://chromium-review.googlesource.com/c/478773/.

Zach I just tested with amd64-generic, and there is no Chrome display and no Chrome cursor now. Can you take a look?

Sure. I'll spin up another image and see if I can repro it this time. Which qemu version were you using exactly?

what's installed on my machine:

$ kvm --version
QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.34), Copyright (c) 2003-2008 Fabrice Bellard

Maybe some of the confusion is from us using differing QEMU version. I've been using a custome built version:

$ x86_64-softmmu/qemu-system-x86_64 --version
QEMU emulator version 2.5.50, Copyright (c) 2003-2008 Fabrice Bellard

And the chroot has it's out:
chroot$ qemu-system-x86_64 --version
QEMU emulator version 2.6.0, Copyright (c) 2003-2008 Fabrice Bellard

Which one do we care about supporting?

The one that everyone has on their devices I guess? But I'm not sure which one that is :) Are we even sure that's where the issue comes from?

It doesn't really matter. What I really want to know (which you answered) was precisely which qemu I should test against.

FWIW we certainly don't care about the one inside the chroot, because it can't use kvm and therefore is unbearably slow. I am curious what our builders are running.

FWIW here is the version that is running on our builders:

$ kvm --version
QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.34), Copyright (c) 2003-2008 Fabrice Bellard

So it would seem that with the latest Chrome OS source (M61, 9627) and a recent QEMU (2.5.50) both the display and the cursor work perfectly. A slightly older Chrome OS (M60) will have a blank display. A QEMU from the chroot or Goobuntu (2.0.0) will have no cursor ever. The problem with qemu is that the callback for cirrus to draw the cursor is predicated on if the display surface is shared:

hw/display/vga.c-            if (!(is_buffer_shared(surface))) {
hw/display/vga.c-                vga_draw_line(s, d, s->vram_ptr + addr, width);
hw/display/vga.c:                if (s->cursor_draw_line)
hw/display/vga.c:                    s->cursor_draw_line(s, d, y);
hw/display/vga.c-            }

It seems that a shared surface is incompatible with the cursor drawing routines. Newer QEMU versions have a mechanism for forcing surface sharing off:

hw/display/cirrus_vga.c-    case 0x12:			// Graphics Cursor Attribute
hw/display/cirrus_vga.c-	s->vga.sr[0x12] = val;
hw/display/cirrus_vga.c:        s->vga.force_shadow = !!(val & CIRRUS_CURSOR_SHOW);

In this snippet of code, a shadow surface for the cursor drawing routine to operate on is forced on when the cursor attribute register (known as sr12) is told to enable the cursor by the guest.

My recommendation is to upgrade the QEMU used by the builders and users who want to actually use Chrome OS under QEMU.

> FWIW we certainly don't care about the one inside the chroot,
>  because it can't use kvm and therefore is unbearably slow. 
> I am curious what our builders are running.
>
> FWIW here is the version that is running on our builders:
> 
> $ kvm --version
> QEMU emulator version 2.0.0 (Debian 2.0.0+dfsg-2ubuntu1.34), Copyright (c) 2003-2008 Fabrice Bellard

FWIW this is no longer true for the last 8 months, Nicolas completed the work started by vapier and I to use the QEMU from the chroot for the testing :
https://chromium-review.googlesource.com/389152
The previous situation has *random* old KVM versions running actually preventing both reproducible results/failures and using new features.

KVM acceleration does work with the chroot QEMU, but it's not the deprecated kvm-tools command-line, so you have to pass the '--enable-kvm' flag to qemu-system-x86_64 (or the more modern: --machine accel=kvm). It has been working for some time, actually I fixed the helper one year ago for people using it :
https://chromium-review.googlesource.com/c/339839/

> My recommendation is to upgrade the QEMU used by the builders and users who want to actually use Chrome OS under QEMU.

All the builders should be using the chroot QEMU v2.6.0, actually I have added the magic trace "QEMU/KVM binary: ${KVM_BINARY} version: $(get_kvm_version)" in the previous CL to be able to verify this :
https://chromium-review.googlesource.com/c/339839/5/lib/cros_vm_lib.sh#144 
Looking a random recent amd64 build, this seems true:

INFO    : QEMU binary: /b/cbuild/chroot/usr/bin/qemu-system-x86_64
INFO    : QEMU version: QEMU emulator version 2.6.0, Copyright (c) 2003-2008 Fabrice Bellard

https://uberchromegw.corp.google.com/i/chromiumos/builders/amd64-generic-full/builds/18784/steps/VMTest%20%28attempt%201%29/logs/stdio


The downside of the chroot QEMU is that it is lacking SDL support for display (since we have no host graphics library) but the VNC support should be working ok.
(and it can be use outside the chroot as per https://chromium-review.googlesource.com/c/351861)

See also issuetracker.google.com/37988983

The mouse cursor is not present with even more recent qemu 2.9.0, at least when using virtio-gpu and GTK. cirrus looks OK iirc. But it would be good to fix the virtio case otherwise the screen resolution is limited to 800x600 which can't be used for Android apps (many are larger than that...) and even Chrome OS doesn't really like it, I think the oobe screens need more pixels than that.

I'm going to mark this bug fixed as this bug report originally related to cirrus+qemu on builders and users in the chroot. There is the bug linked in comment #22 related to the ongoing virtio+qemu use case.