Thu, 7 Apr 2016 22:05:26 +0200 (CEST) Mark Kettenis <mark.kette...@xs4all.nl> > > There are a few instances of this bug. You can also see it with cpu > > frequency and audio volume. > > > > Most drivers maintain soft state that should mirror the hardware > > state. Except when it doesn't. Sometimes the driver has a bug, > > sometimes the hardware lies, sometimes something else goes > > wrong. The many layers of abstraction and acpi don't help either. > > There are defenitely machines out there where the acpi implementation > sufferes from exactly this problem. The AML method that reports back > the current brightness level doesn't actually query the hardware, but > simply reports back the soft state. And that soft state isn't > properly initialized! It wouldn't surprise me if Windows never > actually calls that method, or at least always explicitly sets the > level it wants withour querying the hardware. > > > It's a bug and it's worth reporting as much info about your hardware as > > possible, but don't expect a quick fix. As a workaround, just run > > 'xbacklight > > 50 ; xbacklight 100' or whatever you want. > > Or better, add lines like: > > display.brightness=50 > display.brightness=100 > > to /etc/wsconsctl.conf. > > To be able to fix problems like this we need dmesg and acpidump > output. If you use sendbug(1) to file a bug report, that information > is automatically included if you run it as root. As a bonus, the mail > gets sent to an address that developers actually read...
There is a recent change in behaviour in xbacklight operation on a N280 1005ha, which brings the back-lighting behaviour in consistency with XP. Previously the other OS would change it from very dark to full bright in steps of about 10 (never counted) them, while our behaviour was to go from complete off 0 to full bright 100 in steps of 1. I liked our. After the recent change, our behaviour is similar to the other OS, i.e. that it goes from very dark but NOT off, 0 to 100 in steps of about 7.7 points, which gives coarser adjust, and does not seem more appropriate. If however it is more correct in terms of ACPI consistency, I have no objection, have already changed my way around it. Just mentioning it.
