Bug 98111

Example of messages when these keys (light up and light down) are pressed, when i had the problem :

May  9 15:44:08 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140926/nsarguments-95)
May  9 15:44:09 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140926/nsarguments-95)
May  9 15:44:09 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140926/nsarguments-95)
May  9 15:44:09 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140926/nsarguments-95)
May  9 15:44:09 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140926/nsarguments-95)
May  9 15:44:09 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140926/nsarguments-95)
May  9 15:44:09 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140926/nsarguments-95)
May  9 15:44:09 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140926/nsarguments-95)
May  9 15:44:09 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140926/nsarguments-95)
May  9 15:44:09 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140926/nsarguments-95)
May  9 15:44:10 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140926/nsarguments-95)

acpidump please:
# acpidump > acpidump.txt

When you do not add the acpi_osi kernel cmdline, please list:
# ls /sys/class/backlight
intel_backlight (perhaps some other directories)

and please go into the directories and set brightness manually to see if it has an effect:
# cd intel_backlight
# cat max_brightness
1000
# echo 500 > brightness
# echo 700 > brightness
...

And please use acpi_listen to see if any event is printed when you pressed the backlight related hotkeys.

OK, So :

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.18.13-calculate root=UUID=abd128ba-4319-45ec-a984-caa4d1c459a2 ro zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=30 video=1920x1080 real_resume=UUID=e66325a1-e36f-4690-b16b-894c83693985 elevator=cfq calculate=video:intel splash quiet

# ls /sys/class/backlight
intel_backlight

# ls /sys/class/backlight/intel_backlight/
actual_brightness  bl_power  brightness  device  max_brightness  power  subsystem  type  uevent

cat /sys/class/backlight/intel_backlight/max_brightness 
4882

echo 500 > /sys/class/backlight/intel_backlight/brightness
==> Brightness is set to 10% (and i have the KDE notification)


echo 700 > /sys/class/backlight/intel_backlight/brightness
==> Brightness is set to 14% (and i have the KDE notification)

acpidump and acpi_listen : command not found. I search

Created attachment 176581 [details]
The acpidump.txt file (from sys-power/pmtools ebuild)

acpi_listen, i found it into the  ebuild.

Keyboardbrightness, when up and down (but don't work) :
 PNP0C14:01 000000ff 00000000
 PNP0C14:01 000000ff 00000000

The screen brighness, acpi_listen print nothing.

A function which work, for example power off and on the screen :
 PNP0C14:01 000000ff 00000000
^@video/displayoff DOFF 00000089 00000000 K
 PNP0C14:01 000000ff 00000000

Thanks

Did you try a more up2date kernel, say v4.0?

Created attachment 176781 [details]
Debug patch to see what happened

Please apply this debug patch on top of latest Linus' tree and then attach its dmesg after boot, thanks.

I am going to try the kernel 4.0.

I see your debug patch, but, can I apply it on my kernel ? (I don't know, sorry)

Hi,

I am testing the 4.0.2 kernel.

acpi_listen say :
 PNP0C14:01 000000ff 00000000
video/brightnessdown BRTDN 00000087 00000000 K
video/brightnessdown BRTDN 00000087 00000000
 PNP0C14:01 000000ff 00000000
video/brightnessdown BRTDN 00000087 00000000 K
video/brightnessdown BRTDN 00000087 00000000


But, There are a lot of time between the key down and the brightness down.

I press Fn+F5, and the screen brightness down 30 seconds after.
acpi_listen write in the console when the brightness down.

I have the same comportment with other hotkeys (the 30 seconds delay) : sound, play, stop, next track, poweroff screen....

I attach the acpidump and dmesg with 4.0.2 kernel without acpi_osi parameter.

Created attachment 176801 [details]
acpidump on 4.0.2 kernel without acpi_osi

Created attachment 176811 [details]
dmesg on 4.0.2 kernel without acpi_osi

Oh, yes a detail.

It works almost perfectly.

Sound example : Fn+F11 to low sound, it works. If I let down the Fn button, and press several times F11 to low again, all works.

But, with Brightness, If I press Fn+F5 to low brightness it works. But, If I release the 2 buttons and press on the two again, no problem. It is slower if I let down the Fn key and I press F5 several times to lower the screen brightness. Therefore, the sound or other hotkey pressed after react seconds later.

Created attachment 176841 [details]
dmesg with kernel 3.18.3 patched as requested (patch -p1 < kernel.patch)

(In reply to Adrien D from comment #12)
> Oh, yes a detail.
> 
> It works almost perfectly.
> 
> Sound example : Fn+F11 to low sound, it works. If I let down the Fn button,
> and press several times F11 to low again, all works.
> 
> But, with Brightness, If I press Fn+F5 to low brightness it works. But, If I
> release the 2 buttons and press on the two again, no problem. It is slower
> if I let down the Fn key and I press F5 several times to lower the screen
> brightness. Therefore, the sound or other hotkey pressed after react seconds
> later.

Do you have Windows and if it has the same behaviour?

(In reply to Adrien D from comment #13)
> Created attachment 176841 [details]
> dmesg with kernel 3.18.3 patched as requested (patch -p1 < kernel.patch)

From the dmesg, looks like ACPICA failed to properly evaluate _Q0E and _Q0F control methods which are responsible for delivering backlight events for some reason.
From your description, this doesn't seem to be the case on later kernels any more?

(In reply to Aaron Lu from comment #14)
> (In reply to Adrien D from comment #12)
> > Oh, yes a detail.
> > 
> > It works almost perfectly.
> > 
> > Sound example : Fn+F11 to low sound, it works. If I let down the Fn button,
> > and press several times F11 to low again, all works.
> > 
> > But, with Brightness, If I press Fn+F5 to low brightness it works. But, If
> I
> > release the 2 buttons and press on the two again, no problem. It is slower
> > if I let down the Fn key and I press F5 several times to lower the screen
> > brightness. Therefore, the sound or other hotkey pressed after react
> seconds
> > later.
> 
> Do you have Windows and if it has the same behaviour?

I have Windows, but it works perfectly on this system. I don't have the problem I have described for Linux.

(In reply to Aaron Lu from comment #15)
> (In reply to Adrien D from comment #13)
> > Created attachment 176841 [details]
> > dmesg with kernel 3.18.3 patched as requested (patch -p1 < kernel.patch)
> 
> From the dmesg, looks like ACPICA failed to properly evaluate _Q0E and _Q0F
> control methods which are responsible for delivering backlight events for
> some reason.
> From your description, this doesn't seem to be the case on later kernels any
> more?

In the kernel 4.0 It works, not perfectly, but it works. So I think as you this doesn't seem to be the case on later kernels.

OK, thanks for the info.
So the problem now is that after you press the backlight hotkey, the event is delivered later than expected, right?

(In reply to Aaron Lu from comment #18)
> OK, thanks for the info.
> So the problem now is that after you press the backlight hotkey, the event
> is delivered later than expected, right?

Yes, in the 4.0 kernel; but, it's not easier.
I made several tests.

- I pressed Fn+F5 once : the brightness decreases : OK
- I pressed Fn+F5, I keep the Fn key pressed and pressed again F5 to decrease again the brightness : the event is considered thirty seconds later (about). In this case, between the first and second action, if I send an other hotkey, (for example, mute sound), the sound is muted after the second event realized.
- I pressed Fn+F5, the brighness decreases, and I release Fn and F5, I wait 2 or 3 seconds and I press again this hotkey (Fn+F5) : all works perfectly.

Note: It's difficult for me to describe my problem in english, because I am french and it's very technical ! I hope you understand me :)

I forgot ...
- On kernel 3.18.13, without acpi_osi parameter set to !Windows 2012, only Fn+F6 and Fn+F6 don't work. The rest is okay.
- On kernel 3.18.13, with acpi_osi parameter set to !Windows 2012, Fn+F5 and Fn+F6 work but, the desktop environment (KDE for me) don't know I changed the % of brightness (The battery applet show me the same % level)

Should be a EC problem.

Lv,
Please take a look at this, thanks.

Hi Aaron,

What do i have to look ?

Hi,

So can you try this:
Setting EC_FLAGS_QUERY_HANDSHAKE to 1 in drivers/acpi/ec.c and try again to see if the bug can be fixed.

Thanks
-Lv

Adrien,

Can you please also test v3.19 without any kernel cmdline options and other settings, just plain v3.19? Thanks.

Courtesy to Lv, he found why v3.18 doesn't deliver the notify events:

        Method (_Q0E, 0, NotSerialized)  // _Qxx: EC Query
        {
            SBRN ()
            .... ....
        }

        Method (SBRN, 0, Serialized)
        {
            If (^^^GFX0.PRST ())
            {
                Local0 = ^^^GFX0.GCBL (^^^GFX0.CBLV)
                Local1 = (0x0A - Local0)
                If ((Local1 != LBTN))
                {
                    LBTN = Local1
                }
            }
        }

                Method (GCBL, 1, NotSerialized)
                {
                    Local0 = Zero
                    Arg0 &= 0x7FFFFFFF
                    While ((Local0 < 0x0A))
                    {
                        Local1 = DerefOf (Index (PCTG, Local0))
                        Local2 = DerefOf (Index (PCTG, (Local0 + One)))
                        If (((Arg0 <= Local1) && (Arg0 > Local2)))
                        {
                            Break
                        }

                        Local0++
                    }

                    Return (Local0)
                }

            Device (GFX0)
            {
                Name (_ADR, 0x00020000)  // _ADR: Address
                OperationRegion (VSID, PCI_Config, Zero, 0x04)
                Field (VSID, ByteAcc, NoLock, Preserve)
                {
                    REG0,   32
                }

                Name (PCTG, Package (0x0B) {})
                .... ....
            }

PCTG is declared as an empty package and its elements are assigned in _BCL. In win8 mode, we will not register ACPI video interface so we do not call _BCL and then PCTG is accessed in GCBL, ACPICA will report exception and abort the whole _Q0E control method. From v3.19, we will unconditionally execute _BCL due to some other problem:

commit dce4ec2e452fddb7542b5fc15d0e6b8531f6d5eb
Author: Aaron Lu <aaron.lu@intel.com>
Date:   Tue Oct 28 14:35:59 2014 +0800

    ACPI / video: Run _BCL before deciding registering backlight

I believe the above commit made kernels later than v3.19 starts to send events for this machine.

(In reply to Lv Zheng from comment #23)
> Hi,
> 
> So can you try this:
> Setting EC_FLAGS_QUERY_HANDSHAKE to 1 in drivers/acpi/ec.c and try again to
> see if the bug can be fixed.
> 
> Thanks
> -Lv

7 [08:08:55] adrien@superlinux: /usr/src/linux-3.18.13-calculate  $ grep -r EC_FLAGS_QUERY_HANDSHAKE drivers/acpi/ec.c
static int EC_FLAGS_QUERY_HANDSHAKE; /* Needs QR_EC issued when SCI_EVT set */
                if (EC_FLAGS_QUERY_HANDSHAKE &&
        EC_FLAGS_QUERY_HANDSHAKE = 1;

It's already set to 1, on the 3.18.13 kernel but it doesn't work without additional parameter set to the kernel

It is only set for the specific machine.
You should modify this line:
static int EC_FLAGS_QUERY_HANDSHAKE;
to
static int EC_FLAGS_QUERY_HANDSHAKE = 1;
And try again.

Thanks
-Lv

(In reply to Lv Zheng from comment #27)
> It is only set for the specific machine.
> You should modify this line:
> static int EC_FLAGS_QUERY_HANDSHAKE;
> to
> static int EC_FLAGS_QUERY_HANDSHAKE = 1;
> And try again.
> 
> Thanks
> -Lv

grep EC_FLAGS_QUERY_HANDSHAK drivers/acpi/ec.c 
static int EC_FLAGS_QUERY_HANDSHAKE = 1; /* Needs QR_EC issued when SCI_EVT set */
                if (EC_FLAGS_QUERY_HANDSHAKE &&
        EC_FLAGS_QUERY_HANDSHAKE = 1;

 On kernel 3.18.13.
I rebooted on it.

Hotkeys don't work.

May 18 08:24:38 superlinux kernel: ACPI Error: Method parse/execution failed [\x5c_SB_.PCI0.GFX0.GCBL] (Node ffff880225
c35eb0), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) 
May 18 08:24:38 superlinux kernel: ACPI Error: Method parse/execution failed [\x5c_SB_.PCI0.LPCB.EC0_.SBRN] (Node ffff8
80225c47438), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) 
May 18 08:24:38 superlinux kernel: ACPI Error: Method parse/execution failed [\x5c_SB_.PCI0.LPCB.EC0_._Q0E] (Node ffff8
80225c47460), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) 
May 18 08:24:39 superlinux kernel: ACPI Error: Method parse/execution failed [\x5c_SB_.PCI0.GFX0.GCBL] (Node ffff880225
c35eb0), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) 
May 18 08:24:39 superlinux kernel: ACPI Error: Method parse/execution failed [\x5c_SB_.PCI0.LPCB.EC0_.SBRN] (Node ffff8
80225c47438), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536) 
May 18 08:24:39 superlinux kernel: ACPI Error: Method parse/execution failed [\x5c_SB_.PCI0.LPCB.EC0_._Q0F] (Node ffff8
80225c47488), AE_AML_UNINITIALIZED_ELEMENT (20140926/psparse-536)

Adrien,

Please test on kernels on v3.19 or later, there is a known problem on v3.18 that the hotkey wouldn't work.

Hi, Adrien

Since this looks like the same issue caused by the EC_FLAGS_QUERY_HANDSHAKE, could you give the following patches a try?

Apply the following patches on the latest kernel:
1. attachment 177901 [details]
2. attachment 177911 [details]
3. attachment 177921 [details]

Thanks and best regards
-Lv

The above patch contains 1 line wrong.

Please try to:

1. apply the following patches:
   attachment 178011 [details]
   attachment 178021 [details]
   attachment 178031 [details]
2. build the kernel and try to see if things are improved.

Also we still need the bisection to root cause the issue.

Thanks in advance and sorry for the mistake..

Best regards
-Lv

Hi,

I am going to try this night.

I test on 4.0.4 ?

I'm working on linux-pm.git/linux-next branch.

For the linux.git/master branch, I think you should use v4.1-rc4 tag and apply the following 2 patches:
   attachment 178011 [details]
   attachment 178031 [details]
The other patch is a no-op and can be ignored.

Thanks and best regards
-Lv

I can't patch   attachment 178011 [details] 

patching file drivers/acpi/ec.c
Hunk #1 succeeded at 360 (offset -61 lines).
Hunk #2 succeeded at 396 with fuzz 2 (offset -61 lines).
Hunk #3 succeeded at 406 (offset -61 lines).
Hunk #4 FAILED at 475.
1 out of 4 hunks FAILED -- saving rejects to file drivers/acpi/ec.c.rej

Okay, I tested on 4.1.0-rc5, the patch works.

But I have no network connection.

I tested the brightness, but not work.
It don't work if i use the brightness applet of KDE (brighness keep to 100%)

May 27 21:26:58 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150204/nsarguments-95) 
May 27 21:26:58 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150204/nsarguments-95) 
May 27 21:26:58 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150204/nsarguments-95) 
May 27 21:26:58 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150204/nsarguments-95) 
May 27 21:26:58 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150204/nsarguments-95) 
May 27 21:26:58 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150204/nsarguments-95) 
May 27 21:26:58 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150204/nsarguments-95) 
May 27 21:26:58 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150204/nsarguments-95) 
May 27 21:26:58 superlinux kernel: ACPI Warning: \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150204/nsarguments-95)

