=== baron1984 is now known as AlmightyCthulhu === baron1984 is now known as AlmightyCthulhu [04:35] well thats an unfortunate blowup regarding foxconn === asac_ is now known as asac [04:49] I'm in contact with Foxconn's Chinese headquarters [04:49] they say that even after applying my ACPI mods, some types of RAM are freezing the kernel [04:49] this does not happen in Windows [05:11] well, i meant more the instant reaction and villification of foxconn [06:02] I just got off the phone with Foxconn [06:02] They called me at 1 AM (here) from China [06:03] and were asking me to help them with Linux support for their BIOS [06:03] heh [06:04] if you feel out of your league, just give them canonical's email [06:04] or url [06:04] they have an OEM vendor cert thing [06:04] http://ubuntu-virginia.ubuntuforums.org/showpost.php?p=5459641&postcount=120 [06:05] baron1984: ^ was that a joke? [06:06] no [06:06] they actually called me [06:06] from Shenzen, China [06:06] the other part [06:06] teh s3kr3t me55ag3 [06:06] the part about them sending me a fixed BIOS ROM? [06:06] oh, hehehehe [06:06] yeah [06:06] that was a joke [06:07] sorry, that thread is just so chock full of accusations, vitrol and hate that I can't take anything at face value =( [06:07] it seems very un Ubuntu what transpired there [06:08] what, they gave out a sabotaged BIOS [06:08] when they get massively and publicly called out on it [06:08] its not very collaborative, productive or respectful [06:08] they go from buy vista screw yourself, to "how can we help?" [06:08] granted, they might not have treated you with respect [06:09] i think you would have been better off writing an open letter to the acpi folks === baron1984 is now known as AlmightyCthulhu [06:10] it's not Intel's fault [06:10] intel doesnt run acpi [06:10] and acpi owns the acpi trademarks [06:10] they have a reference implementation of how ACPI should work [06:10] and a compiler that validly compiles the BIOS code [06:10] if someone's claiming "acpi compliance" ACPI probably had a hand involved in it [06:11] so why are they passing the completely busted and incorrect Linux table [06:11] when even Vista's works better? [06:11] for the same reason we ship busted software in 8.04 [06:11] they never had any intention to fix it [06:12] shit happens, and what isn't a priority slips through the cracks [06:12] and wouldn't have, unless it broke Vista or XP [06:12] clearly they had no intention, but it seems unfair to accuse them of fraud [06:13] in any event [06:13] they admitted it was an invalid implementation [06:13] written by unskilled programmers [06:13] (well duh) [06:13] which makes it non compliant, even if it wasn't their intention [06:14] do you know who the acpi sig secretary is? [06:14] probably Microsoft [06:14] bingo [06:15] probably signs off on bad BIOS implementations [06:15] just to bite Linux users [06:15] at any rate, mjg59 thinks the point is moot since newer kernels masquerade as windows [06:15] then my mod shouldn't do anything [06:15] you two might talk [06:16] but it does [06:16] newer kernels [06:16] what are you using? [06:16] 2.6.26? [06:16] :P [06:16] Linux ryan-desktop 2.6.26-4-generic #1 SMP Mon Jul 14 18:39:36 UTC 2008 x86_64 GNU/Linux [06:17] http://mjg59.livejournal.com/94560.html contains comments from some fairly influential and intelligent people [06:18] you two might talk and compare notes. its part of the CoC after all ;) [06:19] at any rate, im goin to bed, what i know about dsdt and acpi wouldn't amount to a plate of beans [06:22] oh, and I'd love to see a way of keeping up to date on progress via this. now that you brought it up and made it a huge deal, it would be terrible to see it wasted =( [06:22] ubuntu-kernel has a fairly low volume ML that might be appropriate, I donno. === gnomefre1k is now known as gnomefreak === gnomefre1k is now known as gnomefreak === gnomefre1k is now known as gnomefreak === gnomefre1k is now known as gnomefreak === gnomefre1k is now known as gnomefreak === gnomefre1k is now known as gnomefreak [17:30] i'm getting a kernel oops on ubuntu 7.04. i have set up kdump and crash so i'm able to see where the error occurred... appears to be in line 717 of skbuff.h (skb_dequeue which is inlined into process_backlog) anyone have suggestions where i could start on figuring out what could be going wrong? the machine it crashes on just sits on my network at the office === ceeka1 is now known as seekay === Daviey_ is now known as Daviey [19:01] BenC: ping 3945B :-) [19:27] Nafallo: yes, was there a fix? [19:27] Nafallo: I don't really have a test rig [19:28] BenC: ah. should I look for someone that has one or just go with the obscurity of my findings this far in a bugreport? :-) [19:29] Nafallo: I have a 3945 card, just no B network to connect to [19:29] yea. same here at the moment :-) [19:31] hmm... I should try setting my linksys in B only mode... [19:31] not now though. I need my internets :-) [19:40] :q === doko_ is now known as doko [21:07] hi guys [21:11] i have a fujitsu u810 umpc. everything works great but this thing has a set of keyboard led lights id like to learn how toturn off or on. i guess ill haveto blearn how to write drivers. what sorts of techniques should i be looking at when trying to discover how these leds afre turned on? [21:12] lspci doesnt szeem to show anything that looks like it controls the leds [21:26] arent keyboard leds kinda controlled by the keyboard? [21:27] i dont think you'd need a PCI slot for that [21:27] not this one, i think its driver controlled but i didnt get windows with it to check [21:27] well theres still a driver [21:27] its just not PCI [21:27] its two leds on a ledge above the kb starngely [21:28] and i dont see a switch for them ... everything is in japanese [21:28] heh [21:28] there's a kernel LED module i think [21:28] clever [21:28] oh! [21:29] im not sure what it controls, or if its sort of a generic interface for all things that have leds [21:29] at any rate, there's also Xkb [21:29] aha, googling [22:31] holycow: usually things like that hang off the parallel port IO range (or similar IO ranges) [22:32] and they are usually poorly documented, requiring IO sniffing in windows to reverse engineer [22:32] or decompiling the windows driver to find out the write/read combos used to control it [22:32] aha! [22:33] holycow: is this keyboard on a USB bus? [22:33] if so, not integrating the led's is a very poor design :) [22:33] lol i dont know, im just starting my journey [22:33] holycow: lsusb is a complimantary tool that might help answer that without logic analyzers and taking the device apart ;) [22:34] actually i doubt it [22:34] you'd be surprised [22:34] oh right forgot about that [22:34] sometimes the quest to reduce costs means integrating several functions into a single chip / bus [22:34] even though its more expensive [22:35] pwnguin: I'd be surprised if they hung keyboard led's off a usb bus and not have them hardware integrated into the keyboard itself [22:35] true [22:37] actually, I'm surprised they aren't already [22:37] i have a touch screen and a finger scanner on the usb bus [22:37] holycow: are these caps/num lock led's or something else? [22:38] no led controller of any kind ... makes sense [22:38] oh something elese [22:38] they are additional leds on little raisers to light the kb at night [22:38] its a umpc fujitsu u810 [22:38] oh, keyboard backlight [22:39] thats it! [22:39] most likely low level IO type things [22:39] that sounds right [22:40] your original suggestion is probable the right approach [22:40] under windows does it change the keyboard backlight based on ambient lighting in the room? [22:40] or is it manual control? [22:40] manual [22:42] might be good to email fujitsu to see if they are willing to cough up specs [22:42] fgqrtyu-= [22:42] oops sorry [22:43] BenC: indeedy, will do [22:43] BenC: i saw your talk on hardware whoring [22:43] thx for the heads up [22:43] pwnguin: hehe [22:44] i thought it was kinda wierd, because it didnt mention how developers can get in touch with the right people [22:44] damn innanet [22:44] it was basically all "when vendors call you" [22:44] pwnguin: I've never had to go that route [22:45] pwnguin: and doing so is usually different (and difficult) depending on the company you are talking about [22:45] apparently if you call the FTC and claim they're committing fraud they get you in touch with people [22:45] pwnguin: good starting points are linux-kernel@vger.kernel.org archives to find out if an engineer from that company has already come out [22:46] and similar places...websites are good places too, but always hard to find something other than customer support [22:46] i guess what i'm saying is it might be a good idea to give people ideas on constructively contacting the right people [22:46] but thanks for the tips [22:46] true, but it wasn't an area where I had experience, so I neglected to mention anything :) [22:47] if you're invited to give the talk again, i might suggest pointing out the deficiency as a way of starting a dialog at the end of the talk :) [22:47] slowly windowsonly hardware is starting to lessen tho [22:48] pwnguin: good idea, thanks for the feedback [22:48] sure [22:48] hopefully vendors will buildintotheirproduct cycles better community interaction [22:48] doubtful [22:48] product cycles dont fit into neat six month releases [22:49] well i dont meant ubuntu community specifically, just thinking more generically [22:49] intel hired some smart people to deal with that, but i think we'll quickly see a "peak keithp" similar to "peak oil" [22:50] heh [22:52] bbl low on battery powr [22:52] thx for the help btw [22:52] BenC: is there a better resource for toshiba than that website? [22:59] holycow: np [22:59] pwnguin: Don't know off hand