Bug 40492 - FB_BACKLIGHT should be added for manually selecting it under menuconfig or similar
Summary: FB_BACKLIGHT should be added for manually selecting it under menuconfig or si...
Status: REOPENED
Alias: None
Product: Other
Classification: Unclassified
Component: Configuration (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: other_configuration@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-03 18:55 UTC by David
Modified: 2017-02-02 23:09 UTC (History)
3 users (show)

See Also:
Kernel Version: 3.0.0
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Kernel's config (80.37 KB, application/octet-stream)
2011-08-03 18:55 UTC, David
Details
Suggested patch addressing problem (373 bytes, patch)
2011-08-06 02:40 UTC, David
Details | Diff
Kernel config used with previous patch (80.38 KB, application/octet-stream)
2011-08-14 10:29 UTC, David
Details

Description David 2011-08-03 18:55:38 UTC
Created attachment 67432 [details]
Kernel's config

I discovered a scenario in which menuconfig fails to set FB_BACKLIGHT symbol when needed.

In my case, I have propietary nvidia drivers once loaded Xorg, but in the meanwhile, I have configured an uvesafb framebuffer (thus, no other framebuffer active nor compiled).

System works ok, but when trying to install nvidiabl[1] (to control nvidia's backlight) I find that FB_BACKLIGHT is not set where it should be because I have BACKLIGHT_CLASS_DEVICE set.

The result is that nvidiabl does not compile.

The workarround for this now is to enable as a modile any component with support for backlight [Nvidia Framebuffer (CONFIG_FB_NVIDIA), ATI Radeon display (CONFIG_FB_RADEON), etc...]

I propose either enabling it automatically with CONFIG_BACKLIGHT_CLASS_DEVICE, or either having a separate option to allow it to be selected manually for external modules.

I add an attachment of a kernel config showing this scenario with FB_BACKLIGHT not set nor any other framebuffer than uvesafb
Comment 1 David 2011-08-03 18:59:08 UTC
Forgot to add URI
[1]: https://github.com/guillaumezin/nvidiabl
Comment 2 Randy Dunlap 2011-08-04 00:55:09 UTC
We can't have CONFIG_BACKLIGHT_CLASS_DEVICE enable CONFIG_FB_BACKLIGHT (via select) because CONFIG_FB_BACKLIGHT already selects BACKLIGHT_CLASS_DEVICE,
so having BACKLIGHT_CLASS_DEVICE select FB_BACKLIGHT would cause a circular
kconfig dependency chain.  We could possibly do your other suggestion of having a separate kconfig option that could be selected manually for external modules, but we don't go to much effort to support external modules.

I'm sending the initial bug report to the linux-fbdev mailing list.
Comment 3 David 2011-08-06 02:39:48 UTC
I think another solution which will be transparent to users.
The source of this problem with nvidiabl is that it is an external module for doing what another modules already do: hability to change backlight of a lcd screen.
The defines needed for this app are just limits for backlight, so I think it should depend on CONFIG_BACKLIGHT_LCD_SUPPORT, better than CONFIG_FB_BACKLIGHT to be more generic and because it does not pertain strictly to a framebuffer (can be used inside a running X session for example with other driver than a fb), I suggest changing the condition to define those variables.

I'll attach a patch that can solve this issue transparently (and I think it won't harm the rest of drivers).

But it is just a suggestion, choose what you find best solution :)
Comment 4 David 2011-08-06 02:40:42 UTC
Created attachment 67732 [details]
Suggested patch addressing problem
Comment 5 Randy Dunlap 2011-08-07 18:21:03 UTC
At a minimum, the other place(s) that protect the use of those macros with #ifdef CONFIG_FB_BACKLIGHT also need to be changed to use #ifdef CONFIG_BACKLIGHT_LCD_SUPPORT.  Did you do any build testing of your patch?
Comment 6 David 2011-08-14 10:22:31 UTC
Yes, I applied my path to 3.0.0 and 3.0.1 and rebuilded nvidiabl with success.
It is also working good, and does not appear to harm any other software nor any other part of system.
Comment 7 David 2011-08-14 10:29:02 UTC
Created attachment 68762 [details]
Kernel config used with previous patch

This is the new config I used to build kernel once applied that patch.
I removed any module I didn't need (that enabled FB_BACKLIGHT) I used as a workarround of this bug.
That's why FB_BACKLIGHT is not set here.
Comment 8 David 2011-08-16 19:51:04 UTC
I(In reply to comment #6)
> Yes, I applied my path to 3.0.0 and 3.0.1 and rebuilded nvidiabl with
> success.
> It is also working good, and does not appear to harm any other software nor
> any
> other part of system.

By rebuilded I meant I rebuilt everything: kernel, and after nvidiabl, and rebooted to test, and worked as expected.
Comment 9 Vasiliy 2011-08-17 08:43:19 UTC
--
Sent from my Nokia N9


On 16/08/2011 22:51 bugzilla-daemon@bugzilla.kernel.org wrote:

https://bugzilla.kernel.org/show_bug.cgi?id=40492





--- Comment #8 from David <StormByte@gmail.com> 2011-08-16 19:51:04 ---
I(In reply to comment #6)
> Yes, I applied my path to 3.0.0 and 3.0.1 and rebuilded nvidiabl with
> success.
> It is also working good, and does not appear to harm any other software nor
> any
> other part of system.

By rebuilded I meant I rebuilt everything: kernel, and after nvidiabl, and
rebooted to test, and worked as expected.

--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
Comment 10 David 2017-02-02 23:08:13 UTC
I am reopening this issue, because in version 4.9.6, this is still present.

I am suggesting adding an explicit CONFIG_FB_BACKLIGHT so users can enable it manually, even when no dependencies set it automatically. This is very useful in cases of, for example, nvidia card is present on UEFI systems, that no other card depending on it is selecting on kernel (and not using nouveau driver).

Can someone take a look of this?

Note You need to log in before you can comment on or make changes to this bug.