May 27 21:29:13 superlinux sudo[9019]: pam_ldap: missing file "/etc/ldap.conf" 
May 27 21:29:13 superlinux sudo[9019]:   adrien : TTY=pts/1 ; PWD=/home/adriencl ; USER=root ; COMMAND=/usr/bin/tailf /var/log/messages 
May 27 21:29:13 superlinux sudo[9019]: pam_unix(sudo:session): session opened for user root by adrien(uid=0) 
May 27 21:29:24 superlinux sudo[9019]: pam_unix(sudo:session): session closed for user root 
May 27 21:29:26 superlinux sudo[10622]:   adrien : TTY=pts/1 ; PWD=/home/adriencl ; USER=root ; COMMAND=/bin/su 
May 27 21:29:26 superlinux sudo[10622]: pam_unix(sudo:session): session opened for user root by adrien(uid=0) 
May 27 21:29:26 superlinux su[10623]: pam_ldap: missing file "/etc/ldap.conf" 
May 27 21:29:26 superlinux su[10623]: Successful su for root by root 
May 27 21:29:26 superlinux su[10623]: + /dev/pts/1 root:root 
May 27 21:29:26 superlinux su[10623]: pam_unix(su:session): session opened for user root by adrien(uid=0) 
May 27 21:29:31 superlinux acpid[10892]: starting up with netlink and the input layer 
May 27 21:29:31 superlinux acpid[10892]: 1 rule loaded 
May 27 21:29:31 superlinux acpid[10892]: waiting for events: event logging is off 
May 27 21:30:01 superlinux cron[14165]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons) 
May 27 21:30:36 superlinux acpid[10892]: client connected from 17676[0:0] 
May 27 21:30:36 superlinux acpid[10892]: 1 client rule loaded 
May 27 21:30:38 superlinux logger[17801]: ACPI event unhandled: video/brightnessdown BRTDN 00000087 00000000 
May 27 21:30:58 superlinux acpid[10892]: client 17676[0:0] has disconnected 
May 27 21:31:11 superlinux logger[20391]: ACPI event unhandled: PNP0C14:01 000000ff 00000000 
May 27 21:31:11 superlinux logger[20394]: ACPI event unhandled: video/brightnessdown BRTDN 00000087 00000000 K 
May 27 21:31:11 superlinux logger[20396]: ACPI event unhandled: video/brightnessdown BRTDN 00000087 00000000 
May 27 21:31:34 superlinux kernel: SGI XFS with ACLs, security attributes, realtime, no debug enabled 
May 27 21:31:34 superlinux kernel: JFS: nTxBlock = 8192, nTxLock = 65536 
May 27 21:31:34 superlinux kernel: ntfs: driver 2.1.32 [Flags: R/W MODULE].

