Re: no function keys in 2.6.18 ?
Yves-Alexis Perez <[EMAIL PROTECTED]> writes: > I've tested a vanilla 2.6.18-rc4 kernel, and it seems that I don't have > anymore function keys from F1 to F10. F11 and F12 work well. Try running "fnset -u" as root. -- Paul Collins Melbourne, Australia Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[OT] Ubuntu and powerpc (was Re: linux-kernel-di-powerpc-2.6_1.24_powerpc.changes REJECTED)
Sven Luther <[EMAIL PROTECTED]> writes: > On Tue, Nov 28, 2006 at 08:00:45AM +0100, Michael Schmitz wrote: >> (contemplating to switch to ubuntu finally, as the Debian development >> process now appears to be broken by design at least as it relates to >> powerpc) > > Oh, ubuntu is not better, Well, Colin Watson is handling the port, which is > fine, but they also left bug reports from me molder in their awful BTS for > months, and they where finally never applied. And they asked for hardware > donation and possibly some monetary incetive (not sure about this one though), > in order to get the pegasos supported, even though we made all the work. They seem to be considering dropping powerpc anyway. http://www.linux.com/article.pl?sid=06/11/16/1443243 > According to the PowerPC review spec, only 0.8% of downloads from > archive.ubuntu.com are for the PowerPC architecture as of November > 2006, down from 1.95% in July 2005. > > Ubuntu founder Mark Shuttleworth and Ubuntu CTO Matt Zimmerman each > indicated that dropping official support for Ubuntu's desktop > install on PowerPC was on the table. While demand for PowerPC is > declining, the work required to keep the port current remains > steady. > > Lack of official support doesn't mean that PowerPC support would go > out the window entirely. If demand for PowerPC server installs > remains steady, it could be maintained as an unofficial port and > moved to ports.ubuntu.com. -- Paul Collins Wellington, New Zealand Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PowerBook G4 (5.9) Debian Sound problem
Steffen Thoss <[EMAIL PROTECTED]> writes: > I'm new to Linux on the PowerPC and have a problem with the sound on my > PowerBook (1.67 Ghz) Modell 5.9. > The problem is that the Gnome System sounds are working but all other > sound like mp3, DVD sound or radio streaming don't. Sometimes I just get > a noise and sometimes just nothing. I also have a constant low noise > from the speaker all the time. First I thought it's from the harddisk > but its from the speakers. I don't know about the second problem, but the first could be caused by DRC (dynamic range compression) -- those event sounds are short enough that it mightn't trigger for those. To check if this is the case, look for the "DRC Switch" slider in your ALSA mixer program and either crank it up to 100% or "mute" it to disable DRC. -- Paul Collins Wellington, New Zealand Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ltrace broken?
Roger Leigh <[EMAIL PROTECTED]> writes:
> Is ltrace working for anyone else in current unstable?
>
> $ ltrace cat
> +++ exited (status 0) +++
Seems okay here:
[briny(~)] ltrace cat
getpagesize()= 4096
setlocale(6, "") = "C"
bindtextdomain("coreutils", "/usr/share/locale") = "/usr/share/locale"
textdomain("coreutils") = "coreutils"
__cxa_atexit(0x10001a90, 0, 0, 2, 0xffc568c) = 0
getopt_long(1, 0x7f890754, "benstuvAET", 0x10003d40, NULL) = -1
__fxstat64(3, 1, 0x7f890410) = 0
__fxstat64(3, 0, 0x7f890410) = 0
malloc(8191) = 0x10015038
read(0, "", 604120194) = 0
free(0x10015038) =
close(0) = 0
exit(0
__fpending(0xffea9e8, 0, 3, 0, 0xff62d24)= 0
fclose(0xffea9e8)= 0
+++ exited (status 0) +++
No -dbg packages installed even.
--
Dag vijandelijk luchtschip de huismeester is dood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-PPC powerbook laptop support.
Yves-Alexis Perez <[EMAIL PROTECTED]> writes: > On Sat, 2006-02-18 at 08:18 +1100, Benjamin Herrenschmidt wrote: > >> You probably need the bunch of patches I did to fix some of the worst >> issues with the radeon driver. I just commited them yesterday in X.org >> CVS... hopefully, debian will get an updated radeon driver when they >> finally switch to modular (7.0) > > I don't follow X strike force list, so do you know when it's gonna > happen ? Sounds like packages are hitting experimental soon: http://gravityboy.livejournal.com/22773.html -- Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.16 backtrace at boot (Ibook G4) (related to "PowerBook5,4 -- no sound?")
Hi Ben, Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > On Tue, 2006-04-18 at 17:20 +0200, Michael Schmitz wrote: >> > > Here a trace at boot from the sound driver : >> > >> > I think that bug happens if the sound driver loads before i2c-powermac. >> >> i2c-keywest is still request-module()d in 2.6.17-rc1, FWIW. >> >> Regarding other sound breakage with 2.6.17-rc1, I traced that to >> >> machine_is(powermac) >> >> returning zero in sound/ppc/pmac.c:snd_pmac_detect() when loading >> snd-powermac. The OSS driver spits -ENODEV as well on loading so I'd >> suspect the same thing here. >> >> machine_is boils down to a comparison machine_id == &mach_powermac, is >> that sort of thing illegal after kernel init? > > Totally untested patch, please let me know if it helps: Results in the following. arch/powerpc/platforms/powermac/setup.c:721: error: 'mach_powermac' undeclared here (not in a function) arch/powerpc/platforms/powermac/setup.c:721: warning: type defaults to 'int' in declaration of 'mach_powermac' make[2]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1 make[1]: *** [arch/powerpc/platforms/powermac] Error 2 make: *** [arch/powerpc/platforms] Error 2 It looks like the EXPORT_SYMBOL() needs to be after the definition. However, I tried adding "EXPORT_SYMBOL(mach_powermac);" after the define_machine(powermac) and now sound works for me with my original I2C_POWERMAC=y SND_POWERMAC=m configuration. -- Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to get the latest git sources
Wolfgang Pfeiffer <[EMAIL PROTECTED]> writes: > Hints to what rules most, from a user's perspective, who does nothing > more than getting the lates git sources and build a kernel .deb with them? Just do $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Now you have a fresh up-to-date Linux tree in ./linux-2.6 To keep it up to date run "git pull" in the root of this new tree. -- Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.16-1 hyper logging
Jean-Christophe Michel <[EMAIL PROTECTED]> writes: > 2.6.16-1 is a bit too much logging: > kernel: evbug.c: Event. Dev: adb2:2.c4/input, Type: 0, Code: 0, Value: 0 > kernel: evbug.c: Event. Dev: powermac/beep, Type: 18, Code: 2, Value: 0 > > Quite 20 lines per second ! Is there a var to change via /proc/sys or is > it necessary to recompile the kernel with less logging ? It looks like the evbug module is loaded, which is designed to do exactly this. Just unload the module. -- Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.17-rc3: cpufreq-set -g ondemand does not work
Bernhard Reiter <[EMAIL PROTECTED]> writes: > but my idea would be that an ondemand govenor would just work > on a load average with some delay to even out spikes. The userspace governor combined with powernowd will give you this. And since the userspace governor defaults to the lowest CPU frequency, it all works out nicely. I've using it happily on my PowerBook. -- Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: snd-aoa status update / automatic driver loading
Johannes Berg <[EMAIL PROTECTED]> writes: > On Thu, 2006-05-18 at 10:25 +0300, Eddy Petrişor wrote: > >> Any chance for 5,2 ? What is needed for it? Codec only? > > I don't know. If you try loading the modules, the kernel will tell you > something about an unhandled layout id. Alternatively, you can find the > layout-id file in your /proc/device-tree/ and tell me the number in it. > The rest I can figure out. I have a PowerBook5,4 here and I'd be happy to test support for it. The hardware is identified by snd-powermac as "PowerMac Snapper" and the layout ID appears to be "3". [briny(device-tree)] od -c [EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/sound/layout-id 000 \0 \0 \0 3 004 -- Dag vijandelijk luchtschip de huismeester is dood
Re: snd-aoa status update / automatic driver loading
Johannes Berg <[EMAIL PROTECTED]> writes:
> On Fri, 2006-05-19 at 23:20 +1000, Paul Collins wrote:
>
>> I have a PowerBook5,4 here and I'd be happy to test support for it.
>> The hardware is identified by snd-powermac as "PowerMac Snapper" and
>> the layout ID appears to be "3".
>
> Try downloading snd-aoa and in snd-aoa-fabric-layout.c change the two
> occurrences of '70' to '3'. If it works, let me know and I'll add the
> proper entry for it.
When I probed i2sbus nothing much seemed to happen, so I added a
printk to see what layout ID was being returned, and I'm getting 51,
not 3 as found in the device tree. However, when I use 51 instead of
3 in those two places, I still don't get much happening.
Here's the dmesg after "modprobe i2sbus":
May 20 00:35:51 briny kernel: i2sbus: mapped i2s control registers
May 20 00:35:51 briny kernel: i2sbus: control register contents:
May 20 00:35:51 briny kernel: i2sbus:fcr0 = 0x0
May 20 00:35:51 briny kernel: i2sbus:cell_control = 0x0
May 20 00:35:51 briny kernel: i2sbus:fcr2 = 0x4ef1c25
May 20 00:35:51 briny kernel: i2sbus:fcr3 = 0x0
May 20 00:35:51 briny kernel: i2sbus:clock_control = 0x0
May 20 00:35:51 briny kernel: layout id is 51
May 20 00:35:51 briny kernel: i2sbus control destroyed
And lsmod:
Module Size Used by
i2sbus 21632 0
soundbus8132 1 i2sbus
radeon129896 0
drm82968 1 radeon
snd_usb_audio 90624 0
snd_usb_lib19232 1 snd_usb_audio
snd_rawmidi29280 1 snd_usb_lib
snd_hwdep 11012 1 snd_usb_audio
hci_usb14164 3
snd_pcm_oss50816 0
snd_pcm 103588 3 i2sbus,snd_usb_audio,snd_pcm_oss
snd_timer 27140 1 snd_pcm
snd_page_alloc 11432 1 snd_pcm
pcmcia 45776 0
ehci_hcd 37224 0
bcm43xx 448916 0
ieee80211softmac 32384 1 bcm43xx
uninorth_agp 2 1
agpgart38484 2 drm,uninorth_agp
ohci_hcd 24452 0
ieee80211 36776 2 bcm43xx,ieee80211softmac
ieee80211_crypt 6880 1 ieee80211
yenta_socket 30412 1
rsrc_nonstatic 13472 1 yenta_socket
pcmcia_core49592 3 pcmcia,yenta_socket,rsrc_nonstatic
Here are the changes I made.
diff --git a/aoa/fabrics/snd-aoa-fabric-layout.c
b/aoa/fabrics/snd-aoa-fabric-layout.c
index 65cda87..180dca4 100644
--- a/aoa/fabrics/snd-aoa-fabric-layout.c
+++ b/aoa/fabrics/snd-aoa-fabric-layout.c
@@ -84,7 +84,7 @@ MODULE_ALIAS("sound-layout-64");
MODULE_ALIAS("sound-layout-65");
MODULE_ALIAS("sound-layout-68");
MODULE_ALIAS("sound-layout-69");
-MODULE_ALIAS("sound-layout-70");
+MODULE_ALIAS("sound-layout-51");
MODULE_ALIAS("sound-layout-72");
MODULE_ALIAS("sound-layout-86");
MODULE_ALIAS("sound-layout-84");
@@ -214,7 +214,7 @@ static struct layout layouts[] = {
},
.busname = "digital in", .pcmid = 1 },
/* Early 2005 PowerBook */
- { .layout_id = 70,
+ { .layout_id = 51,
.codecs[0] = {
.name = "tas",
.connections = tas_connections_nolineout,
diff --git a/soundbus/i2sbus/i2sbus-core.c b/soundbus/i2sbus/i2sbus-core.c
index f6463cb..ff5b52e 100644
--- a/soundbus/i2sbus/i2sbus-core.c
+++ b/soundbus/i2sbus/i2sbus-core.c
@@ -130,7 +130,10 @@ static int i2sbus_add_dev(struct macio_d
u32 *layout_id;
layout_id = (u32*) get_property(sound, "layout-id", NULL);
if (layout_id) {
+ printk(KERN_INFO "layout id is %d\n", *layout_id);
snprintf(dev->sound.modalias, 32, "sound-layout-%d",
*layout_id);
+ } else {
+ printk(KERN_INFO "no layout id!?\n");
}
}
--
Dag vijandelijk luchtschip de huismeester is dood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: snd-aoa status update / automatic driver loading
Johannes Berg <[EMAIL PROTECTED]> writes:
> On Sat, 2006-05-20 at 00:40 +1000, Paul Collins wrote:
>
>> Here's the dmesg after "modprobe i2sbus":
>>
>> May 20 00:35:51 briny kernel: i2sbus: mapped i2s control registers
>> May 20 00:35:51 briny kernel: i2sbus: control register contents:
>> May 20 00:35:51 briny kernel: i2sbus:fcr0 = 0x0
>> May 20 00:35:51 briny kernel: i2sbus:cell_control = 0x0
>> May 20 00:35:51 briny kernel: i2sbus:fcr2 = 0x4ef1c25
>> May 20 00:35:51 briny kernel: i2sbus:fcr3 = 0x0
>> May 20 00:35:51 briny kernel: i2sbus:clock_control = 0x0
>> May 20 00:35:51 briny kernel: layout id is 51
>
> Did you have the changed modules installed? Otherwise you'd also have to
> manually load snd_aoa_fabric_layout and possibly snd_aoa_codec_tas or
> so. If you had them installed the MODULE_ALIAS("sound-layout-51");
> should have made it load automatically.
Yep, I did make install after the build. And modinfo
/lib/modules/`uname -r`/kernel/sound/aoa/snd-aoa-fabric-layout.ko
shows ones of the aliases as "sound-layout-51".
I did a fresh boot with snd-powermac renamed out of the way, and now I
get even less action: nothing logged in dmesg, and when I unload all
five modules and probe snd-powermac (having renamed it back) I get
May 20 01:08:29 briny kernel: snd: can't request rsrc 0 (Sound Control:
0x8001:80010fff)
Then when I removed snd-powermac and probed i2sbus I got the same
May 20 01:10:00 briny kernel: i2sbus: mapped i2s control registers
May 20 01:10:00 briny kernel: i2sbus: control register contents:
May 20 01:10:00 briny kernel: i2sbus:fcr0 = 0x0
May 20 01:10:00 briny kernel: i2sbus:cell_control = 0x0
May 20 01:10:00 briny kernel: i2sbus:fcr2 = 0xb7f53c
May 20 01:10:00 briny kernel: i2sbus:fcr3 = 0x0
May 20 01:10:00 briny kernel: i2sbus:clock_control = 0x0
May 20 01:10:00 briny kernel: layout id is 51
May 20 01:10:00 briny kernel: i2sbus control destroyed
Probing snd_aoa_fabric_layout and snd_aoa_codec_tas yielded no further
dmesg output and /proc/asounds/cards remains "no soundcards".
--
Dag vijandelijk luchtschip de huismeester is dood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [snd] looking for layout-ids
Johannes Berg <[EMAIL PROTECTED]> writes: > Hey, > > In order to replace snd-powermac for the newer machines where the > 'sound' node has the 'layout-id' property, I'm looking for testers on > machines that have a layout-id [1] property with one of the following > values: 0x24, 0x29, 0x33, 0x50 and 0x3a. 0x33 here. -- Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XFree86 Config on imac g3
Peter Rooney <[EMAIL PROTECTED]> writes: > I can't speak for a keyboard, but I use a three-button scrollwheel USB > mouse on a 7600 oldworld mac. I recall that imacs have USB built in, > which should make it as simple as plugging in the mouse and running > "dpkg-reconfigure xserver-xfree86" to tell it what protocol the mouse > uses. This shouldn't be necessary - Giuilo's X setup uses /dev/input/mice with protocol "auto", so just plugging in the mouse should work. As for keyboards, I've used both PS/2 Happy Hacking keyboard and PS/2 IBM Model M keyboards (with USB converters) on my PowerBook with no problems. I imagine regular USB keyboards will be fine. -- Paul Collins Melbourne, Australia Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The powerpc architecture ubiquitous problem: sound
Eugen Dedu <[EMAIL PROTECTED]> writes: >>> Now, the fun part; every sound begins loud (or should I say at a >>> normal level) and then is almost imediately attenuated, resulting in >>> annoyance and really low volume in general. With dmasound-pmac the >>> volume used to be a lot louder and didn't had this kind of issues. >> >> Sounds like DRC. Disable it or yank up its range with a mixer app. > > I use "alsamixer" to turn off DRC. But each two reboots I need to > turn it off again, because the system reboots with DRC on. Do you > have the same problem? Doing 'alsactl store' with DRC disabled should take care of this -- the alsa packages install hooks and whatnot so that 'alsactl restore' is run at the appropriate times. -- Paul Collins Melbourne, Australia Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
kblevel - set keyboard illumination directly
I've extracted the keyboard illumination code from pbbuttonsd for my
own use. I post it here in case it may be useful to others.
I've tried to preserve PowerBook5,8/5,9 support, but I only have a
PowerBook5,4 here so I can't test it.
Thanks of course are due to Matthias Grimm for writing the original
pbbuttonsd code.
/*
* kblevel.c --- control PowerBook keyboard illumination
*
* Copyright 2002 Matthias Grimm
* Copyright 2006 Paul Collins <[EMAIL PROTECTED]>
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*/
/*
* This code was taken from Matthias Grimm's pbbuttonsd.
* Aside from the gratuitous style changes, I altered the code to read
* the machine type from /proc/device-tree/model insted of
* /proc/cpuinfo and added support for 255 brightness levels.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define ADB_BUFSIZE 32
#define I2C_SLAVE 0x0703
#define LMU_ADDR 0x42
int get_machine(void)
{
char buffer[32];
int machine = 0;
int n;
FILE *f;
if ((f = fopen("/proc/device-tree/model", "r"))) {
while (fgets(buffer, sizeof buffer, f)) {
if (!strncmp("PowerBook", buffer, 9)) {
machine = (atoi(&buffer[9]) & 0xf) << 4;
for (n = 9; buffer[n] != ',' && buffer[n] != '\0'; ++n)
;
if (buffer[n] == ',')
machine |= atoi(&buffer[n+1]) & 0xf;
}
break;
}
}
fclose(f);
return machine;
}
int have_i2c_ambient_sensor(int machine)
{
if ((machine >= 0x51) && (machine <= 0x57))
return 1;
return 0;
}
int have_pmu_ambient_sensor(int machine)
{
if ((machine >= 0x58) && (machine <= 0x59))
return 1;
return 0;
}
/*
* This function tries to find the I2C device that controls the
* keyboard illumination and the ambient light sensor used in some
* AlBooks. It returns an open fd on success, otherwise a negative
* error code. The loop starts with device 4 because that's the
* correct device on 17" AlBooks. Device 0 could be falsely detected
* because the function uses only circumstantial evidence to detect
* the correct device.
*/
int find_i2c_device(void)
{
char i2cdevice[20];
char buf[4];
int n;
int fd;
int rc = -ENODEV;
for(n = 4; n < 260; ++n) {
snprintf(i2cdevice, 19, "/dev/i2c-%d", (n & 255) );
if ((fd = open (i2cdevice, O_RDWR)) >= 0 ) {
if (ioctl (fd, I2C_SLAVE, LMU_ADDR) >= 0)
if (read (fd, buf, 4) == 4)
return fd;
close (fd);
} else if (errno == ENODEV) {
rc = -ENODEV;
break;
} else if (errno == EACCES) {
rc = -EACCES;
break;
}
}
return rc;
}
int send_pmu_request(int fd, unsigned char *buffer, int params, ...)
{
va_list list;
int n;
int x;
if (params < 0 || params > 30)
return -1;
buffer[0] = PMU_PACKET;
va_start(list, params);
for (x = 0; x < params; ++x)
buffer[x + 1] = va_arg(list, int);
va_end(list);
n = write(fd, buffer, x+1);
if ((n != x+1) || (n == -1))
return -1;
if ((n = read(fd, buffer, ADB_BUFSIZE)) < 0)
return -1;
return n;
}
int set_keyboard_illumination(unsigned short level)
{
int machine = get_machine();
unsigned char buf[ADB_BUFSIZE];
int fd;
if (level > 255)
level = 255;
if ((have_i2c_ambient_sensor(machine)) && (fd = find_i2c_device()) > 0) {
buf[0] = 0x01; /* i2c register */
/* The format appears to be:
byte 1 byte 2
|<>| |<>|
7654 3210
|<->|
^-- brightness
*/
buf[1] = level >> 4;
buf[2] = (level & 0x0f) << 4;
write(fd, buf, 3);
close(fd);
return 1;
}
if (have_pmu_ambient_sensor(machine) && (fd = open("/dev/adb", O_RDWR)) > 0) {
send_pmu_request(fd, buf, 4, 0x4f, 0, 0, level);
return 1;
}
return 0;
}
int main(int argc, char *argv[])
{
int level;
if (argc == 2) {
/* Some special string values. */
if ((strcmp(argv[1], "on") == 0) || (strcmp(argv[1], "full") == 0)) {
level = 255;
} else if (strcmp(argv[1], "half") == 0) {
level = 127;
} else if (strcmp(argv[1], "quarter") == 0) {
level = 63;
} else if (strcmp(argv[1], "off") == 0) {
level = 0;
} else {
level = atoi(argv[1]);
}
} else {
fprintf(stderr, "usage: kblevel [ off | half | quarter | full | on | 0-255 ]\n");
exit(EXIT_FAILURE);
}
if (!set_keyboard_illumination(level)) {
fprintf(stderr, "failed to set keyboard illumination\n");
exit(EXIT_FAILURE);
}
exit(EXIT_SUCCESS);
}
--
Paul Collins
Melbourne, Australia
Dag vijandelijk luchtschip de huismeester is dood
Re: Tibook Wireless Card dissapeared
Josh Narins <[EMAIL PROTECTED]> writes: > Is there a way I can just tell the pci subsystem that 0002:24:0f.0 is > actually a perfectly valid wireless card, perhaps? I get such a device listed, as well as my wireless card, here on my AlBook. It's probably just some unrelated Apple weirdness. -- Paul Collins Melbourne, Australia Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kblevel - set keyboard illumination directly
Johannes Berg <[EMAIL PROTECTED]> writes: > On Tue, 2006-06-20 at 01:44 +1000, Paul Collins wrote: >> I've extracted the keyboard illumination code from pbbuttonsd for my >> own use. I post it here in case it may be useful to others. > > Cool. One thing I would want to add is support for finding the address > and bus directly via open firmware instead of that stupid 4..260 loop, > you may look at http://git.sipsolutions.net/of-lib.git/ for a WIP > library to access the device-tree. I was able to use this code to find the lmu-controller node and read the address from 'reg' - looks like it's the value shifted right one bit. (An old posting[1] does it similarly.) But I can't work out how to get the bus number (probed as 8 on my machine). The linked patch tries to use the last bit of 'reg', but that can't be right. [1] http://lists.debian.org/debian-powerpc/2004/01/msg01042.html -- Paul Collins Melbourne, Australia Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kblevel - set keyboard illumination directly
Johannes Berg <[EMAIL PROTECTED]> writes: > Indeed, that can't be right, you'll have to crawl /sys: > > /sys/class/i2c-dev/*/name > > The LMU node on my tree is below [EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL > PROTECTED] > which is the i2c bus named "uni-n 0". (combined from [EMAIL PROTECTED]@0 as > far > as I can tell). Maybe we can convince benh to add a property to the i2c > busses that tell which path they have in the device tree. Ben? It's in my device-tree as [EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] I also have [EMAIL PROTECTED] and [EMAIL PROTECTED] in there, but there's no "uni-n 2" in /sys/class/i2c-dev/*/name, so I guess simply sorting by @foo isn't the way to map to the i2c-dev name attributes. -- Paul Collins Melbourne, Australia Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kblevel - set keyboard illumination directly
Johannes Berg <[EMAIL PROTECTED]> writes:
> On Tue, 2006-06-20 at 18:50 +1000, Paul Collins wrote:
>
>> It's in my device-tree as [EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL
>> PROTECTED]
>> I also have [EMAIL PROTECTED] and [EMAIL PROTECTED] in there, but there's no
>> "uni-n 2"
>> in /sys/class/i2c-dev/*/name, so I guess simply sorting by @foo
>> isn't the way to map to the i2c-dev name attributes.
>
> Yeah, I was wrong, see my other mail.
No worries. I have sysfs-based probing code working now.
> Btw, it's in my device-tree as
> [EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] with
> a compatible
> 'lmu-controller' property.
Does this mean that of_find_node_by_name("lmu-controller", 0) will
return the correct node? I don't know much about device tree stuff.
--
Paul Collins
Melbourne, Australia
Dag vijandelijk luchtschip de huismeester is dood
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kblevel - set keyboard illumination directly
Johannes Berg <[EMAIL PROTECTED]> writes:
> On Tue, 2006-06-20 at 20:23 +1000, Paul Collins wrote:
>
>> > Btw, it's in my device-tree as
>> > [EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]
>> > with a compatible
>> > 'lmu-controller' property.
>>
>> Does this mean that of_find_node_by_name("lmu-controller", 0) will
>> return the correct node? I don't know much about device tree stuff.
>
> No, you'll probably need to do of_find_compatible_node(NULL, NULL,
> "lmu-controller") or something like that, if your compatible property
> includes 'lmu-controller' too.
Hmm, no of_find_compatible_node or anything like it that I can see in
the of-lib I pulled today. And delightfully there doesn't seem to be
any 'compatible' property in my lmu-controller node.
Anyway, here's the current version with the sysfs-guided I2C probing.
/*
* kblevel.c --- control PowerBook keyboard illumination
*
* Copyright 2002 Matthias Grimm
* Copyright 2006 Paul Collins <[EMAIL PROTECTED]>
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*/
/*
* This code was taken from Matthias Grimm's pbbuttonsd.
*
* Aside from the gratuitous style changes, I altered the code to read
* the machine type from /proc/device-tree/model insted of
* /proc/cpuinfo and added support for 255 brightness levels.
*
* We now scan sysfs for likely candidates instead of opening every
* possible i2c device and trying to see if it responds as we expect
* the LMU to.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define ADB_BUFSIZE 32
#define I2C_SLAVE 0x0703
/* TODO: read this from the device tree. */
#define LMU_ADDR 0x42
int get_machine(void)
{
char buffer[32];
int machine = 0;
int n;
FILE *f;
if ((f = fopen("/proc/device-tree/model", "r"))) {
while (fgets(buffer, sizeof buffer, f)) {
if (strncmp("PowerBook", buffer, 9) == 0) {
machine = (atoi(&buffer[9]) & 0xf) << 4;
for (n = 9; buffer[n] != ',' && buffer[n] != '\0'; ++n)
;
if (buffer[n] == ',')
machine |= atoi(&buffer[n+1]) & 0xf;
}
break;
}
}
fclose(f);
return machine;
}
int have_i2c_ambient_sensor(int machine)
{
if ((machine >= 0x51) && (machine <= 0x57))
return 1;
return 0;
}
int have_pmu_ambient_sensor(int machine)
{
if ((machine >= 0x58) && (machine <= 0x59))
return 1;
return 0;
}
/* Guess whether an i2c device is the LMU by trying to read sensor data. */
int lmu_probe(const char *dev)
{
char buf[4];
int fd;
if ((fd = open(dev, O_RDWR)) < 0)
return -1;
if (ioctl(fd, I2C_SLAVE, LMU_ADDR) < 0) {
close(fd);
return -1;
}
if (read (fd, buf, 4) == 4) {
return fd;
} else {
close(fd);
return -1;
}
}
/* Find I2C devices that might be the LMU controller and probe them. */
int find_i2c_device(void)
{
char buf[48];
DIR *d;
struct dirent *de;
int rc = -1;
int fd;
int i;
snprintf(buf, sizeof buf - 1, "/sys/class/i2c-dev");
if (d = opendir(buf)) {
while (de = readdir(d)) {
if (de->d_name[0] == '.')
continue;
snprintf(buf, sizeof buf, "/sys/class/i2c-dev/%s/name", de->d_name);
if ((fd = open(buf, O_RDONLY)) < 0) {
continue;
}
if ((i = read(fd, buf, sizeof buf)) < 0) {
close(fd);
continue;
}
if (i >= sizeof buf) {
close(fd);
continue;
}
buf[i] = '\0';
if (!(strncmp("uni-n ", buf, 6) == 0)) {
close(fd);
continue;
}
snprintf(buf, sizeof buf, "/dev/%s", de->d_name);
if ((rc = lmu_probe(buf)) >= 0) {
close(fd);
goto out;
}
}
}
out:
if (d)
closedir(d);
return rc;
}
int send_pmu_request(int fd, unsigned char *buffer, int params, ...)
{
va_list list;
int n;
int x;
if (params < 0 || params > 30)
return -1;
buffer[0] = PMU_PACKET;
va_start(list, params);
for (x = 0; x < params; ++x)
buffer[x + 1] = va_arg(list, int);
va_end(list);
n = write(fd, buffer, x+1);
if ((n != x+1) || (n == -1))
return -1;
if ((n = read(fd, buffer, ADB_BUFSIZE)) < 0)
return -1;
return n;
}
int set_keyboard_illumination(unsigned short level)
{
int machine = get_machine();
unsigned char buf[ADB_BUFSIZE];
int fd;
if (level > 255)
level = 255;
if ((have_i2c_ambient_sensor(machine)) && (fd = find_i2c_device()) > 0) {
buf[0] = 0x01; /* i2c register */
/* The format appears to be:
byte 1 by
Re: disable appletouch when plugging in mouse
Johannes Berg <[EMAIL PROTECTED]> writes:
> Bah, as nice as the script is, it messes up the appletouch driver
> because the touchpad's values drift over time and if we disable it the
> driver won't know.
You could try opening the evdev and doing an exclusive grab (code
attached). This definitely prevents the events from getting to
/dev/input/mice, but I don't know if it'll stop other fds on the same
evdev from getting them.
/* based on code posted to linux-kernel by Peter Osterlund */
/* pass it a /dev/input/eventN node */
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* From linux/include/linux/input.h */
struct input_event {
struct timeval time;
unsigned short type;
unsigned short code;
unsigned int value;
};
#define EVIOCGRAB _IOW('E', 0x90, int) /* Grab/Release device */
int main(int argc, char* argv[])
{
int fd;
if (argc != 2) {
fprintf(stderr, "no device specified\n");
exit(1);
}
if ((fd = open(argv[1], O_RDONLY)) < 0) {
perror("open");
exit(1);
}
if (ioctl(fd, EVIOCGRAB, 1) < 0) {
perror("ioctl");
exit(1);
}
for (;;) {
struct input_event ev;
read(fd, &ev, sizeof(ev));
}
close(fd);
return 0;
}
--
Paul Collins
Melbourne, Australia
Dag vijandelijk luchtschip de huismeester is dood
