On Fri, Feb 17, 2017 at 02:42:26PM +0000, Lionel Landwerlin wrote:If you're seriously considering that, you might also want to bump struct drm_color_lut to use 32bits fields.
On 17/02/17 13:54, Brian Starkey wrote:So it's already using the sign+magnitude stuff. Which presumably
What's the verdict? We've got  which is about to become anotherIf we're talking fixed point reprsentation, ChromeOS is using this :
(driver) implementation - better to change before that merges than
after I guess.
On Wed, Feb 15, 2017 at 11:56:55AM +0000, Daniel Stone wrote:
On 15 February 2017 at 11:39, Ville Syrjälä
On Tue, Jan 31, 2017 at 06:46:39PM +0100, Daniel Vetter wrote:I don't know of any implementation using this; maybe closed Intel
On Tue, Jan 31, 2017 at 6:22 PM, Ville SyrjäläI have no idea. Anyone else?
Hmm. Two's complement is what I was thinking it is. Which shows thatThat sounds supremely backwards. I guess we can't fix this anymore?
I never managed to read the code in any detail. Definitely needs to
be documented properly.
Android stuff? Certainly GitHub showed no-one using it, and neither X
nor Weston/Mutter are using it yet.
means we can't change it to two's complement anymore :( Maybe we add a
CTM2 property ;)
Using sign+magnitude definitely looks rather inefficient since there's
a branch inside the loop. With two's complement you wouldn't need that
thing slowing you down.