lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 12 Jan 2010 09:34:54 -0800
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	James Simmons <jsimmons@...radead.org>
Cc:	David John <davidjon@...ontk.org>,
	Johan Hovold <jhovold@...il.com>,
	Dave Airlie <airlied@...hat.com>,
	dri-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
	Eric Anholt <eric@...olt.net>
Subject: Re: [PATCH] drm/kms: fix fbdev blanking regression

On Tue, 12 Jan 2010 17:28:33 +0000 (GMT)
James Simmons <jsimmons@...radead.org> wrote:

> 
> > On 01/07/2010 12:42 AM, Johan Hovold wrote:
> > >> Yeap. The fix uncovered a bug in your driver. I haven't heard of
> > >> problems with the other drm drivers.
> > >>  
> > >>> The backlight is handled via the DRI driver I assume. At least
> > >>> i9xx_crtc_dpms is called on powerdown.
> > >>
> > >> Can you post your dmesg and kernel config.
> > 
> > [snip]
> > 
> > Adding the Intel DRM people in CC as well. I have the same issue
> > with my GM45.
> 
> Okay I looked at the code to figure out what is happening and why
> only this driver has problems. The problem is that the framebuffer
> layer expects the backlight to be a seperate device. The reason being
> is that some embedded systems will use a gpio backlight. That way
> power management for a graphics card/backlight has 3 seperate states.
> Currently the intel DRM driver treats the backlight as being apart of
> the encoder. Jesse do you have objections to having the intel driver
> expose a backlight device. The bonus of that is the user can also set
> the backlight levels.

On Intel we usually expect the backlight to be exposed by ACPI or a
platform driver.  On recent platforms, the ACPI driver will actually
send requests to the gfx driver to do the actual register writes to
adjust the backlight, but it's still ACPI driven.

Maybe we just need to wire up the fb backlight hooks appropriately?

-- 
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