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