--- Log for 28.10.120 Server: card.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 days and 20 hours ago 00.04.43 # speachy which bug? 00.06.04 # saratoga: a trap gcc inserts because it thinks there's a null pointer dereference going on. 00.07.58 # was able to fix nearly all of the traps, and one was definitely a real bug, with nearly all the rest in the skin/theme code. 00.08.09 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 00.08.14 # the decoder is fairly modified from the original ffmpeg version 00.08.21 # its quite possible something we broke 00.08.41 # where does gcc insert traps? 00.08.59 # gcc 4.9 enables -fdelete-null-pointer-checks by default 00.09.45 # and if its optimizer determines that you're dereferencing a null pointer, it deliberately bails. 00.10.00 # (because that's nominally illegal) 00.10.40 # Build Server message: New build round started. Revision 41a6da6, 293 builds, 8 clients. 00.10.46 # but it doesn't tell you where in the code it thinks there is a null pointer? 00.10.48 # aand this ^^ will globally disable it 00.11.20 # the -Wnull-dereference (?) wasn't added until GCC6. :/ 00.12.24 # there was a lot of teeth gnashing over this back in the day, but I'd thought we were generally okay due to some of our targets being on gcc4.9 for a while now. apparently not entirely.. 00.13.17 # when we update to GCC6 or newer we can flip that back on again and see what the improved diagnostics tell us 00.13.39 # I have a suspicion that some of our sim builds are going to turn yellow 00.13.58 # but I'll clean that mess up in the morning. 00.14.44 # speachy: i'm surprised you turned it on globally. 00.16.06 # braewoods: arm and m68k didn't flag the same things. of the remaining stuff, they agreed only about lua. 00.16.18 # I see. 00.16.45 # strange how GCC is 00.16.48 # I got an issue when plugin usb on m5 and using original usb-hiby.c, it will show PANIC: mount 0 when unplug and exit usb mode 00.16.49 # and the ones I saw in (eg) the SDL plugins seemed to be false positives. 00.16.52 # that feature was new in GCC9 afaik 00.17.00 # 4.9 00.17.06 # so it probably has issues 00.17.41 # so god only knows what other target-dependent heisenbugs there were lurking. 00.18.20 # eg m68k complained about wmapro, but arm complained about libflac 00.19.08 Quit [7] (Disconnected by services) 00.19.15 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 00.19.27 # (granted slightly different -O flags for each...) 00.22.46 # meanwhile, the theme stuff in g#2918 is probably legit. reversi is a false positive. 00.22.47 # Gerrit review #2918 at http://gerrit.rockbox.org/r/2918 : Fix multiple potential null pointer dereferencess by Solomon Peachy 00.23.36 Quit Stanley00 (Read error: Connection reset by peer) 00.24.04 # (especially in the face of malicious or simply badly-coded themes.. makes sense to not crash, if possible) 00.24.07 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 00.25.17 # whats the MIPS FPU useful for in our code? 00.27.28 Quit prof_wolfff (Ping timeout: 265 seconds) 00.30.44 # it isn't, though there is one codec that's able to use FP. Oh, and I think Quake requires FP too. 00.31.09 # on native targets our threading code isn't FP-aware at all. 00.31.31 # I have a half-started patch to change that, but I keep finding larger fires to fight. 00.32.30 # speachy: floating point? 00.32.49 # what do threads have to do with floating point? 00.44.21 # which codec can use FP? 00.45.02 # a few still have the fp code paths, but i'm not sure they still work since we gutted them pretty badly 00.49.54 # Build Server message: Build round completed after 2353 seconds. 00.49.56 # Build Server message: Revision 41a6da6 result: 0 errors 48 warnings 01.07.19 Quit saratoga (Remote host closed the connection) 01.09.35 # <__builtin> the SDL plugins and puzzles all use floating-point 01.10.20 *** Saving seen data "./dancer.seen" 02.39.51 DEBUG EOF from server (Connection reset by peer) (snapshot: netstuff.c line 545) 02.39.51 *** Cleanup 02.39.51 *** Cleanup 02.39.51 *** No seen item changed, no save performed. 02.39.51 *** Exit 02.39.52 *** Started Dancer V4.16 02.39.52 *** Connected to irc.freenode.net on port 6667 02.39.52 *** Logfile for #rockbox started 02.39.53 Mode "logbot :+i" by logbot 02.39.54 Ctcp Version from freenode-connect!frigg@freenode/utility-bot/frigg 02.39.59 *** Server message 501: 'logbot :Unknown MODE flag' 02.40.00 Join logbot [0] (~rockbox@stuffed.shaftnet.org) 02.40.00 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 02.40.00 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 02.40.00 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 02.40.00 Join fs-bluebot [0] (~fs-bluebo@55d46dc5.access.ecotel.net) 02.40.00 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 02.40.00 Join pixelma [0] (marianne@rockbox/staff/pixelma) 02.40.00 Join amiconn [0] (jens@rockbox/developer/amiconn) 02.40.00 Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net) 02.40.00 Join Barlow [0] (~barlow@unaffiliated/barlow) 02.40.00 Join funman [0] (~fun@rockbox/developer/funman) 02.40.00 Join Airwave [0] (~Airwave@ti0006a400-0518.bb.online.no) 02.40.00 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 02.40.00 Join akaWolf [0] (~akaWolf@akawolf.org) 02.40.00 Join kugel [0] (~kugel@rockbox/developer/kugel) 02.40.00 Join Rondom [0] (~rondom@modo.nonmodosedetiam.net) 02.40.00 Join atsampson [0] (~ats@cartman.offog.org) 02.40.00 Join JanC [0] (~janc@lugwv/member/JanC) 02.40.00 Join Oksana [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide) 02.40.00 Join Galois [0] (djao@efnet-math.org) 02.40.00 Join ender| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3) 02.40.00 Join igitoor [0] (igitur@unaffiliated/contempt) 02.40.00 Join t0mato [0] (~t0mato@193.32.127.159) 02.40.00 Join mutax [0] (~mutax@ip5f590aa6.dynamic.kabel-deutschland.de) 02.40.00 Join mendel_munkis [0] (~mendelmun@ool-435680b7.dyn.optonline.net) 02.40.00 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) 02.40.00 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 02.40.00 Join Moarc [0] (~chujko@a105.net128.okay.pl) 02.40.00 Join _bilgus [0] (~bilgus@65.186.35.190) 02.40.00 Join edhelas [0] (9d94237298@149-210-220-39.colo.transip.net) 02.40.00 Join Strife89 [0] (sid399903@gateway/web/irccloud.com/x-frywjzoyenhdxjms) 02.40.00 Join SammysHP [0] (~SammysHP@faol.sammyshp.de) 02.40.00 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) 02.40.00 Join yosafbridge [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de) 02.40.00 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 02.40.00 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) 02.40.00 Join speachy [0] (~speachy@209.2.65.77) 02.40.00 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 02.40.00 Join Tsesarevich [0] (Tsesarevic@fluxbuntu/founder/joejaxx) 02.40.00 Join ps-auxw [0] (~arneb@p548c6f52.dip0.t-ipconnect.de) 02.40.00 Join Slasherii [0] (~miipekk@itu.ihme.org) 02.40.00 Join galaxy_knuckles [0] (~gknux@unaffiliated/galaxy-knuckles/x-1756549) 02.40.00 Join rogeliodh [0] (~rogeliodh@rogeliodh.dev) 02.40.00 Join _3dsv [0] (~3dsv@068-184-255-059.res.spectrum.com) 02.40.00 Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 02.40.00 Join kadoban [0] (kadobanmat@gateway/shell/matrix.org/x-ibzwjrmlfzihcpnq) 02.40.00 Join heredoc [0] (heredoc@2a01:7e01::f03c:91ff:fec1:de1d) 02.40.00 Join bzed [0] (~bzed@shell.bzed.at) 02.40.00 Join danielp3344 [0] (danielp334@gateway/shell/matrix.org/x-aggpelywdczulgkq) 02.40.00 Join blbro[m] [0] (blbrostrat@gateway/shell/matrix.org/x-tpncpihvtlasucfq) 02.40.00 Join efqw [0] (uid412670@gateway/web/irccloud.com/x-cjmgdgoswnanyjsg) 02.40.00 Join fauweh [0] (~root@ithaqua.unzane.com) 02.40.00 Join toruvinn [0] (~toruvinn@87-205-132-1.adsl.inetia.pl) 02.40.00 Join APLU [0] (~mulx@2a03:7220:8081:2900::1) 02.40.00 Join paulk-leonov [0] (~paulk-leo@vpn-0-22.aquilenet.fr) 02.40.00 Join sakax [0] (~r0b0t@unaffiliated/r0b0t) 02.40.00 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 02.40.00 Join lemon_jesus [0] (~lemon_jes@c-73-9-49-209.hsd1.in.comcast.net) 02.40.00 Join braewoods [0] (~braewoods@learnprogramming/staff/braewoods) 02.40.00 Join genevino [0] (~genevino@m2m.pm) 02.40.00 Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) 02.40.00 Join TheSphinX^ [0] (~briehl@srv001.nosupamu.de) 02.40.00 Join Ckat [0] (~Ckat@xn--z7x.xn--6frz82g) 02.40.00 Join dys [0] (~dys@aurora.ydns.eu) 02.40.00 Join Soap [0] (~Soap@rockbox/staff/soap) 02.40.00 Join vup [0] (~~~~@46.101.193.235) 02.40.00 Join alexbobp [0] (~alex@meowface.org) 02.40.00 Join Xeha [0] (~Xeha@unaffiliated/xeha) 02.40.00 Join XDjackieXD [0] (~jackie@irc.chaosfield.at) 02.40.00 Join skrzyp [0] (~skrzyp@skrzyp.net) 02.40.00 Join klock [0] (~freeklock@unaffiliated/klock) 02.40.00 Join jerwin [0] (~flippy-fl@unaffiliated/flippy) 02.40.00 Join ArsenArsen [0] (~Arsen@kshare/developer/ArsenArsen) 02.40.00 Join CommunistWitchDr [0] (quassel@024-217-039-226.res.spectrum.com) 02.40.00 Join sh4 [0] (shapeless@unaffiliated/sh4) 02.40.00 Join ecs [0] (esawady@d2evs.net) 02.40.00 Join asaba [0] (~asaba@103.113.159.184) 02.40.00 Join TorC [0] (~Tor@fsf/member/TorC) 02.40.00 Join __builtin [0] (~quassel@rockbox/developer/builtin) 02.40.00 Join lonoxmont [0] (~lonoxmont@024-180-058-254.res.spectrum.com) 02.40.00 Join kirvesAxe [0] (kirvesaxe@aulis.sange.fi) 02.40.00 Join mikroflops [0] (~yogurt@c188-150-217-176.bredband.comhem.se) 02.40.00 Join Topy44 [0] (OOvo1SKgJD@bellatrix.uberspace.de) 02.40.00 Join benedikt93 [0] (~quassel@unaffiliated/benedikt93) 02.40.00 Join ParkerR [0] (~ParkerR@unaffiliated/parkerr) 02.40.00 Join amdj [0] (~aaron@freenode/staff/atheme.amdj) 02.40.00 Join prg318 [0] (~prg@deadcodersociety/prg318) 02.40.00 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) 02.40.00 Join bleb [0] (~cm@unaffiliated/bleb) 02.40.00 Join aevin [0] (~brootvors@unaffiliated/aevin) 02.40.00 Join user890104 [0] (~Venci@freemyipod.org) 02.40.00 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 02.40.00 Join rasher [0] (~rasher@rockbox/developer/rasher) 02.40.00 Join copper [0] (~copper@unaffiliated/copper) 02.40.00 Join plum [0] (~plum@unaffiliated/plum) 02.40.00 Join @ChanServ [0] (ChanServ@services.) 02.40.00 Join trfl [0] (~ed@static.59.110.40.188.clients.your-server.de) 02.40.00 Join shrizza [0] (~shrizza@oki-180-131-209-187.jptransit.net) 02.40.00 Join blackyus- [0] (~blackyus1@ip189.ip-144-217-213.net) 02.40.00 Join xcin [0] (~x@159.203.132.140) 02.40.00 Join rudi_s [0] (~simon@bmi.informatik.uni-erlangen.de) 02.42.35 Join vvrng [0] (~vvrng@m91-128-94-73.cust.tele2.hr) 03.28.23 Join petur [0] (~petur@199.59.5.11) 03.28.23 Quit petur (Changing host) 03.28.23 Join petur [0] (~petur@rockbox/developer/petur) 03.55.58 Quit Moarc (Quit: i znowu NADMUCHAƁ BALONA) 03.57.26 Join Moarc [0] (~chujko@a105.net128.okay.pl) 03.58.08 Quit Moarc (Client Quit) 04.00.02 Join Moarc [0] (~chujko@a105.net128.okay.pl) 04.00.54 Quit Moarc (Client Quit) 04.02.47 Join Moarc [0] (~chujko@a105.net128.okay.pl) 04.02.55 Quit Moarc (Client Quit) 04.38.37 Join Moarc [0] (~chujko@a105.net128.okay.pl) 04.39.56 *** Saving seen data "./dancer.seen" 04.40.52 Quit Moarc (Client Quit) 04.43.02 Join Moarc [0] (~chujko@a105.net128.okay.pl) 05.37.12 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 05.55.26 # <_bilgus> Well I found the Theme change crash a single uniniatialized variable called stride 06.02.21 Quit Oksana (Ping timeout: 258 seconds) 06.10.52 Quit pixelma (Quit: .) 06.10.52 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 06.13.26 Join amiconn [0] (jens@rockbox/developer/amiconn) 06.13.27 Join pixelma [0] (marianne@rockbox/staff/pixelma) 06.39.59 *** Saving seen data "./dancer.seen" 06.41.43 Join prof_wolfff [0] (~prof_wolf@26.red-83-54-195.dynamicip.rima-tde.net) 06.48.36 Join johnb7 [0] (~johnb2@p5b3afaa7.dip0.t-ipconnect.de) 07.25.32 Quit pamaury (Ping timeout: 265 seconds) 07.26.41 Quit bzed (Remote host closed the connection) 07.26.57 Join bzed [0] (~bzed@shell.bzed.at) 07.34.14 Quit johnb7 (Ping timeout: 265 seconds) 07.44.17 # Eh. I was hoping to run valgrind on Rocker to trace memory leaks and such. I was able to crosscompile it but when run it hits out-of-memory condition. 07.51.23 # Build Server message: New build round started. Revision 621e363, 293 builds, 8 clients. 07.53.22 # and kernel on rocker is compiled without swap support 07.59.07 Join livvy [0] (~livvy@gateway/tor-sasl/livvy) 08.03.17 # braewoods: when we switch threads, the CPU state (eg registers) needs to be stored so it can be restored later. 08.03.45 # braewoods: that needs to include the FPU state, or different threads that try to use the FPU will trash each other. 08.08.04 Quit Stanley00 () 08.09.54 # saratoga: the only FP-using codec (to my knowledge) is the recently-added one that adds support for the obscure ZX Spectrum chiptunes .VTX format. 08.10.56 # (I only committed it so I could use it as a test case to work out target/platform-level FP bugs and FP-aware threading) 08.11.54 # wodz: I have to imagine that the uisim on a host pc would get us 90% of the way there wrt valgrind. 08.12.32 # speachy: I am debuging bluetooth stuff so not really 08.13.17 # wodz: wellllllll... a $5 dongle turns any PC into a bluetooth-enabled one. :D 08.13.20 # Build Server message: Build round completed after 1317 seconds. 08.13.23 # Build Server message: Revision 621e363 result: All green 08.14.50 # speachy: The catch is agptek uses bluez4, while all distros from last 5 or so years bluez5. This two have incompatible dbus api 08.15.15 # well, it was a nice idea while it lasted. 08.17.52 # hmm, In theory I could setup weezy in chroot to play. It was the last debian shiping bluez4 08.19.07 # wheezy I mean 08.21.13 # _bilgus: wrt your comments on 2918, I only fixed up stuff that could lead to a direct nullptr dereference. 08.21.57 # (using gcc's "helpful" silent insertion of trap/udf as a guide where to look....) 08.22.33 # <_bilgus> hmm not sure hth it determined that but uh ok 08.22.54 # <_bilgus> the double pointer one though? 08.23.34 # the double pointer wasn't flagged but I agree it should be checked explicitly. as skin_render_viewport() doesn't check first. 08.24.52 # <_bilgus> as far as I can tell lebillums issue is fixed by the two of these patches together 08.25.33 # <_bilgus> probably the 'questionable areas' 08.26.07 # <_bilgus> I'll mark the FS as Needs Tested 08.30.08 # <_bilgus> I can't believe how long I looked for that bug for what it was I only caught it once I set the sim to crash on FB overrun 08.31.13 # <_bilgus> I found it impossible to trace on the Rocker and actually make sense of what address 08.32.21 # _bilgus: wrt skin_tokens.c:740, what do you mean by "these"? 08.33.51 # <_bilgus> element and params but if your trap is gone then no worries? 08.34.26 # ok, params. adding that check. 08.35.15 # <_bilgus> get_token_value should probably explictly check too 08.35.21 # already added 08.36.06 # <_bilgus> its amazing how that bit of extra pointer checking makes this code much more palatable lol 08.36.33 # <_bilgus> First time I looked at that mess I was like WTF have I gotten myselft into 08.37.06 # <_bilgus> I chased that bug from one end through the other I probably should have left all the logfs 08.37.10 # IMO all of these are legit needed, if only for crash prevention for theme developers 08.37.36 # <_bilgus> Yeah that was my thought too the theme engine is v. unforgiving 08.39.00 # <_bilgus> ok so mendel has a screen flipping issue on the fuze+ I guess I'll investigate that for a bit 08.40.00 *** Saving seen data "./dancer.seen" 08.40.57 # <_bilgus> ah ok so the sbs kinda pushes in at the bottom before if flips to the top 08.44.12 # <_bilgus> I think this might be a good case for the improved viewport code I think we can do it in rb directly 08.49.55 Join MrZeus [0] (~MrZeus@2a02:c7f:70d0:6a00:857e:c3d:75f3:53b) 08.50.29 # _bilgus: you assigned #13249 to Daniel Stenberg 08.50.49 # and then fixed it. guess I should have scrolled to the next page of my mailbox 08.53.34 # <_bilgus> yeah my name isn't in the list so when I try it does badger 08.54.55 # <_bilgus> assign to me works so no worries 09.01.42 # <_bilgus> oh well the fuze+ issue is with the device directly 09.02.29 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 09.05.20 # <_bilgus> ok so If I cange the internal one everything that uses mem set will probably draw wrong so I guess I need to rejigger only when the final copy to the device lcd happens 09.05.26 # Build Server message: New build round started. Revision a605cdf, 293 builds, 8 clients. 09.06.00 # <_bilgus> (lcd_get_address) 09.32.18 # Build Server message: Build round completed after 1612 seconds. 09.32.21 # Build Server message: Revision a605cdf result: All green 09.37.21 # <_bilgus> mendel_munkis, see response in FS 09.42.33 Join johnb7 [0] (~johnb2@p5b3afaa7.dip0.t-ipconnect.de) 09.49.37 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 09.51.36 Quit johnb7 (Ping timeout: 256 seconds) 09.55.53 # speachy: https://gerrit.rockbox.org/r/#/c/rockbox/+/2925/ ? 09.56.21 # braewoods: tested? 09.56.35 # not yet. 09.56.57 # i'll need to write some temporary code for that. 09.57.15 # i'll test it on an unused memory region to see how well it works. 09.57.28 # the others were mechanical changes; this is functionally different. given the bricking risk of bugs in flash code, this needs to be tested first. 09.57.48 # i was planning on it in any case 09.58.04 # let me see 09.58.08 # ok. it's over here. 09.59.02 # i'll write some short code to erase an unused region 10.01.26 # (we don't want some poor user to be the first to test this. granted, "Some poor user" probably won't be trying to flash their 15-year-old iriver device) 10.02.34 Join johnb7 [0] (~johnb2@p5b3afaa7.dip0.t-ipconnect.de) 10.29.51 # oh, in other news, I ordered a couple of those "Cherry Pi" boards that sport an Allwinner V3s SoC. 10.40.04 *** Saving seen data "./dancer.seen" 10.44.18 # a nicer form factor to work with than the PineCubes 10.45.15 Quit massiveH (Quit: Leaving) 10.46.21 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 10.59.49 Quit johnb7 (Ping timeout: 258 seconds) 11.08.43 Join johnb7 [0] (~johnb2@p5b3afaa7.dip0.t-ipconnect.de) 11.27.21 Join johnb3 [0] (~johnb2@p5b3afaa7.dip0.t-ipconnect.de) 11.36.12 # speachy: one thing to note about ARM... unlike x86 it does heavily benefit from code compiled with the latest compatible instruction sets 11.36.45 # i worked with it a few times in the past and setting the compiler architecture for it was very helpful 11.37.48 # braewoods: we already use target-appropriate compiler options; anything more than that will require more hand-written asm. :) 11.58.11 # speachy: I found the issue with mass storage on the m3k 11.58.35 # hmm? 11.59.21 # rb is loading the correct modules but it immediately unloads them for some reason 12.00.14 # I tried the exact same insmod commands from usb-fiio.c in the console and it works just fine 12.01.07 # (verified them with the stock player binary too) 12.01.34 # rockbox unloads them when usb_enabled(false) is called. 12.02.01 # _bilgus: thank you. but I can't find the broken memset cal to which you are referring. 12.03.40 # https://www.irccloud.com/pastebin/dO8UESfI/ 12.03.52 # this is what happens when I plug in the USB cable 12.05.24 # https://www.irccloud.com/pastebin/AIc5K9V5/ 12.05.50 # on the computer side it's clear that the module has been unloaded immeidately 12.06.14 # *immediately 12.24.32 Join tchan1 [0] (~tchan@c-98-220-238-152.hsd1.il.comcast.net) 12.26.43 Quit tchan (Ping timeout: 256 seconds) 12.28.24 Quit pamaury (Ping timeout: 260 seconds) 12.29.17 # speachy: huh. reminds me of a weird issue i had once where the usb printer kernel module was causing issues when cups wanted to control the usb printer directly. i had to unload it. there seemed to be some kind of conflict going on. 12.29.38 # efqw: the rockbox code is pretty consistent; it would only trigger the unload if we received an event saying it had been unplugged. 12.30.25 # braewoods: could be the classic usblp driver vs the libusb-based cups backend. the latter being far more flexible. 12.32.13 # i saved some space at one of desktops in our home by replacing the giant tower with a newer small desktop box that is now mounted to the monitor 12.32.33 # they never used the full capabilities of the old one so this is a good compromise 12.32.40 Quit johnb7 (Ping timeout: 246 seconds) 12.40.05 *** Saving seen data "./dancer.seen" 12.51.57 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 12.55.44 Quit tchan1 (Ping timeout: 240 seconds) 13.05.16 # but I have no idea why it's receiving the unplug event in the first place 13.05.42 # the screen still shows the USB plug icon instead of the rb menu 13.06.08 # so rb thinks it's both plugged in and unplugged? 13.06.41 # <_bilgus> mendel_munkis, there is no broken memcpy? 13.14.02 Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) 13.15.34 # I must have misunderstood you. Did you figure out what the issue with the statusbar is? 13.15.50 Join johnb7 [0] (~johnb2@p5b3afaa7.dip0.t-ipconnect.de) 13.20.05 Quit johnb7 (Ping timeout: 240 seconds) 13.20.29 # _bilgus: they said memset, not memcpy? 13.20.38 # <_bilgus> the device writes a register to enable screen flipping ie. its native screen flippin, I was saying we will need to make a custom memcpy that flips/rotates/transform 13.21.10 # <_bilgus> essentially a blitter 13.22.05 # <_bilgus> sorry had memset on my mind when I typed that 13.26.23 # memset is mainly used for zero-initialize... 13.26.32 # never did understand why any other values would be used 13.26.43 # Build Server message: New build round started. Revision c85d8e2, 293 builds, 8 clients. 13.29.33 # braewoods: to initialize to some other value? 13.29.54 # <_bilgus> braewoods, sometimes you need values other than zero i'm sure you could find a few places around most c code bases 13.30.07 # _bilgus: I already disproved that it's the native flipping that's broken. ie if the register is set without rockbox relizing everything works fine. 13.31.22 # <_bilgus> oh? it didn't look like it did anything but set the register I'll do a text search for it again 13.32.53 # That's why I was thinking it was something in the viewports. 13.34.21 # mendel_munkis: obviously but i've never seen it. 13.38.22 # <_bilgus> mendel_munkis, is this triggered by the button flip part? 13.38.45 # oh wait that's weird. I did another test. and it happens whenever it's uside down regardless of RB settings 13.39.12 # when the register is set upside down 13.40.08 # <_bilgus> I think its prob an error in the device or maybe something missing but uh no clue 13.41.59 # <_bilgus> I think its an important feature for that target though so I might see about adding it manually 13.42.25 # <_bilgus> after I get the other stuff off my list 13.42.56 # Build Server message: Build round completed after 974 seconds. 13.43.01 # Build Server message: Revision c85d8e2 result: All green 13.50.14 Quit tchan (Ping timeout: 260 seconds) 13.52.52 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) 13.53.45 # "When a window area is set by registers R50h ~R53h, only the addressed DRAM area is updated based on I/D [1:0] and AM bits setting." If I'm reading that correctly when lcd_update_rect() is not the whole screen it will preform an update with the correct orientation in a mirrored location. 13.55.14 # <_bilgus> sounds right to me 13.55.47 # so I should be able to fix it with an if in update_rect will try that in a few. 13.56.05 # thanks for the help. 13.56.28 # although I wonder if the speed cost woul be significant. 13.57.47 # <_bilgus> in the blitter? it would add a bit of slowdown extra if branch and maybe slightly less optimized than std memcpy 13.58.07 # <_bilgus> or you mean the device native method? 13.58.13 # I'm not touching thememcopy justthe rectangle coords. 13.58.26 # in the dvice drive. 13.58.44 # <_bilgus> I think thats untenable ultimately 14.20.22 Join tchan1 [0] (~tchan@c-98-220-238-152.hsd1.il.comcast.net) 14.36.23 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 14.38.48 Join johnb7 [0] (~johnb2@p5b3afaa7.dip0.t-ipconnect.de) 14.40.09 *** Saving seen data "./dancer.seen" 14.47.45 Quit johnb7 (Ping timeout: 240 seconds) 14.52.40 Part edhelas 14.53.52 Join edhelas [0] (9d94237298@149-210-220-39.colo.transip.net) 14.55.54 # _bilgus: following your comment in FS#13249, I wanted to try the latest build but now my YP-R1 crashes at startup 14.55.56 # http://www.rockbox.org/tracker/task/13249 SBS Info viewport not refreshing when used as a conditional (bugs, requires testing) 14.56.12 # fresh install, my theme not loaded 14.56.52 # it crashes on the rockbox splash screen 14.57.14 # <_bilgus> eh crap and its not happening in the sim either right? 14.57.36 # lebellium: did the previous nightly build work? 14.58.02 # Don't know about the UI sim as I'm using Windows and the latest rasher version is dated 2018. 14.58.10 # I can try the previous nightly build 14.58.17 # <_bilgus> ok i'll try sim 15.01.21 # f62eee569c-201027 is working 15.02.28 # but 41a6da6 does not? 15.05.00 # it does work too 15.07.42 # there are only three commits since then. One can't be responsible for the crash, leaving only two. 15.08.21 # lebellium: http://www.shaftnet.org/~pizza/rb-r1.zip 15.10.29 # <_bilgus> I see it I think 15.10.55 # speachy: crash 15.11.00 # <_bilgus> no nm 15.11.16 # and there's no working sim for the R1 yet. 15.11.43 # I usually use the Onda VX sim 15.11.56 # but if the issue is really specific to the YP-R1, it doesn't help 15.14.09 # ok, found a bug in a touchscreen path in the work I did. 15.14.24 # <_bilgus> R0 sim doesn't crash 15.14.40 # lebellium: download the new build, same url 15.16.35 # <_bilgus> sbs doesn't show properly in the R0 sim 15.17.54 # speachy: crash 15.19.50 # I wonder if checkwps works 15.22.28 # what theme, the stock cabbiev2? 15.23.39 # fresh install so yes 15.25.31 # any address? 15.25.53 # you mean a panic screen? no 15.26.29 # <_bilgus> so is it crashing at with a605cdf? 15.28.06 Join p3tur [0] (~petur@rockbox/developer/petur) 15.29.19 Join petur2 [0] (~petur@199.59.5.111) 15.29.20 # I don't know which builds speachy uploaded and made me test but I didn't try a605cdf, I tested the latest build c85d8e2865 and the previous nightly build 15.29.36 # _bilgus: the last one I sent him was a605cdf 15.29.43 # (plus one additional fix) 15.29.59 Quit petur2 (Client Quit) 15.30.31 # <_bilgus> shit that means something doesn't like the answer it got 15.30.47 # <_bilgus> 'A patently wrong answer 15.31.44 Quit petur (Ping timeout: 240 seconds) 15.32.24 # * braewoods patents all the wrong answers. 15.32.39 # Now I can profit from other people's mistakes! 15.32.52 # <_bilgus> just saying it was gettin a bunk pointer before 15.33.00 Quit p3tur (Ping timeout: 272 seconds) 15.33.02 # _bilgus: so you debunked it? 15.33.04 # :) 15.33.24 # <_bilgus> cleary still bunk^ 15.34.07 # but what's different about the R1? (other than touchscreen and possibly a higher res screen) 15.36.07 # <_bilgus> The real question is how many more turns of phrase can I use in this conversation, yeah good point speachy I know it won't work right but what if you disable TS 15.36.45 # lebellium: if we disable touch, you can still reset and load new software into the device, right? 15.37.33 # yes 15.37.43 # with the physical power and volume buttons 15.37.59 # ok. gimme a few to do a touch-less build 15.38.07 # there is no bootloader screen to choose between Rockbox and OF 15.38.14 # it's done with the volume button 15.40.17 # _bilgus: the uisim is definitely showing the statusbar viewport all wonky. 15.40.38 # hmm. 15.40.43 # <_bilgus> yeah I think I know whats going on the default vp needs defaults 15.41.08 # well, the main menu vp is suppoed to take the default vp and shrink it by the sb size 15.41.31 # (does this happen on actual targets, or just the sim?) 15.42.32 # <_bilgus> so far just the sim 15.42.48 # might be due to the sim code not picking up a #define that I moved. 15.42.51 # <_bilgus> I should try the rocker sim as well 15.43.17 # I am not noticing an delay in normal usage. Is there anything that uses a lot of update_rect() close together? 15.43.28 # <_bilgus> themes 15.45.55 # lebellium: new build, same URL 15.46.19 # <_bilgus> if you want a wholly arbitrary (between targets) use that rliimg lua script and put in a few lines to get iterations especially on the twist demo 15.50.12 # I don't see any delays, but that may just be me 15.50.26 # it's on gerrit 15.52.01 # _bilgus: it's broken on real targets too. 15.52.29 # <_bilgus> huh I'll try another 15.52.40 # _bilgus: the viewport/sb I mean 15.52.46 # <_bilgus> yeah 15.53.04 # speachy: crash 15.53.09 # backing out today's changes. 15.53.11 # <_bilgus> would almost have to be the changes I made today but I swear they are more sane! 15.53.18 # _bilgus: could be mine! 15.53.37 # <_bilgus> yours are even more sane!! 15.54.07 # _bilgus: when was the last time you sacrified a goat to the elder gods? 15.55.16 # <_bilgus> had to been like last week 15.55.30 # okay. it's either a605cdf or c85d8e 15.56.33 # <_bilgus> i'll let you know shortly 15.56.51 # I'm unzipping it to real hardware now 15.57.36 # it's mine 15.57.40 # (wtf?) 15.59.37 # <_bilgus> I would have bet $$ it was me 15.59.59 # <_bilgus> so there is a bad pointer would be my guess or there is a logic error 16.00.38 # the logic error might actually be in the original code 16.06.15 # I think I know what it is. 16.08.52 # nope. 16.09.08 # I will revert this if I can't figure it out within a couple of hours. 16.20.40 Quit lemon_jesus (Ping timeout: 256 seconds) 16.35.01 # <_bilgus> don't revert just yet I think I should probably just go through and get some logfs set up its just so very hard to trace this stuff through the engine 16.38.52 # <_bilgus> all those NULL checks we could just put an intermediate function to return NULL on the failed check 16.39.24 # I'm going to try and isolate it to a specific change. 16.40.10 *** Saving seen data "./dancer.seen" 16.40.49 # <_bilgus> logf use macro that points back to NULL logf use our intermediate and log all 16.48.20 Quit Rower (Ping timeout: 260 seconds) 16.49.22 # ok, isolated to skin_[display|parser|render|tokens].c 16.50.35 # <_bilgus> get_token_value is recursive 16.50.53 # yeah, that's probably where things are bad but I'm being systematic here 16.53.10 # <_bilgus> maybe there is a void or null skin token we could return 16.55.40 # <_bilgus> yeah don't let me mess up your process I do see a few things i'd like to clean up in there later 16.56.16 # down to just skin_parser or skin_tokens 16.56.49 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 16.58.16 # ok, it's the changes in skin_parser.c 16.59.28 Join beencubed [0] (~beencubed@209.131.238.248) 17.02.29 # specifically the changes to skin_find_item() 17.02.48 # lebellium: I have a new image up for you to try 17.03.17 # <_bilgus> I would have figured line 2530 17.03.34 # this is purely the statusbar going wonky 17.03.50 # I don't know if it's related or not, but I figure it's at least something I can reproduce 17.04.44 # <_bilgus> re skin_data_free_buflib_allocs, I notice we kill all the buffers here I wonder if the caller deselects all the viewports 17.04.49 # huh, I missed that L2530 thing 17.06.25 # the change that probabaly caused the sb to break is the explicit itemlabel=null at the top of the loop 17.07.04 # which means that we still have a valid itemlabel even if we didn't match anything on that iteration. 17.07.24 # <_bilgus> ln 1739 looks suspect 17.08.26 # <_bilgus> no nm sorry i see what its protecting 17.12.10 # <_bilgus> re line 1963 does gcc say how it processes for statemenst is it hopefully always short circuits 17.15.38 # <_bilgus> braewoods, any clue? gcc behavior 'for(' statement invocation short; circuit if conditional doesn't match guaranteed? 17.16.44 # for executes the first statement, then after each iteration it executes the increment statement, then it performs the test. 17.17.31 # ie stmt1 ; do { .... stmt3;} while (stmt2); 17.17.48 Join johnb7 [0] (~johnb2@p5b3afaa7.dip0.t-ipconnect.de) 17.20.59 # <_bilgus> ok as long as its that always 17.22.27 # speachy: same URL, 17.22.28 # ? 17.22.32 # GCC short-ciruits the tests from L->R, ie the first failure will terminate. 17.22.35 # lebellium: yes 17.23.47 Quit johnb7 (Quit: Nettalk6 - www.ntalk.de) 17.26.21 # crash 17.28.32 # well, drat. 17.28.50 # it crashes on the log screen, right? what's the version string it shows? 17.29.58 # s/log/logo/ 17.30.25 # it crashes on the logo screen with 2bc621a26bM-201028 displayed 17.30.35 # thanks 17.34.27 # <_bilgus> speachy gcc statusbar-skinned.c line 138 did you mention this? 17.34.39 # <_bilgus> already.. 17.35.39 # that was one of the changes I'd backed out in an earlier build I sent him 17.41.32 # lebellium: new image, same place. 17.42.50 # <_bilgus> I'm really interested to see the final issue because this code looks fine otherwise 17.43.51 # _bilgus: the statusbar issue cause is still unknown; I've backed out the offending changes (haven't pushed yet) but the problem is somewhere higher in the call stack. 17.45.11 Quit tchan1 (Quit: WeeChat 2.8) 17.45.13 # 91ccb246e7M-201028 crash 17.45.27 Join tchan [0] (~tchan@c-98-220-238-152.hsd1.il.comcast.net) 17.45.27 Quit tchan (Changing host) 17.45.27 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 17.45.49 # _bilgus: ^^ was backing out the L2530 change. 17.51.20 # aha, found the logic goof in skin_find_item. 17.51.41 # the check for token being valid doesn't apply to the UIVP/VP cases. 17.54.08 # Build Server message: New build round started. Revision 8c8284b, 293 builds, 8 clients. 17.54.46 # now we're down to just that crash on the yp-r1 17.54.57 # lebellium: new image up, same place 17.57.32 # crash 17.59.16 Quit klock (*.net *.split) 17.59.16 Quit __builtin (*.net *.split) 17.59.16 Quit benedikt93 (*.net *.split) 17.59.17 Quit blackyus- (*.net *.split) 17.59.17 Quit shrizza (*.net *.split) 17.59.32 Join blackyus17 [0] (~blackyus1@ip189.ip-144-217-213.net) 17.59.37 Join shrizza [0] (~shrizza@oki-180-131-209-187.jptransit.net) 17.59.40 Join benedikt93 [0] (~quassel@unaffiliated/benedikt93) 17.59.54 Join __builtin [0] (~quassel@rockbox/developer/builtin) 18.00.02 Join klock [0] (~freeklock@unaffiliated/klock) 18.03.23 # ok. new image. 18.03.48 # I'm systematically excluding chunks of the patch to try and narrow down which avenue it's coming from. 18.03.56 # lebellium: ^^ 18.04.24 # <_bilgus> yeah I hate when it comes to that 18.06.26 Quit Moarc (Ping timeout: 265 seconds) 18.07.02 Join Moarc_ [0] (~chujko@a105.net128.okay.pl) 18.07.08 # crash 8c8284bbe6M-201028 18.09.51 # ok, that narrows it down to the changes in skin_parser and skin_renderer 18.09.51 # Build Server message: Build round completed after 842 seconds. 18.09.51 # Build Server message: Revision 8c8284b result: 2 errors 0 warnings 18.10.24 # <_bilgus> on the fuzeV2 I get a crash that points to somewhere in skin_engine 18.13.48 # lebellium: new image up 18.16.21 # speachy: I just tried the latest newest build from https://build.rockbox.org/. Still experiencing the issue with borders around top bar elements and most of the main screen 18.16.49 # works :) 18.16.59 # Airwave: the one that just finished? (8c284b) 18.17.10 # lebellium: okay! we're getting somewhere. :D 18.17.15 # speachy: Correct 18.17.32 # Airwave: this was on the Rocker? 18.17.37 # Yes 18.18.38 # Huh if I go into the now playing screen and go back, it's fine 18.19.00 # But after reboot it's back 18.19.29 # lebellium: new one up. 18.20.15 # How do I do a screenshot? There's no option for it in the debug menu 18.21.06 # <_bilgus> Airwave is this clean build? 18.21.19 # _bilgus: What does that mean? 18.21.34 # <_bilgus> like did you rename the .rockbox directory first 18.21.56 # <_bilgus> clean install 18.22.07 # <_bilgus> sorry bad with wordz today 18.22.12 # No 18.22.14 # speachy: crash 18.23.15 # well that was good 18.23.29 # the other H320 I got was not really working even when plugged in 18.23.31 # blah blah 18.23.34 # replaced battery 18.23.38 # works fine now 18.24.09 # lebellium: new one up again. 18.26.19 # works 18.26.46 # we're down to just 6 diff chunks in a single file. 18.27.51 # new one up. 18.28.54 # <_bilgus> crazy 18.29.38 # works 18.30.45 # speachy: Let me know if I could provide some help debugging this issue 18.32.29 # lebellium: again, please. 18.33.04 # whoops. 18.33.06 # hang on 18.33.23 # okay, re-uploaded. 18.33.43 # will report as 72ad226ebf (no 'M') 18.35.32 # works 18.39.30 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 18.40.11 # lebellium: and again. 18.40.13 *** Saving seen data "./dancer.seen" 18.40.26 # this should narrow it down to a single chunk. 18.41.11 # good news, 'cause it's really time to go to bed now :D 18.41.29 # does that mean it works? 18.41.30 Quit bluebrother (Disconnected by services) 18.41.35 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 18.41.40 Join fs-bluebot_ [0] (~fs-bluebo@55d44bbc.access.ecotel.net) 18.42.06 # it does 18.42.25 Quit fs-bluebot (Ping timeout: 240 seconds) 18.45.39 # _bilgus: it's the changes to skin_data_free_buflib_allocs() 18.46.23 # lebellium: do you have time for one more? 18.46.30 # last one 18.47.23 # okay, it's up 18.49.09 # 8c8284bbe6M-201028 works 18.49.39 # okay! 18.50.01 # I'll have a proper fix for this committed soon. 18.50.17 # great, let's see tomorrow 18.50.24 # thanks for your help and good night 18.51.48 Quit lebellium (Quit: Leaving) 18.53.35 # Build Server message: New build round started. Revision a5a8e00, 293 builds, 8 clients. 18.54.27 # _bilgus: see g#2930 for the $%#@! fix. it's what's building now. Probably will fix the crash you saw on the FuzeV2 as well. 18.54.29 # Gerrit review #2930 at http://gerrit.rockbox.org/r/2930 : Fix a crash introduced in a605cdf70 by Solomon Peachy 18.55.03 # Airwave: please try this build when it completes, it might actually fix everyone's problems. 19.04.11 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 19.08.49 # <_bilgus> speachy we both missed that 19.10.01 # Build Server message: Build round completed after 985 seconds. 19.10.03 # Build Server message: Revision a5a8e00 result: 220 errors 0 warnings 19.16.28 # speachy: Oh nice, will do 19.18.33 # <_bilgus> speachy fixed 19.19.42 # <_bilgus> I saw a few other things I wanted to clean up 19.21.39 # erm. did something change in the rockbox code? my latest test build for H300 has a statusbar that's glitching out. 19.22.37 # <_bilgus> its fixed at head except the 220 errors 19.23.04 # i just did a pull and build this in the last 15 minutes. 19.23.13 # is it newer than that? 19.24.11 # <_bilgus> yes^ 19.24.22 # <_bilgus> the errors are all checkwps 19.26.54 Part edhelas 19.27.35 Join edhelas [0] (9d94237298@149-210-220-39.colo.transip.net) 19.28.31 # speachy: good thing you insisted on those tests. 19.28.41 # speachy: for some reason i only had partial success with my program pass. 19.28.51 # only 2 words got written in the region 19.29.04 # strange. 19.29.09 # looks like i got some debugging to do. 19.39.10 # Build Server message: New build round started. Revision c7fb319, 293 builds, 8 clients. 19.39.16 # okay, that'll fix checkwps 19.47.23 # <_bilgus> Awesome! 19.53.13 # <_bilgus> sorry speachy I'm the one that suggested that 19.53.46 # i'm going to start over on that change to the write code 19.53.49 # flash modify 19.53.55 # start by testing the old one 19.54.41 # <_bilgus> and also how did it not crash when skin_buffer was NULL? 19.55.28 # <_bilgus> ah nm I see it 19.55.36 # <_bilgus> 0[0] = 0 19.55.54 # <_bilgus> wow that is subtle 19.56.05 Quit pamaury (Ping timeout: 240 seconds) 19.56.58 # <_bilgus> I like how its not hidden behind macros and abstraction now though 19.59.19 # Build Server message: Build round completed after 1209 seconds. 19.59.20 # Build Server message: Revision c7fb319 result: All green 20.03.31 # _bilgus: i'm still getting a glitching status bar from HEAD. 20.06.26 Quit michaelni (Ping timeout: 256 seconds) 20.18.41 Join MrZeus_ [0] (~MrZeus@2a02:c7f:70d0:6a00:857e:c3d:75f3:53b) 20.18.56 Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) 20.22.19 Quit MrZeus (Ping timeout: 272 seconds) 20.31.54 # braewoods: on the main screen or wps? and on the hxxx targets? 20.36.18 # stock theme? 20.38.54 # braewoods: ok, I see it in the sim 20.39.03 # _bilgus: it's not the problem I'd introduced. 20.39.33 # the statusbar and the remote are glitching together. 20.40.02 # I see bits of the sb paint into the remote, and perhaps vice versa? 20.40.15 *** Saving seen data "./dancer.seen" 20.40.37 # <_bilgus> there is probably something getting the wrong buffer then is that the h120 sim? 20.40.43 # h320 20.41.14 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 20.41.15 # hitting the stop button shows the splash paint onto both screens 20.41.20 # <_bilgus> ok I'll start searching for that after I get done with this patch 20.41.41 Join fs-bluebot [0] (~fs-bluebo@55d4437e.access.ecotel.net) 20.41.44 # I'm operating under the assumption here that this isn't due to my hackery. 20.42.16 # <_bilgus> ugh I would say I'm frustrated but eh not really its a damn complex system 20.42.47 # <_bilgus> i'm glad its getting updated too bc lets face it only the codecs are worse 20.44.05 Quit bluebrother^ (Ping timeout: 240 seconds) 20.44.15 # <_bilgus> oh wait the h320 the one with the massive screen? I saw that in testing and then it disappeared in a later patch so I figured it was fixed but maybe I broke it again 20.44.16 # welllllll, I dunno. if you treat the codecs as a black box they're straightforward. internally they're spaghetti. 20.44.20 Quit fs-bluebot_ (Ping timeout: 268 seconds) 20.44.33 # no, it has the same screen size as the h120.. just full color 20.44.37 # _bilgus: it's glitching along the top edge. 20.44.47 # in the normal menus 20.44.55 # what you get when you first bootup 20.45.12 # currently i'm experimenting with trying to figure out this flash stuff 20.45.41 # <_bilgus> nbd if I can reproduce it in the sim its easy 20.45.50 # <_bilgus> well not easy but at least faster 20.46.22 # <_bilgus> I spend more time compiling than I do coding on this laptop think I might have to drag my rig here 20.47.41 # _bilgus: if I revert c85d8e2865 it is glitch-free 20.50.38 # speachy: yum. spaghetti. 20.59.41 # <_bilgus> UNFORTUNATELY THAT ONE FIXES THE OTHER ISSUE SO I'LL HAVE TO LOOK CLOSELY 20.59.50 # <_bilgus> sorry 20.59.58 # _bilgus: tilt. 21.05.51 # might be the hardcoded screens[SCREEN_MAIN] in skin_backdrop_set_buffer() ? 21.13.45 Quit paulk-leonov (Ping timeout: 246 seconds) 21.31.14 # <_bilgus> shouldn't be it only needs screen if the VP is NULL and that vp is part of the skin_viewport struct 21.37.27 # <_bilgus> g#2931 kcoks off 2.5k but I think it might be broken I wasn't expecting that kind of size decrease I'll get back to it 21.37.28 # Gerrit review #2931 at http://gerrit.rockbox.org/r/2931 : Skin_engine optimize element switch by William Wilgus 21.37.41 # <_bilgus> knocks* 21.39.08 # speachy: Problem is still present on c7fb319151 :-( 21.42.30 # <_bilgus> Airwave this was the rocker and which theme? 21.44.15 # _bilgus: https://themes.rockbox.org/index.php?themeid=2054&target=agptekrocker 21.46.54 Join paulk-leonov [0] (~paulk-leo@leonov.paulk.fr) 21.47.22 # <_bilgus> hmm let me check at head but the version from a few hours ago does not show it 21.48.57 # <_bilgus> ah nm I see them in between the icons? 21.50.25 # <_bilgus> @airwave 21.53.55 # <_bilgus> speachy after further review I feel you are probably right about set_vp_buffer 21.55.15 Quit MrZeus_ (Ping timeout: 268 seconds) 21.57.15 # <_bilgus> the changes I made in that same commit tie it to screen types 22.02.50 # _bilgus: Yeah in between the icons 22.03.01 # And around part of the main screen showing the menu options 22.03.13 # <_bilgus> ok I know what I'm looking for now I'll track it down 22.03.29 # If you try going into Now Playing and then back you'll see how it's supposed to look 22.03.45 # Nice, let me know if I can help in any way 22.15.18 # speachy: https://gerrit.rockbox.org/r/#/c/rockbox/+/2932/ 22.15.25 # speachy: tested working on my iriver h320 22.16.43 # <_bilgus> nice sounds like progress 22.17.10 # <_bilgus> and mendel_munkis figured out the fuze+ screen flip Issue it appears 22.17.42 # i'll be doing some more rework on this module but one problem at a time 22.18.26 # it seems to consistently erase and reprogram 64K sectors in an unused region 22.18.27 # just fine 22.18.52 # i switched patterns every time i did a retest and it produced new results in the ROM dump 22.23.11 # <_bilgus> you might want to set some checksumming 22.23.32 # <_bilgus> even a simple xor over the buffer would be enough 22.25.56 # _bilgus: eh? 22.26.23 # i just did basic tests with constant values. why would i use a checksum? 22.27.19 # <_bilgus> to check for run len errors 22.27.57 # _bilgus: i still don't follow... 22.28.15 # anyway the original code was doing checksums where it added everything up 22.28.16 # <_bilgus> and really random data would be better checksummed in and again out 22.29.00 # <_bilgus> well you said it'd brick the device so I'd got a bit further to make sure everything is going right 22.29.22 # _bilgus: ... yes, the original code does that already? 22.29.30 # it's still in effect. 22.29.38 # <_bilgus> ah ok 22.29.48 # i'm just revisiting it all from the bottom-up. 22.29.55 # making sure stuff works as expected 22.30.03 # for the H320 then i will retest on an H120 22.30.19 # <_bilgus> a wise decision you already found that trap stuff I HAD NO IDEA it was possible 22.30.51 # <_bilgus> oh h320 is fixed with this patch i'll try to include Airwaves issue in it 22.32.17 # <_bilgus> I had to go back to setting a NULL buffer but I just set both screen viewports to default so you have to reselet the viewport to a screen to ensure NULL buffers don't get released into the wild 22.32.35 # <_bilgus> which the skin engine does already 22.32.57 # <_bilgus> reselect 22.33.15 # basically the flash commands are nearly identical between the H120 and H320 22.33.18 # slight difference 22.33.26 # so i needed to rework them 22.33.41 # i mostly did that to switch to an officially sanctioned method of waiting for rom completion 22.33.54 # as in, it's one of the two methods supported by the flash 22.34.06 # toggle bit was the easiest to implement 22.34.41 # <_bilgus> no clue what toggle bit is 22.35.01 # <_bilgus> setting and waiting for it to clear? 22.35.06 # Not at all. 22.35.24 # You keep checking DQ6 (the bit/pin that toggles) until it stops changing. 22.35.37 # via reading from a special memory locaiton 22.36.04 # https://www.rockbox.org/wiki/pub/Main/DataSheets/SST39VF320X_driver_example.txt 22.36.11 # checks 22.36.13 # Check_Toggle_Ready 22.36.37 # it's the bit masked in 0x0040 22.36.48 # the data pins start at DQ0 22.36.52 # and DQ6 is the 7th bit 22.36.56 # ergo, 0x40 22.37.31 # i was stumped at first then i realized the datasheet starts it from 0 22.37.33 # lol 22.37.51 # <_bilgus> what an odd method the must have broken out a connection off the transistor driving the flash write 22.38.13 # it's available in both data sheets for the 2 ROM chips 22.38.17 # so i intend to just use that 22.38.27 # <_bilgus> hell yeah ref code is king 22.38.40 # just the newer one asks you to wait 1 US after the toggle bit is done 22.38.45 # <_bilgus> compared to that I assume RE stuff lol 22.39.02 # the old code did... 22.39.07 # != 0xffff for erases 22.39.09 # <_bilgus> probably wise in both 22.39.14 # and == data for writes 22.39.18 # i didn't feel that was too safe 22.39.43 # it worked but it didn't feel like it was the proper method since it wasn't how it actually worked 22.40.17 *** Saving seen data "./dancer.seen" 22.40.31 # the only other caveat i might have issues with is 22.40.43 # whether the lowest 32K is write protected or not. 22.40.49 # the new chip supports it 22.40.55 # err 64k 22.41.09 # but it has to be enabled by the PCB designers 22.41.11 # so 22.41.19 # i have *no* idea if it is actually in effect 22.41.28 # only way to know is to try it 22.41.46 # if it is then i have a problem i need to overcome 22.41.57 # but as was said, it's hazardous 22.42.01 # <_bilgus> well little risk of brick if not so thats good I guess 22.42.11 # but i need to know 22.42.15 # either way 22.42.31 # and the official routine for it will fuck me over if it's wrong 22.42.34 # and it is WP 22.42.38 # it assumes it isn't 22.42.40 # so 22.42.43 # <_bilgus> I wonder if we could xray something like that 22.42.45 # i need to find out if it is 22.43.06 # <_bilgus> assuming the density wasn't too high it'd probably work 22.43.13 # anyway 22.43.18 # i'll be testing that later 22.43.28 # i need to be able to restore the boot sector if it does work 22.43.33 # <_bilgus> be able to trace the pcb non destructively 22.43.55 # <_bilgus> I guess the next thing is find someone willing to do that 22.44.10 # i'm just going to take the risk and find out 22.44.17 # i have some ideas for how to minimize my risks 22.44.32 # <_bilgus> I'm saying if it is then how to find the proper pin 22.44.37 # oh. 22.44.38 # right. 22.44.41 # but one thing at a time. 22.44.55 # <_bilgus> yeah carts dont work too well infront 22.45.05 # i have to confirm it is even a problem 22.45.17 # just because the chip has it doesn't mean it is active 22.45.38 # the DS states that the WP# is only active if connected AND held low 22.45.44 # otherwise it is high high internally 22.46.03 # held high 22.46.07 # <_bilgus> lol it appears your issue and Airwaves are one in the same 22.46.50 # <_bilgus> nice back to my quest to knock off some of the size bloat from the past week 22.47.40 Quit paulk-leonov (Ping timeout: 260 seconds) 22.55.12 Join paulk-leonov [0] (~paulk-leo@vpn-0-22.aquilenet.fr) 22.55.36 Quit prof_wolfff (Ping timeout: 260 seconds) 23.03.00 # Build Server message: New build round started. Revision c5c17fa, 293 builds, 8 clients. 23.03.22 # <_bilgus> Airwave, it should be fixed when this build round completes 23.03.37 # <_bilgus> please verify at your leisure 23.04.03 # _bilgus: Nice, I'll test it out tomorrow. Thanks for the work on this! 23.04.45 Quit cockroach (Quit: leaving) 23.05.01 # <_bilgus> No problem we appreciate all the testing and dealing with our construction mess 23.06.49 # Issues pop up sometimes, but mostly it's very stable in my experience 23.07.04 # there we go. just erased the test region so the bits are back to normal. 23.08.43 # I would appreciate it if someone with a fuze+ can confirm that g#2928 doesn't case a noticeable screen slowdown. 23.08.45 # Gerrit review #2928 at http://gerrit.rockbox.org/r/2928 : Fuze+: Fix misplaced rectangle when lcd_flip set by Moshe Piekarski 23.11.20 # _bilgus: it's no longer glitching out 23.11.56 # <_bilgus> good now lets hope thats the last of this 23.12.30 # <_bilgus> mendel_munkis, its not my DD but I'll try it out back and forth 23.12.48 # thanks. 23.13.40 # <_bilgus> I assume the code path hasn't diverged so much that I need to try two diff builds or should I look at old vs new too? 23.15.14 # I am refering to old vs new. turning on or off flip shouldn't have an effect on the performance. 23.15.38 Quit paulk-leonov (Ping timeout: 264 seconds) 23.16.17 Join paulk-leonov [0] (~paulk-leo@vpn-0-22.aquilenet.fr) 23.22.08 # Build Server message: Build round completed after 1149 seconds. 23.22.10 # Build Server message: Revision c5c17fa result: All green 23.22.12 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 23.28.20 # <_bilgus> ok so then between builds