Bug 92961

LED backlight: do you mean the LCD panel's backlight?

And the problem is not that it doesn't adjust according to your request but unstable?

(In reply to Aaron Lu from comment #1)
> LED backlight: do you mean the LCD panel's backlight?

Yes, it is LCD LED backlight; The thing is the light is (how to say that) "shaking" but very fast so it is not visible directly but very tiring for eyes;  I am not sure it is flicker cause I have 100% backlight level; I can adjust backlight level but even in 100% the light shaking is taking place :( 

I am not pretty sure how to test(debug) the issue more deeply so if you need more detailed information let me know

Do you have Windows installed? We need to know if this is a software issue or a hardware one first.

(In reply to Aaron Lu from comment #4)
> Do you have Windows installed? We need to know if this is a software issue
> or a hardware one first.

I have Manjaro Linux installed;

I mean if you have Windows, then you can see how it behaves under Windows. Never mind, it appears you don't.

Anyway, it feels more like a hardware issue or perhaps a GPU driver one. The backlight driver is only responsible for setting different backlight levels and nothing more.

(In reply to Aaron Lu from comment #6)
> I mean if you have Windows, then you can see how it behaves under Windows.
> Never mind, it appears you don't.
> 
> Anyway, it feels more like a hardware issue or perhaps a GPU driver one. The
> backlight driver is only responsible for setting different backlight levels
> and nothing more.

I just want to ask may the light shaking take place cause of 4GB of RAM (the non-PAE) which are represented by 2 RAMs as 2GB + 2GB? I heard (somewhere on youtube) that sometimes that may couse backlight shaking (?or flicker I am not sure) cause or the RAM sticks are in two different ports? So, as a "solution", one RAM stick should be physically unplugged? I don't know is it really true info... so could you give me a tip concerning that idea?

And concerning the GPU how to know it is really the GPU issue? I have Intel HD Graphics video card

(In reply to Ghry from comment #7)
> (In reply to Aaron Lu from comment #6)
> > I mean if you have Windows, then you can see how it behaves under Windows.
> > Never mind, it appears you don't.
> > 
> > Anyway, it feels more like a hardware issue or perhaps a GPU driver one.
> The
> > backlight driver is only responsible for setting different backlight levels
> > and nothing more.
> 
> I just want to ask may the light shaking take place cause of 4GB of RAM (the
> non-PAE) which are represented by 2 RAMs as 2GB + 2GB? I heard (somewhere on
> youtube) that sometimes that may couse backlight shaking (?or flicker I am
> not sure) cause or the RAM sticks are in two different ports? So, as a
> "solution", one RAM stick should be physically unplugged? I don't know is it
> really true info... so could you give me a tip concerning that idea?

No idea about this. Worth a try.

> 
> And concerning the GPU how to know it is really the GPU issue? I have Intel
> HD Graphics video card

Jani, is it possible that software defects can cause the backlight appear un-stable?

(In reply to Aaron Lu from comment #8)
> (In reply to Ghry from comment #7)
> > (In reply to Aaron Lu from comment #6)
> > > I mean if you have Windows, then you can see how it behaves under
> Windows.
> > > Never mind, it appears you don't.
> > > 
> > > Anyway, it feels more like a hardware issue or perhaps a GPU driver one.
> The
> > > backlight driver is only responsible for setting different backlight
> levels
> > > and nothing more.
> > 
> > I just want to ask may the light shaking take place cause of 4GB of RAM
> (the
> > non-PAE) which are represented by 2 RAMs as 2GB + 2GB? I heard (somewhere
> on
> > youtube) that sometimes that may couse backlight shaking (?or flicker I am
> > not sure) cause or the RAM sticks are in two different ports? So, as a
> > "solution", one RAM stick should be physically unplugged? I don't know is
> it
> > really true info... so could you give me a tip concerning that idea?
> 
> No idea about this. Worth a try.
> 

Emm... I am not sure concerning the two RAM sticks causes flicker(flashing) eihter but I think if unplugging one of RAM sticks really helps maybe this is GPU fixing issue cause of some framebuffer or similar cache things; But I repeat I am not sure about that so if someone has some somilar expirience please share some tips :)

Please attach dmesg from boot with drm.debug=14 module parameter set and /sys/kernel/debug/dri/0/i915_opregion

Aaron, it's possible a BYT has a backlight other than the SoC PWM. Might be a bad interaction between the two.

@Jani Nikula

OK... I have generated debug file with "dmesg drm.debug=14 > dmesg.log" and copied the /sys/kernel/debug/dri/0/i915_opregion (see attachment)

Created attachment 167021 [details]
dmesg drm.debug=14

Created attachment 167031 [details]
i915_opregion

@Jani Nikula
Did I (In reply to Jani Nikula from comment #10)
> Please attach dmesg from boot with drm.debug=14 module parameter set and
> /sys/kernel/debug/dri/0/i915_opregion
> 
Is the dmesg log correct? I am not sure concerning the param as drm.debug=14 so if I missed something please guide me

(In reply to Ghry from comment #14)
> @Jani Nikula
> Did I (In reply to Jani Nikula from comment #10)
> > Please attach dmesg from boot with drm.debug=14 module parameter set and
> > /sys/kernel/debug/dri/0/i915_opregion
> > 
> Is the dmesg log correct? I am not sure concerning the param as drm.debug=14
> so if I missed something please guide me

No, I'd like to see the full dmesg all the way from boot to the problem. Please increase log buffer size with e.g. log_buf_len=4M kernel parameter as necessary.

@Jani Nikula

OK, I've added the drm.debug=14 to the grub menu :) Now I attached the generated dmesg log file please see it

Created attachment 168191 [details]
dmesg generated with the grub param as "drm.debug=14"

@Jani Nikula

Any news? I am a bit confused concerning the : 

------
[    0.236595] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
------
or
------
[    0.322832] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
------
Anyways, I am not sure what exactly causes the flashing so please guide me

(In reply to Ghry from comment #18)
> @Jani Nikula
> 
> Any news? I am a bit confused concerning the : 
> 
> ------
> [    0.236595] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
> ------

This is harmless, see here if you are interested:
http://lxr.free-electrons.com/source/drivers/acpi/osl.c#L104

> or
> ------
> [    0.322832] PCI: Using host bridge windows from ACPI; if necessary, use
> "pci=nocrs" and report a bug
> ------

This means the PCI is using information from ACPI tables, which is pretty common for x86 systems.

Unfortunately no news, I don't see anything particularly wrong with the dmesg.

Ghry,

Does the problem occur before you boot into OS?

@Aaron Lu
No, the problem occur during all notebook working time; I am using Arch based Manjaro OS; Sometimes people really complain the eyes strain usign the OS so my case is not unique...
I have 100% backlight level to avoid flicker or similar but the micro-flashing is still taking place; I'd really like to make possible to catch what really causes the effect but unfortunally I am not sure "how to do" that :( 

So please if you have any idea do share some tips

If this happens even before you boot into an OS, e.g. in grub or BIOS setup etc., that probably means it is a hardware defect.

I want to point that in the BIOS mode it seems to work more clear; So how to find out more about it? And what about the PWM? How to check is it working correctly for example?

Does it help if you boot with nomodeset kernel command line parameter?

If yes, it might be helpful to get intel_reg_dumper output for both the normal case and the nomodeset case. It's a tool in intel-gpu-tools package http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/

@Jani Nikula
OK here is the normal intel_reg_dumper output (see attachment)

Created attachment 169161 [details]
intel_reg_dumper in normal mode

...and the nomodeset one (see attachment);
p.s during nomodeset boot xserver failed so the console mode was enabled only :(

Created attachment 169191 [details]
intel_reg_dumper with nomodeset grub param

(In reply to Ghry from comment #28)
> ...and the nomodeset one (see attachment);
> p.s during nomodeset boot xserver failed so the console mode was enabled
> only :(

I don't really care about X, I'm interested in knowing if there was a difference in the flicker/flashing between normal and nomodeset.

Emm... I guess I have some issue in nomodeset case too; I took photo during pencil test (please see attachment)

Created attachment 169201 [details]
boot in nomodeset - pencil test - the lines

If the reg dumps are correct, there's no difference in any of the backlight related registers.

@Jani Nikula
I have Intel HD Graphics (the Bay Trail) video card; So is there a way to catch exactly what causes the effect cause eyes strain is really taking place? Please guide me

Oh damn, I'm sorry, I forgot intel_reg_dumper does not support Baytrail, and I only looked at the diff between the dumps. I'll have to ask you to do the dumps again using tools/quick_dump/quick_dump.py. Maybe that'll give us the clues.


I think there's two likely scenarios here.

1) There's a bug in our backlight code that causes the flicker. (Duh.)

2) That's just the way backlight is on your machine. Some people are more sensitive to it than others. It's usually safe to assume that if the box came with Windows and you see the problem with that, there's not much we can do in Linux. To an extent, if your BIOS screen shows the problem as well, the conclusion is the same.

Even in case #2 it *might* sometimes be possible to increase the backlight modulation frequency to reduce flicker, but we generally don't want to do that because the OEM chose the frequency for the components in the machine, and in good faith I assume for good reasons.

Nice explanation, thanks Jani!

@Jani Nikula

(In reply to Jani Nikula from comment #35)
> Oh damn, I'm sorry, I forgot intel_reg_dumper does not support Baytrail, and
> I only looked at the diff between the dumps. I'll have to ask you to do the
> dumps again using tools/quick_dump/quick_dump.py. Maybe that'll give us the
> clues.
> 
> 
> I think there's two likely scenarios here.
> 

I've never done the dumps in this way so please give me detailed instructions please

@Jani Nikula
I mean how to do the dumps again using tools/quick_dump/quick_dump.py ? Please guide me

Exactly like in comment #25 and the dumps you provided, except use tools/quick_dump/quick_dump.py instead of intel_reg_dumper.

Frankly I do not know if distros package up-to-date igt or quick_dump.py, but you can use the repository I linked to.

@Jani Nikula
You mean this http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tools/quick_dump/quick_dump.py source? Should I compile it? I am not sure how to use it so please guide me

http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/README

@Jani Nikula

I tried the script running code: 

$python quick_dump.py

but there is exception as : 
----------
Traceback (most recent call last):
  File "quick_dump.py", line 19, in <module>
    import chipset
ImportError: No module named 'chipset' 
----------

Getting info concerning the chipset module as : 
$modinfo chipset
...outputs this error : 
---------
modinfo: ERROR: Module chipset not found.
---------

I am a bit confused about that :( Did I missed something? Please guide me

@Jani Nikula

Why do I get the exception? Give me a tip please

Frankly I don't know.

@Jani Nikula

Does it mean I have integrate the chipset module (re-compile kernel etc) or there is a workaround? Currently I am using a pre-compiled one

It refers to the python chipset module which is in the same directory as quick_dump.py. Did you run configure and make in the intel-gpu-tools top directory first; I think I failed to mention that, sorry.

I have intel-gpu-tools 1.9-1 installed so I have the "/usr/bin/chipset.py" and "/usr/bin/quick_dump.py" files... I really don't get it why I cannot run the quick_dump?  You mean I should do configure and compile write in the "/usr/bin" folder?

(In reply to Jani Nikula from comment #46)
> It refers to the python chipset module which is in the same directory as
> quick_dump.py. Did you run configure and make in the intel-gpu-tools top
> directory first; I think I failed to mention that, sorry.

I checked the chipset.py script; For some reason it always demands some _chipset module :( I don't see the _chipset module in the /usb/bin directory so I am much confused... Here is the /usr/bin/chipset.py and /usr/bin/quick_dump.py scripts (see attachments)

Created attachment 172021 [details]
the quick_dump.py script code

Created attachment 172031 [details]
the chipset.py script code

Ghry,

Is it possible to contact the vendor to make sure if this is a hardware issue?

(In reply to Aaron Lu from comment #51)
> Ghry,
> 
> Is it possible to contact the vendor to make sure if this is a hardware
> issue?

Thank you for your comment; Actually I have no idea is it really hardware issue or not? the vendor is asus :) I could hear there may be non-pae ram ports issue; I have another asus notebook asus K52F much like this one except the ram it is 2GB (one ram stick) and hdd is 300GB and it has windows xp pro but it work doesn't cause eyes strain at all though its backlight level is 100% :P So I am not sure concerning "hardware issue" but maybe the ram's sticks ports issue or similar?

I have downloaded the intel-gpu-tools sources; I am to compile it; So I'll try to report my results as soon as I can run its quick_dump.py script :) 

Currently I have pre-compiled intel-gpu-tools installed but for some reason its quick_dump.py throws the mentioed exceptions so I am to compile the recommended one...

I am a bit confused right now I can see the intel-gpu-tools requires dependencies as : 

        - gtk-doc-tools
	- libcairo2-dev
	- libdrm-dev
	- libpciaccess-dev
	- libpython3.3-dev
	- libunwind-dev
	- swig2.0
	- x11proto-dri2-dev
	- xutils-dev

I have module error every time I try to run the python3 script as : 
-----error text [begin]-----
Traceback (most recent call last):
  File "./quick_dump.py", line 17, in <module>
    import chipset
  File "/usr/local/bin/chipset.py", line 28, in <module>
    _chipset = swig_import_helper()
  File "/usr/local/bin/chipset.py", line 20, in swig_import_helper
    import _chipset
ImportError: No module named '_chipset'
------error text [end]-----

What lib exactly I am missing? Is it swig2.0 only or something else? I googled but the issue is quite specific as I can get it

Ghry, FWIW, I just posted patches to introduce a new unified non-python intel_reg tool that should work on all platforms. With that, you should be able to use the quick_dump register spec files with something like:

# intel_reg --spec=/path/to/intel-gpu-tools/tools/quick_dump dump

(In reply to Jani Nikula from comment #54)
> Ghry, FWIW, I just posted patches to introduce a new unified non-python

And the actual patch is http://patchwork.freedesktop.org/patch/47175/

@Jani Nikula
Thank you but if I must patch the existing intel-gpu-tools then for which version the patch is dedicated for? How to find out which intel-gpu-tools version is currently installed?

Current git.

@Jani Nikula
You mean this link http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/ goes to version 1.10 so the patch is for version 1.10? I am asking cause I am not sure what version I've installed cause I used the only link you recommended and now I am not sure I put attention which version it was :) 

Anyways I downloaded the intel-gpu-tools with this link "git://anongit.freedesktop.org/xorg/app/intel-gpu-tools" about 1 week ago so it is version 1.10?

You've got the link right, but it really does not make sense to talk about version numbers in reference to a git tree where people push new commits all the time...

As you can see from http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ there are tagged versions, but you can apply the patch on top of master.

@Jani Nikula

I have patched the today downloaded intel-gpu-tools "git://anongit.freedesktop.org/xorg/app/intel-gpu-tools" then compiled then installed; So I could input : 
------
"$sudo intel_reg --spec=/.../.../quick_dump/intel-gpu-tools/tools/quick_dump dump > quick_dump.log"
------
And, as I may suppose, I succeeded to start the quick_dump (see attachment)

Created attachment 174261 [details]
the quick_dump of patched intel-gpu-tools

@Jani Nikula

Any news?

(In reply to Jani Nikula from comment #25)
> Does it help if you boot with nomodeset kernel command line parameter?
> 
> If yes, it might be helpful to get intel_reg_dumper output for both the
> normal case and the nomodeset case. It's a tool in intel-gpu-tools package
> http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/

Ghry, so the idea with the register dumps was to compare the difference between nomodeset (which I assumed has no flicker, please confirm) and the normal case, so we could figure out what we do differently. Please provide those two dumps.

@Jani Nikula

Ok I got the idea; The previous quick dump was with no-nomodeset boot param; Now I boot my notebook with nomodeset boot param (though xserver fails every nomodeset boot so I have to use console only) and here is the nomodeset quick dump which was generated using "sudo intel_reg --spec=/.../.../quick_dump/intel-gpu-tools/tools/quick_dump dump > nomodeset_quick_dump0.log" (see attachment)

Created attachment 175861 [details]
nomodeset quick dump generated with the patched intel-gpu-tools

@Jani Nikula

Any news?
Attachment 174261 [details] is the quick dump in common xserver working mode; The attachment 175861 [details] is the quick dump in nomodeset mode; 

If you need some additional information please let me know

(In reply to Ghry from comment #66)
> Attachment 174261 [details] is the quick dump in common xserver working
> mode; The attachment 175861 [details] is the quick dump in nomodeset mode; 

Sorry, it's been a while. Please confirm that there was *no* flickering with nomodeset.

(In reply to Jani Nikula from comment #67)
> (In reply to Ghry from comment #66)
> > Attachment 174261 [details] is the quick dump in common xserver working
> > mode; The attachment 175861 [details] is the quick dump in nomodeset mode; 
> 
> Sorry, it's been a while. Please confirm that there was *no* flickering with
> nomodeset.

I am not sure concerning *there is no flickering* or flashing so I did my mobile phone photo during the pencil test; It shows the xserver failed info dialog but still I can see some moving "lines"; So please watch the photo I attach cause I am not sure is it flicker or so called flashing or ...

Created attachment 177281 [details]
photo which I made during the pencil test in nomodeset mode

@Jani Nikula

I am not sure but I guess there *is* flicker with nomodeset but still see  attachment 177281 [details] cause I am not sure is it really flicker, flashing or so called graphics artifacts :(

Ghry, well, my whole point with comparing the normal and nomodeset register dumps was that I assumed there would be no flicker with nomodeset, and I could compare the register values set by BIOS vs. our driver.

Since you reported the "backlight micro flashing, eyes strain" to begin with, I assumed you'd be able to tell the difference... I am not sure what we're hunting here... :(

I am not sure either but usually eyes strain is caused by flicker; But still maybe it is not exactly the flicker but lets call it the graphics artifacts (micro image shaking) or similar cause it is more hard to read texts than watch images for example; I do "suspect" that may be cause text is more thin so the graphics "shaking" is more feeling like with it? The double buffer and wrong DPI issue for example - how to check that?

p.s. I attached the BIOS photo taken during pencil test watch it please;

Created attachment 178191 [details]
photo which I made during the pencil test in BIOS mode

@Jani Nikula

I was looking to find similar of as you said "...what we are hunting for?" and maybe I could find a useful info here http://en.wikipedia.org/wiki/Moir%C3%A9_pattern which shows some kind of the effect? So how to know for sure if the "Morie pattern" effect really takes place? And is there an optimal way way to work it around?

...but I do think the flicker or/and artifacts take place a bit anyways so the test http://www.testufo.com/#test=ghosting shows that clearly (see attached image)

Created attachment 178911 [details]
graphics artifacts - the photo which I took during pencil test

@Jani Nikula

I understand the moire pattern is usually visible with camera but the thing is the LED seems like a bit shaking (flashing) so I think that causes the eyes strain actually that's why I asked about the PWM but still I am not sure the LED issue is the only reason; Maybe graphics artifacts are also take place or even more ones; Please give a tip how to analyse the reason(s)?

OK if graphics itself is fine the ACPI question is still takes place; Please see my original question which says I cannot insert asus_laptop kernel module; Any attempt to insert it causes output "modprobe: ERROR: could not insert 'asus_laptop': No such device"; 

I really not sure hot to debug the current running acpi (which is maybe not dedicated for notebooks or similar) so I just wanted to replace it with asus_laptop to see the difference, moreover, in fact I have exactly the asus notebook/laptop so the asus_laptop module must be able to integrated but I get the error? :( 

So please help me to debug my current running ACPI and if something is "not OK" do advise me a patch or some another module to use?

(In reply to Ghry from comment #78)
> OK if graphics itself is fine the ACPI question is still takes place; Please
> see my original question which says I cannot insert asus_laptop kernel
> module; Any attempt to insert it causes output "modprobe: ERROR: could not
> insert 'asus_laptop': No such device"; 

The "No such device" error means the module does not support your model.

> 
> I really not sure hot to debug the current running acpi (which is maybe not
> dedicated for notebooks or similar) so I just wanted to replace it with
> asus_laptop to see the difference, moreover, in fact I have exactly the asus
> notebook/laptop so the asus_laptop module must be able to integrated but I
> get the error? :( 

That's not for sure and depends on firmware support: if firmware doesn't expose the required methods than the module asus-laptop will not work.

> 
> So please help me to debug my current running ACPI and if something is "not
> OK" do advise me a patch or some another module to use?

I still suspect this is a hardware issue, I asked if it is possible to test Windows to see if it is the same problem there but since you don't have Windows, that's not possible. Now I think you can contact your vendor to make sure if this is a hardware issue, especially if you can also feels the "flashing" before you boot into the OS.

@Aaron Lu

I am not sure it is a hardware issue cause the notebook's graphics should pretty clear in windows mode, as I could hear that;

I just found the kernel-4.x has (pin controllers) Bay Trail support; So may the flashing be caused by some clock issue (I have 60Hz clock right now but seems like EDID says it should be 77Hz); or maybe that a video card incorrect refresh rate? 


-------xrandr-------
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
eDP1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 344mm x 193mm
   1366x768      60.02*+
   1024x768      60.00  
   800x600       60.32    56.25  
   640x480       59.94  
----------------------

-------EDID-----------
...
EDID version: 1.4
> Digital display
> 6 bits per primary color channel
> Digital interface is not defined
> Maximum image size: 34 cm x 19 cm
> Gamma: 2.20
> Supported color formats: RGB 4:4:4
> First detailed timing is preferred timing
> Established timings supported:
> Standard timings supported:
> Detailed mode: Clock 77.000 MHz, 344 mm x 193 mm
>                1366 1382 1398 1628 hborder 0
>                 768  771  785  788 vborder 0
>                -hsync -vsync
> Manufacturer-specified data, tag 15
> ASCII string: AUO
...
----------------------

and to have 77Hz clock instaed of 60Hz should I have PWM module enabled? Please guide me;

I'm sorry, but I have no knowledge of graphics card. The ACPI/Power-Video category here tracks issues related to backlight(i.e. backlight up/down adjustment through hotkey or sysfs interface), your problem sounds more like graphics related, so I'll move this bug to that category.

Concerning the backlight... I just tried kernel 3.18.18 and it seems to work more or less better than the previous 3.16 but the thing is after awake (post suspend) the backlight turns off :( OS is on but backlight is switched off; How to fix that in the most optimal way?

Your backlight issue is now tracked in bug #103371, I'll close this bug.