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=\
On Fri, Aug 2, 2013 at 3:03 PM, Josep Lladonosa wrote:
> 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
On 08/02/2013 02:25 PM, 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=\"!Windows 2012\""
What if you remove the above from kernel command line, and add
vid
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 08/01/2013 04:07 PM, Borislav Petkov wrote:
> On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
>> Does reverting efaa14c help?
>
> Nope.
>
> But see my other reply to Aaron.
Assume you have specified to use intel_backlight in xorg.conf, does
booting with video.brightness_swi
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 Edge E530 and, with kernel 3.11.0-rc3, I had to
>> > change to this par
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
On Fri, Aug 2, 2013 at 3:03 PM, Josep Lladonosa wrote:
> 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
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 Edge E530 and, with kernel 3.11.0-rc3, I had to
>> > change to this paramet
On Fri, Aug 02, 2013 at 09:16:03AM +0800, Aaron Lu wrote:
> Since the sysfs interface works on your system, I think your problem
> should be different. Can you please file a bug for this? I can provide
> you with a debug patch and then see what happened. Please attach
> acpidump when filing the bug
On Fri, Aug 02, 2013 at 02:00:42PM +0800, Aaron Lu wrote:
> Assume you have specified to use intel_backlight in xorg.conf
Right, I have:
Section "Device"
Option "Backlight" "intel_backlight"
Identifier "Card0"
Driver "intel"
BusID "PCI:0:2:0"
EndSe
Hello,
Yes, it works! I get now 11 levels from all black to the brightest.
acpi_listen shows messages
Josep
On 2 August 2013 08:36, Aaron Lu wrote:
> On 08/02/2013 02:25 PM, Josep Lladonosa wrote:
>> Hello,
>>
>> I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to
>> change to
On 08/01/2013 05:07 PM, Aaron Lu wrote:
> On 08/01/2013 04:12 PM, Borislav Petkov wrote:
>> On Thu, Aug 01, 2013 at 09:13:35AM +0800, Aaron Lu wrote:
>>> Can you please run acpi_listen and then press the Fn-Fx key, see if the
>>> events are correctly sent out?
>>
>> Like this?
>>
>> # acpi_listen
>
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=\"!Windows 2012\""
instead of previous
GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
to be able to change brightness. In some kerne
On 08/02/2013 02:25 PM, 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=\"!Windows 2012\""
What if you remove the above from kernel command line, and add
vid
On 08/01/2013 04:07 PM, Borislav Petkov wrote:
> On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
>> Does reverting efaa14c help?
>
> Nope.
>
> But see my other reply to Aaron.
Assume you have specified to use intel_backlight in xorg.conf, does
booting with video.brightness_swi
Hello,
Yes, it works! I get now 11 levels from all black to the brightest.
acpi_listen shows messages
Josep
On 2 August 2013 08:36, Aaron Lu wrote:
> On 08/02/2013 02:25 PM, Josep Lladonosa wrote:
>> Hello,
>>
>> I am using a Lenovo Edge E530 and, with kernel 3.11.0-rc3, I had to
>> change to
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=\"!Windows 2012\""
instead of previous
GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"
to be able to change brightness. In some kerne
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=\
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=\"!Windows 2012\""
I think it's pretty obvious that for the time being we need
On Fri, Aug 02, 2013 at 09:16:03AM +0800, Aaron Lu wrote:
> Since the sysfs interface works on your system, I think your problem
> should be different. Can you please file a bug for this? I can provide
> you with a debug patch and then see what happened. Please attach
> acpidump when filing the bug
On Fri, Aug 02, 2013 at 02:00:42PM +0800, Aaron Lu wrote:
> Assume you have specified to use intel_backlight in xorg.conf
Right, I have:
Section "Device"
Option "Backlight" "intel_backlight"
Identifier "Card0"
Driver "intel"
BusID "PCI:0:2:0"
EndSe
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=\"!Windows 2012\""
I think it's pretty obvious that for the time being we need
On 08/01/2013 05:07 PM, Aaron Lu wrote:
> On 08/01/2013 04:12 PM, Borislav Petkov wrote:
>> On Thu, Aug 01, 2013 at 09:13:35AM +0800, Aaron Lu wrote:
>>> Can you please run acpi_listen and then press the Fn-Fx key, see if the
>>> events are correctly sent out?
>>
>> Like this?
>>
>> # acpi_listen
>
On 08/01/2013 04:12 PM, Borislav Petkov wrote:
> On Thu, Aug 01, 2013 at 09:13:35AM +0800, Aaron Lu wrote:
>> Can you please run acpi_listen and then press the Fn-Fx key, see if the
>> events are correctly sent out?
>
> Like this?
>
> # acpi_listen
> video/brightnessdown BRTDN 0087
>
On 08/01/2013 12:36 AM, Borislav Petkov wrote:
> On Wed, Jul 31, 2013 at 06:22:52PM +0200, Borislav Petkov wrote:
>> Dudes,
>>
>> has anyone already reported this (happens on Linus of today +
>> tip/master):
>
> Oh, one more thing: I can't control the backlight anymore on this x230
> with the Fn-F
On 08/01/2013 04:12 PM, Borislav Petkov wrote:
> On Thu, Aug 01, 2013 at 09:13:35AM +0800, Aaron Lu wrote:
>> Can you please run acpi_listen and then press the Fn-Fx key, see if the
>> events are correctly sent out?
>
> Like this?
>
> # acpi_listen
> video/brightnessdown BRTDN 0087
>
On Thu, Aug 01, 2013 at 09:13:35AM +0800, Aaron Lu wrote:
> Can you please run acpi_listen and then press the Fn-Fx key, see if the
> events are correctly sent out?
Like this?
# acpi_listen
video/brightnessdown BRTDN 0087
video/brightnessup BRTUP 0086
video/brightnessdow
On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
> Does reverting efaa14c help?
Nope.
But see my other reply to Aaron.
Thanks.
On 08/01/2013 12:36 AM, Borislav Petkov wrote:
> On Wed, Jul 31, 2013 at 06:22:52PM +0200, Borislav Petkov wrote:
>> Dudes,
>>
>> has anyone already reported this (happens on Linus of today +
>> tip/master):
>
> Oh, one more thing: I can't control the backlight anymore on this x230
> with the Fn-F
On Thu, Aug 01, 2013 at 09:13:35AM +0800, Aaron Lu wrote:
> Can you please run acpi_listen and then press the Fn-Fx key, see if the
> events are correctly sent out?
Like this?
# acpi_listen
video/brightnessdown BRTDN 0087
video/brightnessup BRTUP 0086
video/brightnessdow
On Wed, Jul 31, 2013 at 11:16:52PM +0200, Rafael J. Wysocki wrote:
> Does reverting efaa14c help?
Nope.
But see my other reply to Aaron.
Thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dr
On Wednesday, July 31, 2013 06:36:23 PM Borislav Petkov wrote:
> On Wed, Jul 31, 2013 at 06:22:52PM +0200, Borislav Petkov wrote:
> > Dudes,
> >
> > has anyone already reported this (happens on Linus of today +
> > tip/master):
>
> Oh, one more thing: I can't control the backlight anymore on this
On Wed, Jul 31, 2013 at 06:22:52PM +0200, Borislav Petkov wrote:
> Dudes,
>
> has anyone already reported this (happens on Linus of today +
> tip/master):
Oh, one more thing: I can't control the backlight anymore on this x230
with the Fn-Fx keys and this is most probably related to that recent
ba
On Wednesday, July 31, 2013 06:36:23 PM Borislav Petkov wrote:
> On Wed, Jul 31, 2013 at 06:22:52PM +0200, Borislav Petkov wrote:
> > Dudes,
> >
> > has anyone already reported this (happens on Linus of today +
> > tip/master):
>
> Oh, one more thing: I can't control the backlight anymore on this
On Wed, Jul 31, 2013 at 06:22:52PM +0200, Borislav Petkov wrote:
> Dudes,
>
> has anyone already reported this (happens on Linus of today +
> tip/master):
Oh, one more thing: I can't control the backlight anymore on this x230
with the Fn-Fx keys and this is most probably related to that recent
ba
On Mon, Jun 3, 2013 at 9:42 PM, Aaron Plattner wrote:
> On 06/03/2013 12:36 PM, Daniel Vetter wrote:
>>
>> On Mon, Jun 03, 2013 at 09:13:18AM -0700, Aaron Plattner wrote:
>>>
>>> On 05/20/2013 02:55 PM, Daniel Vetter wrote:
On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wro
On Mon, Jun 03, 2013 at 09:13:18AM -0700, Aaron Plattner wrote:
> On 05/20/2013 02:55 PM, Daniel Vetter wrote:
> >On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote:
> >>Hallo,
> >>
> >>I hope this is the right place to ask, because I actually don't know
> >>whether it is a bug or a
On Mon, Jun 3, 2013 at 4:03 PM, Daniel Vetter wrote:
> On Mon, Jun 3, 2013 at 9:42 PM, Aaron Plattner
> wrote:
>> On 06/03/2013 12:36 PM, Daniel Vetter wrote:
>>>
>>> On Mon, Jun 03, 2013 at 09:13:18AM -0700, Aaron Plattner wrote:
On 05/20/2013 02:55 PM, Daniel Vetter wrote:
>
On Mon, Jun 3, 2013 at 4:03 PM, Daniel Vetter wrote:
> On Mon, Jun 3, 2013 at 9:42 PM, Aaron Plattner wrote:
>> On 06/03/2013 12:36 PM, Daniel Vetter wrote:
>>>
>>> On Mon, Jun 03, 2013 at 09:13:18AM -0700, Aaron Plattner wrote:
On 05/20/2013 02:55 PM, Daniel Vetter wrote:
>
> O
On Mon, Jun 3, 2013 at 9:42 PM, Aaron Plattner wrote:
> On 06/03/2013 12:36 PM, Daniel Vetter wrote:
>>
>> On Mon, Jun 03, 2013 at 09:13:18AM -0700, Aaron Plattner wrote:
>>>
>>> On 05/20/2013 02:55 PM, Daniel Vetter wrote:
On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wro
On 06/03/2013 12:36 PM, Daniel Vetter wrote:
On Mon, Jun 03, 2013 at 09:13:18AM -0700, Aaron Plattner wrote:
On 05/20/2013 02:55 PM, Daniel Vetter wrote:
On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote:
Hallo,
I hope this is the right place to ask, because I actually don't
On 06/03/2013 12:36 PM, Daniel Vetter wrote:
> On Mon, Jun 03, 2013 at 09:13:18AM -0700, Aaron Plattner wrote:
>> On 05/20/2013 02:55 PM, Daniel Vetter wrote:
>>> On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote:
Hallo,
I hope this is the right place to ask, because
On Mon, Jun 03, 2013 at 09:13:18AM -0700, Aaron Plattner wrote:
> On 05/20/2013 02:55 PM, Daniel Vetter wrote:
> >On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote:
> >>Hallo,
> >>
> >>I hope this is the right place to ask, because I actually don't know
> >>whether it is a bug or a
On 05/20/2013 02:55 PM, Daniel Vetter wrote:
On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote:
Hallo,
I hope this is the right place to ask, because I actually don't know
whether it is a bug or a feature that I'm experiencing since linux 3.9:
When I boot my system the backligh
On 05/20/2013 02:55 PM, Daniel Vetter wrote:
> On Sat, May 18, 2013 at 12:39:14AM +0200, Jan Hinnerk Stosch wrote:
>> Hallo,
>>
>> I hope this is the right place to ask, because I actually don't know
>> whether it is a bug or a feature that I'm experiencing since linux 3.9:
>> When I boot my system
On Wed, May 22, 2013 at 6:08 PM, Joakim Plate wrote:
>> 2013/5/20 Daniel Vetter ffwll.ch>
>> Yeah, this is a feature. HDMI has (for oddball backwards compat with
>> analog TV signals) a special mode which reduces the useable RGB value
>> range by chopping off about 10% at the bottom and top end.
Hi,
>
> 2013/5/20 Daniel Vetter ffwll.ch>
> Yeah, this is a feature. HDMI has (for oddball backwards compat with
> analog TV signals) a special mode which reduces the useable RGB value
> range by chopping off about 10% at the bottom and top end. This results in
> light colors getting brighter an
On Wed, May 22, 2013 at 6:08 PM, Joakim Plate wrote:
>> 2013/5/20 Daniel Vetter ffwll.ch>
>> Yeah, this is a feature. HDMI has (for oddball backwards compat with
>> analog TV signals) a special mode which reduces the useable RGB value
>> range by chopping off about 10% at the bottom and top end.
Hi,
>
> 2013/5/20 Daniel Vetter ffwll.ch>
> Yeah, this is a feature. HDMI has (for oddball backwards compat with
> analog TV signals) a special mode which reduces the useable RGB value
> range by chopping off about 10% at the bottom and top end. This results in
> light colors getting brighter an
1 - 100 of 130 matches
Mail list logo
