[01:14] lilstevie: any idea what the trick is to make bluetooth work? Specifically, http://paste.ubuntu.com/769608/ [01:17] twb: 1) make sure the bluetooth hcd is in /lib/firmware [01:17] 2) service bsp-tf101 start [01:17] 3) cross your fingers and all extremities that it works properly [01:17] bluetooth is a pita [01:17] and does not always work [01:18] :-( [01:18] oh main thing, make sure BCM4329.hcd is bcm4329.hcd [01:19] reminant of the old method capitalizes it, when it needs to be lower case [01:19] Did that already [01:19] ok [01:19] check if brcm_patchram_plus is running [01:19] bsp-tf101 is configured to start by default, so why wouldn't it have worked already? [01:19] Yes, it's running [01:20] just making sure [01:20] now do you have x? [01:20] atm yes [01:20] but started from xinit, not a dm [01:20] ok look at the bluetooth icon in the systray [01:20] ha ha, systray [01:21] I said I have X not unity :P [01:21] haha :p [01:21] mainly I started X to get keyboard repeat, but it's being funny there too -- which is why I'm trying to get my bt kb working [01:22] ok [01:22] Where "funny" means e.g. I hold Ctrl+p, and it types ^P over and over -- and keeps typing it if I release p, until I also release Ctrl [01:22] well I know I can see the bt stuff from the gnome bluetooth manager [01:23] but I also can from hcitool [01:23] have you rebooted since fixing up the hcd? [01:23] I'll try restarting that bsp thing [01:23] Yeah, definitely restarted since [01:23] that won't really help :/ [01:23] brcm_patchram is a pita [01:23] and I haven't fully set the bsp package to handle restarting [01:24] stop the bsp package [01:24] how? [01:24] make sure brcm_patchram is killed [01:24] Righto [01:24] service bsp-tf101 stop? [01:24] You know I could help yo make that an upstart job if you prefer [01:24] it is brcm_patchram actually that is the problem [01:25] brcm_patchram sometimes needs to be forcefully killed [01:25] in fact those times when you shutdown the system, and it never seems to turn off, but just sit there.... thats brcm_patchram [01:25] :p [01:25] Oh I wondered about that [01:26] When it sits as "killing all processes" ? [01:26] yep [01:26] LAME [01:26] thats it refusing to die [01:26] now, once you have successfully killed the process, hopefully a kill -9 will do it [01:27] you need to rfkill block it [01:27] otherwise you can't reclaim the interface [01:27] Why not put the rfkill in the sto rule? [01:28] thats fine, but I am not comfortable doing a -9 kill in the stop rule [01:28] OK, then I will do it locally :P [01:28] and the rfkill must be done after the kill [01:28] after the kill -15 ? [01:28] yes [01:28] That's fucked up [01:28] otherwise the iface goes into some crazy land of fail [01:29] Is this under the 2.6.38 kernel or the android derived kernel? [01:30] both [01:30] 2.6.38 is a little more forgiving [01:30] but brcm_patchram trashes the interface on being killed [01:30] I would like to redesign it to me more daemonish [01:31] :p [01:31] like something that will accept being asked to release [01:31] rather than being shot in the head [01:31] cause the problem is that you shoot brcm_patchram in the head, and leave its initialized interface behind [01:32] brcm_patchram will not reinitialize an interface [01:32] and an initialized interface will not be reinitialized again [01:32] So this is YOUR code? [01:32] no [01:32] Not some crazy closed thing? [01:32] this is broadcomm code [01:33] but open broadcomm code [01:33] Ah, O [01:33] OK [01:33] Goddamn keyboard [01:34] anyway, after killing brcm_patchram softblocking, and unblocking cause the interface to reset because brcm_patchram wasn't there to hold its hand [01:34] btw is rfill supposed to be unblocked when bsp thingo starts? [01:34] should be yes [01:34] OK that is probably why it isn't working for me [01:34] Because whenever I look it's soft blocked, probably because it does that at boot [01:34] hm [01:35] maybe I put the old version of the init.d script in there then [01:35] it should unblock it on boot [01:35] but the old version didn't [01:35] I've trashd your version now so I can't check :P [01:35] oh lol [01:36] well anyway, brcm_patchram requires the interface be unblocked when it is invoked [01:38] Heh, now I have a dozen brcm_patchram_plus's running [01:39] I might also just patch the halt script to ignore if that proc is still running... === twb` is now known as twb [02:23] lilstevie: after reboot hcitool scan is working [02:23] lilstevie: I think you shipped the unblock-less version of the script [02:24] oops [02:24] sorry :p [02:25] just so you know, the bluetooth is still very hit and miss [02:26] Understood [02:26] just don't get your hopes up [02:27] I have successfully synced my mouse to the bluetooth a grand total of once [02:27] and used it that is [02:27] I have synced the mouse many times [02:28] only once was it usable [02:28] I'm gonna get a fucked up back if I can't get a kb workin [02:28] Still have my old USB one, might use that [02:29] heh [02:29] s/fucked up/more fucked up/ [02:31] lol [02:41] wow bluetooth crashed [02:41] http://paste.ubuntu.com/769642/ [02:43] http://paste.ubuntu.com/769644/ is the init script I'm using -- lilstevie do you think I should be blocking/unblocking only one of the two bt devices? [02:45] shouldn't make a difference [02:46] any word yet about the transformer prime? [02:46] no [02:47] it is not looking good though [02:47] bootloader locked down? [02:47] http://androidroot.mobi/2011/12/13/thoughts-on-android-tablet-security/ [02:47] well we haven't had one in our hands yet [02:47] but the dlupdate shows that this time even the blobs are signed [02:49] lame. [02:49] have to wait for a better tegra3 system to come along, i guess [02:51] bluetoothd[4662]: input/server.c:connect_event_cb() Incoming connection from E8:06:88:52:C7:74 on PSM 17 [02:51] bluetoothd[4662]: input/server.c:connect_event_cb() Incoming connection from E8:06:88:52:C7:74 on PSM 19 [02:51] *** glibc detected *** bluetoothd: free(): invalid next size (fast): 0x2a7e6eb0 *** [02:51] So, uh, bluetoothd is doing a bad free() in oneiric? [02:54] hm [02:59] FWIW, keyboard repeat on tty is fine on an external USB keyboard [02:59] So it must be something in the kb controller [03:00] Feels weird to have a full-width keyboard for the first time in years [03:00] heh I'd believe it [03:01] the EC driver is hacky as shit [03:01] EC? [03:01] event controller [03:02] controlls the keyboard and mouse [03:03] So like evdev [03:04] no [03:04] cause it is hardware [03:04] Righto [03:05] the asusec is the controller for the keyboard and mouse [03:05] Ah, that fucker [03:05] and a few other little things [03:05] Quite often in the previous install it would spew printks so fast I couldn't do anything but hard-reboot [03:07] I was wondering what asusec was for. [03:08] Nice to know. [03:08] the asusec does a little more [03:08] but that is the main thing [03:14] yup [03:15] Does tf101 have a hardware AES module? And if so, does ubuntu leverage it? [03:16] Some of my programs (e.g. mutt) seem to be hanging a lot, and my first guess is they're churning TLS [03:17] Hm, or it could just be that python is really crap [03:17] 10602 twb 20 0 8800 3568 1680 R 2 0.5 0:00.09 python -c import netrc; print netrc.netrc().authenticators('imap.cyber.com.au')[0] [03:17] yes, and not really at this point I guess [03:17] never tried [03:18] but there is hardware aes [03:20] Since bt isn't working atm I'm doing this: update-rc.d bsp-tf101 disable [03:20] So at least I can halt reliably for now [03:20] heh [03:20] fair enough [03:20] the other stuff in the bsp is for CrOS kernel so it wont affect you [03:20] So next week when I come in yelling that it isn't starting, that is why ;-) [03:21] haha ok [04:15] lilstevie: is there a way to detect (programmatically) if the dock is attached? [04:19] I'd assume the extra devices show up in /sys somewhere? [04:20] http://paste.ubuntu.com/769703/ little /etc/cron.hourly/battery job I wrote to get a feel for battery consumption rate [04:20] infinity: unfortunately no, they still appear and if you cat them it complains to all the login ttys [04:20] infinity: so right now I think that cron job will print gank all over my screen occasionally [04:21] (I also have a battery monitor in .screenrc, but that's not logging, so I can't look at the rate-of-change.) [04:24] tegra-i2c tegra-i2c.3: no acknowledge; tps6586x 4-0034: failed reading at 0x20; Failed to set dvfs regulator vdd_cpu; Failed to set regulator vdd_cpu for clock cpu to 1000 mV; cpu-tegra: Failed to set cpu frequency to 1000000 kHz [04:24] ^^ any idea whart those dmesg's are about? It sounds like it's failing to save my battery [04:29] lilstevie: btw why was apmd installed instead of acpid? [04:29] lilstevie: is apmd an OMAPism? [04:30] And more importantly, is suspend-to-RAM working yet? [04:43] there is no acpi on arm [04:43] and no suspend functions do not work [04:43] well more correctly waking up from suspend functions does not work properly [04:52] lilstevie: well, acpi_listen can see hardware keys being pressed [04:52] That's how I'm triggering shutdowns right now [04:52] (re suspend -- OK, thanks.) [04:53] lilstevie: Hrm, suspend is working on the ac100. Perhaps some bits need merging between trees? [04:54] twb: my point is acpi is not really all there for arm [04:54] infinity: no [04:54] infinity: already spoke to ogra et al. with that [04:54] the ac100 used some nvec stuff for it [04:54] we don't use nvec [04:54] Ah. [04:54] lilstevie: OK, hardware-wise I see your point. From a practical perspective, should I uninstall acpid and install something "better"? [04:55] and, the issue with suspend is the framebuffer [04:55] (The goal being to respond to power/volup/voldn and kb media buttons like brightup/brightdn) [04:55] twb: evdev does that :p [04:56] I mean without resorting to gnome-power-manager or kpowerwhatever [04:56] oh i see [04:56] In the x86 world you just install acpid and acpi-support, but for some reason oneiric doesn't even seem to *have* an acpi-support package [04:56] well that is a bit more difficult [04:56] and yes, that is because we don't have acpi tables [04:56] lilstevie: right now acpid is WORKING, which is partly why I'm confused. [04:56] as in, not at all [04:57] we have a kernel maintained device tree [04:57] which will fill in a few of the blanks [04:57] but not enough [04:57] twb@elba[Desktop]$ config.guess ==> armv7l-unknown-linux-gnu [04:57] twb@elba[Desktop]$ acpi_listen ==> video/brightnessup BRTUP 00000086 00000000 [04:57] infinity: anyway, after suspend, the framebuffer keeps getting suspended [04:58] infinity: under CrOS_2.6.38 it is worse :p it doesn't even wake up [04:59] and twb right, there are some standard features which will [05:00] Ah, OK [05:00] Does android actually suspend the tf though when you leave it or press the power button? [05:00] So the kernel is basically faking it [05:00] TheMuso: yes [05:00] Ah ok. [05:00] Very responsive in coming back then. [05:01] TheMuso: the difference is minimal [05:01] sometimes when you wake it up it is instant, that did not go all the way to LP0 [05:01] when there is about 1-1.5sec lag, that is waking up from WB0/LP0 [05:03] ah ok. [05:04] Are they registers or what? [05:04] Hmm, http://www.faqs.org/patents/app/20090204837 ? [05:05] kinda [05:05] PMIC [05:06] which has control registers [05:07] btw, can I use any old mains<-->usb power brick? [05:07] no [05:08] Bugger [05:08] I want a second one to leave in the office rather than carrying it with me every day [05:09] how typical [05:09] trying to debug the suspend issue [05:09] cant trig the damn bug [05:10] actually [05:10] thats a good thing [05:10] lol [05:10] this is the first time I have done it dockless [05:10] THat means something. [05:10] maybe the bug is in the dock resume :p [05:10] Or something USB. [05:10] WHich doesn't surprise me. [05:10] hah [05:11] What interconnect does the dock use anyway? I just kinda assumed it was power + usb [05:11] a very complex interconnect [05:11] plus a few other random pins, of course [05:11] lilstevie: custom asus one, or custom tegra one? [05:11] usb+gpio+power+i2c+i2s [05:12] (As if USB isn't complex enough interconnect on its own :P) [05:12] the keyboard runs off a combination of GPU+i2c [05:13] er [05:13] GPIO [05:13] heh [05:13] Oh wow, I thought the keyboard would be USB. [05:14] the mouse is i2c and i2s [05:14] Even more weird. [05:15] well not really [05:15] mouse as in touchpad? [05:15] it implements a ps/2 like interface over that [05:15] yes [05:15] I guess they wanted to keep the USB free for the USB ports. [05:15] well technically the USB controller is in the dock ;) [05:15] Yeah, another UBhub... [05:15] if I was doing it, I'd have just run the keyboard and touchpad as USB off a UHCI controller in the dock [05:15] usb hub... [05:16] the keyboard is based of nvex [05:16] How many ports can your typical UHCI controller have soldered onto it? Four? Eight? [05:16] nvec* [05:16] gpio is the primary interface [05:17] If it was four you could just have two ports on the dock, plus one for the kb and one for the tp [05:18] TheMuso: can you tack on to that blueprint that I need to reverse the off state for the lid switch [05:18] :p [05:18] and also, right on queue [05:18] lilstevie: What does it have to do with that daemon [05:18] dock+suspend == bad times [05:18] TheMuso: nothing, just it is dock related :p [05:19] lilstevie: Fair enough. You hsould have write access to the whiteboard of the blueprint... [05:19] But I can add it. [05:19] yeah I just CBF :p [05:19] I really should do a kernel blueprint [05:20] Yeah that would be good, I would like to know what you have planned. [05:20] heh :) [05:21] that kinterruptive stuff also is interconnected with the dock :( [05:21] no trace of it in my dmesg, connect dock, bam [05:21] lilstevie: added. [05:21] ta [05:22] ok, so will not suspend with the usb cord plugged in :p [05:24] lol I love it when one gets side tracked from something else because the point of discussion is interesting enough to dig deeper into a problem. :) [05:25] heh :p [05:26] well I have been meaning to dig deeper into suspend [05:26] cause man will that push batt life to extreme levels [05:26] Yep. [05:29] f*** it [05:29] I cant trigger the damn bug again [05:29] this is annoying, it is what happens every time [05:30] heh [05:30] and when i do trigger it, I am nowhere near a computer that will allow me to remote access it and get detailed logs rather than a 500ms flash [05:31] holy crap [05:31] I don't believe it [05:31] I want to run sleepd [05:32] plugging in the usb cable, hooked to the computer stops the bug [05:32] Which basically just does pm-suspend if it hasn't seen keyboard input for ten minutes [05:32] unplug, bang it is back [05:32] Actually I should install it now and just configure it to turn off the backlight [05:32] Since that's like 30% of the power drain [05:33] lilstevie: weird. [05:33] Anyway, gotta run. [05:34] TheMuso: weird is right, plug usb cable in, resume bug goes away [05:34] unplug it, within 30s bug starts back [05:34] later TheMuso [05:41] got it [05:42] TheMuso: when you are around; figured out why it locks when the usb plug is in [05:43] TheMuso: when the usb plug is in it prevents suspend. when unplugged it gets into a suspend/wake loop [05:43] now just need to figure out why wake from suspend goes into a suspend/wake loop [06:28] mplayer says: mplayer: Symbol `ff_codec_bmp_tags' has different size in shared object, consider re-linking [06:29] sudo mplayer http://radio1.internode.on.net:8000/117 ==> mplayer: relocation error: mplayer: symbol __aeabi_f2ulz, version LIBAVCODEC_53 not defined in file libavcodec.so.53 with link time reference [06:30] >sad face< [06:35] Hmm, that's mplayer1 [06:35] * twb tries mplayer2 [06:38] Same issue with mplayer2 [06:42] ok I am kinda getting a little confused [06:42] twb: which releasE? [06:42] also mplayer would be terrible on unaccelerated hw [06:43] there was a compiler issues which had libav emitting extra symbols on oneiric IIRC [06:43] I only want audio [06:43] It's just my scripts are set up to assume mplayer atm [06:43] micahg: this is on oneiric [06:43] ah, mplayer might need a rebuild if it's failing [06:43] I could probably learn xmms2 or something but today ICBF [06:43] ok, so this is what is happening [06:44] lilstevie: won't *all* video be sucky without hw accel -- not just mplayer? [06:44] as soon as the wake lock is removed (by unplugging the usb cable) suspend: sys_sync; suspend: enter suspend [06:44] twb: actually [06:44] all video will be sucky even with acceleration [06:45] Why? [06:45] until you start doing processing on the AVP [06:45] cause tegra sucks ass [06:45] k [06:45] My simple-minded brain reduces that down to "hardware acceleration" [06:46] ok, so basically as soon as every last piece of hw has come back from suspend; it calls back to suspend 0.o [06:46] no idea why [06:46] twb: it is a little more complex than that, the GPU is weak [06:46] to save power duh :P [06:47] twb: yeah but it resumes from the recalled suspend after 0.310sec [06:47] eh I am coming from matrox and intel [06:47] ^^measured by the kernel timer [06:47] twb: no what i mean is the tegra GPU is really weak [06:47] even weaker than an i915? [06:47] unless video gets preprocessed by the AVP [06:47] Wow [06:48] hum, ok [06:48] for mpeg vid [06:48] thats what all those .axf files are in /lib on android [06:48] they are programs for the avp to aid decoding [06:49] presumably that's only useful if you're watching video, tho [06:49] not e.g. playing doom [06:50] yes [06:50] correct [06:50] Righto [06:57] btw for some reason when I rebooted out of android, the caps lock light was on, and it won't turn off [06:57] (Which is a surprise to me; I didn't even know there WAS a light.) [06:57] lol [07:11] micahg: there's this libavcodec-extra-53 that Provides libavcodec53, is it also likely to be buggered? [07:11] twb: idk [07:11] * twb tries [07:13] answer: it does [07:13] Er, "libavcodec-extra-53 is also buggered" [07:16] hm [07:17] http://pastie.org/3014429 [07:18] lilstevie: how do you get that out? netconsole? [07:18] (assume you're still banging against suspend issues.) [07:18] because once you plug in the USB it triggers wake lock [07:19] Ah [07:19] it seems to fully wake up [07:19] then bam out of nowhere suspends again [07:20] Does the suspend key have a down and an up event? [07:20] which is what that portion of the dmesg is [07:20] it isn't that :p [07:20] Maybe it suspends before the up even arrives, so it thinks you're still holding it down [07:20] OK [07:20] I called suspend from the power menu :) [07:20] What happens if you throw away the GUI and call it from /sys ? ;-P [07:21] no idea really :p [07:21] the only way I know to suspend from /sys isn't in the kernel [07:22] Might be /proc I forget [07:25] Something like echo mem > /sys/power/state [07:26] yeah [07:26] And if you cat it it tells you someting like "swap mem" to mean it supports suspend to both disk and ram [07:26] Of course that's JUST suspending, and pm-utils and friends do all sorts of crazy shit in addition to that to work around failtastic hw [07:26] only supports mem [07:27] like halting bt and turning all the LEDs off and rmmoding things [07:27] It wouldn't surprise me in the slightest if one of those things was actually CAUSING the resume problems [07:28] lol [07:28] I will try it [07:28] :) [07:28] just need to call reboot [07:28] I bet you get new and excitingly different problems [07:28] something has to be calling suspend [07:28] Just remember to turn off the GUI and esp. gnome-power-manager first [07:28] heh [07:29] service lightdm stop [07:29] problem solved [07:29] You could just "stop lightdm" [07:32] fwiw identical result [07:32] well surface is identical [07:32] will check out the dmesg in 2 secs [07:33] k [07:38] yep same result [07:39] Aw [07:39] Well at least we know it's not any of the helper code now [07:39]