Backlight control on Lombard PB

Hi all,

I saw a couple of posts from people who seem to have the recent kernels
(2.2.17pre1[3-5]-ben1) running on a 1999 Powerbook.
Unfortunately, I have still the same problems with the backlight control
that first appeared with 2.2.17pre10-ben1, i.e.

 1. {Fn-,}F[12] don't adjust brightness
 2. After wakeup from sleep, the backlight remains dark

At least it does not seem to crash anymore when I try to repeatedly wake
it up, but the only thing I can do at that point is to reboot.
Has anyone one of these kernels working on a Lombard and is actually able
to use sleep (or adjust monitor brightness)?

Besides, the keycodes 10 and 50 (less/greater and asciicircum/degree) on
the german keyboard seem to have been swapped in pre13-pre15.

Thanks for any feedback,
							Derek


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

I saw a couple of posts from people who seem to have the recent kernels
(2.2.17pre1[3-5]-ben1) running on a 1999 Powerbook.
Unfortunately, I have still the same problems with the backlight control
that first appeared with 2.2.17pre10-ben1, i.e.

 1. {Fn-,}F[12] don't adjust brightness
 2. After wakeup from sleep, the backlight remains dark

Should be fixed in BenH's current tree, he said he was going to do it this
past weekend. The pmu backlight controller didn't get registered on the
Lombard (and possibly Wallstreet) because the backlight-control property
is missing on these machines.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, 9 Aug 2000, Michael Schmitz wrote:

quoted

I saw a couple of posts from people who seem to have the recent kernels
(2.2.17pre1[3-5]-ben1) running on a 1999 Powerbook.
Unfortunately, I have still the same problems with the backlight control
that first appeared with 2.2.17pre10-ben1, i.e.

 1. {Fn-,}F[12] don't adjust brightness
 2. After wakeup from sleep, the backlight remains dark

Should be fixed in BenH's current tree, he said he was going to do it this
past weekend. The pmu backlight controller didn't get registered on the
Lombard (and possibly Wallstreet) because the backlight-control property
is missing on these machines.

So we were just lucky that it used to work before?

It should be in the linux-pmac-benh branch then, yeah? I rsynced again
from linuxcare.com.au yesterday (or rather 2:00 UT this morning), and the
problem still remains. Is there anything else to do, upgrade to a newer
BootX perhaps, or whatever?

Thanks,
							Derek


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

quoted

Should be fixed in BenH's current tree, he said he was going to do it this
past weekend. The pmu backlight controller didn't get registered on the
Lombard (and possibly Wallstreet) because the backlight-control property
is missing on these machines.

So we were just lucky that it used to work before?

Nope, it broke because BenH added code to have either the PMU driver or
the atyfb driver register a backlight control callback (depending on where
the power control logic actually resides).

It should be in the linux-pmac-benh branch then, yeah? I rsynced again
from linuxcare.com.au yesterday (or rather 2:00 UT this morning), and the
problem still remains. Is there anything else to do, upgrade to a newer
BootX perhaps, or whatever?

Compile you own kernel, and add a || machine_is_compatible("PowerBook1,1")
right after the || machine_is_compatible("AAPL,PowerBook1999") in
arch/ppc/kernel/pmac_support.c:register_backlight_controller(). That fixed
it for me. I'll resync and see what BenH did there later today.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, 9 Aug 2000, Michael Schmitz wrote:

quoted

It should be in the linux-pmac-benh branch then, yeah? I rsynced again
from linuxcare.com.au yesterday (or rather 2:00 UT this morning), and the
problem still remains. Is there anything else to do, upgrade to a newer
BootX perhaps, or whatever?

Compile you own kernel, and add a || machine_is_compatible("PowerBook1,1")
right after the || machine_is_compatible("AAPL,PowerBook1999") in
arch/ppc/kernel/pmac_support.c:register_backlight_controller(). That fixed
it for me. I'll resync and see what BenH did there later today.

Hmm, there is a  || machine_is_compatible("AAPL,PowerBook1,1")
in it. I'll check the file I rsynced at home later.

							Derek


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Hmm, there is a  || machine_is_compatible("AAPL,PowerBook1,1")
in it. I'll check the file I rsynced at home later.

That won't work, I tried that :-)

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

quoted

Hmm, there is a  || machine_is_compatible("AAPL,PowerBook1,1")
in it. I'll check the file I rsynced at home later.

