Re: Naive question on brightness keys

[Hans-Werner Hilse <hilse@xxxxxx>]

Hi,

On Wed, 29 Aug 2007 13:44:03 -0400 (EDT)
Radu-Cristian FOTESCU <beranger5ca@yahoo.ca> wrote:

> --- Hans-Werner Hilse <hilse@web.de> wrote:
> > Because those aren't handled by any software. Nothing is eaten. 
> > But nothing is provided either.
> 
> I am sorry to be that stubborn, but "nothing is provided either" when at the
> boot loader's prompt, yet the key are working then!

Of course true from the end user's perspective. From a programmer's
POV, in that case you *have* kind of a OS up and running then: It's the
BIOS. In the very moment ACPI fires up, your OS is supposed to provide
all those means itself. The basic point is: You have a different
environment in both cases, but I wouldn't call the initial
BIOS-provided one "nothing provided".

> But (wrt to the graphical table), note that *all* the Linux distros I tested,
> and also PC-BSD (I am not sure on NetBSD) were using ACPI too, and they were
> also (Linux) able to suspend to disk! In short, not using APM, yet working
> stuff.

Yes, provided by software and specialized daemons. Linux has hardware
support for a lot of those special interfaces that have to be used for
controlling such things like backlight. Other OSs might also bring such
support. Usually, these kernel interfaces have to be controlled from
userland. Daemons sitting there and reacting on keystrokes (which
themselves might only be readable by specialized interfaces) issue
commands to the kernel to take appropriate actions. Having APM enabled
often keeps some of the BIOS functions alive and kicking. There's no
guarantee, though. I guess in case of the other systems some bring the
proper drivers and some don't (e.g. Gentoo: You're the one to configure
the kernel!). Some bring an initial desktop environment that has
configured support for those things (e.g. have khotkeys configured and
running), some don't. Some might even skip ACPI and bring rudiments of
the BIOS provided functionality. Most of the systems are configurable
w/ regard to all this. My basic point is: There's actually some effort
needed to support this explicitly. It's not about some efforts that
lead to have those things dysfunctional.

> --- Joerg Sonnenberger <joerg@britannica.bec.de> wrote:
> > Your BIOS most likely decides to disable the automatic
> > handling in the Embedded Controller if the OS currently running
> > wants to use ACPI. It most likely also provides a vendor specific
> > control via the ACPI EC API, but no support for that is present
> > in DragonFly. The joys of ACPI. 
> 
> Uh, some of the Linux distros I've tested are not binding any special key to
> anything (they only treated the suspend key at most), so I thought they're
> somehow "ignoring" them, therefore it's highly unlikely that they're
> providing some specific ACPI support _precisely_ for the brigtness keys!
> Sounds illogical to me.

It's pretty easy: Most systems have a power knob, so configuring the
ACPI event listener for power button events is pretty easy and can be
commonly used. Configuring it is more or less the same for any system.
Those special laptop controls are way more varying among different
systems and providing good defaults is somewhat harder. Having suspend
support at all is a mostly different matter.

> > There's software for setting brightness (e.g. ddccontrol, I'm not sure
> > what software would fit your model). And there's software for binding
> > stuff to keys. Combined, following the basic UNIX principles, you can
> > get your keyboard-driven brightness control. Some of this software can
> > make the needed calls itself, using known interfaces. There's e.g.
> > khotkeys, hotkeys, ...
> 
> No, I don't care about binding keys to software. What I want is *not* to use
> software like ddccontrol (never heard of, sorry), but to let those keycodes
> pass "as before", so that the real-mode-software-hook-bound-to-hardware (if
> still there) continues to work. 

They didn't "pass", they were handled by another entity, your system's
BIOS. If you boot w/o ACPI, part of it will stay in charge, I guess. It
might work then. But note that even on Windows, usually userland
software handles keystrokes and take appropriate measures. On the other
OSs, similar means have to get explicitly implemented. It's not a
matter of not intercepting (actively prohibiting), it's about no
implementation (passively prohibiting). So there's at least not a
malicious thought behind it. From my experience, in the free software
environment, that usually indicates lack of motivation to support it
(more than actually already supported).

> I still fail to understand anything, as long as there are those differences I
> was initially telling about in that table. I don't know where to start
> digging, and I hope(d) some system/kernel devs might have good pointers...

Hm, I was searching but sorry, I don't have precise pointers at the
moment. I think the key is understanding the different states upon
boot-up and under which conditions a current OS's kernel operates.

Just for getting an idea how complex this all is, this is a description
for the Linux kernel's support of some toshiba-specific hotkeys -- and
that is only for having *input* interfaces (I don't suggest reading it
thoroughly):
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/thinkpad-acpi.txt;hb=HEAD

-hwh