On Mon, Aug 29, 2016 at 10:24:38AM +0300, Jani Nikula wrote: > If it's an Iybridge, there's no low vswing, and that explanation is > false. You can verify by trying i915.edp_vswing=1 or i915.edp_vswing=2 > on an unpatched kernel. What I should look for when trying those two settings? Will they successfully fix my problem with intel_backlight with upstream 4.8-rc? I thought it had to be the same issue as on skylake as I get the backlight flikering at low frequency but getting brighter and darker in a cycle lasting a few seconds and I thought there couldn't be too many other random bugs that ends up with the same side effect. It looks like the hardware actually broke, software issue isn't the first thing that comes to mind. As it's hard to imagine a timer in the kernel reprogramming the backlight setting higher and lower just to annoy me :). First in fact I thought at a plasma issue, but I tried to downgrade the kernel first as that was quicker than downgrading kde/plasma... I initially thought there were two userland daemons stepping into each other toes. Another thing is that if I keep decreasing the brightness the screen eventually goes off and it returns on as I increase the backlight level again (then low freq flickering starts). With acpi_video0 even at the lowest brightness setting of 0, it never turns off the screen completely. > Doesn't mean there can't be something else wrong with the mode you get > using a different panel_type. And this makes me wonder what the point is > in trying to patch up the commit instead of reverting. Reverting the whole thing would be sure fine with me, I don't know what the benefits there should be in using intel_backlight instead of acpi_video0 like the previous code did, but I couldn't imagine too many hw to behave like this if intel_backlight clearly has to work stable for someone or it wouldn't exist in the first place. This is just a "echo " into a backlight file if I tweak the backlight settings... doesn't sound performance critical stuff to me, ACPI will do just fine. However I'm not even sure how this problem could surface in the first place without the kernel continuously reprogramming the hw values. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
