On Sun, 10 Jan 2016 21:28:31 +0100 Joerg Jung <[email protected]> wrote: > On Sun, Jan 10, 2016 at 04:59:22AM +0200, Sviatoslav Chagaev wrote: > > Hi, > > > > I'm running -current on Apple MacBook Air 6,2. I installed using Jasper's > > instructions [1], OpenBSD is the only OS and boots via EFI. > > > > I'm experiencing a problem with LCD backlight: on wakeup from suspend, the > > backlight brightness is not restored and becomes unadjustable. If adjusted > > down, > > it turns off, if adjusted up, it goes to 100%. > > I also own a MacBook Air 6,2 and wakeup does not really work at all for > me, as the screen just stays black. Basically I see the same as > reported in [5] for the MacBook Pro.
Try the following: 1) Upgrade to latest snapshot. 2) Bind `wsconsctl display.brightness+=5` to some key combination in your X window manager. 3) On wake up, start adjusting the brightness up. At some magical point (something like 87% for me IIRC) you should observe the backlight turning on and going to 100% brightness. From this point, if you adjust down, the backlight turns off, if you adjust up, the backlight goes to 100%. If you don't observe this, we might be experiencing different issues. > > > An Intel developer claims [2] that it's not a bug in Intel KMS driver and > > people > > claim [3] the problem goes away when booting in legacy BIOS mode. > > That makes no sense to me. If the problem goes aways when booting > legacy BIOS, so it must be a bug when not, right? Judging by the code at e.g. sys/dev/pci/drm/i915/intel_panel.c:984, it seems Intel KMS driver expects BIOS or EFI to configure backlight, then reads these values and uses them itself. I found documentation for Intel Haswell [1] and glanced over descriptions of relevant registers (BLC_PWM_CTL, BLC_PWM2_CTL, BLC_PWM_DATA, BLC_MISC_CTL, BLM_HIST_CTL, BLM_HIST_BIN, BLM_HIST_GUARD, UTIL_PIN_CTL, SBLC_PWM_CTL1, SBLC_PWM_CTL2), they are confusing... Based on these, I agree, it might be a bug in Intel KMS. I'll add debug prints and play with these registers, maybe I'll spot some incorrect values. [1] https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-hsw-commandreference-registers_0_0.pdf > > > It turns out [4], a numbers of MacBook models [5], including mine, have a > > Texas > > Instruments LP8550 LED backlight controller on I2C bus. By default, it's > > controlled by external PWM. But it can be configured to be controlled by > > it's > > own internal register instead. > > > > So below is a driver for TI LP8550. > > > > With this driver, after wake up from suspend, the brightness level is > > restored > > and can be freely adjusted. > > I've tested the driver and while it compiles and attaches fine it does > not work for me. After switching to console the screen stays black. Yep, it needs to be integrated with Intel KMS to not break anything... > > > The catch is that Intel KMS driver seems to control the chip's ``EN'' pin > > (basically an on/off pin). So whenever Intel KMS toggles the backlight, > > namely > > on power management (e.g. `xset dpms force off`) and on Xorg <--> VT > > switch, > > the chip's brightness control register gets reset and you need to > > `wsconsctl display.backlight=<non_zero>` to turn the backlight back on. > > > > But it beats rebooting. > > Not for me, with my machine -current works better without your patch, > because I can switch from X to console and back and brightness is > correctly adjusted. > > > If there's any chance for it to be commited, please tell me what I need to > > fix/improve to get it commited (so I don't have to reapply it every time I > > upgrade). > > IMHO, instead of adding another driver to the mix, I would prefer this > to be handled through the associated asmc(4) keys instead of accessing > the chip directly. The SMC is supposed to be the central point for such > manipulations. Unfortunately, the keys are not documented and need some > non-trivial effort to be figured out. > > If this is not possible through asmc(4) and if your new driver improves > the situation then I'm fine with importing it, but for now it is just > worse. > > > Next step could be to somehow integrate it with Intel KMS. > > Yes, for me this is must-have before it can be committed. > > Some minor style comments on the code inline below. Thanks, if there will be a next version of this diff, I'll fix them.
