Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 18 2月, 2015 1 次提交
  3. 09 2月, 2015 1 次提交
  5. 20 1月, 2015 1 次提交
  7. 07 1月, 2015 1 次提交
  9. 23 12月, 2014 1 次提交
  11. 15 12月, 2014 1 次提交
  13. 01 12月, 2014 1 次提交
  15. 30 10月, 2014 1 次提交
    • A
      ACPI / video: Run _BCL before deciding registering backlight · dce4ec2e
      由 Aaron Lu 提交于 
      The ASUS K53SM's ACPI table queries _OSI("Windows 2012") in the video
output device's _BCL and _BCM control method instead of the usual _INI
functions of the _SB or PCI host bridge PCI0 devices. This made our
video module thought this is a pre-Win8 system when deciding if we
should register a backlight interface for it and the end result is that
a non-working acpi_video interface is registered and user is unable to
control backlight from GUI. Solve this problem by evaluating _BCL control
method before doing the decision.

Note that for some Thinkpad systems, the _BCL is also required to be
evaluated for the hotkey event to be generated no matter if we will
register an ACPI video backlight interface for it or not. Since the
thinkpad_acpi module will do this anyway we didn't add such a thing in
the video module previously. But now with this change here, the
thinkpad_acpi module is no more necessary for those systems regarding
backlight functionality.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=85051Reported-and-tested-by: NRalf Jung <post+kernel@ralfj.de>
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      dce4ec2e
  17. 01 10月, 2014 1 次提交
    • A
      ACPI / video: check _DOD list when creating backlight devices · 0b8db271
      由 Aaron Lu 提交于 
      The _DOD method lists which video output device is currently attached so
we should only care about them and ignore others. An user recently
reported that there are two acpi_video interfaces appeared on his system
and one of them doesn't work. From the acpidump, it is found that there
are more than one video output devices that have _BCM control method but
the _DOD lists only one of them. So this patch checks if the video output
device is in the _DOD list and will not create backlight device if it is
not in the list. Also, we consider the broken _DOD case(reflected by the
video->attached_count is 0) and do not change behaviour for those broken
_DOD systems.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=84111
Reported-and-tested-by: ntrrgc@gmail.com
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0b8db271
  19. 22 9月, 2014 1 次提交
  21. 04 9月, 2014 1 次提交
  23. 02 9月, 2014 3 次提交
  25. 30 7月, 2014 1 次提交
  27. 21 7月, 2014 2 次提交
  29. 16 7月, 2014 1 次提交
  31. 15 7月, 2014 1 次提交
  33. 08 7月, 2014 2 次提交
  35. 06 6月, 2014 1 次提交
  37. 27 5月, 2014 3 次提交
  39. 20 5月, 2014 1 次提交
    • H
      ACPI / video: Add an acpi_video_unregister_backlight function · 1b7f37e1
      由 Hans de Goede 提交于 
      Add an acpi_video_unregister_backlight function, which only unregisters
the backlight device, and leaves the acpi_notifier in place. Some acpi_vendor
driver need this as they don't want the acpi_video# backlight device, but do
need the acpi-video driver for hotkey handling.

Chances are that this new acpi_video_unregister_backlight() is actually
what existing acpi_vendor drivers have wanted all along. Currently acpi_vendor
drivers which want to disable the acpi_video# backlight device, make 2 calls:

acpi_video_dmi_promote_vendor();
acpi_video_unregister();

The intention here is to make things independent of when acpi_video_register()
gets called. As acpi_video_register() will get called on acpi-video load time
on non intel gfx machines, while it gets called on i915 load time on intel
gfx machines.

This leads to the following 2 interesting scenarios:

 a) intel gfx:
  1) acpi-video module gets loaded (as it is a dependency of acpi_vendor
     and i915)
  2) acpi-video does NOT call acpi_video_register()
  3) acpi_vendor loads (lets assume it loads before i915), calls
     acpi_video_dmi_promote_vendor(); which sets
     ACPI_VIDEO_BACKLIGHT_DMI_VENDOR
  4) calls acpi_video_unregister -> not registered, nop
  5) i915 loads, calls acpi_video_register
  6) acpi_video_register registers the acpi_notifier for the hotkeys,
     does NOT register a backlight device because of
     ACPI_VIDEO_BACKLIGHT_DMI_VENDOR

 b) non intel gfx
  1) acpi-video module gets loaded (as it is a dependency acpi_vendor)
  2) acpi-video calls acpi_video_register()
  3) acpi_video_register registers the acpi_notifier for the hotkeys,
     and a backlight device
  4) acpi_vendor loads, calls acpi_video_dmi_promote_vendor()
  5) calls acpi_video_unregister, this unregisters BOTH the acpi_notifier
     for the hotkeys AND the backlight device

So here we have possibly the same acpi_vendor module, making the same calls,
but with different results, in one cases acpi-video does handle hotkeys,
in the other it does not.

Note that the a) scenario turns into b) if we assume the i915 module loads
before the vendor_acpi module, so we also have different behavior depending
on module loading order!

So as said I believe that quite a few existing acpi_vendor modules really
always want the behavior of a), hence this patch adds a new
acpi_video_unregister_backlight() which gives the behavior of a) independent
of module loading order.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1b7f37e1
  41. 17 5月, 2014 1 次提交
  43. 16 5月, 2014 1 次提交
  45. 13 5月, 2014 1 次提交
  47. 07 5月, 2014 1 次提交
    • H
      ACPI / video: change acpi-video brightness_switch_enabled default to 0 · 886129a8
      由 Hans de Goede 提交于 
      acpi-video is unique in that it not only generates brightness up/down
keypresses, but also (sometimes) actively changes the brightness itself.

This presents an inconsistent kernel interface to userspace, basically there
are 2 different scenarios, depending on the laptop model:

 1) On some laptops a brightness up/down keypress means: show a brightness osd
 with the current brightness, iow it is a brightness has changed notification.

 2) Where as on (a lot of) other laptops it means a brightness up/down key was
 pressed, deal with it.

Most of the desktop environments interpret any press as in scenario 2, and
change the brightness up / down as a response to the key events, causing it
to be changed twice, once by acpi-video and once by the DE.

With the new default for video.use_native_backlight we will be moving even
more laptops over to behaving as in scenario 2. Making the remaining laptops
even more of a weird exception. Also note that it is hard to detect scenario
1 properly in userspace, and AFAIK none of the DE-s deals with it.

Therefor this commit changes the default of brightness_switch_enabled to 0
making its behavior consistent with all the other backlight drivers.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      886129a8
  49. 06 5月, 2014 1 次提交
  51. 07 4月, 2014 1 次提交
  53. 19 3月, 2014 1 次提交
  55. 20 2月, 2014 2 次提交
  57. 07 12月, 2013 1 次提交
    • L
      ACPI: Clean up inclusions of ACPI header files · 8b48463f
      由 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>
      8b48463f
  59. 16 11月, 2013 1 次提交
  61. 07 11月, 2013 3 次提交