Hi, On Tue, Jul 14, 2020 at 8:31 AM Doug Anderson <diand...@chromium.org> wrote: > > > Hopefully BOE gets back to you soon, and there's no rush, I'm just an > > end user who is extremely appreciative of all the work everyone on the > > list and the kernel in general put in to make my machines usable. > > Just FYI that I got confirmation that the panel is truly 6 bpp but it > will do FRC dithering if given an 8 bpp input. That means that you > should be getting just as good picture quality (and possibly more > tunable) by using the dithering in the display pipeline and leaving > the panel as 6bpp. Thus I'm going to assume that's the route we'll go > down. If ever we find someone that wants to use this panel on a > display controller that can't do its own dithering then I guess we'll > have to figure out what to do then... > > In terms of the more optimal pixel clock for saving power, my proposal > is still being analyzed and I'll report back when I hear more. I'm > seeing if BOE can confirm that my proposal will work both for my panel > (the -n62 variant) and the one you have (the -n61 variant).
To close the loop here: we finally got back an official word that we shouldn't use my proposed timings that would have allowed us to move down to a 1.62 GHz pixel clock. Though they work most of the time, there are apparently some corner cases where they cause problems / flickering. :( While you could certainly use the timings on your own system if they happen to work for you, I don't think it'd be a good idea to switch the default over to them or anything. I'm told that hardware makers will take this type of thing into consideration for future hardware. -Doug _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
