--- Log for 20.08.114 Server: verne.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 23 hours and 55 minutes ago 00.07.40 Join Scall [0] (~chat@unaffiliated/scall) 00.10.17 Quit efyx_ (Ping timeout: 255 seconds) 00.10.34 Quit efyx__ (Ping timeout: 244 seconds) 00.12.22 *** Saving seen data "./dancer.seen" 00.12.40 Quit pystar89 (Ping timeout: 246 seconds) 00.13.25 Join TheGuyWhoIsTheGu [0] (~androirc@modemcable045.77-163-184.mc.videotron.ca) 00.13.28 Quit ender` (Quit: We're not lost. We're locationally challenged. -- John M. Ford) 00.18.02 Join Guest81512 [0] (Slayer@c-69-143-187-144.hsd1.va.comcast.net) 00.18.02 Quit Guest50306 (Read error: Connection reset by peer) 00.23.22 Quit TheGuyWhoIsTheGu (Read error: Connection reset by peer) 00.23.24 Quit Guest81512 (Read error: Connection reset by peer) 00.23.59 Join Guest50306 [0] (Slayer@c-69-143-187-144.hsd1.va.comcast.net) 00.29.51 Join efyx_ [0] (~efyx@219.146-67-87.adsl-dyn.isp.belgacom.be) 00.30.07 Join efyx__ [0] (~efyx@219.146-67-87.adsl-dyn.isp.belgacom.be) 00.38.14 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 32.0/20140814150857]) 01.11.54 Join franklin [0] (~franklin@cpe-071-071-071-105.triad.res.rr.com) 01.14.29 Nick SuperBrainAK is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) 01.34.54 # TheSeven, any news on the timer bug? 01.36.11 Quit efyx__ (Ping timeout: 246 seconds) 01.36.11 Quit efyx_ (Ping timeout: 246 seconds) 01.36.46 Join efyx_ [0] (~efyx@219.146-67-87.adsl-dyn.isp.belgacom.be) 01.36.48 Join efyx__ [0] (~efyx@219.146-67-87.adsl-dyn.isp.belgacom.be) 01.39.39 Nick DormantBrain is now known as SuperBrainAK (~andy@2001:470:8:a61::5f92:59a1) 01.50.48 Quit shamus (Ping timeout: 244 seconds) 01.51.09 Join shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) 02.02.29 # How can I get the USB HID feature working on ipod classic? defining ENABLE_USB_HID adds the interface, but no functionality 02.03.57 # <[Saint]> Are you surprised it wasn't disabled entirely arbitrarily? 02.04.07 # <[Saint]> It wasn't enabled for a reason. ;) 02.11.22 Join pystar89 [0] (~pystar89@ip-176-199-76-43.hsi06.unitymediagroup.de) 02.12.25 *** Saving seen data "./dancer.seen" 02.12.33 # [Saint], what was that reason? 02.12.55 # <[Saint]> ...it doesn't work, perhaps? Duh. 02.13.03 # Why doesn't it work? :) 02.13.13 # <[Saint]> Fucked if I know. 02.13.52 # VID/PID? 02.14.43 Quit bcobco () 02.15.01 # <[Saint]> I...what? Just, no. No. 02.15.14 # <[Saint]> Man, the questions you ask sometimes... 02.17.44 # Do you think gevaerts would know? 02.17.58 # It seems like he did a lot of work on the USB stack... 02.18.32 # <[Saint]> I think if you were to ask him he'd get very pissed about it...why not try it out? 02.18.55 # Well, he's away now... "asleep" 02.18.57 # <[Saint]> (we both know he's not been happy about you singling him out for random arbitrary requests over the past weeks) 02.19.10 # hehe... 02.19.17 # <[Saint]> Its not funny. At all. 02.19.35 # Ok then... does anyone else know /anything/ about the USB stack? 02.24.05 # But seriously, the only major USB changes have been contributed by him and pamaury 02.26.38 # And TheSeven did some major work on the S5L USB driver, too 02.28.27 # And Rafael Carre made about a million commits for USB, too :) 02.29.49 # <[Saint]> Just fix what you can and leave the things that are quite obviously over your head for someone else. 02.35.22 # where do I start? there's no USB code in firmware/targets/arm/s5l8702 02.35.38 # In the s5l8700 dir? 02.36.08 # never mind... the usb driver in s5l8700 is for nano2g and 6g 02.38.28 # w00t there's a datasheet!!! :D 02.39.31 Quit Cinos (Ping timeout: 240 seconds) 02.42.05 # Is the s3c6400x a USB controller or a SoC? Is there one in the Classic? 02.43.09 Join Cinos [0] (Cinos@cinos.biz) 02.44.28 # <[Saint]> And you wanted to port the Linux kernel to this thing. 02.44.31 # <[Saint]> ...wow. 02.44.56 # I have no tools to take it apart with... broke :) 02.45.01 # (I am) 02.45.19 # <[Saint]> If you think you need to you're quite highly confused. 02.45.30 # <[Saint]> Dude, just fix the things you can. 02.45.37 # Like??? 02.45.37 # <[Saint]> You're jumping in WAY over your head. 02.45.57 # And I pop right out... buoyancy! 02.46.01 # <[Saint]> I have no idea what you're capable of. Apparently neither do you. 02.46.27 # I've written TONS of low-level code... just very little for ARM 02.48.12 # It'd be real nice if half the links on the FreeMyIpod wiki worked :) 02.49.04 # <[Saint]> Its a wiki. 02.49.12 # <[Saint]> DOn't like it, fix it. 02.50.56 # Well, anyhow, I am assuming that's the chip in there that's running USB and the coprocessor 02.51.06 # * franklin pings TheSeven 02.51.11 Join cmhobbs [0] (~cmhobbs@ip98-186-66-92.fv.ks.cox.net) 02.51.20 Quit cmhobbs (Changing host) 02.51.20 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 02.56.04 # Hey cmhobbs 02.57.18 # TheSeven, is the S3C6400X the coprocessor? 03.00.04 Quit AlexP (Read error: Connection reset by peer) 03.02.46 Quit krabador (Quit: Take the time.) 03.04.56 Join krabador [0] (~krabador@unaffiliated/krabador) 03.05.35 Quit RiD (Ping timeout: 245 seconds) 03.11.17 Join RiD [0] (~RiD@2.83.12.42) 03.12.18 Quit cmhobbs (Ping timeout: 260 seconds) 03.22.00 # Does USB HID work on the nano2g? 03.22.35 Quit ZincAlloy (Quit: Leaving.) 03.23.14 # Hmm... nope 03.23.27 # What does HAVE_USB_HID_MOUSE do? 03.30.07 Quit the-kyle (Remote host closed the connection) 03.32.52 Join the-kyle [0] (~kyle@kyle.tk) 03.40.59 Quit the-kyle (Remote host closed the connection) 03.43.44 Join the-kyle [0] (~kyle@kyle.tk) 03.54.03 Quit krabador (Quit: Take the time.) 03.54.30 # saratoga, I broke G#904 into G#919 and G#920 now 03.54.36 # 3Gerrit review #904 at http://gerrit.rockbox.org/r/904 : 3Improved iPod CHIP8 keymaps and fixed a bug that prevented it from working by Franklin Wei 03.54.36 # 3Gerrit review #919 at http://gerrit.rockbox.org/r/919 : 3Fixed a chip8 bug by Franklin Wei 03.54.37 # 3Gerrit review #920 at http://gerrit.rockbox.org/r/920 : 3Improved CHIP8 iPod keymaps by Franklin Wei 03.54.48 # * franklin slaps fs-bluebot for spamming :) 03.54.49 # franklin: ouch! 03.56.10 Join jhMikeS [0] (~jethead71@c-68-43-2-35.hsd1.mi.comcast.net) 03.56.20 Quit jhMikeS (Changing host) 03.56.20 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 03.57.01 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 03.57.25 # franklin, a late hello :D 03.58.35 # so, cmhobbs, have you tried plugin-writing yet? 04.02.03 # unfortunately not 04.02.05 # i haven't had time 04.02.10 # i'm on holiday with my family this weekend though 04.02.15 # i hope to roll up my sleeves and get into it 04.02.27 # i'll have two devices there because my dad's got one as well 04.02.42 # some of the plugins are terrible examples, they probably haven't been updated in years 04.03.05 # So I'd humbly say that 2048 is probably the best example of plugin structure in there 04.05.37 # There are so many HZ assumptions in the plugins, especially in the DOOM code 04.12.27 *** Saving seen data "./dancer.seen" 04.17.11 Quit amiconn (Disconnected by services) 04.17.11 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.17.11 Quit pixelma (Disconnected by services) 04.17.11 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.17.14 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.17.14 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.23.05 # [Saint]: I just saw the dump you posted, thanks. It looks like a bunch of startups. 04.32.07 # i'll take a look at it for sure 04.32.36 # Well, have fun :) 04.37.52 # jhMikeS: ploco posted a patch which fixed it 04.40.10 Quit franklin (Remote host closed the connection) 04.43.33 # where's that 04.44.29 # g#894 04.44.30 # 3Gerrit review #894 at http://gerrit.rockbox.org/r/894 : 3RaaA: Android work around the Kitkat ART crashes by Chiwen Chang 04.45.13 # so it's actually related to that? 04.45.34 # dunno, didnt look at the diff, just tried it and it works 04.45.37 # so yeah maybe 04.45.50 # need someone on an old android to try master 04.46.33 # the pc is obviously garbage when it crashes 04.48.13 # I tried to set that up but it's giving me a headache with the tool crashing when trying to make the apk, no matter the version 04.55.24 # If it were directly in the changed code, I would expect every target to die at boot but that's not the case obviously. 05.05.33 Quit jhMikeS (Ping timeout: 240 seconds) 05.11.28 Quit ender| (Read error: Connection reset by peer) 05.11.29 Quit RiD (Quit: A good plan today is better than a perfect plan tomorrow.) 05.11.50 Join ender| [0] (krneki@2a01:260:4094:1:42:42:42:42) 05.14.35 Quit steffengy (Disconnected by services) 05.14.36 Join steffengy1 [0] (~quassel@p5088FDCB.dip0.t-ipconnect.de) 05.54.12 Quit TheSeven (Ping timeout: 250 seconds) 05.55.38 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.01.13 Join jhMikeS [0] (~jethead71@c-68-43-2-35.hsd1.mi.comcast.net) 06.01.21 Quit jhMikeS (Changing host) 06.01.21 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 06.12.29 *** Saving seen data "./dancer.seen" 06.17.25 # <[Saint]> jhMikeS: JdGordon: didn't you see how aggressive that patch is? 06.17.37 # <[Saint]> Oops - double highlight. 06.17.41 # I didnt look at the details 06.17.54 # <[Saint]> There's no way it'd be accepted 06.18.13 # <[Saint]> Also - neither of us are using ART. ;) 06.19.12 # but it does point to some other sort of issue 06.19.43 # <[Saint]> Let me start my shit up and I'll get you the android build requiremnets 06.21.22 # if that patch fixes that crash then it's not really in what I did itself but some side effect (a side effect that should not exist in the design itself) 06.22.14 # somewhere it ends up loading a messed up jump buffer since that PC value is obvious nonsense 06.24.00 # <[Saint]> Okies: 06.24.58 # <[Saint]> Android SDK Tools, Android NDK Platform-tools, Android SDK Build-tools 19.1, SDK Platform 19 06.26.02 # that's what I got in place but aapt dies with "illegal instruction" 06.26.18 # <[Saint]> hmmm 06.27.14 Quit cmhobbs (Ping timeout: 244 seconds) 06.27.46 # granted my vm is sort of ancient 06.27.47 # <[Saint]> just updating my SDK tools and NDK platform tools now to see if that's it. 06.28.46 # the kernel 2.6.26 lenny (hell if I want to upgrad that crap again right now if not strictly necessary) 06.29.04 # <[Saint]> holy... 06.30.59 # 2.6.26-1-686 06.31.39 # <[Saint]> hmmmm...actually. I just updated and it spat an error about missing zipalign 06.31.50 # <[Saint]> seems like paths may have been juggled around. 06.31.54 # <[Saint]> gah. 06.32.49 # <[Saint]> Ahhhh....also need build-tools rev. 20 06.32.51 # I got me a zipalign 06.33.16 # I just grabbed revision 19 off android sdk 06.33.28 # tried 20 as well with no difference 06.34.37 # <[Saint]> sec - still chasing changed requirements. 06.35.12 # I was piecing it together it wanted 19 and 19.1.0 for this stuff 06.36.31 # I got ndk 10 and it only goes to 19 06.37.02 # <[Saint]> looks like android moved some shit around. bah. 06.41.42 # the automatic build spits out some warnings that aren't shown in the table 06.42.03 # actually errors 06.43.25 # <[Saint]> ok - I can build with current toolset using the versions given above 06.43.53 # <[Saint]> just needed to make a simlink for zilalign from build-tools to tools 06.44.00 # <[Saint]> *zipalign 06.45.35 # <[Saint]> That is, for the record: 06.46.20 # <[Saint]> Android SDk Tools 23.0.2, Android SDK Platform-tools 20, Android SDK Build-tools 19.1, and SDK Platform 19 06.46.28 # [Saint]: explain why that patch is "aggressive". I don't know that part of things enough to know what's going on there. 06.46.46 # <[Saint]> its coring out the entire battery metering system 06.46.59 # <[Saint]> granted the host can do this itself..but 06.47.09 # meaning? 06.47.22 # <[Saint]> meaning, we'll never be able to display the battery ststus 06.47.29 # <[Saint]> *status 06.48.16 Join ploco [0] (dce9b7f9@gateway/web/freenode/ip.220.233.183.249) 06.48.20 # ah 06.48.58 # <[Saint]> Oh - and, for the record, openjdk7 rdk/jre 06.49.13 # <[Saint]> (and a 64 bit multiarch system ofc) 06.49.26 # <[Saint]> *jdk/jre 06.49.28 # wait, if that patch looks for android-5, why is my configured build wanting android-19? 06.49.31 # [Saint]: have a look again, nothing is disabled in that patch now. battery works 06.49.50 # <[Saint]> oh, my mistake. I'm stuck in the past I guess. 06.49.54 # I mean, changes it from android-5 06.50.33 # hmmm... 06.50.55 # <[Saint]> we most certainly need platform 19 06.51.07 # <[Saint]> mail went out about that yonks ago. 06.51.31 # <[Saint]> just seems like we're looking for zipalign in the wrong place 06.51.52 # <[Saint]> easily fixed, and easily worked around with a symlink 06.52.28 # tools/configure still has much older stuff named 06.53.21 # <[Saint]> that may be setting the minimum platform API 06.53.36 # <[Saint]> ie. the minimum version we'll run on 06.53.42 # <[Saint]> (he says without loking at all) 06.54.39 # <[Saint]> anyhoo - I can build with current tools with a slight workaround - so I'm not sure what's up with your system. 06.54.51 # <[Saint]> but my SDK/NDK are *much* much newer. 06.57.47 # <[Saint]> and my kernel is orders of magnitude newer as well, but I sincerely doubt that's it. 06.57.49 # I pulled the latest stuff 06.58.19 # <[Saint]> you must've been fighting pretty hard to keep that kernel version whilst still keeping the rest of the system up-to-date. 06.58.19 # I'll change explicitly to 19 to make sure it even builds 06.58.23 # <[Saint]> (assuming it is) 06.58.57 # it ain't. it builds rockbox, that's that's used for and hasn't had any issues until trying this 07.24.18 Quit ploco (Quit: Page closed) 07.36.14 Join kugel [0] (~kugel@rockbox/developer/kugel) 07.36.45 Join xaioscn [0] (~Dell@host-184-166-130-123.bln-mt.client.bresnan.net) 07.42.59 # Hi All, I'm seeing a bit of weird behavior on my Sansa Clip Zip 4GB running 3.13 of Rockbox. I have music on both the Internal Storage and on a 32gb SDHC Class 4 San Disk microSD card. When I select Database->Artists->All Tracks with Shuffle on it seems to find all 2566 Songs on both the Internal and External Storage, however when it goes to play them it will skip over any songs on the External 07.43.00 # Storage to the next avaliable song on the Internal Storage. I am able to select any song (or even folder) on the External Storage and play it without issue. I seem to recall this working in the past, but I did recently load up a fair number of new songs (several hundred in fact in multiple folders on the SD card). This MP3 player does live in the car constantly plugged in so I am not ruling 07.43.01 # out hardware issues due to the extreme heat and cold it has been exposed to in the past (I use the auto-on and auto-off features frankly #1 killer feature of Rockbox). Any ideas? I'd also settle for the ability to have it generate a playlist soley off of the external storage if that's a work around. Thanks. 07.46.43 Join saratoga_ [0] (123e1c18@gateway/web/freenode/ip.18.62.28.24) 07.46.51 # xaioscn: could try rebuilding the database 07.50.58 # saratoga_ Thank you that did the trick! Should I force it to rebuild the database everytime I load up new songs? 07.51.56 # shouldn't be necessary unless something goes wrong 07.53.15 # Awesome, I rarely load new songs (and it looks like it did find about 1,000 new ones) so I'm good to rock and roll! Thanks for all your hardwork on the project, it really makes these little Clip Zip's shine they work great in the car on shuffle with that auto on/off feature and big SD cards. 08.05.54 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 08.12.32 *** Saving seen data "./dancer.seen" 08.21.09 Join LinusN [0] (~linus@giant.haxx.se) 08.21.12 Join ender` [0] (krneki@foo.eternallybored.org) 08.35.53 # [Saint]: the ART patch isnt agressive 08.36.19 # <[Saint]> it /was/ - we've already established that. 08.37.07 # where? 08.37.32 Quit pamaury (Ping timeout: 240 seconds) 08.41.26 Quit saratoga_ (Quit: Page closed) 08.43.47 # I'm still having stupid problem. Is it possible to try the sigaltstack threads and newer sdk in root.make alone? (just to root.make part of the patch) 08.52.08 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 09.00.20 # jhMikeS: just #define HAVE_SIGALTSTACK_THREADS in $builddir/autoconf.h 09.01.29 # I would except I can't get an apk to make. make it seems bombs out with 'illegal instruction" 09.02.10 # you can install sdk platform 19 and sdk tools 19.1.0 from the sdk manager (run $sdkdir/tools/android) 09.03.04 # if it dies in zipalign you could comment try to skip that build step, zipaligning is optional 09.03.05 # I've already got all that 09.03.23 Quit bertrik (Remote host closed the connection) 09.03.55 # says "make: *** [/home/user/rockbox/builds/android/bin/resources.ap_] Illegal instruction" 09.05.27 # that combination worked on my box, but it is amd64 (yours seems to be x86) 09.05.37 # oh my goodness 09.05.45 # it's sort of not a box 09.06.50 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 09.14.12 Join petur [0] (5bb7304d@rockbox/developer/petur) 09.14.34 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 09.22.11 Quit scorche` (Ping timeout: 250 seconds) 09.24.11 Join scorche [0] (~scorche@rockbox/administrator/scorche) 09.27.20 # * jhMikeS thinks its weird that r3 is treated non-volatile 09.27.41 # the abi is differnt 09.37.22 Quit scorche (Ping timeout: 244 seconds) 09.38.26 # alot of pure asm is not going to work properly unless it stacks r3 as well 09.41.13 # another thing: hosted targets should never use our errno.h, never ever. it has to match the host, not our own defs 09.51.04 # * [Saint] thought he made it clear a 64bit machine was required 09.51.11 # <[Saint]> Sorry if I didn't... 09.51.43 # <[Saint]> Needs a 64bit multiarch system. 09.54.54 # * jhMikeS wasn't clear 09.55.37 # <[Saint]> I thought *I* wasn't clear. 09.55.58 # <[Saint]> ...then who was phone? 09.56.02 # funny though, why? It's gets through everything else 09.56.43 # <[Saint]> I honestly have no idea. 09.58.04 # exactly what is required to be 64bit? 09.58.44 # and the fact I can download 32-bit sdk/ndk 10.00.44 # <[Saint]> Maybe I'm confusing an unrelated issue - someone with a lot more of a clue should likely confirm or deny now I'm doubting myself. 10.01.08 # <[Saint]> It just occurred to me that I may be confusing opinion and fact. 10.01.56 # I wouldn't expect the tools to be doing anything if they were only 64-bit arch but they run 10.01.58 # <[Saint]> kugel is probably the one with the absolute oversight in this area. 10.02.32 # <[Saint]> s/probably/certainly/ 10.02.37 # so, I'm just examining a rockbox.so objdump and some things stike me 10.02.43 # the sdk and ndk should work on 32bit machines 10.04.25 # jhMikeS: about errno, the host errno isnt multiplexed across our threads 10.04.41 # I did it already 10.04.54 # ?? 10.05.20 # added errno save and restore to the context 10.05.46 # but for our code to use this errno it needs our header, no? 10.05.57 # no 10.06.12 # ok 10.06.18 # just the function redirect 10.06.41 Join lebellium [0] (~chatzilla@i16-les01-ntr-212-194-176-149.sfr.lns.abo.bbox.fr) 10.06.41 # eh? 10.07.03 # the function redirect is in our header? 10.07.38 # #define errno (*__errno()) 10.08.43 # thread.c needs to see the real one of course, not ours 10.09.38 # the above define is in our header 10.10.43 # that should mask the host one everwhere else 10.10.51 # but don't use the values, use the system ones 10.11.05 # you said "hosted targets should never use our errno.h" 10.11.39 # I should have clarified what I meant 10.12.11 # use the hosts values but our errno #define 10.12.27 # unless using host threads 10.12.28 # how do you do that? you get both with include errno.h 10.12.34 *** Saving seen data "./dancer.seen" 10.12.56 # I'm not sure it's right at this time 10.13.50 # (the alternative would be to actually set errno at context switch, it has overhead unfortunately) 10.14.18 # well, you'd better or else it not going to be right 10.17.51 # it's just a "maybe" if it isn't considered context and it would mix up with the hosts own functions' setting of it 10.20.58 # within the single host thread (with N rb threads) there is only a single errno, we can do whatever we want. only library functions ever set it (we don't call these from our context switch routines), and only in case of error (it's never set back to 0 by the host) 10.27.18 # sure, that's where the issue starts, if one of ours sets it, we context swich, then another sets it and switches back, now it's probably wrong 10.27.58 # why? 10.28.35 # is that with setting errno on CS or without? 10.28.46 # without 10.28.51 # (without things will be fishy if the __errno() override isn't seen) 10.29.03 # yea 10.30.21 # but, I want host functions' setting of it to be able to blend with our functions that set it. 10.30.42 # so, nvm, code should see the hosts errno, not ours 10.31.20 # I thought it out earlier when doing it then had to rethink it again :) 10.32.53 # and CS just saves and restores the host value for each "thread" 10.32.56 # again, the host errno isn't multiplexed 10.33.12 # so we'd have to do it on CS 10.33.17 # * kugel is too slow 10.33.18 # I put that in 10.35.27 Join AlexP [0] (~alex@rockbox/staff/AlexP) 10.35.35 # I see "__errno@plt". maybe they gave it a similar name? 10.35.51 # plt == platform I'm guessing 10.36.23 # so perhaps it's fine 10.36.25 # Procedure Linkage Table? 10.36.43 # haha, ok 10.37.26 # I see filesystem functions there too 10.37.32 # that's a call to android code then? 10.37.32 Join kuldeepdhaka [0] (~kuldeepdh@unaffiliated/kuldeepdhaka) 10.38.12 # section .plt 10.38.55 # I'm also wondering when r3 has to be stacked and when not, some functions do it, some don't 10.39.15 # even if r3 is clobbered 11.00.50 Nick SuperBrainAK is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) 11.04.36 Join scorche [0] (~scorche@rockbox/administrator/scorche) 11.16.23 Join scorche` [0] (~scorche@ip68-0-156-139.tc.ph.cox.net) 11.16.33 Quit scorche (Disconnected by services) 11.16.33 Quit scorche` (Changing host) 11.16.33 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 11.26.37 # the problem has to do with the compiler moving stuff across the save/load, where before it just happened to be ok 11.28.19 # * jhMikeS 's been waiting for the this day to come for years 11.29.07 # jhMikeS: so you fixed all the android crashes? :) 11.29.56 # I didn't fix it yet. I see the issue though and what changes in the assembly output that messes it up. 11.30.54 # the context save/restore really isn't portable. I was just working on a patch that swaps it one function call in one spot which would fix it. 11.31.03 # that's why that patch alleviates the problem 11.33.55 # it save r5 before r5 is loaded with the thread pointer, then loads r5 with load_context, then assumes it still point to the thread, but it doesn't 11.37.34 # jhMikeS: which android crash is this? the one under ART? 11.37.37 # it means the basic design that's been there forever really has to be corrected or else this stuff will pop up here and there 11.38.07 # kugel: the ART patch correct it but due to different context saving / restoring in switch_thread 11.38.51 # yea, so there is a problem with our custom CS? I remember under maemo it was also problematic 11.39.09 # but when I look at it it seems safe for EABI 11.39.50 # yes there is. the compiler doesn't know registers were clobbered 11.40.58 # IIUC because the CS is a function call it has to stack r0-r3, all other registers need to be stored in the context struct, or am I wrong? 11.41.34 # I have frankly been surprised for awhile it's worked at all 11.42.45 # enlighten me if/when you know what'S wrong with it exactly, because I cant see it 11.43.31 # no, it saves a reg, then the compiler loads that reg with something else, loads the new context, and the compiler uses the reg after that but the load clobbered what it (rightfully) assumes it still contains 11.44.16 # it loads the regs just before the return of switch_thread(), should be safe? 11.44.21 # no 11.45.04 # you don't know what order it will place things, really 11.46.36 # r5 gets clobbered but then it loads errno after that. I suppose moving errno load to before the load might patch it up for now. 11.47.34 # where is errno loaded? 11.49.12 # * kugel looks at old code 11.50.00 # in thread.c in thread_store/load_context 11.50.02 # yes, i think load_context() must be last 11.50.58 # reordering that might help, the compiler shouldnt be able to reorder itself becuase load_context() is asm volatile 11.51.15 # however, I think the ART crashes are older than your reworks 11.53.02 # I remember reading somewhere it's not guaranteed it won't move things and it doesn't know certain regs are changing 11.54.09 # it can only reorder memory accesses, but not function calls and IIRC not asm volatile blocks 11.54.46 # (i.e. a asm volatile block should be treated as a function call w.r.t to reodering optimizations) 11.55.38 # if that's so, then r4+ are safe to assume don't get clobbered if not listed 11.55.59 # changing the order appears to make it look good though 11.56.34 # so, I guess I can just push that one right now 11.58.48 # the rework I've got also gets rid of the start pointer and just sets it all up to directly jump it to startup code 11.59.08 # jhMikeS: i think the registers still need to be listed 11.59.40 # they aren't and never were 11.59.53 # nothing to to do with anything I ever did 12.00.43 # right, that might be a bug, and may have worked because it's just before the end of switch_thread() where gcc doesnt do anything to the regs anymore 12.01.30 # I'm just putting it back that way for now :) 12.01.37 # hm no, wait, listing them would make gcc stash the regs (and restore afterwards) right? 12.02.24 # I think that's correct. There's a big note "only!" for r0 which I take it somebody went through the trouble. 12.03.20 # yes for clobber. maybe r4-r14 should be in hte list of output operands 12.03.43 # which is empty there 12.05.17 # A single point of swapping it also makes it easier to not save or restore if the thread doesn't change 12.07.09 # win32 fiber threads to true swapping, store context is a nop there 12.08.39 # Build Server message: 3New build round started. Revision 5fb3702, 253 builds, 30 clients. 12.09.10 # * jhMikeS saw that while digging around 12.11.34 # * jhMikeS hates what he sees ldm, then pop back to back 12.12.35 *** Saving seen data "./dancer.seen" 12.16.37 # Build Server message: 3Build round completed after 479 seconds. 12.18.46 # I wonder if you could do nothing in store/load but just tell it you did 12.34.18 # heh, that does indeed work with the exception of sp 12.34.58 # no redundant loads or stores, the function call takes care of it 13.03.40 Join Guest81512 [0] (Slayer@c-69-143-187-144.hsd1.va.comcast.net) 13.06.02 Quit Guest50306 (Ping timeout: 240 seconds) 13.13.32 Quit kuldeepdhaka (Ping timeout: 246 seconds) 14.12.39 *** Saving seen data "./dancer.seen" 14.39.39 Join ZincAlloy [0] (~Adium@pD9EEAF2D.dip0.t-ipconnect.de) 14.58.31 Quit olspookishmagus (Ping timeout: 245 seconds) 14.59.49 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) 15.00.13 Nick olspookishmagus is now known as Guest48784 (~pookie@snf-137798.vm.okeanos.grnet.gr) 15.02.30 Join RiD [0] (~RiD@2.83.12.42) 15.06.48 Join amayer [0] (~amayer@mail.weberadvertising.com) 15.56.47 Quit Zagor (Quit: Clint excited) 16.04.36 Part LinusN 16.12.40 *** Saving seen data "./dancer.seen" 16.25.43 Join kuldeepdhaka [0] (~kuldeepdh@unaffiliated/kuldeepdhaka) 16.36.47 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 32.0/20140818191513]) 16.40.31 Quit kugel (Ping timeout: 244 seconds) 16.44.41 Join franklin [0] (~franklin@cpe-071-071-071-105.triad.res.rr.com) 16.49.45 Join kuldeepdhaka_ [0] (~kuldeepdh@unaffiliated/kuldeepdhaka) 16.50.44 # Anyone know why the USB HID feature doesn't work on iPod Classic? 16.52.54 Quit kuldeepdhaka (Ping timeout: 255 seconds) 17.06.22 # gevaerts, you wrote a lot of the USB stack, didn't you? 17.06.30 # I did 17.06.56 # what is the usb core on the ipod classic ? 17.07.03 # s3c6400 17.08.17 # * franklin wonders if it would be possible to play back PCM audio through the piezo speaker 17.09.52 # I tried compiling with ENABLE_USB_HID, it adds all the features you would expect (remote_control), but it doesn't work :( 17.10.17 # That might be why it's disabled 17.10.34 # haha I know... why doesn't it work? 17.10.58 Join TheGuyWhoIsTheGu [0] (~androirc@modemcable045.77-163-184.mc.videotron.ca) 17.11.42 # isn't the s3c6400 a synopsys core ? with which we have some many problems ? 17.12.00 # The Rockbox Android Daily Build doesn't work after installing it, it stops working, like ot. Force closes. 17.12.32 # pamaury, the datasheet has "Samsung" written on it :) 17.12.49 # So? 17.13.23 # Maybe it's from Samsung :P 17.13.46 # The soc is from samsung, yes 17.13.50 # it doesn't mean anything, USB cores usually are IPs sold by very few companies 17.13.51 # There is a datasheet, though http://www.datasheet4u.com/datasheet/S/3/C/S3C6400x_Samsung.pdf.html 17.13.58 # just checked, it's a synopsys core 17.14.00 # Ah I see 17.14.07 # Just samsung-branded 17.14.51 # TheGuyWhoIsTheGu: the android port seems to be in a fairly bad shape these days, mostly involving newer android versions 17.16.18 # So, no one is working on supporting it? 17.16.24 # Oh ok, well ill have to wait for a functional build 17.16.44 # TheGuyWhoIsTheGu, expect it between now and never :( 17.17.03 # There's not that much work being done on it :( 17.17.05 # many tried, no one succeeded, TheSeven did a complete rewrite for emcore and someone attemped a rockbox port, I don't know what is the state of this 17.17.31 # So TheSeven would be the best to ask? 17.17.37 # Hahaha well ok, no one has an older build?? 17.17.47 # franklin: yes 17.17.51 # Of course there are archived builds :) 17.18.12 # But apparently, "All Quassel clients vanished from the face of the earth..." 17.18.27 # So no links :( 17.19.13 # So how would I dump the PCM data to the piezo? 17.19.35 # (I am 100% serious) 17.19.56 # TheGuyWhoIsTheGu: I'm not at all convinced that older builds would help you 17.20.13 # The problem is the newer Android version? 17.20.41 # Likely, yes 17.20.49 # I remember that I had a working build of Rockbox in my android phone with 4.4.4 17.20.51 # Well, sitll a bug in rockbox 17.21.07 # So how would I dump PCM data to the piezo? 17.22.37 # It /is/ possible: https://en.wikipedia.org/wiki/Space_Hulk_%281993_video_game%29#Reception 17.32.47 # And there's an expired patent for something like it: https://encrypted.google.com/patents/US5054086 17.37.15 # So, how do I do it in Rockbox? 17.37.25 # Where could I upload a working build of Rockbox for android 4.4.4 because I found it. I have the APK 17.37.54 # Where'd you get it? 17.38.43 # I had it on my phone and a backup of my sd card on my PC 17.39.21 # Oh 17.39.53 # Some file-sharing site, maybe? Or you could ask the RB website admins to host it if you like 17.40.13 # Ok I'll ask 17.40.31 # dropbox, google drive 17.40.37 # mega 17.40.53 # mega will taken down soon enough... 17.42.00 Quit petur (Ping timeout: 246 seconds) 17.42.18 # Rockbox won't host it for you 17.42.40 Quit Guest48784 (Ping timeout: 272 seconds) 17.42.43 # Will they link to it? 17.43.46 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) 17.43.48 # Where do I ask? 17.44.04 # I bet gevaerts knows :P 17.44.10 Nick olspookishmagus is now known as Guest76939 (~pookie@snf-137798.vm.okeanos.grnet.gr) 17.44.29 # First of all, where did you get your build from? Is it from unmodified sources? 17.44.58 # Because if it isn't, you need to provide the source as well 17.45.25 # From Rasher's website 17.45.27 # ugh GPL issues... 17.45.33 # OK, that's unmodified then 17.45.42 # franklin: this isn't an unfortunate side effect... 17.45.46 # It's an old revision 17.46.08 # GPL is great sometimes... and just annoying other times 17.46.22 # franklin: yes, and this is one of the times where it's great 17.46.31 # You could post in the "unsupported builds" section on the forums 17.46.39 # Great for the people in the future... but not for us :) 17.47.01 Join TheGuyWhoIsTheG2 [0] (b8a34d2d@gateway/web/freenode/ip.184.163.77.45) 17.48.24 # I'm the one with the working Android build, but I'm connected on my computer. So do I post it in the forums with a link to Google Drive? 17.49.18 # That should work 17.49.36 # Add the revision in the post 17.50.05 # OK 17.50.09 # I think you could attach it, if the forum allows .apks 17.50.14 # (I don't think it does) 17.54.03 # Wow MEGA is great 17.58.59 Quit TheGuyWhoIsTheGu (Read error: Connection reset by peer) 18.02.11 # http://forums.rockbox.org/index.php/topic,48482.msg229348.html#msg229348 18.02.21 # The link to the post 18.02.43 Quit pamaury (Ping timeout: 250 seconds) 18.05.12 # I heard that the iPod Classic is a very fast device for Rockbox, is that true and is there any suggestions for other devices? 18.05.33 # Yes it is fast, and is rather complete 18.05.45 # True, there are tons of small to medium-sized bugs 18.06.22 # So if I had to build a device today, an iPod Classic would be a great option? 18.06.25 # (like the user timer not working, which is why DOOM is broken :( as well as the difficult install process) 18.06.30 # build a device? 18.06.43 # *buy 18.06.45 # sorry 18.06.46 # haha 18.07.14 # If you want a complete rockbox port, get a sansa or an earlier ipod 18.07.35 # but classic looks quite pleasing and runs rockbox quite nicely other than for a few bugs 18.07.47 # (though install is a bit tedious) 18.07.55 # I had an iPod video and it was slow while using the eq that's why I'm asking 18.08.30 # iPod classic sounds perfect 18.08.39 # even with 10-band EQ 18.08.55 # * gevaerts finds that hard to believe 18.08.59 # it does :) 18.09.16 # If you use ten bands, you're almost certainly doing something wrong, in which case it *can't* sound perfect 18.09.32 # I count 10 bands 18.10.04 # When I used a lot of bands the playback and the device was slow and buffering occured 18.11.39 # In practice, the ipod video is more or less the slowest device you can get 18.12.04 # I have a nice 216 MHz CPU in mine 18.12.12 # You don't 18.12.19 # 54MHz? 18.12.30 # It's the same CPU as other old ipods and sansas, but it has a much bigger screen than those, and that does make a difference 18.12.30 # Wow, for the first Rockbox device to have, I took the worse one 18.12.39 # The classic? 18.12.42 *** Saving seen data "./dancer.seen" 18.12.54 # franklin: video 18.12.55 # Ah you're thinking of the video 18.13.00 # *late* 18.13.14 # My /classic/ has a nice 216MHz CPU 18.13.21 # TheGuyWhoIsTheG2: it's not a bad device. It's just a bit underpowered if you want lots of DSP or CPU-intensive codecs 18.13.43 # * gevaerts would like to point out that MHz is not a useful unit of CPU performance 18.13.55 # gevaerts, it is in some cases 18.14.11 # Oh ok, well maybe I should have learn a little bit more about EQs and how they work 18.14.18 # For example, a 4MHz CPU is almost always going to slower than a 16MHz one 18.14.24 # No 18.14.27 Quit Kohlrabi (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 18.14.35 # Do you guys have any plans for an iOS app, I have an old iPhone 3G taking more and more dust, it's jailbroken but all the tweaks need a newer version :( 18.14.36 Join Kohlrabi [0] (~kohlrabi@kohlio.de) 18.14.41 # Unless that 4MHz is a CISC and the 16MHz is some crazy VLIW RISC 18.14.47 # The 4 MHz one could be a pipelined 32 bit thing, while the 16MHz one could be an 8 bit slow design 18.14.54 # Also, RAM matters too 18.15.15 # TheGuyWhoIsTheG2: I'm not aware of any real efforts in that direction 18.15.30 # TheGuyWhoIsTheG2, $99 for a dev membership 18.15.45 # Some people have talked about it over the years, but I doubt if anyone ever even tried to get started 18.15.50 # If you want to cough that up and start working on it, go for it 18.16.02 # franklin: that's the problem 18.16.27 # but do you need a dev membership to make a jailbreak app? 18.16.30 # no 18.16.53 # You don't even need one for a non-jailbreak device. You only need one if you want other people to be able to run it 18.17.00 # gevaerts: for comparing similar CPUs (say intel core i3s), clock freq is pretty good 18.17.01 # So you don't need one to get started 18.17.06 # (for comparing) 18.17.21 # gevaerts, you need a Mac 18.17.23 # franklin: yes, but in the rockbox context, there's a *lot* of variation 18.17.27 # Or a hackintosh 18.17.37 # gevaerts, not much... most ARM 18.17.50 # Some MIPS/SH/coldfire 18.19.25 # ok I see why there no real effort for iOS devices 18.19.37 # franklin: within the ARM devices, there can be a *huge* difference in performance/MHz. Up to almost 9x in some cases... 18.19.53 # Have a look at the table on http://www.rockbox.org/wiki/SoundCodecMonkeysAudio 18.20.43 # Gigabeat S plays -c5000 APE at 112% realtime with a 528MHz CPU, PP502x devices play it at 2% realtime with 80MHz 18.21.00 # So that's 55x the performance with 6.6x the clock cycles 18.21.08 # ah 18.21.15 # Why? cache? ram? 18.21.21 # Cache is one part 18.21.33 # RAM speed is another 18.22.20 # multi-core? 18.22.37 # The PP502x is, but that's not a factor here 18.22.48 # The APE decoder doesn't use that 18.23.19 # Should it? 18.23.29 # Have you guys heard about ViPER4Android 18.23.42 # I don't think it makes much of a difference. APE is stupid anyway :) 18.23.53 # haha 18.24.42 # You're paying *huge* CPU prices (which translate directly to battery runtime) for a filesize gain of maybe a few percents over flac 18.25.03 # ah 18.25.11 # 2% realtime :O 18.27.52 # gevaerts, would ipod classic be any better on APE? 18.28.20 # I'd expect it to be fairly similar to nano2g 18.28.33 # ah so about 2% realtime :) 18.28.56 # with c5000 18.29.29 # wow slow 18.29.37 # play-stop-play-stop 18.29.41 # APE c5000 is 5% smaller than flac at -8 for the rockbox test track 18.29.58 # wow 18.30.20 # * franklin is considering a Gigabeat S for his next DAP 18.30.28 # Don't 18.30.43 # If you think a classic is a pain to install, you haven't tried those :) 18.30.57 # It's a breeze to me 18.31.10 # Download, chmod +x, exec 18.31.12 # They have a habit of reformatting the data partition for no reason if you look at them in an odd way 18.31.26 # look in them? 18.32.26 # If they don't like the partition layout or the firmware partition contents or something like that, they helpfully clear everything and tell you you need to restore 18.33.06 # Also, some of them don't like dual boot while others dislike single boot 18.33.12 # gevaerts: mine never does that unless I trash it 18.33.24 # Yes, some of them are friendly :) 18.33.31 # it's caused by the microsoft firmware 18.33.31 # You just won't know in advance 18.33.31 # haha 18.33.37 Join rela [0] (~x@pdpc/supporter/active/rela) 18.33.44 # well, so classic is the best ATM? 18.33.51 # it would do it if dual booting but never otherwise 18.33.53 Join kugel [0] (~kugel@rockbox/developer/kugel) 18.33.59 # jhMikeS, you mentioned dumping PCM to the piezo 18.34.03 # could it be done? 18.34.46 # franklin: probably gonna need some fancy ISR and a to modulate it in a weird way if all it does is beep otherwise 18.35.12 # And it'll never get in HEAD, right? 18.35.25 # gevaerts: it's possible to revert the S to an older flash and not have the single boot issue 18.35.43 # so, don't get a Gigabeat S, right? 18.35.57 # If I were to buy a new DAP now, what should I buy then? 18.35.58 # I have one 18.36.02 # jhMikeS: a lot of things are possible. Do you enjoy walking people through all the steps? :) 18.36.16 # :) 18.36.30 # Also, all you gain is being able to playe APE -c5000 :) 18.36.32 # gevaerts: no, but there is a one-clicky solution that's just like upgrading 18.36.49 # franklin: if you like vgm or ape Gigabeat S is your friend 18.36.52 # gevaerts, does it run DOOM? :) 18.37.06 # S does run doom indeed, it's almost a joke for it 18.37.12 # haha 18.37.24 # You don't need anywhere near that CPU power for doom 18.37.28 # what challenges it? video, vgm and ape 18.37.39 # video barely 18.37.59 # * franklin is considering building a cluster computer with Gigabeat S' now 18.38.39 # gevaerts: we just need a gloomier, doomier doom 18.39.05 # maybe port quake or something :) 18.39.15 # Go ahead :) 18.39.25 # Wow sansa clip is surprising powerful 18.39.33 # But it has the worst screen ever 18.39.55 # franklin: don't look at it, just listen! 18.40.10 # I mean, seriously? Who decided that it would be a good idea to make a screen that was half yellow, half blue? 18.40.13 # gevaerts: nah...too easy probably 18.40.18 # With a split in the middle!? 18.40.33 # jhMikeS, while you're at it, port a C compiler, too :) 18.40.39 # franklin: must be the guy who designed space invaders 18.41.00 # franklin: wtf would you need that for? 18.41.04 # haha game title, etc goes in top, game goes in bottom 18.41.16 # jhMikeS, to build itself 18.41.29 # and to say that I have a self-hosting platform on my ipod 18.41.42 # port an emulator to run it on first 18.42.47 # ok, 'nuff silliness; this is serious 18.42.49 # :) 18.43.00 # Ok... seriously, why isn't 2048 a link on http://www.rockbox.org/wiki/PluginIndex 18.43.19 # All the other plugins are 18.43.55 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 18.44.58 # where the actual link to it/ 18.44.59 # ? 18.45.42 # http://www.rockbox.org/wiki/Plugin2048 18.46.18 Quit TheGuyWhoIsTheG2 (Quit: Page closed) 18.46.57 # jhMikeS, the plugin index is generated automatically 18.50.03 # I gather that 18.50.14 # just sayin' :) 18.50.51 # it's the only one with digits 18.51.21 # chip8 has digits, too 18.51.59 # oops, skimmed past that 18.54.05 # any idea why? 18.57.20 # not yet 18.57.44 # I'm looking for some key difference in the chip8 vs. 2048 and am failing to see it 18.57.59 # you have %TOC% while it doesn't but would that matter? 19.01.44 # chip8 does have a "chip8" though at the top, not _only_ numbers 19.02.16 # yeah, maybe that's it... try Plugin2048 as the title 19.03.13 # me or you? 19.03.18 # you, I need to go now 19.03.22 # catch you soon 19.03.23 # oh really 19.03.34 # yes 19.03.56 # cya 19.04.07 Quit franklin (Remote host closed the connection) 19.05.01 Quit rela (Read error: Connection reset by peer) 19.06.01 Quit kuldeepdhaka_ (Ping timeout: 245 seconds) 19.07.33 # even the iPod video should be fast enough unless you're doing something stupid like turning on a million EQ bands 19.11.29 # saratoga: like 10 of them? 19.11.48 # did we enable 10 bands on the PP players? 19.12.17 # on the iPod Video, they're there 19.12.56 # probably not the best idea 19.13.10 # hence the guy's inquiry into faster devices 19.13.17 # i always meant to look into moving them to the coprocessor as well rather than the main CPU, but it seemed pointless with only 5 bands 19.13.37 # it's unclear whether he's using it right though 19.13.50 # possibly using it as a non-parametric EQ 19.15.16 # oh no, multicore DSP now? :) 19.15.52 # iPods have a co-processor? 19.16.23 # all portal player do 19.17.20 Join Rower [0] (husvagn@h176n2-aeg-a11.ias.bredband.telia.com) 19.19.15 Join kuldeepdhaka_ [0] (~kuldeepdh@unaffiliated/kuldeepdhaka) 19.26.25 Join lleeloo [0] (~lleeloo@37.215.51.30) 19.26.41 Quit lleeloo (Client Quit) 19.29.18 Join lleeloo [0] (~lleeloo@37.215.51.30) 19.32.36 Part ZincAlloy 19.46.22 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 19.46.33 Quit bluebrother (Disconnected by services) 19.48.39 Quit fs-bluebot (Ping timeout: 260 seconds) 19.50.41 Join krabador_ [0] (~krabador_@95.239.176.24) 19.52.32 Join fs-bluebot [0] (~fs-bluebo@g226070165.adsl.alicedsl.de) 19.53.08 Nick krabador_ is now known as krabador (~krabador_@95.239.176.24) 19.53.28 Quit krabador (Changing host) 19.53.28 Join krabador [0] (~krabador_@unaffiliated/krabador) 20.05.45 Join rela [0] (~x@pdpc/supporter/active/rela) 20.12.44 *** Saving seen data "./dancer.seen" 20.21.29 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 20.29.12 Join lebellium [0] (~chatzilla@89-93-178-161.hfc.dyn.abo.bbox.fr) 20.33.23 Quit michaelni (Read error: Connection timed out) 20.40.37 Join michaelni [0] (~michael@chello084114129144.4.15.vie.surfer.at) 20.41.43 Quit michaelni (Max SendQ exceeded) 20.44.07 Join michaelni [0] (~michael@chello084114129144.4.15.vie.surfer.at) 20.47.16 Quit michaelni (Client Quit) 20.47.48 Join franklin [0] (980c1337@gateway/web/freenode/ip.152.12.19.55) 20.50.32 # saratoga: have you looked at G#919? 20.50.34 # 3Gerrit review #919 at http://gerrit.rockbox.org/r/919 : 3Fixed a CHIP8 bug, was part of G#904 by Franklin Wei 20.54.42 Join michaelni [0] (~michael@chello084114129144.4.15.vie.surfer.at) 21.02.06 Quit rela (Read error: Connection reset by peer) 21.07.26 Quit jhMikeS (Ping timeout: 246 seconds) 21.23.56 Join ploco [0] (dce9b7f9@gateway/web/freenode/ip.220.233.183.249) 21.28.38 Join robertd [0] (ba593ff9@gateway/web/freenode/ip.186.89.63.249) 21.29.08 Quit robertd (Client Quit) 21.29.17 # jhMikeS: Good news! your thread patch works! and no longer crash in scrolling text. (but doesn't fix ART problem, those are global reference mismatch) 21.29.31 Join robertd [0] (ba593ff9@gateway/web/freenode/ip.186.89.63.249) 21.31.18 # ploco: thread patch for every target? 21.34.43 # that affect the host targets the most 21.35.39 # yay 21.36.42 # * franklin needs to go 21.36.47 Quit franklin (Quit: Page closed) 21.43.48 # hmm..take some of my words back. Kitkat ART still panic at power thread, so not only the global reference, must use SIGALTSTACK_THREADS. this sucks..... 21.48.40 Quit kuldeepdhaka_ (Ping timeout: 260 seconds) 21.50.16 Join n1s [0] (~n1s@rockbox/developer/n1s) 21.55.15 Quit ploco (Quit: Page closed) 22.07.22 Join kuldeepdhaka [0] (~kuldeepdh@unaffiliated/kuldeepdhaka) 22.12.48 *** Saving seen data "./dancer.seen" 22.16.07 # ploco (logs): SIGALTSTACK threads are really lightweight too, it's not a problem 22.16.37 # actually i think android is the only HOSTED target that doesn't use them 22.18.12 Quit bertrik (Quit: reboot) 22.21.22 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 22.23.33 Join franklin [0] (980c3a61@gateway/web/freenode/ip.152.12.58.97) 22.29.24 # wha? 22.47.19 Quit n1s (Quit: Ex-Chat) 23.02.19 Quit lleeloo (Ping timeout: 244 seconds) 23.07.40 Quit amayer (Quit: Leaving) 23.07.45 Quit kugel (Ping timeout: 264 seconds) 23.20.52 # TheSeven: why doesn't USB HID work on ipod classic? 23.48.19 # franklin: in git master or with my patches? 23.49.26 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 32.0/20140818191513]) 23.49.33 # git master 23.49.46 # er, it's a mystery if USB works there at all ;) 23.49.49 # that driver is utterly broken 23.50.31 # do your patches make HID work? 23.51.51 # what patches? gerrit ones? 23.52.09 # and no, my patches don't make hid work 23.52.18 # they make everything except for hid work at least ;) 23.52.23 # (and some other minor nitpicks) 23.52.36 # how can I make HID work? :) 23.52.46 # by figuring out why it doesn't work in the first place 23.52.50 # lol 23.53.09 # from what I can tell the HID data packets arrive at the PC, but it ignores them for some reason 23.53.19 # maybe compare the data packets with a device where it works 23.53.29 # how do I intercept USB packets? 23.53.44 # with e.g. wireshark on linux 23.53.53 # wireshark works with usb? 23.54.02 # yes, but only on linux 23.54.10 # and if you're messing with USB, be sure to apply g#844 23.54.12 # 3Gerrit review #844 at http://gerrit.rockbox.org/r/844 : 3usb-designware: New USB driver for Synopsys DesignWare USB OTG core. by Michael Sparmann 23.54.13 # well, that's what I use :) 23.54.18 # (and, on ipod nano 2g, g#843 as well) 23.54.19 # 3Gerrit review #843 at http://gerrit.rockbox.org/r/843 : 3Fix cache coherency on ARM940T (and other ARMv4T cores). by Michael Sparmann 23.54.28 # (linux, not that patch yet) 23.56.30 # TheSeven: so what interface? 23.58.43 # never mind