Re: [PATCH 1/3] drm/i915: Select starting pipe bpp irrespective or the primary plane

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2015-05-04 5:34 GMT-03:00 Daniel Vetter <daniel@xxxxxxxx>:
> On Thu, Apr 30, 2015 at 10:43:39AM -0300, Paulo Zanoni wrote:
>> 2015-04-15 8:06 GMT-03:00 Ander Conselvan De Oliveira <conselvan2@xxxxxxxxx>:
>> > Reviewed-by: Ander Conselvan de Oliveira <conselvan2@xxxxxxxxx>
>> >
>> > On Fri, 2015-04-10 at 16:22 +0200, Daniel Vetter wrote:
>> >> Since universal planes the primary plane might not be around, and it's
>> >> kinda silly to restrict the pipe bpp to the primary plane if we might
>> >> end up displaying a 10bpc video overlay. And with atomic we might very
>> >> well enable a pipe without a primary plane. So just use the platform
>> >> max as a starting point and then restrict appropriately.
>> >>
>> >> Of course this is all still a bit moot as long as we artificially
>> >> compress everything to max 8bpc because we don't use the hi-bpc gamma
>> >> tables.
>> >>
>> >> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx>
>>
>> This commit makes the HDMI colors look very funny on my BDW machine. I
>> just boot it with HDMI (no eDP), and I get this:
>> http://people.freedesktop.org/~pzanoni/color-regression.jpg (the
>> original wallpaper only has gradients of blue). Although I like the
>> new wallpaper color scheme, I don't think most users will.
>>
>> Reverting this commit (and also "drm/i915: Drop unecessary fb
>> arguments from function signatures" in order to make things compile
>> again) fixes the problem for me.
>>
>> Since this is a major issue for me, I'd be happy to test patches.
>
> We dump pipe_bpp and dither settings into dmesg. Do you see any
> differences in there between working and broken kernel?

Just to document the discussion on IRC:

It seems the problem is happening because we're now trying 12bpc
instead of 8bpc, and 12bpc is broken for HDMI. In fact, 12bpc was
already broken before this patch, the problem is that this patch is
now trying to use it. It even generates a WARN, so this bug is
definitely something we can catch with automated systems somehow.

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch



-- 
Paulo Zanoni
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux