Dark display

[torreydale]

I am now using one of the compton.conf files from that site.  Things appear to be okay on one computer.  This is what my compton.conf file looked like before the change.

Code: [Select]


#################################
#
# Backend
#
#################################


# Backend to use: "xrender" or "glx".
# GLX backend is typically much faster but depends on a sane driver.
backend = "glx";


#################################
#
# GLX backend
#
#################################


glx-no-stencil = true;


# GLX backend: Copy unmodified regions from front buffer instead of redrawing them all.
# My tests with nvidia-drivers show a 10% decrease in performance when the whole screen is modified,
# but a 20% increase when only 1/4 is.
# My tests on nouveau show terrible slowdown.
# Useful with --glx-swap-method, as well.
glx-copy-from-front = false;


# GLX backend: Use MESA_copy_sub_buffer to do partial screen update.
# My tests on nouveau shows a 200% performance boost when only 1/4 of the screen is updated.
# May break VSync and is not available on some drivers.
# Overrides --glx-copy-from-front.
# glx-use-copysubbuffermesa = true;


# GLX backend: Avoid rebinding pixmap on window damage.
# Probably could improve performance on rapid window content changes, but is known to break things on some drivers (LLVMpipe).
# Recommended if it works.
# glx-no-rebind-pixmap = true;




# GLX backend: GLX buffer swap method we assume.
# Could be undefined (0), copy (1), exchange (2), 3-6, or buffer-age (-1).
# undefined is the slowest and the safest, and the default value.
# copy is fastest, but may fail on some drivers,
# 2-6 are gradually slower but safer (6 is still faster than 0).
# Usually, double buffer means 2, triple buffer means 3.
# buffer-age means auto-detect using GLX_EXT_buffer_age, supported by some drivers.
# Useless with --glx-use-copysubbuffermesa.
# Partially breaks --resize-damage.
# Defaults to undefined.
glx-swap-method = "undefined";


#################################
#
# Shadows
#
#################################


# Enabled client-side shadows on windows.
shadow = true;
# Don't draw shadows on DND windows.
no-dnd-shadow = true;
# Avoid drawing shadows on dock/panel windows.
no-dock-shadow = true;
# Zero the part of the shadow's mask behind the window. Fix some weirdness with ARGB windows.
clear-shadow = true;
# The blur radius for shadows. (default 12)
shadow-radius = 5;
# The left offset for shadows. (default -15)
shadow-offset-x = -5;
# The top offset for shadows. (default -15)
shadow-offset-y = -5;
# The translucency for shadows. (default .75)
shadow-opacity = 0.5;


# Set if you want different colour shadows
# shadow-red = 0.0;
# shadow-green = 0.0;
# shadow-blue = 0.0;


# The shadow exclude options are helpful if you have shadows enabled. Due to the way compton draws its shadows, certain applications will have visual glitches
# (most applications are fine, only apps that do weird things with xshapes or argb are affected).
# This list includes all the affected apps I found in my testing. The "! name~=''" part excludes shadows on any "Unknown" windows, this prevents a visual glitch with the XFWM alt tab switcher.
shadow-exclude = [
    "! name~=''",
    "name = 'Notification'",
    "name = 'Plank'",
    "name = 'Docky'",
    "name = 'Kupfer'",
    "name = 'xfce4-notifyd'",
    "name *= 'VLC'",
    "name *= 'compton'",
    "name *= 'Chromium'",
    "name *= 'Chrome'",
    "name *= 'Firefox'",
    "class_g = 'Conky'",
    "class_g = 'Kupfer'",
    "class_g = 'Synapse'",
    "class_g ?= 'Notify-osd'",
    "class_g ?= 'Cairo-dock'",
    "class_g ?= 'Xfce4-notifyd'",
    "class_g ?= 'Xfce4-power-manager'"
];
# Avoid drawing shadow on all shaped windows (see also: --detect-rounded-corners)
shadow-ignore-shaped = false;


#################################
#
# Opacity
#
#################################


menu-opacity = 1;
inactive-opacity = 1;
active-opacity = 1;
frame-opacity = 1;
inactive-opacity-override = false;
alpha-step = 0.06;


# Dim inactive windows. (0.0 - 1.0)
# inactive-dim = 0.2;
# Do not let dimness adjust based on window opacity.
# inactive-dim-fixed = true;
# Blur background of transparent windows. Bad performance with X Render backend. GLX backend is preferred.
# blur-background = true;
# Blur background of opaque windows with transparent frames as well.
# blur-background-frame = true;
# Do not let blur radius adjust based on window opacity.
blur-background-fixed = false;
blur-background-exclude = [
    "window_type = 'dock'",
    "window_type = 'desktop'"
];


#################################
#
# Fading
#
#################################


# Fade windows during opacity changes.
fading = true;
# The time between steps in a fade in milliseconds. (default 10).
fade-delta = 4;
# Opacity change between steps while fading in. (default 0.028).
fade-in-step = 0.03;
# Opacity change between steps while fading out. (default 0.03).
fade-out-step = 0.03;
# Fade windows in/out when opening/closing
# no-fading-openclose = true;


# Specify a list of conditions of windows that should not be faded.
fade-exclude = [ ];


#################################
#
# Other
#
#################################


# Try to detect WM windows and mark them as active.
mark-wmwin-focused = true;
# Mark all non-WM but override-redirect windows active (e.g. menus).
mark-ovredir-focused = true;
# Use EWMH _NET_WM_ACTIVE_WINDOW to determine which window is focused instead of using FocusIn/Out events.
# Usually more reliable but depends on a EWMH-compliant WM.
use-ewmh-active-win = true;
# Detect rounded corners and treat them as rectangular when --shadow-ignore-shaped is on.
detect-rounded-corners = true;


# Detect _NET_WM_OPACITY on client windows, useful for window managers not passing _NET_WM_OPACITY of client windows to frame windows.
# This prevents opacity being ignored for some apps.
# For example without this enabled my xfce4-notifyd is 100% opacity no matter what.
detect-client-opacity = true;


# Specify refresh rate of the screen.
# If not specified or 0, compton will try detecting this with X RandR extension.
refresh-rate = 0;


# Set VSync method. VSync methods currently available:
# none: No VSync
# drm: VSync with DRM_IOCTL_WAIT_VBLANK. May only work on some drivers.
# opengl: Try to VSync with SGI_video_sync OpenGL extension. Only work on some drivers.
# opengl-oml: Try to VSync with OML_sync_control OpenGL extension. Only work on some drivers.
# opengl-swc: Try to VSync with SGI_swap_control OpenGL extension. Only work on some drivers. Works only with GLX backend. Known to be most effective on many drivers. Does not actually control paint timing, only buffer swap is affected, so it doesn’t have the effect of --sw-opti unlike other methods. Experimental.
# opengl-mswc: Try to VSync with MESA_swap_control OpenGL extension. Basically the same as opengl-swc above, except the extension we use.
# (Note some VSync methods may not be enabled at compile time.)
vsync = "opengl-swc";


# Enable DBE painting mode, intended to use with VSync to (hopefully) eliminate tearing.
# Reported to have no effect, though.
dbe = false;
# Painting on X Composite overlay window. Recommended.
paint-on-overlay = true;


# Limit compton to repaint at most once every 1 / refresh_rate second to boost performance.
# This should not be used with --vsync drm/opengl/opengl-oml as they essentially does --sw-opti's job already,
# unless you wish to specify a lower refresh rate than the actual value.
sw-opti = false;


# Unredirect all windows if a full-screen opaque window is detected, to maximize performance for full-screen windows, like games.
# Known to cause flickering when redirecting/unredirecting windows.
# paint-on-overlay may make the flickering less obvious.
unredir-if-possible = true;


# Specify a list of conditions of windows that should always be considered focused.
focus-exclude = [ ];


# Use WM_TRANSIENT_FOR to group windows, and consider windows in the same group focused at the same time.
detect-transient = true;
# Use WM_CLIENT_LEADER to group windows, and consider windows in the same group focused at the same time.
# WM_TRANSIENT_FOR has higher priority if --detect-transient is enabled, too.
detect-client-leader = true;


#################################
#
# Window type settings
#
#################################


wintypes:
{
    tooltip =
    {
        # fade: Fade the particular type of windows.
        fade = true;
        # shadow: Give those windows shadow
        shadow = false;
        # opacity: Default opacity for the type of windows.
        opacity = 0.85;
        # focus: Whether to always consider windows of this type focused.
        focus = true;
    };
};

[trinidad]

Maybe --inactive-dim-fixed

https://forum.manjaro.org/t/dump-your-compton-config-with-inxi-g/10069/11

Most complete config file I could find online so far.
Also consider if multiple users must be enabled globally.
Also perhaps null at startup and load new each restart, or perhaps disable hibernation altogether.
I doubt shadow is the issue. Conky should excluded by default.
Dump your config file and check through it.

Also I think this is the defined security update: https://usn.ubuntu.com/usn/usn-3377-2/

Possibly the new mem limits affected compton settings as it was probably not updated. Reinstall?

TC

[torreydale]

It is compton related.  I unchecked compton in the Application Autostart tab of Session and Startup, rebooted, and the normal brightness returned.  I do need Compton for screen tearing.  The command line I had for application autostart was the following:

Code: [Select]

compton --backend glx --paint-on-overlay --glx-no-stencil --vsync opengl-swc

Can anyone recommend something different?

[m654321]

All the laptops I've mentioned are running the Compton compositor, if that makes any difference to those reading.  Perhaps there's a shadow-exclude setting in the compton.conf file that will make a difference.

I don't know if this helps, but I'm not running Compton on any of our setups in sig, and none of them have the dark display problem.
I have no idea if they're linked in your case, but might it be worth investigating, even if it's only to eliminate that possibility ..?

[torreydale]

All the laptops I've mentioned are running the Compton compositor, if that makes any difference to those reading.  Perhaps there's a shadow-exclude setting in the compton.conf file that will make a difference.

[m654321]

re-edited reply #22

[m654321]

I figured as I run updates, the problem would just reappear, so I actually didn't stay with the restore point.  I bring up the restore point to demonstrate that the issue, in my opinion, is software related.  The hardware has remained constant.  The only variable is the updates.

But the problem might not reappear, when #121 or higher becomes available, that's of course if it really is a kernel issue with #120.

From what you said above, the obvious question is if you didn't use the restore point to reset your system to sometime before the #120 release, were you still able restore the brightness control ? If you were able to get the brightness working, how did you achieve it (useful to know for others who might also be stuck on this problem) ?

[torreydale]

I figured as I run updates, the problem would just reappear, so I actually didn't stay with the restore point.  I bring up the restore point to demonstrate that the issue, in my opinion, is software related.  The hardware has remained constant.  The only variable is the updates.

[m654321]

Lenovo Thinkpad x250 (mine)
Lenovo Thinkpad x260 (friend/coworker)
Dell Latitude e6430 (mine)
All with Intel Integrated Graphics.  All working fine prior to last week.

Out of curiosity, I had a look on the net: the first two PCs are only 2-3 years old, your own laptop 5 years, so the first two are relatively new.
Thankfully, you had the restore point to go back to.  Maybe better to stay at kernel 4.4.0-97 #119 until #121 or higher is released & then try
the upgrade again. Hopefully, if you bypass #120 with other updates, your screen brightness will work again...

After you started this thread, I tried updating my 10-year-old Dell Latitude D630 from #119 to #120, but it would'nt install #120,
as I mentioned previously in reply #1.

 

[TheDead]

Could it be "stuck" on a brightness level thats too low?
Since they're all Intel chipset maybe trying the "Fix Brightness Control on Intel Chipsets" like I mentionned in the other thread :
https://itsfoss.com/fix-brightness-ubuntu-1310/

Just in case it's related, I also have the DELL e6430 at work right now. It's on Win7 x64 but it also has a Quadro card (two video cards). I didn't check if this is standard for the model...

Cheers!

[trinidad]

I can relate to your pain over you mother's situation. My mom is 85 and a 150 miles away, and my sister just bought her a new Windows 10 box. I expect some travel time in the very near future.

TC

[torreydale]

@Jerry,

I did try 4.10 and 4.13 to no avial.  I had a similar dark display problem with a friend's Toshiba laptop.  I mentioned it here: https://www.linuxliteos.com/forums/other/brightness-keys/msg35028/#msg35028.  But in the case of that laptop, things were so dark I could barely see anything, and it was not responding to brightness keys at all.  Mysteriously, when I was about to do similar things suggested by @trinidad and @m654321 on that laptop, it got better on its own.  It did show the problem very early on after installing Linux Lite 3.6, however.  Like the same day I installed Linux Lite 3.6, I noticed the darkness and no response to brightness keys issue on that laptop. 

My Dell e6430 had been running Linux Lite 3.x for months--at least since April 2017--without this issue until last week.  The Thinkpad x250 that I have had been running Linux Lite 3.x for 5 weeks (as long as I've had it) without this issue until last week.  A friend/coworker noticed the same thing with his Thinkpad x260, which had been running Linux Lite 3.x for 2 months without this issue until last week. 

As a test I reverted the Dell e6430 to a restore point from last month, the Thinkpad x250 to a restore point from Sep 9, 2017, and the Thinkpad x260 to a restore point from a few weeks ago.  The problem was not evident in the restore point environments for either of those devices.  In the current update state for each device, it is.

I hope whatever mysteriously caused this inconvenience will go away as mysteriously.  I'd barely be willing to do what is listed in the links provided by @trinidad and @m654321 for myself.  And I wouldn't even recommend Linux to anyone if the fix had to be as involved for the user as what is suggested in those links.  It's not son friendly trying to solve this remotely, and it isn't mother friendly at all.  Alas, my mother is still on Linux Lite 2.x.  Hopefully she is not seeing this issue.

[Jerry]

Does using one of our custom kernels affect the outcome?

[m654321]

Respectfully as I am only moderately skilled in this area, I would reiterate that it is indeed hardware specific especially where the laptops are concerned, and even sometimes firmware specific, but I think it may also be praxis specific because it can involve systemd and work habits on certain machines, such as shutting down from hibernation or suspend, or hard resetting before an update, or after a failed update...
TC compatibility issues can be.

I think you describe very well how complicated compatibility issues can be
Thankfully, I've never had any compatibility issues with LL on all four of our laptops (in sig) - luck of the draw I guess, as well as the way  LL has been crafted by Jerry and the team ...

[trinidad]

Respectfully as I am only moderately skilled in this area, I would reiterate that it is indeed hardware specific especially where the laptops are concerned, and even sometimes firmware specific, but I think it may also be praxis specific because it can involve systemd and work habits on certain machines, such as shutting down from hibernation or suspend, or hard resetting before an update, or after a failed update. It can involve all or several different hardware specifics which is why I posted the Arch page. I am certain the problem exhibits a variety and often even a combination of factors, including hardware specific issues,  BIOS ACPI issues, kernel updates, and so forth. I expect this to turn out to be an user instance specific bug with no specific uniform solution. I do not see an across the board solution, other than tuning specific hardware, firmware, software, and praxis to solve the issue on a user by user basis. I have six different boxes on the #120 kernel after this afternoon and none of them exhibits an issue. I expect this to keep coming up in laptops for a while, but at this point I honestly don't think the kernel is flawed. I can only add one instance, and it is not negative. When I updated to #120 on my oldest Dell laptop the screen brightness control keys which had never worked previously worked perfectly afterwards. If there's a fluke on some hardware new keyboard recognition sources may be the cause.

TC