> Date: Sun, 10 Jan 2016 21:28:31 +0100 > From: Joerg Jung <m...@umaxx.net> > > 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. > > > 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? > > > 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. > > > 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.
Also, I'dlike to see the acpidump output for this machine before we decide things are indeed broken.
