Subject: Re: radeonfb, VTs and trackpad
To: Peter Bex <Peter.Bex@xs4all.nl>
From: Michael <macallan1888@gmail.com>
List: port-macppc
Date: 01/15/2007 16:14:44
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Jan 15, 2007, at 15:48, Peter Bex wrote:

> On Sun, Jan 14, 2007 at 07:00:09PM -0500, Michael wrote:
>>> I've tried to add a few VTs, which works according to dmesg, but
>>> I can't switch to them.  Whenever I press Ctrl+Apple+F1..F4, the
>>> machine simply resets itself.  How does this work?
>>
>> The function keys that control brightness, volume etc. in MacOS may 
>> act
>> as separate ADB device - you can force them to send normal keyboard
>> events by adding option FORCE_FUNCTION_KEYS
>> to your kernel config.
>
> That did the trick.  Could this be made the default in GENERIC?
> I think it would make it a little more userfriendly since people 
> wouldn't
> get these surprising sudden crashes.

Yeah, given the fact that brightness control only works on a handful 
older PowerBooks anyway that makes sense.

>> Please grab the latest src/sys/arch/macppc/dev/ams.c and amsvar.h from
>> - -current.
>> When the driver detects a trackpad it should set up a sysctl node like
>> machdep.ams0.tapping which defaults to 1 - set it to 0 and tapping the
>> pad shouldn't cause button events.
>> Works on my PowerBook, if it works for you as well I'll have it pulled
>> into 4.0
>
> Thanks a lot!  This works perfect.

Ok, I'll request pullup then.

> From your other e-mail:
>
>> To switch VTs use Command-F[1-5]. If the function keys don't send
>> proper scancodes but appear as abtn device ( to control volume,
>> brightness etc. ) use Fn-Command-F[1-5]
>
> That works for me on console.  When I am in X, I can't switch back
> to another VT.  Could this be related to the fact that
> Ctrl+Command+Backspace doesn't kill the X server?

Ctrl-Alt-Backspace kills the Xserver.
We don't support VT switching on non-PC platforms yet, mainly because 
much of it relies on the console using VGA text mode which never 
happens on a mac.

>> This is a bug in the PMU code which tries to control display 
>> brightness
>> on machines that can't do this via PMU ( like all Powerbooks that
>> shipped with something newer than a G3, likely all iBooks ) - the PMU
>> itself responds to invalid commands by powering down.
>
> That's just stupid.  Why does Apple do this?  To make it hard for 
> people
> to use a non-Apple OS on their hardware?

I have no idea, really. In most cases the PMU node in the OF device 
tree has childs indicating what kind of functionality is present ( like 
ADB etc. ) but I didn't find such a thing for backlight control. My 
PB3400c has no 'backlight' node but the PMU supports it, others have it 
elsewhere and don't - like the G4 iBooks. We might have to make up a 
table mapping model names to PMU features.
Even weirder is that PMUs used in newer desktop macs don't seem to 
power down on illegal commands either.

>> Hmm, as far as X is concerned there is no difference between radeonfb
>> and ofb - it shuts up the console, then mmap()s registers and
>> framebuffer. Could you please mail me the XFree86.0.log for both 
>> cases?
>
> Never mind, it appears something else caused it.  I never thought about
> comparing ofb/radeonfb, I just noticed it was slower than before.
> There's no noticable speed difference between ofb/radeonfb.

Good, I'd be extremely surprised if there was one ;)

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBRavuxMpnzkX8Yg2nAQKiMwf6Axdr+yhTJS6pSLP3el/iNgF8gsYJE1of
MraNqHdOgJdSUHsn5fSJJB7mJrOJqkCxWeVd4Me1EnuA4uDxjdqK7+GgEnWVgMY5
+A1PsATHb2NlY88d2FjM5IvQsOp+hz0kAgd7aHhxlbhSR8wuVqfqfOlk1ploCwcC
eJgS0HKCprRzv4Q4irCjJ/n1NFeDdWOVtHdyPGGZvM60JWxHWOikO9OoTTlR3fm/
vkSvB93tB4XMlk3bxNZQlwAGRIHojo3A4N12FhYcvBf7r/tclQYdGi/w+p0ykiri
aRkAapbkPBARoLtn/VvV/fmeLJnu2bEGJD9B+hHv745bOyaFMfAUtw==
=wX8h
-----END PGP SIGNATURE-----