I confirmed the problem is because the viz::CopyOutputRequest doesn't work with mus.

FYI, In wayland the cursor is a surface. In exo, every surface is an aura::Window. To use hardware cursor, exo submits a frame with the cursor surface and uses CopyOutputRequest to get composited result of the frame as a SkBitmap, and then convert it to a ui::PlatformCursor.

fsamuel@, could you please take a look? Thanks.

I think this will be fixed by the work miu@ is doing. Doing I have that right

Not sure: I've never looked at ARC++ before, so I don't know about the graphics paths or UI resource issues involved here.

To fix this issue we need support CopyOutputRequest in mus and mash. See Pointer::CaptureCursor() [1] for the detail.

[1] https://cs.chromium.org/chromium/src/components/exo/pointer.cc?sq=package:chromium&dr&q=CopyOutputRequest+file:%5Esrc/components/exo/+package:%5Echromium$&l=350

miu@ Do we have a plan to support CopyOutputRequest in mus world? 

We want this, but there is no design yet, AFAIK. Actually, it should be trivial...just some minor plumbing.

My priority is to get tab/desktop capture working first. From those efforts, it's likely one-off snapshots will be easy to get running.

Fyi, I landed some cursor fixes in exo that that most likely leaves the cursor as the default cursor for exo windows on Mus.

Peng, could you reevaluate this and see if it's still an issue?

With reveman's change, we will have a cursor for ARC++ on mus, but it is not the cursor set by ARC++. 

That's an improvement:)

We have a workaround for this issue, so it doesn't block mushrome anymore.

Deprecating label Proj-Mustash-Mus-WS in favor of Components.

CopyOutputRequests do work with mus now (for about a month or two now). Is this bug still a problem? Re-assigning back to original requestor to see if the problem is resolved and we should WontFix...

--mus has been nuked, so I don't think this is an issue anymore.