On Wed, 2020-09-30 at 16:25 -0400, Lyude Paul wrote:
> On Tue, 2020-09-29 at 13:32 -0600, Kevin Chowski wrote:
> > Thank you for the reply. And in regards to digging into it further,
> > thanks for requesting that I do some more due diligence here :)
> >
> > Also if you did get around to it, thank
On Tue, 2020-09-29 at 13:32 -0600, Kevin Chowski wrote:
> Thank you for the reply. And in regards to digging into it further,
> thanks for requesting that I do some more due diligence here :)
>
> Also if you did get around to it, thanks for double-checking with
> Bill! Let me know if you'd like me
Thank you for the reply. And in regards to digging into it further,
thanks for requesting that I do some more due diligence here :)
Also if you did get around to it, thanks for double-checking with
Bill! Let me know if you'd like me to reach out instead, or if
anything else needs to be done in thi
On Thu, 2020-09-24 at 17:46 -0600, Kevin Chowski wrote:
> cc back a few others who were unintentionally dropped from the thread
> earlier.
>
> Someone (at Google) helped me dig into this a little more and they
> found a document titled "eDP Backlight Brightness bit alignment" sent
> out for review
cc back a few others who were unintentionally dropped from the thread earlier.
Someone (at Google) helped me dig into this a little more and they
found a document titled "eDP Backlight Brightness bit alignment" sent
out for review in January 2017. I registered for a new account (google
is a member
Hi! Since I got dropped from the thread, many responses inline
On Tue, 2020-09-22 at 12:58 -0700, Puthikorn Voravootivat wrote:
> +Lyude
> I notice that Lyude email was somehow dropped from the thread.
> Lyude was the person who submitted the patch for Thinkpad and should
> know the OUI of the pan
+Lyude
I notice that Lyude email was somehow dropped from the thread.
Lyude was the person who submitted the patch for Thinkpad and should
know the OUI of the panel.
On Tue, Sep 22, 2020 at 11:47 AM Kevin Chowski wrote:
>
> Alrighty, I'll take everyone else's silence as tacit approval of
> Ville'
Alrighty, I'll take everyone else's silence as tacit approval of
Ville's opinions. (I didn't receive any email bounces this time, so I
think my issue was transient.) I will start on inverting the quirk and
making the most-significant-alignment matter for these registers by
default.
Who can help me
I'll defer to Ville & Lyude.
I dug up more on the bug report and found that both Thinkpad and
Galaxy Chromebook use the same Samsung OLED.
So my 2 vs 1 argument is actually not valid.
On Fri, Sep 18, 2020 at 10:59 AM Kevin Chowski wrote:
>
> Apologies once again, some of my emails were bouncing
Apologies once again, some of my emails were bouncing for some
addresses yesterday. Hopefully it was a temporary condition; I'll
continue trying to dig into it on my end if it happens again for this
email.
Since there's evidence that some models want lsb and some (well, at
least one) want msb, my
On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> > Galaxy Chromebo
On Thu, 2020-09-17 at 11:31 -0600, Kevin Chowski wrote:
> Thanks very much for the quick reply, Lyude!
>
> I'm happy to make the requested changes, but I wanted to clarify before
> falling down the wrong hole: are you suggesting that I move
> the intel_dp_aux_set_backlight/intel_dp_aux_get_backlig
On Thu, 2020-09-17 at 21:25 +0300, Ville Syrjälä wrote:
> On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> > Galaxy Chromebook. So
On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> The Lyude fde7266fb2f6 change is actually based on Chromium change
> (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> Galaxy Chromebook. So currently we have 2 examples that use LSB
> interpretation and 1
The Lyude fde7266fb2f6 change is actually based on Chromium change
(https://crrev.com/c/1650325) that fixes the brightness for Samsung
Galaxy Chromebook. So currently we have 2 examples that use LSB
interpretation and 1 that use MSB.
On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski wrote:
>
> Apol
Apologies for being too vague. To be as precise I can be, here is the
specific code delta I tested: https://crrev.com/c/2406616 . To answer
your other question, the code I tested against is indeed including the
fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
message): our current top
(resending as plain-text, my last mail was rejected by lots of
addresses for some reason)
Thanks very much for the quick reply, Lyude!
I'm happy to make the requested changes, but I wanted to clarify
before falling down the wrong hole: are you suggesting that I move the
intel_dp_aux_set_backlight
Thanks very much for the quick reply, Lyude!
I'm happy to make the requested changes, but I wanted to clarify before
falling down the wrong hole: are you suggesting that I move
the intel_dp_aux_set_backlight/intel_dp_aux_get_backlight routines to
the drm_dp_helper.c file?
On Thu, Sep 17, 2020 at
On Thu, 17 Sep 2020, Kevin Chowski wrote:
> We have observed that Google Pixelbook's backlight hardware is
> interpretting these backlight bits from the most-significant side of the
> 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> assumes the peripheral cares about the le
On Thu, Sep 17, 2020 at 11:09:06AM -0600, Kevin Chowski wrote:
> We have observed that Google Pixelbook's backlight hardware is
> interpretting these backlight bits from the most-significant side of the
> 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> assumes the periphera
Just an FYI, my plan for some of this eDP backlight code is to move as much of
it into helpers as possible since we need to implement the same interface in
nouveau. We probably can figure out some other solution for handling this quirk
if this isn't possible, but could we maybe use the panel's OUI
We have observed that Google Pixelbook's backlight hardware is
interpretting these backlight bits from the most-significant side of the
16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
assumes the peripheral cares about the least-significant bits.
Testing was done from within
22 matches
Mail list logo