--- Log for 02.11.120  Server: weber.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 4 days and 22 hours ago

00.05.00 #       <_bilgus> if it was the plugin itd show when the screen wasn't fliiped I'd think
00.05.51 #       <_bilgus> I feel into the same idea that its the plugin but the plugin is right
00.05.55 #       <_bilgus> fell*
00.27.35 #       <mendel_munkis> I cant figure out the oscilloscope but I did catch the other off by one I knew was there.
01.32.01 Join    lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
01.38.47 Nick    Oksana_ is now known as Oksana (~Wikiwide@Maemo/community/ex-council/Wikiwide)
01.42.11 ***     Saving seen data "./dancer.seen"
02.08.00 Quit    lebellium (Quit: Leaving)
02.16.11 Join    petur [0] (~petur@199.59.5.111)
02.16.11 Quit    petur (Changing host)
02.16.11 Join    petur [0] (~petur@rockbox/developer/petur)
02.18.19 Quit    amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
02.18.20 Quit    pixelma (Quit: .)
02.20.56 Join    amiconn [0] (jens@rockbox/developer/amiconn)
02.20.56 Join    pixelma [0] (marianne@rockbox/staff/pixelma)
02.36.19 Quit    t0mato (Quit: Ping timeout (120 seconds))
02.52.11 Join    t0mato [0] (~t0mato@193.32.127.159)
03.32.44 Quit    Stanley00 ()
03.42.12 ***     Saving seen data "./dancer.seen"
03.51.42 Join    Stanley00 [0] (~stanley00@unaffiliated/stanley00)
04.46.45 Join    vmx [0] (~vmx@ip5f5ac60f.dynamic.kabel-deutschland.de)
04.53.30 Join    skx_ [0] (~r0b0t@unaffiliated/r0b0t)
04.57.02 Quit    sakax (Ping timeout: 272 seconds)
05.26.08 Join    ufdm_ [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net)
05.27.54 Quit    ufdm (Read error: Connection reset by peer)
05.42.14 ***     Saving seen data "./dancer.seen"
06.08.04 Quit    prof_wolfff (Ping timeout: 240 seconds)
06.53.37 Quit    ufdm_ (Quit: Leaving)
06.53.52 Join    ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net)
07.10.32 Join    l0g [0] (~unix@180.242.215.21)
07.11.49 ***     Invited to ##chatterz by l0g!~unix@180.242.215.21
07.20.27 Quit    Stanley00 ()
07.22.00 Quit    ubervison (Quit: Leaving)
07.27.33 Part    l0g
07.42.16 ***     Saving seen data "./dancer.seen"
08.03.23 Quit    Acou_Bass (Ping timeout: 268 seconds)
08.05.11 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
08.16.48 #       <speachy> _bilgus: I'd like to pick back up g#2568 -- it's a feature long requested.  Since your vp rework the experiment works much better too
08.16.51 #       <fs-bluebot> Gerrit review #2568 at http://gerrit.rockbox.org/r/2568 : usb:  prompt user about what to do upon usb insertion  (WIP) by Solomon Peachy
08.17.28 #       <speachy> but now while it works great on standard contexts, in wps it breaks badly.
08.37.01 #       <edhelas> speachy "proof of concept for discussion and flagellation" :D
08.38.05 Nick    Slasherii is now known as Slasheri (~miipekk@itu.ihme.org)
08.39.18 Quit    Slasheri (Changing host)
08.39.18 Join    Slasheri [0] (~miipekk@rockbox/developer/Slasheri)
08.45.49 Quit    Acou_Bass (Ping timeout: 264 seconds)
08.47.18 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
09.17.07 #       <_bilgus> speachy, does it just have issues staying on the screen? it probably needs to hold the screen or it needs to mark the vp as clean so the wps doesn't try to take it back
09.17.54 #       <speachy> it's just using the standard gui_syncyesno_run() stuff.
09.18.12 #       <_bilgus> oh that should already be aware
09.18.21 #       <_bilgus> ok i'll try it
09.18.44 #       <speachy> under the wps, it paints, and then goes a little nuts; the screen is partially repainted over, and the wps gets the keypresses.
09.19.10 #       <speachy> but it doesn't recover unless I leave and then go back to the wps
09.23.26 Quit    vmx (Ping timeout: 264 seconds)
09.42.00 Join    massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
09.42.20 ***     Saving seen data "./dancer.seen"
09.43.14 #       <_bilgus> ACTIVITY_USBSCREEN
09.43.24 #       <_bilgus> I don't see that in the usb code
09.43.45 #       <_bilgus> wps isn't aware of your screen perhaps
09.44.18 #       <_bilgus> i'll still make guisync work but ultimately you need to push and pop your activity
09.44.28 Join    johnb3 [0] (~johnb2@p5b3afcc0.dip0.t-ipconnect.de)
09.45.45 #       <_bilgus> misc.h push_current_activity(enum current_activity screen); pop_current_activity(void); get_current_activity(void)
10.01.11 #       <speachy> okeydokey, will try
10.07.56 #       <_bilgus> yep that did the trick
10.08.22 #       <_bilgus> I think you'll find the wps very agressive about taking its viewport back
10.12.59 #       <_bilgus> looks like maybe you need to stop playback too though I guess it might be the wanted action
10.13.50 #       <speachy> well, either you care about using your device in USB mode (in which case playback would stop), or you'd tell it to only charge, in which case you'd want playback to continue.  either way you don't want to interrupt playback until the choice is made.
10.14.48 #       <_bilgus> the only other thing might be a timeout
10.15.25 #       <speachy> ok, the activity fixed the wps going nuts, but the WPS doesn't repaint properly afterwards.  I guess we need to flag it as dirty?
10.15.36 #       <_bilgus> well I guess in a build doesn't work situation you could do it through USB mode in the bootloader
10.16.04 #       <_bilgus> it should be dirty automagically
10.16.22 #       <_bilgus> you popped the activity when you were done?
10.16.33 #       <speachy> while the message is on-screen, the wps progress bar continues to be displayed on the bottomw
10.17.00 #       <_bilgus> yeah thats what I was saying about stopping pb
10.17.48 #       <speachy> and after answering no, it doesn't repaint the background properly
10.18.06 #       <_bilgus> ok i'll mess with it for a few
10.18.16 #       <speachy> (active elements on the wps are updated)
10.18.49 #       <speachy> might be a bug in yesno.c instead
10.19.27 #       <speachy> hmm, or wps not handling the activity switch properly.
10.20.39 #       <speachy> there's a much more elaborate usb-insertion prompt screen in pamaury's old MTP patch
10.21.08 #       <_bilgus> my guess would be something in the wps not being aware
10.21.44 #       <_bilgus> its refreshing through another mechanism most likely
10.22.19 #       <_bilgus> and it marks stuff as clean when its done
10.27.28 #       <speachy> but carringt this thing forward, my idea is to add a default preference for the mode -- usb, charge, prompt, and we'd default to prompt.
10.32.25 Quit    beencubed (Ping timeout: 240 seconds)
10.33.03 #       <_bilgus> that sounds good
10.33.12 #       <_bilgus> because it quickly gets annoying lol
10.35.26 Join    beencubed [0] (~beencubed@209.131.238.248)
10.38.27 #       <speachy> it's been a constant user complaint for quite a while now
10.44.03 #       <_bilgus> wps has its own stuff for this
10.44.17 #       <_bilgus> gwps_enter and leave
10.46.42 #       <_bilgus> looks like currently its all handled in the event loop for the wps
10.47.25 #       <_bilgus> we don't want it to be exclusively its domain though so maybe there is another way
10.50.40 Join    vmx [0] (~vmx@ip5f5ac60f.dynamic.kabel-deutschland.de)
10.51.30 #       <_bilgus> speachy I assume we kick out the action on usb plug
10.52.11 #       <_bilgus> I think what we will have to do is tread usb insertion as an action
10.52.27 #       <_bilgus> like ACTION_USB_INSERT_PROMPT
10.52.44 Quit    Acou_Bass (Ping timeout: 260 seconds)
10.52.51 #       <_bilgus> the wps will have to have its own handler to fit within the provided constraints
10.53.05 #       <_bilgus> wps.c has the loop
10.53.50 #       <_bilgus>             case ACTION_USB_INSERT_PROMPT
10.53.50 #       <_bilgus>             {
10.53.50 #       <_bilgus>                 gwps_leave_wps();
10.53.50 DBUG    Enqueued KICK _bilgus
10.53.50 #       <_bilgus>                 if (1 == gui_syncpitchscreen_run())
10.53.50 #       <_bilgus>                     return GO_TO_ROOT;
10.53.51 ***     Alert Mode level 1
10.53.51 #       <_bilgus>                 restore = true;
10.53.53 #       <_bilgus>             }
10.53.55 #       <_bilgus>             break;
10.55.52 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
10.56.40 #       <_bilgus> we can check at your current spot and pass the action if needed
10.58.06 #       <_bilgus> like if (current activity == wps) shit we do we have a way to send actions from core I hope
10.59.03 Quit    massiveH (Quit: Leaving)
10.59.07 #       <speachy> I suppose anther appropach is to _leave_ the wps (ie not unlike the existing usb screen) and re-enter it upon exiting the prompt?
11.00.33 #       <_bilgus> sounds like a good idea
11.00.45 #       <_bilgus> it probably should just return to root
11.00.58 #       <_bilgus> then we don't have to fight to keep ontop
11.01.34 #       <_bilgus> the menus will probably fight you as well since they are constantly refreshing
11.02.13 #       <_bilgus> or instead of guisync if you make it a menu then nothing else will get it
11.02.27 #       <speachy> I'd rather return to WPS if the choice is to ignore the insertion.
11.02.32 #       <_bilgus> the menu keep their own event loop
11.02.35 #       <speachy> return to <last activity>
11.03.23 #       <_bilgus> if you use a menu I think it will happen automagically when it release the vp let me try real quick
11.03.52 ***     Alert Mode OFF
11.05.10 Quit    Acou_Bass (Ping timeout: 256 seconds)
11.16.06 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
11.17.31 #       <_bilgus> damnit the menus look to auto kill when usb is in
11.23.24 #       <speachy> c!
11.23.40 Ctcp    Ignored 1 channel CTCP requests in 0 seconds at the last flood
11.23.40 #       * speachy grumbles at the cat bumping mouse focus
11.28.09 #       <johnb3> speachy The Hifi Walker I bought from *zon has a firmware version 1.3 on it. It refuses both to update to your patched image and to the official v1.2 I downloaded from their website :-(
11.28.55 #       <speachy> johnb3: huh.   that's disappointing.  any specific error, or just "Failed" ?
11.29.07 #       <johnb3> Just failed
11.29.20 #       <speachy> grab the eros q image instead and see what happens
11.29.48 #       <speachy> (I wonder if that means that hifiwalker finally switched to a different target/platform ID)
11.30.46 #       <_bilgus> ok so same deal with menus wps fights it for focus
11.31.29 #       <_bilgus> so I'd say store last activity and kill everything dump to root
11.36.09 Quit    petur (Quit: Connection reset by beer)
11.40.21 Quit    vmx (Quit: Leaving)
11.42.23 ***     Saving seen data "./dancer.seen"
11.42.47 #       <johnb3> speachy "Insert TF ... File error ... Failed". I tried both erosq and k.
11.43.07 #       <johnb3> I haven't found the 1.3 on the web though.
11.47.16 Quit    Acou_Bass (Quit: ZNC 1.7.5 - https://znc.in)
11.51.14 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
11.53.47 #       <speachy> johnb3: it's most likely the platform id string.  not much that I can do without a ROM dump though.
11.54.13 #       <speachy> (well, unless you're willing to take yours apart and get a serial console)
11.55.25 #       <johnb3> I was about to take apart the one with the broken usb socket, but not this new one.
11.55.55 #       <speachy> you could use the ingenic burn tool to extract the full ROM
11.56.02 #       <johnb3> Any idea where to search for the v1.3 on the web?
11.56.45 #       <johnb3> where can I find/download  that?
11.57.55 #       <speachy> (Alternatively it could be a datecode match that prevents downgrades?
11.58.31 #       <johnb3> I was also thinking of prevention of "downgrade".
11.58.44 #       <johnb3> by version string or date
11.59.07 #       <speachy> IIRC there's no version string, just the date.
12.01.36 Join    MrZeus [0] (~MrZeus@185.195.232.149)
12.02.50 #       <speachy> eg the agptek h3 uses "eros_agptek" instead the "erosq" every other fw target uses
12.03.11 #       <speachy> hifiwalker probably did something similar
12.03.14 #       <speachy> for v1.3 I mean
12.07.05 #       <johnb3> for the ROM dump: is this the "cloner tool"? on https://www.iletushi.com/us/updatefirmware.html
12.08.34 #       <speachy> johnb3: https://www.iletushi.com/us/map/class/big/cloner-100BH0-windowsrelease20161201.rar
12.08.47 #       <speachy> whoops, you barely beat me to it
12.09.45 #       <johnb3> Windows complains the drivers lack a signature. I need to look it up how to do that without.
12.10.14 Join    wodz [0] (~wodz@89-64-78-138.dynamic.chello.pl)
12.11.27 Quit    johnb3 (Quit: Nettalk6 - www.ntalk.de)
12.11.41 #       <wodz> speachy: How did you run my discovery util? I do it like this 1) in bootloader select tools -> adb 2) select tools second time but do not select anything 3) connect usb cable 4) adb push.... 5) adb shell 6) run discovery
12.11.52 #       <speachy> wodz: that's it
12.12.12 #       <speachy> I'm running it on the erosq and x3ii though, my rocker is with bilgus
12.12.38 #       <wodz> damn. I tried hard on agptek and in wheezy chroot and couldn't crash it
12.13.39 #       <speachy> granted my toolchain build is slightly different, but that shouldn't matter since it's dynamic linking anyway
12.13.42 #       <_bilgus> if you need me to do something with it I can run stuff tonight
12.14.24 #       <speachy> _bilgus: http://www.shaftnet.org/~pizza/discovery
12.14.51 #       <speachy> adb push that to /mnt/sd_0, adb shell, then ./discovery
12.15.29 #       <speachy> if it goes boom, the problem's (presumably) with the toolchain/etc, if it works, then we have some subtle platform differences between teh rocker and the rest
12.15.33 #       <speachy> (either is possible)
12.15.38 #       <_bilgus> ok i can try that here shortly
12.16.00 #       <wodz> preferably with some a2dp sink advertising device in discoverable state
12.16.55 #       <speachy> johnb3:  btw, I emailed hifiwalker's support folks asking about the v1.3 firmware
12.17.00 Quit    wodz (Quit: Leaving)
12.19.24 Join    johnb3 [0] (~johnb2@p5b3afcc0.dip0.t-ipconnect.de)
12.21.08 #       <_bilgus> DefaultAdapter: /org/bluez/682/hci0
12.21.08 #       <_bilgus> bluez_adapter_call_method(StartDiscovery)
12.21.08 #       <_bilgus> 	Discovering : 1
12.21.08 #       <_bilgus> !
12.21.10 #       <_bilgus> c
12.21.12 #       <_bilgus> 	Discovering : 0
12.21.14 #       <_bilgus> !
12.21.16 #       <_bilgus> c
12.21.18 #       <_bilgus> bluez_adapter_call_method(StopDiscovery)
12.21.21 #       <speachy> ok, so it works.
12.21.30 Quit    johnb3 (Client Quit)
12.21.32 #       <speachy> the problem is some target difference
12.21.40 #       <speachy> #$%#@$%!!
12.28.57 #       <speachy> DefaultAdapter: /org/bluez/284/hci0
12.29.00 #       <speachy> bluez_adapter_call_method(StartDiscovery)
12.29.01 #       <speachy>         Discovering : 1
12.29.03 #       <speachy> !
12.29.05 #       <speachy> c
12.29.08 #       <speachy> Segmentation fault
12.29.09 #       <speachy> y
12.29.12 #       <speachy> (ignore the 'y')
12.29.16 #       <speachy> identical binary
12.29.58 Join    johnb3 [0] (~johnb2@p5b3afcc0.dip0.t-ipconnect.de)
13.12.17 Join    lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
13.20.17 #       <johnb3> speachy I installed the driver, but I am overwhelmed by the Cloner GUI and don't know what to do.
13.22.38 #       <johnb3> So unless someone can give me intructions or have a Teamviewer session, I won't be of much help.
13.42.26 ***     Saving seen data "./dancer.seen"
13.45.48 Quit    beencubed (Quit: Leaving)
14.04.47 #       <mendel_munkis> any advice on compiling a 2012 rockbox dev build? make tells me a bunch of things don't match the target pattern.
14.06.31 #       <speachy> ew.  you're presumably going to need 2012-era toolchains too.
14.07.01 #       <speachy> johnb3: I haven't figured out how to get this thing to _read_ yet.
14.31.52 #       <johnb3> bbl
14.31.58 Quit    johnb3 (Quit: Nettalk6 - www.ntalk.de)
14.37.17 #       <mendel_munkis> do we have old snapshots available somewhere?
14.40.39 #       <speachy> we have old releases, there's probably one from that era
14.41.51 #       <mendel_munkis> thanks
14.44.38 Join    petur [0] (~petur@rockbox/developer/petur)
14.44.47 #       <mendel_munkis> bah didn't make it into stable until 3.14 wwhich I can build myself.
15.29.18 #       <_bilgus> mendel I may have a backup at home of the OOOOLLLD toolchain on a vm
15.29.57 #       <_bilgus> may its so old its hard telling if I tossed it but probably still have it on a backup if not
15.31.37 #       <_bilgus> oh and I think I made a vm at some point or at least had a backup of the one rb provided
15.32.04 #       <mendel_munkis> the oscilloscope bug exists in 3.14 (the earliest fuze+ version I can get my hands on) so it's definitely not because of any recent changes
15.32.32 #       <mendel_munkis> I wanted to do a bisect but I suspect there is no good version to bisect against
15.32.41 #       <_bilgus> https://www.mediafire.com/file/im5u2t2hbmct4m0/Ubuntu_16.10_Yakkety_%252864bit%2529.7z/file
15.33.08 #       <_bilgus> the logic of oscope isn't changing though
15.33.30 #       <_bilgus> it has no idea the framebuffer is copied backwards when flipped
15.33.36 #       <mendel_munkis> also the commit message on the originaloscope commit sounds like the horizontal update may be hacky.
15.34.56 #       <_bilgus> the whole thing is hacky (backend) but it is sane
15.35.12 #       <_bilgus> telling you I vetted the backend for a week straight
15.35.35 #       <mendel_munkis> I'm not saying it's not
15.36.08 #       <_bilgus> every time I thought it was wrong, it was wrong but at driver level
15.36.49 #       <mendel_munkis> I meant  to say I think it's a bug in the driver since paumery wrote it
15.37.22 #       <_bilgus> if its at driver level that gets broad real fast
15.37.37 #       <mendel_munkis> yup.
15.37.46 #       <_bilgus> then you have to look at all trhe places people hacked around it
15.38.14 #       * _bilgus did not find it fun
15.40.33 #       <mendel_munkis> I want to check commit d9177c and seeif it shows up there.
15.41.40 #       <_bilgus> if its always reproducible if you don't find any smoking guns then make the screen backend aware of the flip and move the vp 1 px to right or left accordingly
15.42.05 #       <mendel_munkis> huh?
15.42.30 ***     Saving seen data "./dancer.seen"
15.42.51 #       <_bilgus> the way the screen backend works is that it snapshots a portion of the bitmap and it copies it back scrolled
15.43.19 #       <_bilgus> so that update line is drawn as a single pixel at screen edge
15.44.18 #       <_bilgus> whats happening I suspect is that instead of copying Vert col 0 and pasting at v col 1 its overlapping a bit
15.44.34 #       <_bilgus> grabs col 0 too and propagates into a wall
15.45.28 #       <_bilgus> but the screen flip shouldn't have that power
15.46.01 #       <_bilgus> how would it alter the coords above it we aren't snapshotting the actual LCD buffer
15.46.31 #       <_bilgus> its more likely a driver bug as in it isn't set up right
15.47.13 #       <_bilgus> but we then shift everything by 1 px further and keep it out of that region in the LCD
15.47.57 #       <_bilgus> is there some weird backporch scrolling function coming into effect here?
15.49.10 #       <_bilgus> IDK just wandering atm I guess I have hardware in hand I'll start screwing around
15.49.58 #       <mendel_munkis> I have a few theories but I have a class soon. I'll try them out in a few hours.
16.19.06 #       <braewoods> _bilgus: how do i find out how much stack space is available in RB?
16.20.25 Quit    JanC (Remote host closed the connection)
16.20.48 Join    JanC [0] (~janc@lugwv/member/JanC)
16.28.36 #       <speachy> braewoods: under the debug menu there's thread/stack dump that includes stack usage
16.29.05 #       <braewoods> speachy: ok... i was wondering if a single 4K allocation would overload the stack.
16.40.05 #       <speachy> braewoods: almost certianly
16.41.06 #       <speachy> I think default stack size is in the range of 512B, though individual stacks can be larger, especially codecs.
16.48.47 Quit    MrZeus (Ping timeout: 268 seconds)
17.12.20 #       <braewoods> speachy: ok... good to know
17.17.38 #       <speachy> plugins get a decent stack I think
17.18.32 #       <speachy> default stack size is 1K.
17.19.50 #       <speachy> but individual plugins can and do go (much) larger.
17.30.20 Quit    lebellium (Quit: Leaving)
17.42.34 ***     Saving seen data "./dancer.seen"
18.08.28 #       <braewoods> speachy: what's the difference between plugin_get_buffer and plugin_get_audio_buffer?
18.16.30 #       <gevaerts> plugin_get_buffer() get free plugin RAM. plugin_get_audio_buffer() stops playback so you can have *all* RAM
18.19.54 Join    MrZeus [0] (~MrZeus@185.195.232.149)
18.32.21 #       <braewoods> ok.
18.42.25 #       <mendel_munkis> tried taking an oscope screenshot and it hard paniced.
18.50.31 #       <_bilgus> mendel_munkis, thats interesting
18.51.10 #       <_bilgus> I assume its only on device?
19.05.22 #       <mendel_munkis> the panic or the bug?
19.08.48 #       <mendel_munkis> yeah the bug is only on hardware
19.09.16 #       <mendel_munkis> no testing until the battery drains. (from a full charge)
19.24.38 Quit    MrZeus (Ping timeout: 256 seconds)
19.26.01 Quit    petur (Quit: Leaving)
19.35.33 Quit    bluebrother (Disconnected by services)
19.35.38 Join    bluebrother^ [0] (~dom@rockbox/developer/bluebrother)
19.35.51 Join    fs-bluebot_ [0] (~fs-bluebo@55d44815.access.ecotel.net)
19.38.00 Quit    fs-bluebot (Ping timeout: 256 seconds)
19.38.26 #       <_bilgus> I had the same the second time it got wires
19.39.13 #       <_bilgus> how do you screenshot from the device?
19.42.36 ***     Saving seen data "./dancer.seen"
20.00.45 Quit    ps-auxw (Ping timeout: 240 seconds)
20.06.49 Join    ps-auxw [0] (~arneb@p548d590b.dip0.t-ipconnect.de)
20.11.18 Quit    ps-auxw (Disconnected by services)
20.11.26 Join    ps-auxw [0] (~arneb@p548d571d.dip0.t-ipconnect.de)
20.25.13 Quit    speachy (Quit: WeeChat 2.8)
20.28.45 #       <mendel_munkis> turn on screendump and plug in a usb
20.31.00 #       <_bilgus> what was the panic?
20.31.20 #       <mendel_munkis> stkov USB
20.31.35 #       <mendel_munkis> yeah I know it's not directly a lcd related panic
20.31.55 #       <_bilgus> it quite possibly still is
20.57.19 Join    kugel_ [0] (~kugel@ip5b40dab6.dynamic.kabel-deutschland.de)
20.57.20 Quit    kugel_ (Changing host)
20.57.20 Join    kugel_ [0] (~kugel@rockbox/developer/kugel)
21.00.54 Quit    kugel (Ping timeout: 260 seconds)
21.06.23 #       <_bilgus> mendel its just happens that the stack is too small it gets covered up by the extra afforded by the screendump but then its time to pay the piper
21.08.23 #       <mendel_munkis> that sounds like a bug to me
21.23.49 #       <_bilgus> mendel_munkis, added 0x80 and screen dump says 94% used after screendump
21.24.01 #       <_bilgus> sounds like a good guess
21.24.37 #       <mendel_munkis> added 0x80 to reg_3_val?
21.24.57 #       <_bilgus> no usb stack
21.25.00 #       <mendel_munkis> oh to the stack size
21.39.43 #       <fs-bluebot_> Build Server message: New build round started. Revision 611c187, 293 builds, 7 clients.
21.40.00 #       <_bilgus> mendel there you go
21.42.37 ***     Saving seen data "./dancer.seen"
21.47.11 Join    Stanley00 [0] (~stanley00@unaffiliated/stanley00)
21.51.06 #       <braewoods> _bilgus: random question. why do ROM chips come in different sizes for the smallest addressable unit?
21.51.15 #       <braewoods> e.g., some are bytes some are words etc
21.51.42 #       <_bilgus> my guess would be speed
21.52.06 #       <braewoods> i see
21.52.12 #       <_bilgus> also arm likes word aligned but sheer speculation
21.52.24 #       <braewoods> i saw these on coldfire mainly
21.52.48 #       <_bilgus> could just be whatever was available too
21.53.18 #       <_bilgus> uh we have someone round here that is into ram stuff but hell if I could tell you whom
21.53.39 #       <_bilgus> like in industry
21.53.47 #       <_bilgus> might ask in -community
21.54.16 #       <braewoods> makes programming them a bit of a chore.
21.54.22 #       <mendel_munkis> might it be time to remove experimental from there?
21.54.29 #       <braewoods> i suspect the byte order of these is dependent on the host CPU
21.54.54 #       <_bilgus> lol mendel IDK its still kinda an experiment
21.55.06 #       <mendel_munkis> also it's interesting that screendump usually doesn't panic. (although this isn't the first time)
22.03.37 #       <fs-bluebot_> Build Server message: Build round completed after 1434 seconds.
22.03.41 #       <fs-bluebot_> Build Server message: Revision 611c187 result: 4 errors 0 warnings
22.22.34 #       <_bilgus> gotta figure it still might given the right / wrong circumstance..
22.24.15 #       <_bilgus> I was incredulous when I saw 4 errors
22.24.27 #       <_bilgus> NFW!
22.25.02 #       <_bilgus> I guess the builders failed
22.27.39 Quit    efqw (Quit: Connection closed for inactivity)
22.28.53 Join    beencubed [0] (~beencubed@209.131.238.248)
22.51.08 Quit    tchan (Quit: WeeChat 2.8)
23.13.24 Quit    [7] (Disconnected by services)
23.13.31 Join    TheSeven [0] (~quassel@rockbox/developer/TheSeven)
23.14.06 Join    tchan [0] (~tchan@lunar-linux/developer/tchan)
23.42.39 ***     Saving seen data "./dancer.seen"