Re: [RFC] [intel-gfx] :The backlight issue when KMS is used

Re: [RFC] [intel-gfx] :The backlight issue when KMS is used

[Zhang Rui]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

CC Thomas, Len and linux-acpi mail list.

On Tue, 2009-04-07 at 16:22 +0800, Matthew Garrett wrote:
> On Tue, Apr 07, 2009 at 04:20:34PM +0800, Zhang Rui wrote:
> 
> > All subsystems can register a set of callbacks for backlight control in
> > its own way, e.g. ACPI, platform driver, i915.
> > And the backlight manager only exports one single I/F to users, like:
> > ----|
> >     |----brightness
> >     |----actual_brightness
> >     |----max_brightness
> >     |----...
> >     |----mode
> > and it supports multiple modes, e.g.
> > 1. generic ---ACPI
> > 2. platform---platform drivers
> > 3. legacy-----i915
> 
> This seems to be a lot of complexity for an uncommon case. Is there any 
> real need to modify the mode at runtime?

if this is implemented, the video_detect.c can be removed because we
don't need to detect the ACPI video extension when loading platform
drivers.
every driver that has its own ways to control the backlight can register
a set of callbacks and then it's the backlight manager's responsibility
to choose which one to use.

>  What happens if the platform 
> driver gets loaded before i915?
> 
the backlight manager always choose the one with the highest priority if
multiple callbacks are registered. i.e
if (ACPI control methods are available)
	changes to the "generic" mode
else if (platform specific callbacks are available)
	changes to the "platform" mode
else if (i915 callbacks are available)
	changes to the "legacy" mode

the backlight manager always run this logic when a new set of callbacks
is registered/unregistered.

thanks,
rui

