<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Hello Danny, <blockquote cite="mid200604181258.17338.danny.kukawka@web.de" type="cite"> <blockquote type="cite"> <pre wrap="">David, good to commit? </pre> </blockquote> <pre wrap=""> No, it's not good to commit. I assume he use the generic ACPI video driver (modprobe video) and not a special driver e.g. from/for futjisu. 1.) I can't see where you check if this machine is a) a FujitsuSiemens or/and b) this special machine in your patch. If this patch go in, HAL offer set brightness for all machines with loaded video module and which have this path in /proc/acpi. But this happens also on several (in fact many) other machines - on this point we are at: </pre> </blockquote> Okay. This is what I meant in the first posting. If it is impossible to auto-detect brightness capability, there should be a possibility to register this capability manually into a running hald. But there seems to be no provision for that. <blockquote cite="mid200604181258.17338.danny.kukawka@web.de" type="cite"> <pre wrap="">2.) I see no check if the device really support set brightness. You need to check if there are values returned which make sense (e.g. not <not supported> ) 3.) Also if the device not return <not supported>: this mean not that set brightness is supported by this machine. This can also differ in several cases from bios version to bios version. And on many (maybe the most) this does not work. 4.) Also if a device support set brightness via this path the number of brightness levels can differ from '8'. You see it make no sense to commit this in the CVS.</pre> </blockquote> Again, these checks are nice if we expect one monolithic piece of code to detect every possible mainboard/bios/acpi combination and give that piece of code ultimate power over whether or not a machine has brightness control. I would prefer a combined approach where the auto-detector code can supply (rather: initialize) the capabilities to its best knowledge. This initial (conservative and safe) setup could then be complemented by machine-specific code which adds capabilities and sets them up properly. I can see these ideas in the HAL whitepaper on freedesktop.org. But has it been implemented yet? If so, how can I plug in external "capability generators"? For example, the administrator of an exotic machine (like mine!) could then supply something which does modprobe and other initialization, writes hal entries and implements the necessary calls (i.e., the code which Richard kindly patched into hald and associated scripts). This would encapsulate the hardware side as neatly as HAL encapsulates the client side. It would also make recompiling unnecessary for the "exotic" people. A static approach can never embrace all hardware setups because so many hardware implementations are simply broken and need nasty fixes to work at all. Ideally, we would instead end up with a "library" of independent, packageable fixes for hardware which administrators can safely ignore or activate at their discretion. Forgive me if I'm being too verbose ;-) - Ján </body> </html>