- 24 9月, 2016 1 次提交
-
-
由 zino lin 提交于
acpi_video0 doesn't work, asus-wmi brightness interface doesn't work, too. So, we use native brightness interface to handle the brightness adjustion, and add quirk_asus_ux303ub. Signed-off-by: Nzino lin <linzino7@gmail.com> Acked-by: NCorentin Chary <corentin.chary@gmail.com> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
- 02 7月, 2016 1 次提交
-
-
由 João Paulo Rechi Vita 提交于
Some Asus laptops that have an airplane-mode indicator LED, also have the WMI WLAN user bit set, and the following bits in their DSDT: Scope (_SB) { (...) Device (ATKD) { (...) Method (WMNB, 3, Serialized) { (...) If (LEqual (IIA0, 0x00010002)) { OWGD (IIA1) Return (One) } } } } So when asus-wmi uses ASUS_WMI_DEVID_WLAN_LED (0x00010002) to store the wlan state, it drives the airplane-mode indicator LED (through the call to OWGD) in an inverted fashion: the LED is ON when airplane mode is OFF (since wlan is ON), and vice-versa. This commit creates a quirk to not register a RFKill switch at all for these laptops, to allow the asus-wireless driver to drive the airplane mode LED correctly through the ASHS ACPI device. It also adds a match to that quirk for the Asus X555UB, which is affected by this problem. Signed-off-by: NJoão Paulo Rechi Vita <jprvita@endlessm.com> Reviewed-by: NCorentin Chary <corentin.chary@gmail.com> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
- 28 5月, 2016 1 次提交
-
-
由 Oleksij Rempel 提交于
Asus Zenbook ux31a is providing ACPI0008 interface for ALS (Ambient Light Sensor), which is accessible for OS => Win 7. This sensor can be used with iio/acpi-als driver. Since it is disabled by default, we should use asus-wmi interface to enable it. Signed-off-by: NOleksij Rempel <linux@rempel-privat.de> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
- 20 1月, 2016 1 次提交
-
-
由 Geliang Tang 提交于
to_platform_driver has been defined in platform_device.h, so drop this repetitive macro in asus-wmi.c. Signed-off-by: NGeliang Tang <geliangtang@163.com> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
- 11 11月, 2015 1 次提交
-
-
由 Dan Carpenter 提交于
The asus_wmi_get_devstate_simple() returns 0-1 on success. In theory according to static checkers, it can return either -EIO or -ENODEV on failure. Currently the error handling code only handles -ENODEV and -EIO is treated as success. Let's make it handle the -EIO error as well. It's possible that it can't actually return -EIO and this patch is not needed but in that case this patch is harmless and silences a static checker warning so it's still worth it. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
- 10 10月, 2015 1 次提交
-
-
由 Rasmus Villemoes 提交于
The macros KELVIN_TO_CELSIUS and CELSIUS_TO_KELVIN actually convert between deciKelvins and Celsius, so rename them to reflect that. While at it, use a statement expression in DECI_KELVIN_TO_CELSIUS to prevent expanding the argument multiple times and get rid of a few casts. Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk> Acked-by: NDarren Hart <dvhart@linux.intel.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
- 03 10月, 2015 1 次提交
-
-
由 Oleksij Rempel 提交于
Afters suspend/resume cycle with closed lid the kbd backlight level is lost. This patch will will restore this value to last known level. Signed-off-by: NOleksij Rempel <linux@rempel-privat.de> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
- 19 6月, 2015 2 次提交
-
-
由 Hans de Goede 提交于
Port the backlight selection logic to the new backlight interface selection API. This commit also removes various obsolete pr_xxx messages related to backlight interface selection. These are obsolete because they assume there is only a vendor or acpi backlight driver and no other choice. Also they are not necessary, if the user wants to know which backlight interfaces are registered a simple "ls /sys/class/backlight" suffices. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NDarren Hart <dvhart@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Hans de Goede 提交于
acpi_video_unregister() not only unregisters the acpi-video backlight interface but also unregisters the acpi video bus event listener, causing e.g. brightness hotkey presses to no longer generate keypress events. The unregistering of the acpi video bus event listener usually is undesirable, which by itself is a good reason to switch to acpi_video_unregister_backlight(). Another problem with using acpi_video_unregister() rather then using acpi_video_unregister_backlight() is that on systems with an intel video opregion (most systems) and a wmi_backlight_power quirk, whether or not the acpi video bus event listener actually gets unregistered depends on module load ordering: Scenario a: 1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there is an intel opregion. 2) intel.ko gets loaded, calls acpi_video_register() which registers both the listener and the acpi backlight interface 3) asus-wmi.ko gets loaded, calls acpi_video_unregister() causing both the listener and the acpi backlight interface to unregister Scenario b: 1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there is an intel opregion. 2) asus-wmi.ko gets loaded, calls acpi_video_dmi_promote_vendor(), calls acpi_video_unregister(), which is a nop since acpi_video_register has not yet been called 2) intel.ko gets loaded, calls acpi_video_register() which registers the listener, but does not register the acpi backlight interface due to the call to the preciding call to acpi_video_dmi_promote_vendor() *) acpi/video.ko always loads first as both other modules depend on it. So we end up with or without an acpi video bus event listener depending on module load ordering, not good. Switching to using acpi_video_unregister_backlight() means that independ of ordering we will always have an acpi video bus event listener fixing this. Note that this commit means that systems without an intel video opregion, and systems which were hitting scenario a wrt module load ordering, are now getting an acpi video bus event listener while before they were not! On some systems this may cause the brightness hotkeys to start generating keypresses while before they were not (good), while on other systems this may cause the brightness hotkeys to generate multiple keypress events for a single press (not so good). Since on most systems the acpi video bus is the canonical source for brightness events I believe that the latter case will needs to be handled on a case by case basis by filtering out the duplicate keypresses at the other source for them. Cc: Corentin Chary <corentin.chary@gmail.com> Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: NDarren Hart <dvhart@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 08 6月, 2015 1 次提交
-
-
由 Hans de Goede 提交于
acpi_video_unregister() not only unregisters the acpi-video backlight interface but also unregisters the acpi video bus event listener, causing e.g. brightness hotkey presses to no longer generate keypress events. The unregistering of the acpi video bus event listener usually is undesirable, which by itself is a good reason to switch to acpi_video_unregister_backlight(). Another problem with using acpi_video_unregister() rather then using acpi_video_unregister_backlight() is that on systems with an intel video opregion (most systems) and a wmi_backlight_power quirk, whether or not the acpi video bus event listener actually gets unregistered depends on module load ordering: Scenario a: 1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there is an intel opregion. 2) intel.ko gets loaded, calls acpi_video_register() which registers both the listener and the acpi backlight interface 3) asus-wmi.ko gets loaded, calls acpi_video_unregister() causing both the listener and the acpi backlight interface to unregister Scenario b: 1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there is an intel opregion. 2) asus-wmi.ko gets loaded, calls acpi_video_dmi_promote_vendor(), calls acpi_video_unregister(), which is a nop since acpi_video_register has not yet been called 2) intel.ko gets loaded, calls acpi_video_register() which registers the listener, but does not register the acpi backlight interface due to the call to the preciding call to acpi_video_dmi_promote_vendor() *) acpi/video.ko always loads first as both other modules depend on it. So we end up with or without an acpi video bus event listener depending on module load ordering, not good. Switching to using acpi_video_unregister_backlight() means that independ of ordering we will always have an acpi video bus event listener fixing this. Note that this commit means that systems without an intel video opregion, and systems which were hitting scenario a wrt module load ordering, are now getting an acpi video bus event listener while before they were not! On some systems this may cause the brightness hotkeys to start generating keypresses while before they were not (good), while on other systems this may cause the brightness hotkeys to generate multiple keypress events for a single press (not so good). Since on most systems the acpi video bus is the canonical source for brightness events I believe that the latter case will needs to be handled on a case by case basis by filtering out the duplicate keypresses at the other source for them. Cc: acpi4asus-user@lists.sourceforge.net Signed-off-by: NHans de Goede <hdegoede@redhat.com> Acked-by: Corentin Chary <corentin.chary@gmail.com) Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
- 14 5月, 2015 1 次提交
-
-
由 Kast Bernd 提交于
This patch is partially based on Felipe Contrera's earlier patch, that was discussed here: https://lkml.org/lkml/2013/10/8/800 Some problems of that patch are solved, now: 1) The main obstacle for the earlier patch seemed to be the use of virt_to_phys, which is accepted, now 2) random memory corruption occurred on my notebook, thus DMA-able memory is allocated now, which solves this problem 3) hwmon interface is used instead of the thermal interface, as a hwmon device is already set up by this driver and seemed more appropriate than the thermal interface 4) Calling the ACPI-functions was modularized thus it's possible to call some multifunctions easily, now (by using asus_wmi_evaluate_method_agfn). Unfortunately the WMI doesn't support controlling both fans on a dual-fan notebook because of an restriction in the acpi-method "SFNS", that is callable through the wmi. If "SFNV" would be called directly even dual fan configurations could be controlled, but not by using wmi. Speed readings only work on auto-mode, thus "-1" will be reported in manual mode. Additionally the speed readings are reported as hundreds of RPM thus they are not too precise. This patch is tested only on one notebook (N551JK) but a similar module, that contained some code to try to control the second fan also, was reported to work on an UX32VD, at least for the first fan. As Felipe already mentioned the low-level functions are described here: http://forum.notebookreview.com/threads/fan-control-on-asus-prime-ux31-ux31a-ux32a-ux32vd.705656/Signed-off-by: NKast Bernd <kastbernd@gmx.de> Acked-by: NCorentin Chary <corentin.chary@gmail.com> Cc: Corentin Chary <corentin.chary@gmail.com> Cc: Darren Hart <dvhart@infradead.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
- 04 12月, 2014 1 次提交
-
-
由 Markus Elfring 提交于
The backlight_device_unregister() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net> For msi-wmi.c: Acked-by: NAnisse Astier <anisse@astier.eu> Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
-
- 16 8月, 2014 3 次提交
-
-
由 AceLan Kao 提交于
Wifi will be controlled by asus-wmi driver when wapf > 0 So, controls the wifi-led when wapf > 0 Signed-off-by: NAceLan Kao <acelan.kao@canonical.com> Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-
由 Hans de Goede 提交于
When bl_power support got added to asus-wmi, the error handling for it was written to ignore -ENODEV, to avoid not registering a backlight interface for models which have no bl_power control, but do have brightness control. At the same time the error handling for brightness_max was modified to do the same, this is wrong, when there is no brightness_max asus-wmi should not register a backlight interface. Note the caller of asus_wmi_backlight_init already special cases -ENODEV, and will not cause the wmi driver regristration to fail because of a -ENODEV return from asus_wmi_backlight_init. https://bugzilla.redhat.com/show_bug.cgi?id=1097436Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-
由 Hans de Goede 提交于
Some Asus motherboards for desktop PC-s export an acpi-video interface advertising backlight support. Test the dmi chassis-type and tell acpi-video to not register a backlight interface on desktops. https://bugzilla.redhat.com/show_bug.cgi?id=1097436Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-
- 11 6月, 2014 1 次提交
-
-
由 Rickard Strandqvist 提交于
There is a risk that the variable will be used without being initialized. This was largely found by using a static code analysis program called cppcheck. Signed-off-by: NRickard Strandqvist <rickard_strandqvist@spectrumdigital.se> Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-
- 30 5月, 2014 1 次提交
-
-
由 Yijing Wang 提交于
pci_bus_add_device() always returns 0, so there's no point in returning anything at all. Make it a void function and remove the tests of the return value from the callers. [bhelgaas: changelog, remove unused "err" from i82875p_setup_overfl_dev()] Signed-off-by: NYijing Wang <wangyijing@huawei.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 21 1月, 2014 1 次提交
-
-
由 Guenter Roeck 提交于
Simplify the code and avoid race conditions due to late sysfs attribute registration. Also replace SENSOR_DEVICE_ATTR with DEVICE_ATTR; the additional parameter is not used and thus unnecessary. Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-
- 15 1月, 2014 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Multiple race conditions are possible between the rfkill hotplug in the asus-wmi and eeepc-laptop drivers and the generic PCI bus rescan and device removal that can be triggered via sysfs. To avoid those race conditions make asus-wmi and eeepc-laptop use global PCI rescan-remove locking around the rfkill hotplug. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 07 12月, 2013 1 次提交
-
-
由 Lv Zheng 提交于
Replace direct inclusions of <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h>, which are incorrect, with <linux/acpi.h> inclusions and remove some inclusions of those files that aren't necessary. First of all, <acpi/acpi.h>, <acpi/acpi_bus.h> and <acpi/acpi_drivers.h> should not be included directly from any files that are built for CONFIG_ACPI unset, because that generally leads to build warnings about undefined symbols in !CONFIG_ACPI builds. For CONFIG_ACPI set, <linux/acpi.h> includes those files and for CONFIG_ACPI unset it provides stub ACPI symbols to be used in that case. Second, there are ordering dependencies between those files that always have to be met. Namely, it is required that <acpi/acpi_bus.h> be included prior to <acpi/acpi_drivers.h> so that the acpi_pci_root declarations the latter depends on are always there. And <acpi/acpi.h> which provides basic ACPICA type declarations should always be included prior to any other ACPI headers in CONFIG_ACPI builds. That also is taken care of including <linux/acpi.h> as appropriate. Signed-off-by: NLv Zheng <lv.zheng@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci stuff) Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> (Xen stuff) Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 11 7月, 2013 2 次提交
-
-
由 AceLan Kao 提交于
Controlling the wlan led seems to have some side effects to the machines with wapf value is not equal to 4. It will make the keyboard backlight out of order. So, the patch will enable the wlan led function only if the wapf == 4. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=46791Reported-by: NMirto Silvio Busico <m.busico@ieee.org> Tested-by: NKarol Herbst <karolherbst@me.com> Tested-by: Ndrunkenbatman <drunkenbatman@gmail.com> Signed-off-by: NAceLan Kao <acelan.kao@canonical.com> Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-
由 vic 提交于
Append newline to messages. Signed-off-by: NViktar Vauchkevich <victorenator@gmail.com> Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-
- 27 2月, 2013 2 次提交
-
-
由 Shuah Khan 提交于
Fix the following build warning CC [M] drivers/platform/x86/asus-wmi.o drivers/platform/x86/asus-wmi.c:1356:13: warning: ‘do_nothing’ defined but not used [-Wunused-function] Signed-off-by: NShuah Khan <shuah.khan@hp.com> Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-
由 Corentin Chary 提交于
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com> Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-
- 25 2月, 2013 2 次提交
-
-
由 AceLan Kao 提交于
For machines with AMD graphic chips, it will send out WMI event and ACPI interrupt at the same time while hitting the hotkey. BIOS will notify the system the next display output mode throught WMI event code, so that windows' application can show an OSD to tell the user which mode will be taken effect. User can hit the display toggle key many times within 2 seconds to choose the mode they want. After 2 seconds, WMI dirver should send a WMIMethod(SDSP) command to tell the BIOS which mode the user chose. And then BIOS will raise another ACPI interrupt to tell the system to really switch the display mode. In Linux desktop, we don't have this kind of OSD to let users to choose the mode they want, so we don't need to call WMIMethod(SDSP) to have another ACPI interrupt. To simplify the problem, we just have to ignore the WMI event, and let the first ACPI interrupt to send out the key event. For the need, here comes another quirk to add machines with this kind of behavior. When the WMI driver receives the display toggle WMI event, and found the machin is in the list, it will do nothing and let ACPI video driver to report the key event. Signed-off-by: NAceLan Kao <acelan.kao@canonical.com> Signed-off-by: NCorentin Chary <corentincj@iksaif.net> Signed-off-by: NMatthew Garrett <matthew.garrett@nebula.com>
-
由 AceLan Kao 提交于
For those machines with wapf=4, BIOS won't update the wireless LED, since wapf=4 means user application will take in chage of the wifi and bt. So, we have to update wlan LED status explicitly. But I found there is another wireless LED bug in launchpad and which is not in the wapf=4 quirk. So, it might be better to set wireless LED status explicitly for all machines. BugLink: https://launchpad.net/bugs/901105Signed-off-by: NAceLan Kao <acelan.kao@canonical.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 18 12月, 2012 1 次提交
-
-
由 Corentin Chary 提交于
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 14 9月, 2012 1 次提交
-
-
由 Corentin Chary 提交于
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 18 8月, 2012 1 次提交
-
-
由 AceLan Kao 提交于
If the user bit is set, that mean BIOS can't set and record the wlan status, it will report the value read from id ASUS_WMI_DEVID_WLAN_LED (0x00010012) while we query the wlan status by id ASUS_WMI_DEVID_WLAN (0x00010011) through WMI. So, we have to record wlan status in id ASUS_WMI_DEVID_WLAN_LED (0x00010012) while setting the wlan status through WMI. This is also the behavior that windows app will do. Quote from ASUS application engineer === When you call WMIMethod(DSTS, 0x00010011) to get WLAN status, it may return (1) 0x00050001 (On) (2) 0x00050000 (Off) (3) 0x00030001 (On) (4) 0x00030000 (Off) (5) 0x00000002 (Unknown) (1), (2) means that the model has hardware GPIO for WLAN, you can call WMIMethod(DEVS, 0x00010011, 1 or 0) to turn WLAN on/off. (3), (4) means that the model doesn’t have hardware GPIO, you need to use API or driver library to turn WLAN on/off, and call WMIMethod(DEVS, 0x00010012, 1 or 0) to set WLAN LED status. After you set WLAN LED status, you can see the WLAN status is changed with WMIMethod(DSTS, 0x00010011). Because the status is recorded lastly (ex: Windows), you can use it for synchronization. (5) means that the model doesn’t have WLAN device. WLAN is the ONLY special case with upper rule. For other device, like Bluetooth, you just need use WMIMethod(DSTS, 0x00010013) to get, and WMIMethod(DEVS, 0x00010013, 1 or 0) to set. === Signed-off-by: NAceLan Kao <acelan.kao@canonical.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 28 7月, 2012 3 次提交
-
-
由 AceLan Kao 提交于
According to the ASUS WMI spec., to enable resume on lid open should use the device ID(0x00120032), but it doesn't work indeed. After discussing with ASUS' BIOS engineer, they say wake on lid open doesn't have a uniq device ID(0x00120032) in the BIOS. It shares the same device ID with deep S3(0x00120031), and the deep S3(resume on lid open) is disable by default. Adding this option in asus wmi sysfs /sys/devices/platform/<platform>/lid_resume so that userspace apps can enable/disable this feature by themselves. Signed-off-by: NAceLan Kao <acelan.kao@canonical.com> Signed-off-by: NCorentin Chary <corentin.chary@gmail.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
由 AceLan Kao 提交于
BugLink: https://bugs.launchpad.net/bugs/1000146 Some h/w that can adjust screen brightness through ACPI functions, but can't turn on/off the backlight power correctly. So, we list those h/w in quirks and try to turn on/off the backlight power through WMI. Signed-off-by: NAceLan Kao <acelan.kao@canonical.com> Signed-off-by: NCorentin Chary <corentin.chary@gmail.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
由 Alex Hung 提交于
According to responses from the BIOS team, ASUS_WMI_METHODID_DSTS2 (0x53545344) will be used as future DSTS ID. In addition, calling asus_wmi_evaluate_method(ASUS_WMI_METHODID_DSTS2, 0, 0, NULL) returns ASUS_WMI_UNSUPPORTED_METHOD in new ASUS laptop PCs. This patch fixes no DSTS ID will be assigned in this case. Signed-off-by: NAlex Hung <alex.hung@canonical.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com> Cc: stable@kernel.org
-
- 27 3月, 2012 5 次提交
-
-
由 Corentin Chary 提交于
But we can still do it on other boards, as this might happen if the backlight driver change when update_bl is called. Signed-off-by: NCorentin Chary <corentin.chary@gmail.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
由 Corentin Chary 提交于
Some models work better with different values of wapf, so move the variable into quriks_entry to make it more easy to give a specific value to different models. Based on original patch from AceLan Kao <acelan.kao@canonical.com> Cc: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: NCorentin Chary <corentin.chary@gmail.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
由 AceLan Kao 提交于
Due to some implementation reasons, ASUS ET2012 All-in-One machines can't report the correct backlight power status, it will always return 1. To track the backlight power status correctly, we have to store the status by ourselves. BTW, by the BIOS design, the backlight power will be turn on/off sequently, no matter what the value of the parameter will be. More over, the brightness adjustment command will turn on the backlight power. Those behaviors will make us fail to track the backlight power status. For example, While we are trying to turn on the backlight power, we will send out the brightness adjustment command and then trying to figure out if we have to turn on the backlight power, then send out the command. But, the real case is that, the backlight power turns on while sending the brightness adjustment command, and then we send out the command to turn on the backlight power, it actually will turn off the backlight power and the backlight power status we recorded becomes wrong. So, we have to seperate these two commands by a if statement. Signed-off-by: NAceLan Kao <acelan.kao@canonical.com> Signed-off-by: NCorentin Chary <corentin.chary@gmail.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
由 AceLan Kao 提交于
Some ASUS ET2012E/I All-in-One machines that use a scalar board to control the brightness, and they only accept brightness up and down command. So, I introduced a get_scalar_command() function to pass the command to the scalar board through WMI. Besides, we have to store the brightness value locally, for we need the old value to know the brightness value is increasing or decreasing. BTW, since there is no way to retrieve the actual brightness(it would be a fixed value), and the max brightness value would be fixed to 1, so we have to keep passing the brightness up/down command when we reached the max brightness value or 0. Signed-off-by: NAceLan Kao <acelan.kao@canonical.com> Signed-off-by: NCorentin Chary <corentin.chary@gmail.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
由 Corentin Chary 提交于
Signed-off-by: NCorentin Chary <corentin.chary@gmail.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 28 2月, 2012 1 次提交
-
-
由 Yinghai Lu 提交于
The old pci_remove_bus_device actually did stop and remove. Make the name reflect that to reduce confusion. This patch is done by sed scripts and changes back some incorrect __pci_remove_bus_device changes. Suggested-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NYinghai Lu <yinghai@kernel.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 04 1月, 2012 1 次提交
-
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
-
- 24 10月, 2011 1 次提交
-
-
由 Axel Lin 提交于
This patch fixes wrong test for successful registered led_classdev, and also fixes a leak due to missing led_classdev_unregister call for asus->kbd_led in asus_wmi_led_exit. device_create returns &struct device pointer on success, or ERR_PTR() on error. Thus if led_classdev_register fails, led_cdev->dev is always not NULL. Thus to unregister a successful registered led_classdev, we should check (!IS_ERR_OR_NULL(asus->tpd_led.dev)) instead of (asus->tpd_led.dev). we use IS_ERR_OR_NULL instead of IS_ERR because if we havn't call led_classdev_register, the led_cdev->dev is NULL. Signed-off-by: NAxel Lin <axel.lin@gmail.com> Acked-by: NCorentin Chary <corentin.chary@gmail.com> Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-