On Tue, 2020-03-10 at 14:07 -0400, Lyude Paul wrote:
> Hi! These are the backported versions of the eDP backlight fixes for
> i915 that Lenovo asked me to try getting into the Fedora kernel in
> time
> for beta. Note that these are pending upstream in intel's
> drm-intel-next-queued tree, and will
The X1 Extreme is one of the systems that lies about which backlight
interface that it uses in its VBIOS as PWM backlight controls don't work
at all on this machine. It's possible that this panel could be one of
the infamous ones that can switch between PWM mode and DPCD backlight
control mode, but
Max backlight value for the panel was being calculated using byte
count i.e. 0x if 2 bytes are supported for backlight brightness
and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT
determines the number of active control bits used for the brightness
setting. Thus, even if the panel
Hi! These are the backported versions of the eDP backlight fixes for
i915 that Lenovo asked me to try getting into the Fedora kernel in time
for beta. Note that these are pending upstream in intel's
drm-intel-next-queued tree, and will make it into the kernel come next
merge window.
Turns out we actually already have some companies, such as Lenovo,
shipping machines with AMOLED screens that don't allow controlling the
backlight through the usual PWM interface and only allow controlling it
through the standard EDP DPCD interface. One example of one of these
laptops is the X1 Ex
The whole point of using OUIs is so that we can recognize certain
devices and potentially apply quirks for them. Normally this should work
quite well, but there appears to be quite a number of laptop panels out
there that will fill the OUI but not the device ID. As such, for devices
like this I can
According to Dell, trying to match their panels via OUI is not reliable
enough and we've been told that we should check against the EDID
instead. As well, Dell seems to have some panels that are actually
intended to switch between using PWM for backlight controls and DPCD for
backlight controls dep
For eDP panels, it appears it's expected that so long as the panel is in
DPCD control mode that the brightness value is never set to 0. Instead,
if the desired effect is to set the panel's backlight to 0 we're
expected to simply turn off the backlight through the
DP_EDP_DISPLAY_CONTROL_REGISTER.
W
Currently we always determine the initial panel brightness level by
simply reading the value from DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB. This
seems wrong though, because if the panel is not currently in DPCD
control mode there's not really any reason why there would be any
brightness value programmed
On Tue, Feb 25, 2020 at 12:48:08PM -0700, stan wrote:
> On Tue, 25 Feb 2020 14:24:10 -0500
> Neil Horman wrote:
>
> > On Tue, Feb 25, 2020 at 11:58:56AM -0700, stan wrote:
>
> > > Doesn't the elimination of the shadow pool, and the removal of
> > > push_to_pool end the ability to push entropy?
Dne 03. 03. 20 v 18:45 Peter Robinson napsal(a):
On Tue, Mar 3, 2020 at 4:17 PM Hans de Goede wrote:
Hi,
On 3/3/20 4:23 PM, Jeremy Cline wrote:
On Tue, 2020-03-03 at 16:09 +0100, Hans de Goede wrote:
Hi,
On 3/3/20 3:29 PM, Peter Robinson wrote:
Yes you are right, it should probably be som
11 matches
Mail list logo