[-- Attachment #2: backlight-manager --]
[-- Type: application/mbox, Size: 3195 bytes --]

Re: [RFC] [intel-gfx] :The backlight issue when KMS is used

[Jesse Barnes]

On Tue, 07 Apr 2009 16:48:22 +0800
Zhang Rui <rui.zhang@intel.com> wrote:

> CC Thomas, Len and linux-acpi mail list.
> 
> On Tue, 2009-04-07 at 16:22 +0800, Matthew Garrett wrote:
> > On Tue, Apr 07, 2009 at 04:20:34PM +0800, Zhang Rui wrote:
> > 
> > > All subsystems can register a set of callbacks for backlight
> > > control in its own way, e.g. ACPI, platform driver, i915.
> > > And the backlight manager only exports one single I/F to users,
> > > like: ----|
> > >     |----brightness
> > >     |----actual_brightness
> > >     |----max_brightness
> > >     |----...
> > >     |----mode
> > > and it supports multiple modes, e.g.
> > > 1. generic ---ACPI
> > > 2. platform---platform drivers
> > > 3. legacy-----i915
> > 
> > This seems to be a lot of complexity for an uncommon case. Is there
> > any real need to modify the mode at runtime?
> 
> if this is implemented, the video_detect.c can be removed because we
> don't need to detect the ACPI video extension when loading platform
> drivers.
> every driver that has its own ways to control the backlight can
> register a set of callbacks and then it's the backlight manager's
> responsibility to choose which one to use.
> 
> >  What happens if the platform 
> > driver gets loaded before i915?
> > 
> the backlight manager always choose the one with the highest priority
> if multiple callbacks are registered. i.e
> if (ACPI control methods are available)
> 	changes to the "generic" mode
> else if (platform specific callbacks are available)
> 	changes to the "platform" mode
> else if (i915 callbacks are available)
> 	changes to the "legacy" mode
> 
> the backlight manager always run this logic when a new set of
> callbacks is registered/unregistered.

The other option of course (as discussed this morning on IRC
w/Dr_Jackob) is to avoid using the sysfs backlight API in the KMS case
(KMS clients would be expected to go through output properties
instead).  This has the disadvantage of essentially deprecating a
currently used interface, but OTOH making for a more consistent
interface across new output types with brightness control (DDC has bits
for this, as does displayport I think).

But we'd definitely want to preserve the current ACPI interaction, so
we'd have to make the i915 and other DRM drivers clients of the
ACPI or platform backlight drivers (at least internally to the kernel)
where available.

This might be a bit simpler than the de-registration stuff we talked
about, and would intuitively extend to other output types that add
backlight support in the future.

Any thoughts about that?

-- 
Jesse Barnes, Intel Open Source Technology Center

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [RFC] [intel-gfx] :The backlight issue when KMS is used

[yakui_zhao]

On Tue, 2009-04-07 at 15:38 +0800, Matthew Garrett wrote:
> On Tue, Apr 07, 2009 at 03:25:23PM +0800, yakui_zhao wrote:
> > On Tue, 2009-04-07 at 13:57 +0800, Matthew Garrett wrote:
> > > No, since in UMS mode the X server handles the backlight registers.
> > If so, there is no change about the backlight flowchart in UMS mode.
> > 
> > And only when the KMS mode is used, a new backlight I/F is registered.
> > Right?
> 
> Right.
> 
> > > The acpi case is uninteresting - acpi_video_backlight_support() doesn't 
> > > require the acpi video driver. The platform driver case is more 
> > > interesting, but the easiest solution is probably to add a notifier 
> > > chain for backlight device add and have i915 unregister when a platform 
> > > device registers.
> > Yes. We will have to create the communication channel between backlight
> > device and i915 driver. And when a backlight I/F is registered, we will
> > have to check whether the backlight I/F in 915 should be unregistered. 
> > Right? 
> > Does this make the problem complex? 
> 
> Not really. It's not a lot of code.
When a new backlight I/F is registered, it should unregister the
backlight I/F registered in 915 driver if it exists. And before i915
driver registers a backlight I/F, it will have to check whether the
backlight I/F is already registered by other code. If it exists, it will
give up.
And this code seems hack. 

If so, we will have to do so even for the boxes based on non-intel
platforms. 
> 
> > > I'm not sure what you mean by arbiter order?
> > What I said is which backlight I/F should be selected if there exist
> > multiple backlight I/F?
> 
> The platform-specific one.
> 

--
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

Re: [RFC] [intel-gfx] :The backlight issue when KMS is used

[yakui_zhao]

On Tue, 2009-04-07 at 16:48 +0800, Zhang, Rui wrote:
> CC Thomas, Len and linux-acpi mail list.
> 
> On Tue, 2009-04-07 at 16:22 +0800, Matthew Garrett wrote:
> > On Tue, Apr 07, 2009 at 04:20:34PM +0800, Zhang Rui wrote:
> > 
> > > All subsystems can register a set of callbacks for backlight control in
> > > its own way, e.g. ACPI, platform driver, i915.
> > > And the backlight manager only exports one single I/F to users, like:
> > > ----|
> > >     |----brightness
> > >     |----actual_brightness
> > >     |----max_brightness
> > >     |----...
> > >     |----mode
> > > and it supports multiple modes, e.g.
> > > 1. generic ---ACPI
> > > 2. platform---platform drivers
> > > 3. legacy-----i915
> > 
> > This seems to be a lot of complexity for an uncommon case. Is there any 
> > real need to modify the mode at runtime?
> 
> if this is implemented, the video_detect.c can be removed because we
> don't need to detect the ACPI video extension when loading platform
> drivers.
> every driver that has its own ways to control the backlight can register
> a set of callbacks and then it's the backlight manager's responsibility
> to choose which one to use.
> 
> >  What happens if the platform 
> > driver gets loaded before i915?
> > 
> the backlight manager always choose the one with the highest priority if
> multiple callbacks are registered. i.e
> if (ACPI control methods are available)
> 	changes to the "generic" mode
> else if (platform specific callbacks are available)
> 	changes to the "platform" mode
> else if (i915 callbacks are available)
> 	changes to the "legacy" mode
> 
> the backlight manager always run this logic when a new set of callbacks
> is registered/unregistered.
Is this manager realized in kernel space or user space?
> 
> thanks,
> rui

Re: [RFC] [intel-gfx] :The backlight issue when KMS is used

[Thomas Renninger]

On Tuesday 07 April 2009 10:48:22 Zhang Rui wrote:
> CC Thomas, Len and linux-acpi mail list.
> 
> On Tue, 2009-04-07 at 16:22 +0800, Matthew Garrett wrote:
> > On Tue, Apr 07, 2009 at 04:20:34PM +0800, Zhang Rui wrote:
> > 
> > > All subsystems can register a set of callbacks for backlight control in
> > > its own way, e.g. ACPI, platform driver, i915.
> > > And the backlight manager only exports one single I/F to users, like:
> > > ----|
> > >     |----brightness
> > >     |----actual_brightness
> > >     |----max_brightness
> > >     |----...
> > >     |----mode
> > > and it supports multiple modes, e.g.
> > > 1. generic ---ACPI
> > > 2. platform---platform drivers
> > > 3. legacy-----i915
> > 
> > This seems to be a lot of complexity for an uncommon case. Is there any 
> > real need to modify the mode at runtime?
Whatabout several graphics cards, vendors are already selling.
If you switch the graphics cards you also might have to pick up another
backlight back-end?
 
> if this is implemented, the video_detect.c can be removed because we
> don't need to detect the ACPI video extension when loading platform
> drivers.
Hmm, above pretty much looks like what video_detect.c does + i915 detection.
One problem is that you have to detect things before drivers are loaded and
possibly register the wrong interface, so this needs to be implemented in
code that is always compiled in.
Are there more details where and how this should get implemented?
Or can someone provide a pointer to the beginning of the thread?
The graphics driver was the missing part when choosing who is going to
switch things. Now that it moves into the kernel, synchronization between
all above drivers is probably a good idea.

Whatabout display output switching?
The problem is similar, you have:
  - vendor specific (e.g. in thinkpad-laptop)
  - ACPI
  - graphics driver
Here the first two never really worked (at least for a large range of systems)
AFAIK. AFAIK 3D graphics drivers disable IO regions so that ACPI
or others cannot change them anymore and take over. How is this supposed to
work with (and without) KMS?

   Thomas

> every driver that has its own ways to control the backlight can register
> a set of callbacks and then it's the backlight manager's responsibility
> to choose which one to use.
> 
> >  What happens if the platform 
> > driver gets loaded before i915?
> > 
> the backlight manager always choose the one with the highest priority if
> multiple callbacks are registered. i.e
> if (ACPI control methods are available)
> 	changes to the "generic" mode
> else if (platform specific callbacks are available)
> 	changes to the "platform" mode
> else if (i915 callbacks are available)
> 	changes to the "legacy" mode
> 
> the backlight manager always run this logic when a new set of callbacks
> is registered/unregistered.
> 
> thanks,
> rui
> 

Re: [RFC] [intel-gfx] :The backlight issue when KMS is used

[Thomas Renninger]

Hi,

We have these interfaces:
  - vendor specific implementation
    (mostly in drivers/platform/x86/vendor-laptop.c)
  - ACPI generic backlight only
  - Opregion (this is the KMS/i915 interface you are talking about
    or is there another abstraction?)
  - Possibly other graphics card specific coming up with KMS?
  - X-server is doing it (UMS)

Matthew and Jesse are looking for following approach:
Let all drivers try to register for the generic backlight interface.
As we do not know which driver will get loaded first, you want to 
detect whether another driver already registered the backlight
interface and implement a priority to eventually let the newly
loaded driver unregister the other driver's backlight device, notify
this driver via a notifier chain and then register the own backlight
interface (is that correct?).

Priority could look like:
1) vendor specific drivers
2) ACPI generic drivers
3) Graphics card's specific kernel drivers (IGD/Opregion and possibly
   others)
