Hi Artur,
於 六，2012-02-04 於 20:19 -0700，Joey Lee 提到：
> Add Cc. to dri mail
>
> Hi Pali,
>
> 於 五，2012-02-03 於 16:24 +0100，Pali Rohár 提到：
> > On Friday 20 January 2012 17:55:57 Pali Rohár wrote:
> > > On Friday 20 January 2012 11:28:59 joeyli wrote:
> > > > 於 五，2012-01-20 於 11:12 +0800，joeyli 提到：
> > > >
> > > > > Hi Pali,
> > > > >
> > > > > Sorry for I am late reply you.
> > > > >
> > > > > 於 二，2012-01-17 於 19:10 +0100，Pali Rohár 提到：
> > > > >
> > > > > > On Wednesday 21 December 2011 12:45:07 Pali Rohár wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > I tried to boot with all 3 strings in acpi_os_name, but nothing was
> > > > > > > changed. I'm attaching dmesg outputs, one from BIOS mode, one from
> > > > > > > UEFI mode. Both are with "Microsoft Windows NT".
> > > > > >
> > > > > > Did you looked at my logs?
> > > > >
> > > > > I checked your dmesg log, found the acpi_os_name kernel parameter is :
> > > > >
> > > > > [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-generic
> > > > > root=UUID=4ec6272a-8551-40f3-a1b1-3e10984f3e69 ro pcie_aspm=force
> > > > > acpi.debug_level=0x2 acpi.debug_layer=0xFFFFFFFF "acpi_os_name=Microsoft
> > > > > Windows NT" splash vt.handoff=7
> > > > >
> > > > > We still need by-pass the os name check in DSDT when test function key,
> > > > >
> > > > > please help to feed:
> > > > > acpi_os_name="Windows 2009"
> > > > >
> > > > > And,
> > > > > looks like the acpi debug level not enough, please kindly change acpi
> > > > >
> > > > > debug parameter to:
> > > > > acpi.debug_level=0xF acpi.debug_layer=0xFFFFFFFF log_buf_len=5M
> > > > >
> > > > > summary:
> > > > > acpi.debug_level=0xF acpi.debug_layer=0xFFFFFFFF log_buf_len=5M
> > > > > acpi_os_name="Windows 2009"
> > > >
> > > > Forgot remind,
> > > > please remember press brightness function key a couple of times before
> > > > you dump the dmesg and messages log.
> > > >
> > > >
> > > > Thanks a lot!
> > > > Joey Lee
> > >
> > > Hello,
> > >
> > > there was no acpi log, so I recompiled ubuntu kernel with
> > > CONFIG_ACPI_DEBUG=y and CONFIG_ACPI_DEBUG_FUNC_TRACE. Then I started kernel
> > > with your params.
> > >
> > > Now I'm attaching very long debug output. I belive it will be now usefull.
> > >
> > > Pressing brightness keys did not show anything in log.
> > >
> > > After writing 0 to /sys/class/backlight/acpi_video0/brightness in log
> > > appear: [ 57.675070] [ACPI Debug] Integer 0x000000000000000B
> > > ...
> > >
> > > And after writing 10:
> > > [ 99.865208] [ACPI Debug] Integer 0x0000000000000048
> > > [ 99.865295] evmisc-0120 [4294967289] ev_queue_notify_reques:
> > > Dispatching Notify on [DGFX] Node ffff880136246c80 Value 0xD0 (**Device
> > > Specific**) [ 99.865350] video-1474 [4294967289] video_bus_notify
> > > : Unsupported event [0xd0]
> >
> > Do you need more logs? Or is this enought?
> >
>
> Yes, as you point out, this is a doubt for video bus received 0xD0 event
> but nobody take care it.
>
> Traced dsdt of EliteBook 8460p from you, the _BCM like this:
>
> Method (_BCM, 1, Serialized) /* ATI _BCM, per log, run this _BCM */
> {
> Store (\_SB.BCM (Arg0), Local0) /* set next level, normally return 0x1 if XP sp2 or later */
> If (Local0) /* if XP sp2 or later */
> {
> Store (BRID, Local1)
> If (LEqual (SBRV (), 0x00)) /* normally SBRV return 1, will not emit SMI */
> {
> \_SB.SSMI (0xEA74, 0x04, Local1, 0x00, 0x00)
> }
>
> Signal (\_SB.BEVT) /* emit BEVT event, HKFR (HotkeyFunctionResponse) waiting it, but why? */
> }
> }
>
> _BCM call SBRV to setup brightness value to variable ABRI:
>
> Method (SBRV, 0, Serialized) /* call by ATI _BCM */
> {
> Store (\_SB.SBRC (), ABRI) /* SBRC() return the brightness value, why store to ABRI? only used in PEGP.DGFX.AFN2 */
> Or (PSBR, 0x80, PSBR)
> Notify (^, 0xD0) /* notify method's parent: PEGP.DGFX by 0xD0 */
> Return (0x01) /* normally return 1 */
> }The PEGP.DGFX acpi device was binding to acpi/video driver, the above
> ASL code emit a 0xD0 bus event to video.c but cann't process it. Even we
> add a new bus event in video.c and generate a acpi event, there still
> need another acpi driver should take care it.
>
> I thought this acpi event might need take care by radeon drm, but I am
> not good for radeon, need more help.
>
> Per your acpi debug log, the brightness value was changed normally when
> you access _BCM:
>
> 83133 Jan 20 17:17:51 Pali-EliteBook kernel: [ 57.674669] ACPI: Execute Method [\_SB_.PCI0.PEGP.DGFX.LCD_._BCM] (Node ffff8 801362472a8) # start test _BCM manually
> 83134 Jan 20 17:17:51 Pali-EliteBook kernel: [ 57.674736] exregion-0199 [01] ex_system_memory_space: System-Memory (width 8 ) R/W 0 Address=00000000BF7ACE1C
> 83135 Jan 20 17:17:51 Pali-EliteBook kernel: [ 57.674748] exregion-0199 [02] ex_system_memory_space: System-Memory (width 8 ) R/W 1 Address=00000000BF7ACE1C
> ...
> 83179 Jan 20 17:17:51 Pali-EliteBook kernel: [ 57.675070] [ACPI Debug] Integer 0x000000000000000B # brightness value is 11
> 83180 Jan 20 17:17:51 Pali-EliteBook kernel: [ 57.675090] evmisc-0120 [4294967289] ev_queue_notify_reques: Dispatching No tify on [DGFX] Node ffff880136246c80 Value 0xD0 (**Device Specific**)
> 83181 Jan 20 17:17:51 Pali-EliteBook kernel: [ 57.675099] video-1474 [4294967288] video_bus_notify : Unsupported event [0xd0]
> ...
> 83197 Jan 20 17:18:33 Pali-EliteBook kernel: [ 99.863593] ACPI: Execute Method [\_SB_.PCI0.PEGP.DGFX.LCD_._BCM] (Node ffff8 801362472a8)
> 83198 Jan 20 17:18:33 Pali-EliteBook kernel: [ 99.863817] exregion-0199 [01] ex_system_memory_space: System-Memory (width 8 ) R/W 0 Address=00000000BF7ACE1C
> 83243 Jan 20 17:18:33 Pali-EliteBook kernel: [ 99.865208] [ACPI Debug] Integer 0x0000000000000048 # brightness value is 72
> 83244 Jan 20 17:18:33 Pali-EliteBook kernel: [ 99.865295] evmisc-0120 [4294967289] ev_queue_notify_reques: Dispatching Notify on [DGFX] Node ffff880136246c80 Value 0xD0 (**Device Specific**)
> 83245 Jan 20 17:18:33 Pali-EliteBook kernel: [ 99.865350] video-1474 [4294967289] video_bus_notify : Unsupported event [0xd0]
>
> The brightness values are 11(0x0B) and 72(0x48), that means the BCM
> method return a good value and set to ABRI, ABRI waiting the guy who
> take the 0xD0 event to read then change brightness.
>
> Another doubt is the latest statement in _BCM, it emit a BEVT event:
>
> Signal (\_SB.BEVT)
>
> Only HKFR(HotkeyFunctionResponse) method is waiting this event, it
> should related to how the HP implement brightness function key on
> Windows through wmi.
>
> Of course this issue really close related to video driver, even more,
> we might need to know hp wmi for how to implement on Windows.
>
> Unfortunately, sorry for I don't have any solution to you, now, I will
> continue to trace and find any support from other experts.
>
>
> Thanks a lot!
> Joey Lee
After traced the acpidump of HP EliteBook 8560w from you,
I added Cc. to you on this mailing loop because your HP EliteBook 8560w
has the same situation with HP EliteBook 8460p.
Pali Rohár reported the same brightness control issue on 8460p.
The only difference between 8560w with 8460p is HP's ODM put _BCM and
SBRV in SSDT3 table on 8560w.
Please kindly read the above my description. Sorry for I don't have any
solution, now.
Thanks a lot!
Joey Lee
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
