New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 831623 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Make exo work with sw compositing

Project Member Reported by sky@chromium.org, Apr 11 2018

Issue description

Without this you can't test over remote desktop, which makes development hard for some of us. As we don't want this for actual devices we could DCHECK that we're not on a real machine (base::SysInfo::IsRunningOnChromeOS()).
 
Components: -UI>Shell Internals>Compositing>Software

Comment 2 by danakj@chromium.org, Apr 13 2018

Cc: marc...@chromium.org
This is probably a bit more work than its worth considering chromeos doesn't use software compositing.

It is possible to use gpu based compositing over remote desktop, using different drivers, cuz I did this before. I did a search and can't find instructions though, maybe marcheu can provide some and we can put them somewhere searchable, and link from the chromium graphics page.

Comment 3 by danakj@chromium.org, Apr 13 2018

Status: Available (was: Untriaged)
I don't think we want this for real devices. Just when base::SysInfo::IsRunningOnChromeOS() is false for Ash/Exo development purposes.

Making Exo work with SW compositing is not hard. We just need to produce SharedBitmaps from exo::Buffer instances instead of textures. I can provide more details for this if needed. I don't think it should take more than a day to implement by someone who is familiar with SW compositing in chrome. 

There's also the option of using llvmpipe instead of SW compositing with remote desktop. I've done that in the past when working on chromeos chrome and exo over remote desktop. Don't remember the exact details for how I made this work. I probably had to force mesa to use a llvmpipe using an environment variable.

Comment 5 by danakj@chromium.org, Apr 13 2018

The SharedBitmapIds and SharedMemory fds need to also be given to the CompositorFrameSink.

llvmpipe was what I was trying to refer to yeah! With that I found this thread where we figured out how to make it work at that time. go/llvmpipe-chromoting
Should I make an llvmpipe build for rodete and throw it in my www? Let me know if that'd help.
Yes, I think I might have just done a LD_PRELOAD when using llvmpipe. I don't remember it being hard to get working.

exo::Buffer::ProduceTransferableResource currently returns a texture backed TransferableResource. If we update that function to return a SharedBitmap backed TransferableResource instead, then the rest of exo will hopefully do the right thing when SW compositing is used.

Clients that use DMABufs will of course not work but that should be handled by not advertising dmabuf wayland protocol support when SW compositing is used. All standard linux wayland clients would still work as they don't use DMABufs.  

Sign in to add a comment