Bug 832002 gets basic support ready, but we need one more gonk patch to turn this on. Once the patch is available, I need to confirm that our current kernels have the right support (they very much should).

-> dwilson to hook us up with the ics_chocolate-rebased qcom/display patch for this. I did a dumb rebase of the strawberry patch but it dint build.

My rebased ics_strawberry patch was actually correct, but I was missing a needed patch to kernel headers (patch 1). So here's the rebased patch, which builds now. Everything runs and works fine, but testing reveals our (really old! jeez) otoro kernel doesn't have the right patch applied E/copybit ( 105): copyBits failed (Operation not permitted) Will file a separate bug on getting an update there. Unagi should be fine.

jhford, same song, second verse here: can we get these into our otoro and unagi patch queues? Thanks!

(This is for landing directly to device/qcom/otoro, not for patch queue.)

(Note: all these patches can land at any time because they don't affect anything until the gecko hwc pref is flipped.)

We have a fork of libcopybit at https://github.com/mozilla-b2g/hardware_qcom_display. Device specific patch queues are not necessary for this.

When was that last rebased? Who's signed up to rebase it? We need to keep our eyes on the v1 prize and worry about cleanliness a bit later.

(In reply to Chris Jones [:cjones] [:warhammer] from comment #9) > When was that last rebased? Who's signed up to rebase it? > > We need to keep our eyes on the v1 prize and worry about cleanliness a bit > later. I dunno but this is what we've actually been using for a while now. Same with the kernel repo. Rebasing isn't a big deal if we base on the proper tag. Also git rebase is easy.

jhford enabled the appropriate patches required for hwc color layers on Buri/Leo in bug 862397.