Re: [RFC] [intel-gfx] :The backlight issue when KMS is used
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 -- 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
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 -- 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
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. -- 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
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 -- 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
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 -- 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
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 -- 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
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 -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment.
Re: [RFC] [intel-gfx] :The backlight issue when KMS is used
On Sat, 2009-04-04 at 00:29 +0800, Matthew Garrett wrote: On Fri, Apr 03, 2009 at 09:24:08AM -0700, Jesse Barnes wrote: I'd rather not have a native kernel backlight property (i.e. a property on the LVDS output) exposed at all. I chatted with Matthew about this a little, and I think the best thing to do would be to have the i915 driver register a backlight interface of its own if one doesn't already exist (e.g. in the case of a platform specific i2c interface and no ACPI backlight support). We might have to hack the backlight class code a little to prevent multiple registrations for the same device, but that shouldn't be too hard. Then whichever driver loads first (i915 or acpi video) would create a backlight interface if it could, and the userspace driver could use it; no need for new properties. Right. I'd imagine it as i915 loading and calling is_acpi_backlight(). If that returns false, it should register a backlight device and also a notifier. If a machine-specific platform device (like thinkpad_acpi or dell_laptop or whatever) then loads, i915 should unregister its driver and leave it up to the machine-specific one. The DDX would then use the backlight device under all circumstances. A good idea. When there is no generic ACPI backlight I/F(_BQC/_BCL/_BCM) or platform backlight I/F, a new baclight I/F(using platform I2C command) will be registered in i915 driver. Will this new backlight I/F be registered in both UMS/KMS mode? But if we do so, it seems that we have to solve the dependency issue among acpi_video, i915 and platform driver. For example: I915 driver is loaded firstly and the interface will be registered. But after the acpi video driver/platform driver is loaded, how to send the notification event that i915 should unregister its interface? If the interface is unregistered, we will have to consider the arbiter order. Does this make the problem more complex? Will this new backlight I/F be registered in UMS mode? cc: Richard Purdie Best regards. Yakui -- 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
On Tue, Apr 07, 2009 at 11:45:11AM +0800, yakui_zhao wrote: On Sat, 2009-04-04 at 00:29 +0800, Matthew Garrett wrote: Right. I'd imagine it as i915 loading and calling is_acpi_backlight(). If that returns false, it should register a backlight device and also a notifier. If a machine-specific platform device (like thinkpad_acpi or dell_laptop or whatever) then loads, i915 should unregister its driver and leave it up to the machine-specific one. The DDX would then use the backlight device under all circumstances. A good idea. When there is no generic ACPI backlight I/F(_BQC/_BCL/_BCM) or platform backlight I/F, a new baclight I/F(using platform I2C command) will be registered in i915 driver. Will this new backlight I/F be registered in both UMS/KMS mode? No, since in UMS mode the X server handles the backlight registers. But if we do so, it seems that we have to solve the dependency issue among acpi_video, i915 and platform driver. For example: I915 driver is loaded firstly and the interface will be registered. But after the acpi video driver/platform driver is loaded, how to send the notification event that i915 should unregister its interface? If the interface is unregistered, we will have to consider the arbiter order. 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. I'm not sure what you mean by arbiter order? -- Matthew Garrett | mj...@srcf.ucam.org -- 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
On Tue, 2009-04-07 at 13:57 +0800, Matthew Garrett wrote: On Tue, Apr 07, 2009 at 11:45:11AM +0800, yakui_zhao wrote: On Sat, 2009-04-04 at 00:29 +0800, Matthew Garrett wrote: Right. I'd imagine it as i915 loading and calling is_acpi_backlight(). If that returns false, it should register a backlight device and also a notifier. If a machine-specific platform device (like thinkpad_acpi or dell_laptop or whatever) then loads, i915 should unregister its driver and leave it up to the machine-specific one. The DDX would then use the backlight device under all circumstances. A good idea. When there is no generic ACPI backlight I/F(_BQC/_BCL/_BCM) or platform backlight I/F, a new baclight I/F(using platform I2C command) will be registered in i915 driver. Will this new backlight I/F be registered in both UMS/KMS mode? 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? But if we do so, it seems that we have to solve the dependency issue among acpi_video, i915 and platform driver. For example: I915 driver is loaded firstly and the interface will be registered. But after the acpi video driver/platform driver is loaded, how to send the notification event that i915 should unregister its interface? If the interface is unregistered, we will have to consider the arbiter order. 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? 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? -- 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
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. 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. -- Matthew Garrett | mj...@srcf.ucam.org -- 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
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? What happens if the platform driver gets loaded before i915? -- Matthew Garrett | mj...@srcf.ucam.org -- 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
On Tue, 2009-04-07 at 15:25 +0800, Zhao, Yakui wrote: But if we do so, it seems that we have to solve the dependency issue among acpi_video, i915 and platform driver. For example: I915 driver is loaded firstly and the interface will be registered. But after the acpi video driver/platform driver is loaded, how to send the notification event that i915 should unregister its interface? If the interface is unregistered, we will have to consider the arbiter order. 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? that's why I proposed to implement a backlight manager in the sysfs backlight class driver. 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 The sysfs backlight manager always chooses the mode with highest priority (generic platform legacy), and call the respective callbacks when backlight is changed. For example, the backlight manager switches to the generic mode from legacy mode automatically when ACPI video driver is loaded at runtime. thanks, rui -- 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
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 backlight-manager Description: application/mbox -- 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
On Tue, 07 Apr 2009 16:48:22 +0800 Zhang Rui rui.zh...@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
[RFC] [intel-gfx] :The backlight issue when KMS is used
Hi, All When the kernel is booted with KMS enabled, the backlight brightness can't be changed by xrandr tool. This issue is caused by that the native kernel backlight I/F is not exposed to userland. In such case there is no backlight property in xrandr tool. Of course the brightness can't be controlled by xrandr tool. If the native kernel backlight I/F is exposed to userland(ie. the backlight property is hooked up by xrandr tool), the brightness will be controlled by xrandr tool. But the inconsistency between ACPI backlight I/F and xrandr tool appears. When it is changed by ACPI I/F, the xrandr can report the correct brightness. But if the brightness is changed by native kernel I/F, the ACPI I/F will report the incorrect brightness. It is inconsistent and not what we expected. Even when the ACPI opregion is used, the inconsistency still exists. In fact this inconsistency also exists in UMS mode if the backlight control mode is legacy/native/combo. The issue is that the ACPI I/F can't reflect the true brightness if the brightness is changed by xrandr tool. In UMS mode the ACPI I/F (kernel) mode will be preferred if there exists the ACPI backlight I/F. Only when there is no ACPI I/F, it will fall back to the other three modes. How about following what we have done in UMS mode ? a. When there exists the ACPI backlight I/F, the ACPI I/F will be hook up in drmmode_display.c and exposed to xrandr tool. Then the backlight can be changed by xrandr tool(the ACPI I/F is called). Of course the backlight can also be changed by ACPI I/F. It is similar with what we have done in UMS mode. Of course to eliminate the potential inconsistency, the other three backlight control modes won't be exposed again. b. If there is no ACPI backlight I/F, the native kernel backlight property will be exposed. And then the backlight can be changed by xrandr. (No ACPI I/F can control the brightness). Welcome the comments. Best regards. Yakui -- -- ___ 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
On Fri, 3 Apr 2009 17:29:06 +0100 Matthew Garrett mj...@srcf.ucam.org wrote: On Fri, Apr 03, 2009 at 09:24:08AM -0700, Jesse Barnes wrote: I'd rather not have a native kernel backlight property (i.e. a property on the LVDS output) exposed at all. I chatted with Matthew about this a little, and I think the best thing to do would be to have the i915 driver register a backlight interface of its own if one doesn't already exist (e.g. in the case of a platform specific i2c interface and no ACPI backlight support). We might have to hack the backlight class code a little to prevent multiple registrations for the same device, but that shouldn't be too hard. Then whichever driver loads first (i915 or acpi video) would create a backlight interface if it could, and the userspace driver could use it; no need for new properties. Right. I'd imagine it as i915 loading and calling is_acpi_backlight(). If that returns false, it should register a backlight device and also a notifier. If a machine-specific platform device (like thinkpad_acpi or dell_laptop or whatever) then loads, i915 should unregister its driver and leave it up to the machine-specific one. The DDX would then use the backlight device under all circumstances. Yeah, that's the main thing. I don't want to repeat the horror show of the UMS backlight interface. Everything should go through /sys/class/backlight, and the kernel should figure out which one is best (i.e. provides the most consistent experience). -- Jesse Barnes, Intel Open Source Technology Center -- -- ___ 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
On Fri, 03 Apr 2009 13:49:38 +0800 yakui_zhao yakui.z...@intel.com wrote: How about following what we have done in UMS mode ? a. When there exists the ACPI backlight I/F, the ACPI I/F will be hook up in drmmode_display.c and exposed to xrandr tool. Then the backlight can be changed by xrandr tool(the ACPI I/F is called). Of course the backlight can also be changed by ACPI I/F. It is similar with what we have done in UMS mode. Of course to eliminate the potential inconsistency, the other three backlight control modes won't be exposed again. b. If there is no ACPI backlight I/F, the native kernel backlight property will be exposed. And then the backlight can be changed by xrandr. (No ACPI I/F can control the brightness). I'd rather not have a native kernel backlight property (i.e. a property on the LVDS output) exposed at all. I chatted with Matthew about this a little, and I think the best thing to do would be to have the i915 driver register a backlight interface of its own if one doesn't already exist (e.g. in the case of a platform specific i2c interface and no ACPI backlight support). We might have to hack the backlight class code a little to prevent multiple registrations for the same device, but that shouldn't be too hard. Then whichever driver loads first (i915 or acpi video) would create a backlight interface if it could, and the userspace driver could use it; no need for new properties. Thoughts? -- Jesse Barnes, Intel Open Source Technology Center -- -- ___ 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
On Fri, Apr 03, 2009 at 09:24:08AM -0700, Jesse Barnes wrote: I'd rather not have a native kernel backlight property (i.e. a property on the LVDS output) exposed at all. I chatted with Matthew about this a little, and I think the best thing to do would be to have the i915 driver register a backlight interface of its own if one doesn't already exist (e.g. in the case of a platform specific i2c interface and no ACPI backlight support). We might have to hack the backlight class code a little to prevent multiple registrations for the same device, but that shouldn't be too hard. Then whichever driver loads first (i915 or acpi video) would create a backlight interface if it could, and the userspace driver could use it; no need for new properties. Right. I'd imagine it as i915 loading and calling is_acpi_backlight(). If that returns false, it should register a backlight device and also a notifier. If a machine-specific platform device (like thinkpad_acpi or dell_laptop or whatever) then loads, i915 should unregister its driver and leave it up to the machine-specific one. The DDX would then use the backlight device under all circumstances. -- Matthew Garrett | mj...@srcf.ucam.org -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
