| Summary: | intel_backlight on "switchable" graphics | ||
|---|---|---|---|
| Product: | [Unmaintained] solid | Reporter: | Aaron Bauman <bmangentoo> |
| Component: | powermanagement | Assignee: | Dario Freddi <drf> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | afiestas, bernd.paysan, bmangentoo |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Aaron Bauman
2012-01-30 15:13:48 UTC
Can you cat /sys/class/backlight/acpi_video1/type /sys/class/backlight/acpi_video0/type /sys/class/backlight/intel_backlight/type Thanks. video1 = firmware video0 = firmware intel_backlight = raw Ok so, do you have any idea of how to deal with swicheable GPU ?any idea of knowing which video_acpi is the correct one? Alex, I am able to adjust the brightness by modifying the intel_backlight/brightness file. As far as dealing with the dual GPU's I have been unsuccessful in the switcheroo (kernel) or even starting X with the radeon. If I were booted and running off of the radeon I am unsure which video1 or video0 would become relevant at that point. Other reports say the radeon GPU does the rendering but everything is sent back through the intel card so that would change things. I hope this helps. Please feel free to ask any further questions. I am more than happy to assist! intel_backlight is now the "last resource interface" since it is "raw" instead we will prioritize the ones with interface "firmware". I'm going to push a commit in a few minutes that will close this bug (since it is against 4.8) which will put intel_backlight after acpi_video1/0. Not related to this bug, can you give me the output of everything within acpi_video1/0 folders? Thanks ! So why is it not currently working? I am unsure how it is determined that an interface, while available, is not the correct one? Working on getting you the data you requested as well. Do you need just the main files in the acpi_video1/0 or all the subdirectories as well? Git commit 018679ecdd07a2fd8dfb27df79355465252e8bc2 by Alex Fiestas. Committed on 02/02/2012 at 23:59. Pushed by afiestas into branch 'KDE/4.8'. Put acpi_video1/0 before intel_backlight Now we know that firmware interface should be put BEFORE the raw ones so in this case, acpi_video1/0 are firmware and intel_backlight is RAW. Related: bug 288180 M +4 -3 powerdevil/daemon/backends/upower/backlighthelper.cpp http://commits.kde.org/kde-workspace/018679ecdd07a2fd8dfb27df79355465252e8bc2 Git commit 5257ff19aa3e779a9e07cc49ee82cca7a051b558 by Alex Fiestas. Committed on 03/02/2012 at 02:12. Pushed by afiestas into branch 'master'. If kernel newer than 2.6.36 use the backlight type instead of whitelist If the kernel is newer than 2.6.36 it indicates the type of the backlight wether it is a firmware/platform or raw. We should attempt to connect to these interfaces in this order. This should fix any compatibility issue we have right now and make this code comaptible with drivers that may appear in the future. Related: bug 288180 CCMAIL: lukas@kde.org FIXED-IN: 4.9 M +97 -5 powerdevil/daemon/backends/upower/backlighthelper.cpp M +19 -0 powerdevil/daemon/backends/upower/backlighthelper.h http://commits.kde.org/kde-workspace/5257ff19aa3e779a9e07cc49ee82cca7a051b558 WEll not is not determinated by any logic but a whitelist, the last change shown in the report (5257ff1) changes that by prefering the ones with type firmware. In your case, acpi_video1 will be loaded which is working for you. Once switcheable graphics is working perfect we will have to adapt the code to pic the "active one". Understood, I applied the patch with no luck of controlling it. intel_backlight is my active one. What do you mean with Alex, I applied your patch to powerdevil in hopes of controlling the backlight with power management (battery applet, fn keys etc). I am not able to though. intel_backlight is what I am able to manually (echo foo > /sys/class/backlight/intel_backlight/brightness) control to change brightness settings. I see, then I'm afraid it is some kind of error in the stack below KDE, what we have been told from Kernel developer is: -Firmware drivers first -Then platform -finally Raw intel_backlight is a raw driver and since you have some others (acpi_video0-1) which are firmware we are selecting them. can you give me some more information about your hardware? maybe lshw output? Alex, first and foremost thank you for your patience on this bug and the awesome feedback. Here is a link to my lshw output. http://pastebin.com/kk3TztYE Alex, I have been able to get my discrete graphics card working and the issue still remains. So the system is not using the acpi_video0/1 at all it seems. Are you able to change your brightness by echoing to them as you do with intel_brightness ? No I am not able to. intel is the only one that works even while utilizing the discrete card. Others are saying the acpi kernel driver is just ignorant so this may be out of the KDE realm as you mentioned. I've the same problem with an Asus UX32VD, with Intel HD4000+NVidia 620M. The thing the kernel developer propose does not work - you have to use the raw file. I don't even see any reaction from the acpi files, regardless if setting acpi_backlight=vendor or =video (which creates two different firmware backlights). |