On Mon, 2009-11-30 at 04:09 +0800, Rafał Miłecki wrote: > W dniu 28 listopada 2009 01:30 użytkownik Rafał Miłecki > <zajec5@xxxxxxxxx> napisał: > > As discussed in http://marc.info/?t=124947671300008&r=1&w=2 we need to > > redesign our backlight device class. > > I was trying to make it work this way: > 1. Everytime register request comes, look for backlight_display with given name. > 1. A. If needed, create new backlight_display > 2. Add new device to devices list of backlight_display > 3. Find best device on devices list of backlight_display > 4. Register if under /sys/class/backlight/name_of_display > > This didn't work because of registering only the best device. Look at > this code in drivers/acpi/video.c: > > device->backlight = backlight_device_register(name, > NULL, device, &acpi_backlight_ops); > (...) > result = sysfs_create_link(&device->backlight->dev.kobj, > &device->dev->dev.kobj, "device"); > IMO, we should create one device for one display. For example, device /sys/class/backlight/panel0 is created the first time a backlight_ops for this display is registered. And create the symbol link from the backlight class device to "physical device" (device that invokes backlight_device_register) in the backlight class device driver, if we really need it. Remove and recreate a link pointing to the new physical device when the backlight mode is changed. thanks, rui > It expects device to be registered (have dev.kobj) after calling > backlight_device_register. > > So in summary we just can not do lazy registration. Every device > passed to backlight_device_register has to be registered in that > function or never. > > So I think we have to register every device and just keep symlink > /sys/class/backlight/display_name pointing best device. We could > register devices in > 1) /sys/class/backlight/.devicename (hidden) > 2) some /sys/class/internal-usage/devicename > > Do you agree on this? > -- 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