3 has highest prio.

If I got that right, I do not like:
  - the complexity that has to be added to the generic backlight
    interface and each backlight driver.
  - The fact that several HW access mechanisms might be used. That
    all are working is rather unlikely. Once e.g. Windows is only
    using IGD, OEMs might still have a not working vendor specific
    solution remaining in their BIOSes. If the vendor specific
    solution is registered first the machine might in worst case
    freeze, before the i915 driver could have taken over.

Whatabout a similar approach like video_detect which checks for
ACPI generic functions and fills a global variable which mechanism
to go for before module load time.

If the i915 backlight switching is the IGD implementation, then
video_detect.c is nearly already sufficient. All that has to be
added is whether generic ACPI backlight functions support IGD and
acpi_video_backlight_support() must not only return true/false, but
e.g.:
  1 (no acpi things, go for vendor specific)
  2 (generic ACPI functions, but no IGD, go for video.ko)
  3 (generic ACPI functions and IGD, video.ko will not register for
     backlight)

The main problem with that approach is (for IGD it might not be that
hard, but for other upcoming graphics cards?), that if the card has
to be set up first in a complex way (e.g. atombios things for Radeon 
must be parsed before) you have to statically compile in all necessary
things to check whether the later loaded graphics cards driver can
serve backlight functionality or not.
If upcoming other graphics cards kernel drivers all can do backlight
switching on all cards, it could simply be checked for:
"vendor pci id of the graphics card" + "KMS set in .config"

