1. 19 6月, 2015 21 次提交
    • H
      thinkpad-acpi: Port to new backlight interface selection API · b33c6ce5
      Hans de Goede 提交于
      Port the backlight selection logic to the new backlight interface
      selection API.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
      Acked-by: NDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b33c6ce5
    • H
      sony-laptop: Port to new backlight interface selection API · 56d5c34a
      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: NMattia Dongili <malattia@linux.it>
      Acked-by: NDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      56d5c34a
    • H
      samsung-laptop: Port to new backlight interface selection API · 6c072299
      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>
      6c072299
    • H
      msi-wmi: Port to new backlight interface selection API · 33a4edfb
      Hans de Goede 提交于
      Port the backlight selection logic to the new backlight interface
      selection API.
      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>
      33a4edfb
    • H
      msi-laptop: Port to new backlight interface selection API · 2cc6c717
      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>
      2cc6c717
    • H
      intel-oaktrail: Port to new backlight interface selection API · 76d0a351
      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>
      76d0a351
    • H
      ideapad-laptop: Port to new backlight interface selection API · 26bff5f0
      Hans de Goede 提交于
      Port the backlight selection logic to the new backlight interface
      selection API.
      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>
      26bff5f0
    • H
      fujitsu-laptop: Port to new backlight interface selection API · 413226f7
      Hans de Goede 提交于
      Port the backlight selection logic to the new backlight interface
      selection API.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NJonathan Woithe <jwoithe@just42.net>
      Acked-by: NDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      413226f7
    • H
      eeepc-laptop: Port to new backlight interface selection API · 21db4b1d
      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>
      21db4b1d
    • H
      dell-wmi: Port to new backlight interface selection API · 18bd7696
      Hans de Goede 提交于
      Port the backlight selection logic to the new backlight interface
      selection API.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NPali Rohár <pali.rohar@gmail.com>
      Acked-by: NDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      18bd7696
    • H
      dell-laptop: Port to new backlight interface selection API · ee4cfe28
      Hans de Goede 提交于
      Port the backlight selection logic to the new backlight interface
      selection API.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: NPali Rohár <pali.rohar@gmail.com>
      Acked-by: NDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      ee4cfe28
    • H
      compal-laptop: Port to new backlight interface selection API · 358fefe7
      Hans de Goede 提交于
      Port the backlight selection logic to the new backlight interface
      selection API.
      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>
      358fefe7
    • H
      asus-wmi: Port to new backlight interface selection API · 62c4aa1a
      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>
      62c4aa1a
    • H
      asus-laptop: Port to new backlight interface selection API · 8b9e6b70
      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>
      8b9e6b70
    • H
      apple-gmux: Port to new backlight interface selection API · 86ac056a
      Hans de Goede 提交于
      Port the backlight selection logic to the new backlight interface
      selection API.
      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>
      86ac056a
    • H
      acer-wmi: Port to new backlight interface selection API · 9a65f0df
      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>
      Reviewed-by: NLee, Chun-Yi <jlee@suse.com>
      Acked-by: NDarren Hart <dvhart@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9a65f0df
    • H
      acpi-video-detect: video: Make video_detect code part of the video module · 14ca7a47
      Hans de Goede 提交于
      This is a preparation patch for the backlight interface selection logic
      cleanup, there are 2 reasons to not always build the video_detect code
      into the kernel:
      
      1) In order for the video_detect.c to also deal with / select native
      backlight interfaces on win8 systems, instead of doing this in video.c
      where it does not belong, video_detect.c needs to call into the backlight
      class code. Which cannot be done if it is builtin and the blacklight class
      is not.
      
      2) Currently all the platform/x86 drivers which have quirks to prefer
      the vendor driver over acpi-video call acpi_video_unregister_backlight()
      to remove the acpi-video backlight interface, this logic really belongs
      in video_detect.c, which will cause video_detect.c to depend on symbols of
      video.c and video.c already depends on video_detect.c symbols, so they
      really need to be a single module.
      
      Note that this commits make 2 changes so as to maintain 100% kernel
      commandline compatibility:
      
      1) The __setup call for the acpi_backlight= handling is moved to
         acpi/util.c as __setup may only be used by code which is alwasy builtin
      2) video.c is renamed to acpi_video.c so that it can be combined with
         video_detect.c into video.ko
      
      This commit also makes changes to drivers/platform/x86/Kconfig to ensure
      that drivers which use acpi_video_backlight_support() from video_detect.c,
      will not be built-in when acpi_video is not built in. This also changes
      some "select" uses to "depends on" to avoid dependency loops.
      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>
      14ca7a47
    • H
      apple-gmux: Stop using acpi_video_dmi_demote_vendor() · a341b8ab
      Hans de Goede 提交于
      acpi_video_dmi_demote_vendor() is going away as part of the cleanup of
      the code for determinging which backlight class driver(s) to register.
      
      The call to acpi_video_dmi_demote_vendor() was meant to undo the call to
      acpi_video_dmi_promote_vendor() when the gmux device is removed, this is
      questionable though since the promote call sets a flag, not a counter, so
      the demote call may undo a promoto done elsewhere. Moreover in practice
      this is a nop since the gmux device is never removed, and the flag is only
      checked when acpi/video.ko gets loaded, so even if the user manually
      removes apple-gmux the demote call is still a nop as video.ko will already
      have loaded by this time.
      
      Also note that none of the other users of acpi_video_dmi_promote_vendor()
      use acpi_video_dmi_demote_vendor().
      
      If we ever encounter a system with a gmux where the acpi-video interface
      should be used, then the proper fix would be to dmi-blacklist the gmux
      driver on that system.
      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>
      a341b8ab
    • H
      samsung-laptop: Use acpi_video_unregister_backlight instead of acpi_video_unregister · acf5493c
      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 broken_acpi_video 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) samsung-laptop.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) samsung-laptop.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>
      acf5493c
    • H
      asus-wmi: Use acpi_video_unregister_backlight instead of acpi_video_unregister · 4c27febf
      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>
      4c27febf
    • H
      apple_gmux: Use acpi_video_unregister_backlight instead of acpi_video_unregister · 10bffa65
      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) 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) apple-gmux.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) apple-gmux.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: Seth Forshee <seth.forshee@canonical.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>
      10bffa65
  2. 20 5月, 2015 1 次提交
  3. 06 5月, 2015 1 次提交
  4. 04 5月, 2015 1 次提交
  5. 25 4月, 2015 1 次提交
  6. 08 4月, 2015 4 次提交
  7. 27 3月, 2015 3 次提交
  8. 26 3月, 2015 4 次提交
  9. 19 3月, 2015 2 次提交
  10. 15 3月, 2015 2 次提交