hal-0.5.9-5.fc7 There's no brightness control for the Latitude D420 in gnome-power-manager. lshal output attached
Created attachment 153410 [details] lshal.txt
Please test if this works if you rebuild the HAL SRPM with --with-dell-backlight - notably you need libsmbios-devel, libsmbios for this. Just waiting for the damn merge to happen so we can make this change in Fedora. Thanks.
It works, kind of: - the dcdbas module isn't loaded automatically - the brightness is still handled in hardware, and that causes major confusion (especially when enabling the automatic light sensor brightness, as in bug 237768)
(In reply to comment #3) > It works, kind of: > - the dcdbas module isn't loaded automatically This should be loaded by the initscripts. Bill? > - the brightness is still handled in hardware, and that causes major confusion > (especially when enabling the automatic light sensor brightness, as in bug 237768) I think that's a gnome-power-manager bug.
(In reply to comment #4) > (In reply to comment #3) > > It works, kind of: > > - the dcdbas module isn't loaded automatically > > This should be loaded by the initscripts. Bill? Or maybe udev > > - the brightness is still handled in hardware, and that causes major confusion > > (especially when enabling the automatic light sensor brightness, as in bug 237768) > > I think that's a gnome-power-manager bug. Do you have a reference? The hal-info data claims that the brightness is not handled in hardware... I added this bug as depending on the merge.
dcdbas has nothing to make it automatically loaded. Should add some sort of DMI matching in the kernel.
(In reply to comment #6) > dcdbas has nothing to make it automatically loaded. Can we just add it to the hack we currently do, e.g. > # Initialize ACPI bits > if [ -d /proc/acpi ]; then > for module in /lib/modules/$unamer/kernel/drivers/acpi/* ; do > module=${module##*/} > module=${module%.ko} > modprobe $module >/dev/null 2>&1 > done > fi since this tries to load a bunch of drivers anyway. It's just one more driver. Please? > Should add some sort of DMI > matching in the kernel. Yes, all hardware drivers need to export a modalias so we can automatically load stuff via standard mechanisms (e.g. udev)... but am not holding my breath for that.
> Can we just add it to the hack we currently do, e.g. > > > # Initialize ACPI bits > > if [ -d /proc/acpi ]; then > > for module in /lib/modules/$unamer/kernel/drivers/acpi/* ; do > > module=${module##*/} > > module=${module%.ko} > > modprobe $module >/dev/null 2>&1 > > done > > fi > > since this tries to load a bunch of drivers anyway. It's just one more driver. > Please? I already get enough complaints about that. Must beat kernel into sanity.
(In reply to comment #8) > I already get enough complaints about that. Must beat kernel into sanity. Sigh. So you don't want Dell laptop brightness to work for people. Can you at least then delete all that crap in /etc/rc.sysinit so there's an incentive to fix the root problems please?
(In reply to comment #9) > (In reply to comment #8) > > I already get enough complaints about that. Must beat kernel into sanity. > > Sigh. So you don't want Dell laptop brightness to work for people. By that logic, we should also automatically load on boot in rc.sysinit: - toshiba SMM driver - sonypi - asus-laptop - sony-laptop - msi-laptop and probably some more that I'm forgetting. We need to draw the line somewhere. If we want these automatically available, either a) shove them in /etc/sysconfig/modules/udev-stw.modules (a better place for this hack) b) build them into the kernel statically c) fix the modules CC'ing kernel and udev maintainers.
Also see http://marc.info/?l=linux-hotplug-devel&m=117088435326752&w=2 Historically we've just been punting this...
Yes, but that suggests maintaining static mappings of modules <-> DMI/smbios info in userspace. If we do that, why not do it for PCI, USB, etc? The kernel can't be *THAT* hard to fix. Hm, where's that source RPM.
Just make a small helper application, which reads the smbios and create a list of modules to load and store it in /etc/sysconfig/modules/smbios.modules. This helper application could be run from either a udev rule, or in rc.sysinit. Best solution would be, to handle the stuff the standard way like pci and usb with modaliases.
I prepared a kernel patch which exports DMI info to userspace including a modalias string for autoloading of all those special laptop support modules. It's right now available here: http://0pointer.de/public/dmi-id.patch I will post that for kernel inclusion shortly.
(In reply to comment #14) > I prepared a kernel patch which exports DMI info to userspace including a > modalias string for autoloading of all those special laptop support modules. > > It's right now available here: > > http://0pointer.de/public/dmi-id.patch > > I will post that for kernel inclusion shortly. This is definitely the right approach, very nice work Lennart. Are you planning on patching all the other kernel modules (such as ibm-acpi, dcdbas etc.) too? Hmm, it's probably to late for Fedora 7 to include this... davej?
I opened bug 239225 to track the rebuild of HAL with dell backlight support.
(In reply to comment #15) > (In reply to comment #14) > > I prepared a kernel patch which exports DMI info to userspace including a > > modalias string for autoloading of all those special laptop support modules. > > > > It's right now available here: > > > > http://0pointer.de/public/dmi-id.patch > > > > I will post that for kernel inclusion shortly. > > This is definitely the right approach, very nice work Lennart. Are you planning > on patching all the other kernel modules (such as ibm-acpi, dcdbas etc.) too? Nope. That is a job for the respective module maintainers. For thinkpad-acpi you're lucky, he already contacted me to ping him as soon as he can add those lines. All modules besides msi-laptop and thinkpad-acpi need someone to check this out. I will ping everyone who maintains a module where having these lines could be useful as soon as it gets commited upstream. BTW: Updated patch is here: http://lkml.org/lkml/2007/5/8/428 Now all we need is CPUID-based module autoloading (for k8temp and the CPU scaling modules) and ACPI-DSDT-based module autoloading (for all those ACPI modules) and we should be able to load all driver modules without manual configuration.
Add a dep on the addition of the dmi-id patch.
*** Bug 249203 has been marked as a duplicate of this bug. ***
Please see Bug 248257. Matt Domsch fixed the Dell module and it is going upstream.
Adding the depends, as this bug is model specific (even though it probably shouldn't be).
This seems to be working fine with a stock rawhide now.