| Message ID | BANLkTi=hUBrKnbrF+Q_ZOxdUPVSOUYUm2Q@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Michael Chang -- Tuesday 10 May 2011: > Could you please try this patch and get the log ? We wonder why > is_backlight_combination_mode () returns false. This information was already buried in the bugzilla thread: https://bugzilla.kernel.org/show_bug.cgi?id=31522 "It turned out that on this machine INTEL_INFO(dev)->gen equals 4, and is_backlight_combination_mode() returns 0x40000000." But to say it again in your words: :-) [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 (0x40000000) 6x during boot-up, and several times later when changing the backlight brightness. This was with 8b061610dac3a3b89770c85ad63b481a47b0c38e. And now I have a little shocker for you (and me): because this was a vanilla kernel (apart from these debug messages), the screen went black again, like I knew it. But pressing the "brightness down" key turns the backlight on! I can't believe that I haven't tested that. I guess I've only tried "brightness up" and "display toggle". Those don't turn backlight on. Or maybe somethine else relevant meanwhile changed in the i915 drivers. (I've regularly been updating to HEAD.) So, the problem was just the initial state all the time? m.
Forward to upstream for more discussion. ? ??2011-05-13 ? 17:27 +0800?Michael Chang ??? > Melchior, > > I tried to puzzle out the possible cause of the problem, but sorry > that no further progress to give you. I'd like to debug this issue, > also did Joey. But there's more questions in my mind, made me feel not > able to proceed any further.. :( > > 1. is_backlight_combination_mode() really returns 0x4 ..? I understand > your words, but if this is true then Joey Lee provided patch should > log out some information about changing the LPBC > > set backlight lbpc = ... > > but I didn't see any of the log output .. :( > > 2. I dig the old mailing thread .. found a post > > http://marc.info/?l=linux-kernel&m=130462815211684&w=2 > > If you rebase this patch to your currently git commit, will it fixes > all problems for you now (only vanilla kernel with this patch)? (You > replied that this patch works for you ..) Also another interesting > finding... > > > + if (!lbpc) > > + combo_mode = 0; > > Looks like the purpose of it is to NOT touch the LPBC registers if > lbpc is zero ...(since this forces is_backlight_combination_mode > return 0). This would make contradiction about the assumption that you > could change to back-light via LPBC .. (using setpci is actually > access the LPBC registers .. IMHO). > > Total a mess for me now .. Did I made anything wrong .. I know I may > lose some details. > > I'm thinking is it ok for us to discuss in IRC, the communication > would be more efficient. Would this be convenient for you ? This is up > to you. > > Have nice weekend .. :) > > Regards, > Michael Chang > > 2011/5/10 Melchior FRANZ <melchior.franz@gmail.com>: > > * Michael Chang -- Tuesday 10 May 2011: > >> Could you please try this patch and get the log ? We wonder why > >> is_backlight_combination_mode () returns false. > > > > This information was already buried in the bugzilla thread: > > > > https://bugzilla.kernel.org/show_bug.cgi?id=31522 > > "It turned out that on this machine INTEL_INFO(dev)->gen equals 4, > > and is_backlight_combination_mode() returns 0x40000000." > > > > > > But to say it again in your words: :-) > > > > [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 (0x40000000) > > > > 6x during boot-up, and several times later when changing the backlight > > brightness. > > > > > > This was with 8b061610dac3a3b89770c85ad63b481a47b0c38e. And now > > I have a little shocker for you (and me): because this was a > > vanilla kernel (apart from these debug messages), the screen went > > black again, like I knew it. But pressing the "brightness down" > > key turns the backlight on! I can't believe that I haven't tested > > that. I guess I've only tried "brightness up" and "display toggle". > > Those don't turn backlight on. Or maybe somethine else relevant > > meanwhile changed in the i915 drivers. (I've regularly been > > updating to HEAD.) > > > > So, the problem was just the initial state all the time? > > > > m. > >
At Tue, 10 May 2011 13:08:23 +0200, Melchior FRANZ wrote: > > * Michael Chang -- Tuesday 10 May 2011: > > Could you please try this patch and get the log ? We wonder why > > is_backlight_combination_mode () returns false. > > This information was already buried in the bugzilla thread: > > https://bugzilla.kernel.org/show_bug.cgi?id=31522 > "It turned out that on this machine INTEL_INFO(dev)->gen equals 4, > and is_backlight_combination_mode() returns 0x40000000." > > > But to say it again in your words: :-) > > [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 (0x40000000) > > 6x during boot-up, and several times later when changing the backlight > brightness. > > > This was with 8b061610dac3a3b89770c85ad63b481a47b0c38e. And now > I have a little shocker for you (and me): because this was a > vanilla kernel (apart from these debug messages), the screen went > black again, like I knew it. But pressing the "brightness down" > key turns the backlight on! I can't believe that I haven't tested > that. I guess I've only tried "brightness up" and "display toggle". > Those don't turn backlight on. Or maybe somethine else relevant > meanwhile changed in the i915 drivers. (I've regularly been > updating to HEAD.) > > So, the problem was just the initial state all the time? Looks so, indeed. Now, the question is what's the real cause. IIRC, you reported that the backlight gets normal when you revert my commit in 2.6.38.x. So, this was regarded as a regression at first. But, one question remains: whether the backlight level control worked with the reverted kernel? Judging from the attempts so far, it looks like that only LBPC can adjust the level on your machine. If it's true, 2.6.38.0 shouldn't be able to adjust the level. If you can still change the level without LBPC, the former analysis was incorrect. Also, with the latest 2.6.38.x, you found that the backlight gets back when you adjust the level down. Another question now is what happens if you again turn it up to the max level. Is the backlight still on? If the backlight is kept on even with the max level, it implies that the problem is only the initial value; once when set correctly, it'll work fine after that. OTOH, if the backlight gets off again at max, it means that the max value (LBPC 0xfe) is a sort of out-of-range. Then LBPC calculation in the driver has to be modified. thanks, Takashi
Hey, * Michael Chang -- Friday 13 May 2011: > But there's more questions in my mind, made me feel not > able to proceed any further.. :( No problem. The reason for inconsistencies in my reports is simply that I've realized some properties only later. So here's a new error description, based on ddb503b42960, which is current HEAD. On this "Acer Travelmate 5735Z-452G32Mnss" the following happens since after 2.6.37-rc8, with acpi_osi=Linux: - the backlight goes dark as soon as KMS takes over early in the boot process (the screen contents aren't corrupted, though, and under appropriate lighting conditions I can even see the (very dark) uncorrupted contents.) - when I press the "backlight darker" key, the backlight is turned on. (No other key does that AFAICS, including "display toggle" and "backlight brighter.) Everything works correctly after that, including backlight adjustment, BUT: - when I close the lid and open it again, the backlight stays black again, just like before. Backlight adjustment turns it on, and now even the "brighter" key does it sometimes, but not always.) > 1. is_backlight_combination_mode() really returns 0x4 ..? From https://bugzilla.kernel.org/show_bug.cgi?id=31522, comment #8: "It turned out that on this machine INTEL_INFO(dev)->gen equals 4, and is_backlight_combination_mode() returns 0x40000000." That was true when I reported it. But lpbc was always 0 in my tests back then, and now it's not. > I understand your words, but if this is true then Joey Lee provided > patch should log out some information about changing the LPBC > > set backlight lbpc = ... > > but I didn't see any of the log output .. :( You hadn't told me that these patches were meant to be incremental, so I backed the first logging patch out before applying the other. Here is the result of ddb503b42960 with both logging patches applied: boot phase: [ 2.620237] [drm] Initialized drm 1.1.0 20060810 [ 2.664806] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 2.664812] i915 0000:00:02.0: setting latency timer to 64 [ 2.726569] [drm:intel_opregion_setup], graphic opregion physical addr: 0x7ba8c018 [ 2.726612] [drm:intel_opregion_setup], Public ACPI methods supported [ 2.726615] [drm:intel_opregion_setup], SWSCI supported [ 2.726617] [drm:intel_opregion_setup], ASLE supported [ 2.726650] i915 0000:00:02.0: irq 44 for MSI/MSI-X [ 2.726655] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 2.726656] [drm] Driver supports precise vblank timestamp query. [ 2.753294] [drm:init_status_page], render ring hws offset: 0x00000000 [ 2.753431] [drm:init_status_page], bsd ring hws offset: 0x00021000 [ 2.753547] [drm:intel_parse_bios], Using VBT from OpRegion: $VBT CANTIGA d [ 2.797315] [drm:intel_panel_get_backlight], get backlight val = 2890 [ 2.797319] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 2.797322] [drm:intel_panel_get_backlight], get backlight PWM = 0 [ 2.797328] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 2.797658] [drm:intel_panel_set_backlight], set backlight PWM = 0 [ 2.797661] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 2.797664] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 2.797667] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [ 2.797669] [drm:intel_panel_set_backlight], set backlight max = 736950 [ 2.797671] [drm:intel_panel_set_backlight], set backlight lbpc = 1 [ 2.797678] [drm:intel_opregion_asle_intr], non asle set request?? [ 2.797681] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401930 [ 2.797683] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040 [ 2.797685] [drm:intel_panel_set_backlight], set backlight level = 0 [ 2.905962] scsi 4:0:0:0: Direct-Access Generic- Multi-Card 1.00 PQ: 0 ANSI: 0 CCS [ 3.040041] [drm:gm45_get_vblank_counter], trying to get vblank count for disabled pipe A [ 3.040047] [drm:gm45_get_vblank_counter], trying to get vblank count for disabled pipe A [ 3.090368] checking generic (80000000 3ff0000) vs hw (80000000 10000000) [ 3.090373] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver [ 3.090392] Console: switching to colour dummy device 80x25 [ 3.091058] fbcon: inteldrmfb (fb0) is primary device [ 3.125522] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 3.125525] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [ 3.125527] [drm:intel_panel_set_backlight], set backlight PWM = 736950 [ 3.125529] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 3.125531] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 3.125533] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [ 3.125535] [drm:intel_panel_set_backlight], set backlight max = 736950 [ 3.125537] [drm:intel_panel_set_backlight], set backlight lbpc = 255 [ 3.125541] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399040 [ 3.125543] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040 [ 3.125544] [drm:intel_panel_set_backlight], set backlight level = 2890 [ 3.125557] [drm:intel_opregion_asle_intr], [ 3.125559] Console: switching non asle set request?? [ 3.125562] to colour frame buffer device 170x48 [ 3.128264] fb0: inteldrmfb frame buffer device [ 3.128265] drm: registered panic notifier [ 3.429079] acpi device:07: registered as cooling_device2 [ 3.429425] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:01/input/input6 [ 3.429521] ACPI: Video Device [OVGA] (multi-head: yes rom: no post: no) [ 3.429980] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 3.806479] sd 4:0:0:0: [sdb] 15720448 512-byte logical blocks: (8.04 GB/7.49 GiB) [ 3.807220] sd 4:0:0:0: [sdb] Write Protect is off [ 3.807222] sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00 [ 3.807225] sd 4:0:0:0: [sdb] Assuming drive cache: write through [ 3.809345] sd 4:0:0:0: [sdb] Assuming drive cache: write through [ 3.813728] sdb: sdb1 [ 3.815475] sd 4:0:0:0: [sdb] Assuming drive cache: write through [ 3.815513] sd 4:0:0:0: [sdb] Attached SCSI removable disk [ 4.786309] md: linear personality registered for level -1 [ 84.936637] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 84.936641] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [ 84.936644] [drm:intel_panel_set_backlight], set backlight PWM = 72250 [ 84.936646] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 84.936649] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 84.936652] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [ 84.936654] [drm:intel_panel_set_backlight], set backlight max = 736950 [ 84.936656] [drm:intel_panel_set_backlight], set backlight lbpc = 25 [ 84.936660] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401930 [ 84.936662] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040 [ 84.936664] [drm:intel_panel_set_backlight], set backlight level = 2890 [ 84.936669] [drm:intel_opregion_asle_intr], non asle set request?? [ 84.936672] [drm:intel_opregion_asle_intr], non asle set request?? brighter: [ 325.356259] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 325.356268] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [ 325.356273] [drm:intel_panel_set_backlight], set backlight PWM = 0 [ 325.356278] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 325.356283] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 325.356288] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [ 325.356292] [drm:intel_panel_set_backlight], set backlight max = 736950 [ 325.356297] [drm:intel_panel_set_backlight], set backlight lbpc = 1 [ 325.356302] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401930 [ 325.356307] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040 [ 325.356311] [drm:intel_panel_set_backlight], set backlight level = 0 [ 325.356318] [drm:intel_opregion_asle_intr], non asle set request?? [ 325.356324] [drm:intel_opregion_asle_intr], non asle set request?? darker: [ 359.642417] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 359.642424] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [ 359.642429] [drm:intel_panel_set_backlight], set backlight PWM = 72250 [ 359.642434] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 359.642439] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 359.642443] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [ 359.642448] [drm:intel_panel_set_backlight], set backlight max = 736950 [ 359.642452] [drm:intel_panel_set_backlight], set backlight lbpc = 25 [ 359.642458] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399040 [ 359.642463] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040 [ 359.642467] [drm:intel_panel_set_backlight], set backlight level = 2890 [ 359.642474] [drm:intel_opregion_asle_intr], non asle set request?? [ 359.642480] [drm:intel_opregion_asle_intr], non asle set request?? > http://marc.info/?l=linux-kernel&m=130462815211684&w=2 > > If you rebase this patch to your currently git commit, will it fixes > all problems [...] This patch didn't fix my problems back then, and since an always zeroed lbpc is apparently not the case, I assume this test wouldn't be very helpful. Of course, if you insist, then I'll try it again. Thanks for your help, and sorry for the confusion. :-) m.
* Takashi Iwai -- Sunday 15 May 2011: > IIRC, you reported that the backlight gets normal when you revert my > commit in 2.6.38.x. So, this was regarded as a regression at first. Yes. And it *is* a regression, which is the whole point of my initial complaint, as reported by Maciej in https://bugzilla.kernel.org/show_bug.cgi?id=31522 > But, one question remains: whether the backlight level control worked > with the reverted kernel? Good point. Turns out it didn't work with 2.6.38-rc8 either. But it did work at some time before. (I use this notebook mainly as a terminal ATM, so I didn't care much for backlight level. This came up later during investigation.) So the only thing that 2.6.38 broke was that the backlight was initially off. Adjustment had already been broken before (and works now again; sigh ... confused? I am! :-). > If you can still change the level without > LBPC, the former analysis was incorrect. I don't even know what an LBPC is, other than a variable named like that. So I'd need a hint for how to test that. > Also, with the latest 2.6.38.x, you found that the backlight gets back > when you adjust the level down. When I reported this, it was about 2.6.39-* and HEAD, not stable versions. But I tried now, and openSuSE's 2.6.38.6 behaves the same. > Another question now is what happens if you again turn it up to the > max level. Is the backlight still on? Yes. If the backlight was on at one point, then increasing the level to maximum never turned if off. > If the backlight is kept on even with the max level, it implies that > the problem is only the initial value; once when set correctly, it'll > work fine after that. Yes, that's the case. (Except that after closing the lid it's off again.) m.
2011/5/16 Melchior FRANZ <melchior.franz@gmail.com>: > I don't even know what an LBPC is, other than a variable named like that. > So I'd need a hint for how to test that. It resides at your vga adapter's pci configuration space, offset 0xf4. You can know your LPBC value by: $ lspci -xxx -s 00:02.0 | awk '/^f0:/ {print $6}' And alter it's value via setpci (assuming set it to max) $ setpci -s 00:02.0 F4.B=ff I assume you've tried this .. as you report setpci works for you. :) From your new attached log, In booting phase your LPBC is set to 255 and actual brightness is maximum (255*2890=736950). I see no other change after it until manual brightness change. This is a totally reversed to your problem. Could you help to get the LPBC value in the initial dark condition? If it's not corresponds to 255, maybe something sneaks and changes it but not logged. [ 3.125522] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 3.125525] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [ 3.125527] [drm:intel_panel_set_backlight], set backlight PWM = 736950 [ 3.125529] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 3.125531] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 3.125533] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [ 3.125535] [drm:intel_panel_set_backlight], set backlight max = 736950 [ 3.125537] [drm:intel_panel_set_backlight], set backlight lbpc = 255 [ 3.125544] [drm:intel_panel_set_backlight], set backlight level = 2890 > Yes, that's the case. (Except that after closing the lid it's off again.) Maybe this is another clue for root cause. Would it be convenient for you to gather the log? 1. $ dmesg -c 2. Close the lid 3. Open the lid 4. $ dmesg > dmesg.lid Thanks a lot, Michael Chang
* Michael Chang -- Tuesday 17 May 2011: [LBPC] > You can know your LPBC value by: > $ lspci -xxx -s 00:02.0 | awk '/^f0:/ {print $6}' > > And alter it's value via setpci (assuming set it to max) > $ setpci -s 00:02.0 F4.B=ff > > I assume you've tried this .. as you report setpci works for you. :) Ahh, yes, indeed. This lspci line (almost) always shows a value that corresponds with the actual backlight brightness, and both lines work with and without acpi_osi=Linux. (Whereas adjustment via keys only works *with* acpi_osi=Linux.) (Tested with 2.6.39-rc7/bd1a643e10) > Could you help to get the LPBC value in the initial dark condition? If > it's not corresponds to 255, maybe something sneaks and changes it but > not logged. Initially (with acpi_osi=Linux) LPBC=0xff. After "brightness down" it's 0x19, and after then pressing "brightness up" it's 0x01. The lowest value I can achieve after pressing "brightness down" a few times is 0xe5, the highest is 0x01. Neither 0xff nor 0x00 can be reached via keys, but can (most of the time -- see below!) be set with the setpci line and give the expected results, backlight off and fully on. ("display toggle" has no effect on LBPC, btw.) Setting 0xFF doesn't always turn the backlight off, though! If LBPC is at the (key) maximum 0x01, then setting 0xFF via setpci changes only the LBPC value as shown by lspci, but the backlight isn't actually turned off! If I then press "backlight darker" once (LBPC=0x19), then setting 0xFF via setpci works again. > 1. $ dmesg -c > 2. Close the lid > 3. Open the lid > 4. $ dmesg > dmesg.lid The results are: [ 188.571040] [drm:intel_panel_set_backlight], set backlight PWM = 736950 [ 188.571048] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 188.571054] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 [ 188.571059] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 [ 188.571064] [drm:intel_panel_set_backlight], set backlight max = 736950 [ 188.571069] [drm:intel_panel_set_backlight], set backlight lbpc = 255 [ 188.571075] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399040 [ 188.571080] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040 [ 188.571084] [drm:intel_panel_set_backlight], [ 188.571088] [drm:intel_opregion_asle_intr], non asle set request?? [ 188.571093] set backlight level = 2890 The backlight is off now, as always after closing/reopening the lid, and LPBC=0xff. m. PS: I'd be willing to join an irc.freenode.net channel in case you or anyone else wants quicker ("live") responses to such queries.
Melchior, I want to double check with you. If you change brightness from lowest to highest, the LPBC value changes this way Highest Lowest 0x10 , 0x19 ...... 0xe5 And vice versa, from Lowest to Highest Lowest Highest 0xe5 , ...... 0x19 0x10 If above is true, then you have a very particular notebook that reverse the sense of the LPBC values .... I don't know who ever came across such device. wow. Regarding that your brightness control key, due to that it is controlled by acer_wmi and likely that BIOS aware this, it would do brightness in a reversed way. I think Joey would check DSDT and see any clue or evidence for this. OTOH the i915 driver didn't aware of this and operates as usual sense that means falling into the trap. PS. I see your log always reverse the sense of this LPBC value, now I know why. :) Regards, Michael Chang 2011/5/17 Melchior FRANZ <melchior.franz@gmail.com>: > * Michael Chang -- Tuesday 17 May 2011: > [LBPC] >> You can know your LPBC value by: >> $ lspci -xxx -s 00:02.0 | awk '/^f0:/ {print $6}' >> >> And alter it's value via setpci (assuming set it to max) >> $ setpci -s 00:02.0 F4.B=ff >> >> I assume you've tried this .. as you report setpci works for you. :) > > Ahh, yes, indeed. This lspci line (almost) always shows a value that > corresponds with the actual backlight brightness, and both lines work > with and without acpi_osi=Linux. (Whereas adjustment via keys only works > *with* acpi_osi=Linux.) (Tested with 2.6.39-rc7/bd1a643e10) > > > >> Could you help to get the LPBC value in the initial dark condition? If >> it's not corresponds to 255, maybe something sneaks and changes it but >> not logged. > > Initially (with acpi_osi=Linux) LPBC=0xff. After "brightness down" > it's 0x19, and after then pressing "brightness up" it's 0x01. The lowest > value I can achieve after pressing "brightness down" a few times is 0xe5, > the highest is 0x01. Neither 0xff nor 0x00 can be reached via keys, but > can (most of the time -- see below!) be set with the setpci line and give > the expected results, backlight off and fully on. ("display toggle" has > no effect on LBPC, btw.) > > Setting 0xFF doesn't always turn the backlight off, though! If LBPC is > at the (key) maximum 0x01, then setting 0xFF via setpci changes only the > LBPC value as shown by lspci, but the backlight isn't actually turned off! > If I then press "backlight darker" once (LBPC=0x19), then setting 0xFF > via setpci works again. > > > >> 1. $ dmesg -c >> 2. Close the lid >> 3. Open the lid >> 4. $ dmesg > dmesg.lid > > The results are: > > [ 188.571040] [drm:intel_panel_set_backlight], set backlight PWM = 736950 > [ 188.571048] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 > [ 188.571054] [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824 > [ 188.571059] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950 > [ 188.571064] [drm:intel_panel_set_backlight], set backlight max = 736950 > [ 188.571069] [drm:intel_panel_set_backlight], set backlight lbpc = 255 > [ 188.571075] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399040 > [ 188.571080] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040 > [ 188.571084] [drm:intel_panel_set_backlight], > [ 188.571088] [drm:intel_opregion_asle_intr], non asle set request?? > [ 188.571093] set backlight level = 2890 > > The backlight is off now, as always after closing/reopening the lid, > and LPBC=0xff. > > m. > > > > PS: I'd be willing to join an irc.freenode.net channel in case you or > anyone else wants quicker ("live") responses to such queries. >
Hey, * Michael Chang -- Tuesday 17 May 2011: > If you change brightness from lowest to highest, the LPBC value changes > this way > > Highest Lowest > 0x10 , 0x19 ...... 0xe5 Yes. (Though it's 0x01, not 0x10.) ---0xFF ... initial value and after closing/reopening lid | 0xE5 \ ... dark | 0xCC | | 0xB2 | (1)| 0x99 | | 0x7F |_____key adjustable range | 0x66 | | 0x4C | | 0x33 | -->0x19 | 0x01 / ... bright 0x00 ... also bright, only settable with setpci (1) is the jump that resurrects the backlight from darkness by pressing the "brightness down" key And again, if fully turned up via keys (and therefore at 0x01), then setting to 0xff with setpci doesn't turn it off. At all other key steps it does. :-) > If above is true, then you have a very particular notebook that > reverse the sense of the LPBC values .... I don't know who ever came > across such device. wow. Maybe they screwed it up and therefore sold it with Linux ("linpus") and a custom driver preinstalled ... > Regarding that your brightness control key, due to that it is > controlled by acer_wmi and likely that BIOS aware this, it would do > brightness in a reversed way. acer_wmi doesn't do the brightness adjustment. But maybe under "linpus" some variant of it did. (BTW: there are two keys on this notebook that aren't handled by the kernel, by X11 or even acer_wmi. There are just no events for them. Looks like another ACER brain damage err.. "capability". :-) m.
diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index a06ff07..8f14bfa 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -116,12 +116,21 @@ static int Melchior(struct drm_device *dev) { struct drm_i915_private *dev_priv = dev->dev_private; - if (INTEL_INFO(dev)->gen >= 4) - return I915_READ(BLC_PWM_CTL2) & BLM_COMBINATION_MODE; + if (INTEL_INFO(dev)->gen >= 4) { - if (IS_GEN2(dev)) - return I915_READ(BLC_PWM_CTL) & BLM_LEGACY_MODE; + int ret = I915_READ(BLC_PWM_CTL2) & BLM_COMBINATION_MODE; + DRM_DEBUG_DRIVER("BLM_COMBINATION_MODE = %d\n", ret); + return ret; + } + + if (IS_GEN2(dev)) { + int ret = I915_READ(BLC_PWM_CTL) & BLM_LEGACY_MODE; + DRM_DEBUG_DRIVER("BLM_LEGACY_MODE = %d\n", ret); + return ret; + } + + DRM_DEBUG_DRIVER("Do nothing, return false\n"); return 0; }