That won't work, I tried that :-)

My fault, I made a typo there... remove the "AAPL," part.

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Wed, 9 Aug 2000, Michael Schmitz wrote:

Should be fixed in BenH's current tree, he said he was going to do it this
past weekend. The pmu backlight controller didn't get registered on the
Lombard (and possibly Wallstreet) because the backlight-control property
is missing on these machines.

Well, the backlight control surely doesn't work on Pismos... I just hate
it when I have to boot over to MacOS to switch up the backlight level
(I usually keep it low because it eats so much battery...)
Now, I realize that the PMU on Pismos is somewhat different, but supposedly
there is a way (in MacOS) to try to poke what kind of values are being
written to the registers when you change the backlight in MacOS (fn-F1/F2)

actually, to be able to turn off the backlight is perharps the most
important single power-saving feature. unfortunately, I myself don't have
any reverse-engineering experience on MacOS (this is my first mac ever...)


-topi


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Well, the backlight control surely doesn't work on Pismos... I just hate
it when I have to boot over to MacOS to switch up the backlight level
(I usually keep it low because it eats so much battery...)
Now, I realize that the PMU on Pismos is somewhat different, but supposedly
there is a way (in MacOS) to try to poke what kind of values are being
written to the registers when you change the backlight in MacOS (fn-F1/F2)

actually, to be able to turn off the backlight is perharps the most
important single power-saving feature. unfortunately, I myself don't have
any reverse-engineering experience on MacOS (this is my first mac ever...)

Backlight control should work on Pismo with my latest kernels. It's not
driven by te PMU on those machines, it's directly controlled by the ATI
chip. I finally found some time to push the Lombard fix yesterday.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

quoted

Should be fixed in BenH's current tree, he said he was going to do it this
past weekend. The pmu backlight controller didn't get registered on the
Lombard (and possibly Wallstreet) because the backlight-control property
is missing on these machines.

Well, the backlight control surely doesn't work on Pismos... I just hate

I was speaking about Lombard and related machines. On the Pismo, the
backlight control is in the display driver IIRC.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

On Thu, 10 Aug 2000, Michael Schmitz wrote:

quoted

quoted

Should be fixed in BenH's current tree, he said he was going to do it this
past weekend. The pmu backlight controller didn't get registered on the
Lombard (and possibly Wallstreet) because the backlight-control property
is missing on these machines.

Well, the backlight control surely doesn't work on Pismos... I just hate

I was speaking about Lombard and related machines. On the Pismo, the
backlight control is in the display driver IIRC.

And with the fix to pmac_setup.c it is indeed working on the Lombard,
thanks to everyone!

BenH did some research on the settings of the function keys, but that's
probably not exactly the problem with the Pismo...(?):

I've done some hacking on MacOS today and found that the Fn key behaviour
can apparently be triggered by setting an ADB register of the keyboard.

If you write 0xc6 0x01 to register 1 of the keyboard, the Fx keys will be
real function keys by default and Fn will trigger the control buttons.
Write 0xc6 00 to revert the behaviour to default.

So a userland tool can be easily hacked using the trackpad tool source as
an example, you have to find the keyboard instead of the trackpad (device
with default and current address 2 should always work on PowerBook and
iBook ADB) and then do the register write of a 2 bytes message
(0xc6 0x01). I can't try this now, but if someone wants to look at it...

I tried to make some sense of this, but unfortunately I wasn't able to tell
from trackpad.c where I'd try to find the keyboard and where exactly the
register write is done (one of the 'send(buf, n)', probably? Then
  buf[0] = 0xc6;
  buf[1] = 0x01;
  send(buf, 2);
would be the thing to do?). No experience with this, but maybe I'll get it
yet sorted out...
Would this work for setting the register:

void set_fnkey(int id, int mode)
{
	unsigned char buf[16];

	set_program_mode(id, 1);

#ifdef DEBUG
	printf("setting mode: %d\n", mode);
#endif

	buf[0] = 0xc6;
	buf[1] = (mode < 1) ? 00 : 0x01;
	send(buf, 2);
	listen(buf);

	set_program_mode(id, 0);

}

if called with (2, 1) to set the F keys to function keys, and with (2, 0)
to set it back to default? I'm afraid I've not fully grasped what
set_program_mode(id, n) does.


Cheers,
							Derek


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/