Advantage:
  - It does not have above mentioned disadvantages
  - It's easy to add boot params or a blacklist to fallback to another
    backlight solution

Disadvantage:
  - You have the backlight functionality detection code
    compiled into the kernel
  - The code could get complex if graphics cards have to be set up
    or similar to check whether a KMS graphics driver will be able
    to do backlight switching

     Thomas

Re: [RFC] [intel-gfx] :The backlight issue when KMS is used

[Richard Purdie]

On Wed, 2009-04-08 at 12:17 +0200, Thomas Renninger wrote:
> Matthew and Jesse are looking for following approach:
> Let all drivers try to register for the generic backlight interface.
> As we do not know which driver will get loaded first, you want to 
> detect whether another driver already registered the backlight
> interface and implement a priority to eventually let the newly
> loaded driver unregister the other driver's backlight device, notify
> this driver via a notifier chain and then register the own backlight
> interface (is that correct?).
> 
> Priority could look like:
> 1) vendor specific drivers
> 2) ACPI generic drivers
> 3) Graphics card's specific kernel drivers (IGD/Opregion and possibly
>    others)
> 3 has highest prio.
> 
> If I got that right, I do not like:
>   - the complexity that has to be added to the generic backlight
>     interface and each backlight driver.

I'm not arguing for or against any approach here but if we need to have
this priority handoff system, I'd like to see it as a wrapper around the
backlight class and the class itself is unlikely to need changes. The
wrapper would register one backlight device with the generic class and
then redirect the function calls as needed.

Cheers,

Richard

Re: [RFC] [intel-gfx] :The backlight issue when KMS is used

[yakui_zhao]

On Wed, 2009-04-08 at 18:17 +0800, Thomas Renninger wrote:
> Hi,
> 
> We have these interfaces:
>   - vendor specific implementation
>     (mostly in drivers/platform/x86/vendor-laptop.c)
>   - ACPI generic backlight only
>   - Opregion (this is the KMS/i915 interface you are talking about
>     or is there another abstraction?)
IMO it is unnecessary to consider the Opregion as the interface. In fact
it is only for the communication between the ACPI and graphics driver.
We can send the request by using ACPI generic backlight and then the
brightness is changed in the graphics driver.
>   - Possibly other graphics card specific coming up with KMS?
>   - X-server is doing it (UMS)
Yes. For example: three other control methods are provided in UMS for
intel driver. Native/ Legacy/ Combo mode. 
   And the control methods are hook up by Xrandr tool.
> 
> Matthew and Jesse are looking for following approach:
> Let all drivers try to register for the generic backlight interface.
> As we do not know which driver will get loaded first, you want to 
> detect whether another driver already registered the backlight
> interface and implement a priority to eventually let the newly
> loaded driver unregister the other driver's backlight device, notify
> this driver via a notifier chain and then register the own backlight
> interface (is that correct?).
   
