| 00:00:14 | pamaury | 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 | chrisjj | I wasn't complaining. But thanks - I'll take that raincheck :-) |
| 00:03:01 | chrisjj | 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 | pamaury | yes |
| 00:06:13 | chrisjj | OK. The UWFSF on backlight /wake/ was cured, but interestingly by the bootloader update from V2Beta, not by the .rockbox update. |
| 00:06:37 | pamaury | UWFSF ? |
| 00:07:01 | chrisjj | ugly white full-screen flash :-) |
| 00:09:01 | chrisjj | I mention this for in case state persisting from the bootloader is not supposed to affect LCD performance under .rockbox. |
| 00:09:45 | chrisjj | I'd have thought it was not. I.e. I'd have thought .rockbox would completely setup the LCD state itself. |
| 00:10:18 | pamaury | it does |
| 00:10:19 | chrisjj | Sorry. s/The UWFSF on backlight /wake/ was cured/The UWFSF on backlight /sleep/ was cured/ |
| 00:11:09 | chrisjj | Well, if it does, I wonder how come I see different performance of LCD in .rockbox, after different bootloaders. |
| 00:11:52 | chrisjj | 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 | pamaury | 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 | chrisjj | Thanks. I too wouldn't care, if the port ran reliably. |
| 00:18:41 | chrisjj | On the UWFSF, is this something on which you'd appreciate further info? |
| 00:19:21 | pamaury | 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 | lebellium | gevaerts: where should I look for the shortname checking with WPS usage? |
| 00:21:30 | lebellium | matching checkwps usage* |
| 00:21:47 | chrisjj | OK. |
| 00:22:33 | chrisjj | BTW, I just reflashed Unit G bootloader from V2Beta to lcd_fix... and the sleep UWFSF remains! |
| 00:22:35 | gevaerts | lebellium: I'm pretty sure it's the name you can give to configure |
| 00:22:40 | gevaerts | Not sure if that helps :) |
| 00:23:07 | lebellium | Is it necessarily the same name as the config file name. For example creativezen.h ? |
| 00:23:24 | gevaerts | no |
| 00:23:46 | gevaerts | Arguably it *should* be, but those can be different |
| 00:24:37 | gevaerts | 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 | chrisjj | 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 | lebellium | gevaerts: here you go http://pastebin.com/0He38QRE |
| 00:31:12 | pamaury | ah great, freescale but a speaker powerdown bit but it cannot be cleared once it is set, seriously? |
| 00:34:44 | chrisjj | 'markedly different LCD performance' Both with config.cfg deleted. |
| 00:36:16 | gevaerts | 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 | lebellium | thanks |
| 00:37:47 | lebellium | working |
| 00:37:53 | lebellium | magic |
| 00:38:17 | pamaury | damn, I wonder if the speaker also needs some magic like the headphones to start |
| 00:39:41 | chrisjj | Freescale: 'It is reset by a power-on reset only' |
| 00:40:29 | *** | Saving seen data "./dancer.seen" |
| 00:40:34 | chrisjj | 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 | gevaerts | lebellium: I imagine some of those have new resolutions |
| 00:41:17 | lebellium | 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 | pamaury | chrisjj: I assume the MUTE bit of the speaker control powers up/down |
| 00:42:51 | lebellium | gevaerts: Samsung YH-820 is new resolution. It's the only one which should have 0 theme |
| 00:43:52 | chrisjj | pamaury: I failed to parse that. |
| 00:44:37 | * | pamaury is speaking about MUTE in HW_AUDIOOUT_SPEAKERCTRL |
| 00:44:43 | gevaerts | Hmmm |
| 00:46:12 | __builtin | oh hey gevaerts, I was wondering something |
| 00:46:22 | gevaerts | 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 | scorche | gevaerts: yeah - i saw those errors recently |
| 00:47:12 | chrisjj | ' 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 | gevaerts | No |
| 00:47:58 | pamaury | chrisjj: quoting the manual is not helping... |
| 00:48:04 | gevaerts | It definitely won't build all revisions |
| 00:48:09 | scorche | gevaerts: you know of a quick fix or should it just wait until i completely re-do that server? |
| 00:48:28 | chrisjj | Are you following the speaker antipop startup/shutdown sequence? |
| 00:48:39 | pamaury | it is described nowhere so no |
| 00:49:18 | chrisjj | Ah. Meets the definition of magic, so perhaps yes you do need to apply some :( |
| 00:49:40 | gevaerts | scorche: the first issue is it missing sdl-config |
| 00:50:14 | gevaerts | And then for some targets the android sdk apparently... |
| 00:50:19 | gevaerts | (and ndk) |
| 00:50:30 | gevaerts | 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 | chrisjj | 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 | pamaury | chrisjj: yes, that's for headphone only and it doesn't work |
| 00:54:46 | pamaury | I implement my own version of antipop |
| 00:55:40 | chrisjj | 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 | pamaury | actually funny thing, the power down bit for speaker can be cleared and set at will, despite what the manual says |
| 00:58:33 | pamaury | and no typo was not a joke |
| 00:59:05 | chrisjj | 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 | gevaerts | 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] | </s> |
| 01:00 |
| 01:00:18 | fs-bluebot | Build Server message: New 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 | scorche | gevaerts: libsdl1.2-dev? |
| 01:02:53 | gevaerts | Yes, that's the one I expect |
| 01:04:19 | scorche | k - done |
| 01:05:23 | gevaerts | Great! |
| 01:05:28 | gevaerts | Seems to work |
| 01:06:01 | gevaerts | Well, the ones I expect to work. You didn't magically fix unmaintained broken half finished ports :) |
| 01:11:29 | fs-bluebot | Build Server message: Build round completed after 670 seconds. |
| 01:11:30 | fs-bluebot | Build Server message: Revision 637c741 result: 6 errors 1 warnings |
| 01:11:53 | lebellium | gevaerts: should I see a difference now? |
| 01:13:48 | gevaerts | lebellium: not yet :) |
| 01:15:18 | chrisjj | pamaury, re the mystery Unit N, I reinstalled bootloader and .rockbox, and still get LCD dots then data abort. |
| 01:15:59 | chrisjj | 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 | gevaerts | scorche: did I just kill apache? |
| 01:17:44 | fs-bluebot | Build Server message: New build round started. Revision 79e8cd4, 255 builds, 15 clients. |
| 01:18:08 | gevaerts | Or just the entire server? |
| 01:18:34 | __builtin | well, forums aren't working now :P |
| 01:19:27 | scorche | gevaerts: the latter - give it 3 minutes to reboot |
| 01:22:16 | chrisjj | Correction: L, N and Q. Unit G shows the same as Q (Ugly White Full Screen Flash on backlight sleep.) |
| 01:22:54 | pamaury | chrisjj: see commits for typo |
| 01:25:29 | chrisjj | Not https://www.rockbox.org/since-4weeks.html 'fix typo (nwz-zx100 -> nw-zx100)', I guess :-) |
| 01:25:52 | pamaury | https://git.rockbox.org/?p=rockbox.git;a=commit;h=fd26294 |
| 01:26:10 | chrisjj | Ooo... |
| 01:27:24 | chrisjj | I think that rates as a 'codo' :-) |
| 01:29:05 | chrisjj | Congrats on the catch. |
| 01:29:36 | fs-bluebot | Build Server message: Build round completed after 712 seconds. |
| 01:29:37 | fs-bluebot | Build Server message: Revision 79e8cd4 result: 0 errors 1 warnings |
| 01:32:10 | chrisjj | 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 | pamaury | chrisjj: no, as far as I know, there is no way to detect jack on the ZEN |
| 01:37:05 | chrisjj | 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 | chrisjj | A nightmare because audio jack is on my list of BSoPO factor candidates. Or was. Now removed. |
| 01:38:06 | pamaury | 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 | chrisjj | Yes I'm sure. I've seen it 30 times today. |
| 01:40:35 | chrisjj | UWFSF happens on wake too, but the two are different. Wake is clean-cut and about 100ms. |
| 01:41:25 | chrisjj | 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 | pamaury | 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 | chrisjj | Sounds like exactly the same thing I see on ZEN Unit L. |
| 01:44:22 | chrisjj | 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 |
| 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:00 |
| 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:00 |
| 04:12:29 | jhMikeS | 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:00 |
| 05:23:00 | fs-bluebot | Build Server message: New build round started. Revision 823f726, 255 builds, 15 clients. |
| 05:23:07 | __builtin | fingers crossed here... |
| 05:36:22 | fs-bluebot | Build Server message: Build round completed after 802 seconds. |
| 05:36:23 | fs-bluebot | Build Server message: Revision 823f726 result: 51 errors 0 warnings |
| 05:36:39 | __builtin | shoot |
| 05:37:36 | __builtin | mmh, it's the optimization flags |
| 05:52:16 | fs-bluebot | Build Server message: New build round started. Revision c1b913b, 255 builds, 15 clients. |
| 06:00 |
| 06:03:07 | fs-bluebot | Build Server message: Build round completed after 651 seconds. |
| 06:03:08 | fs-bluebot | Build Server message: Revision c1b913b result: All green |
| 06:25:52 | fs-bluebot | Build Server message: New 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 | fs-bluebot | Build Server message: Build round completed after 698 seconds. |
| 06:37:31 | fs-bluebot | Build Server message: Revision 0a5b0dd result: All green |
| 06:40:37 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 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:00 |
| 08:40:39 | *** | Saving seen data "./dancer.seen" |
| 10:00 |
| 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 | Massa | 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 | Massa | 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 | Massa | I've a few question regarding login and wiki etc. |
| 10:50:14 | Massa | It seems I never registered at the wiki pages - can't remember why; so know I did! |
| 10:51:10 | Massa | Can someone please add me to the WikiUsersGroup? My wiki name is MatthiasM |
| 11:00 |
| 11:07:22 | | Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) |
| 11:21:59 | cc___ | Hi Massa ! what were you working on ? |
| 11:25:45 | Massa | Parts of the picture resizing and integrating of the pictures / albumart in wps |
| 11:26:53 | Massa | and I was involved in the wps redesign at that time - which leads to the viewport design |
| 11:27:40 | Massa | And some patches for games and other stuff to make it better work at the iRiver H340 devices... |
| 11:28:31 | Massa | Currently I'm interested in iPod Video / Classic and SDXC / mSATA support |
| 11:29:58 | Massa | 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 | lebellium | pamaury: do you want real KAS for NW-ZX100? Something else too? |
| 11:46:46 | pamaury | lebellium: yes |
| 11:47:00 | dongs | what's a KAS |
| 11:47:02 | pamaury | 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 | pamaury | Key And Signature |
| 11:47:28 | dongs | o |
| 11:55:21 | lebellium | pamaury: |
| 11:55:29 | lebellium | Model: NW-ZX100 |
| 11:55:30 | lebellium | Series: NW-ZX100 Series |
| 11:55:32 | lebellium | kas (node 11,key and signature): |
| 11:55:33 | lebellium | 63 64 64 61 38 64 35 65 35 33 36 30 66 64 34 33 cdda8d5e5360fd43 |
| 11:55:35 | lebellium | 37 33 31 35 34 33 38 38 37 34 33 66 38 34 64 32 73154388743f84d2 |
| 11:55:36 | lebellium | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
| 11:55:38 | lebellium | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ |
| 11:55:46 | lebellium | don't forget to fix the typo (NWZ/NW) when you pudate upg.c |
| 11:55:50 | lebellium | update* |
| 11:57:14 | | Quit pamaury (Ping timeout: 240 seconds) |
| 11:57:19 | | Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) |
| 11:57:21 | dongs | ragequit |
| 11:58:51 | pamaury_ | lebellium: thanks |
| 11:58:54 | pamaury_ | which typo ? |
| 11:59:00 | | Join johnb3 [0] (~johnb3@p5B296D6F.dip0.t-ipconnect.de) |
| 11:59:06 | pamaury_ | ah in the upg structure rigt |
| 11:59:08 | lebellium | "nwz-zx100", false, "2c0bf029804f73e073154388743f84d2" }, |
| 11:59:25 | pamaury_ | Massa: I added you to the wiki (I think) |
| 11:59:59 | johnb3 | Mihail: see my forum post. Which build should I try next with my clip+ var0: -7, -8 or something else? |
| 12:00 |
| 12:01:06 | pamaury_ | lebellium: you made the typo too :-o |
| 12:01:28 | pamaury_ | oh no you just copied my wrong line |
| 12:01:34 | lebellium | :) |
| 12:02:01 | lebellium | I can't claim I never make the typo NWZ vs NW but I try not to! |
| 12:02:18 | pamaury_ | beware, quoting leads to the chrisjj side of #rockbox |
| 12:02:31 | lebellium | sorry |
| 12:03:16 | fs-bluebot | Build Server message: New build round started. Revision 0cabc1f, 255 builds, 16 clients. |
| 12:05:34 | johnb3 | 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 | pamaury_ | 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 | johnb3 | alright. |
| 12:08:04 | Massa | pamaury_: thanks - yes you did :-) |
| 12:11:44 | pixelma | 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 | pamaury_ | a that's right, the wiki name rule, I always forget about that |
| 12:12:31 | fs-bluebot | Build Server message: Build round completed after 555 seconds. |
| 12:12:32 | fs-bluebot | Build Server message: Revision 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 | pamaury_ | Massa: we have a real name policy, so you must put your real name on the wiki |
| 12:13:48 | pixelma | lebellium: calling it stupid gives incentive to start a debate... |
| 12:13:57 | lebellium | that's true |
| 12:14:02 | | Nick pamaury_ is now known as pamaury (~pamaury@rockbox/developer/pamaury) |
| 12:14:16 | Massa | 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 | pamaury | pixelma: is that enough ? |
| 12:15:10 | pamaury | 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 | johnb3 | chrisjj: for me the screen is no problem but it doesn't really fill the palm of my hand. |
| 12:16:23 | pamaury | chrisjj: can you test a build for me on the ZEN ? |
| 12:16:32 | chrisjj | Yes. |
| 12:16:46 | johnb3 | So i feel I don't have a secure grip ;-) Maybe I will learn ... |
| 12:17:26 | Massa | pamaury: Can I change the WikiName? |
| 12:17:27 | chrisjj | johnb3: You could glue it to the back of the slightly larger ZEN :-) |
| 12:17:47 | pamaury | Massa: I don't know, I think not, the simplest way is to recreate an account :-/ |
| 12:17:58 | pamaury | gevaerts: can one change a wiki name ? |
| 12:18:22 | johnb3 | the only zen I had was a Creative NOMAD Jukebox Zen Xtra and didn't like it too much. sold. |
| 12:18:22 | chrisjj | What astonished me about the E585 was the battery runtime. |
| 12:19:03 | pamaury | chrisjj: https://www.dropbox.com/s/3c53ow3rdkt2bxn/rockbox_zen_blfix.zip?dl=0 |
| 12:19:15 | pamaury | it is an attempt at fixing the white flash on backlight |
| 12:20:12 | Massa | pamaury: O.K. I added another WikiUser "MatthiasMohr" - could you please add me to the group (and remove MatthiasM)? |
| 12:20:23 | pamaury | yes |
| 12:20:48 | chrisjj | backlight |
| 12:21:10 | chrisjj | d/backlight/ |
| 12:22:03 | Massa | Is it possible to sign in to gerrit with a GitHub account? |
| 12:22:07 | Massa | pamaury: thanks! |
| 12:23:05 | pamaury | Massa: in theory there a github oauth integration |
| 12:23:33 | pamaury | but I think last time I tried it ended up in a 404 on github :-/ |
| 12:23:53 | Massa | 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 | Massa | you were faster than me ;-) |
| 12:24:23 | pamaury | oauth is really annoying, it breaks all the time |
| 12:26:24 | pamaury | I will see with bjorn if we can fix gerrit github |
| 12:26:35 | pamaury | but he is usually not very responsive |
| 12:27:37 | Massa | 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 | chrisjj | 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 | Massa | I personally think that combining several accounts is a bad idea (privacy related) |
| 12:30:32 | pamaury | Massa: iirc Launchpad |
| 12:32:53 | chrisjj | ZEN testers' Pro Tip: To revert Settings changes made since last power-on, press reset. |
| 12:32:56 | Massa | pamaury: it's not in the list at OpenId (or I'm unable to see it)!? Do you have a link? |
| 12:33:59 | lebellium | chrisjj: aren't you the only one? |
| 12:35:22 | Massa | Someone here with knowledge about the configure script? Especially with building the simulator? |
| 12:35:31 | chrisjj | ... or plug USB to PC. |
| 12:36:40 | pamaury | Massa: it's on the Sign-In page for gerrit (for me) |
| 12:37:04 | pamaury | Massa: with configure script yes, simulator less |
| 12:37:43 | Massa | I think there are some script bugs related to it, especially with detecting the sdl-config |
| 12:38:13 | pamaury | chrisjj: what about this https://www.dropbox.com/s/ndt0fkfetalw9eh/rockbox_zen_blfix_ugly.zip?dl=0 |
| 12:38:49 | Massa | 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 | pamaury | can you pastebin ? It's a bit vague :) |
| 12:39:32 | Massa | 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 | chrisjj | lebellium: We live in hope :-) |
| 12:39:53 | pamaury | Massa: beware that configure is sh based |
| 12:40:07 | pamaury | (for reasons I don't understand, we might as well move it to bash) |
| 12:40:43 | pamaury | 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 | Massa | http://pastebin.com/KVa8cXRa |
| 12:44:22 | Massa | first of all, you see line 3 there ( line 348 in script)? |
| 12:45:00 | Massa | it directly calls "sdl-config" and not the one which get's searched and found earlier (in variable $sdl) |
| 12:46:05 | Massa | that's the first bug - it should be changed to "$sdl" |
| 12:46:10 | pamaury | indeed |
| 12:47:28 | Massa | 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 | pamaury | well it does that: |
| 12:47:56 | pamaury | files="${CROSS_COMPILE}sdl-config:sdl-config" |
| 12:47:56 | pamaury | no ? |
| 12:48:11 | pamaury | with comment # sdl-config might (not) be prefixed for cross compiles so try both. |
| 12:48:32 | chrisjj | 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 | pamaury | Massa: did you manage to setup a gerrit account or should I push a first fix ? |
| 12:51:39 | chrisjj | I can send video proof if required :-) |
| 12:52:11 | chrisjj | But I'll be posting the devices to you hopefully Monday. |
| 12:52:49 | pamaury | 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 | chrisjj | I think the backlight is not off. I think the white flash is the backlight On and the pixels White. |
| 12:54:44 | chrisjj | And surely you did see it yourself on lcd_fix when you have a real device. Albeit a month back. |
| 12:54:54 | chrisjj | s/have/had/ |
| 12:55:17 | pamaury | 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 | pamaury | I don't have this flash on sleep. |
| 12:55:37 | pamaury | ever |
| 12:56:00 | pamaury | I only have a flash on wake and this solves it for me |
| 12:56:12 | chrisjj | I thought you don't have the flash because you don't have the device :-) |
| 12:56:19 | pamaury | on the X-Fi |
| 12:56:37 | pamaury | It's the same LCD as far as I know |
| 12:57:33 | chrisjj | 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 | chrisjj | Did you look for flash on ZEN classic when you had one? |
| 13:00 |
| 13:01:33 | Massa | 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 | pamaury | Massa: I sent an email to Bjorn to see if he can look into this. |
| 13:02:05 | pamaury | Don't forgot to read UsingGit on the wiki |
| 13:02:21 | pamaury | 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 | Massa | O.K., now back to configure... |
| 13:04:46 | Massa | 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 | Massa | 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 | Massa | which is the wrong one |
| 13:06:40 | pamaury | hum, that's tricky |
| 13:07:19 | Massa | 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 | pamaury | yeah but how does it know the cross environment location ? |
| 13:07:54 | pamaury | I can only think of $(CROSS_PREFIX)gcc −−print-sysroot |
| 13:08:20 | pamaury | or you need to tell the script |
| 13:08:50 | pamaury | me thinks |
| 13:08:50 | pamaury | `$(CROSS_PREFIX)gcc −−print-sysroot`/bin |
| 13:08:50 | pamaury | is a valid search location |
| 13:09:40 | Massa | that's a nice idea - didn't think of that :-o |
| 13:09:44 | pamaury | 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 | pamaury | maybe adding |
| 13:10:02 | pamaury | `$(CROSS_PREFIX)gcc −−print-sysroot`/mingw/bin |
| 13:10:02 | pamaury | doesn't hurt |
| 13:10:46 | Massa | 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 | Massa | only the mingw subdirectory is somehow "incorrect" |
| 13:12:30 | pamaury | Massa: currently how to specify your cross compiler ? |
| 13:13:13 | pamaury | you pass CROSS_COMPILE=blabla ./configure blabla ? |
| 13:14:03 | Massa | this is my currently used complete configre script: http://pastebin.com/uZA5VwDt |
| 13:15:04 | pamaury | a diff would be helpful ;) |
| 13:15:51 | pamaury | or upload to gerrit for review |
| 13:20:58 | Massa | this is the diff: http://pastebin.com/UGYpBgcP |
| 13:21:57 | Massa | 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 | Massa | - it also contains a lot "echo" - to find the reason for my problems ;-) |
| 13:24:39 | pamaury | 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 | pamaury | ah ok some are commented |
| 13:25:47 | pamaury | there is a lot commented code |
| 13:28:08 | Massa | there is a lot "test code" ;-) |
| 13:28:55 | Massa | the problem is, that the generated GCCOPTS make the test compile to detect the architecture fails with "unknown command line option" |
| 13:29:40 | Massa | 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 | Massa | here's the output of the 64-bit mingw compiler, called by the script: |
| 13:30:23 | Massa | x86_64-w64-mingw32-cpp: error: unrecognized command line option ‘-W -Wall -Wundef -O -nostdlib -ffreestanding -Wstrict-prototypes -pipe -std=gnu99’ |
| 13:30:55 | pamaury | can you remind where the test is done in configure ? |
| 13:32:08 | Massa | in line 375 in original configure, line 487 in mine |
| 13:33:10 | Massa | that was bullshit - have to search it.. |
| 13:34:06 | Massa | line 4277 in original script, 4398 in mine |
| 13:34:54 | | Quit johnb3 (Ping timeout: 240 seconds) |
| 13:35:06 | pamaury | so you are saying that |
| 13:35:06 | pamaury | cpp_defines=$(echo "" | $CPP $GCCOPTS -dD) |
| 13:35:06 | pamaury | fails ? |
| 13:35:19 | Massa | yes |
| 13:37:51 | pamaury | weird, on my (linux) machine, this works: |
| 13:37:51 | pamaury | CROSS_COMPILE=i686-w64-mingw32- ../tools/configure |
| 13:37:51 | pamaury | (I haven't tried to actually compiled the sim) |
| 13:40:15 | pamaury | what is your environment ? linux ? cygwin ? |
| 13:46:27 | Massa | cygwin |
| 13:47:46 | Massa | 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 | pamaury | can you replace /bin/sh by /bin§bash no line 1 ? |
| 13:49:33 | Massa | 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 | pamaury | 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 | Massa | 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 | pamaury | and what is the content of GCCOPTS normally ? |
| 13:52:17 | Massa | I thought it could be some kind of invisible special characters which gets removed when pasting... |
| 13:52:44 | pamaury | I suspect it's more of an expansion problem |
| 13:52:47 | Massa | what do you mean by "normally"? |
| 13:53:07 | pamaury | if you don't change it and let the script run without modification |
| 13:53:19 | pamaury | I suspect it treats $CC $GCCOPTS |
| 13:53:25 | pamaury | as having one argument only |
| 13:53:58 | | Quit TorC (Read error: Connection reset by peer) |
| 13:54:59 | Massa | 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 | Massa | 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 | pamaury | spaces you be irrelevant |
| 13:58:18 | pamaury | and what is the error message again ? |
| 13:58:24 | Massa | that's the reason why I think there could be some strange special characters which are not visible... |
| 13:58:50 | Massa | 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 | pamaury | what's weird in this message |
| 13:59:12 | pamaury | is that it *seems* it is trated the entire line as one argument |
| 13:59:50 | Massa | yes, you're right - how could that be? |
| 13:59:51 | pamaury | because cpp print an error *per switch* when it does recognize it, not the entire line |
| 14:00 |
| 14:00:29 | pamaury | this is going to sound crazy but |
| 14:00:38 | pamaury | what happens if you replace the line by |
| 14:00:38 | pamaury | cpp_defines=`echo "" | $CPP $GCCOPTS -dD` |
| 14:02:46 | Massa | you mean backticks instead of "$()"? No change! |
| 14:04:56 | Massa | BTW, when I hardcoded paste the GCCOPTS line in my version of the script the error remains :-( |
| 14:06:05 | pamaury | hum, ok give me an hour, I'll install cygwin in a VM |
| 14:06:28 | Massa | btw, how do you setup a cross compiling environment in you linux? I could not manage to compile the SDL library... |
| 14:06:40 | Massa | I use cygwin64 if that matters... |
| 14:07:14 | Massa | (with both: mingw64 and mingw32 - so I could in principal compile it for both "worlds") |
| 14:09:25 | pamaury | 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 | pamaury | Massa: downloading, it may take a small while, I'll ping you when I have a working setup |
| 14:15:00 | Massa | 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 | chrisjj | 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 | pamaury | I maintain there is no evidence for that though |
| 14:30:06 | pamaury | 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 | chrisjj | OK, then I'll scratch that as a candidate cause for the LCD differences across units. |
| 14:52:26 | pamaury | 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 | pamaury | I have found a difference between ZEN and ZEN X-Fi code, it's bit puzzling |
| 14:54:23 | chrisjj | Do we have any better candidate explanation for the three different LCD performances I see? |
| 14:56:15 | chrisjj | I mean: better than different LCDs. |
| 14:57:44 | pamaury | I don't have an explanation yet, except that the code must be doing something wrong and leads to unpredictable behavior |
| 15:00 |
| 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 | chrisjj | Wrong code can given different results only if the hardware is different. |
| 15:02:35 | chrisjj | So it sounds to me like different LCDs is the best explanation we have. |
| 15:03:44 | chrisjj | 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 | chrisjj | We know only that the Creative code disassembly shows no detection of different LCDs. |
| 15:04:58 | chrisjj | It may be that the same Creative code drives different LCDs fine. |
| 15:06:05 | chrisjj | Without detecting the LCD type. |
| 15:06:25 | pamaury | 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 | pamaury | 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 | pamaury | 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 | Massa | __builtin: are you here? |
| 15:15:12 | | Quit dfkt (Ping timeout: 245 seconds) |
| 15:17:02 | pamaury | Massa: cygwin installed, I need to get rockbox and see if I miss libs |
| 15:23:01 | pamaury | 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 | pamaury | I'll send you a build to try |
| 15:24:23 | pamaury | (I think OF uses standby) |
| 15:24:50 | pamaury | (or might not power down at all) |
| 15:28:25 | gevaerts | pamaury: I have no idea! |
| 15:28:39 | pamaury | gevaerts: about what ? |
| 15:28:42 | * | pamaury forgot |
| 15:28:49 | gevaerts | The wiki |
| 15:29:03 | pamaury | ok, I thought we ran into this issue previously |
| 15:29:08 | gevaerts | Well, maybe |
| 15:29:23 | gevaerts | But I don't know anything more about the wiki than how to add people |
| 15:30:49 | lebellium | 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 | gevaerts | lebellium: the server went away every time I tried to re-run checkwps, so I went to sleep |
| 15:33:51 | lebellium | ok |
| 15:34:24 | gevaerts | Also, technically yesterday the Zen X-Fi and Zen X-Fi Style weren't on the theme site at all! |
| 15:34:46 | lebellium | I mean once they were |
| 15:35:01 | gevaerts | 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 | lebellium | lol |
| 15:35:10 | lebellium | 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 | chrisjj | 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 | chrisjj | 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 | Massa | 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 | pamaury | 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 | pamaury | Massa: I finally rockbox and cygwin so let me try a sim build |
| 15:47:28 | chrisjj | And of course your suggestion of standing-by the LCD fits with that. |
| 15:48:09 | chrisjj | ... provided the difference we see is after the current power down. |
| 15:48:40 | chrisjj | pamaury: I accept there are literally no two different LCD that have the same init sequence known to you. |
| 15:48:41 | pamaury | Massa: I'm not familar with cygwin. What is the different between i686-w64-mingw32 and i686-pc-mingw32 ? |
| 15:48:53 | Massa | (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 | chrisjj | But while there's no better explanation known to you, I think this has to stand as the best explanation. |
| 15:49:46 | pamaury | Massa: ok so if I run: |
| 15:49:46 | pamaury | CROSS_COMPILE=i686-w64-mingw32- ../tools/configure |
| 15:49:46 | pamaury | I get |
| 15:49:46 | DBUG | Enqueued KICK pamaury |
| 15:49:46 | pamaury | .... |
| 15:49:46 | pamaury | Cygwin host detected |
| 15:49:47 | *** | Alert Mode level 1 |
| 15:49:47 | pamaury | configure didn't find sdl-config, which indicates that you |
| 15:49:51 | Massa | pamaury: Huh? I've i686-w64-mingw32 and x86_64-w64-mingw32 |
| 15:50:12 | Massa | the latter is the 64-bit version... |
| 15:50:16 | | Quit StaticAmbience (Remote host closed the connection) |
| 15:50:17 | pamaury | I didn't install the 64-bit compiler, but I have an extra "pc" one |
| 15:51:13 | chrisjj | BTW, one of the display differences could be due to non-LCD hardware differences. This is the dots. |
| 15:51:13 | pamaury | i686-pc-cygwin-gcc |
| 15:51:14 | pamaury | 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 | pamaury | Massa: can you pastebin your diff to fix sdl-config ? |
| 15:53:50 | | Quit robertd1 (Ping timeout: 240 seconds) |
| 15:57:02 | Massa | pamaury: http://pastebin.com/TK2Tdaa0 |
| 15:57:45 | Massa | pamaury: did you install the 32- or the 64- version of cygwin? |
| 15:58:50 | pamaury | I installed cygwin64 but I must have chosen the 32-bit compiler in the (very long) list |
| 15:58:55 | pamaury | I don't think it matters anyway |
| 15:59:48 | *** | Alert Mode OFF |
| 16:00 |
| 16:00:13 | pamaury | Massa: how do I tell cygwin to install more package ? Do I have to re-run the installer ? |
| 16:00:45 | Massa | Yes, re-run the installer anytime you want to install more packages or to update existing ones... |
| 16:01:14 | Massa | the 64-bit compilation stops now with an error: |
| 16:01:19 | Massa | 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 | Massa | 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 | Massa | 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 | pamaury | 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 | pamaury | 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 | Massa | 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 | pamaury | yeah, but better use the w64-mingw32 I think |
| 16:09:04 | pamaury | anyway, in your diff |
| 16:09:15 | pamaury | I don't like the 64-bit option |
| 16:09:20 | Massa | 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 | pamaury | the script should detect 64-bit and use override it if necessary |
| 16:10:27 | Massa | 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 | pamaury | arg, /me hates windows |
| 16:10:46 | | Join StaticAmbience [0] (~Quassel@host86-170-83-76.range86-170.btcentralplus.com) |
| 16:11:55 | Massa | you can do the same in 64-bit Linux! |
| 16:12:20 | Massa | Huh? What does this mean: |
| 16:12:30 | Massa | 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 | Massa | 1091979 [main] make 4384 fork: child -1 - forked process 5144 died unexpectedly, retry 0, exit code 0xC0000142, errno 11 |
| 16:13:01 | pamaury | 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 | pamaury | admitedly cygwin doesn't make it easy because there is no easily detectable compiler |
| 16:14:15 | Massa | 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 | Massa | Maybe that's possible - but we don't know it ;-) |
| 16:15:35 | pamaury | you can build a multilib gcc yes |
| 16:15:37 | pamaury | like on linux |
| 16:17:17 | Massa | 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 | pamaury | nope :( |
| 16:18:07 | pamaury | Massa: reading your sysroot handling, I suspect it's going to fail on linux |
| 16:18:25 | pamaury | or other targets |
| 16:18:40 | pamaury | because I am not 100% that a sysroot is mandatory |
| 16:19:04 | pamaury | hum scratch that, it just prints a warning |
| 16:20:24 | Massa | No, you're right - I should surround it by a if [ "$winbuild" = "yes" ]... |
| 16:21:58 | Massa | Or maybe it's not bad to keep it as is - and to only surround the warn messages with that "if"... |
| 16:22:42 | pamaury | damn, cygwin is slooooooooow |
| 16:22:54 | pamaury | and doing things, I don't know what |
| 16:23:14 | Massa | what do you mean? |
| 16:24:39 | pamaury | I don't know, the whole is just super slow |
| 16:25:35 | Massa | 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 | pamaury_ | 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 | pamaury_ | 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 | pamaury_ | 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 | pamaury_ | ah damn, make fails because it tries to call gcc |
| 16:40:32 | chrisjj | 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 | pamaury_ | Massa: did you run this issue as well ? |
| 16:41:57 | | Join Petri152 [0] (~Petri@petritrebs.ca) |
| 16:43:17 | Massa | No, I didn't have this issue |
| 16:43:54 | chrisjj | 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 | Massa | about touching the unrelated lines - that's because I configured the editor to remove trailing spaces when saving... |
| 16:45:39 | Massa | 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 | Massa | 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 | pamaury_ | 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 | pamaury_ | 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 | Massa | 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 | Massa | 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:00 |
| 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 | pamaury_ | massa_: so what was the problem ? |
| 17:48:24 | pamaury_ | massa_: in your cygwin env, do you have a default compiler, ie if you type "gcc -v", does it print something ? |
| 17:48:57 | massa_ | 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 | massa_ | pamaury_: yes, e.g. it prints "Target: x86_64-pc-cygwin" |
| 17:49:39 | pamaury_ | 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 | pamaury_ | massa_: ah, I don't have such a compiler, that's why it fails for me |
| 17:50:40 | massa_ | pamaury_: oh, do you think it should be possible to build without a "native" gcc? |
| 17:51:23 | pamaury_ | 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 | massa_ | 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 | massa_ | But not now - I'm away, at least for a few hours... |
| 17:53:57 | pamaury_ | did you make changes to other files ? |
| 17:54:41 | massa_ | 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 | massa_ | 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 | pamaury_ | yes sysroot should be conditional to cross compile |
| 17:56:47 | | Quit Bilgus (Quit: Leaving) |
| 17:57:32 | massa_ | 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 | massa_ | 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 |
| 18:00:13 | massa_ | 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 | massa_ | 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 | pamaury_ | chrisjj: https://www.dropbox.com/s/zmj6pq33hr54bwr/rockbox_zen_nolcdsleep.zip?dl=0 |
| 18:37:02 | pamaury_ | 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 | pamaury | 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:00 |
| 19:24:03 | chrisjj | me returns. |
| 19:24:38 | chrisjj | pamaury: shall I test both, or one? |
| 19:25:02 | pamaury | chrisjj: both please |
| 19:25:36 | pamaury | 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 | pamaury | dotclkpolfix is the one that tries to fix the coloured lcd dots |
| 19:26:55 | chrisjj | OK. |
| 19:28:19 | pamaury | 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 | chrisjj | 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 | pamaury | chrisjj: dotclkpolfix doesn't fix flash |
| 19:38:05 | pamaury | it's only supposed to fix the unit where you get funny dots (could you upload a picture of that btw ?) |
| 19:41:45 | chrisjj | 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 | chrisjj | 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 | chrisjj | 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 | chrisjj | On Unit N, rockbox_zen_nolcdsleep 0cabc1fc5M-170114 shows no change. |
| 19:51:50 | chrisjj | 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 | pamaury | 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 | chrisjj | By Screendump, unlikely, since this function broke a while back. |
| 19:58:12 | pamaury | you can't a screendump of a data abort, I mean picture, litteraly |
| 20:00 |
| 20:02:24 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:8c6b:961d:b210:157a) |
| 20:04:51 | chrisjj | OK, fetching camera... |
| 20:06:28 | pamaury | I still don't understand the data abort, and why specifically on this device, why is it special ? |
| 20:06:53 | chrisjj | Webcam blinded http://i.imgur.com/UkyMcAz.png |
| 20:07:18 | pamaury | ah |
| 20:07:25 | pamaury | can you pastebin the whole text ? |
| 20:07:38 | pamaury | or at least all the pc address and stack trace if any ? |
| 20:10:59 | chrisjj | Phone blinded too. |
| 20:10:59 | chrisjj | config.cgf brightness is ignored by the Data Abort screen |
| 20:11:16 | chrisjj | Transcribing to pastebin... |
| 20:11:34 | pamaury | data abort cannot access config.cfg... |
| 20:29:53 | chrisjj | http://pastebin.com/dkudq48N |
| 20:30:23 | | Join johnb2 [0] (~johnb2@p5B296D6F.dip0.t-ipconnect.de) |
| 20:31:08 | chrisjj | 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 | pamaury | 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 | pamaury | chrisjj: does the data abort happen in the bootloader or in .rockbox ? |
| 20:32:30 | chrisjj | Yup, makes sense. I was just hoping otherwise. Though I'd say 30% would do fine too :-) |
| 20:32:55 | chrisjj | Re the Data Abrt, as teh pastebin says, it follows the RB logo. |
| 20:33:21 | pamaury | ah yeah the BL doesn't display a logo |
| 20:33:51 | pamaury | 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 | chrisjj | To the pastebin I added a description of all screen updates prior to the Abort. |
| 20:39:33 | chrisjj | No, I am using factory defaults. |
| 20:40:03 | chrisjj | I.e. I am using your .ZIPs .rockbox with no added config.cfg. |
| 20:40:57 | chrisjj | 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 | pamaury | the data aborts occurs in the skin engine |
| 20:42:37 | pamaury | do you remove .rockbox entirely between tests ? |
| 20:42:58 | chrisjj | I rename it. |
| 20:43:25 | chrisjj | 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 | chrisjj | There's no BSoPO as one would expect from a freeze and angry watchdog. |
| 20:45:22 | chrisjj | 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 | chrisjj | 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 | pamaury | anyway |
| 20:52:16 | pamaury | you can try to benchmark the nolcdsleep if you want |
| 20:52:22 | pamaury | see if that makes a big difference battery wise |
| 20:56:08 | chrisjj | 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 | chrisjj | 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 | chrisjj | Dots are present. Menus are operable. WPS causes DA. |
| 20:59:12 | chrisjj | I have it running now. Any diagnostics I should extract? |
| 21:00 |
| 21:01:08 | pamaury | I can't think of anything |
| 21:01:17 | pamaury | there must be something wrong but I have no idea what |
| 21:01:38 | chrisjj | Oops, entering Text Editor gave DA. Undefined instruction at 61EC4500. |
| 21:04:52 | chrisjj | 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 | chrisjj | 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 | pamaury | 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 | chrisjj | Sounds probable to me. |
| 21:11:47 | chrisjj | Shame I can't show you an image. I think you'd find the dot pattern very illuminating. |
| 21:12:50 | chrisjj | 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 | chrisjj | 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 | chrisjj | 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 | chrisjj | 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 | chrisjj | 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 | chrisjj | 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 | chrisjj | 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 | chrisjj | Vertically adjacent dots are eight pixels apart. Each dot is on the pixel row /below/ the dot immediately to its left. |
| 21:32:51 | chrisjj | 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 | fs-bluebot | Gerrit review #336 at http://gerrit.rockbox.org/r/336 : SH 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 | fs-bluebot | Gerrit review #123 at http://gerrit.rockbox.org/r/123 : Add an alternative analogic touchpad sensitivity setting by Jean-Louis Biasini |
| 21:33:38 | __builtin | g 123 |
| 21:33:40 | fs-bluebot | Gerrit review #123 at http://gerrit.rockbox.org/r/123 : Add an alternative analogic touchpad sensitivity setting by Jean-Louis Biasini |
| 21:34:03 | chrisjj | Perhaps some of those numbers ring bells from the DMA process. |
| 21:42:08 | pamaury | 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:00 |
| 22:09:22 | chrisjj | Pushing pixels to the LCDIF is the only operation that can cause such a messup, surely? |
| 22:10:10 | pamaury | chrisjj: not so sure, if I had to choose, I would blame the lcdif rather than the DMA but who knows |
| 22:10:10 | chrisjj | Does one frame's push occur in a single DMA operation, do you know? Or in smaller blocks. |
| 22:10:20 | pamaury | chrisjj: are you planning to ship me this unit ? |
| 22:11:07 | chrisjj | 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 | pamaury | no each frame uses, iirc, 4 linked DMA transfers |
| 22:11:55 | chrisjj | 4? Why 4? |
| 22:12:14 | massa | pamaury: I'm back again :-) |
| 22:12:44 | chrisjj | To fit inside a 64K byte limit, perhaps? |
| 22:13:51 | __builtin | hello massa |
| 22:13:53 | pamaury | 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 | massa | pamaury: I did some more changes in my script - and suddenly the error occured again... |
| 22:14:47 | pamaury | massa: which changes ? I managed to build the simulator fine, after the vscanf problem |
| 22:15:11 | massa | __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 | massa | 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 | massa | pamaury: and I found out, what the problem is - you were right, the CC call treats the GCCOPTS as _one_ parameter! |
| 22:17:53 | massa | pamaury: and I know why this happens :-) |
| 22:18:18 | pamaury | massa: haha! I suspected that but I don't know why ? |
| 22:18:26 | pamaury | because it works here |
| 22:18:44 | massa | __builtin: I found a problem in apps/plugins/puzzles/rbwrappers.c |
| 22:18:53 | __builtin | anything else? |
| 22:19:56 | massa | __builtin: no, I did currently not see your post :-) |
| 22:20:27 | massa | pamaury: the reason is somehow setting IFS=":" |
| 22:22:26 | massa | 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 | pamaury | hum, interesting |
| 22:23:12 | pamaury | I wonder if IFS influences argument splitting in commands |
| 22:23:43 | massa | seems so - when I set back IFS to the initial value, everything is fine! |
| 22:24:18 | pamaury | massa: http://tldp.org/LDP/abs/html/internalvariables.html |
| 22:24:26 | pamaury | it definitely influences echo |
| 22:24:45 | pamaury | massa: I have a theory, switch to bash instead of sh |
| 22:26:48 | massa | does not change a thing |
| 22:27:17 | massa | maybe IFS gets automatically restored after leaving a function? |
| 22:27:20 | pamaury | somehow I would expect the IFS change to be local, but that may depend on how you write it |
| 22:27:39 | massa | (and my newer changes are not inside a function) |
| 22:29:30 | pamaury | massa: then the simple solution is to unset IFS |
| 22:29:37 | pamaury | IFS=":" |
| 22:29:38 | pamaury | blablabla |
| 22:29:38 | pamaury | unset IFS |
| 22:30:04 | massa | the simplest solution in my case is not to set IFS and use space separated name lists :-) |
| 22:32:17 | pamaury | 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 | massa | 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 | lebellium | gevaerts: I assume we have to give up :) |
| 22:37:43 | massa | 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 | massa | 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 | massa | 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 | massa | pamaury: here's the configure diff of my latest version: http://pastebin.com/2hZVjeTs |
| 22:51:56 | massa | pamaury: this should also work in pure cross hosting environments... |
| 22:53:20 | massa | [Saint]: well, I assume possible spaces and other strange characters are the reason why the PATH separator is a ":" :-) |
| 22:54:33 | massa | So you always have to expect the worst when handling with filenames and directory names... |
| 22:56:27 | massa | __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 | massa | __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 |
| 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 | pamaury | 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 | pamaury | 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 | massa | pamaury: shit, then my two-liner to fix it for those environments cannot be tested :-) |
| 23:07:42 | massa | [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 | massa | [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 | massa | [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 | massa | [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 | pamaury | I usually don't compile on windows, I cross compile from linux but hey |
| 23:12:48 | massa | pamaury: and you also compile the simulators for windows in your linux cross environment? |
| 23:13:14 | pamaury | I don't compile simulators for windows but I don't see why it can't be done |
| 23:13:32 | pamaury | you need to cross compile sdl and then cross compile the sim |
| 23:13:51 | pamaury | 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 | massa | 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 | massa | 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 | massa | 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 | massa | And what's difficult with rbutil? |
| 23:21:07 | pamaury | massa: I think we just use the basic SDL library |
| 23:21:21 | pamaury | massa: for rbutil you need all of Qt |
| 23:22:15 | massa | That's easy - I often compiled Qt in a lot of environments :-) |
| 23:24:04 | pamaury | Well apparently bluebrother runs into problem with accessibility stuff |
| 23:24:17 | massa | But I never tried to compile rbutil - never saw a reason to do that... |
| 23:25:58 | massa | 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 | massa | [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 | massa | [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 | massa | [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 | pamaury | massa: warning of formats are really annoying |
| 23:32:07 | massa | [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 | pamaury | 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 | massa | pamaury: what is that z prefix in the format (e.g. %zu)? |
| 23:35:40 | pamaury | size_t |
| 23:35:57 | massa | aah, I see it's actually a C99 addition for size_t |
| 23:38:23 | massa | so why are the global CCOPTS (which contain -std=gnu99) not used in my case? |
| 23:39:30 | massa | I mean it's used, but does not show a effect? |
| 23:41:29 | pamaury | massa: iirc, windows's printf doesn't know about %zu |
| 23:42:08 | pamaury | I'm not 100% sure |
| 23:42:32 | pamaury | honestly that's really really low priority |
| 23:48:46 | massa | pamaury: normally it should link against a mingw gcc libc version which should support it or not? |
| 23:52:35 | massa | maybe we should just add "-Wno-format" to get rid of those warnings? |
| 23:55:03 | pamaury | maybe |
| 23:56:59 | massa | at least in the windows cross compiles... |
| 23:57:15 | massa | (and that we see other, more important warnings...) |
icon identifies that the person is a core developer (has commit access).