--- Log for 14.01.117 Server: nylund.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 9 days and 3 hours ago 00.00.14 # chrisjj: you'll be allowed to complain the day you implement a speaker setting in a plugin. Until then I don't see the point of arguing 00.02.36 # <[Saint]> nothing better to do, presumably. 00.02.51 # I wasn't complaining. But thanks - I'll take that raincheck :-) 00.03.01 # Returning to the ZEN BSoPO mystery, are you aware the ugly white full-screen flash on backlight wake is remains present on lcd_fix? 00.03.57 # yes 00.06.13 # OK. The UWFSF on backlight /wake/ was cured, but interestingly by the bootloader update from V2Beta, not by the .rockbox update. 00.06.37 # UWFSF ? 00.07.01 # ugly white full-screen flash :-) 00.09.01 # I mention this for in case state persisting from the bootloader is not supposed to affect LCD performance under .rockbox. 00.09.45 # I'd have thought it was not. I.e. I'd have thought .rockbox would completely setup the LCD state itself. 00.10.18 # it does 00.10.19 # Sorry. s/The UWFSF on backlight /wake/ was cured/The UWFSF on backlight /sleep/ was cured/ 00.11.09 # Well, if it does, I wonder how come I see different performance of LCD in .rockbox, after different bootloaders. 00.11.52 # This is on two different devices so in theory this could be the rumoured different LCDs... but I thought I'd ask before reflashing. 00.12.58 # The old bootloader left the LCD in a weird state when giving the hand to .rockbox. It is possible that the code in .rockbox did not manage to recover from this. I don't know, I don't really care to be honest as look as the lcd works 00.16.33 # Thanks. I too wouldn't care, if the port ran reliably. 00.18.41 # On the UWFSF, is this something on which you'd appreciate further info? 00.19.21 # I probably know how to fix it 00.19.30 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 00.21.15 # gevaerts: where should I look for the shortname checking with WPS usage? 00.21.30 # matching checkwps usage* 00.21.47 # OK. 00.22.33 # BTW, I just reflashed Unit G bootloader from V2Beta to lcd_fix... and the sleep UWFSF remains! 00.22.35 # lebellium: I'm pretty sure it's the name you can give to configure 00.22.40 # Not sure if that helps :) 00.23.07 # Is it necessarily the same name as the config file name. For example creativezen.h ? 00.23.24 # no 00.23.46 # Arguably it *should* be, but those can be different 00.24.37 # I suspect it's also the name used in tools/builds.pm 00.25.28 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 00.26.56 Quit petur (Quit: Leaving) 00.28.57 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 00.28.57 # * pamaury thinks there is a bug in the speaker code for imx233. Enable > Disable > Enable leaves the speaker disabled 00.29.13 # pamaury, i.e. On two units having the same bootloader and .rockbox, I see markedly different LCD performance. 00.30.16 Quit ender` (Quit: Trying to establish voice contact ... please yell into keyboard.) 00.30.33 # gevaerts: here you go http://pastebin.com/0He38QRE 00.31.12 # ah great, freescale but a speaker powerdown bit but it cannot be cleared once it is set, seriously? 00.34.44 # 'markedly different LCD performance' Both with config.cfg deleted. 00.36.16 # lebellium: I've added them. Now running checkwps on all themes, I hope that's enough to actually make them get themes 00.36.26 # thanks 00.37.47 # working 00.37.53 # magic 00.38.17 # damn, I wonder if the speaker also needs some magic like the headphones to start 00.39.41 # Freescale: 'It is reset by a power-on reset only' 00.40.29 *** Saving seen data "./dancer.seen" 00.40.34 # Which does somewhat take the shine off 'Due to the differential output, the speaker can be powered up or down nearly instantaneously without any pop problems.' :-) 00.41.13 # lebellium: I imagine some of those have new resolutions 00.41.17 # gevaerts: I guess we only have a problem with the 128x160 targets (NWZ-E370 and Zen Mozaic). The theme for Philips SA9200 should display for them, I guess 00.42.04 # * chrisjj assumes pamaury's talking about HW_AUDIOOUT_PWRDN bit 24. 00.42.24 # chrisjj: I assume the MUTE bit of the speaker control powers up/down 00.42.51 # gevaerts: Samsung YH-820 is new resolution. It's the only one which should have 0 theme 00.43.52 # pamaury: I failed to parse that. 00.44.37 # * pamaury is speaking about MUTE in HW_AUDIOOUT_SPEAKERCTRL 00.44.43 # Hmmm 00.46.12 # <__builtin> oh hey gevaerts, I was wondering something 00.46.22 # scorche: apparently the theme server doesn't have the necessary stuff installed to build checkwps these days 00.46.58 # <__builtin> what's the best way I should handle making and pushing multiple changes in git? I've got a bunch of changes on a branch and they're split into a couple commits 00.47.00 # gevaerts: yeah - i saw those errors recently 00.47.12 # ' The speaker antipop startup/shutdown sequence should be followed before toggling this bit.' ... 00.47.28 # <__builtin> if I push them normally, the build server will take forever to finish, no? 00.47.36 # No 00.47.58 # chrisjj: quoting the manual is not helping... 00.48.04 # It definitely won't build all revisions 00.48.09 # gevaerts: you know of a quick fix or should it just wait until i completely re-do that server? 00.48.28 # Are you following the speaker antipop startup/shutdown sequence? 00.48.39 # it is described nowhere so no 00.49.18 # Ah. Meets the definition of magic, so perhaps yes you do need to apply some :( 00.49.40 # scorche: the first issue is it missing sdl-config 00.50.14 # And then for some targets the android sdk apparently... 00.50.19 # (and ndk) 00.50.30 # Not sure why that's needed for checkwps, really 00.52.51 # * gevaerts suspects that's probably people being overly cautious/lazy when adding checks to configure 00.53.01 # pamaury: Did you see the little antipop sequence description on 29-26? I promise not to quote it :-) 00.53.28 # * pamaury spots the obvious typo in the code that explains everything 00.54.39 # chrisjj: yes, that's for headphone only and it doesn't work 00.54.46 # I implement my own version of antipop 00.55.40 # For headphone only but can you translate it to use the same control bits for speaker? 00.56.35 # * chrisjj wonders if pamaury was joking about the typo. 00.56.57 # * __builtin doubts it 00.57.53 # * chrisjj wonders if this typoed code is Freescale's 00.58.28 # actually funny thing, the power down bit for speaker can be cleared and set at will, despite what the manual says 00.58.33 # and no typo was not a joke 00.59.05 # So please do tell us the explanation for everything! 00.59.10 # <[Saint]> heh - freescale not meeting parity with their documentation 00.59.17 # <[Saint]> I am both shocked and amazed 00.59.18 # scorche: I suspect it's just the sdl dev stuff that's missing. The android stuff is a red herring, checkwps doesn't build for the android-based things anyway apparently 00.59.24 # <[Saint]> 01.00.18 # Build Server message: 3New build round started. Revision 637c741, 255 builds, 15 clients. 01.01.34 # * chrisjj assumes Freescale's non-parity is for parity with Rockbox's non-parity. 01.02.42 # gevaerts: libsdl1.2-dev? 01.02.53 # Yes, that's the one I expect 01.04.19 # k - done 01.05.23 # Great! 01.05.28 # Seems to work 01.06.01 # Well, the ones I expect to work. You didn't magically fix unmaintained broken half finished ports :) 01.11.29 # Build Server message: 3Build round completed after 670 seconds. 01.11.30 # Build Server message: 3Revision 637c741 result: 6 errors 1 warnings 01.11.53 # gevaerts: should I see a difference now? 01.13.48 # lebellium: not yet :) 01.15.18 # pamaury, re the mystery Unit N, I reinstalled bootloader and .rockbox, and still get LCD dots then data abort. 01.15.59 # pamaury, I now have three units (G, N and Q) showing markedly different LCD performance from the same versions of bootloader (45697a0bf-161212) and .rockbox (again 45697a0bf-161212). Two have shown multiple BSoPOs though I've not yet reproduced the conditions for that. Let me know if you want any detail on this. 01.17.34 # scorche: did I just kill apache? 01.17.44 # Build Server message: 3New build round started. Revision 79e8cd4, 255 builds, 15 clients. 01.18.08 # Or just the entire server? 01.18.34 # <__builtin> well, forums aren't working now :P 01.19.27 # gevaerts: the latter - give it 3 minutes to reboot 01.22.16 # Correction: L, N and Q. Unit G shows the same as Q (Ugly White Full Screen Flash on backlight sleep.) 01.22.54 # chrisjj: see commits for typo 01.25.29 # Not https://www.rockbox.org/since-4weeks.html 'fix typo (nwz-zx100 -> nw-zx100)', I guess :-) 01.25.52 # https://git.rockbox.org/?p=rockbox.git;a=commit;h=fd26294 01.26.10 # Ooo... 01.27.24 # I think that rates as a 'codo' :-) 01.29.05 # Congrats on the catch. 01.29.36 # Build Server message: 3Build round completed after 712 seconds. 01.29.37 # Build Server message: 3Revision 79e8cd4 result: 0 errors 1 warnings 01.32.10 # pamaury: Does .rockbox on ZEN (plain speakerless ZEN model) ever read the audio jack status? 01.33.07 # * __builtin probably spends as much time wrangling with git as he does writing code... :( 01.35.26 # * chrisjj hopes __builtin finds comfort in the fact he's not alone. https://eev.ee/blog/2015/04/24/just-enough-git-to-be-less-dangerous/ 01.35.59 # chrisjj: no, as far as I know, there is no way to detect jack on the ZEN 01.37.05 # OK, thanks. I am sure I saw audio jack insert cause backlight wake (yes really) but it was at 4am so I guess I was asleep and having a nightmare. 01.37.49 # A nightmare because audio jack is on my list of BSoPO factor candidates. Or was. Now removed. 01.38.06 # chrisjj: regarding the white flash on the ZEN, are you sure it happens on sleep ? It should happen on wake 01.38.28 # * chrisjj checks he's awake 01.39.43 # Yes I'm sure. I've seen it 30 times today. 01.40.35 # UWFSF happens on wake too, but the two are different. Wake is clean-cut and about 100ms. 01.41.25 # Sleep's is sheared and about 40ms. 01.41.42 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) 01.42.51 # I wonder if we are talking about the same thing. On the ZEN X-Fi, when backlight goes off (what I call sleep), there is no white screen, it fades slowly and then becomes dark. But when backlight goes on (what I call wake), you can briefly see a completely white screen 01.43.44 # Sounds like exactly the same thing I see on ZEN Unit L. 01.44.22 # But on e.g. Unit G I see a flash on sleep too. 01.45.03 # * pamaury thinks he may have an explanation but needs to check something 01.53.33 Quit ZincAlloy (Quit: Leaving.) 02.00.24 # * chrisjj goes to bed hoping not to have nightmares about audio jack power draw subtly disturbing cached memory DMA. 02.03.21 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 02.21.51 Quit pamaury (Ping timeout: 255 seconds) 02.30.32 Quit Strife89 (Ping timeout: 240 seconds) 02.31.54 Join Strife89 [0] (~quassel@adsl-98-80-182-98.mcn.bellsouth.net) 02.40.33 *** Saving seen data "./dancer.seen" 02.42.45 Quit Senji (Ping timeout: 252 seconds) 03.17.08 Join Senji [0] (~Senji@85.187.103.250) 03.22.32 Quit Senji (Ping timeout: 258 seconds) 03.56.37 # <[Saint]> ...what the hell? 03.56.41 # <[Saint]> :-S 03.56.46 # <[Saint]> That boy ain't right. 04.12.29 # he's really KenM irl 04.27.30 # <[Saint]> Ha! 04.35.15 Quit [Saint] (Remote host closed the connection) 04.35.50 Join [Saint] [0] (~sinner@rockbox/staff/saint) 04.40.36 *** Saving seen data "./dancer.seen" 05.23.00 # Build Server message: 3New build round started. Revision 823f726, 255 builds, 15 clients. 05.23.07 # <__builtin> fingers crossed here... 05.36.22 # Build Server message: 3Build round completed after 802 seconds. 05.36.23 # Build Server message: 3Revision 823f726 result: 51 errors 0 warnings 05.36.39 # <__builtin> shoot 05.37.36 # <__builtin> mmh, it's the optimization flags 05.52.16 # Build Server message: 3New build round started. Revision c1b913b, 255 builds, 15 clients. 06.03.07 # Build Server message: 3Build round completed after 651 seconds. 06.03.08 # Build Server message: 3Revision c1b913b result: All green 06.25.52 # Build Server message: 3New build round started. Revision 0a5b0dd, 255 builds, 15 clients. 06.26.03 Quit TheSeven (Disconnected by services) 06.26.15 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 06.37.30 # Build Server message: 3Build round completed after 698 seconds. 06.37.31 # Build Server message: 3Revision 0a5b0dd result: All green 06.40.37 *** Saving seen data "./dancer.seen" 07.36.18 Quit alexweissman (Remote host closed the connection) 07.38.52 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 07.43.13 Join [Sinner] [0] (~sinner@rockbox/staff/saint) 07.43.45 Quit [Saint] (Read error: Connection reset by peer) 07.45.36 Quit pixelma (Quit: .) 07.45.36 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 07.45.50 Quit [Sinner] (Read error: Connection reset by peer) 07.47.08 Nick Bray90820_ is now known as bray90820 (~bray90820@173-25-204-30.client.mchsi.com) 07.48.59 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 07.48.59 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 07.49.19 Join [Sinner] [0] (~sinner@rockbox/staff/saint) 07.51.42 Quit [Sinner] (Read error: Connection reset by peer) 07.52.12 Join [Saint] [0] (~sinner@rockbox/staff/saint) 08.40.39 *** Saving seen data "./dancer.seen" 10.14.41 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 10.19.45 Quit krnlyng (Ping timeout: 256 seconds) 10.23.05 Join Massa [0] (4fe8c676@gateway/web/freenode/ip.79.232.198.118) 10.23.25 Part robertd1 10.23.30 Join robertd1 [0] (~root@186-90-12-124.genericrev.cantv.net) 10.23.33 # Hello everybody! 10.28.07 Join smoke_fumus [0] (~smoke_fum@dynamic-vpdn-93-125-15-142.telecom.by) 10.31.30 Join krnlyng [0] (~liar@77.117.99.4.wireless.dyn.drei.com) 10.40.40 *** Saving seen data "./dancer.seen" 10.43.47 # <[Saint]> Hiiiiiiiii D̶o̶c̶t̶o̶r̶ ̶N̶i̶c̶k̶, Massa. 10.48.48 # Years ago I actively developed for rockbox - but I had a break for several years; but now I try get familiar again ;-) 10.49.21 # I've a few question regarding login and wiki etc. 10.50.14 # It seems I never registered at the wiki pages - can't remember why; so know I did! 10.51.10 # Can someone please add me to the WikiUsersGroup? My wiki name is MatthiasM 11.07.22 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) 11.21.59 # Hi Massa ! what were you working on ? 11.25.45 # Parts of the picture resizing and integrating of the pictures / albumart in wps 11.26.53 # and I was involved in the wps redesign at that time - which leads to the viewport design 11.27.40 # And some patches for games and other stuff to make it better work at the iRiver H340 devices... 11.28.31 # Currently I'm interested in iPod Video / Classic and SDXC / mSATA support 11.29.58 # And I try to fix the windows simulator build so that it works with (my) current cygwin installation again... 11.30.35 Join ender` [0] (krneki@foo.eternallybored.org) 11.34.45 Join lebellium [0] (~chatzilla@89-93-179-5.hfc.dyn.abo.bbox.fr) 11.35.04 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 11.40.05 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 11.42.42 # pamaury: do you want real KAS for NW-ZX100? Something else too? 11.46.46 # lebellium: yes 11.47.00 # what's a KAS 11.47.02 # basically I'd interested in everything not in https://git.rockbox.org/?p=rockbox.git;a=blob;f=utils/nwztools/upgtools/upg.c or in the not confirmed list 11.47.24 # Key And Signature 11.47.28 # o 11.55.21 # pamaury: 11.55.29 # Model: NW-ZX100 11.55.30 # Series: NW-ZX100 Series 11.55.32 # kas (node 11,key and signature): 11.55.33 # 63 64 64 61 38 64 35 65 35 33 36 30 66 64 34 33 cdda8d5e5360fd43 11.55.35 # 37 33 31 35 34 33 38 38 37 34 33 66 38 34 64 32 73154388743f84d2 11.55.36 # 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 11.55.38 # 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 11.55.46 # don't forget to fix the typo (NWZ/NW) when you pudate upg.c 11.55.50 # update* 11.57.14 Quit pamaury (Ping timeout: 240 seconds) 11.57.19 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 11.57.21 # ragequit 11.58.51 # lebellium: thanks 11.58.54 # which typo ? 11.59.00 Join johnb3 [0] (~johnb3@p5B296D6F.dip0.t-ipconnect.de) 11.59.06 # ah in the upg structure rigt 11.59.08 # "nwz-zx100", false, "2c0bf029804f73e073154388743f84d2" }, 11.59.25 # Massa: I added you to the wiki (I think) 11.59.59 # Mihail: see my forum post. Which build should I try next with my clip+ var0: -7, -8 or something else? 12.01.06 # lebellium: you made the typo too :-o 12.01.28 # oh no you just copied my wrong line 12.01.34 # :) 12.02.01 # I can't claim I never make the typo NWZ vs NW but I try not to! 12.02.18 # beware, quoting leads to the chrisjj side of #rockbox 12.02.31 # sorry 12.03.16 # Build Server message: 3New build round started. Revision 0cabc1f, 255 builds, 16 clients. 12.05.34 # pamaury_: This week I received my E585. As I had never seen it in real life before, I am astonished how tiny it is. I can do testing in the future if you want me to. My presence on IRC is limited however ... 12.06.20 # johnb3: I think at the moment we are good, me and lebellium have a E580 to test on, but when audio is finally working you can test it :) 12.06.32 # alright. 12.08.04 # pamaury_: thanks - yes you did :-) 12.11.44 # pamaury_: you added "MatthiasM" as is? I haven't looked at it but that wiki name doesn't comply with the rules...) 12.12.24 # a that's right, the wiki name rule, I always forget about that 12.12.31 # Build Server message: 3Build round completed after 555 seconds. 12.12.32 # Build Server message: 3Revision 0cabc1f result: 0 errors 1 warnings 12.12.35 # * lebellium doesn't want to debate about this stupid real name policy again 12.12.59 # Massa: we have a real name policy, so you must put your real name on the wiki 12.13.48 # lebellium: calling it stupid gives incentive to start a debate... 12.13.57 # that's true 12.14.02 Nick pamaury_ is now known as pamaury (~pamaury@rockbox/developer/pamaury) 12.14.16 # pamaury_: I added my real name to the irc nicks list: https://www.rockbox.org/wiki/IrcNicks 12.14.20 # * chrisjj wishes the E585 screen wasn't so tiny. 12.14.37 # pixelma: is that enough ? 12.15.10 # or must the name itself be the full name ? 12.15.26 # * pamaury knows some people are very picky about this and prefers to ask 12.15.53 # chrisjj: for me the screen is no problem but it doesn't really fill the palm of my hand. 12.16.23 # chrisjj: can you test a build for me on the ZEN ? 12.16.32 # Yes. 12.16.46 # So i feel I don't have a secure grip ;-) Maybe I will learn ... 12.17.26 # pamaury: Can I change the WikiName? 12.17.27 # johnb3: You could glue it to the back of the slightly larger ZEN :-) 12.17.47 # Massa: I don't know, I think not, the simplest way is to recreate an account :-/ 12.17.58 # gevaerts: can one change a wiki name ? 12.18.22 # the only zen I had was a Creative NOMAD Jukebox Zen Xtra and didn't like it too much. sold. 12.18.22 # What astonished me about the E585 was the battery runtime. 12.19.03 # chrisjj: https://www.dropbox.com/s/3c53ow3rdkt2bxn/rockbox_zen_blfix.zip?dl=0 12.19.15 # it is an attempt at fixing the white flash on backlight 12.20.12 # pamaury: O.K. I added another WikiUser "MatthiasMohr" - could you please add me to the group (and remove MatthiasM)? 12.20.23 # yes 12.20.48 # backlight 12.21.10 # d/backlight/ 12.22.03 # Is it possible to sign in to gerrit with a GitHub account? 12.22.07 # pamaury: thanks! 12.23.05 # Massa: in theory there a github oauth integration 12.23.33 # but I think last time I tried it ended up in a 404 on github :-/ 12.23.53 # yes - but it does not work; when I click at the link and log in to my GitHub account, I only get a 404 on github :-( 12.24.11 # you were faster than me ;-) 12.24.23 # oauth is really annoying, it breaks all the time 12.26.24 # I will see with bjorn if we can fix gerrit github 12.26.35 # but he is usually not very responsive 12.27.37 # Where can I easily get an OpenID just for that? I don't want to combine my google or wordpress accounts with that and also don't want to sign up e.g. to myspace just for that... 12.28.13 # pamaury: No change. I.e. Clean boot of that build Version 3ad3145b4-170114 on a ZEN that previously showed backlight sleep and wake white flash (Unit G) still shows that. 12.28.24 # I personally think that combining several accounts is a bad idea (privacy related) 12.30.32 # Massa: iirc Launchpad 12.32.53 # ZEN testers' Pro Tip: To revert Settings changes made since last power-on, press reset. 12.32.56 # pamaury: it's not in the list at OpenId (or I'm unable to see it)!? Do you have a link? 12.33.59 # chrisjj: aren't you the only one? 12.35.22 # Someone here with knowledge about the configure script? Especially with building the simulator? 12.35.31 # ... or plug USB to PC. 12.36.40 # Massa: it's on the Sign-In page for gerrit (for me) 12.37.04 # Massa: with configure script yes, simulator less 12.37.43 # I think there are some script bugs related to it, especially with detecting the sdl-config 12.38.13 # chrisjj: what about this https://www.dropbox.com/s/ndt0fkfetalw9eh/rockbox_zen_blfix_ugly.zip?dl=0 12.38.49 # I tried to make it more reliable and fixed it already - but now I have some strange error when it tries to identify the architecture 12.39.31 # can you pastebin ? It's a bit vague :) 12.39.32 # It's strange, because I can enter the exact commands with their arguments at my command line by hand and they work - but not inside the script! 12.39.37 # lebellium: We live in hope :-) 12.39.53 # Massa: beware that configure is sh based 12.40.07 # (for reasons I don't understand, we might as well move it to bash) 12.40.43 # there are subtle but important difference between bash and sh. What is the command that fails ? 12.40.44 *** Saving seen data "./dancer.seen" 12.43.38 # http://pastebin.com/KVa8cXRa 12.44.22 # first of all, you see line 3 there ( line 348 in script)? 12.45.00 # it directly calls "sdl-config" and not the one which get's searched and found earlier (in variable $sdl) 12.46.05 # that's the first bug - it should be changed to "$sdl" 12.46.10 # indeed 12.47.28 # the second bug (at least for cross-compiling environments) is, that it searches for sdl-config in the PATH - and not in the predefined cross compiling environment 12.47.55 # well it does that: 12.47.56 # files="${CROSS_COMPILE}sdl-config:sdl-config" 12.47.56 # no ? 12.48.11 # with comment # sdl-config might (not) be prefixed for cross compiles so try both. 12.48.32 # pamaury: On that rockbox_zen_blfix_ugly 03895dd28M-170114, the backlight flashes remain. 12.49.38 # * pamaury cannot believe it and gives on flash for now 12.50.01 # Massa: did you manage to setup a gerrit account or should I push a first fix ? 12.51.39 # I can send video proof if required :-) 12.52.11 # But I'll be posting the devices to you hopefully Monday. 12.52.49 # I need to see it myself, I don't understand the physics of this flash, the display cannot flash when backlight is off 12.53.53 # I think the backlight is not off. I think the white flash is the backlight On and the pixels White. 12.54.44 # And surely you did see it yourself on lcd_fix when you have a real device. Albeit a month back. 12.54.54 # s/have/had/ 12.55.17 # This builds turn off backlight and wait for an extra 100ms before turning off the LCD. If backlights takes more than 100ms to turn off that's bad 12.55.35 # I don't have this flash on sleep. 12.55.37 # ever 12.56.00 # I only have a flash on wake and this solves it for me 12.56.12 # I thought you don't have the flash because you don't have the device :-) 12.56.19 # on the X-Fi 12.56.37 # It's the same LCD as far as I know 12.57.33 # Ah. X-Fi. Well perhaps that where the rumoured different LCD is. Which is not to say it is likely that the LCD here takes >100ms for backlight to go off. 12.59.11 # Did you look for flash on ZEN classic when you had one? 13.01.33 # pamaury: now I logged in successfully to gerrit with an launchpad Id - but it's never wrong to fix the GitHub OAuth login ;-) 13.01.55 # Massa: I sent an email to Bjorn to see if he can look into this. 13.02.05 # Don't forgot to read UsingGit on the wiki 13.02.21 # you need a small hook in your git to generate Change-Id on commit 13.02.30 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:71cb:3547:d2da:f5e6) 13.02.49 # O.K., now back to configure... 13.04.46 # In my cygwin64 / mingw environment the correct sdl-config can be found as "sdl-config" inside the cross environment; e.g. in /i686-w64-mingw32/sys-root/mingw/bin 13.05.41 # so with the current search method it searches for i686-w64-mingw32-sdl-config through the PATH and didn't find it, but it'll find a (native) sdl-config 13.05.56 # which is the wrong one 13.06.40 # hum, that's tricky 13.07.19 # so it's fine to first search for $(CROSS_COMPILE)sdl-config - but it should search inside the cross environment first and then in the PATH 13.07.40 # yeah but how does it know the cross environment location ? 13.07.54 # I can only think of $(CROSS_PREFIX)gcc --print-sysroot 13.08.20 # or you need to tell the script 13.08.50 # me thinks 13.08.50 # `$(CROSS_PREFIX)gcc --print-sysroot`/bin 13.08.50 # is a valid search location 13.09.40 # that's a nice idea - didn't think of that :-o 13.09.44 # but it might not work, mingw tends to do weird things, like putting prefixed tools in /bin and not prefixed tools in /mingw/bin 13.10.02 # maybe adding 13.10.02 # `$(CROSS_PREFIX)gcc --print-sysroot`/mingw/bin 13.10.02 # doesn't hurt 13.10.46 # I wrote a function which searches in /usr, /usr/local for the cross_prefix directory - with cross gcc it would be easier; but only if it's in PATH... 13.11.09 # only the mingw subdirectory is somehow "incorrect" 13.12.30 # Massa: currently how to specify your cross compiler ? 13.13.13 # you pass CROSS_COMPILE=blabla ./configure blabla ? 13.14.03 # this is my currently used complete configre script: http://pastebin.com/uZA5VwDt 13.15.04 # a diff would be helpful ;) 13.15.51 # or upload to gerrit for review 13.20.58 # this is the diff: http://pastebin.com/UGYpBgcP 13.21.57 # I currently don't want it to upload to gerrit, because it's not finished and has problems which I don't know what's going on... 13.23.51 # - it also contains a lot "echo" - to find the reason for my problems ;-) 13.24.39 # that looks complicated, why do you need all those include and libs dir ? The cross compiler is supposed to know that already 13.25.43 # ah ok some are commented 13.25.47 # there is a lot commented code 13.28.08 # there is a lot "test code" ;-) 13.28.55 # the problem is, that the generated GCCOPTS make the test compile to detect the architecture fails with "unknown command line option" 13.29.40 # and they don't seem to be wrong - when I enter the CC command by hand, with that exact parameters it works! 13.30.19 # here's the output of the 64-bit mingw compiler, called by the script: 13.30.23 # x86_64-w64-mingw32-cpp: error: unrecognized command line option ‘-W -Wall -Wundef -O -nostdlib -ffreestanding -Wstrict-prototypes -pipe -std=gnu99’ 13.30.55 # can you remind where the test is done in configure ? 13.32.08 # in line 375 in original configure, line 487 in mine 13.33.10 # that was bullshit - have to search it.. 13.34.06 # line 4277 in original script, 4398 in mine 13.34.54 Quit johnb3 (Ping timeout: 240 seconds) 13.35.06 # so you are saying that 13.35.06 # cpp_defines=$(echo "" | $CPP $GCCOPTS -dD) 13.35.06 # fails ? 13.35.19 # yes 13.37.51 # weird, on my (linux) machine, this works: 13.37.51 # CROSS_COMPILE=i686-w64-mingw32- ../tools/configure 13.37.51 # (I haven't tried to actually compiled the sim) 13.40.15 # what is your environment ? linux ? cygwin ? 13.46.27 # cygwin 13.47.46 # the really strange thing is: when I add a line with GCCOPTS= directly above the $CPP command in the original script with the determined parameters of my script it does work! 13.49.26 # can you replace /bin/sh by /bin§bash no line 1 ? 13.49.33 # yes, it seems to work - but it does find the wrong sdl-config and therefore it would use the wrong library and include directories... 13.50.18 # yes I understand there is a problem with sdl but are you saying that sh vs bash makes a difference at this line ? 13.51.31 # no, I don't think it's a bash vs. sh problem; as said - when I paste the parameter line in the original script it does work... 13.51.37 Join Senji [0] (~Senji@85.187.103.250) 13.52.07 # and what is the content of GCCOPTS normally ? 13.52.17 # I thought it could be some kind of invisible special characters which gets removed when pasting... 13.52.44 # I suspect it's more of an expansion problem 13.52.47 # what do you mean by "normally"? 13.53.07 # if you don't change it and let the script run without modification 13.53.19 # I suspect it treats $CC $GCCOPTS 13.53.25 # as having one argument only 13.53.58 Quit TorC (Read error: Connection reset by peer) 13.54.59 # GCCOPTS=-W -Wall -O -Wstrict-prototypes -pipe -std=gnu99 -fno-builtin -g -Wno-unused-result -mmmx -mno-ms-bitfields -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/SDL -D_GNU_SOURCE=1 -Dmain=SDL_main -I$(SIMDIR) -Wno-pointer-sign -Wno-override-init 13.55.44 Join TorC [0] (~TorC@cpe-50-113-35-138.hawaii.res.rr.com) 13.55.45 Quit TorC (Changing host) 13.55.45 Join TorC [0] (~TorC@fsf/member/TorC) 13.57.49 # on the first sight it's the same - on the second sight: it does onky have one space between "-Wall" and "-O" and between "-O" and "-Wstrict-prototypes" whereas the other version has two... 13.58.12 # spaces you be irrelevant 13.58.18 # and what is the error message again ? 13.58.24 # that's the reason why I think there could be some strange special characters which are not visible... 13.58.50 # i686-w64-mingw32-cpp: error: unrecognized command line option ‘-W -Wall -O -Wstrict-prototypes -pipe -std=gnu99 -fno-builtin -g -Wno-unused-result -mmmx -mno-ms-bitfields -I/usr/i686-w64-mingw32/sys-root/mingw/include/SDL -D_GNU_SOURCE=1 -Dmain=SDL_main -I$(SIMDIR) -Wno-pointer-sign -Wno-override-init’ 13.59.00 # what's weird in this message 13.59.12 # is that it *seems* it is trated the entire line as one argument 13.59.50 # yes, you're right - how could that be? 13.59.51 # because cpp print an error *per switch* when it does recognize it, not the entire line 14.00.29 # this is going to sound crazy but 14.00.38 # what happens if you replace the line by 14.00.38 # cpp_defines=`echo "" | $CPP $GCCOPTS -dD` 14.02.46 # you mean backticks instead of "$()"? No change! 14.04.56 # BTW, when I hardcoded paste the GCCOPTS line in my version of the script the error remains :-( 14.06.05 # hum, ok give me an hour, I'll install cygwin in a VM 14.06.28 # btw, how do you setup a cross compiling environment in you linux? I could not manage to compile the SDL library... 14.06.40 # I use cygwin64 if that matters... 14.07.14 # (with both: mingw64 and mingw32 - so I could in principal compile it for both "worlds") 14.09.25 # I have never compiled sdl for cross compile but I don't think it's a problem, you first install mingw on linux and then compile sdl using it. There is a project called "mxe" that contains scripts to help that I think 14.14.12 # Massa: downloading, it may take a small while, I'll ping you when I have a working setup 14.15.00 # In the meantime I try to remove all what is currently unneeded in my script version and I try to integrate your idea by getting the correct directory with the cross gcc... 14.18.11 Join johnb3 [0] (~johnb3@p5B296D6F.dip0.t-ipconnect.de) 14.26.06 # pamaury: Re ZEN, do you recall seeing anything supporting the notion here https://www.rockbox.org/irc/log-20170110#22:10:49 that there's at least two distinct LCDs used? 14.29.57 # I maintain there is no evidence for that though 14.30.06 # Creative has code for one LCD only 14.33.18 Join Senji_ [0] (~Senji@85.187.103.250) 14.37.11 Quit Senji (Ping timeout: 258 seconds) 14.38.55 Join Senji [0] (~Senji@85.187.103.250) 14.39.54 Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) 14.40.48 *** Saving seen data "./dancer.seen" 14.42.06 Quit Senji_ (Ping timeout: 255 seconds) 14.42.31 Quit StaticAmbience (Remote host closed the connection) 14.46.12 Join StaticAmbience [0] (~Quassel@host86-148-184-110.range86-148.btcentralplus.com) 14.47.02 Quit shmibs (Quit: leaving =o) 14.50.55 # OK, then I'll scratch that as a candidate cause for the LCD differences across units. 14.52.26 # I mean as usual take it with a grain of salt, reverse engineering is an art, the potential for mistakes is high 14.53.44 # I have found a difference between ZEN and ZEN X-Fi code, it's bit puzzling 14.54.23 # Do we have any better candidate explanation for the three different LCD performances I see? 14.56.15 # I mean: better than different LCDs. 14.57.44 # I don't have an explanation yet, except that the code must be doing something wrong and leads to unpredictable behavior 15.00.23 Join shmibs [0] (~shmibs@shmibbles.me) 15.00.56 Quit shmibs (Client Quit) 15.01.41 Join StaticAmbience_ [0] (~Quassel@host86-157-17-111.range86-157.btcentralplus.com) 15.02.22 Join shmibs [0] (~shmibs@shmibbles.me) 15.02.31 # Wrong code can given different results only if the hardware is different. 15.02.35 # So it sounds to me like different LCDs is the best explanation we have. 15.03.44 # You suggest Creative has code for one LCD only, but we don't know actually know that. 15.04.04 Quit StaticAmbience (Ping timeout: 240 seconds) 15.04.25 # We know only that the Creative code disassembly shows no detection of different LCDs. 15.04.58 # It may be that the same Creative code drives different LCDs fine. 15.06.05 # Without detecting the LCD type. 15.06.25 # that is incredibly unlikely though, and even if was true, I don't see the point because we couldn't possibly know that thus there is no difference one lcd or several lcd. 15.06.26 # Also if you do something unpredictable, the result can be different on each device, but no two LCD are exactly identical anyway 15.07.18 Quit shmibs (Quit: leaving =o) 15.08.42 Join shmibs [0] (~shmibs@shmibbles.me) 15.10.16 # so the real only difference I can see betwen ZEN and ZEN X-Fi code is that the X-Fi resets the LCD but the ZEN apparetly does not 15.12.00 Join skapazzo [0] (~skapazzo@151.9.205.1) 15.12.04 Quit StaticAmbience_ (Remote host closed the connection) 15.14.36 Join StaticAmbience [0] (~Quassel@host86-157-17-111.range86-157.btcentralplus.com) 15.15.05 # __builtin: are you here? 15.15.12 Quit dfkt (Ping timeout: 245 seconds) 15.17.02 # Massa: cygwin installed, I need to get rockbox and see if I miss libs 15.23.01 # chrisjj: one thing we can try to match closer to the OF is to avoid powering the LCD on/off but rather putting it in standby mode 15.23.23 # I'll send you a build to try 15.24.23 # (I think OF uses standby) 15.24.50 # (or might not power down at all) 15.28.25 # pamaury: I have no idea! 15.28.39 # gevaerts: about what ? 15.28.42 # * pamaury forgot 15.28.49 # The wiki 15.29.03 # ok, I thought we ran into this issue previously 15.29.08 # Well, maybe 15.29.23 # But I don't know anything more about the wiki than how to add people 15.30.49 # gevaerts: compared to yesterday we lost themes for Zen X-Fi and Zen X-Fi Style on the theme website 15.32.48 Join Senji_ [0] (~Senji@85.187.103.250) 15.33.23 # lebellium: the server went away every time I tried to re-run checkwps, so I went to sleep 15.33.51 # ok 15.34.24 # Also, technically yesterday the Zen X-Fi and Zen X-Fi Style weren't on the theme site at all! 15.34.46 # I mean once they were 15.35.01 # Yes, but that was after midnight :) 15.35.07 Join n3m9 [0] (~n3m9@ANantes-652-1-64-223.w90-59.abo.wanadoo.fr) 15.35.07 # lol 15.35.10 # ok you win 15.35.24 Quit Senji (Ping timeout: 256 seconds) 15.37.12 # * gevaerts has another go 15.41.42 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 15.42.21 Quit prg318 (Ping timeout: 258 seconds) 15.43.47 # pamaury: I don't see why the same Creative code driving different LCDs is incredibly unlikely. The difference could be immaterial to the particular way the Creative codes drives, especially if that coding was deliberate to avoid differences. 15.46.06 # The point of considering this is that it recommends RB drive very closely follows the OF drive. Which is not to say your RB drive doesn't already, but perhaps closer is needed. 15.46.49 # pamaury: I've a new version of the script - with that (much easier) I was able to compile a running x86 simulator - x64 version is in progress :-) 15.46.50 # I don't think you know how LCD works. There are litteraly no two different LCD that have the same init sequence 15.47.21 # Massa: I finally rockbox and cygwin so let me try a sim build 15.47.28 # And of course your suggestion of standing-by the LCD fits with that. 15.48.09 # ... provided the difference we see is after the current power down. 15.48.40 # pamaury: I accept there are literally no two different LCD that have the same init sequence known to you. 15.48.41 # Massa: I'm not familar with cygwin. What is the different between i686-w64-mingw32 and i686-pc-mingw32 ? 15.48.53 # (I got a lot of warnings - mostly format warnings and an error in puzzles - which I fixed by a small edit in rbwrappers) 15.49.05 # But while there's no better explanation known to you, I think this has to stand as the best explanation. 15.49.46 # Massa: ok so if I run: 15.49.46 # CROSS_COMPILE=i686-w64-mingw32- ../tools/configure 15.49.46 # I get 15.49.46 DBUG Enqueued KICK pamaury 15.49.46 # .... 15.49.46 # Cygwin host detected 15.49.47 *** Alert Mode level 1 15.49.47 # configure didn't find sdl-config, which indicates that you 15.49.51 # pamaury: Huh? I've i686-w64-mingw32 and x86_64-w64-mingw32 15.50.12 # the latter is the 64-bit version... 15.50.16 Quit StaticAmbience (Remote host closed the connection) 15.50.17 # I didn't install the 64-bit compiler, but I have an extra "pc" one 15.51.13 # BTW, one of the display differences could be due to non-LCD hardware differences. This is the dots. 15.51.13 # i686-pc-cygwin-gcc 15.51.14 # I guess it targets the cygwin environment 15.52.53 Join StaticAmbience [0] (~Quassel@host86-157-17-111.range86-157.btcentralplus.com) 15.53.17 # Massa: can you pastebin your diff to fix sdl-config ? 15.53.50 Quit robertd1 (Ping timeout: 240 seconds) 15.57.02 # pamaury: http://pastebin.com/TK2Tdaa0 15.57.45 # pamaury: did you install the 32- or the 64- version of cygwin? 15.58.50 # I installed cygwin64 but I must have chosen the 32-bit compiler in the (very long) list 15.58.55 # I don't think it matters anyway 15.59.48 *** Alert Mode OFF 16.00.13 # Massa: how do I tell cygwin to install more package ? Do I have to re-run the installer ? 16.00.45 # Yes, re-run the installer anytime you want to install more packages or to update existing ones... 16.01.14 # the 64-bit compilation stops now with an error: 16.01.19 # make: *** [/cygdrive/d/Prog/Projekt/RockBox/rockbox.git/lib/rbcodec/codecs/codecs.make:189: /cygdrive/d/Prog/Projekt/RockBox/rockbox.git/build.ipodvideo.sim/lib/rbcodec/codecs/libopus/silk/resampler_private_AR2.o] Error 127 16.01.37 Join robertd1 [0] (~root@186-90-12-124.genericrev.cantv.net) 16.01.54 Part robertd1 16.01.59 Join robertd1 [0] (~root@186-90-12-124.genericrev.cantv.net) 16.03.34 # So do you think i686-pc-mingw32 is the 32-bit version for 32-bit compiler? And i686-w64-mingw32 is the one for a 64-bit compiler? 16.04.53 # If yes, how can we distinguish / detect which one is present? And what about the old i586-mingw32msvc which is currently present in the script? 16.06.30 # no, I think i686-w64-mingw32 is the windows toolchain that targets windows (without dependency on cygwin) whereas i686-pc-mingw32 targets cygwin 16.06.58 Quit StaticAmbience (Ping timeout: 255 seconds) 16.07.14 # i586-mingw32msvc probably doesn't exists anymore, now afaik, there are only two toolchains: i686-w64-mingw32 and x86_64-w64-mingw32 16.08.03 # at my installation x86_64-pc-cygwin seems to target cygwin64, so I assumed that i686-pc-cygwin would target 32-bit cygwin? 16.09.01 # yeah, but better use the w64-mingw32 I think 16.09.04 # anyway, in your diff 16.09.15 # I don't like the 64-bit option 16.09.20 # BTW, I already tried to compile a "native" cygwin simulator - that shows a lot compile problems because of duplicated headers in rockbox' "firmware/libc" and /usr/include... 16.09.30 # the script should detect 64-bit and use override it if necessary 16.10.27 # no, I don't think so - in prinicpal I'm able to choose between 64-bit and 32-bit in my environment (and the 64-bit compile does not work...) 16.10.45 # arg, /me hates windows 16.10.46 Join StaticAmbience [0] (~Quassel@host86-170-83-76.range86-170.btcentralplus.com) 16.11.55 # you can do the same in 64-bit Linux! 16.12.20 # Huh? What does this mean: 16.12.30 # 0 [main] make 4384 fork: child -1 - forked process 1008 died unexpectedly, retry 0, exit code 0xC0000142, errno 11 make: /cygdrive/d/Prog/Projekt/RockBox/rockbox.git/apps/plugins/rockboy/rockboy.make:18: fork: Resource temporarily unavailable 1 16.12.56 # 1091979 [main] make 4384 fork: child -1 - forked process 5144 died unexpectedly, retry 0, exit code 0xC0000142, errno 11 16.13.01 # yes but that's my point: if you don't say anything, it uses gcc (whatever default it uses). If you want to target *something else*, you have to do something (change compiler) 16.13.24 # admitedly cygwin doesn't make it easy because there is no easily detectable compiler 16.14.15 # yes, you're right - I also wondered why they didn't integrate all the different versions in _one_ gcc (with target options)... 16.14.33 # Maybe that's possible - but we don't know it ;-) 16.15.35 # you can build a multilib gcc yes 16.15.37 # like on linux 16.17.17 # do you know what all those "forked process died unexpectedly" mean which I get, when I try to build the 64-bit simulator version? 16.17.33 # nope :( 16.18.07 # Massa: reading your sysroot handling, I suspect it's going to fail on linux 16.18.25 # or other targets 16.18.40 # because I am not 100% that a sysroot is mandatory 16.19.04 # hum scratch that, it just prints a warning 16.20.24 # No, you're right - I should surround it by a if [ "$winbuild" = "yes" ]... 16.21.58 # Or maybe it's not bad to keep it as is - and to only surround the warn messages with that "if"... 16.22.42 # damn, cygwin is slooooooooow 16.22.54 # and doing things, I don't know what 16.23.14 # what do you mean? 16.24.39 # I don't know, the whole is just super slow 16.25.35 # It's slow - but it's also slow to compile in a VM... 16.26.26 Quit n3m9 (Read error: Connection reset by peer) 16.30.05 Quit pamaury (Ping timeout: 255 seconds) 16.30.15 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 16.31.54 # Massa: your patch works, there are two things I don't like: 1) it touches unrelated lines (probably spaces) 2) in findsdl, I'm not a big fan of setting IFS=":" once, I find it clearer to set IFS before every loop 16.32.15 # I'm trying to compile now (32-bit) 16.33.59 Join Senji [0] (~Senji@85.187.103.250) 16.34.22 Quit Petri152 (Ping timeout: 245 seconds) 16.35.13 # Massa: did you compile with make -j by any chance ? 16.36.42 Join StaticAmbience_ [0] (~Quassel@host86-157-17-68.range86-157.btcentralplus.com) 16.36.45 Quit Senji_ (Ping timeout: 248 seconds) 16.39.24 # ah damn, make fails because it tries to call gcc 16.40.32 # pamaury: The ZEN Unit N colours dots could be due to differences in SoC, not LCD. The fact it shows in the RB bootloader indicates it is not provoked by your LCD power-down. 16.40.43 Quit StaticAmbience (Ping timeout: 255 seconds) 16.40.52 *** Saving seen data "./dancer.seen" 16.41.19 # Massa: did you run this issue as well ? 16.41.57 Join Petri152 [0] (~Petri@petritrebs.ca) 16.43.17 # No, I didn't have this issue 16.43.54 # For your suggested build to try, I vote for backlight sleep ding nothing else to the LCD i.e. no standby or powerdown. If that cures the flash (and I bet it will) then we can benchmark the battery runtime to see if there'd be any gain from a debugged LCD powerdown/standby. 16.44.19 # about touching the unrelated lines - that's because I configured the editor to remove trailing spaces when saving... 16.45.39 # about IFS - it never gets set back - do you think the correct way is to set it before the loop, reset it after it and again for the next loop? 16.46.36 # I now try to compile the 64-bit version with "make -j 1" - and no, I didn't gave it a "-j" option before... 16.46.57 # Massa: no, the correct way is for each loop to set it to what it wants. Because if you set it for several loops and of one them changes, you siltently break the other, not good 16.47.20 # Massa: ok, I was thinking the -j could make cygwin run out of resource for processes but apparently that's not it 16.49.27 # is there any make configuration or environment variable which could change the default behaviour of "-j 1"? 16.49.32 Join guest6538 [0] (~user@49.206.117.146) 16.54.32 Quit guest6538 (Read error: Connection reset by peer) 16.54.32 Quit TorC (Read error: Connection reset by peer) 16.55.49 # pamaury_: with "make -j 1" my 64-bit compile also works and produces a running executable :-) 16.56.00 Quit StaticAmbience_ (Ping timeout: 240 seconds) 16.56.18 Join StaticAmbience [0] (~Quassel@host86-157-17-68.range86-157.btcentralplus.com) 16.56.38 Join TorC [0] (~TorC@fsf/member/TorC) 17.08.10 Quit Strife89 (Ping timeout: 240 seconds) 17.08.13 Quit Petri152 (Ping timeout: 248 seconds) 17.08.56 Join Strife89 [0] (~quassel@adsl-98-67-57-35.mcn.bellsouth.net) 17.34.03 Nick Massa is now known as massa_ (4fe8c676@gateway/web/freenode/ip.79.232.198.118) 17.47.09 Join Petri152 [0] (~Petri@petritrebs.ca) 17.47.29 # massa_: so what was the problem ? 17.48.24 # massa_: in your cygwin env, do you have a default compiler, ie if you type "gcc -v", does it print something ? 17.48.57 # pamaury_: it seems my make does get called (somehow) with -j n (n > 1); the call with "make -j 1" fixes this... 17.49.35 # pamaury_: yes, e.g. it prints "Target: x86_64-pc-cygwin" 17.49.39 # chrisjj: I will send you a build with no lcd sleep. It will solve the white flash but not the lcd dot problem. And I'm not really sure about battery life 17.49.55 # massa_: ah, I don't have such a compiler, that's why it fails for me 17.50.40 # pamaury_: oh, do you think it should be possible to build without a "native" gcc? 17.51.23 # no clearly it's not, it's just that in this case, we are not really "cross" compiling, we could use the same compiler for host and target (ie mingw) 17.53.16 # I have to do some cleanups for the script changes and then I can put it to gerrit (if I manage how to do this) for review. 17.53.39 # But not now - I'm away, at least for a few hours... 17.53.57 # did you make changes to other files ? 17.54.41 # BTW, I think the correct way in findsdl is to wrap the sysroot things with if [ -n "$CROSS_COMPILE" ] 17.54.51 Quit ZincAlloy (Quit: Leaving.) 17.56.10 # pamaury_: there are a lot of warnings (for whom I want to have a look later) - but only one error in "apps/plugins/puzzles/rbwrappers.c" 17.56.37 # yes sysroot should be conditional to cross compile 17.56.47 Quit Bilgus (Quit: Leaving) 17.57.32 # pamaury_: that's why I wanted to talk to __builtin, there is a method named "vsscanf" in it - which conflicts with a system one... 17.58.35 # pamaury_: it's only called once - a few lines above, so I just changed the name of that function from "vsscanf" to "sscanf_vsscanf" - that was it... 18.00.13 # pamaury_: thanks for your help! When I'm back and cleaned up the changes at the scrip I'll ping you again - maybe today, maybe tomorrow :-) 18.00.24 # Bye! 18.00.44 Quit massa_ () 18.05.03 # <__builtin> dang it 18.05.05 # <__builtin> too late 18.06.42 Join prg318 [0] (~prg318@deadcodersociety/prg318) 18.08.48 # chrisjj: https://www.dropbox.com/s/zmj6pq33hr54bwr/rockbox_zen_nolcdsleep.zip?dl=0 18.37.02 # chrisjj: there ? 18.37.04 Nick pamaury_ is now known as pamaury (~pamaury@rockbox/developer/pamaury) 18.40.01 Join johnb2 [0] (~johnb2@p5B296D6F.dip0.t-ipconnect.de) 18.40.54 *** Saving seen data "./dancer.seen" 18.44.09 Quit johnb2 (Ping timeout: 240 seconds) 18.45.45 # chrisjj: could you check if https://www.dropbox.com/s/n96ich90ua23v28/rockbox_zen_dotclkpolfix.zip?dl=0 fixed the lcd with coloured dots ? 18.58.16 Quit jhMikeS (Ping timeout: 256 seconds) 19.24.03 # me returns. 19.24.38 # pamaury: shall I test both, or one? 19.25.02 # chrisjj: both please 19.25.36 # nolcdsleep is the one where I disabled lcd sleep on backlight, so I expected to white flash but worse battery life and still coloured lcd dots 19.25.50 # dotclkpolfix is the one that tries to fix the coloured lcd dots 19.26.55 # OK. 19.28.19 # I found a "bug"/mismatch in the LCD configuration and soc configuration that could result in unpredictable behavior and potentialy corrupted lcd data 19.36.54 # On Unit G (on which lcd_fix shows flash on backlight wake and sleep), rockbox_zen_dotclkpolfix 93c2fbb0d-170114 again shows flash on both. 19.37.23 Join johnb2 [0] (~johnb2@p5B296D6F.dip0.t-ipconnect.de) 19.37.33 # chrisjj: dotclkpolfix doesn't fix flash 19.38.05 # it's only supposed to fix the unit where you get funny dots (could you upload a picture of that btw ?) 19.41.45 # On Unit G, rockbox_zen_nolcdsleep 0cabc1fc5M-170114 shows no flash on sleep and a shorter and dimmer flash on wake. On sleep, the backlight fade doesn't reach zero. 19.42.17 # Now I'll test on for coloured dots, requiring Unit N. 19.44.30 Join n3m9 [0] (~n3m9@ANantes-652-1-64-223.w90-59.abo.wanadoo.fr) 19.47.23 # On Unit N (on which the lcd_fix bootloader and .rockbox show coloured dots), rockbox_zen_dotclkpolfix 93c2fbb0d-170114 shows no change. And like other recent builds, it shows a data abort after the RB logo. 19.50.57 # On Unit N, rockbox_zen_nolcdsleep 0cabc1fc5M-170114 shows no change. 19.51.50 # And like other recent builds, it shows a data abort after the RB logo, though two out of five runs showed a RB logo with keys non-responsive. 19.53.30 Quit johnb2 (Ping timeout: 240 seconds) 19.53.52 Quit __builtin (Ping timeout: 260 seconds) 19.54.21 Join __builtin [0] (~xray@cpe-75-177-76-62.triad.res.rr.com) 19.54.44 Nick __builtin is now known as Guest43679 (~xray@cpe-75-177-76-62.triad.res.rr.com) 19.55.57 Quit Guest43679 (Changing host) 19.55.57 Join Guest43679 [0] (~xray@rockbox/developer/builtin) 19.56.27 # chrisjj: can you take a picture of the data abort with dotclkpolfix ? 19.57.25 Nick Guest43679 is now known as __builtin (~xray@rockbox/developer/builtin) 19.57.32 # By Screendump, unlikely, since this function broke a while back. 19.58.12 # you can't a screendump of a data abort, I mean picture, litteraly 20.02.24 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:8c6b:961d:b210:157a) 20.04.51 # OK, fetching camera... 20.06.28 # I still don't understand the data abort, and why specifically on this device, why is it special ? 20.06.53 # Webcam blinded http://i.imgur.com/UkyMcAz.png 20.07.18 # ah 20.07.25 # can you pastebin the whole text ? 20.07.38 # or at least all the pc address and stack trace if any ? 20.10.59 # Phone blinded too. 20.10.59 # config.cgf brightness is ignored by the Data Abort screen 20.11.16 # Transcribing to pastebin... 20.11.34 # data abort cannot access config.cfg... 20.29.53 # http://pastebin.com/dkudq48N 20.30.23 Join johnb2 [0] (~johnb2@p5B296D6F.dip0.t-ipconnect.de) 20.31.08 # I guessed data abort does not access config.cfg, but I'd hoped it would retain the brightness previously set by .rockbox from config.cfg. 20.31.46 # chrisjj: no because if a data abort happens when lcd is off there is no way to know the value of the setting, thus setting backlight to 100% is the only safe option 20.31.56 # chrisjj: does the data abort happen in the bootloader or in .rockbox ? 20.32.30 # Yup, makes sense. I was just hoping otherwise. Though I'd say 30% would do fine too :-) 20.32.55 # Re the Data Abrt, as teh pastebin says, it follows the RB logo. 20.33.21 # ah yeah the BL doesn't display a logo 20.33.51 # are you using a custom theme ? 20.34.30 Quit johnb2 (Ping timeout: 240 seconds) 20.35.13 Quit paulk-collins (Quit: Leaving) 20.39.19 # To the pastebin I added a description of all screen updates prior to the Abort. 20.39.33 # No, I am using factory defaults. 20.40.03 # I.e. I am using your .ZIPs .rockbox with no added config.cfg. 20.40.57 # The coloured dots show in the BL and .rockbox, but I have seen the DA only in .rockbox. 20.40.58 *** Saving seen data "./dancer.seen" 20.42.26 # the data aborts occurs in the skin engine 20.42.37 # do you remove .rockbox entirely between tests ? 20.42.58 # I rename it. 20.43.25 # Skin engine, eh? As with previous builds, the DA varies (e.g. can be 'at 6004C7F8'). And occasionally is absent, whereupon I see the RB logo but keys are unresponsive. 20.44.04 # There's no BSoPO as one would expect from a freeze and angry watchdog. 20.45.22 # And the coloured dots are flashing, as you'd expect if RB had got stuck in a loop that pacified the watchdog AND the dots are bytes from working memory getting fed to LCD by wayward DMA controller. 20.49.36 # FWIW, deleting all cabbieV2 makes no difference. 20.50.58 Join Strife1989 [0] (~Strife89@204.116.245.126) 20.51.17 Nick Strife1989 is now known as Strife89|laptop (~Strife89@204.116.245.126) 20.51.21 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 20.51.21 # * pamaury wonders what makes this particular unit special 20.52.08 # anyway 20.52.16 # you can try to benchmark the nolcdsleep if you want 20.52.22 # see if that makes a big difference battery wise 20.56.08 # pamaury, no thing I know makes this unit special except that it is the only one that shows the coloured dots and data abort on RB. On OF, it operates exactly as does other units, inc. other units that don't show dots and DA on RB. 20.58.07 # An interesting thing. If I start the unit from reset by connecting it to PC and then disconnecting, sometimes I get no DA and .rockbox runs. 20.59.06 # Dots are present. Menus are operable. WPS causes DA. 20.59.12 # I have it running now. Any diagnostics I should extract? 21.01.08 # I can't think of anything 21.01.17 # there must be something wrong but I have no idea what 21.01.38 # Oops, entering Text Editor gave DA. Undefined instruction at 61EC4500. 21.04.52 # I reverted to a build in which Screendump is less broken, and with dots on screen got this: http://i.imgur.com/hp8GEat.png , http://i.imgur.com/slHExCs.png . 21.06.16 # That clearly indicates the dots aren't in the the main memory frame buffer and hence are being created by e.g. the DMA, no? 21.10.26 # no I think are created by the LCD, or more specifically by a subtle mismtach in the timing with the lcd, but that's just a theory 21.10.49 # Sounds probable to me. 21.11.47 # Shame I can't show you an image. I think you'd find the dot pattern very illuminating. 21.12.50 # ZEN tester's Pro Tip: Though Screendump broken on recent builds and appears broken on Build 3f55f01-131201, that specific build does save the .bmp you want despite then saving a stream of repeats under successive filenames until it gives a Data Abort. 21.13.59 # BTW, what means the "Scanning disc" popup that appears before the crash on some builds? 21.14.10 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 21.14.57 # <__builtin> it's the database, I thinkj 21.18.30 # What could trigger database activity on an install with no config.cfg? Some other user file?? 21.21.36 Quit rudi_s (Quit: leaving) 21.21.41 # pamaury, the dot pattern is invariant in layout, differing (and continuously) changing in colouration. There are typically 381 dots, arranged in 16 columns evenly spaced at 20 pixels, in approx. 24 rows. 21.23.42 # Each dot is one non-black pixel, or two horizontally separated by about three pixels. 21.25.06 Join rudi_s [0] (~simon@kraftwerk.ruderich.eu) 21.25.07 # Two pixels in the same dot are always different colour. Vertically adjacent dots are mostly the same colour. Horizontally adjacent dots always differ in colour. 21.27.31 # The first dot is on pixel row 0 or 1 (counting from top). The last dot is on approx pixel row 192. 21.30.18 # Vertically adjacent dots are eight pixels apart. Each dot is on the pixel row /below/ the dot immediately to its left. 21.32.51 # This means that the dot positions are as if something stepped through a 320-pixel-wide row-by-row frame buffer in memory order, each step being 336 pixels, and each footfall leaving a coloured dot. 21.32.54 # 3Gerrit review #336 at http://gerrit.rockbox.org/r/336 : 3SH gcc 4.6.3 with link-time optimization, for Archos targets by Boris Gjenero 21.33.27 # <__builtin> hmm 21.33.30 # <__builtin> g 123 21.33.32 # 3Gerrit review #123 at http://gerrit.rockbox.org/r/123 : 3Add an alternative analogic touchpad sensitivity setting by Jean-Louis Biasini 21.33.38 # <__builtin> g 123 21.33.40 # 3Gerrit review #123 at http://gerrit.rockbox.org/r/123 : 3Add an alternative analogic touchpad sensitivity setting by Jean-Louis Biasini 21.34.03 # Perhaps some of those numbers ring bells from the DMA process. 21.42.08 # dma doesn't do anything but pushes the pixel to the lcdif. It's the lcdif that controls how the data is sent. I am not entirely sure I visualize the thing correctly. 21.43.56 Join johnb2 [0] (~johnb2@p5B296D6F.dip0.t-ipconnect.de) 22.09.22 # Pushing pixels to the LCDIF is the only operation that can cause such a messup, surely? 22.10.10 # chrisjj: not so sure, if I had to choose, I would blame the lcdif rather than the DMA but who knows 22.10.10 # Does one frame's push occur in a single DMA operation, do you know? Or in smaller blocks. 22.10.20 # chrisjj: are you planning to ship me this unit ? 22.11.07 # I was planning to ship you a unit that works best, but perhaps I should put this one that works worst in too. 22.11.22 Join massa [0] (4fe8c676@gateway/web/freenode/ip.79.232.198.118) 22.11.42 # no each frame uses, iirc, 4 linked DMA transfers 22.11.55 # 4? Why 4? 22.12.14 # pamaury: I'm back again :-) 22.12.44 # To fit inside a 64K byte limit, perhaps? 22.13.51 # <__builtin> hello massa 22.13.53 # each transfer can do 64K and the frame is 320 x 230 x 3 bytes 22.13.59 # <__builtin> sorry I wasn't around earlier 22.14.12 # pamaury: I did some more changes in my script - and suddenly the error occured again... 22.14.47 # massa: which changes ? I managed to build the simulator fine, after the vscanf problem 22.15.11 # __builtin: Hi, did you read the content of the chat of this day? 22.16.36 Quit jhMikeS (Ping timeout: 256 seconds) 22.16.40 # pamaury: as I said - some cleanup and also some checks for the different possible CROSS_COMPILE variants for x86 22.16.56 # <__builtin> massa: parts of it ;) 22.17.40 # <__builtin> I see that there's a naming conflict in sgt-puzzles, I can fix that 22.17.40 # pamaury: and I found out, what the problem is - you were right, the CC call treats the GCCOPTS as _one_ parameter! 22.17.53 # pamaury: and I know why this happens :-) 22.18.18 # massa: haha! I suspected that but I don't know why ? 22.18.26 # because it works here 22.18.44 # __builtin: I found a problem in apps/plugins/puzzles/rbwrappers.c 22.18.53 # <__builtin> anything else? 22.19.56 # __builtin: no, I did currently not see your post :-) 22.20.27 # pamaury: the reason is somehow setting IFS=":" 22.22.26 # pamaury: I added another for loop with checks and a leading IFS=":" - and an echo of GCCOPTS before and after - before it's good and after it's not good... 22.23.00 # hum, interesting 22.23.12 # I wonder if IFS influences argument splitting in commands 22.23.43 # seems so - when I set back IFS to the initial value, everything is fine! 22.24.18 # massa: http://tldp.org/LDP/abs/html/internalvariables.html 22.24.26 # it definitely influences echo 22.24.45 # massa: I have a theory, switch to bash instead of sh 22.26.48 # does not change a thing 22.27.17 # maybe IFS gets automatically restored after leaving a function? 22.27.20 # somehow I would expect the IFS change to be local, but that may depend on how you write it 22.27.39 # (and my newer changes are not inside a function) 22.29.30 # massa: then the simple solution is to unset IFS 22.29.37 # IFS=":" 22.29.38 # blablabla 22.29.38 # unset IFS 22.30.04 # the simplest solution in my case is not to set IFS and use space separated name lists :-) 22.32.17 # that will paths with spaces though (which could break for a whole lot of other reasons I admit) but yeah you can do that 22.34.57 # no, no - the loops over the PATH are all inside functions - I mean my new one with a list of potential CROSS_COMPILE names 22.35.35 # gevaerts: I assume we have to give up :) 22.37.43 # pamaury: I just checked it, after leaving a function the IFS is unset again... 22.40.59 *** Saving seen data "./dancer.seen" 22.41.33 # * [Saint] thinks if you're using paths with spaces in you deserve to get your shit broken 22.41.57 # <[Saint]> (also - yes, field separators create some odd magic at times) 22.45.39 Quit skapazzo (Quit: Lost terminal) 22.48.21 # Saint: I don't think any cross compiler environment name (e.g. i686-w64-mingw32) will contain a space - so keeping them in a space separated list should imho O.K. 22.50.39 # <[Saint]> AFAIK, you're right, but you can't account for end users doing "weird shit" (TM). 22.50.44 # pamaury: do you still have your VM environment with no native gcc? 22.50.56 # <[Saint]> But IMO spaces in paths is a cardinal sin. 22.51.33 # pamaury: here's the configure diff of my latest version: http://pastebin.com/2hZVjeTs 22.51.56 # pamaury: this should also work in pure cross hosting environments... 22.53.20 # [Saint]: well, I assume possible spaces and other strange characters are the reason why the PATH separator is a ":" :-) 22.54.33 # So you always have to expect the worst when handling with filenames and directory names... 22.56.27 # __builtin: BTW, in my self compiled (64-bit) simulator the keypresses works :-) 22.56.54 # <__builtin> massa: sorry, in what context, again? 22.59.49 # __builtin: that was the reason why I started the whole thing - I had problems with the simulators compiled by rasher and then tried to compile them myself... 22.59.59 # <__builtin> ohh, yeah 23.00.12 # <__builtin> I forgot for a second 23.00.14 # <__builtin> nice job! 23.01.23 Join johnb3 [0] (~johnb2@p5B296D6F.dip0.t-ipconnect.de) 23.01.39 # massa: no I installed the pc-cygwin-blabla and I can just gcc in cygwin now 23.02.00 Quit johnb2 (Ping timeout: 258 seconds) 23.02.17 # massa: thanks, I'll have a look at the diff later 23.02.30 # <[Saint]> we found the one guy who uses cygwin folks. 23.02.30 # <[Saint]> the searchis over. 23.02.42 # pamaury: shit, then my two-liner to fix it for those environments cannot be tested :-) 23.07.42 # [Saint]: Well, I first tried to use a recent version of Ubuntu - but this doesn't worked either, I couldn't build the simulators... 23.08.19 # <[Saint]> wow - two people using cygwin in one day. 23.08.26 # <[Saint]> we are truly blessed by a miracle. 23.08.42 Quit Strife89|laptop (Quit: Leaving) 23.09.03 # [Saint]: So I gave cygwin a try again - nowadays I most of the time use windows at my laptop (had been different in the past)... 23.09.39 # [Saint]: oh, you didn't talk to me? 23.09.54 # <[Saint]> But...yeah, compiling for Windows is a royal pain in the tits and the environment can break if you look at it sideways. 23.10.08 # <[Saint]> massa: no, it was originally directed at pamaury 23.10.39 # [Saint]: pamaury only installed cygwin in a VM to help me find and fix the cross compiling issues :-) 23.10.57 # <[Saint]> aha, right. 23.11.11 # I usually don't compile on windows, I cross compile from linux but hey 23.12.48 # pamaury: and you also compile the simulators for windows in your linux cross environment? 23.13.14 # I don't compile simulators for windows but I don't see why it can't be done 23.13.32 # you need to cross compile sdl and then cross compile the sim 23.13.51 # that doesn't sound too horrible, I mean compared to RBUtil for example 23.15.37 # <[Saint]> Oh, absolutely. It's just annoying, not particularly difficult. 23.16.04 # <[Saint]> Not having the statically linked SDL is what I think gets most people. 23.16.27 # <[Saint]> and perhaps the absolute myriad of params that govern it. 23.17.26 # Hmm, I couldn't manage it in the first place and then searched in the Internet for somebody who managed it - and it seems to be difficult 8-) 23.18.15 # I wonder why there aren't precompiled packages for that - you can get packages for a lot of cross-compiled libraries, but not for SDL... 23.18.38 # BTW, which of the SDL libraries does rockbox use? 23.19.14 # <[Saint]> I legitimately have no idea and I made absolutely zero effort to find out. 23.19.27 # <[Saint]> I just compiled _ALL THE THINGS_ in my static binary. 23.19.51 # <[Saint]> bluebrother would be able to tell you. 23.20.25 # <[Saint]> oh, actually, maybe not. 23.20.40 # <[Saint]> I imagine rbutil and the sim have radically different requirements. 23.20.41 # And what's difficult with rbutil? 23.21.07 # massa: I think we just use the basic SDL library 23.21.21 # massa: for rbutil you need all of Qt 23.22.15 # That's easy - I often compiled Qt in a lot of environments :-) 23.24.04 # Well apparently bluebrother runs into problem with accessibility stuff 23.24.17 # But I never tried to compile rbutil - never saw a reason to do that... 23.25.58 # What about all those warnings, especially in DEBUGF formats, when I compile it? Don't they come in linux? 23.26.09 # <[Saint]> the current reason is if you have an iPod 6G and want to test the bootloader installation automation. 23.26.43 # <[Saint]> They do. But warnings are warnings. If it was a problem they'd be errors. 23.27.02 # <[Saint]> I generally just tell it to shut up about warns. 23.27.27 # [Saint]: yes I have one and tried to put SDXC cards in it - I gave up (nothing to do with rockbox) 23.28.27 # <[Saint]> Lots of people seem to have a wide range of issues with SD or CF based solid state conversion in the ipods. 23.28.34 # <[Saint]> I guess I've been relatively lucky. 23.28.57 # [Saint]: about warnings: I have another opinion about warnings - they have a reason and point to potential problems; if they can be fixed they should 23.29.24 # <[Saint]> That reminds me that I still want to try an ipod6g build with multivolume in a large format disk and see if the OF is fine running off the first partition. 23.30.54 # [Saint]: I tried that - and the OF still corrupted my disk; everything is fine if you use cards below the magical 128G limit - but you'll have trouble if you use bigger ones. 23.31.29 # massa: warning of formats are really annoying 23.32.07 # [Saint]: All that was the reason why I bought an old iPod Video 5.5 - with that everything works (but with really really slow transfer rates from PC to Pod) 23.32.11 # <[Saint]> massa: yeah, bummer, I kinda had a feeling it would do that...well, you saved me from wasting that time I guess. 23.32.16 # because windows and linux don't handle the same format, and rockbox itself probably doesn't have a very standard implementation anyway 23.32.57 Quit user890104 (Quit: .) 23.33.18 Join user890104 [0] (Venci@unaffiliated/user890104) 23.33.34 # pamaury: what is that z prefix in the format (e.g. %zu)? 23.35.40 # size_t 23.35.57 # aah, I see it's actually a C99 addition for size_t 23.38.23 # so why are the global CCOPTS (which contain -std=gnu99) not used in my case? 23.39.30 # I mean it's used, but does not show a effect? 23.41.29 # massa: iirc, windows's printf doesn't know about %zu 23.42.08 # I'm not 100% sure 23.42.32 # honestly that's really really low priority 23.48.46 # pamaury: normally it should link against a mingw gcc libc version which should support it or not? 23.52.35 # maybe we should just add "-Wno-format" to get rid of those warnings? 23.55.03 # maybe 23.56.59 # at least in the windows cross compiles... 23.57.15 # (and that we see other, more important warnings...)