Re: off topic - Apple service sucks
im pretty sure you sign on that condition when you put it in for service. fortunately the few times ive used apple service they havent wiped my machine, but i dont dual boot. I _do_ dual boot, and the Apple that replaced my display did not alter anything on the machine. I had set it up to boot MacOS first, with autologin enabled, so that may have something to do with it. IIRC they promise to wipe the drive when you don't clear the password or use autologin. IOW: it all depends on the store. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i daily build fails when building initrd (PowerMac7,3)
On Mon, Mar 27, 2006 at 02:20:11AM +0200, Frans Pop wrote: There is no problem with initramfs-tools, just a problem with the maintainer of the ppc port who is too quick to jump to conclusions again. Since the debian-installer team clearly stated that debian would be better off without me, and that i was not irreplacable, i am now very curious who you are speaking about :) I have not yet disabled the powerpc daily-builds, but there are enough people who received a pegasos machine donated, including members of the debian-installer team, and will be able to take this over soon i hope. I thought someone mentioned 'cooling off' or some such. Color me confused. If the d-i team does not get their act together WRT daily builds, I can offer to set up a 233 MHz G3 with accounts for d-i. Ditto for someone to build kernels. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu
Hi Michael, On Sat, 25 Mar 2006 16:55:21 +0100 (CET), Michael Schmitz [EMAIL PROTECTED] said: I am now getting button 2 and button 3 events sent, but the modifiers are getting sent too. That's per design, and was done to fix bug #304328. Maybe the fix broke your case, though. After some consideration, I believe that that this new behaviour, where the modifier is sent as well as the emulated mouse button, is the cleanest and most X-like way of doing it. Remove the patch to pass though modifier events, then. Or at least block the modifer events that were used to generate the mouse events (see below). You lose the option to generate mouse events with modifers (but then, you cannot distinguish between a mouse event with and without modifier anyway, if you chose to use a modifier with the mouse keycode). I looked at the mouseemu source code, and spent some time reading various X documentation. Based on my limited understanding of X, it seems there is no clean way of mulitplexing modifier keys to fulfil both tasks (mouse button emulation, but normal modifier behviour for other keypresses). I imagine that these issues are already well-known. Later on today I will have at look at the behaviour of Apple X11, and check out what events it is generating. First of all, don't use modifier keys tha you need to see in other apps with mouse emulation. Second, you can change the passthrough code to only pass a modifier event if it does not belong to a emulation key - this will get quite messy though. You'll need to delay the modifier for a short time to see if a mouse key follows (or send a modifier up, mouse button, modifier down sequence). I think that out of all the workarounds, the suggestion to send a modifier up, mouse button down sequence would be the best. But still, like you suggest, it will get quite messy. I can imagine a few cases in which this will lead to confusing and unintended behaviours. Thank you, Michael, you for all your help and advice. -- http://www.fastmail.fm - Email service worth paying for. Try it for free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mouseemu
I am now getting button 2 and button 3 events sent, but the modifiers are getting sent too. That's per design, and was done to fix bug #304328. Maybe the fix broke your case, though. After some consideration, I believe that that this new behaviour, where the modifier is sent as well as the emulated mouse button, is the cleanest and most X-like way of doing it. Yep; I've had a closer look and there's little chance to do it any other way. I looked at the mouseemu source code, and spent some time reading various X documentation. Based on my limited understanding of X, it seems there is no clean way of mulitplexing modifier keys to fulfil both tasks (mouse button emulation, but normal modifier behviour for other keypresses). I imagine that these issues are already well-known. The state of the modifier key is kept by the X server, so you need to send the modifier before you send a regular key event (disregarding mouse events for a moment here). We could postpone the modifier event until we know what other event follows, but that's equally messy. Later on today I will have at look at the behaviour of Apple X11, and check out what events it is generating. Right, they must have solved this some way already. I think that out of all the workarounds, the suggestion to send a modifier up, mouse button down sequence would be the best. But still, like you suggest, it will get quite messy. I can imagine a few cases in which this will lead to confusing and unintended behaviours. Should not really happen, because mouseemu intercepts all input events hopefully, and hence can ensure they get sent in the correct order. Meaning you cannot sneak a key event in between the mod up, mouse down, mod down sequence. IIRC X doesn't mind if the modifier state changes while a button is kept down. Either way, there's limits to what extent you can emulate mouse buttons using modifier keys. I'll cook up some experimental hack for you to test. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i daily build fails when building initrd (PowerMac7,3)
On Mon, Mar 27, 2006 at 10:16:12AM +0200, Michael Schmitz wrote: On Mon, Mar 27, 2006 at 02:20:11AM +0200, Frans Pop wrote: There is no problem with initramfs-tools, just a problem with the maintainer of the ppc port who is too quick to jump to conclusions again. Since the debian-installer team clearly stated that debian would be better off without me, and that i was not irreplacable, i am now very curious who you are speaking about :) I have not yet disabled the powerpc daily-builds, but there are enough people who received a pegasos machine donated, including members of the debian-installer team, and will be able to take this over soon i hope. I thought someone mentioned 'cooling off' or some such. Color me confused. Sorry, but i am in a personal dire situation, caring for my mother who has generalized cancer, and posts like franzes above are certainly not easy when you try to cool off. If the d-i team does not get their act together WRT daily builds, I can offer to set up a 233 MHz G3 with accounts for d-i. Ditto for someone to build kernels. The real problem is not the machine, they can even use an account on the IBM donated quad-power5 at augsbourg if needed. The real issue is that there is something wrong with how the d-i team thinks. On one part they bashed on me over the expulsion process, and frans was quite un-comprehending and caustic, but on the other hand they still think of me as the ppc porter, and expect me to know all, be well informed before posting, and fix the daily builds that occasionally get broken by other parts of the daily builds. I am not in an emotional state right now to do any kidn of fixing, and am more worried about finding an oxygen thank in the miami airport for thursday afternoon than any kind of debian work. This may change in the future, but i will probably not want to take over the d-i porter job again (unless asked very nicely by the d-i team maybe) in any case, and will probably concentrate on other parts of debian or something. In any case, i think it is best for debian and the etch release process that someone else takes the d-i powerpc porter hat for some time now. I can keep the daily build up, and since it syncs daily from the svn, everyone else can fix stuff there, since it is from there that it gets broken anyway :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i daily build fails when building initrd (PowerMac7,3)
If the d-i team does not get their act together WRT daily builds, I can offer to set up a 233 MHz G3 with accounts for d-i. Ditto for someone to build kernels. The real problem is not the machine, they can even use an account on the IBM donated quad-power5 at augsbourg if needed. The real issue is that there is something wrong with how the d-i team thinks. On one part they bashed on me over the expulsion process, and frans was quite un-comprehending and caustic, but on the other hand they still think of me as the ppc porter, and expect me to know all, be well informed before posting, and fix the daily builds that occasionally get broken by other parts of the daily builds. Well, nice to hear it's not the hardware that's holding things up. Now we just need to find someone to volunteer to take over from you. Anyone? Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to debug kernel Oops
On 3/26/06, Michael Schmitz [EMAIL PROTECTED] wrote: Unable to handele kernel paging request for data at address 0x0008 Faulting instruction address:0xe2709440 Oops : kernel acces of bad area, sig 11 [#1] ... ... NIP [E2709440] ieee80211_master_star_xmit+0x6c/0x4bc [80211] LR [E2709400] ieee80211_master_star_xmit+0x2c/0x4bc [80211] Call Trace : ... ... --- How to find the problem and solve it ? Part 1: Disassemble the ieee80211_master_star_xmit function (locate the start address in the module from the symbol table, and use objdump -d), and compare with the C code. That should tell you what NULL pointer you need to deal with here. Part 2: figure out how a NULL pointer got passed in the first place. Thank you very much. This exceeds my competences. I do not know programming, I give up. Best regards, Bin Michael
Re: sound on quad powermac/latest powerbooks/imacs
Hi, I've been rewriting the linux apple sound driver completely with a much nicer layout :) It isn't really to be used too widely now but if anyone is motivated to help hacking there are some things that need sorting out and I'd certainly appreciate help :) I cannot offer help coding, but if you have something I can try on PowerMac 8,2 I can test it and report back to you. Eduardo. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sound on quad powermac/latest powerbooks/imacs
On 3/25/06, Johannes Berg [EMAIL PROTECTED] wrote: On Fri, 2006-03-24 at 16:26 +0200, Eddy Petrişor wrote: So one could add now a codec over the lower layers? That's the plan, yes. AFAICS my laptop* needs snapper[1]; I found it strinking that the powerbook in question (5,2) hasn't mic support. There is also an external mic input besides the internal mic (I know as I have used it in MacOSX). that's a tas3001 right? Or tas3004? I have the datasheet for the latter and need tas3004 on my powerbook. I will not able to answer to this exactly for a few days.. will answer until the end of the week. Please remind me if I don't answer until next Monday. Does the current experimental implementation support input? No. A smaller rewrite of the clock/pcm/bitrate stuff is on order, after that it will. Ok, nice. When will that be ? :-D -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: sound on quad powermac/latest powerbooks/imacs
On Mon, Mar 27, 2006 at 04:51:09PM +0200, Eduardo Trápani wrote : Hi, I've been rewriting the linux apple sound driver completely with a much nicer layout :) It isn't really to be used too widely now but if anyone is motivated to help hacking there are some things that need sorting out and I'd certainly appreciate help :) I cannot offer help coding, but if you have something I can try on PowerMac 8,2 I can test it and report back to you. Same for 8,1. Actually, if you could share the patched sources of a kernel, that would be great (I am affraid I know nothing to this git thing). Regards, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Qemu and GCC-3.4 on powerpc
Hello,
the version 0.8.0 of qemu in the Debian-pool will not compile on
PowerPC with GCC 3.4. The following patch will fix it:
--- cpu-all.h~ 2005-12-19 23:51:53.0 +0100
+++ cpu-all.h 2006-03-27 22:47:54.291613000 +0200
@@ -249,15 +249,11 @@
static inline void stl_le_p(void *ptr, int v)
{
-#ifdef __powerpc__
-__asm__ __volatile__ (stwbrx %1,0,%2 : =m (*(uint32_t *)ptr) : r
(v), r (ptr));
-#else
uint8_t *p = ptr;
p[0] = v;
p[1] = v 8;
p[2] = v 16;
p[3] = v 24;
-#endif
}
static inline void stq_le_p(void *ptr, uint64_t v)
If I use GCC 3.3, then qemu compiles with the assembler instruction in
the patch above, but qemu does not work correctly (tested with Knoppix V5.0).
If I try to compile qemu with GCC 3.4 without the patch I get the following
error:
qemu-0.8.0/linux-user/elfload.c: In function `load_elf_binary':
qemu-0.8.0/cpu-all.h:253: error: inconsistent operand constraints in an `asm'
qemu-0.8.0/cpu-all.h:253: error: inconsistent operand constraints in an `asm'
But if I copy the function stl_le_p to a seperate file, the function
will compile with GCC 3.4.
Is this a bug in qemu, or is it a bug in GCC 3.4?
Greetings,
Dieter Schuster
--
GnuPG Key-ID: 1024D/5EE6EF26, bitte verschlüsselte E-Post; keine HTML-Post.
Keine Logik-/Softwarepatente. Pas de Brevets Logique/Logiciels.
No Logic/Software Patents.
pgpTwrrHv183A.pgp
Description: PGP signature
