This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 237767 - No brightness control for g-p-m for Latitude D420
No brightness control for g-p-m for Latitude D420
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
:
: 249203 (view as bug list)
Depends On: 239225 240781 248257
Blocks: 237760
  Show dependency treegraph
 
Reported: 2007-04-25 06:35 EDT by Bastien Nocera
Modified: 2013-03-05 22:50 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-27 13:12:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
lshal.txt (120.36 KB, text/plain)
2007-04-25 06:35 EDT, Bastien Nocera
no flags Details

  None (edit)
Description Bastien Nocera 2007-04-25 06:35:25 EDT
hal-0.5.9-5.fc7

There's no brightness control for the Latitude D420 in gnome-power-manager.

lshal output attached
Comment 1 Bastien Nocera 2007-04-25 06:35:25 EDT
Created attachment 153410 [details]
lshal.txt
Comment 2 David Zeuthen 2007-04-25 11:49:22 EDT
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.
Comment 3 Bastien Nocera 2007-04-25 12:30:14 EDT
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)
Comment 4 David Zeuthen 2007-04-25 12:34:09 EDT
(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.


Comment 5 Bastien Nocera 2007-04-25 12:45:21 EDT
(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.
Comment 6 Bill Nottingham 2007-04-25 12:54:28 EDT
dcdbas has nothing to make it automatically loaded. Should add some sort of DMI
matching in the kernel.
Comment 7 David Zeuthen 2007-04-25 13:46:38 EDT
(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.
Comment 8 Bill Nottingham 2007-04-25 13:48:51 EDT
> 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.
Comment 9 David Zeuthen 2007-04-25 13:53:58 EDT
(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? 
Comment 10 Bill Nottingham 2007-04-25 14:12:23 EDT
(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.
Comment 11 David Zeuthen 2007-04-25 14:29:28 EDT
Also see

 http://marc.info/?l=linux-hotplug-devel&m=117088435326752&w=2

Historically we've just been punting this...
Comment 12 Bill Nottingham 2007-04-25 14:39:43 EDT
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.
Comment 13 Harald Hoyer 2007-04-26 05:16:01 EDT
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.
Comment 14 Lennart Poettering 2007-05-04 20:25:40 EDT
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.
Comment 15 David Zeuthen 2007-05-05 16:36:45 EDT
(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?
Comment 16 Bastien Nocera 2007-05-06 09:30:02 EDT
I opened bug 239225 to track the rebuild of HAL with dell backlight support.
Comment 17 Lennart Poettering 2007-05-09 10:28:15 EDT
(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.
Comment 18 Bastien Nocera 2007-05-22 08:40:45 EDT
Add a dep on the addition of the dmi-id patch.
Comment 19 David Zeuthen 2007-07-23 10:19:09 EDT
*** Bug 249203 has been marked as a duplicate of this bug. ***
Comment 20 Rui Matos 2007-10-29 17:54:36 EDT
Please see Bug 248257. Matt Domsch fixed the Dell module and it is going upstream.
Comment 21 Bastien Nocera 2007-10-29 18:11:50 EDT
Adding the depends, as this bug is model specific (even though it probably
shouldn't be).
Comment 22 Bastien Nocera 2008-03-27 13:12:17 EDT
This seems to be working fine with a stock rawhide now.

Note You need to log in before you can comment on or make changes to this bug.