> Priority could look like:
> 1) vendor specific drivers
> 2) ACPI generic drivers
> 3) Graphics card's specific kernel drivers (IGD/Opregion and possibly
>    others)
> 3 has highest prio.
> 
> If I got that right, I do not like:
>   - the complexity that has to be added to the generic backlight
>     interface and each backlight driver.
>   - The fact that several HW access mechanisms might be used. That
>     all are working is rather unlikely. Once e.g. Windows is only
>     using IGD, OEMs might still have a not working vendor specific
>     solution remaining in their BIOSes. If the vendor specific
>     solution is registered first the machine might in worst case
>     freeze, before the i915 driver could have taken over.
> 
> Whatabout a similar approach like video_detect which checks for
> ACPI generic functions and fills a global variable which mechanism
> to go for before module load time.
> 
> If the i915 backlight switching is the IGD implementation, then
> video_detect.c is nearly already sufficient. All that has to be
> added is whether generic ACPI backlight functions support IGD and
> acpi_video_backlight_support() must not only return true/false, but
> e.g.:
>   1 (no acpi things, go for vendor specific)
>   2 (generic ACPI functions, but no IGD, go for video.ko)
>   3 (generic ACPI functions and IGD, video.ko will not register for
>      backlight)
> 
> The main problem with that approach is (for IGD it might not be that
> hard, but for other upcoming graphics cards?), that if the card has
> to be set up first in a complex way (e.g. atombios things for Radeon 
> must be parsed before) you have to statically compile in all necessary
> things to check whether the later loaded graphics cards driver can
> serve backlight functionality or not.
> If upcoming other graphics cards kernel drivers all can do backlight
> switching on all cards, it could simply be checked for:
> "vendor pci id of the graphics card" + "KMS set in .config"
What you said is also OK. 
But I don't know whether this will make the problem complex.
This issue I raised is related with that no backlight can be controlled
by xrandr tool after using KMS.
    For example: >http://bugs.freedesktop.org/show_bug.cgi?id=20963
   
    On this box neither generic ACPI backlight I/F nor platform
backlight I/F exists. In UMS mode the backlight can be controlled by
xrandr(the specific control method is used). But in KMS mode the
specific control method is realized in kernel space and this is not
exposed to user space. In such case the backlight can't be controlled.
    And we expect that the backlight still can be controlled by xrandr
tool in KMS mode.

Another issue is the inconsistency between the ACPI backlight I/F and
specific control method. 
    For example: there exists the generic ACPI backlight I/F and this
depends on intel opregion. If the legacy control method is selected,
then ACPI backlight I/F can't report the correct brightness after the
brightness is changed by xrandr tool. 
    So we expect to avoid the inconsistency in KMS mode.
> 
> Advantage:
>   - It does not have above mentioned disadvantages
>   - It's easy to add boot params or a blacklist to fallback to another
>     backlight solution
> 
> Disadvantage:
>   - You have the backlight functionality detection code
>     compiled into the kernel
>   - The code could get complex if graphics cards have to be set up
>     or similar to check whether a KMS graphics driver will be able
>     to do backlight switching
> 
>      Thomas

Re: [RFC] [intel-gfx] :The backlight issue when KMS is used

[Thomas Renninger]

On Thursday 09 April 2009 03:12:19 am yakui_zhao wrote:
> On Wed, 2009-04-08 at 18:17 +0800, Thomas Renninger wrote:
> > Hi,
> >
> > We have these interfaces:
> >   - vendor specific implementation
> >     (mostly in drivers/platform/x86/vendor-laptop.c)
> >   - ACPI generic backlight only
> >   - Opregion (this is the KMS/i915 interface you are talking about
> >     or is there another abstraction?)
>
> IMO it is unnecessary to consider the Opregion as the interface. In fact
> it is only for the communication between the ACPI and graphics driver.
> We can send the request by using ACPI generic backlight and then the
> brightness is changed in the graphics driver.
>
> What you said is also OK.
> But I don't know whether this will make the problem complex.
> This issue I raised is related with that no backlight can be controlled
> by xrandr tool after using KMS.
>     For example: >http://bugs.freedesktop.org/show_bug.cgi?id=20963
Why should this get a i915 and not a native samsung-laptop driver?
Can someone come up with some example code how the backlight switching
implementation for this one would look like.
This is needed anyway and then it is much easier to think about how to make 
sure backlight drivers do not get double registered.

     Thomas