(In reply to Adrien D from comment #36)
> May 27 21:29:13 superlinux sudo[9019]: pam_ldap: missing file
> "/etc/ldap.conf" 
> May 27 21:29:13 superlinux sudo[9019]:   adrien : TTY=pts/1 ;
> PWD=/home/adriencl ; USER=root ; COMMAND=/usr/bin/tailf /var/log/messages 
> May 27 21:29:13 superlinux sudo[9019]: pam_unix(sudo:session): session
> opened for user root by adrien(uid=0) 
> May 27 21:29:24 superlinux sudo[9019]: pam_unix(sudo:session): session
> closed for user root 
> May 27 21:29:26 superlinux sudo[10622]:   adrien : TTY=pts/1 ;
> PWD=/home/adriencl ; USER=root ; COMMAND=/bin/su 
> May 27 21:29:26 superlinux sudo[10622]: pam_unix(sudo:session): session
> opened for user root by adrien(uid=0) 
> May 27 21:29:26 superlinux su[10623]: pam_ldap: missing file
> "/etc/ldap.conf" 
> May 27 21:29:26 superlinux su[10623]: Successful su for root by root 
> May 27 21:29:26 superlinux su[10623]: + /dev/pts/1 root:root 
> May 27 21:29:26 superlinux su[10623]: pam_unix(su:session): session opened
> for user root by adrien(uid=0) 
> May 27 21:29:31 superlinux acpid[10892]: starting up with netlink and the
> input layer 
> May 27 21:29:31 superlinux acpid[10892]: 1 rule loaded 
> May 27 21:29:31 superlinux acpid[10892]: waiting for events: event logging
> is off 
> May 27 21:30:01 superlinux cron[14165]: (root) CMD (test -x
> /usr/sbin/run-crons && /usr/sbin/run-crons) 
> May 27 21:30:36 superlinux acpid[10892]: client connected from 17676[0:0] 
> May 27 21:30:36 superlinux acpid[10892]: 1 client rule loaded 
> May 27 21:30:38 superlinux logger[17801]: ACPI event unhandled:
> video/brightnessdown BRTDN 00000087 00000000 
> May 27 21:30:58 superlinux acpid[10892]: client 17676[0:0] has disconnected 
> May 27 21:31:11 superlinux logger[20391]: ACPI event unhandled: PNP0C14:01
> 000000ff 00000000 
> May 27 21:31:11 superlinux logger[20394]: ACPI event unhandled:
> video/brightnessdown BRTDN 00000087 00000000 K 
> May 27 21:31:11 superlinux logger[20396]: ACPI event unhandled:
> video/brightnessdown BRTDN 00000087 00000000 

This looks to me like:
With the Windows 2012 _OSI, brightness change should be done in the following style:
1. user presses brightness keys.
2. event is sent to the userspace
3. userspace should take care of change the brightness (possibly via graphics driver functionaility).

Anyway, it seems the patch works.
And there is a gap that the userspace cannot handle the event.

Thanks and best regards
-Lv

> May 27 21:31:34 superlinux kernel: SGI XFS with ACLs, security attributes,
> realtime, no debug enabled 
> May 27 21:31:34 superlinux kernel: JFS: nTxBlock = 8192, nTxLock = 65536 
> May 27 21:31:34 superlinux kernel: ntfs: driver 2.1.32 [Flags: R/W MODULE].

(In reply to Adrien D from comment #35)
> Okay, I tested on 4.1.0-rc5, the patch works.
> 
> But I have no network connection.
> 
> I tested the brightness, but not work.
> It don't work if i use the brightness applet of KDE (brighness keep to 100%)
> 
> May 27 21:26:58 superlinux kernel: ACPI Warning:
> \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer],
> ACPI requires [Package] (20150204/nsarguments-95) 
> May 27 21:26:58 superlinux kernel: ACPI Warning:
> \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer],
> ACPI requires [Package] (20150204/nsarguments-95) 
> May 27 21:26:58 superlinux kernel: ACPI Warning:
> \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer],
> ACPI requires [Package] (20150204/nsarguments-95) 
> May 27 21:26:58 superlinux kernel: ACPI Warning:
> \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer],
> ACPI requires [Package] (20150204/nsarguments-95) 
> May 27 21:26:58 superlinux kernel: ACPI Warning:
> \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer],
> ACPI requires [Package] (20150204/nsarguments-95) 
> May 27 21:26:58 superlinux kernel: ACPI Warning:
> \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer],
> ACPI requires [Package] (20150204/nsarguments-95) 
> May 27 21:26:58 superlinux kernel: ACPI Warning:
> \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer],
> ACPI requires [Package] (20150204/nsarguments-95) 
> May 27 21:26:58 superlinux kernel: ACPI Warning:
> \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer],
> ACPI requires [Package] (20150204/nsarguments-95) 
> May 27 21:26:58 superlinux kernel: ACPI Warning:
> \x5c_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer],
> ACPI requires [Package] (20150204/nsarguments-95)

This is not related to this bug, normally we handle such kind of issue in drivers/acpi/acpica/nspredef.c to keep OSPM interface as simple as possible.

Thanks and best regards
-Lv

With the patch applied, please re-do the acpi_listen test to find out if the event is correctly delivered without any delay.
Also, does the intel_backlight interface still work with the patched kernel(using the echo method)?

Hello,

 PNP0C14:01 000000ff 00000000
video/brightnessdown BRTDN 00000087 00000000 K
 PNP0C14:01 000000ff 00000000
video/brightnessdown BRTDN 00000087 00000000 K
 PNP0C14:01 000000ff 00000000
video/brightnessdown BRTDN 00000087 00000000 K
 PNP0C14:01 000000ff 00000000
video/brightnessdown BRTDN 00000087 00000000 K
 PNP0C14:01 000000ff 00000000
video/brightnessdown BRTDN 00000087 00000000 K
 PNP0C14:01 000000ff 00000000
video/brightnessup BRTUP 00000086 00000000 K
 PNP0C14:01 000000ff 00000000
video/brightnessup BRTUP 00000086 00000000 K
 PNP0C14:01 000000ff 00000000
video/brightnessup BRTUP 00000086 00000000 K

With acpi_osi on 4.1.0-rc5 : All works perfectly with kernel patched.
Without acpi_osi on 4.1.0-rc5 : Same comportment as Comment 19.

