On Wednesday 11 October 2006 00:10, Matt Domsch wrote: > On Tue, Oct 10, 2006 at 03:47:26PM +0100, Richard Hughes wrote: > > On Tue, 2006-10-10 at 22:32 +0800, Yu Luming wrote: > > > >From my understanding, a cute userspace App shouldn't have this kind > > > > > > of logic: > > > if (is DELL ) > > > invoke libsmbios > > > if (is foo) > > > invoke libfoo, > > > if (is bar) > > > invoke libbar, > > > .... > > > else > > > operate on /sys/class/backlight/ ,.,.. > > > > This is what HAL has at the moment[1]. And it's hell to maintain, but > > works for a lot of users. > > This is slightly different. This shows that there are a number of > slightly different kernel implementations: > > /proc/acpi/toshiba/lcd > /proc/acpi/asus/brn > /proc/acpi/pcc/brightness > /proc/acpi/ibm/brightness > /proc/acpi/sony/brightness > /proc/omnibook/lcd > > which is indeed nasty. I'd agree all in-kernel solutions should use > the same kernel<->user interface. I'd also expect the kernel to have Yes, we all seem to agree we need to throw away /proc/acpi just after we have solid sysfs interface for acpi. > a generic ACPI driver that exports the _BCL and _BCM method > implementations via that same interface, so that systems providing > that will "just work". drivers/acpi/video.c currently exports this > via /proc/acpi/video/$DEVICE/brightness, which isn't the same as > /sys/class/backlight. :-( Yes, I'm working on acpi video driver transition , and have posted a patch to user backlight for acpi video driver. http://marc.theaimsgroup.com/?l=linux-acpi&m=115574087203605&w=2 > > There's also at least one more userspace option for the sonypi using > spiictrl. This is where I expected libsmbios to plug in also, as a > fallback to the ACPI _BCL/_BCM methods above. I think spiictrl would be thrown away just after we have solid sysfs support. Thanks, Luming - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
