Now that the drm helper sets the backlight using luminance
too we can use that. Remove the obselete function.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_dp_aux_backlight.c | 34 ++-
1 file changed, 3 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i9
Now that drm_edp_backlight init has been to be able to setup
brightness manipulation via luminance we can just use that.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_dp_aux_backlight.c | 100 +-
1 file changed, 49 insertions(+), 51 deletions(-)
diff --git a/driver
Use drm dp helper to enable backlight now that it has been modified
to set PANEL_LUMINANCE_CONTROL_ENABLE bit based on if capability
supports it and the driver wants it. Remove the dead code.
Signed-off-by: Suraj Kandpal
---
.../gpu/drm/i915/display/intel_dp_aux_backlight.c | 14 --
Now that drm_edp_backlight init has been to be able to setup
brightness manipulation via luminance we can just use that.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_dp_aux_backlight.c | 100 +-
1 file changed, 49 insertions(+), 51 deletions(-)
diff --git a/driver
Now that the drm helper sets the backlight using luminance
too we can use that. Remove the obselete function.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_dp_aux_backlight.c | 34 ++-
1 file changed, 3 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i9
Use drm dp helper to enable backlight now that it has been modified
to set PANEL_LUMINANCE_CONTROL_ENABLE bit based on if capability
supports it and the driver wants it. Remove the dead code.
Signed-off-by: Suraj Kandpal
---
.../gpu/drm/i915/display/intel_dp_aux_backlight.c | 14 --
According to our internal spec we need to now check if both
panel luminance and smooth brightness are available in panel for
us to be able to change brightness using luminance value.
--v2
-Add Fixes tag [Ankit]
Fixes: 64481497924d ("drm/i915/backlight: Check Luminance based brightness
co
Now that the drm helper sets the backlight using luminance
too we can use that. Remove the obselete function.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_dp_aux_backlight.c | 34 ++-
1 file changed, 3 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i9
Now that drm_edp_backlight init has been to be able to setup
brightness manipulation via luminance we can just use that.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_dp_aux_backlight.c | 100 +-
1 file changed, 49 insertions(+), 51 deletions(-)
diff --git a/driver
Use drm dp helper to enable backlight now that it has been modified
to set PANEL_LUMINANCE_CONTROL_ENABLE bit based on if capability
supports it and the driver wants it. Remove the dead code.
Signed-off-by: Suraj Kandpal
---
.../gpu/drm/i915/display/intel_dp_aux_backlight.c | 14 --
According to our internal spec we need to now check if both
panel luminance and smooth brightness are available in panel for
us to be able to change brightness using luminance value.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 3 ++-
1 file changed, 2
On 4/8/2025 10:31 AM, Suraj Kandpal wrote:
According to our internal spec we need to now check if both
panel luminance and smooth brightness are available in panel for
us to be able to change brightness using luminance value.
Since DP_EDP_SMOOTH_BRIGHTNESS_CAPABLE is introduced in eDP2.0 and
On 4/10/2025 11:11 AM, Nautiyal, Ankit K wrote:
On 4/8/2025 10:31 AM, Suraj Kandpal wrote:
According to our internal spec we need to now check if both
panel luminance and smooth brightness are available in panel for
us to be able to change brightness using luminance value.
Since DP_EDP_SMOO
On 08-04-2025 10:31, Suraj Kandpal wrote:
According to our internal spec we need to now check if both
panel luminance and smooth brightness are available in panel for
us to be able to change brightness using luminance value.
Signed-off-by: Suraj Kandpal
---
Reviewed-by: Arun R Murthy
Thanks
> Check if we are capable of controlling brightness via luminance which is
> dependent on PANEL_LUMINANCE_CONTROL_CAPABLE bit being set on
> EDP_GENERAL_CAPABILITY_2 register.
>
> --v2
> -Prefer using luminance rather than nits [Jani] -Fix commit message
>
> --v3
> -Fix the bit name used in commi
> eDP is supposed to use VESA interface when using revision 1.5 and above, use
> Intel interface for backlight control otherwise. Add check to use correct
> interface.
>
> Signed-off-by: Suraj Kandpal
> Tested-by: Ben Kao
> ---
Reviewed-by: Arun R Murthy
Thanks and Regards,
Arun R Murthy
-
eDP is supposed to use VESA interface when using revision 1.5 and above,
use Intel interface for backlight control otherwise. Add check to
use correct interface.
Signed-off-by: Suraj Kandpal
Tested-by: Ben Kao
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 8 +++-
1 file change
Create a function that fills in the value for
PANEL_TARGET_LUMINANCE_VALUE which helps in changing the luminance in
nits using VESA interface.
--v2
-Prefer using luminance over nits [Jani]
Signed-off-by: Suraj Kandpal
Tested-by: Ben Kao
Reviewed-by: Arun R Murthy
---
.../drm/i915/display/inte
Enable nits based luminance by writing the PANEL_LUMINANCE_CONTROL
bit and set the correct register to change brightness.
Signed-off-by: Suraj Kandpal
Tested-by: Ben Kao
Reviewed-by: Arun R Murthy
---
.../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 +++
1 file changed, 15 in
Check if we are capable of controlling brightness via luminance
which is dependent on PANEL_LUMINANCE_CONTROL_CAPABLE bit being set
on EDP_GENERAL_CAPABILITY_2 register.
--v2
-Prefer using luminance rather than nits [Jani]
-Fix commit message
--v3
-Fix the bit name used in commit message [Arun]
-
Modify vesa_get_brightness function to take into account
luminance_control_support and based on that read the appropriate
register and return the value.
--v2
-Changes since we now use luminance instead of nits
Signed-off-by: Suraj Kandpal
Tested-by: Ben Kao
Reviewed-by: Arun R Murthy
---
.../
Modify backlight setup function for VESA interface to take into
account the nits based luminance.
--v2
-Prefer using luminance over nits [Jani]
Signed-off-by: Suraj Kandpal
Tested-by: Ben Kao
Reviewed-by: Arun R Murthy
---
.../drm/i915/display/intel_dp_aux_backlight.c | 99 +++
> Enable nits based luminance by writing the PANEL_LUMINANCE_CONTROL bit
> and set the correct register to change brightness.
>
> Signed-off-by: Suraj Kandpal
> Tested-by: Ben Kao
> ---
Reviewed-by; Arun R Murthy
Thanks and Regards,
Arun R Murthy
---
> .../gpu/drm/i915/display
> > Create a function that fills in the value for
> > PANEL_TARGET_LUMINANCE_VALUE which helps in changing the luminance
> in nits using VESA interface.
> >
> > --v2
> > -Prefer using luminance over nits [Jani]
> >
> > Signed-off-by: Suraj Kandpal
> > Tested-by: Ben Kao
> > ---
> Reviewed-by: Aru
> Modify backlight setup function for VESA interface to take into account the
> nits
> based luminance.
>
> --v2
> -Prefer using luminance over nits [Jani]
>
> Signed-off-by: Suraj Kandpal
> Tested-by: Ben Kao
> ---
Reviewed-by: Arun R Murthy
Thanks and Regards,
Arun R Murthy
---
Subject: RE: [PATCH 4/7] drm/i915/backlight: Modify function to get VESA
> brightness in Nits
>
> > Modify vesa_get_brightness function to take into account
> > luminance_control_support and based on that read the appropriate
> > register and return the value.
> >
>
Subject: RE: [PATCH 3/7] drm/i915/backlight: Check Luminance based
> brightness control for VESA
>
> > Check if we are capable of controlling brightness via luminance which
> > is dependent on PANEL_LUMINANCE_OVERRIDE being set.
> >
> Is PANEL_LUMINANCE_OVERRIDE a macro?
> Modify vesa_get_brightness function to take into account
> luminance_control_support and based on that read the appropriate register
> and return the value.
>
> --v2
> -Changes since we now use luminance instead of nits
>
> Signed-off-by: Suraj Kandpal
> Tested-by: Ben Kao
> ---
> .../drm/i9
> Create a function that fills in the value for PANEL_TARGET_LUMINANCE_VALUE
> which helps in changing the luminance in nits using VESA interface.
>
> --v2
> -Prefer using luminance over nits [Jani]
>
> Signed-off-by: Suraj Kandpal
> Tested-by: Ben Kao
> ---
Reviewed-by: Arun R Murthy
Thanks
> Check if we are capable of controlling brightness via luminance which is
> dependent on PANEL_LUMINANCE_OVERRIDE being set.
>
Is PANEL_LUMINANCE_OVERRIDE a macro? I don't see this definition!
> --v2
> -Prefer using luminance rather than nits [Jani] -Fix commit message
>
> Signed-off-by: Suraj
> eDP is supposed to use VESA interface when using revision 1.5 and above, use
> Intel interface for backlight control otherwise. Add check to use correct
> interface.
>
> Signed-off-by: Suraj Kandpal
> Tested-by: Ben Kao
> ---
Reviewed-by: Arun R Murthy
Thanks and Regards,
Arun R Murthy
-
Create a function that fills in the value for
PANEL_TARGET_LUMINANCE_VALUE which helps in changing the luminance in
nits using VESA interface.
--v2
-Prefer using luminance over nits [Jani]
Signed-off-by: Suraj Kandpal
Tested-by: Ben Kao
---
.../drm/i915/display/intel_dp_aux_backlight.c | 30 ++
Modify vesa_get_brightness function to take into account
luminance_control_support and based on that read the appropriate
register and return the value.
--v2
-Changes since we now use luminance instead of nits
Signed-off-by: Suraj Kandpal
Tested-by: Ben Kao
---
.../drm/i915/display/intel_dp_au
Enable nits based luminance by writing the PANEL_LUMINANCE_CONTROL
bit and set the correct register to change brightness.
Signed-off-by: Suraj Kandpal
Tested-by: Ben Kao
---
.../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/dr
Modify backlight setup function for VESA interface to take into
account the nits based luminance.
--v2
-Prefer using luminance over nits [Jani]
Signed-off-by: Suraj Kandpal
Tested-by: Ben Kao
---
.../drm/i915/display/intel_dp_aux_backlight.c | 99 +++
1 file changed, 59 inserti
Check if we are capable of controlling brightness via luminance
which is dependent on PANEL_LUMINANCE_OVERRIDE being set.
--v2
-Prefer using luminance rather than nits [Jani]
-Fix commit message
Signed-off-by: Suraj Kandpal
Tested-by: Ben Kao
---
drivers/gpu/drm/i915/display/intel_display_type
eDP is supposed to use VESA interface when using revision 1.5 and above,
use Intel interface for backlight control otherwise. Add check to
use correct interface.
Signed-off-by: Suraj Kandpal
Tested-by: Ben Kao
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 8 +++-
1 file change
l, Suraj
>
> Subject: Re: [PATCH 3/7] drm/i915/backlight: Check Nits based brightness
> control for VESA
>
> On Fri, 24 Jan 2025, Suraj Kandpal wrote:
> > Check if we are capable of controlling brightness via Nits which is
> > dependant on PANEL_LUMINANCE_OVERRIDE
On Fri, 24 Jan 2025, Suraj Kandpal wrote:
> Create a function that fills in the value for
> PANEL_TARGET_LUMINANCE_VALUE which helps in changing the brightness in
> NITS using VESA interface.
>
> Signed-off-by: Suraj Kandpal
> ---
> .../drm/i915/display/intel_dp_aux_backlight.c | 29
On Fri, 24 Jan 2025, Suraj Kandpal wrote:
> Check if we are capable of controlling brightness via Nits which
> is dependant on PANEL_LUMINANCE_OVERRIDE and SMOOTH_BRIGHTNESS
> capablility being set.
>
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/display/intel_display_types.h|
On Sun, Feb 02, 2025 at 06:28:08AM -0800, Guenter Roeck wrote:
> On 2/2/25 05:27, David Laight wrote:
> > On Tue, 21 Jan 2025 15:15:09 -0800
> > Linus Torvalds wrote:
> >
> > > On Tue, 21 Jan 2025 at 14:59, Rodrigo Vivi wrote:
> > > >
> > > > I'm pushing this soon to drm-intel-next, unless Linu
This patch works as expected with 6.13.0-rc7 on Dell Bolan.
Tested-by: Ben Kao
This patch works as expected with 6.13.0-rc7 on Dell Bolan.
Tested-by: Ben Kao
This patch works as expected with 6.13.0-rc7 on Dell Bolan.
Tested-by: Ben Kao
This patch works as expected with 6.13.0-rc7 on Dell Bolan.
Tested-by: Ben Kao
This patch works as expected with 6.13.0-rc7 on Dell Bolan.
Tested-by: Ben Kao
This patch works as expected with 6.13.0-rc7 on Dell Bolan.
Tested-by: Ben Kao
On 2/2/25 05:27, David Laight wrote:
On Tue, 21 Jan 2025 15:15:09 -0800
Linus Torvalds wrote:
On Tue, 21 Jan 2025 at 14:59, Rodrigo Vivi wrote:
I'm pushing this soon to drm-intel-next, unless Linus want to take
this one directly to his tree
Let's just go through the proper channels and go
On Tue, 21 Jan 2025 15:15:09 -0800
Linus Torvalds wrote:
> On Tue, 21 Jan 2025 at 14:59, Rodrigo Vivi wrote:
> >
> > I'm pushing this soon to drm-intel-next, unless Linus want to take
> > this one directly to his tree
>
> Let's just go through the proper channels and go through the drm tree.
eDP is supposed to use VESA interface when using revision 1.5 and above,
use Intel interface for backlight control otherwise. Add check to
use correct interface.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 8 +++-
1 file changed, 7 insertions(+),
Check if we are capable of controlling brightness via Nits which
is dependant on PANEL_LUMINANCE_OVERRIDE and SMOOTH_BRIGHTNESS
capablility being set.
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp_aux_backlight
Modify backlight setup function for VESA interface to take into
account the NITS based brightness.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_dp_aux_backlight.c | 97 +++
1 file changed, 57 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/display
Enable Nits based brightness by writing the PANEL_LUMINANCE_CONTROL
bit and set the correct register to change brightness.
Signed-off-by: Suraj Kandpal
---
.../gpu/drm/i915/display/intel_dp_aux_backlight.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/
Create a function that fills in the value for
PANEL_TARGET_LUMINANCE_VALUE which helps in changing the brightness in
NITS using VESA interface.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_dp_aux_backlight.c | 29 +++
1 file changed, 29 insertions(+)
diff --git a/
Modify vesa_get_brightness function to take into account nits_support
and based on that read the appropriate register and return the value.
Signed-off-by: Suraj Kandpal
---
.../drm/i915/display/intel_dp_aux_backlight.c | 20 +++
1 file changed, 20 insertions(+)
diff --git a/driv
On Tue, 21 Jan 2025 at 14:59, Rodrigo Vivi wrote:
>
> I'm pushing this soon to drm-intel-next, unless Linus want to take
> this one directly to his tree
Let's just go through the proper channels and go through the drm tree.
Unless I've issed something, I think this is only an active issue on
par
On Tue, Jan 21, 2025 at 06:52:03AM -0800, Guenter Roeck wrote:
> The scale() functions detects invalid parameters, but continues
> its calculations anyway. This causes bad results if negative values
> are used for unsigned operations. Worst case, a division by 0 error
> will be seen if source_min =
The scale() functions detects invalid parameters, but continues
its calculations anyway. This causes bad results if negative values
are used for unsigned operations. Worst case, a division by 0 error
will be seen if source_min == source_max.
On top of that, after v6.13, the sequence of WARN_ON() f
On Mon, 20 Jan 2025, Guenter Roeck wrote:
> The scale() functions detects invalid parameters, but continues
> its calculations anyway. This causes bad results if negative values
> are used for unsigned operations. Worst case, a division by 0 error
> will be seen if source_min == source_max.
>
> On
The scale() functions detects invalid parameters, but continues
its calculations anyway. This causes bad results if negative values
are used for unsigned operations. Worst case, a division by 0 error
will be seen if source_min == source_max.
On top of that, after v6.13, the sequence of WARN_ON() f
Le 02/10/2024 à 13:51, Jani Nikula a écrit :
On Tue, 01 Oct 2024, Christophe JAILLET wrote:
Le 30/09/2024 à 09:48, Jani Nikula a écrit :
On Sat, 28 Sep 2024, Christophe JAILLET wrote:
"name" is allocated and freed in intel_backlight_device_register().
The initial allocation just duplicates "
On Tue, 01 Oct 2024, Christophe JAILLET wrote:
> Le 30/09/2024 à 09:48, Jani Nikula a écrit :
>> On Sat, 28 Sep 2024, Christophe JAILLET
>> wrote:
>>> "name" is allocated and freed in intel_backlight_device_register().
>>> The initial allocation just duplicates "intel_backlight".
>>>
>>> Later,
Le 30/09/2024 à 09:48, Jani Nikula a écrit :
On Sat, 28 Sep 2024, Christophe JAILLET wrote:
"name" is allocated and freed in intel_backlight_device_register().
The initial allocation just duplicates "intel_backlight".
Later, if a device with this name has already been registered, another
dynam
On Sat, 28 Sep 2024, Christophe JAILLET wrote:
> "name" is allocated and freed in intel_backlight_device_register().
> The initial allocation just duplicates "intel_backlight".
>
> Later, if a device with this name has already been registered, another
> dynamically generated one is allocated using
"name" is allocated and freed in intel_backlight_device_register().
The initial allocation just duplicates "intel_backlight".
Later, if a device with this name has already been registered, another
dynamically generated one is allocated using kasprintf().
So at the end of the function, when "name"
Hi,
On 11/21/21 12:00, Hans de Goede wrote:
> After the recent refactoring of the backlight code the contents of
> intel_panel_actually_set_backlight() is exactly the same (minus a
> small wording difference in the drm_dbg_kms() as the contents if the
> more widely used intel_backlight_set_pwm_lev
Reviewed-by: Lyude Paul
On Sun, 2021-11-21 at 12:00 +0100, Hans de Goede wrote:
> At least the Bay Trail LPSS PWM controller used with DSI panels on many
> Bay Trail tablets seems to leave the PWM pin in whatever state it was
> (high or low) ATM that the PWM gets disabled. Combined with some pane
On Sun, 21 Nov 2021, Hans de Goede wrote:
> At least the Bay Trail LPSS PWM controller used with DSI panels on many
> Bay Trail tablets seems to leave the PWM pin in whatever state it was
> (high or low) ATM that the PWM gets disabled. Combined with some panels
> not having a separate backlight-en
On Sun, 21 Nov 2021, Hans de Goede wrote:
> After the recent refactoring of the backlight code the contents of
> intel_panel_actually_set_backlight() is exactly the same (minus a
> small wording difference in the drm_dbg_kms() as the contents if the
> more widely used intel_backlight_set_pwm_level
At least the Bay Trail LPSS PWM controller used with DSI panels on many
Bay Trail tablets seems to leave the PWM pin in whatever state it was
(high or low) ATM that the PWM gets disabled. Combined with some panels
not having a separate backlight-enable pin this leads to the backlight
sometimes stay
After the recent refactoring of the backlight code the contents of
intel_panel_actually_set_backlight() is exactly the same (minus a
small wording difference in the drm_dbg_kms() as the contents if the
more widely used intel_backlight_set_pwm_level() function.
Drop the duplicate intel_panel_actual
On Sun, 23 Aug 2020, Sam Ravnborg wrote:
> Update backlight implementation to utilize newly added backlight
> functionality.
>
> - Use macros for initialization
> - Replace direct access to backlight_properties with get and set
> operations
> - Moved enable/disable after registering backlight de
Update backlight implementation to utilize newly added backlight
functionality.
- Use macros for initialization
- Replace direct access to backlight_properties with get and set
operations
- Moved enable/disable after registering backlight device
One side-effect of these changes is that the conf
Update backlight implementation to utilize newly added backlight
functionality.
- Use macros for initialization
- Replace direct access to backlight_properties with get and set
operations
- Dropped extra checks as some methods accepts a NULL backlight device.
One side-effect of these changes is
Use the CRC PWM device in intel_panel.c and add new MIPI backlight
specififc callbacks
v2: Modify to use pwm_config callback
v3: Addressed Jani's comments
- Renamed all function as pwm_* instead of vlv_*
- Call intel_panel_actually_set_backlight in enable function
- Return -ENODEV in c
On Thu, 25 Jun 2015, Shobhit Kumar wrote:
> On Thu, Jun 25, 2015 at 2:18 PM, Ville Syrjälä
> wrote:
>> On Mon, Jun 22, 2015 at 04:24:25PM +0530, Shobhit Kumar wrote:
>>> Use the CRC PWM device in intel_panel.c and add new MIPI backlight
>>> specififc callbacks
>>>
>>> v2: Modify to use pwm_conf
On Thu, Jun 25, 2015 at 6:17 PM, Ville Syrjälä
wrote:
> On Thu, Jun 25, 2015 at 05:38:50PM +0530, Shobhit Kumar wrote:
>> On Thu, Jun 25, 2015 at 2:18 PM, Ville Syrjälä
>> wrote:
>> > On Mon, Jun 22, 2015 at 04:24:25PM +0530, Shobhit Kumar wrote:
>> >> Use the CRC PWM device in intel_panel.c
On Thu, Jun 25, 2015 at 2:18 PM, Ville Syrjälä
wrote:
> On Mon, Jun 22, 2015 at 04:24:25PM +0530, Shobhit Kumar wrote:
>> Use the CRC PWM device in intel_panel.c and add new MIPI backlight
>> specififc callbacks
>>
>> v2: Modify to use pwm_config callback
>> v3: Addressed Jani's comments
>>
On Thu, Jun 25, 2015 at 05:38:50PM +0530, Shobhit Kumar wrote:
> On Thu, Jun 25, 2015 at 2:18 PM, Ville Syrjälä
> wrote:
> > On Mon, Jun 22, 2015 at 04:24:25PM +0530, Shobhit Kumar wrote:
> >> Use the CRC PWM device in intel_panel.c and add new MIPI backlight
> >> specififc callbacks
> >>
> >> v
On Mon, Jun 22, 2015 at 04:24:25PM +0530, Shobhit Kumar wrote:
> Use the CRC PWM device in intel_panel.c and add new MIPI backlight
> specififc callbacks
>
> v2: Modify to use pwm_config callback
> v3: Addressed Jani's comments
> - Renamed all function as pwm_* instead of vlv_*
> - Call in
Use the CRC PWM device in intel_panel.c and add new MIPI backlight
specififc callbacks
v2: Modify to use pwm_config callback
v3: Addressed Jani's comments
- Renamed all function as pwm_* instead of vlv_*
- Call intel_panel_actually_set_backlight in enable function
- Return -ENODEV in c
On Wed, 29 Apr 2015, Shobhit Kumar wrote:
> Use the CRC PWM device in intel_panel.c and add new MIPI backlight
> specififc callbacks
>
> v2: Modify to use pwm_config callback
>
> CC: Samuel Ortiz
> Cc: Linus Walleij
> Cc: Alexandre Courbot
> Cc: Thierry Reding
> Signed-off-by: Shobhit Kumar
>
Use the CRC PWM device in intel_panel.c and add new MIPI backlight
specififc callbacks
v2: Modify to use pwm_config callback
CC: Samuel Ortiz
Cc: Linus Walleij
Cc: Alexandre Courbot
Cc: Thierry Reding
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/i915/intel_drv.h | 5 +++
drivers/gpu/
On Fri, 09 Jan 2015, Jeremiah Mahler wrote:
> Jani, all,
>
> On a Lenovo X1 Carbon if the display is off when suspend is entered
> it will be off when it is resumed. A key must be pressed to restore
> normal brightness.
Please file a bug on [1] and attach dmesg with drm.debug=14 set, from
boot t
Jani, all,
On a Lenovo X1 Carbon if the display is off when suspend is entered
it will be off when it is resumed. A key must be pressed to restore
normal brightness.
xset dpms force off
sleep 1
sudo systemctl suspend
(resume)
(screen off, press any key)
The behavior I am accustomed to
On Fri, Aug 02, 2013 at 09:16:03AM +0800, Aaron Lu wrote:
> Hi Jani & Daniel,
>
> It turned out there is an integer overflow problem, and the below patch
> fixed this problem on Acer Aspire 4732Z and thinkpad R61i.
>
> From: Aaron Lu
> Subject: [PATCH] drm/i915: avoid brightness overflow when do
On Fri, Aug 02, 2013 at 09:16:03AM +0800, Aaron Lu wrote:
> Hi Jani & Daniel,
>
> It turned out there is an integer overflow problem, and the below patch
> fixed this problem on Acer Aspire 4732Z and thinkpad R61i.
>
> From: Aaron Lu
> Subject: [PATCH] drm/i915: avoid brightness overflow when do
On 2 August 2013 23:25, Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 3:11 PM, Josep Lladonosa wrote:
>> "Before" means with previous kernels that worked with
>>
>> GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
>
> That's probably a different issue. You would need to bisect the pro
"Before" means with previous kernels that worked with
GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
I have not checked this issue with acpi_osi="!Windows 2012".
Josep
On 2 August 2013 22:08, Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 3:03 PM, Josep Lladonosa wrote:
>> With t
Hi,
With this setup, something has happened: in xorg, when screen goes to
screensaver and after, enters into Standby mode, when I press a key,
it keeps black and, to recover screen, I have to adjust brightness
manually (by increasing), as if it didn't remember previous value to
standby mode.
This
On Friday, August 02, 2013 01:58:55 PM Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 9:03 AM, Rafael J. Wysocki wrote:
> > On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
> >> On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa
> >> wrote:
> >> > Hello,
> >> >
> >> > I am using a L
On 2 August 2013 23:25, Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 3:11 PM, Josep Lladonosa wrote:
>> "Before" means with previous kernels that worked with
>>
>> GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
>
> That's probably a different issue. You would need to bisect the pro
On Fri, Aug 02, 2013 at 10:11:27PM +0200, Josep Lladonosa wrote:
> "Before" means with previous kernels that worked with
>
> GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
>
> I have not checked this issue with acpi_osi="!Windows 2012".
Hey Josep,
would you please not top-post when y
"Before" means with previous kernels that worked with
GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
I have not checked this issue with acpi_osi="!Windows 2012".
Josep
On 2 August 2013 22:08, Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 3:03 PM, Josep Lladonosa wrote:
>> With t
Hi,
With this setup, something has happened: in xorg, when screen goes to
screensaver and after, enters into Standby mode, when I press a key,
it keeps black and, to recover screen, I have to adjust brightness
manually (by increasing), as if it didn't remember previous value to
standby mode.
This
On Fri, Aug 2, 2013 at 6:35 PM, Rafael J. Wysocki wrote:
> On Friday, August 02, 2013 01:58:55 PM Felipe Contreras wrote:
>> On Fri, Aug 2, 2013 at 9:03 AM, Rafael J. Wysocki wrote:
>> > On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
>> >> I think it's pretty obvious that for the
On Fri, Aug 2, 2013 at 6:35 PM, Rafael J. Wysocki wrote:
> On Friday, August 02, 2013 01:58:55 PM Felipe Contreras wrote:
>> On Fri, Aug 2, 2013 at 9:03 AM, Rafael J. Wysocki wrote:
>> > On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
>> >> I think it's pretty obvious that for the
On Friday, August 02, 2013 01:58:55 PM Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 9:03 AM, Rafael J. Wysocki wrote:
> > On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
> >> On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa wrote:
> >> > Hello,
> >> >
> >> > I am using a Lenovo
On Fri, Aug 2, 2013 at 3:11 PM, Josep Lladonosa wrote:
> "Before" means with previous kernels that worked with
>
> GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
That's probably a different issue. You would need to bisect the problem.
> I have not checked this issue with acpi_osi="!Wi
On Friday, August 02, 2013 01:48:37 AM Felipe Contreras wrote:
> On Fri, Aug 2, 2013 at 1:25 AM, Josep Lladonosa wrote:
> > Hello,
> >
> > I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to
> > change to this parameter to the kernel boot:
> >
> >
> > GRUB_CMDLINE_LINUX="acpi_osi=\
1 - 100 of 179 matches
Mail list logo