I tried with 4.0.4 without patchs and I have the same comportment (so i think your patch doesn't modify the comportment, just display more logs ?)

So let's first confirm if this is an EC issue.
Can you use 4.1.0-rc5 without applying any patches, but modify
static int EC_FLAGS_QUERY_HANDSHAKE;
to
static int EC_FLAGS_QUERY_HANDSHAKE = 1;
And try again?

Thanks and best regards
-Lv

And since you said nothing was abnormal on Windows.
Can you tell us the version of the Windows?

Thanks and best regards
-Lv

(In reply to Lv Zheng from comment #42)
> And since you said nothing was abnormal on Windows.
> Can you tell us the version of the Windows?
> 
> Thanks and best regards
> -Lv

I tested on Windows 7 Family (The Windows which is sold with the laptop)

(In reply to Lv Zheng from comment #41)
> So let's first confirm if this is an EC issue.
> Can you use 4.1.0-rc5 without applying any patches, but modify
> static int EC_FLAGS_QUERY_HANDSHAKE;
> to
> static int EC_FLAGS_QUERY_HANDSHAKE = 1;
> And try again?
> 
> Thanks and best regards
> -Lv

Okay, I do that.

acpi_listen 

video/brightnessdown BRTDN 00000087 00000000
 PNP0C14:01 000000ff 00000000
video/brightnessdown BRTDN 00000087 00000000 K
video/brightnessup BRTUP 00000086 00000000
 PNP0C14:01 000000ff 00000000
 PNP0C14:01 000000ff 00000000
video/brightnessup BRTUP 00000086 00000000
video/brightnessup BRTUP 00000086 00000000 K
video/brightnessdown BRTDN 00000087 00000000
video/brightnessup BRTUP 00000086 00000000 K


You can see the delay between each action in the logs :

May 28 08:47:28 superlinux logger[17925]: ACPI event unhandled: PNP0C14:01 000000ff 00000000
May 28 08:47:28 superlinux logger[17928]: ACPI event unhandled: video/brightnessdown BRTDN 00000087 00000000 K
May 28 08:47:28 superlinux logger[17931]: ACPI event unhandled: video/brightnessdown BRTDN 00000087 00000000

May 28 08:48:01 superlinux logger[21218]: ACPI event unhandled: PNP0C14:01 000000ff 00000000
May 28 08:48:01 superlinux logger[21222]: ACPI event unhandled: video/brightnessdown BRTDN 00000087 00000000 K
May 28 08:48:01 superlinux logger[21224]: ACPI event unhandled: video/brightnessdown BRTDN 00000087 00000000

(In reply to Adrien D from comment #40)
> With acpi_osi on 4.1.0-rc5 : All works perfectly with kernel patched.
> Without acpi_osi on 4.1.0-rc5 : Same comportment as Comment 19.
> 
> I tried with 4.0.4 without patchs and I have the same comportment (so i
> think your patch doesn't modify the comportment, just display more logs ?)

Let me explain this.
Hope you can perform proper and valid test after knowing the background.

A event query process is composed of 3 steps:
1. After seeing SCI_EVT interrupt indication, Linux EC driver writes QR_EC command to the EC command register
2. EC firmware reads QR_EC command and writes query value to the EC data register
3. Linux EC driver reads query value from the EC data register

Originally, Linux allows 2nd QR_EC command to be queued up after write the QR_EC command. This patch changes this behavior and the 2nd QR_EC command will only be allowed to be queued up after read the query value.

If EC firmware clears SCI_EVT interrupt indication before writing the query value and after reading the QR_EC command, The patch then can reduce the number of the queued up QR_EC.

If the machine requires the EC_FLAGS_QUERY_HANDSHAKE quirk (such platforms may refuse to respond QR_EC if SCI_EVT is not indicated, on which case, the driver can suffer from a transaction timeout), then this may avoid possible useless QR_EC from being sent and eliminate the delay.

But your test result can't persuade us that this patch can fit all the cases.

Thanks and best regards
-Lv

(In reply to Adrien D from comment #44)
> (In reply to Lv Zheng from comment #41)
> > So let's first confirm if this is an EC issue.
> > Can you use 4.1.0-rc5 without applying any patches, but modify
> > static int EC_FLAGS_QUERY_HANDSHAKE;
> > to
> > static int EC_FLAGS_QUERY_HANDSHAKE = 1;
> > And try again?
> > 
> > Thanks and best regards
> > -Lv
> 
> Okay, I do that.
> 
> acpi_listen 
> 
> video/brightnessdown BRTDN 00000087 00000000
>  PNP0C14:01 000000ff 00000000
> video/brightnessdown BRTDN 00000087 00000000 K
> video/brightnessup BRTUP 00000086 00000000
>  PNP0C14:01 000000ff 00000000
>  PNP0C14:01 000000ff 00000000
> video/brightnessup BRTUP 00000086 00000000
> video/brightnessup BRTUP 00000086 00000000 K
> video/brightnessdown BRTDN 00000087 00000000
> video/brightnessup BRTUP 00000086 00000000 K
> 
> 
> You can see the delay between each action in the logs :
> 
> May 28 08:47:28 superlinux logger[17925]: ACPI event unhandled: PNP0C14:01
> 000000ff 00000000
> May 28 08:47:28 superlinux logger[17928]: ACPI event unhandled:
> video/brightnessdown BRTDN 00000087 00000000 K
> May 28 08:47:28 superlinux logger[17931]: ACPI event unhandled:
> video/brightnessdown BRTDN 00000087 00000000
> 
> May 28 08:48:01 superlinux logger[21218]: ACPI event unhandled: PNP0C14:01
> 000000ff 00000000
> May 28 08:48:01 superlinux logger[21222]: ACPI event unhandled:
> video/brightnessdown BRTDN 00000087 00000000 K
> May 28 08:48:01 superlinux logger[21224]: ACPI event unhandled:
> video/brightnessdown BRTDN 00000087 00000000

Then we may need the EC debugging log to root cause.
Can you:
1. restore EC_FLAGS_QUERY_HANDSHAKE to none 1.
2. uncomment the following line in drivers/acpi/ec.c
/* #define DEBUG */
to
#define DEBUG
3. rebuild the kernel and retry.
4. boot the kernel and type dmesg -c to clear all boot logs.
5. do your brightness key press test to demonstrate the delay.
6. execute the following command to capture the kernel log of the test:
dmesg -c > brightness-delay0.dmesg.
7. upload the brightness-delay0.dmesg here for us to investigate.

Do another test with EC_FLAGS_QUERY_HANDSHAKE set to 1 and save the test result in brightness-delay1.dmesg, and upload the brightness-delay1.dmesg here.

Thanks in advance.

Best regards
-Lv

Hi, Adrien

I've fixed several issues in the previous patches.
Could you help to try again?

1. The patchset is based on the linux-pm.git/linux-next branch as I need some commits in that branch. So please git pull the following git:

   # git remote add linux-pm git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git 
   # git fetch linux-pm
   # git branch linux-pm-next linux-pm/linux-next
   # git checkout linux-pm-next

2. Apply the following patches:
   attachment 178641 [details]
   attachment 178651 [details]
   attachment 178661 [details]
   attachment 178671 [details]

3. Enable the EC debugging log:
   Uncomment the following line in drivers/acpi/ec.c
   /* #define DEBUG */
   to
   #define DEBUG

4. Rebuild the kernel

5. Try several SCI_EVT clearing approaches:
   1. Boot the kernel with acpi.ec_event_clearing=status, and do the test, save the dmesg to ec-status-dmsg.txt
   2. Boot the kernel with acpi.ec_event_clearing=query, and do the test, save the dmesg to ec-query-dmsg.txt
   3. Boot the kernel with acpi.ec_event_clearing=event, and do the test, save the dmesg to ec-event-dmsg.txt
   4. Boot the kernel with acpi.ec_event_clearing=method, and do the test, save the dmesg to ec-method-dmsg.txt

6. Upload the 4 dmesg logs here and tell us if you have met some problems with the trials.

IMO, "status" should still be broken for your platform, and all the other 3 modes should be working for your platform.

Thanks and best regards
-Lv

  attachment 178661 [details]
   attachment 178671 [details]

They don't work. I can't patch

superlinux linux-pm # patch -p1 < patch-178641.patch 
patching file drivers/acpi/ec.c
Hunk #1 succeeded at 386 (offset -5 lines).
Hunk #2 succeeded at 404 (offset -17 lines).
Hunk #3 succeeded at 441 (offset -17 lines).
Hunk #4 succeeded at 451 (offset -17 lines).
Hunk #5 succeeded at 459 (offset -17 lines).
superlinux linux-pm # patch -p1 < patch-178651.patch 
patching file drivers/acpi/ec.c
Hunk #1 succeeded at 873 (offset -31 lines).
Hunk #2 succeeded at 901 (offset -31 lines).
superlinux linux-pm # patch -p1 < patch-178661.patch 
patching file drivers/acpi/ec.c
Hunk #1 succeeded at 379 (offset -5 lines).
Hunk #2 succeeded at 390 (offset -5 lines).
Hunk #3 succeeded at 446 (offset -17 lines).
Hunk #4 succeeded at 465 (offset -17 lines).
Hunk #5 succeeded at 922 (offset -31 lines).
Hunk #6 FAILED at 1044.
1 out of 6 hunks FAILED -- saving rejects to file drivers/acpi/ec.c.rej
patching file drivers/acpi/internal.h
Hunk #1 FAILED at 139.
1 out of 1 hunk FAILED -- saving rejects to file drivers/acpi/internal.h.rej
superlinux linux-pm # patch -p1 < patch-178671.patch 
patching file drivers/acpi/ec.c
Hunk #2 succeeded at 136 with fuzz 2 (offset -7 lines).
Hunk #3 FAILED at 445.
Hunk #4 succeeded at 456 (offset -17 lines).
Hunk #5 succeeded at 484 (offset -17 lines).
Hunk #6 FAILED at 596.
Hunk #7 succeeded at 984 (offset -31 lines).
Hunk #8 succeeded at 1015 (offset -31 lines).
Hunk #9 succeeded at 1522 (offset 12 lines).
2 out of 9 hunks FAILED -- saving rejects to file drivers/acpi/ec.c.rej

It seems there may be multiple problems here, so
please test the Linux-4.1 kernel, as recently released:-)
and lets see what is still broken from that point forward.

There are some patches in linux-next that may help,
and so soon we'll have 4.2-rc to easily test those patches.

I tested kernel 4.1.1 and I have the same problem.

I must add acpi_osi="!Windows 2012" to work fine

The patch listed in comment 47 has been merged by upstream.
could you try a test using kernel 4.2-rc1 without acpi_osi="!Windows 2012" specified?
If you still have problems, please:

1. Enable the EC debugging log and rebuild the kernel:
   Uncomment the following line in drivers/acpi/ec.c
   /* #define DEBUG */
   to
   #define DEBUG
2. Perform the test and upload the dmesg here.

Thanks and best regards
-Lv

Same problem as comment 19 https://bugzilla.kernel.org/show_bug.cgi?id=98111#c19

Could you provide the dmesg with "#define DEBUG" uncommented in ec.c?
Thanks in advance.

Best regards
-Lv

Could you also take a look at bug 94411, see if this is a duplicate report and attachment 179201 [details] can help to fix this issue.

Thanks
-Lv

You can try recent upstream kernel where the patches are already shipped.
If the problem can still be observed, please feel free to re-open it.

Thanks
-Lv