| Message ID | 20090415164939.GA27807@srcf.ucam.org (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Delegated to: | Zhao yakui |
| Headers | show |
On 04/15/2009 06:49 PM, Matthew Garrett wrote: > Does this help? > > diff --git a/drivers/gpu/drm/i915/i915_opregion.c b/drivers/gpu/drm/i915/i915_opregion.c > index 6942772..8dc1fd3 100644 > --- a/drivers/gpu/drm/i915/i915_opregion.c > +++ b/drivers/gpu/drm/i915/i915_opregion.c > @@ -370,11 +370,8 @@ int intel_opregion_init(struct drm_device *dev, int resume > Hi Matthew, Yes please, after your patch the brightness can be adjusted again. :) The behaviour seems slightly different from before your 74a365b3f354 commit in that /sys/class/backlight remains empty until i915 gets loaded for the first time, the contents then persist even if i915 is unloaded. Perhaps the directory was populated by a different kernel module, since when I did the bisect yesterday the directory would be there on boot before I started X or loaded i915. I'm not sure if that matters to any other user-space app. (or if ideally one is supposed to be able to control brightness in the console without having to load i915), but it's fine for controlling brightness in Xorg. Thanks, Niel -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 15, 2009 at 09:55:55PM +0200, Niel Lambrechts wrote: > The behaviour seems slightly different from before your 74a365b3f354 > commit in that /sys/class/backlight remains empty until i915 gets loaded > for the first time, the contents then persist even if i915 is unloaded. > Perhaps the directory was populated by a different kernel module, since > when I did the bisect yesterday the directory would be there on boot > before I started X or loaded i915. In the past the directory would be created when the acpi video driver was loaded, but probably wouldn't work. Doing it that way is a violation of the opregion spec and causes some machines to break in a horrible manner, so I'd prefer not to go back to that version... > I'm not sure if that matters to any other user-space app. (or if > ideally one is supposed to be able to control brightness in the console > without having to load i915), but it's fine for controlling brightness > in Xorg. If you use modesetting then you shouldn't need to launch X to get working brightness control. The problem with the old-style world is that you won't get interrupts until X comes up.
On 04/15/2009 10:01 PM, Matthew Garrett wrote: > On Wed, Apr 15, 2009 at 09:55:55PM +0200, Niel Lambrechts wrote: > > >> The behaviour seems slightly different from before your 74a365b3f354 >> commit in that /sys/class/backlight remains empty until i915 gets loaded >> for the first time, the contents then persist even if i915 is unloaded. >> Perhaps the directory was populated by a different kernel module, since >> when I did the bisect yesterday the directory would be there on boot >> before I started X or loaded i915. >> > > In the past the directory would be created when the acpi video driver > was loaded, but probably wouldn't work. Doing it that way is a violation > of the opregion spec and causes some machines to break in a horrible > manner, so I'd prefer not to go back to that version... > Cool, I suspected it was intended behaviour... :) So is there any chance of getting this fix merged any time soon (at least before 2.6.30 is out)? > If you use modesetting then you shouldn't need to launch X to get > working brightness control. The problem with the old-style world is that > you won't get interrupts until X comes up. I'd love to use KMS, but I have no idea how to troubleshoot the freeze I'm getting after the main gdm login screen. Or is there still a future i915 milestone(s) to be reached before I can realistically do i915.modeset=1, given the large amount of activity around this in recent times? Thanks for the help! Niel -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Apr 15, 2009 at 10:57:12PM +0200, Niel Lambrechts wrote: > So is there any chance of getting this fix merged any time soon (at > least before 2.6.30 is out)? Yeah, I'd hope it's merged before .30. I've sent it to the maintainers. > I'd love to use KMS, but I have no idea how to troubleshoot the freeze > I'm getting after the main gdm login screen. Or is there still a future > i915 milestone(s) to be reached before I can realistically do > i915.modeset=1, given the large amount of activity around this in recent > times? There's still a lot of work being done in this area, and it can be a bit sensitive to you using the correct X driver version with a given kernel version.
On Thu, 2009-04-16 at 00:49 +0800, Matthew Garrett wrote: > Does this help? If so, we don't need the following patch. >http://marc.info/?l=linux-acpi&m=123967828429865&w=2 >check whether the ACPI video driver is deferrable only when KMS is set > diff --git a/drivers/gpu/drm/i915/i915_opregion.c b/drivers/gpu/drm/i915/i915_opregion.c > index 6942772..8dc1fd3 100644 > --- a/drivers/gpu/drm/i915/i915_opregion.c > +++ b/drivers/gpu/drm/i915/i915_opregion.c > @@ -370,11 +370,8 @@ int intel_opregion_init(struct drm_device *dev, int resume) > if (mboxes & MBOX_ACPI) { > DRM_DEBUG("Public ACPI methods supported\n"); > opregion->acpi = base + OPREGION_ACPI_OFFSET; > - if (drm_core_check_feature(dev, DRIVER_MODESET)) { > + if (drm_core_check_feature(dev, DRIVER_MODESET)) > intel_didl_outputs(dev); > - if (!resume) > - acpi_video_register(); > - } > } else { > DRM_DEBUG("Public ACPI methods not supported\n"); > err = -ENOTSUPP; > @@ -391,6 +388,10 @@ int intel_opregion_init(struct drm_device *dev, int resume) > opregion->asle = base + OPREGION_ASLE_OFFSET; > } > > + if (!resume) > + acpi_video_register(); > + > + > /* Notify BIOS we are ready to handle ACPI video ext notifs. > * Right now, all the events are handled by the ACPI video module. > * We don't actually need to do anything with them. */ > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/gpu/drm/i915/i915_opregion.c b/drivers/gpu/drm/i915/i915_opregion.c index 6942772..8dc1fd3 100644 --- a/drivers/gpu/drm/i915/i915_opregion.c +++ b/drivers/gpu/drm/i915/i915_opregion.c @@ -370,11 +370,8 @@ int intel_opregion_init(struct drm_device *dev, int resume) if (mboxes & MBOX_ACPI) { DRM_DEBUG("Public ACPI methods supported\n"); opregion->acpi = base + OPREGION_ACPI_OFFSET; - if (drm_core_check_feature(dev, DRIVER_MODESET)) { + if (drm_core_check_feature(dev, DRIVER_MODESET)) intel_didl_outputs(dev); - if (!resume) - acpi_video_register(); - } } else { DRM_DEBUG("Public ACPI methods not supported\n"); err = -ENOTSUPP; @@ -391,6 +388,10 @@ int intel_opregion_init(struct drm_device *dev, int resume) opregion->asle = base + OPREGION_ASLE_OFFSET; } + if (!resume) + acpi_video_register(); + + /* Notify BIOS we are ready to handle ACPI video ext notifs. * Right now, all the events are handled by the ACPI video module. * We don't actually need to do anything with them. */