modprobe acer-wmi gives the result: FATAL: Error inserting acer_wmi (/lib/modules/2.6.39-1.fc15.x86_64/kernel/drivers/platform/x86/acer-wmi.ko): No such device Please find acpidump.dat, dmidecode.log and dsdt in the attached files.
Created attachment 59002 [details] dmidecode
Created attachment 59012 [details] acpidump
Created attachment 59022 [details] dsdt
After traced the DSDT from Acer Aspire 5750G, this machine support new WMID_GUID3 methods but not support older wmi method: 676AA15E-6A47-4D9F-A2CC-1E6D18D14026: object_id: ¼^@ notify_id: BC reserved: 00 instance_count: 1 flags: 0x8 ACPI_WMI_EVENT 61EF69EA-865C-4BC3-A502-A0DEBA0CB531: object_id: AA notify_id: 41 reserved: 41 instance_count: 1 flags: 0x2 ACPI_WMI_METHOD I will clear up acer-wmi driver to support this kind machine, but I am busy at this week, will find time to do that.
Found the brightness control by this machine is follow standard acpi video interface: Method (_Q11, 0, NotSerialized) /* brightness decrease */ { ... If (LGreaterEqual (OSYS, 0x07D6)) /* Vista or Windows 7 */ { If (LEqual (OBV, 0xFF)) { Notify (^^^PEG0.PEGP.DD01, 0x87) } Else { Notify (^^^GFX0.DD03, 0x87) /* ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS 0x87 */ } } Method (_BCM, 1, NotSerialized) { Divide (Arg0, 0x0A, Local0, Local1) Decrement (Local1) Store (Local1, ^^^LPCB.EC0.BRTS) } This issue should not related to acer-wmi driver, even acer-wmi driver support this machine, it cann't help anything for brightness control on this machine. Did brightness control works before 2.6.39 kernel? Could you please help to attached dmesg on this bugzilla? Did you see and error message when you press Fn key to increase/decrease brightness?
I have checked it with 2.6.38 and Brightness control also didn't work. Please tell me, where can I find an error message when I press Fn key? I have checked /var/log/messages and it didn't have a related error. Please find dmesg in the attached file.
Created attachment 59132 [details] dmesg
There have problem on your machine when video bus initial: [ 3.524610] fb0: inteldrmfb frame buffer device [ 3.524612] drm: registered panic notifier [ 3.834812] acpi device:2f: registered as cooling_device8 [ 3.835017] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input5 [ 3.835091] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 3.835118] ACPI Exception: AE_NOT_FOUND, Evaluating _DOD (20110316/video-1148) [ 3.835183] ACPI Error: [\_SB_.PCI0.GFX0.DD02._BCL] Namespace lookup failure, AE_NOT_FOUND (20110316/psargs-359) [ 3.835189] ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEG0.PEGP.DD02._BCL] (Node ffff880159181118), AE_NOT_FOUND (20110316/psparse-536) [ 3.835377] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/device:35/LNXVIDEO:01/input/input6 [ 3.835409] ACPI: Video Device [PEGP] (multi-head: no rom: yes post: no) [ 3.835498] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 Add Cc. to Zhang Rui
Hi malashenko, Before ACPI experts join us, could you please help to dump some acpi debug information? Please add the following kernel parameter to your boot/grub/menu.lst : acpi.debug_level=0x0000004F and acpi.debug_layer=0xFFFFFFFF log_buf_len=5M After reboot system, please attached the dmesg on this bugzilla. Thank's
Created attachment 59162 [details] dmesg with acpi debug Please find the new dmesg in the attached dmesg_2 file. Thank you!
There didn't show up any acpi debug message in your dmesg_2 file. Could you please help to check your kernel config file? The acpi debug config need set to yes: CONFIG_ACPI_DEBUG=y
Created attachment 59452 [details] dmesg with acpi debug enabled I recompiled the kernel with: CONFIG_ACPI_DEBUG=y CONFIG_ACPI_DEBUG_FUNC_TRACE=y I hope that new version of dmesg is correct (please find it in the attached file). Thank you!
(In reply to comment #12) > Created an attachment (id=59452) [details] > dmesg with acpi debug enabled > > I recompiled the kernel with: > CONFIG_ACPI_DEBUG=y > CONFIG_ACPI_DEBUG_FUNC_TRACE=y > I hope that new version of dmesg is correct (please find it in the attached > file). > Thank you! OK, the dmesg log is right at this time. Then, could you please help to do 2 testing: - Press Fn+Right/Left key to increase/decrease brightness one time, then attached the dmesg on this bug. - Please check if you have backlight sysfs, please try to modify brightness, like: echo 2 > /sys/class/backlight/acpi_video0/brightness echo 9 > /sys/class/backlight/acpi_video0/brightness Does it work? then also attached the dmesg on this bug. Thank's
Created attachment 59592 [details] dmesg after Fn+Right/Left key pressing Please find dmesg after Fn+Right/Left key pressing in the attached file.
Created attachment 59602 [details] dmesg after echo * > /sys/class/backlight/acpi_video0/brightness echo 2 > /sys/class/backlight/acpi_video0/brightness and echo 9 > /sys/class/backlight/acpi_video0/brightness don't work. Please find dmesg after these commands in the attached file. Thank you!
(In reply to comment #14) > Created an attachment (id=59592) [details] > dmesg after Fn+Right/Left key pressing > > Please find dmesg after Fn+Right/Left key pressing in the attached file. Thank's for your dmesg, it's help me to confirm your Fn key map to _Q event: _Q11: brightness decrease _Q12: brightness increase
(In reply to comment #15) > Created an attachment (id=59602) [details] > dmesg after echo * > /sys/class/backlight/acpi_video0/brightness > > echo 2 > /sys/class/backlight/acpi_video0/brightness and > echo 9 > /sys/class/backlight/acpi_video0/brightness > don't work. > Please find dmesg after these commands in the attached file. > Thank you! Per your DSDT, in _BCM method, it write a value to the BRTS register in EC, I believe this register handle brightness level: Method (_BCM, 1, NotSerialized) { Divide (Arg0, 0x0A, Local0, Local1) Decrement (Local1) Store (Local1, ^^^LPCB.EC0.BRTS) } But, look like the EC firmware didn't change brightness when BRTS modified, that's not make sense because it must be works on Windows 7. Your dmesg on comment #14 confirm we are running the same logic path with Windows 7. Next step is: we need to make sure the _BCM store value to BRTS is success, we need monitor the EC's memory block. I will find a good way for you to monitor it, might need EC expert's help.
EC must can handle the BRTS changed. Please help to confirm the value in BRTS changed by _BCM, please kindly enable CONFIG_ACPI_EC_DEBUGFS=m, then run Thomas's ec_access tool: ftp://ftp.suse.com/pub/people/trenn/sources/ec/ Check value: modprobe ec_sys ./ec_access -b 0xB9 Please check the value changed when you press brightness up/down key.
(In reply to comment #18) > EC must can handle the BRTS changed. > > Please help to confirm the value in BRTS changed by _BCM, > please kindly enable CONFIG_ACPI_EC_DEBUGFS=m, then run Thomas's ec_access > tool: > ftp://ftp.suse.com/pub/people/trenn/sources/ec/ > > Check value: > modprobe ec_sys > ./ec_access -b 0xB9 > > Please check the value changed when you press brightness up/down key. Yes, the value changes step by step 0x00, 0x02 ... 0x09 when I press Fn+Right key and return back 0x09, 0x08 ... 0x00 when I press Fn+Left key. Many Thanks!
Thank's for your testing, it's help to confirm our value write to EC register. Unfortunately, I have no idea why the EC didn't change brightness level even the BRTS register was changed. I will try to trace DSDT hope can dig more information. This issue MIGHT not related to acer-wmi driver. I wonder how does the brightness control key works on Windows 7, I thought we need EC expert's help.
(In reply to comment #20) > Thank's for your testing, it's help to confirm our value write to EC > register. > > Unfortunately, > I have no idea why the EC didn't change brightness level even the BRTS > register > was changed. I will try to trace DSDT hope can dig more information. This > issue > MIGHT not related to acer-wmi driver. > > I wonder how does the brightness control key works on Windows 7, I thought we > need EC expert's help. I would like to confirm, on Windows 7 it works without problem. Thank you!
I thought we might need send out a magic command to EC or evaluate special wmi method to initial EC, there must be have a specially windows driver or program do the job. We have 2 options can try: a. Ask Acer. b. Try reverse Engineer lib file in windows. For a. selection, I will send a mail to Acer guys, try to contact with them. For b. selection, I need to ask Carlos Corbacho for how to, I didn't do it before.
(In reply to comment #21) > (In reply to comment #20) > > Thank's for your testing, it's help to confirm our value write to EC > register. > > > > Unfortunately, > > I have no idea why the EC didn't change brightness level even the BRTS > register > > was changed. I will try to trace DSDT hope can dig more information. This > issue > > MIGHT not related to acer-wmi driver. > > > > I wonder how does the brightness control key works on Windows 7, I thought > we > > need EC expert's help. > > I would like to confirm, on Windows 7 it works without problem. > > Thank you! Read this: http://msdn.microsoft.com/en-us/windows/hardware/gg487382.aspx I thought brightness control key works on Windows 7 because it have WDDM video driver, but Linux didn't support WDDM. Per the above spec, windows driver will try 2 ways to modify brightness: + WDDM video driver + if no WDDM video driver, then will follow ACPI standard. So, the _BCM must be work on machine but it's fail on Acer Aspire 5750G.
Just in case, I don't know if it's relevant. I can use the backlight keys if I boot the kernel using acpi_osi="Linux", although acer_wmi still doesn't work. And changing the backlight values by software (echo value > /sys/class/backlight/acpi_video0/brightness) doesn't work too unless I use one of the brightness keys after changing it. (same laptop, acer bios 1.12, kernel 3.0.2)
(In reply to comment #24) > Just in case, I don't know if it's relevant. I can use the backlight keys if > I > boot the kernel using acpi_osi="Linux", although acer_wmi still doesn't work. > And changing the backlight values by software (echo value > > /sys/class/backlight/acpi_video0/brightness) doesn't work too unless I use > one > of the brightness keys after changing it. > > (same laptop, acer bios 1.12, kernel 3.0.2) Does your machine is also Acer Aspire 5750G ? Could you please also attached your DSDT on bugzilla or open a new bug if your machine is not 5750G? This issue is because there BIOS have bug in _BCM, you cann't modify brightness level by standard acpi method. The acpi_osi="Linux" works on your machine is because OEM direct access the BCLP register for video but not through ACPI method.
Created attachment 69252 [details] DSDT Table for Acer Aspire 5750g - bios 1.12
(In reply to comment #25) > (In reply to comment #24) > > Just in case, I don't know if it's relevant. I can use the backlight keys > if I > > boot the kernel using acpi_osi="Linux", although acer_wmi still doesn't > work. > > And changing the backlight values by software (echo value > > > /sys/class/backlight/acpi_video0/brightness) doesn't work too unless I use > one > > of the brightness keys after changing it. > > > > (same laptop, acer bios 1.12, kernel 3.0.2) > > Does your machine is also Acer Aspire 5750G ? Could you please also attached > your DSDT on bugzilla or open a new bug if your machine is not 5750G? > Yes, it's the same laptop. Mine has more RAM though. > This issue is because there BIOS have bug in _BCM, you cann't modify > brightness > level by standard acpi method. > > The acpi_osi="Linux" works on your machine is because OEM direct access the > BCLP register for video but not through ACPI method. Ok, it's good to know.
Hi, Lee, what's the status of this bug?
I'm running 3.2.6 (Gentoo) on Aspire 5750G-2414G1TMnkk. Backlight control works well with `acpi_backlight=vendor`. I can use keys, /sys/class/backlight/intel_backlight/ interface and KDE backlight controls. When using keys I get "unhandled event" messages, they work only in X environment. If you need more information or some tests I can provide them. :-)
(In reply to comment #29) > I'm running 3.2.6 (Gentoo) on Aspire 5750G-2414G1TMnkk. Backlight control > works > well with `acpi_backlight=vendor`. I can use keys, > /sys/class/backlight/intel_backlight/ interface and KDE backlight controls. Yes, this is another workaround to control brightness through i915 drm driver. > When using keys I get "unhandled event" messages, they work only in X > environment. If you need more information or some tests I can provide them. > :-) I thought the "keys" means the Fn+left/right (brightness function key). Please kindly attach on /var/log/messages log after you press brightness control function key a couple of times. Thanks
Hi Rui, (In reply to comment #28) > Hi, Lee, > what's the status of this bug? I already pass this situation to Acer PM face to face, he said will pass to BIOS team for _BCM doesn't work on many Acer machines. But, I didn't get further response from Acer. Currently, only 2 work around is use acpi_osi="Linux" or acpi_backlight=vendor, the i915 brightness control works. I have no idea how to fix this problem because we confirm acer-wmi already write the brightness value to EC regitser, but we have no way to know the EC firmware is really change brightness.
Created attachment 72376 [details] Log after pressing Fn+arrows (In reply to comment #30) > I thought the "keys" means the Fn+left/right (brightness function key). > Please kindly attach on /var/log/messages log after you press brightness > control function key a couple of times. > > Thanks Well yes, I meant Fn+arrows. Pressing these buttons change brightness only in X (KDE) environment, they don't work in terminal. Although they work in X, "unhandled events" are still logged. I think this is related to acpid and I need to write some script to handle these evenets, so it probably has nothing to do with this bug. :-)
(In reply to comment #32) > Created an attachment (id=72376) [details] > Log after pressing Fn+arrows > > (In reply to comment #30) > > I thought the "keys" means the Fn+left/right (brightness function key). > > Please kindly attach on /var/log/messages log after you press brightness > > control function key a couple of times. > > > > Thanks > > Well yes, I meant Fn+arrows. Pressing these buttons change brightness only in > X > (KDE) environment, they don't work in terminal. Although they work in X, > "unhandled events" are still logged. I think this is related to acpid and I > need to write some script to handle these evenets, so it probably has nothing > to do with this bug. :-) The acpi/video driver capture those acpi event then emit brightness changed keycode to userland. And, acpi/video driver also changed brightness through _BCM when brightness_switch_enabled module parameter was enabled (default). Unfortunately, the _BCM is broken on this acer machine, so the action from acpi/video for change brightness is also not work. Use acpid to workaround it is a idea.
Created attachment 72591 [details] 0001-acer-wmi-Add-quirk-table-for-video-backlight-vendor-.patch Please try this patch if 'acpi_backlight=vendor' kernel parameter works to you. If 'acpi_backlight=vendor' works on your machine, but this patch not work, please attach on your dmidecode.log: #dmidecode > dmidecode.log
I've applied this patch against 3.3.0. 'acpi_backlight=vendor' works like before. dmesg: DMI: Acer Aspire 5750G/JE50_HR, BIOS V1.14 09/07/2011 acer_wmi: Acer Laptop ACPI-WMI Extras acer_wmi: Function bitmap for Communication Button: 0x1 input: Acer WMI hotkeys as /devices/virtual/input/input7 acer_wmi: Get 0x1 Device Status failed: 0xe2 - 0x0 When 'acpi_backlight=vendor' option is not present there is an additional message: acer_wmi: Brightness must be controlled by generic video driver And backlight control doesn't work. So I assume that patch works. :-)
Hi Andrzej, (In reply to comment #35) > I've applied this patch against 3.3.0. 'acpi_backlight=vendor' works like > before. dmesg: > DMI: Acer Aspire 5750G/JE50_HR, BIOS V1.14 09/07/2011 > acer_wmi: Acer Laptop ACPI-WMI Extras > acer_wmi: Function bitmap for Communication Button: 0x1 > input: Acer WMI hotkeys as /devices/virtual/input/input7 > acer_wmi: Get 0x1 Device Status failed: 0xe2 - 0x0 > When 'acpi_backlight=vendor' option is not present there is an additional > message: > acer_wmi: Brightness must be controlled by generic video driver > And backlight control doesn't work. So I assume that patch works. :-) hm... that means my patch no works. If my patch works, means you don't need add 'acpi_backlight=vendor' for enable brightness control, acer-wmi will do the job. Please kindly share your dmidecode to me: # dmidecode > dmidecode.log
Created attachment 73350 [details] Dmidecode, patched kernel (In reply to comment #36) > Please kindly share your dmidecode to me: > # dmidecode > dmidecode.log Here you are.
Created attachment 73641 [details] test.patch for v3.3 OK, your machine is not in quirk table, I add it. Please try this patch! If this patch works, will add your machine to kernel, then will not need add vendor manually.
Hi! I have to admit I completely forgot about this. Now I can't apply your patch against 3.6.0.
I've examined acer-wmi.c and found out that patch is probably no longer needed. I've tested two kernels: 3.5.4 and 3.6.0. In 3.5.4 with 'acpi_backlight=vendor' everything works fine (keys/KDE controls). Without 'acpi_backlight' parameter message 'acer_wmi: Brightness must be controlled by generic video driver' is printed and keys don't work. However, KDE backlight controls still work (/sys/class/backlight/intel_backlight is present). In 3.6.0 keys don't work regardless of 'acpi_backlight' parameter (above message is always printed).
there is a lot of change about this piece of code recently, but I do not see why it may bring the problem. could you please verify if the problem exists in the latest upstream kernel?
(In reply to comment #40) > I've examined acer-wmi.c and found out that patch is probably no longer > needed. > I've tested two kernels: 3.5.4 and 3.6.0. In 3.5.4 with > 'acpi_backlight=vendor' > everything works fine (keys/KDE controls). Without 'acpi_backlight' parameter > message 'acer_wmi: Brightness must be controlled by generic video driver' is Yes, the message means acpi video is in charge of backlight control, not acer_wmi. And acpi video driver can't handle backlight for your system. > printed and keys don't work. However, KDE backlight controls still work > (/sys/class/backlight/intel_backlight is present). Does /sys/class/backlight/acpi_video0 exist? > In 3.6.0 keys don't work regardless of 'acpi_backlight' parameter (above > message is always printed). I suppose there is a "Disabling ACPI video driver" message printed in v3.6? If so, you can try the following patch to see if it works around your problem: diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c index c9076bd..137bebc 100644 --- a/drivers/platform/x86/acer-wmi.c +++ b/drivers/platform/x86/acer-wmi.c @@ -2229,8 +2229,8 @@ static int __init acer_wmi_init(void) interface->capability &= ~ACER_CAP_BRIGHTNESS; pr_info("Brightness must be controlled by acpi video driver\n"); } else { - pr_info("Disabling ACPI video driver\n"); - acpi_video_unregister(); +// pr_info("Disabling ACPI video driver\n"); +// acpi_video_unregister(); } if (wmi_has_guid(WMID_GUID3)) { Thanks.
3.8.4 with or without 'acpi_backlight=vendor': acer_wmi: Brightness must be controlled by generic video driver acer_wmi: Disabling ACPI video driver /sys/class/backlight/intel_backlight - PRESENT /sys/class/backlight/acpi_video0 - MISSING RESULT: Buttons don't work, KDE controls work. 3.8.4 with patch and without 'acpi_backlight=vendor': acer_wmi: Brightness must be controlled by generic video driver /sys/class/backlight/intel_backlight - PRESENT /sys/class/backlight/acpi_video0 - PRESENT RESULT: Neither buttons nor KDE controls work. 3.8.4 with patch and 'acpi_backlight=vendor': acer_wmi: Brightness must be controlled by generic video driver /sys/class/backlight/intel_backlight - PRESENT /sys/class/backlight/acpi_video0 - MISSING RESULT: Buttons and KDE controls work. 3.8.4 patch used: --- drivers/platform/x86/acer-wmi.c.orig 2013-03-23 18:51:05.725970055 +0100 +++ drivers/platform/x86/acer-wmi.c 2013-03-23 18:52:18.995965110 +0100 @@ -2211,8 +2211,8 @@ interface->capability &= ~ACER_CAP_BRIGHTNESS; pr_info("Brightness must be controlled by acpi video driver\n"); } else { - pr_info("Disabling ACPI video driver\n"); - acpi_video_unregister(); + //pr_info("Disabling ACPI video driver\n"); + //acpi_video_unregister(); } if (wmi_has_guid(WMID_GUID3)) {
Created attachment 96441 [details] Test patch to remove acpi_video_unregister call Hi, Please kindly test this patch, it is on top of 3.8.4, also applies to latest Linus' git tree. Please list /sys/class/backlight after test, thanks.
BTW, you do not need to add any kernel command line parameter with this patch.
ls /sys/class/backlight/: intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight There are no messages in dmesg regarding backlight. Keys and KDE controls work. Everything seems to be OK. :-)
Hi Aaron, (In reply to comment #44) > Created an attachment (id=96441) [details] > Test patch to remove acpi_video_unregister call > > Hi, > > Please kindly test this patch, it is on top of 3.8.4, also applies to latest > Linus' git tree. > > Please list /sys/class/backlight after test, thanks. Base on Andrzej's dmidecode, the product name on his machine is "Aspire 5750G". Looks this issue causes by acpi_video_backlight_support() could not detect the brightness console suopport on "Aspire 5750G", so please only add Aspire 5750G to video_detect.c: diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 4ac2593..93de5e1 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -164,6 +164,13 @@ static struct dmi_system_id video_detect_dmi_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "UL30VT"), }, }, + .callback = video_detect_force_vendor, + .ident = "Acer Aspire 5750G", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Acer"), + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750G"), + }, + }, { }, }; On the other hand, please do _NOT_ remove the video_vendor_dmi_table and acpi_video_unregister logic in acer-wmi. Those machines (TravelMate 4750, Extensa 5235, Aspire 5750...) has broken _BCM implementation in ACPI, so we leave generic video driver (e.g. i915) to control the backlight on those machine.
Created attachment 97041 [details] acer-wmi-5750g.patch Hi Andrzej, Could you please try this acer-wmi patch? This patch add 5750g to the blacklist of _BCM broken. Please remove other patch then test this patch alone. Thanks a lot!
(In reply to comment #48) > Created an attachment (id=97041) [details] > acer-wmi-5750g.patch > > Hi Andrzej, > > Could you please try this acer-wmi patch? This patch add 5750g to the > blacklist > of _BCM broken. > > Please remove other patch then test this patch alone. > > Thanks a lot! Please remove "acpi_backlight=vendor" parameter when you try this patch.
(In reply to comment #47) > Hi Aaron, > > (In reply to comment #44) > > Created an attachment (id=96441) [details] [details] > > Test patch to remove acpi_video_unregister call > > > > Hi, > > > > Please kindly test this patch, it is on top of 3.8.4, also applies to > latest > > Linus' git tree. > > > > Please list /sys/class/backlight after test, thanks. > > Base on Andrzej's dmidecode, the product name on his machine is "Aspire > 5750G". > Looks this issue causes by acpi_video_backlight_support() could not detect > the > brightness console suopport on "Aspire 5750G", so please only add Aspire > 5750G > to video_detect.c: I think the systems listed in video_vendor_dmi_table all have broken acpi video driver support, no? > > diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c > index 4ac2593..93de5e1 100644 > --- a/drivers/acpi/video_detect.c > +++ b/drivers/acpi/video_detect.c > @@ -164,6 +164,13 @@ static struct dmi_system_id video_detect_dmi_table[] = { > DMI_MATCH(DMI_PRODUCT_NAME, "UL30VT"), > }, > }, > + .callback = video_detect_force_vendor, > + .ident = "Acer Aspire 5750G", > + .matches = { > + DMI_MATCH(DMI_SYS_VENDOR, "Acer"), > + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750G"), > + }, > + }, > { }, > }; > > > On the other hand, > please do _NOT_ remove the video_vendor_dmi_table and acpi_video_unregister > logic in acer-wmi. Those machines (TravelMate 4750, Extensa 5235, Aspire > 5750...) has broken _BCM implementation in ACPI, so we leave generic video > driver (e.g. i915) to control the backlight on those machine. Yes, this is the case. And removing the video_vendor_dmi_table and acpi_video_unregister in acer-wmi doesn't change the fact, since we have placed all those system to video_detect.c so that acpi video driver will _not_ create backlight interface for them. So I don't see why this is a problem.
Hi Lee, The problem should be, the handling of hotkey requires acpi video driver, so we can't unload acpi video module in acer-wmi. And I do not like the idea of calling acpi_video_unregister in another module, it's not that it had to be this way. acpi video driver can have such knowledge to not create backlight interface for the broken systems, it doesn't need other modules to tell it. And in this problem, unload acpi video driver will also disable the notification handling provided by acpi video driver. So please consider listing broken systems for acpi video driver in acpi video driver, not in other platform driver. The whole point of having those systems in indivisual platform driver is to avoid a big DMI table in video_detect.c, but that is unfortunately not easy to realize. BTW, there is no need to add this system to the dmi table, since we already have 5750, and AFAIK, the dmi function use strstr to decide if the system matches, so 5750G should already match 5750.
(In reply to comment #50) > (In reply to comment #47) > > Hi Aaron, > > > > (In reply to comment #44) > > > Created an attachment (id=96441) [details] [details] [details] > > > Test patch to remove acpi_video_unregister call > > > > > > Hi, > > > > > > Please kindly test this patch, it is on top of 3.8.4, also applies to > latest > > > Linus' git tree. > > > > > > Please list /sys/class/backlight after test, thanks. > > > > Base on Andrzej's dmidecode, the product name on his machine is "Aspire > 5750G". > > Looks this issue causes by acpi_video_backlight_support() could not detect > the > > brightness console suopport on "Aspire 5750G", so please only add Aspire > 5750G > > to video_detect.c: > > I think the systems listed in video_vendor_dmi_table all have broken acpi > video > driver support, no? Yes! The machines put in video_vendor_dmi_table list means all have broken _BCM implementation. So, the backlight of those machines should take care by nature video driver, e.g. i915. > > > > > diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c > > index 4ac2593..93de5e1 100644 > > --- a/drivers/acpi/video_detect.c > > +++ b/drivers/acpi/video_detect.c > > @@ -164,6 +164,13 @@ static struct dmi_system_id video_detect_dmi_table[] = > { > > DMI_MATCH(DMI_PRODUCT_NAME, "UL30VT"), > > }, > > }, > > + .callback = video_detect_force_vendor, > > + .ident = "Acer Aspire 5750G", > > + .matches = { > > + DMI_MATCH(DMI_SYS_VENDOR, "Acer"), > > + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750G"), > > + }, > > + }, > > { }, > > }; > > > > > > On the other hand, > > please do _NOT_ remove the video_vendor_dmi_table and acpi_video_unregister > > logic in acer-wmi. Those machines (TravelMate 4750, Extensa 5235, Aspire > > 5750...) has broken _BCM implementation in ACPI, so we leave generic video > > driver (e.g. i915) to control the backlight on those machine. > > Yes, this is the case. And removing the video_vendor_dmi_table and > acpi_video_unregister in acer-wmi doesn't change the fact, since we have > placed > all those system to video_detect.c so that acpi video driver will _not_ > create > backlight interface for them. So I don't see why this is a problem. I reviewed Andrzej's comment #43, he removed the acpi_video_unregister in acer-wmi, it causes the acpi/video driver didn't remove. So video driver still works on transfer the video bus notify event to keycode event for raise to userspace. There have 2 issues on Andrzej's machine: + The _BCM doesn't works on his machine, so we need block the sysfs interface of acpi/video for leave i915 take care backlight control. The solution is the patch on comment#48, it put "Aspire 5750G" to video_vendor_dmi_table. This patch's effect should the same with "acpi_backlight=vendor". + The function key doesn't work after put "Aspire 5750G" to video_vendor_dmi_table, or use "acpi_backlight=vendor". That because acpi/video driver removed by acpi_video_unregister in acer-wmi or "acpi_backlight=vendor", so video driver will not emit keycode when it received any event from acpi video bus. This situation is more complex because it relates to user space implementation: Fn key pressed by user ===> emit notify event to acpi video bus ===> acpi/video driver ===> transfer to keycode, emit to userspace ===> Xorg grab keycode, emit X event ===> user space application, e.g. gnome-settings-daemon, it grab the X event then change brightness through xrandr api There have 2 situation on this machine: a. The best situation is: This machine emits scan code when press Fn key, we can transfer it to keycode for raise to user space. Then the Fn key can works even the acpi/video driver unregister. b. If this machine doesn't emit any scan code, then we need got a question: Does it make sense for acpi/video emit keycode to user space while _BCM doesn't work? I mean in the case, i915's backlight interface is the REAL player for change the backlight but not acpi/video driver. We keep the acpi/video is for trigger brightess change logic in userspace?
(In reply to comment #51) > Hi Lee, > > The problem should be, the handling of hotkey requires acpi video driver, so > we > can't unload acpi video module in acer-wmi. > > And I do not like the idea of calling acpi_video_unregister in another > module, > it's not that it had to be this way. acpi video driver can have such > knowledge > to not create backlight interface for the broken systems, it doesn't need > other > modules to tell it. And in this problem, unload acpi video driver will also > disable the notification handling provided by acpi video driver. So please > consider listing broken systems for acpi video driver in acpi video driver, > not > in other platform driver. The whole point of having those systems in > indivisual > platform driver is to avoid a big DMI table in video_detect.c, but that is > unfortunately not easy to realize. Those broken machines information is vendor specific, that's why we put it to platform driver but not video_detect.c. I tried to put it to video_detect, but finally put those machine to platform driver is our resolution. But, for acpi_video_unregister, you can raise it on platform-driver-x86@vger.kernel.org for discussion. There have 4 platform drivers follow this rule, now. > > BTW, there is no need to add this system to the dmi table, since we already > have 5750, and AFAIK, the dmi function use strstr to decide if the system > matches, so 5750G should already match 5750. Thanks for your remind, I will check it.
(In reply to comment #48) > Created an attachment (id=97041) [details] > acer-wmi-5750g.patch > > Hi Andrzej, > > Could you please try this acer-wmi patch? This patch add 5750g to the > blacklist > of _BCM broken. > > Please remove other patch then test this patch alone. > > Thanks a lot! acer_wmi: Brightness must be controlled by generic video driver acer_wmi: Brightness must be controlled by generic video driver acer_wmi: Disabling ACPI video driver (Yes, it's printed twice) /sys/class/backlight/intel_backlight - PRESENT /sys/class/backlight/acpi_video0 - MISSING RESULT: Buttons don't work, KDE controls work. So the result is the same as with 3.8.4 without any patches and parameters. It seems it's now detected twice: as 5750 and 5750G, so I think Aaron is right - there is no need to add 5750G to that table.
(In reply to comment #53) > Those broken machines information is vendor specific, that's why we put it to > platform driver but not video_detect.c. I tried to put it to video_detect, > but > finally put those machine to platform driver is our resolution. I think the reason is to avoid a big DMI table, which I agree we should try to avoid. But for such problems, unfortunately, I don't see it is possible to avoid that. And it brings the problem of unnecessary module dependency between acpi video driver and vendor driver due to the cross module function call: acpi_video_unregister. Bug #52651 is waiting to be solved due to this. If we do not do this, we will again need to add Select or Depends on ACPI VIDEO for asus-wmi module. > > But, for acpi_video_unregister, you can raise it on > platform-driver-x86@vger.kernel.org for discussion. There have 4 platform > drivers follow this rule, now. I'll, once I've all the reporters verified the patch fixed the problem :-) I need to make sure I understand the problem correctly before propose the patch upstream. Bug #51051 is similar, but there is some problem blocking the verification now, so I need to wait for a little longer.
(In reply to comment #55) > (In reply to comment #53) > > Those broken machines information is vendor specific, that's why we put it > to > > platform driver but not video_detect.c. I tried to put it to video_detect, > but > > finally put those machine to platform driver is our resolution. > > I think the reason is to avoid a big DMI table, which I agree we should try > to > avoid. But for such problems, unfortunately, I don't see it is possible to > avoid that. And it brings the problem of unnecessary module dependency > between > acpi video driver and vendor driver due to the cross module function call: > acpi_video_unregister. Bug #52651 is waiting to be solved due to this. If we > do > not do this, we will again need to add Select or Depends on ACPI VIDEO for > asus-wmi module. > > > > > But, for acpi_video_unregister, you can raise it on > > platform-driver-x86@vger.kernel.org for discussion. There have 4 platform > > drivers follow this rule, now. > > I'll, once I've all the reporters verified the patch fixed the problem :-) I > need to make sure I understand the problem correctly before propose the patch > upstream. Bug #51051 is similar, but there is some problem blocking the > verification now, so I need to wait for a little longer. Those machines has broken _BCM means Windows doesn't used ACPI interface when OEM design. From my point of view, I will want to only put the machine last already have good testing for not unload acpi/video driver, don't touch the other old machines unless those machines also testing with acpi/video driver.
Created attachment 97101 [details] 0001-acer-wmi-add-Acer-Aspire-5750G-to-video-vendor-list-.patch Hi Andrzej, Please help to test this patch, it's still add 5750G to table but this time I add a new capability for avoid unregister acpi/video driver on your machine. Please try this patch without "acpi_backlight=vendor", I this time acpi/video will keep there for emit keycode. Please also use "lsmod | grep video" to check if video driver still there. Thanks for your help!
From my position, I will send this patch on comment#57 after Andrzej has well testing with it. For larger scope change, let's wait Aaron launch on upstream for more discussion.
(In reply to comment #58) > From my position, I will send this patch on comment#57 after Andrzej has well > testing with it. This will not work, at least when GNOME is used. For other GUIs, I don't know. The reason: if we do not call acpi_video_unregister, the acpi video driver will still create the backlight interface for it; and g-s-d will prefer to use the firmware interface(acpi_video0) than the native one(intel_backlight in this case) and we still have problem(hotkey can deliver this time, but backlight change will have no effect). Please don't get me wrong, I like small changes too, but in this case, I just don't see how to avoid "big" changes.
(In reply to comment #59) > (In reply to comment #58) > > From my position, I will send this patch on comment#57 after Andrzej has > well > > testing with it. > > This will not work, at least when GNOME is used. For other GUIs, I don't > know. > > The reason: if we do not call acpi_video_unregister, the acpi video driver > will > still create the backlight interface for it; and g-s-d will prefer to use the > firmware interface(acpi_video0) than the native one(intel_backlight in this > case) and we still have problem(hotkey can deliver this time, but backlight > change will have no effect). > > Please don't get me wrong, I like small changes too, but in this case, I just > don't see how to avoid "big" changes. hm... you are right, the acer-wmi loaded after acpi/video driver loaded, call acpi_video_dmi_promote_vendor() in acer-wmi is too late for block the acpi/video create backlight interface. But I still prefer don't touch other old machines but only against the Aspire 5750G on this issue.
(In reply to comment #60) > But I still prefer don't touch other old machines but only against the Aspire > 5750G on this issue. May I know why? I'm pretty sure the systems listed in video_vendor_dmi_table all have broken implementation of acpi backlight interface, so why we can't move them to video_detect.c and eliminate the code(promote_vendor and unregister call) in acer-wmi?
(In reply to comment #61) > (In reply to comment #60) > > But I still prefer don't touch other old machines but only against the > Aspire > > 5750G on this issue. > > May I know why? I'm pretty sure the systems listed in video_vendor_dmi_table > all have broken implementation of acpi backlight interface, so why we can't > move them to video_detect.c and eliminate the code(promote_vendor and > unregister call) in acer-wmi? The reason is testing, after move those machines to video_detect.c means we want block the blacklight interface generated but still keep the video.c emit keycode of backlight change. In the BIOS of those machines may emit keycode by EC or have potential problem with other stuff in acpi/video, e.g. video probe or video switch. So, the key point is need testing to make sure there have no side effect after we add acpi/video driver back on those machines. For Aspire 5750G, yes, no problem after our good testing, but it should not assume other machines in the blacklist that have the same result as we expect.
(In reply to comment #62) > > The reason is testing, after move those machines to video_detect.c means we > want block the blacklight interface generated but still keep the video.c emit > keycode of backlight change. Right. > > In the BIOS of those machines may emit keycode by EC or have potential > problem > with other stuff in acpi/video, e.g. video probe or video switch. So, the key > point is need testing to make sure there have no side effect after we add > acpi/video driver back on those machines. It would be good to know what exactly the problem is, or we may never be able to move them :-) > > For Aspire 5750G, yes, no problem after our good testing, but it should not > assume other machines in the blacklist that have the same result as we > expect. OK, then I'll update the patch to only cover the affected systems. And for 5750G, I'll need to move 5750. Are you OK with this?
(In reply to comment #63) > (In reply to comment #62) > > > > The reason is testing, after move those machines to video_detect.c means we > > want block the blacklight interface generated but still keep the video.c > emit > > keycode of backlight change. > > Right. > > > > > In the BIOS of those machines may emit keycode by EC or have potential > problem > > with other stuff in acpi/video, e.g. video probe or video switch. So, the > key > > point is need testing to make sure there have no side effect after we add > > acpi/video driver back on those machines. > > It would be good to know what exactly the problem is, or we may never be able > to move them :-) > Need volunteer help to testing, I think just wait machine owner complaint for their backlight key control. If nobody complaint means it works fine or they don't care it. > > > > For Aspire 5750G, yes, no problem after our good testing, but it should not > > assume other machines in the blacklist that have the same result as we > expect. > > OK, then I'll update the patch to only cover the affected systems. And for > 5750G, I'll need to move 5750. Are you OK with this? Looks the difference between 5750G with 5750 is 5750G applied Nvidia discrete graphics to enhance the performance of graphics but 5750 used Intel integrated graphics. There has risk for they has different behavior but Intel integrated graphics should have better suitability then Nvidia chip. If the acpi/video works fine on 5750G, then I am OK move 5750.
(In reply to comment #64) > > Need volunteer help to testing, I think just wait machine owner complaint for > their backlight key control. If nobody complaint means it works fine or they > don't care it. I agree. So does this mean you are ok to move all systems from acer-wmi to video_detect.c? > Looks the difference between 5750G with 5750 is 5750G applied Nvidia discrete > graphics to enhance the performance of graphics but 5750 used Intel > integrated > graphics. > There has risk for they has different behavior but Intel integrated graphics > should have better suitability then Nvidia chip. > > If the acpi/video works fine on 5750G, then I am OK move 5750. Cool. BTW, I just realized that, if acer-wmi does not remove the promote_vendor and acpi_video_unregister calls, then we will still need your patch in comment #57 to make sure acpi_video_unregister is not called for 5750G. So please let me know what do you think, so that we can move to the next step. Thanks.
Should I still test patch from comment #57? It seems you agreed that it won't work. ;-)
(In reply to comment #65) > (In reply to comment #64) > > > > Need volunteer help to testing, I think just wait machine owner complaint > for > > their backlight key control. If nobody complaint means it works fine or > they > > don't care it. > > I agree. So does this mean you are ok to move all systems from acer-wmi to > video_detect.c? > NO! please only move 5750G/5750 to video_detect.c at this moment, unless there have other machine owner complain backlight key. > > Looks the difference between 5750G with 5750 is 5750G applied Nvidia > discrete > > graphics to enhance the performance of graphics but 5750 used Intel > integrated > > graphics. > > There has risk for they has different behavior but Intel integrated > graphics > > should have better suitability then Nvidia chip. > > > > If the acpi/video works fine on 5750G, then I am OK move 5750. > > Cool. > > BTW, I just realized that, if acer-wmi does not remove the promote_vendor and > acpi_video_unregister calls, then we will still need your patch in comment > #57 > to make sure acpi_video_unregister is not called for 5750G. So please let me > know what do you think, so that we can move to the next step. Thanks. How about create a new acpi function? e.g. acpi_video_backlight_unregister
(In reply to comment #66) > Should I still test patch from comment #57? It seems you agreed that it won't > work. ;-) Yes, don't need to test it until new patch generated, thanks a lot!
Created attachment 97261 [details] 0001-acpi-video-add-function-for-unregister-backlight-i.patch Unregister whole acpi/video driver may not we want when ACPI backlight implementation does no work on this machine. This patch add new function for only unregister backlight interface. Hi all acpi expert, How do you think? Thanks
Created attachment 97271 [details] 0001-acpi-video-add-function-for-unregister-backlight-i.patch Created an attachment (id=97261) [details] 0001-acpi-video-add-function-for-unregister-backlight-i.patch Unregister whole acpi/video driver may not we want when ACPI backlight implementation does no work on this machine. This patch add new function for only unregister backlight interface. Hi all acpi expert, This is a draft patch doesn't testing yet. How do you think? Thanks
Created attachment 97281 [details] 0001-acer-wmi-add-Acer-Aspire-5750G-to-video-vendor-list-.patch Respin the patch on comment#57 against acpi_video_backlight_unregister(). Remove whole acpi/video driver when backlight support broken that causes we lost other function of acpi/video, only unregister the backlight device of acpi/video is another thinking.
That's something I would like to avoid as explained here: https://bugzilla.kernel.org/show_bug.cgi?id=51051#c31 Especially when we don't understand the problem clearly, adding too much quirk code make it hard for people to understand what happened.
Perhaps it's time to raise this to mailinglist for a discussion.
Do you want me to test those two patches? Because I'm a little confused now. ;-) Also, should I look at some other bug/mailing list thread/etc? I can always test anything you come up with regarding this bug (since I own this laptop), but I have to know where to look.
(In reply to comment #74) > Do you want me to test those two patches? Because I'm a little confused now. > ;-) > > Also, should I look at some other bug/mailing list thread/etc? I can always > test anything you come up with regarding this bug (since I own this laptop), > but I have to know where to look. Sorry for I sticky on other issue at last week, I will clear up my 2 patches and attached here again. Please help to test them, thanks.
Created attachment 98851 [details] 0001-acpi-video-add-function-to-support-unregister-backli.patch This patch add a function on acpi/video to unregister backlight interface of acpi video devices. This function used by downstream driver, like acer-wmi for tell acpi/video to unregister backlight.
Hi Andrzej, Please help to apply/test the following 2 patches on your machine: + On comment#76: 0001-acpi-video-add-function-to-support-unregister-backli.patch + On comment#71: 0001-acer-wmi-add-Acer-Aspire-5750G-to-video-vendor-list-.patch Please apply both of them, I tested it works to me on my acer machine for removed all backlight interface of acpi/video but still keep the intel_backlight. Please remove 'acpi_backlight=vendor' or 'acpi_osi="Linux"' when you testing. Thanks a lot!
(In reply to comment #77) > Hi Andrzej, > > Please help to apply/test the following 2 patches on your machine: > > + On comment#76: > 0001-acpi-video-add-function-to-support-unregister-backli.patch > + On comment#71: > 0001-acer-wmi-add-Acer-Aspire-5750G-to-video-vendor-list-.patch > acer_wmi: Brightness must be controlled by generic video driver acer_wmi: Brightness must be controlled by generic video driver acer_wmi: Keep acpi video driver for emit keycode against backlight change /sys/class/backlight/intel_backlight - PRESENT /sys/class/backlight/acpi_video0 - MISSING RESULT: Buttons work, KDE controls work.
(In reply to comment #78) > (In reply to comment #77) > > Hi Andrzej, > > > > Please help to apply/test the following 2 patches on your machine: > > > > + On comment#76: > > 0001-acpi-video-add-function-to-support-unregister-backli.patch > > + On comment#71: > > 0001-acer-wmi-add-Acer-Aspire-5750G-to-video-vendor-list-.patch > > > > acer_wmi: Brightness must be controlled by generic video driver > acer_wmi: Brightness must be controlled by generic video driver > acer_wmi: Keep acpi video driver for emit keycode against backlight change > > /sys/class/backlight/intel_backlight - PRESENT > /sys/class/backlight/acpi_video0 - MISSING > > RESULT: Buttons work, KDE controls work. Thanks for your testing, I just sent out patches to ACPI and platform driver mail address for review. I think either we create unregister backlight interface or put quirk table acpi/video, this issue can be fixed.
ACPI video module is removed by acer-wmi, while it is required to handle hotkey notificaions. I think Lee will take care of this, re-assign to platform_x86 drivers.
(In reply to Aaron Lu from comment #80) > ACPI video module is removed by acer-wmi, while it is required to handle > hotkey notificaions. I think Lee will take care of this, re-assign to > platform_x86 drivers. OK, base on ACPI upstream's conclusion, acpi/video driver handle the backlight_quirks when detected OSI = Windows 8. To acer-wmi driver's position, I will handle the other machines that's OSI = Windows 7. Due to acpi/video driver already unregistr by acer-wmi but causes nobody handle the backlight hotkey. I will add a patch for add the hotkey handler to acer-wmi when we choice unregister acpi/video driver.
Are there any news about this bug? I'm having the same issues on an Acer Aspire 5742G laptop.
Are there any patches I should try for my Acer 5742G laptop ?
Booting with "video.use_native_backlight=1" fixed all my backlight issues. I just found out about this kernel parameter. Using it successfully remove acpi_video0 and acpi_video1, so the system (and KDE) only makes use of intel_backlight, which is correct.
Please attach the dmi info and acpidump for your Acer Aspire 5742G: # dmidecode > dmi_5742g.info # acpidump > acpidump_5742g.txt Thanks.
Created attachment 123561 [details] acpi dump for 5742g
Created attachment 123571 [details] dmi for 5742g
BTW this is a Windows 7 laptop, if that matters, as I've seen your patch says video.use_native_backlight=1 is mainly for Windows 8 laptops.
(In reply to AnAkkk from comment #88) > BTW this is a Windows 7 laptop, if that matters, as I've seen your patch > says video.use_native_backlight=1 is mainly for Windows 8 laptops. The firmware of your laptop claimed support of Win8 so the OS would assume this is a Win8 compatible firmware :-)
I just meant that when I bought it, Windows 7 was pre-installed :) What are the next steps, will use_native_back_light be set to 1 by default for my laptop ?
Well, I'm not sure at the moment. Keep an eye on linux-acpi mainling list, there may be some news.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0e9f81d3b7cd0649a3bc437391b6a0650f98f844 Any reason Acer Aspire 5742G hasn't been added to this list? :(
Actually something must have changed in 3.14-rc4, neither my backlight key nor my wireless key work. Everything worked fine in rc3. (use_native_back_light is still set to 1)
Changing /sys/class/backlight/intel_backlight/brightness still work fine, it's just the keys that do not do anything. There is only intel_backlight in /sys/class/backlight.
Lee, Is it safe to say all Acer Aspire laptops that has _OSI("Windows 2012") query in their ACPI table will have a working GPU backlight interface? I was wondering how to control the length of the DMI table.
(In reply to AnAkkk from comment #94) > Changing /sys/class/backlight/intel_backlight/brightness still work fine, > it's just the keys that do not do anything. There is only intel_backlight in > /sys/class/backlight. Please do a git bisect to find out the offending commit that breaks your hotkey, thanks.
First, I'd say sorry for my late because I confused the module type of 5742G and 5750G. (In reply to Aaron Lu from comment #95) > Lee, > > Is it safe to say all Acer Aspire laptops that has _OSI("Windows 2012") > query in their ACPI table will have a working GPU backlight interface? I was > wondering how to control the length of the DMI table. Unfortunately there have many old Acer Aspire Laptops BIOS doesn't support Windows 2012. Especially there have some model support Windows 7 but their ACPI _BCM is fine. As the cases attached on this bug, DSDT of Acer Aspire 5750G only supports Windows 2009. But, the DSDT of AnAkkk's Acer Aspire 5742G supports Windows 2012. I think Aspire 5742G should add to video_dmi_table as 0e9f81d3 patch, but Aspire 5750G should add to acer-wmi, and need careful for emit keycode.
(In reply to Aaron Lu from comment #96) > (In reply to AnAkkk from comment #94) > > Changing /sys/class/backlight/intel_backlight/brightness still work fine, > > it's just the keys that do not do anything. There is only intel_backlight > in > > /sys/class/backlight. > > Please do a git bisect to find out the offending commit that breaks your > hotkey, thanks. Well, for some reason it doesn't work anymore with my 3.13 kernel either, so I guess the issue is not in the kernel after all.
Ok, I think the 3.13.5 kernel I tested on, had the same commit that caused these issues. I've started bisecting and it now works fine. I'll continue tomorrow to find out the bad commit. (I opened a different issue for these problems, as they're unrelated https://bugzilla.kernel.org/show_bug.cgi?id=71221)
(In reply to Lee, Chun-Yi from comment #97) > I think Aspire 5742G should add to video_dmi_table as 0e9f81d3 patch, but > Aspire 5750G should add to acer-wmi, and need careful for emit keycode. OK, thanks for the info. Then I will make sure AnAkkk's Aspire 5750G works fine with video.use_native_backlight=1 before adding it to the DMI table.
(In reply to Aaron Lu from comment #100) > (In reply to Lee, Chun-Yi from comment #97) > > I think Aspire 5742G should add to video_dmi_table as 0e9f81d3 patch, but > > Aspire 5750G should add to acer-wmi, and need careful for emit keycode. > > OK, thanks for the info. Then I will make sure AnAkkk's Aspire 5750G works > fine with video.use_native_backlight=1 before adding it to the DMI table. Just wonder... We need maintain this DMI table until Intel video driver works on all Windows 8 machines for backlight control? How can we know the Intel driver ready for all issue machines?
(In reply to Aaron Lu from comment #100) > (In reply to Lee, Chun-Yi from comment #97) > > I think Aspire 5742G should add to video_dmi_table as 0e9f81d3 patch, but > > Aspire 5750G should add to acer-wmi, and need careful for emit keycode. > > OK, thanks for the info. Then I will make sure AnAkkk's Aspire 5750G works > fine with video.use_native_backlight=1 before adding it to the DMI table. Mine is a 5742G.
Hello all, I hope I am posting this in the right place. I have an Acer Aspire One, model D257 with intel integrated graphics. The backlight control buttons always worked out of the box with no special kernel parameters until 3.13. Upon upgrading to 3.13, -brightness went to max -fn brightness keys are non-responsive -# ls /sys/class/backlight/ acpi_video0 intel_backlight Before the patch, acpi_video0 did not exist. I believe it to be the culprit. I added the video.use_native_backlight=1 parameter to my kernel line in grub. Nothing changed. I then added /etc/X11/xorg.conf.d/20-intel.conf Section "Device" Identifier "card0" Driver "intel" Option "Backlight" "intel_backlight" BusID "PCI:0:2:0" EndSection With the xorg pointer and the kernel parameter, my computer now boots at previously set backlight level, but the fn+brightness keys still do not work. This is my first time posting a bug, so please let me know what other information you would find helpful. Thanks. Here is the discussion thread about my problem:https://bbs.archlinux.org/viewtopic.php?pid=1388092
(In reply to Lee, Chun-Yi from comment #101) > (In reply to Aaron Lu from comment #100) > > (In reply to Lee, Chun-Yi from comment #97) > > > I think Aspire 5742G should add to video_dmi_table as 0e9f81d3 patch, but > > > Aspire 5750G should add to acer-wmi, and need careful for emit keycode. > > > > OK, thanks for the info. Then I will make sure AnAkkk's Aspire 5750G works > > fine with video.use_native_backlight=1 before adding it to the DMI table. > > Just wonder... > > We need maintain this DMI table until Intel video driver works on all > Windows 8 machines for backlight control? How can we know the Intel driver Yes... > ready for all issue machines? I don't know, it seems all we can do right now is to add systems that report broken backlight and works with use_native_backlight to the video module's DMI table.
(In reply to Joshua Brown from comment #103) > Hello all, I hope I am posting this in the right place. I have an Acer > Aspire One, model D257 with intel integrated graphics. The backlight > control buttons always worked out of the box with no special kernel > parameters until 3.13. > > Upon upgrading to 3.13, > > -brightness went to max > -fn brightness keys are non-responsive > -# ls /sys/class/backlight/ > acpi_video0 intel_backlight > > Before the patch, acpi_video0 did not exist. I believe it to be the culprit. > > I added the video.use_native_backlight=1 parameter to my kernel line in > grub. Nothing changed. > > I then added > /etc/X11/xorg.conf.d/20-intel.conf > Section "Device" > Identifier "card0" > Driver "intel" > Option "Backlight" "intel_backlight" > BusID "PCI:0:2:0" > > EndSection > > With the xorg pointer and the kernel parameter, my computer now boots at > previously set backlight level, but the fn+brightness keys still do not work. > > This is my first time posting a bug, so please let me know what other > information you would find helpful. > > Thanks. Here is the discussion thread about my > problem:https://bbs.archlinux.org/viewtopic.php?pid=1388092 It's a different issue so please file a new bug under ACPI/Power-Video category and attach acpidump there.
(In reply to Aaron Lu from comment #105) > It's a different issue so please file a new bug under ACPI/Power-Video > category and attach acpidump there. Done, thank you. If interested, it is @ https://bugzilla.kernel.org/show_bug.cgi?id=71491
AnAkkk, What's the status of the bisect? Do I understand correctly that even with video.use_native_backlight=1 your laptop doesn't have a working backlight hotkey now?
The bisect was for the other issue (https://bugzilla.kernel.org/show_bug.cgi?id=71221), which happens randomly on pretty much all kernels, so it turned out to be useless. The backlight hotkey works fine when I use video.use_native_backlight=1 on 3.14-rc6. I guess it just needs adding 5742G to the dmi table now :)
Created attachment 131661 [details] Add Acer Aspire 5742G into the video native backlight table Hi AnAkkk, Can you please verify this patch? Thanks.
(In reply to Aaron Lu from comment #109) > Created attachment 131661 [details] > Add Acer Aspire 5742G into the video native backlight table > > Hi AnAkkk, > > Can you please verify this patch? Thanks. Indeed, this patch fixes the issue. I no longer need to use video.use_native_backlight=1. It's not easy to test though as I'm pretty much affected all the time by #71221 now.
[Aspire 5742G-SomeextragibberishIcanonlyseeinbiosmenu] Intel i5-M540 + Nvidia GT540M version (<- Do they sync their model names? oO How much I hate this laptop.... I have that Backlight madness too. Currently on archs latest kernel build 3.14.4-1-ARCH #1. No Virtualbox modules loaded. As someone in Bug 71221 had. I have 3 entries in /sys/class/backlight acpi_video0,acpi_video1,intel_backlight Only intel_backlight works. Hotkeys for backlight dont. With acpi_backlight=vendor the hotkeys work, until they stop doing it. Sometimes after 2 minutes, sometimes after 10 minutes. When they dont work they crash my xserver. When they dont work they try acpi_video0. I dont even... I eyed through the kernel config, seems pretty unspecific. Acpi is of course active and acer wmi is as module and loaded. arch-patch-titles dont look like they mess with acpi or acer quirks. Logdumps when I have my sanity back. I wonder what works on that thing. I will coffee nao.
The issue was fixed for 5742G in kernel 3.15-rc6.
(In reply to AnAkkk from comment #112) > The issue was fixed for 5742G in kernel 3.15-rc6. Closing. Please file any new/remaining drm/i915 bugs at https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel