Menu
▾
▴
mactel-linux-devel — mactel-linux Development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
(4) |
Mar
(135) |
Apr
(130) |
May
(82) |
Jun
(101) |
Jul
(75) |
Aug
(37) |
Sep
(28) |
Oct
(45) |
Nov
(114) |
Dec
(27) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(22) |
Feb
(60) |
Mar
(81) |
Apr
(120) |
May
(29) |
Jun
(50) |
Jul
(67) |
Aug
(41) |
Sep
(36) |
Oct
(4) |
Nov
(4) |
Dec
|
| 2008 |
Jan
(5) |
Feb
(17) |
Mar
(5) |
Apr
(6) |
May
(5) |
Jun
(9) |
Jul
(5) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bastien D. <es...@gm...> - 2011-06-03 08:25:36
|
Hi, I already settled the problem on another mailing list : http://lists.alioth.debian.org/pipermail/pommed-devel/2011-May/000077.html I got interesting insights from James Cameron but I got stuck when trying to obtain the right address from Mac OS X. I was inspecting the following program: http://mattdanger.net/2008/12/adjust-mac-os-x-display-brightness-from-the-terminal/ But unfortunately I can't access the source of the function which seems to do the dirty work because the file iomig64.c is missing in http://www.opensource.apple.com/ Right now I'm thinking on trying a brute force approach. Since the backlight value seems to be kept from Mac OS X to Linux, how about: -- Setting the backlight value to minimum on Mac OS X, rebooting into Linux and dumping the content of the interesting parts of memory into file A, reboot into Mac OS X, set the brightness to the maximum, reboot into Linux, dump the memory into file B. -- Extracting the address(es) where the value in file A is 0 and the value in file B is 256. Does it seem like a viable approach ? I thought that x1600_backlight.c, which is included in pommed sources, might be a good starting point ? Cheers, -- Bastien |
|
From: Nobuhiro I. <iwa...@ni...> - 2010-08-20 07:18:50
|
Hi,
2010/8/20 David Brown <ma...@da...>:
> On Fri, Aug 20, 2010 at 09:05:52AM +0900, Nobuhiro Iwamatsu wrote:
>
>> MacbookPro 6,2 and 7,1 does not work curret linux kernel and linus/HEAD.
>> Because these bluetooth device class was FF.
>>
>> I want to fix this problem and wrote simple patch.
>> When I send patch, the result of usb-devices is necessary.
>> But I have only MacbookPro 7,1.
>> Coud you send it if there is a person using Macbookpro6,2?
>
> Below is the output of usb-devices on my Macbookpro6,2:
Thank you very much!
I want to bring these information together in wiki.
However, I cannot create account in wiki .....
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
|
|
From: Nobuhiro I. <iwa...@ni...> - 2010-08-20 07:15:56
|
Hi,
2010/8/20 David Brown <da...@da...>:
> On Fri, Aug 20, 2010 at 08:20:41AM +0200, Sven Anders wrote:
>
>> I don't have an MacBookPro 6,2, so I cannot help you here, but
>> what do you mean with "the result of usb-devices" ?
>
> 'usb-devices' is a program in the usbutils package. It outputs a list
> of the USB devices in the system, along with details about them. It
> is the information that used to be part of /proc/bus/usb/devices.
>
> I have a 6,2 here, and I'll see if I can figure out how to get this
> information.
>
Thank you !
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
|
|
From: David B. <ma...@da...> - 2010-08-20 07:09:33
|
On Fri, Aug 20, 2010 at 09:05:52AM +0900, Nobuhiro Iwamatsu wrote: >MacbookPro 6,2 and 7,1 does not work curret linux kernel and linus/HEAD. >Because these bluetooth device class was FF. > >I want to fix this problem and wrote simple patch. >When I send patch, the result of usb-devices is necessary. >But I have only MacbookPro 7,1. >Coud you send it if there is a person using Macbookpro6,2? Below is the output of usb-devices on my Macbookpro6,2: T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 6 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev=02.06 S: Manufacturer=Linux 2.6.33-ARCH ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=0000:00:1a.7 C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 4 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1 P: Vendor=0424 ProdID=2514 Rev=00.03 C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=2mA I: If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 3 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0a5c ProdID=4500 Rev=01.00 S: Manufacturer=Apple Inc. S: Product=BRCM2070 Hub C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=94mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub T: Bus=01 Lev=03 Prnt=03 Port=00 Cnt=01 Dev#= 6 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=05ac ProdID=820a Rev=01.00 C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid T: Bus=01 Lev=03 Prnt=03 Port=01 Cnt=02 Dev#= 7 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=05ac ProdID=820b Rev=01.00 C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid T: Bus=01 Lev=03 Prnt=03 Port=02 Cnt=03 Dev#= 8 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=05ac ProdID=8218 Rev=00.22 S: Manufacturer=Apple Inc. S: Product=Bluetooth USB Host Controller C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=(none) I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) T: Bus=01 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=05ac ProdID=0236 Rev=00.90 S: Manufacturer=Apple Inc. S: Product=Apple Internal Keyboard / Trackpad C: #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=40mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid I: If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid I: If#= 2 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=bcm5974 T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=03 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=05ac ProdID=8403 Rev=98.33 S: Manufacturer=Apple S: Product=Card Reader S: SerialNumber=000000009833 C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 8 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev=02.06 S: Manufacturer=Linux 2.6.33-ARCH ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=0000:00:1d.7 C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 3 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=02 MxPS=64 #Cfgs= 1 P: Vendor=0424 ProdID=2514 Rev=00.03 C: #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=2mA I: If#= 0 Alt= 1 #EPs= 1 Cls=09(hub ) Sub=00 Prot=02 Driver=hub T: Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=05ac ProdID=8507 Rev=04.35 S: Manufacturer=Apple Inc. S: Product=Built-in iSight S: SerialNumber=8JA4B2Q3TDCLKL00 C: #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 1 Cls=0e(video) Sub=01 Prot=00 Driver=uvcvideo I: If#= 1 Alt= 0 #EPs= 0 Cls=0e(video) Sub=02 Prot=00 Driver=uvcvideo I: If#= 2 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) T: Bus=02 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 4 Spd=1.5 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=05ac ProdID=8242 Rev=00.16 S: Manufacturer=Apple Computer, Inc. S: Product=IR Receiver C: #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid |
|
From: Nobuhiro I. <iwa...@ni...> - 2010-08-20 07:07:58
|
Hi,
2010/8/20 Sven Anders <an...@an...>:
> Nobuhiro Iwamatsu schrieb:
>> Hi, all.
>>
>> MacbookPro 6,2 and 7,1 does not work curret linux kernel and linus/HEAD.
>> Because these bluetooth device class was FF.
>>
>> I want to fix this problem and wrote simple patch.
>> When I send patch, the result of usb-devices is necessary.
>> But I have only MacbookPro 7,1.
>> Coud you send it if there is a person using Macbookpro6,2?
>
> I don't have an MacBookPro 6,2, so I cannot help you here, but
> what do you mean with "the result of usb-devices" ?
>
> Please be more specific or send the command we should execute...
Oh, sorry.
usb-devices is a program being provide with usbutils.
USB information on the executed machine is output.
Or we can get the data that looks like by executing the following.
cat /proc/bus/usb/devices"
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
|
|
From: Sven A. <an...@an...> - 2010-08-20 06:37:41
|
Nobuhiro Iwamatsu schrieb:
> Hi, all.
>
> MacbookPro 6,2 and 7,1 does not work curret linux kernel and linus/HEAD.
> Because these bluetooth device class was FF.
>
> I want to fix this problem and wrote simple patch.
> When I send patch, the result of usb-devices is necessary.
> But I have only MacbookPro 7,1.
> Coud you send it if there is a person using Macbookpro6,2?
I don't have an MacBookPro 6,2, so I cannot help you here, but
what do you mean with "the result of usb-devices" ?
Please be more specific or send the command we should execute...
Regards
Sven Anders
--
Sven Anders <an...@an...> () UTF-8 Ribbon Campaign
/\ Support plain text e-mail
ANDURAS intranet security AG
Messestrasse 3 - 94036 Passau - Germany
Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin
|
|
From: Nobuhiro I. <iwa...@ni...> - 2010-08-20 00:28:10
|
Hi, all.
MacbookPro 6,2 and 7,1 does not work curret linux kernel and linus/HEAD.
Because these bluetooth device class was FF.
I want to fix this problem and wrote simple patch.
When I send patch, the result of usb-devices is necessary.
But I have only MacbookPro 7,1.
Coud you send it if there is a person using Macbookpro6,2?
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
|
|
From: Rolando M. <rol...@gm...> - 2008-08-11 17:10:47
|
Hi, I having a problem with /sys/devices/platform/applesmc.768/light Doing a cat to the file results in a "cat: light: Input/output error". This prevents pommed from working. I have a macbook pro (bought last week, so I think it is 4), and I am using kernel 2.6.25-11 (Fedora 9) (but tried the 2.6.26 with the same result). What's the problem? Is there any workaround? Thanks, Rolando |
|
From: paul s <mac...@qu...> - 2008-07-24 06:15:41
|
>> also can you provide a map for the sensors? cool... kind of figured they were in order... :-) > smc firmware prevent turning off or let them going too fast. i noticed that lm_sensors didn't pick up on fan3 which is labeled as cpu and has fan3_max at 3300... however if i echo 6000 out to fan3_min it spins up... so obviously i had to try them all and they all can go faster then their fanX_max... so it makes me wonder what the actual max speeds are of the fans or where we could find that information... btw, great work. cheers paul Roberto De Ioris wrote: > On Wed, 2008-07-23 at 19:41 -0400, paul s wrote: >> is there documentation on the three max fan speeds, a way to find them >> out or should i trust what fanX_max says? > > I "hope" the smc firmware prevent turning off or let them going too > fast. But obviously i can not be sure of this... > >> also can you provide a map for the sensors? >> >> cpu A = tempX_input >> ambient = tempX_input >> gpu = tempX_input >> gpu diode = tempX_input >> gpu heatsink = tempX_input >> hd bay 1 = tempX_input >> memory controller = tempX_input >> optical drive = tempX_input >> power = tempX_input > > > cpu = temp1_input > ambient = temp2_input > gpu = temp3_input > gpu diode = temp4_input > gpu heatsink = temp5_input > hd bay 1 = temp6_input > memory controller = temp7_input > optical drive = temp8_input > power = temp9_input > > -- > Roberto De Ioris > http://unbit.it |
|
From: Roberto De I. <ro...@un...> - 2008-07-24 04:57:43
|
On Wed, 2008-07-23 at 19:41 -0400, paul s wrote: > is there documentation on the three max fan speeds, a way to find them > out or should i trust what fanX_max says? I "hope" the smc firmware prevent turning off or let them going too fast. But obviously i can not be sure of this... > > also can you provide a map for the sensors? > > cpu A = tempX_input > ambient = tempX_input > gpu = tempX_input > gpu diode = tempX_input > gpu heatsink = tempX_input > hd bay 1 = tempX_input > memory controller = tempX_input > optical drive = tempX_input > power = tempX_input cpu = temp1_input ambient = temp2_input gpu = temp3_input gpu diode = temp4_input gpu heatsink = temp5_input hd bay 1 = temp6_input memory controller = temp7_input optical drive = temp8_input power = temp9_input -- Roberto De Ioris http://unbit.it |
|
From: paul s <mac...@qu...> - 2008-07-24 00:07:35
|
is there documentation on the three max fan speeds, a way to find them
out or should i trust what fanX_max says?
also can you provide a map for the sensors?
cpu A = tempX_input
ambient = tempX_input
gpu = tempX_input
gpu diode = tempX_input
gpu heatsink = tempX_input
hd bay 1 = tempX_input
memory controller = tempX_input
optical drive = tempX_input
power = tempX_input
cheers
paul
Roberto De Ioris wrote:
> Hi all, this patch (2.6.26 vanilla) add supports for fans and
> temperature sensors on intel iMac.
>
> Tested on iMac 24" 2.8ghz (iMac8,1), it supports the following sensors:
>
> cpu A
> ambient
> gpu
> gpu diode
> gpu heatsink
> hd bay 1
> memory controller
> optical drive
> power
>
> Signed-off-by: Roberto De Ioris <ro...@un...>
> ---
> diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
> index aacc0c4..bc616c3 100644
> --- a/drivers/hwmon/applesmc.c
> +++ b/drivers/hwmon/applesmc.c
> @@ -98,6 +98,8 @@ static const char* temperature_sensors_sets[][36] = {
> "TH1P", "TH2P", "TH3P", "TMAP", "TMAS", "TMBS", "TM0P",
> "TM0S",
> "TM1P", "TM1S", "TM2P", "TM2S", "TM3S", "TM8P", "TM8S",
> "TM9P",
> "TM9S", "TN0H", "TS0C", NULL },
> +/* Set 5: iMac */
> + { "TC0D", "TA0P", "TG0P", "TG0D", "TG0H", "TH0P", "Tm0P",
> "TO0P", "Tp0C", NULL },
> };
>
> /* List of keys used to read/write fan speeds */
> @@ -1223,6 +1225,8 @@ static __initdata struct dmi_match_data
> applesmc_dmi_data[] = {
> { .accelerometer = 0, .light = 0, .temperature_set = 3 },
> /* MacPro: temperature set 4 */
> { .accelerometer = 0, .light = 0, .temperature_set = 4 },
> +/* iMac: temperature set 5 */
> + { .accelerometer = 0, .light = 0, .temperature_set = 5 },
> };
>
> /* Note that DMI_MATCH(...,"MacBook") will match "MacBookPro1,1".
> @@ -1248,6 +1252,10 @@ static __initdata struct dmi_system_id
> applesmc_whitelist[] = {
> DMI_MATCH(DMI_BOARD_VENDOR,"Apple"),
> DMI_MATCH(DMI_PRODUCT_NAME,"MacPro2") },
> (void*)&applesmc_dmi_data[4]},
> + { applesmc_dmi_match, "Apple iMac", {
> + DMI_MATCH(DMI_BOARD_VENDOR,"Apple"),
> + DMI_MATCH(DMI_PRODUCT_NAME,"iMac") },
> + (void*)&applesmc_dmi_data[5]},
> { .ident = NULL }
> };
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Mactel-linux-devel mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/mactel-linux-devel
|
|
From: Roberto De I. <ro...@un...> - 2008-07-23 11:55:40
|
Hi all, this patch (2.6.26 vanilla) add supports for fans and
temperature sensors on intel iMac.
Tested on iMac 24" 2.8ghz (iMac8,1), it supports the following sensors:
cpu A
ambient
gpu
gpu diode
gpu heatsink
hd bay 1
memory controller
optical drive
power
Signed-off-by: Roberto De Ioris <ro...@un...>
---
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index aacc0c4..bc616c3 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -98,6 +98,8 @@ static const char* temperature_sensors_sets[][36] = {
"TH1P", "TH2P", "TH3P", "TMAP", "TMAS", "TMBS", "TM0P",
"TM0S",
"TM1P", "TM1S", "TM2P", "TM2S", "TM3S", "TM8P", "TM8S",
"TM9P",
"TM9S", "TN0H", "TS0C", NULL },
+/* Set 5: iMac */
+ { "TC0D", "TA0P", "TG0P", "TG0D", "TG0H", "TH0P", "Tm0P",
"TO0P", "Tp0C", NULL },
};
/* List of keys used to read/write fan speeds */
@@ -1223,6 +1225,8 @@ static __initdata struct dmi_match_data
applesmc_dmi_data[] = {
{ .accelerometer = 0, .light = 0, .temperature_set = 3 },
/* MacPro: temperature set 4 */
{ .accelerometer = 0, .light = 0, .temperature_set = 4 },
+/* iMac: temperature set 5 */
+ { .accelerometer = 0, .light = 0, .temperature_set = 5 },
};
/* Note that DMI_MATCH(...,"MacBook") will match "MacBookPro1,1".
@@ -1248,6 +1252,10 @@ static __initdata struct dmi_system_id
applesmc_whitelist[] = {
DMI_MATCH(DMI_BOARD_VENDOR,"Apple"),
DMI_MATCH(DMI_PRODUCT_NAME,"MacPro2") },
(void*)&applesmc_dmi_data[4]},
+ { applesmc_dmi_match, "Apple iMac", {
+ DMI_MATCH(DMI_BOARD_VENDOR,"Apple"),
+ DMI_MATCH(DMI_PRODUCT_NAME,"iMac") },
+ (void*)&applesmc_dmi_data[5]},
{ .ident = NULL }
};
|
|
From: Sven A. <an...@an...> - 2008-07-23 08:21:53
|
Hello, just for info: We have new hope for better Atheros wireless driver support: http://wireless.kernel.org/en/users/Drivers/ath9k Here is the first success report: https://lists.ath9k.org/pipermail/ath9k-devel/2008-July/000011.html I think it will stabilize in the next few weeks and then it will be usable out of the box... Regards Sven -- Sven Anders <an...@an...> () Ascii Ribbon Campaign /\ Support plain text e-mail ANDURAS service solutions AG Innstraße 71 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032 Mitglieder des Vorstands: Sven Anders, Marcus Junker Vorsitzender des Aufsichtsrats: Mark Peters |
|
From: Brandon K. <bdk...@gm...> - 2008-06-16 14:38:07
|
Thank you for your help. I will do that and report back. Brandon Koepke |
|
From: Sven A. <an...@an...> - 2008-06-16 08:05:48
|
Brandon Koepke schrieb:
> Any idea where to append the Cpu0Inst and Cpu1Inst files.
>
> Just append it to dsdt.dsl?
>
> Sorry, I used acpixtract to extract the full SSDT; however,
> the cpu0inst and cpu1inst data was not there. (I already know
> how to get the data, but I'm just not sure if I have to append
> the rest of the SSDT or just the values from cpu0inst and cpu1inst).
Sorry, but I cannot help you here, because I do not know that much
about ACPI, yet. And I have no time to get deeper into it, because
I have too much work at the moment. Sorry.
Besides I think this very special question is a candidate for the
ACPI mailing list. But please sent an update, if it worked...
Regards
Sven
--
Sven Anders <an...@an...> () Ascii Ribbon Campaign
/\ Support plain text e-mail
ANDURAS service solutions AG
Innstraße 71 - 94036 Passau - Germany
Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55
Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032
Mitglieder des Vorstands: Sven Anders, Marcus Junker
Vorsitzender des Aufsichtsrats: Mark Peters
|
|
From: paul s <mac...@qu...> - 2008-06-11 21:33:57
|
hi - i've sent this to the mactel users list and haven't received a reply yet, so i figured i'd try here... i spent most of the past weekend building 2.6.25.4 kernels for Fedora[8|9] and checking what works best with a mbp4,1 and could not get the applesmc-int-protect.patch to apply... the full error is here: http://queuemail.com/applesmc-int-protect.patch.err and basically this is the juicy stuff... [snip] + make ARCH=x86_64 nonint_oldconfig scripts/kconfig/lex.zconf.c:1647: warning: 'input' defined but not used .config:53:warning: trying to assign nonexistent symbol PREEMPT_BKL .config:79:warning: trying to assign nonexistent symbol PCIEASPM .config:80:warning: trying to assign nonexistent symbol PCIEASPM_DEBUG .config:205:warning: trying to assign nonexistent symbol MTD_PNC2000 . . . .config:3518:warning: trying to assign nonexistent symbol X86_64_XEN CONFIG_SENSORS_APPLESMC_PROTECT make[1]: *** [nonint_oldconfig] Error 1 make: *** [nonint_oldconfig] Error 2 [/snip] without applying this patch the kernel builds and runs successfully... are there changes to the kernel .config needed to make this patch apply? i am building the kernel with just the default config file... http://queuemail.com/config-x86_64 has anyone else had any luck applying all the patches or experienced the same error with the 25 set? cheers paul |
|
From: Jerome F. <jf...@gm...> - 2008-06-08 06:51:02
|
>> >>> >> > The way you're doing it:
>> >>> >> >
>> >>> >> >> static struct hidinput_key_translation apple_fn_keys[] = {
>> >>> >> >> { KEY_BACKSPACE, KEY_DELETE },
>> >>> >> >> { KEY_F1, KEY_BRIGHTNESSDOWN, APPLE_FLAG_FKEY },
>> >>> >> >> { KEY_F2, KEY_BRIGHTNESSUP, APPLE_FLAG_FKEY },
>> >>> >> >> { KEY_F3, KEY_FN_F5, APPLE_FLAG_FKEY }, /*
>> >>> >> >> Exposé */
>> >>> >> >> { KEY_F4, KEY_FN_F4, APPLE_FLAG_FKEY }, /*
>> >>> >> >> Dashboard */
>> >>> >> >> + { KEY_F5, KEY_KBDILLUMDOWN, APPLE_FLAG_FKEY },
>> >>> >> >> + { KEY_F6, KEY_KBDILLUMUP, APPLE_FLAG_FKEY },
>> >>> >> >> { KEY_F7, KEY_PREVIOUSSONG, APPLE_FLAG_FKEY },
>> >>> >> >> { KEY_F8, KEY_PLAYPAUSE, APPLE_FLAG_FKEY },
>> >>> >> >> { KEY_F9, KEY_NEXTSONG, APPLE_FLAG_FKEY },
>> >>> >> >
>> >>> >> > breaks keyboards without these special keys, e.g. external USB
>> >>> >> > keyboards. Also, I think some MacBook Pros have/had a different layout
>> >>> >> > of the special keys, though you may already account for that.
>> >>> >> >
>> >>> >> I had a quick look and on Google images, and the only similar layout
>> >>> >> but different for these 2 keys that I can find is the one of the alu
>> >>> >> wireless keyboard of Apple:
>> >>> >> http://www.thomann.de/fr/prod_bdb_AR_119224.html?image=0&sid=c0c7390b59f0507d18fadbba8776c7b8
>> >>> >
>> >>> > Same for the USB aluminum keyboard.
>> >>> >
>> >>> >> But these two keys seem to be mapped to nothing in fact. So, imho,
>> >>> >> mapping these two keys to keyboard brightness control, even if it's
>> >>> >> not applicable to these keyboard, still makes sense to me : It keeps
>> >>> >> the layout consistent (having to press Fn to get the Fx keys except
>> >>> >> for F5 and F6 is weird), and should no other side effect on these
>> >>> >> keyboards.
>> >>> >
>> >>> > I disagree; as there's no special function engraved on these keys, they
>> >>> > should always generate F5/6.
>> >>> >
>> >>> So, we should prevent macbook users from using their keyboard
>> >>> backlights to allow people using other apple keyboards to use F5/F6
>> >>> with or without the Fn key ?
>> >>
>> >> Of course not (where did you get that idea?). They should just use a
>> >> different table.
>> >>
>> > Ok, but then, how do you suggest to make the difference between the
>> > keyboards needing the macbook table and the others ? The easiest
>> > solution would be to define another quirk. But as I said, the integer
>> > used to store the list of quirks to use is almost full (see
>> > include/linux/hid.h) which makes it, imo, a not-lasting-enough
>> > solution (If we go this way, I have the feeling we will have to find
>> > another way at the next kernel release). The other solution would be
>> > to hardcore some products id drivers/hid/hid-input.c using a macro,
>> > which is, still imo, kind of dirty (I did it in my patch because it's
>> > already done currently in the code of the mainstream kernel).
>> > So, what do you think we should do precisely ?
>> >
>> Hmm .... actually, I just thought of something pretty stupid/simple:
>> add another field to the structure
>> drivers/hid/usbhid/hid-quirks.c:hid_blacklist. As a temporary
>> solution, it should be fine. Does anyone know any possible side effect
>> of adding a field to this structure ?
>
> Not me (ask the hid developers maybe? :), but yeah, basically the
> quicker'n'dirtier way is to extend the existing device ID test for
> selecting the table, and the cleaner way would be to add a field to some
> quirk struct where the table pointer can be stored.
>
Here is a "quirk & dirty" patch for the kernel 2.6.25.4. For the keys
F5/F6, it should only affect Apple Wellspring 2 keyboards (the one I
have) : I've simply used another bit in the integer storing what
quirks to use (2 bits left ...). |
|
From: Jerome F. <jf...@gm...> - 2008-06-02 17:44:03
|
2008/6/2 Jerome Flesch <jf...@gm...>:
>>> >> > The way you're doing it:
>>> >> >
>>> >> >> static struct hidinput_key_translation apple_fn_keys[] = {
>>> >> >> { KEY_BACKSPACE, KEY_DELETE },
>>> >> >> { KEY_F1, KEY_BRIGHTNESSDOWN, APPLE_FLAG_FKEY },
>>> >> >> { KEY_F2, KEY_BRIGHTNESSUP, APPLE_FLAG_FKEY },
>>> >> >> { KEY_F3, KEY_FN_F5, APPLE_FLAG_FKEY }, /*
>>> >> >> Exposé */
>>> >> >> { KEY_F4, KEY_FN_F4, APPLE_FLAG_FKEY }, /*
>>> >> >> Dashboard */
>>> >> >> + { KEY_F5, KEY_KBDILLUMDOWN, APPLE_FLAG_FKEY },
>>> >> >> + { KEY_F6, KEY_KBDILLUMUP, APPLE_FLAG_FKEY },
>>> >> >> { KEY_F7, KEY_PREVIOUSSONG, APPLE_FLAG_FKEY },
>>> >> >> { KEY_F8, KEY_PLAYPAUSE, APPLE_FLAG_FKEY },
>>> >> >> { KEY_F9, KEY_NEXTSONG, APPLE_FLAG_FKEY },
>>> >> >
>>> >> > breaks keyboards without these special keys, e.g. external USB
>>> >> > keyboards. Also, I think some MacBook Pros have/had a different layout
>>> >> > of the special keys, though you may already account for that.
>>> >> >
>>> >> I had a quick look and on Google images, and the only similar layout
>>> >> but different for these 2 keys that I can find is the one of the alu
>>> >> wireless keyboard of Apple:
>>> >> http://www.thomann.de/fr/prod_bdb_AR_119224.html?image=0&sid=c0c7390b59f0507d18fadbba8776c7b8
>>> >
>>> > Same for the USB aluminum keyboard.
>>> >
>>> >> But these two keys seem to be mapped to nothing in fact. So, imho,
>>> >> mapping these two keys to keyboard brightness control, even if it's
>>> >> not applicable to these keyboard, still makes sense to me : It keeps
>>> >> the layout consistent (having to press Fn to get the Fx keys except
>>> >> for F5 and F6 is weird), and should no other side effect on these
>>> >> keyboards.
>>> >
>>> > I disagree; as there's no special function engraved on these keys, they
>>> > should always generate F5/6.
>>> >
>>> So, we should prevent macbook users from using their keyboard
>>> backlights to allow people using other apple keyboards to use F5/F6
>>> with or without the Fn key ?
>>
>> Of course not (where did you get that idea?). They should just use a
>> different table.
>>
> Ok, but then, how do you suggest to make the difference between the
> keyboards needing the macbook table and the others ? The easiest
> solution would be to define another quirk. But as I said, the integer
> used to store the list of quirks to use is almost full (see
> include/linux/hid.h) which makes it, imo, a not-lasting-enough
> solution (If we go this way, I have the feeling we will have to find
> another way at the next kernel release). The other solution would be
> to hardcore some products id drivers/hid/hid-input.c using a macro,
> which is, still imo, kind of dirty (I did it in my patch because it's
> already done currently in the code of the mainstream kernel).
> So, what do you think we should do precisely ?
>
Hmm .... actually, I just thought of something pretty stupid/simple:
add another field to the structure
drivers/hid/usbhid/hid-quirks.c:hid_blacklist. As a temporary
solution, it should be fine. Does anyone know any possible side effect
of adding a field to this structure ?
|
|
From: Jerome F. <jf...@gm...> - 2008-06-02 17:14:12
|
>> >> > The way you're doing it:
>> >> >
>> >> >> static struct hidinput_key_translation apple_fn_keys[] = {
>> >> >> { KEY_BACKSPACE, KEY_DELETE },
>> >> >> { KEY_F1, KEY_BRIGHTNESSDOWN, APPLE_FLAG_FKEY },
>> >> >> { KEY_F2, KEY_BRIGHTNESSUP, APPLE_FLAG_FKEY },
>> >> >> { KEY_F3, KEY_FN_F5, APPLE_FLAG_FKEY }, /*
>> >> >> Exposé */
>> >> >> { KEY_F4, KEY_FN_F4, APPLE_FLAG_FKEY }, /*
>> >> >> Dashboard */
>> >> >> + { KEY_F5, KEY_KBDILLUMDOWN, APPLE_FLAG_FKEY },
>> >> >> + { KEY_F6, KEY_KBDILLUMUP, APPLE_FLAG_FKEY },
>> >> >> { KEY_F7, KEY_PREVIOUSSONG, APPLE_FLAG_FKEY },
>> >> >> { KEY_F8, KEY_PLAYPAUSE, APPLE_FLAG_FKEY },
>> >> >> { KEY_F9, KEY_NEXTSONG, APPLE_FLAG_FKEY },
>> >> >
>> >> > breaks keyboards without these special keys, e.g. external USB
>> >> > keyboards. Also, I think some MacBook Pros have/had a different layout
>> >> > of the special keys, though you may already account for that.
>> >> >
>> >> I had a quick look and on Google images, and the only similar layout
>> >> but different for these 2 keys that I can find is the one of the alu
>> >> wireless keyboard of Apple:
>> >> http://www.thomann.de/fr/prod_bdb_AR_119224.html?image=0&sid=c0c7390b59f0507d18fadbba8776c7b8
>> >
>> > Same for the USB aluminum keyboard.
>> >
>> >> But these two keys seem to be mapped to nothing in fact. So, imho,
>> >> mapping these two keys to keyboard brightness control, even if it's
>> >> not applicable to these keyboard, still makes sense to me : It keeps
>> >> the layout consistent (having to press Fn to get the Fx keys except
>> >> for F5 and F6 is weird), and should no other side effect on these
>> >> keyboards.
>> >
>> > I disagree; as there's no special function engraved on these keys, they
>> > should always generate F5/6.
>> >
>> So, we should prevent macbook users from using their keyboard
>> backlights to allow people using other apple keyboards to use F5/F6
>> with or without the Fn key ?
>
> Of course not (where did you get that idea?). They should just use a
> different table.
>
Ok, but then, how do you suggest to make the difference between the
keyboards needing the macbook table and the others ? The easiest
solution would be to define another quirk. But as I said, the integer
used to store the list of quirks to use is almost full (see
include/linux/hid.h) which makes it, imo, a not-lasting-enough
solution (If we go this way, I have the feeling we will have to find
another way at the next kernel release). The other solution would be
to hardcore some products id drivers/hid/hid-input.c using a macro,
which is, still imo, kind of dirty (I did it in my patch because it's
already done currently in the code of the mainstream kernel).
So, what do you think we should do precisely ?
|
|
From: Jerome F. <jf...@gm...> - 2008-06-02 08:27:55
|
>> > The way you're doing it:
>> >
>> >> static struct hidinput_key_translation apple_fn_keys[] = {
>> >> { KEY_BACKSPACE, KEY_DELETE },
>> >> { KEY_F1, KEY_BRIGHTNESSDOWN, APPLE_FLAG_FKEY },
>> >> { KEY_F2, KEY_BRIGHTNESSUP, APPLE_FLAG_FKEY },
>> >> { KEY_F3, KEY_FN_F5, APPLE_FLAG_FKEY }, /*
>> >> Exposé */
>> >> { KEY_F4, KEY_FN_F4, APPLE_FLAG_FKEY }, /*
>> >> Dashboard */
>> >> + { KEY_F5, KEY_KBDILLUMDOWN, APPLE_FLAG_FKEY },
>> >> + { KEY_F6, KEY_KBDILLUMUP, APPLE_FLAG_FKEY },
>> >> { KEY_F7, KEY_PREVIOUSSONG, APPLE_FLAG_FKEY },
>> >> { KEY_F8, KEY_PLAYPAUSE, APPLE_FLAG_FKEY },
>> >> { KEY_F9, KEY_NEXTSONG, APPLE_FLAG_FKEY },
>> >
>> > breaks keyboards without these special keys, e.g. external USB
>> > keyboards. Also, I think some MacBook Pros have/had a different layout
>> > of the special keys, though you may already account for that.
>> >
>> I had a quick look and on Google images, and the only similar layout
>> but different for these 2 keys that I can find is the one of the alu
>> wireless keyboard of Apple:
>> http://www.thomann.de/fr/prod_bdb_AR_119224.html?image=0&sid=c0c7390b59f0507d18fadbba8776c7b8
>
> Same for the USB aluminum keyboard.
>
>> But these two keys seem to be mapped to nothing in fact. So, imho,
>> mapping these two keys to keyboard brightness control, even if it's
>> not applicable to these keyboard, still makes sense to me : It keeps
>> the layout consistent (having to press Fn to get the Fx keys except
>> for F5 and F6 is weird), and should no other side effect on these
>> keyboards.
>
> I disagree; as there's no special function engraved on these keys, they
> should always generate F5/6.
>
So, we should prevent macbook users from using their keyboard
backlights to allow people using other apple keyboards to use F5/F6
with or without the Fn key ? I know you said that a better way of
making all these quirks is in process, but in the meantime, I still
think that enforcing consistency across all Apple keyboards is the
better solution. Moreover, people using external apple keyboards will
still be able to map Fn-F5 Fn-F6 to something else (including F5/F6),
but MacBook Pro users need these keys to be mapped to the control of
the keyboard backlights because these key codes are hard-coded in
pommed. Actually, even if they weren't, they would have to map F5/F6
to be coherent with the drawing on their keyboard, probably
conflicting with many other use of F5/F6.
|
|
From: Jerome F. <jf...@gm...> - 2008-06-02 07:58:05
|
> On Sun, 2008-06-01 at 20:00 -0700, Jerome Flesch wrote:
>> >>
>> >> In kernel/mactel-patches-2.6.24/hid-add-new-apple-keyboard.patch , two
>> >> keys seem to be missing in the array "apple_keyboard_fn_keys":
>> >> { KEY_F5, KEY_KBDILLUMDOWN, POWERBOOK_FLAG_FKEY },
>> >> { KEY_F6, KEY_KBDILLUMUP, POWERBOOK_FLAG_FKEY },
>> >>
>> >> Without these two lines, it's not possible for me on my macbook pro
>> >> 4.1 to adjust the light of the keyboard with pommed, but with them, it
>> >> works fine.
>> >
>> >
>> > It would be great if you could test if the problem still happens on
>> > 2.6.25.x, and port it if necessary (I quickly tried, but it is not trival,
>> > as some files changed quite importantly in the kernel)
>> >
>> Done. I had to port the patch for the 2.6.24 to the 2.6.25.4 (some
>> part of the 2.6.24 patch were already included mainstream ?).
>
> Yeah, I pushed that via the hid tree for external Aluminum USB
> keyboards.
>
>> I've joined the patch to this mail.
>>
>> The problem with the two keys is confirmed and solved in this patch.
>>
>> I prefered to not add another "#define APPLE_QUIRK" as done in the
>> 2.6.24 patch because the 2.6.25 seems to include a lot more quirks and
>> almost all the bits of the 32bits integer contaning the list of quirk
>> to apply are used now. Moreover, the word "powerbook" has been
>> replaced in many places by "apple", so adding another quirk name using
>> the word "apple" would have been confusing :/
>> Instead, I did like it seems to be done in the mainstream 2.6.25.4 :
>> Look if the product ID is between 0x220 and 0x300 to know if it's a
>> powerbook keyboard or another apple keyboard. According to the list of
>> apple keyboards in drivers/hid/usbhid/hid-quirks.c, it should be fine.
>
> The way you're doing it:
>
>> static struct hidinput_key_translation apple_fn_keys[] = {
>> { KEY_BACKSPACE, KEY_DELETE },
>> { KEY_F1, KEY_BRIGHTNESSDOWN, APPLE_FLAG_FKEY },
>> { KEY_F2, KEY_BRIGHTNESSUP, APPLE_FLAG_FKEY },
>> { KEY_F3, KEY_FN_F5, APPLE_FLAG_FKEY }, /*
>> Exposé */
>> { KEY_F4, KEY_FN_F4, APPLE_FLAG_FKEY }, /*
>> Dashboard */
>> + { KEY_F5, KEY_KBDILLUMDOWN, APPLE_FLAG_FKEY },
>> + { KEY_F6, KEY_KBDILLUMUP, APPLE_FLAG_FKEY },
>> { KEY_F7, KEY_PREVIOUSSONG, APPLE_FLAG_FKEY },
>> { KEY_F8, KEY_PLAYPAUSE, APPLE_FLAG_FKEY },
>> { KEY_F9, KEY_NEXTSONG, APPLE_FLAG_FKEY },
>
> breaks keyboards without these special keys, e.g. external USB
> keyboards. Also, I think some MacBook Pros have/had a different layout
> of the special keys, though you may already account for that.
>
I had a quick look and on Google images, and the only similar layout
but different for these 2 keys that I can find is the one of the alu
wireless keyboard of Apple:
http://www.thomann.de/fr/prod_bdb_AR_119224.html?image=0&sid=c0c7390b59f0507d18fadbba8776c7b8
But these two keys seem to be mapped to nothing in fact. So, imho,
mapping these two keys to keyboard brightness control, even if it's
not applicable to these keyboard, still makes sense to me : It keeps
the layout consistent (having to press Fn to get the Fx keys except
for F5 and F6 is weird), and should no other side effect on these
keyboards.
My quick look on Google images also showed me some macbooks pro
(probably first generation) having the powerbook layout (
http://www.notebookreview.com/assets/15839.jpg ). But none of them
having one similar-but-different to mine.
> I'm CC'ing Michael Hanselmann, who's done most of the work on this
> stuff. I think his plan was to add a new field to the quirks struct so a
> single quirk can use several different tables. Michael, have you
> submitted any of that yet?
>
|
|
From: Jerome F. <jf...@gm...> - 2008-06-02 03:00:08
|
>> Hello,
>>
>> In kernel/mactel-patches-2.6.24/hid-add-new-apple-keyboard.patch , two
>> keys seem to be missing in the array "apple_keyboard_fn_keys":
>> { KEY_F5, KEY_KBDILLUMDOWN, POWERBOOK_FLAG_FKEY },
>> { KEY_F6, KEY_KBDILLUMUP, POWERBOOK_FLAG_FKEY },
>>
>> Without these two lines, it's not possible for me on my macbook pro
>> 4.1 to adjust the light of the keyboard with pommed, but with them, it
>> works fine.
>
>
> It would be great if you could test if the problem still happens on
> 2.6.25.x, and port it if necessary (I quickly tried, but it is not trival,
> as some files changed quite importantly in the kernel)
>
Done. I had to port the patch for the 2.6.24 to the 2.6.25.4 (some
part of the 2.6.24 patch were already included mainstream ?). I've
joined the patch to this mail.
The problem with the two keys is confirmed and solved in this patch.
I prefered to not add another "#define APPLE_QUIRK" as done in the
2.6.24 patch because the 2.6.25 seems to include a lot more quirks and
almost all the bits of the 32bits integer contaning the list of quirk
to apply are used now. Moreover, the word "powerbook" has been
replaced in many places by "apple", so adding another quirk name using
the word "apple" would have been confusing :/
Instead, I did like it seems to be done in the mainstream 2.6.25.4 :
Look if the product ID is between 0x220 and 0x300 to know if it's a
powerbook keyboard or another apple keyboard. According to the list of
apple keyboards in drivers/hid/usbhid/hid-quirks.c, it should be fine.
Hm, just two other things:
- Why is there no 'apply' script in
mactel/kernel/mactel-patches-2.6.25 like in
mactel/kernel/mactel-patches-2.6.24 ? It makes these patches much
easier to use for non-dev people.
- Also, can you integrate my two-lines fix to the patch for the kernel
2.6.24 please? I had a problem with the kernel 2.6.25 older than the
2.6.25.4 (bug in the SATA driver), and I have the feeling that the
kernel 2.6.24 can still be useful for some people.
|
|
From: Ludwig 'K. N. <lu...@no...> - 2008-05-30 06:34:18
|
Jerome Flesch a écrit :
>>> In kernel/mactel-patches-2.6.24/hid-add-new-apple-keyboard.patch , two
>>> keys seem to be missing in the array "apple_keyboard_fn_keys":
>>> { KEY_F5, KEY_KBDILLUMDOWN, POWERBOOK_FLAG_FKEY },
>>> { KEY_F6, KEY_KBDILLUMUP, POWERBOOK_FLAG_FKEY },
>>>
>>> Without these two lines, it's not possible for me on my macbook pro
>>> 4.1 to adjust the light of the keyboard with pommed, but with them, it
>>> works fine.
>> Indeed, I just recompile with those two lines above and it works, thanx a
>> lot :) BTW, do you know what KEY_CYCLEWINDOWS (F3) and KEY_CONFIG (F4) refer
>> to ? pommed returns "KBD: inhibit clear 0x08 -> 0x00" for both of them,
>> which have no result on keyboard backlight.
>>
> Pommed doesn't handle these keys. And I think it makes sense since
> this way it let you map them to whatever you want. I think
> KEY_CYCLEWINDOWS correspond to the Compiz-fusion plugin "Scale", and
> KEY_CONFIG is probably supposed to be mapped to launch
> gnome-control-center or kcontrol (actually I'm too lazy to reboot
> under MacOSX to check :)
OK, since it's confirmed pommed don't use them, I just mapped them
respectively to XF86RotateWindows and XF86MyComputer in my .Xmodmap
Thanx,
--
Ludwig 'Kn' Noujarret
lu...@no...
|
|
From: Jerome F. <jf...@gm...> - 2008-05-30 05:56:41
|
>> In kernel/mactel-patches-2.6.24/hid-add-new-apple-keyboard.patch , two
>> keys seem to be missing in the array "apple_keyboard_fn_keys":
>> { KEY_F5, KEY_KBDILLUMDOWN, POWERBOOK_FLAG_FKEY },
>> { KEY_F6, KEY_KBDILLUMUP, POWERBOOK_FLAG_FKEY },
>>
>> Without these two lines, it's not possible for me on my macbook pro
>> 4.1 to adjust the light of the keyboard with pommed, but with them, it
>> works fine.
>
> Indeed, I just recompile with those two lines above and it works, thanx a
> lot :) BTW, do you know what KEY_CYCLEWINDOWS (F3) and KEY_CONFIG (F4) refer
> to ? pommed returns "KBD: inhibit clear 0x08 -> 0x00" for both of them,
> which have no result on keyboard backlight.
>
Pommed doesn't handle these keys. And I think it makes sense since
this way it let you map them to whatever you want. I think
KEY_CYCLEWINDOWS correspond to the Compiz-fusion plugin "Scale", and
KEY_CONFIG is probably supposed to be mapped to launch
gnome-control-center or kcontrol (actually I'm too lazy to reboot
under MacOSX to check :)
|
|
From: Jerome F. <jf...@gm...> - 2008-05-30 05:51:15
|
> Hi,
>
> Jerome Flesch wrote:
>>
>> Hello,
>>
>> In kernel/mactel-patches-2.6.24/hid-add-new-apple-keyboard.patch , two
>> keys seem to be missing in the array "apple_keyboard_fn_keys":
>> { KEY_F5, KEY_KBDILLUMDOWN, POWERBOOK_FLAG_FKEY },
>> { KEY_F6, KEY_KBDILLUMUP, POWERBOOK_FLAG_FKEY },
>>
>> Without these two lines, it's not possible for me on my macbook pro
>> 4.1 to adjust the light of the keyboard with pommed, but with them, it
>> works fine.
>
>
> It would be great if you could test if the problem still happens on
> 2.6.25.x, and port it if necessary (I quickly tried, but it is not trival,
> as some files changed quite importantly in the kernel)
>
Ok, I will try it as soon as I have time for it (probably tomorrow or Saturday).
>> I'm also wondering : Is there any plan to integrate your patches to
>> the mainstream linux kernel ?
>
> - applesmc*: My responsability, but I'm lacking time to get them integrated
> (and some need disk-protect*)
> - appletouch*: Sven Anders
> - disk-protect* + export-lookup_dev.patch: Elias Oltmanns (from hdaps) and
> me (some exports to be able to park the head from my driver)
> - sigmatel_*: Maybe I should send them upstream, but to be honest I'm not
> sure these are absolutely necessary, or if you should set your model using a
> kernel parameters.
>
> So basically there are 2 patches I could send upstream relatively easily:
> applesmc-retry-when-accessing-keys.patch
> applesmc-remove-debugging-messages.patch
> (the 2nd one fixing a problem occuring when the 1st one is used IIRC)...
>
> I'll get that done, when I have time...
>
Actually, even if I don't know much about the process of development
of the kernel, I have a good knowledge in C programming (Unix and
embedded), so, if you feel I could help you, just ask :)
> Best regards,
>
> Nicolas
>
|
71 messages has been excluded from this view by a project administrator.
