On my Fujitsu Lifebook E753 I experienced some "regressions" with current kernel versions (e.g. 3.9.7) compared to linux 3.5 (used in Ubuntu 12.04 for instance): - on bootup backlight is extremely dark (I can change it though) - the wireless button does not work any more Recently I did a bisect and found out, that the "regression" was introduced with commit "a57f7f9175b8ccbc9df83ac13860488913115de4". Searching the internet I read about a bootloader option "acpi_osi="!Windows 2012" which solved the issue for me. I reported it on the linux-acpi mailing list and was asked to report it here and add a acpidump. Perhaps I have done something wrong but all I get is: Linux version not implemented yet Could not get ACPI tables, AE_SUPPORT If you need some additional information tell me. Thanks.
Please "git clone git://github.com/acpica/acpica.git" and "make && make install" Try acpidump again.
Created attachment 106081 [details] acpidump Ok, find attached the acpidump output.
Created attachment 106091 [details] errors acpidump threw some errors which are attached.
Created attachment 106101 [details] acpidump without boot option Booting without "acpi_osi="!Windows 2012" gives a different acpidump which is attached.
Please add kernel param "video.use_bios_initial_backlight=0" and check whether this resolves bootup backlight issue. For wireless key, it's in charge of fujitsu-laptop platform driver and it doesn't follow ACPI spec. So it is out of ACPI scope.
Yes, using this kernel parameter also resolves the backlight issue. Thank you. However, if I remove the "acpi_osi="!Windows 2012" parameter, my wireless key is not working any more. So should I contact the fujitsu-laptop guys?
Please provide the output of dmidecode and I can do a quirk for this machine. Your can apply a bug to drivers product and platform_x86 component for the wireless button bug.
Created attachment 106221 [details] dmidecode Ok, thanks. Find attached the dmidecode. It was created with boot parameter "acpi_osi="!Windows 2012"". If this has any influence and you need the dmidecode without or with another boot parameter - tell me.
Please try this patch without any kernel param and backlight should work on bootup. diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index 5d7075d..e441876 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -450,6 +450,14 @@ static struct dmi_system_id video_dmi_table[] __initdata = { }, { .callback = video_ignore_initial_backlight, + .ident = "Fujitsu E753", + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "FUJITSU"), + DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK E753"), + }, + }, + { + .callback = video_ignore_initial_backlight, .ident = "HP Pavilion dm4", .matches = { DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
Yes, it works as intended now. Thank you. I had to change one line to apply the patch, though: .ident = "HP Pavilion dm4", failed. With: .ident = "HP Pavilion m4", it worked, so I guess it was a typo?
No, I think your tree lack the follow commit. I base on linux-pm bleeding-edge branch. Which kernel you apply the patch? Can you try v3.10-rc7? commit 771d09b3c4c45d4d534a83a68e6331b97fd82e15 Author: Gustavo Maciel Dias Vieira <gustavo@sagui.org> Date: Mon Mar 4 15:23:37 2013 +0000 ACPI video: ignore BIOS backlight value for HP dm4 On a HP Pavilion dm4 laptop the BIOS sets minimum backlight on boot, completely dimming the screen. Ignore this initial value for this machine. Signed-off-by: Gustavo Maciel Dias Vieira <gustavo@sagui.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index 313f959..f8a28b3 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -447,6 +447,14 @@ static struct dmi_system_id video_dmi_table[] __initdata = { DMI_MATCH(DMI_PRODUCT_NAME, "HP Folio 13 - 2000 Notebook PC"), }, }, + { + .callback = video_ignore_initial_backlight, + .ident = "HP Pavilion dm4", + .matches = { + DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"), + DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion dm4 Notebook PC"), + }, + }, {} };
You are right, sorry. I used the current stable tree. With rc7 the patch applies.
Thanks for test. I will send this patch to ACPI maillist soon.
You're welcome. Thank you for the quick response and help.
Author: Lan Tianyu <tianyu.lan@intel.com> Date: Tue Jul 16 10:07:21 2013 +0800 ACPI / video: ignore BIOS initial backlight value for Fujitsu E753 entered Linus's tree as of v3.11-rc2.
We have a patch to solve all these initial black screen problem: commit 2c62333a408f5badd2d2ffd7177f95deeccc5ca4 Author: Aaron Lu <aaron.lu@intel.com> Date: Wed Nov 6 09:07:10 2013 +0800 ACPI / video: Quirk initial backlight level 0 It is now in Rafael's linux-next branch: http://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git Can someone please kindly give it a test? If confirmed, we can save an entry in the DMI table, thanks. When using that branch, please manually remove the corresponding entry for your system in the DMI table, or the test is obviously useless :-)
For easy testing, I've prepared a branch for you: https://github.com/aaronlu/linux acpi_video_dmi It is based on Rafael's linux-next branch(thus it already has the above mentioned fix patch), with only one patch on top: Remove the affected system from the DMI table to test if the above mentioned fix patch can work for it.
Sry for my late response. I saw you already applied the patch and I can confirm, that it works for my Fujitsu E753, too. Thanks! Just FYI: There is one short stage in the boot process, when the screen gets darker. It is reset to normal after half a second or sth, but this is different to the behaviour beforehand.
(In reply to Jan Hinnerk Stosch from comment #18) > Sry for my late response. I saw you already applied the patch and I can > confirm, that it works for my Fujitsu E753, too. > Thanks! Thanks for the confirm! > > Just FYI: > There is one short stage in the boot process, when the screen gets darker. > It is reset to normal after half a second or sth, but this is different to > the behaviour beforehand. Not sure what caused this, that commit alone shouldn't affect it in my opinion.
(In reply to Aaron Lu from comment #19) > Not sure what caused this, that commit alone shouldn't affect it in my > opinion. Ok, I'll try to find out more details if I get some time. Thanks anyway..