Re: Naive question on brightness keys

[Radu-Cristian FOTESCU <beranger5ca@xxxxxxxx>]

--- 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!

> No, this is a misconception. When something works in real mode it is
> not meaning that it is a purely hardware-based functionality. After
> all, most complex functionality is *not* purely hardware-based. In this
> case, the BIOS probably provides *software* hooks which only work in
> real mode. In most cases, the software hooks are still accessible in
> APM mode (as opposed to ACPI). So running without ACPI and using APM
> would be a first step.

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.

--- 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 might also be a slightly different initialisation, but that 
> is very hard to tell in  an abstract mail like this.

Ummm... because the issue is 'abstract' too! I simply don't know
who-when-where is handling these keys when they work "by themselves", so I
don't know how can they not work when an OS is loaded!

> 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. 

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...

> @Radu-Christian: Sorry if I sounded too pissed, please don't take 
> it personal. And please ask if the answer left open some questions.

No problem. You were not aggressive, none of you. I have been made idiot in
the past by some FreeBSD devs, so I know what rudeness means :-)

Cheers,
R-C



      ____________________________________________________ 
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at
http://ca.toolbar.yahoo.com.