Re: [Intel-gfx] [PATCH v6] drm/i915: respect the VBT minimum backlight brightness again
On 12/11/2015 09:28, Shih-Yuan Lee (FourDollars) wrote: I think the first step is to identify which backlight interface is able to actually change the brightness. Usually there are two backlight interfaces under /sys/class/backlight/, i.e. /sys/class/backlight/acpi_video0 and /sys/class/backlight/intel_backlight. However you may see other different backlight interfaces under /sys/class/backlight/. It depends on what hardware you are using. Executing `cat max_brightness` under those folders can see the max brightness and then you can execute `echo $(($(cat max_brightness)/2)) | sudo tee brightness` to adjust it to about 50% brightness. only /sys/class/backlight/intel_backlight is present. max_brightness is 937 these commands have no effect on display brightness: echo 0 >brightness echo 468 >brightness echo 937 >brightness Regards, Steph On Thu, Nov 12, 2015 at 4:08 PM, Stéphane ANCELOT <mailto:sance...@free.fr>> wrote: Hi, I have seen you were working on brightness. Right, but this is useful only if many worlwide users would be able to activate it. I have never been able to make it working on my intel systemes (core i5 - 4300u , core i3 ...) Very difficult to check where the problem is coming from, altough you have either an intel_backlight or acpi_backlight folder in the sys directory Regarding many many posts on the web, this sounds tricky and difficult to know why it has not worked, or simply the documentation is lacking Regards, S.Ancelot On 12/11/2015 06:43, Shih-Yuan Lee (FourDollars) wrote: There was a wonderful period after commit 6dda730e55f412a6dfb181cae6784822ba463847 Author: Jani Nikula http://intel.com>> Date: Tue Jun 24 18:27:40 2014 +0300 drm/i915: respect the VBT minimum backlight brightness The backlight class 0 brightness means the PWM min and it does not turn off the backlight. After kernel 3.18, the backlight class 0 brightness is used to turn off the backlight and the PWM min is missing. Because of commit e6755fb78e8f20ecadf2a4080084121336624ad9 Author: Jani Nikula http://intel.com>> Date: Tue Aug 12 17:11:42 2014 +0300 drm/i915: switch off backlight for backlight class 0 brightness Use "VBT backlight PWM modulation frequency 200 Hz, active high, min brightness 10, level 255" as an example. It means the VBT min is 10 out of [0..255] and the PWM max is 937 from other place so the corresponding PWM min should be 37 (10 * 937 / 255). When we set backlight class 0 brightness, the backlight is turned off. Althought the PWM value is 37 when the backlight is off but it is useless. When we set set backlight class 1 brightness, the backlight is on but the PWM value is 38 and it doesn't match the corresponding PWM min of the VBT minimum backlight. And it has another minor issue that there are some backlight class brightness values are mapped to the same PWM value because the backlight class brightness range is larger than the valid PWM brightness range. The backlight class brightness range [0..937] The valid PWM brightness range [37..937] This commit makes that backlight class 1 brightness means the PWM min and backlight class max_brightness means the PWM max, and the ranges become The backlight class brightness range [0..901] The valid PWM brightness range [36..937] That's no backlight class brightness value mapped to the same PWM value. Signed-off-by: Shih-Yuan Lee (FourDollars) mailto:sy...@canonical.com>> --- drivers/gpu/drm/i915/intel_panel.c | 26 ++ 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index b05c6d9..8efa199 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -1194,10 +1194,9 @@ static int intel_backlight_device_register(struct intel_connector *connector) props.type = BACKLIGHT_RAW; /* -* Note: Everything should work even if the backlight device max -* presented to the userspace is arbitrarily chosen. +* Expose the whole valid PWM brightness range to the backlight class. */ - props.max_brightness = panel->backlight.max; + props.max_brightness = panel->backlight.max - panel->backlight.min; props.brightness = scale_hw_to_user(connec
Re: [Intel-gfx] [PATCH v6] drm/i915: respect the VBT minimum backlight brightness again
Hi,
I have seen you were working on brightness. Right, but this is useful
only if many worlwide users would be able to activate it.
I have never been able to make it working on my intel systemes (core i5
- 4300u , core i3 ...)
Very difficult to check where the problem is coming from, altough you
have either an intel_backlight or acpi_backlight folder in the sys directory
Regarding many many posts on the web, this sounds tricky and difficult
to know why it has not worked, or simply the documentation is lacking
Regards,
S.Ancelot
On 12/11/2015 06:43, Shih-Yuan Lee (FourDollars) wrote:
There was a wonderful period after
commit 6dda730e55f412a6dfb181cae6784822ba463847
Author: Jani Nikula
Date: Tue Jun 24 18:27:40 2014 +0300
drm/i915: respect the VBT minimum backlight brightness
The backlight class 0 brightness means the PWM min and it does not turn
off the backlight. After kernel 3.18, the backlight class 0 brightness
is used to turn off the backlight and the PWM min is missing.
Because of
commit e6755fb78e8f20ecadf2a4080084121336624ad9
Author: Jani Nikula
Date: Tue Aug 12 17:11:42 2014 +0300
drm/i915: switch off backlight for backlight class 0 brightness
Use "VBT backlight PWM modulation frequency 200 Hz, active high, min
brightness 10, level 255" as an example. It means the VBT min is 10
out of [0..255] and the PWM max is 937 from other place so the
corresponding PWM min should be 37 (10 * 937 / 255).
When we set backlight class 0 brightness, the backlight is turned off.
Althought the PWM value is 37 when the backlight is off but it is
useless. When we set set backlight class 1 brightness, the backlight is
on but the PWM value is 38 and it doesn't match the corresponding PWM
min of the VBT minimum backlight.
And it has another minor issue that there are some backlight class
brightness values are mapped to the same PWM value because the backlight
class brightness range is larger than the valid PWM brightness range.
The backlight class brightness range [0..937]
The valid PWM brightness range [37..937]
This commit makes that backlight class 1 brightness means the PWM min
and backlight class max_brightness means the PWM max, and the ranges
become
The backlight class brightness range [0..901]
The valid PWM brightness range [36..937]
That's no backlight class brightness value mapped to the same PWM value.
Signed-off-by: Shih-Yuan Lee (FourDollars)
---
drivers/gpu/drm/i915/intel_panel.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index b05c6d9..8efa199 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1194,10 +1194,9 @@ static int intel_backlight_device_register(struct
intel_connector *connector)
props.type = BACKLIGHT_RAW;
/*
-* Note: Everything should work even if the backlight device max
-* presented to the userspace is arbitrarily chosen.
+* Expose the whole valid PWM brightness range to the backlight class.
*/
- props.max_brightness = panel->backlight.max;
+ props.max_brightness = panel->backlight.max - panel->backlight.min;
props.brightness = scale_hw_to_user(connector,
panel->backlight.level,
props.max_brightness);
@@ -1400,7 +1399,8 @@ static u32 get_backlight_min_vbt(struct intel_connector
*connector)
struct drm_device *dev = connector->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_panel *panel = &connector->panel;
- int min;
+ int vbt_min;
+ u32 pwm_min;
WARN_ON(panel->backlight.max == 0);
@@ -1411,14 +1411,24 @@ static u32 get_backlight_min_vbt(struct intel_connector *connector)
* against this by letting the minimum be at most (arbitrarily chosen)
* 25% of the max.
*/
- min = clamp_t(int, dev_priv->vbt.backlight.min_brightness, 0, 64);
- if (min != dev_priv->vbt.backlight.min_brightness) {
+ vbt_min = clamp_t(int, dev_priv->vbt.backlight.min_brightness, 0, 64);
+ if (vbt_min != dev_priv->vbt.backlight.min_brightness) {
DRM_DEBUG_KMS("clamping VBT min backlight %d/255 to %d/255\n",
- dev_priv->vbt.backlight.min_brightness, min);
+ dev_priv->vbt.backlight.min_brightness, vbt_min);
}
/* vbt value is a coefficient in range [0..255] */
- return scale(min, 0, 255, 0, panel->backlight.max);
+ pwm_min = scale(vbt_min, 0, 255, 0, panel->backlight.max);
+
+ /*
+* Because backlight class brightness 0 is used to turn off the
backlight, we
+* need to step down a little bit here to make backlight class
brightness 1
+* match the real PWM min.
+*/
+ if (pwm_min > 0)
+
[Intel-gfx] 3.16 backlight kernel options
Hi, Which option is mandatory in linux kernel to be able to act on brightness of display ? Regards, Steph ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] INTEL ATOM E3826 Feedback from an industrial customer.
Hi, My name is Stéphane ANCELOT, I am working at Numalliance R&D Team in France (http://www.numalliance.com). We are making our own wire bending CNC platform, linux based using INTEL PC platforms (automation and GUI in the same PC). That may be the wrong place, but I think it is important to report my experience, regarding intel graphics performance , when benchmarking INTEL ATOM platforms for usage in our CNC.You may be able to report to the right persons in INTEL group Our application need realtime performance to run automation tasks. This is done using Realtime patches against standard linux kernels. This means we can not use the more recent kernels, but stabilised kernel releases versions (at time of writing, RT preempt : kernel 3.14, xenomai API: kernel 3.16...) I used a kernel 3.16.2. We are using a 19 inch vertical display at 1280x1024 resolution. We faced following problems with GFX driver : a/console flickering console at screen bottom in kernel 3.16.2 . The problem increased when there was CPU/disk/network activity.This problem does not appear from kernel 3.18.2 release. Unfortunately in our environment, we can not use 3.18 kernel , because it is not ready with realtime patches. b/ 2D performance Poor 2D performance, looks like we have not had 2D acceleration. Visually poor performance visible when raising/lowering fullscreen window. When moving object in paint application (inkscape) , the object does not follow efficiently the mouse. c/ 3D performances In our application,we are making heavy usage of 3D for CNC simulation (some screenshots available on request only). We have seen lot better performances than ATOM D2550 , we tried in the past. That seems a good thing. Conclusion Although there is a wish from Intel to provide ATOM platforms ready for industry, it is not ready regarding ATOM platforms. Because we can not change kernel releases versions, when validating a product. This requirement should be considered. In the same way, we can not change the PC platform every year, because of processor obsolescence. In our case, we are dependant on Ethernet realtime driver, Realtime patches, graphic 2D and 3D performance. We think too, that since ATOM platforms is not very spreaded and so common as Desktop platforms, BayTrail drivers are not so efficients. I am sure They will be... but in may be 2 years... For these reasons, we will stop benchmarking ATOM platforms, and will benchmark Core Ix platforms, since we think the GFX chipsets is better supported regarding drivers . Am I right ? I am an open minded guy, so feel free to give your positive or negative opinion ! ;-) I can give more details if needed. Have a look at what we are doing with an INTEL platform : https://www.youtube.com/watch?v=wj30CeAFwuk Regards Stephane ANCELOT sance...@numalliance.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] flickering console
Hi I don't know if it is the right place... but I will explain my problem : I am using an ATOM INTEL E3826 platform. I have got flickering problems at bottom of my tty console, using 3.16.2 kernel. I tried kernel 3.18 and it has not the problem. For some technical reasons, I can not switch to 3.18 . Please can you tell me which software part of 3.16.2 I should modify to solve it? Regards, Steph ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
