-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-09-05 16:04:56 -0400, Bengt Ahlgren wrote: > Jung-uk Kim <j...@freebsd.org> writes: > >> On 2013-09-04 18:47:47 -0400, Jung-uk Kim wrote: >>> On 2013-09-04 18:39:07 -0400, Bengt Ahlgren wrote: >>>> The value of hw.acpi.video.lcd0.brightness changes when the >>>> screen brightness keys (Fn+Home/End) are pressed, but >>>> nothing happens with the screen. Same goes for changing the >>>> value with sysctl. After a fresh boot it works with one >>>> issue. The screen brightness level seems to lag behind one >>>> keypress. Without acpi_video, screen brightness changes >>>> without the lag. >>> >>>> hw.acpi.video.lcd0.active is always stuck at 0 - can't >>>> change with sysctl (regardless if the screen is on after a >>>> fresh boot, or black after a text console suspend/resume): >>> >>>> [root@bit ~]# sysctl hw.acpi.video.lcd0.active=1 >>>> hw.acpi.video.lcd0.active: 0 -> 0 >>> >>>> Again, for my old X40 with non-KMS Xorg intel driver has >>>> (curiously, the screen blinks when issuing this sysctl >>>> command): >>> >>>> [bengta@P142 ~]$ sysctl hw.acpi.video >>>> hw.acpi.video.lcd0.active: 1 hw.acpi.video.crt0.active: 0 >>> >>> Then, KMS probably breaks acpi_video(4), too. :-( >> >> kib let me know that there is a way to make it work but it was >> not well-integrated to i915kms.ko. If you are interested in >> fixing it, dev/drm2/i915/intel_opregion.c is the source and you >> can download the specification from here: >> >> https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf > >> > Hmm, scanning that spec, I wonder whether the opregion > functionality is better placed together with acpi_video, and then > i915kms makes calls to that instead?
Traditionally, platform-specific code goes to dev/acpi_support. So, dev/acpi_support/acpi_intel.c may be created to cater its needs, if it is absolutely necessary. > Hmm, again, perhaps the intel platform needs opregion support to > work properly also without the kms driver. Could be anexplanation > for the backlight issues. Yes and yes, I think. However, many developers are tired of dealing with syscons ugliness and now the Foundation is sponsoring ray@ to replace syscons with newcons+KMS if my understanding is correct. I am not sure how it will be layered at the end, though. > (Just speculation so far... I have no idea if/how this relates to > or interacts with options VESA) Apparently, they interact badly. :-( Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSKOpXAAoJECXpabHZMqHOSnIIANS/Kt043RI7fFLNYVeWvpH0 zQ8C3wTi66aIW9B5bvYcXcJXcE1yazfegbtAHT6i0Hf4/BrvoMkN3umHIRYMbMv9 ei7WoFDLRIuyGzqgMy7CP3t9byYZolRBuyIt+zELsNU/5zCkgSP3di40TK+oLJ+3 NXhALsLZA37B1S3TYaiLy+U4BylfC3iNhFDlDRrikuYvAym/s5o/Ro0Ea8dyUw4i CtWDEomCIwjzOuythAl1wlXYeMtZZp+6Fj2Pemhh9COzFXgHiTfhfVySRVt0tBAs 6FKmQnc30ra2clU1o5JJuzwlOsgGH+aztvrdjc4VGr/wGpdmKW6FrNlpcku1VkQ= =i0JD -----END PGP SIGNATURE----- _______________________________________________ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
