| 00:04:09 | pamaury | ah... I feel like an idiot |
| 00:04:14 | pamaury | I had the hold switch |
| 00:04:25 | lebellium | ok working! |
| 00:04:51 | lebellium | never seen the 240x320 cabbie v2 on such a small screen :D |
| 00:06:07 | pamaury | lebellium: there is a small bug in the bootloader with respect to HOLD handling |
| 00:06:17 | pamaury | for now make sure you boot with HOLD on off |
| 00:06:23 | pamaury | otherwise keys won't work |
| 00:06:28 | pamaury | I'll fix in my next gerrit update |
| 00:08:28 | pamaury | lebellium: can you confirm sound is not working ? |
| 00:09:45 | lebellium | I confirm the sound is not working |
| 00:09:52 | lebellium | but playback doesn't crash |
| 00:10:43 | lebellium | it's funny because album art does show up properly with cabbiev2 but not with my theme |
| 00:10:44 | pamaury | yes, it's "just" a problem with audio output apparently |
| 00:11:24 | lebellium | oh and it believes the battery is empty |
| 00:11:32 | pamaury | lebellium: I think you guessed it, to access your files you need to go to the "contents" folder |
| 00:11:46 | lebellium | I guessed it :) |
| 00:11:47 | pamaury | I need to figure out how to make it start there by default |
| 00:12:04 | lebellium | on YP-R0 it's in mnt |
| 00:12:04 | pamaury | ah ? It is supposed to read battery correctly |
| 00:13:24 | lebellium | the battery indicator just moves |
| 00:13:30 | lebellium | not stable |
| 00:14:38 | pamaury | lebellium: go to System > Debug > View battery |
| 00:14:54 | pamaury | what does it show ? |
| 00:15:07 | lebellium | 4.166V |
| 00:16:04 | pamaury | and rockbox displays an empty battery bar ? |
| 00:16:38 | lebellium | 4.153V now |
| 00:18:43 | lebellium | no it's 97% |
| 00:19:18 | pamaury | I'm confused, you said it was thinking it's empty |
| 00:19:35 | lebellium | yes, low battery message and shutting down |
| 00:20:01 | lebellium | now it seems to be stable at 97% but it wasn't |
| 00:21:46 | pamaury | well I don't know, I'm reading the battery using Sony's power module |
| 00:22:25 | lebellium | it just moves from 97 to 99 and back to 97% |
| 00:22:29 | lebellium | we'll see that later |
| 00:24:15 | | Part robertd1 |
| 00:26:34 | pamaury | well there are several options to read the battery |
| 00:26:55 | pamaury | the power modules does magic and converts it to a 5 level value (low, 1, 2, 3, 4, full) |
| 00:27:12 | pamaury | but I found it a bit imprecise so I used the actual voltage |
| 00:27:50 | lebellium | congrats to pamaury |
| 00:27:52 | lebellium | https://drive.google.com/file/d/0B7z2DypmySvnSDdLT0JlQzdhWWM/view?usp=sharing |
| 00:27:54 | lebellium | https://drive.google.com/file/d/0B7z2DypmySvnNDBoSks1ZG91MTA/view?usp=sharing |
| 00:27:55 | lebellium | https://drive.google.com/file/d/0B7z2DypmySvnN3AteUhNVHdmbXc/view?usp=sharing |
| 00:27:57 | lebellium | https://drive.google.com/file/d/0B7z2DypmySvnWXN1N3pjdHFXLWM/view?usp=sharing |
| 00:27:59 | lebellium | https://drive.google.com/file/d/0B7z2DypmySvnSWlPbHB1YWExY2c/view?usp=sharing |
| 00:29:09 | pamaury | the sony logo is a bit ugly on the E580 |
| 00:29:41 | pamaury | the bootloader extract a 130x130 icon which is ok on the E450 and E460 but on the E580 they added a gradient that makes the cut very visible |
| 00:29:50 | pamaury | but that's a minor detail |
| 00:30:32 | lebellium | on E450 you don't see the blue/black difference?! |
| 00:30:45 | pamaury | the bootloader also misses important features, like warning when the HOLD switch is on (instead of doing nothing), also it misses a timeout (it will happily drain the battery waiting for the user currently) for a default action/shutdown |
| 00:30:56 | pamaury | lebellium: no, the logo is a bit different |
| 00:31:39 | lebellium | ok |
| 00:31:47 | lebellium | I guess we deserve to sleep now! |
| 00:32:28 | pamaury | yes :) |
| 00:32:41 | pamaury | tomorrow I'll add the A15 |
| 00:33:52 | lebellium | thanks for the efforts |
| 00:33:54 | lebellium | good night |
| 00:38:28 | chrisjj | pamaury: be68b6a7b crashed likewise, after 2-3hrs. |
| 00:38:36 | *** | Saving seen data "./dancer.seen" |
| 00:39:22 | pamaury | it justs powers off ? are you use you have a long playlist and you have repeat ? |
| 00:39:44 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) |
| 00:40:07 | chrisjj | Yes I am sure. |
| 00:40:29 | chrisjj | Playlist has 500 3min tracks and Repeat = All. |
| 00:40:46 | chrisjj | Now I can't say /just/ powers off. |
| 00:40:56 | pamaury | that's weird. The last commit related to imx233 (so zen indirect) dates from september |
| 00:41:10 | pamaury | have you tried a dev build from more recently ? |
| 00:41:30 | chrisjj | I can say screen goes black, sound goes silent, keys go non-responsive... and power button press does a power-on operation suggesting power went off. |
| 00:42:09 | pamaury | potentially sounds like a panic to me |
| 00:42:12 | chrisjj | No I haven't because TMK the official dev builds do not include lcd_fix. |
| 00:42:56 | chrisjj | ZEN panics I've seen don't go black screen. |
| 00:43:31 | chrisjj | Even if there's a backlight timeout, they show black screen on white background that stays indefinitely. |
| 00:43:57 | chrisjj | However, I may never have encountered a panic occurring when backlight is off. |
| 00:44:05 | pamaury | that depends, a panic in some places may not be able to make the screen work |
| 00:44:14 | chrisjj | How can I determine whether the black screen is hiding a panic display? |
| 00:44:35 | pamaury | you can't |
| 00:45:03 | pamaury | I think bisecting is the only option |
| 00:45:31 | chrisjj | bisecting... what? |
| 00:47:25 | __builtin | binary search through commits to isolate the introduction of a regression |
| 00:48:27 | pamaury | chrisjj: can I send you another build to try and narrow down the problem ? |
| 00:48:31 | chrisjj | Yup. |
| 00:49:21 | chrisjj | __builtin: note: "official dev builds do not include lcd_fix" without which RB is unstable on ZEN, so I have very few commits to bisect :-) |
| 00:51:11 | pamaury | the lcd fix only affects the bootloader |
| 00:51:16 | pamaury | at least that should be the case |
| 00:52:09 | pamaury | chrisjj: https://www.dropbox.com/s/bvid5emyl0wd206/rockbox_zen_7e0820fe2.zip?dl=0 |
| 00:54:22 | chrisjj | Got it... |
| 00:55:21 | chrisjj | Running. |
| 00:55:35 | | Quit xorly (Ping timeout: 240 seconds) |
| 00:55:36 | chrisjj | And I see a change in the start-up flashes. |
| 00:55:38 | | Join lebellium_z3c [0] (~AndChat73@89-93-179-5.hfc.dyn.abo.bbox.fr) |
| 00:56:02 | lebellium_z3c | pamaury: I have sound!! |
| 00:56:54 | chrisjj | 7e0820fe2 crashes on the first backlight sleep. |
| 00:56:54 | lebellium_z3c | But totally crappy |
| 00:57:43 | lebellium_z3c | Like the max output at any volume |
| 00:59:28 | chrisjj | 7e0820fe2 - runs #1 and #2 crashed on the first backlight sleep. Runs #3 and #4 has survived backlight sleep. |
| 00:59:44 | | Quit lebellium_z3c (Client Quit) |
| 01:00 |
| 01:00:50 | | Quit shamus (Read error: Connection reset by peer) |
| 01:04:36 | pamaury | I thought the back sleep problems were long gone |
| 01:06:43 | chrisjj | Certainly on 45697a0bf-161212 (lcd_fix) I had no backlight sleep crashes. |
| 01:06:50 | pamaury | hum |
| 01:07:01 | pamaury | ok, let's stop there and resume tomorrow, I'm tired |
| 01:07:35 | chrisjj | They subsequently started only on be68b6a7bM-170108. |
| 01:07:41 | chrisjj | OK. |
| 01:07:45 | pamaury | I see two options: 1) I introduced a bug since 45697a0bf 2) somehow the lcd_fix also "fixes" the backlight sleep problem but I have no idea how it's possible |
| 01:08:09 | pamaury | because the lcd_fix is a one-time thing on boot |
| 01:08:14 | chrisjj | One think before you go if you don't mind. Am I correct in saying the master has no lcd_fix version? |
| 01:08:27 | pamaury | yes |
| 01:09:06 | chrisjj | OK. "I introduced a bug since 45697a0bf " could be one of those changes that makes no difference to ZEN :-) but I think it unlikely. |
| 01:09:15 | pamaury | I really should push it, I just haven't tried it on the other imx target to make sure it introduces no regression. Because the way I understand it, the lcd_fix is only supposed to fix something in the bootloader |
| 01:09:36 | chrisjj | But lcd_fix included .rockbox update |
| 01:10:09 | pamaury | yeah but it should make no difference, or at best it should only prevent a possible (but very very unlikely) white screen of death on boot |
| 01:10:41 | pamaury | I think we have to test 45697a0bf without lcd_fix to be sure |
| 01:10:50 | pamaury | (ie just 45697a0bf) |
| 01:11:22 | chrisjj | ?? |
| 01:11:47 | chrisjj | The lcd_fix you gave me says "Version: 45697a0bf-161212" |
| 01:12:04 | pamaury | sorry, the commit right before it |
| 01:12:16 | pamaury | cd8b33327c9 |
| 01:12:18 | pamaury | I'm tired |
| 01:12:25 | pamaury | good night |
| 01:13:09 | chrisjj | "cd8b33327c9" Ah, got you. I'll see if have/can get that. Night-night. |
| 01:16:50 | | Quit pamaury (Ping timeout: 240 seconds) |
| 01:18:15 | chrisjj | __builtin: Can you help me find this past ZEN cd8b33327c9 build on rockbox.org? |
| 01:22:26 | __builtin | No, I'm busy. |
| 01:30:35 | | Quit Senji_ (Ping timeout: 240 seconds) |
| 01:31:04 | chrisjj | OK. Anyone else? |
| 01:37:08 | | Quit WakiMiko (Max SendQ exceeded) |
| 01:37:41 | | Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) |
| 01:37:44 | | Join b-t` [0] (~user@s5596c859.adsl.online.nl) |
| 01:38:02 | | Quit Bilgus (Remote host closed the connection) |
| 01:38:04 | | Quit b-t (Write error: Broken pipe) |
| 01:59:04 | | Quit elensil (Ping timeout: 256 seconds) |
| 02:00 |
| 02:13:23 | | Join elensil [0] (~edhelas@2001:1c02:1903:d800:49e3:50f1:371b:c023) |
| 02:14:45 | | Quit skapazzo (Quit: leaving) |
| 02:23:44 | chrisjj | Is WPS supposed to show the charge level when charging? Here (ZEN cabbieV2) it doens't. |
| 02:38:38 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:19:30 | | Quit ZincAlloy (Quit: Leaving.) |
| 03:23:35 | | Join o43 [0] (~jas@c-73-7-150-112.hsd1.ga.comcast.net) |
| 03:38:10 | | Quit o43 (Ping timeout: 240 seconds) |
| 03:47:32 | | Join o43 [0] (~jas@c-73-7-150-112.hsd1.ga.comcast.net) |
| 03:54:06 | | Join Bilgus [0] (~WW@cpe-174-102-17-217.cinci.res.rr.com) |
| 04:00 |
| 04:28:55 | [Saint] | what resolution is the ZEN? |
| 04:28:58 | | Quit o43 (Ping timeout: 260 seconds) |
| 04:29:35 | [Saint] | No, lets do it a different way - what do you expect to happen, chrisjj? |
| 04:30:16 | [Saint] | it should show that a charger is connected, and the battery meter should reflect this. If you're expecting a numeric value, then, no. |
| 04:31:08 | [Saint] | this is handled by the .sbs and has nothing to do with cabbiev2 directly other than the fact that cabbiev2 uses the fallback statusbar. |
| 04:37:03 | | Join o43 [0] (~jas@c-73-7-150-112.hsd1.ga.comcast.net) |
| 04:37:59 | [Saint] | Oh, hmmm, sorry, My mistake. I forgot cabbiev2 disabled the .sbs |
| 04:38:42 | *** | Saving seen data "./dancer.seen" |
| 04:38:58 | [Saint] | So the answer is no. |
| 04:40:09 | __builtin | [Saint]: do you have a PortalPlayer iPod you can test something on? |
| 04:40:52 | [Saint] | It'll show if a charger is connected and not charging, is connected and charging, or the battery state. |
| 04:41:04 | [Saint] | __builtin: several, but none on my right this very second. |
| 04:41:14 | [Saint] | what do you need tested? |
| 04:41:23 | [Saint] | s/my/me/ |
| 04:41:43 | __builtin | how slow an antialiased line function of mine is |
| 04:42:12 | __builtin | turns out the PP devices are the slowest devices (by cpu freq, at least) that have a color screen |
| 04:44:49 | [Saint] | MHz does not speed make. |
| 04:45:11 | __builtin | yes, I know |
| 04:45:25 | __builtin | how else should I attempt to quantify speed then? |
| 04:46:33 | [Saint] | the only adequate and objective metric in my opinion would be the codec performance comparison benchmarks. |
| 04:47:02 | [Saint] | There you get a sample size of targets performing a known operation. |
| 04:47:41 | __builtin | well, I can't easily run queries against those (i.e. which are the slowest ones with a color display) |
| 04:48:19 | __builtin | so cpu frequency will have to do ;) |
| 04:48:22 | [Saint] | Why not? |
| 04:48:28 | [Saint] | Oh. You said /easily/ |
| 04:49:00 | __builtin | yeah −− with cpu frequency anything I need is just a grep and awk away |
| 04:49:02 | [Saint] | Meh. You know which targets have colour displays, and the output is standardized. You could form a nice little table with some grep magic. |
| 04:50:41 | [Saint] | you don't need to care about all the codec results as long as you pick one that is consistent amongst the targets you're interested in. |
| 04:51:45 | [Saint] | frequency falls over, I think, because on the surface it's 80MHz but you've also got the coprocessor to think about so it's realistically dual-core. |
| 04:52:11 | __builtin | well, in this case it's a single thread doing all the work |
| 04:52:14 | [Saint] | though there's a lot of fundamental differences. |
| 04:52:26 | [Saint] | ah. |
| 04:52:36 | [Saint] | right. |
| 04:52:48 | __builtin | basically it doesn't *have* to be the slowest device, just slow enough to see if my algorithm is "too slow" |
| 04:54:07 | __builtin | I tried testing on one of lebellium's c200s, but horrible display makes it hard to really judge anything |
| 04:55:17 | __builtin | right now antialiased (Wu) lines take about 4x longer than Bresenham (or whatever rockbox uses) |
| 04:59:23 | [Saint] | serious question, at 220x176 to 240x320, does it matter? |
| 04:59:36 | [Saint] | is the difference even visible? |
| 05:00 |
| 05:00:26 | __builtin | actually, yes |
| 05:00:38 | __builtin | let me get you some visual evidence |
| 05:03:46 | [Saint] | that's genuinely surprising. |
| 05:04:34 | __builtin | https://www.fwei.tk/shot28.png |
| 05:06:34 | [Saint] | I imagine 176x220 makes a significant difference. |
| 05:09:41 | Bilgus | wow that is quite a difference |
| 05:10:21 | [Saint] | the problem is, though, it's in simulation and the pixel packing and DPI is completely different. |
| 05:10:41 | [Saint] | sim can't really tell you shit in this regard. |
| 05:10:58 | | Quit o43 (Ping timeout: 260 seconds) |
| 05:11:20 | * | __builtin is waiting for [Saint] to test it on his device so he can see! |
| 05:11:24 | __builtin | :P |
| 05:11:43 | Bilgus | __builtin, what kind of algorithm are you using? |
| 05:12:07 | __builtin | a fixed point adaptation of Wu's algorithm |
| 05:12:07 | Bilgus | is it simple interpolation? |
| 05:13:28 | __builtin | basically it draws a 2-pixel wide line with different brightness values that add to unity |
| 05:13:54 | __builtin | and those values are dependent on how much "line" falls into each pixel |
| 05:14:25 | __builtin | well, good night |
| 05:15:07 | Bilgus | I'm a big fan of pre computed values |
| 05:16:07 | Bilgus | I once did something similar with beizer curves for rounded controls |
| 05:16:59 | | Join o43 [0] (~jas@c-73-7-150-112.hsd1.ga.comcast.net) |
| 05:34:56 | | Quit o43 (Quit: Lost terminal) |
| 06:00 |
| 06:30:23 | | Quit TheSeven (Ping timeout: 258 seconds) |
| 06:31:02 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 06:38:43 | *** | Saving seen data "./dancer.seen" |
| 06:46:49 | | Join gs6 [0] (~na@cpe-70-121-72-128.austin.res.rr.com) |
| 06:46:54 | | Quit [Saint] (Remote host closed the connection) |
| 06:47:06 | gs6 | Is Rockbox dead/dying? |
| 06:47:43 | gs6 | There is no recent Android build, right? |
| 06:48:20 | | Join [Saint] [0] (~sinner@rockbox/staff/saint) |
| 06:59:45 | Bilgus | the wat I got it was there won't be a recent Android build either as they changed the threading model but there are new ports in progress |
| 07:00 |
| 07:01:25 | Bilgus | @ gs6 |
| 07:02:41 | [Saint] | ...wut? |
| 07:02:48 | [Saint] | that first sentence is super awkward. |
| 07:03:34 | [Saint] | and, no, everything past Android 4.4.4 is dead. |
| 07:03:41 | gs6 | Okay |
| 07:04:01 | [Saint] | you can compile for Android 5+, but it is an obscene hack. |
| 07:04:18 | [Saint] | honestly though, it's 2017. |
| 07:04:32 | [Saint] | wanting to run Rockbox on modern Android seems like masochism. |
| 07:04:44 | [Saint] | If you prefer, I could just come over and kick you in the balls. |
| 07:04:50 | gs6 | Well, I don't know many decent music players for Android |
| 07:05:02 | gs6 | Rockbox has features VLC doesn't have |
| 07:05:10 | gs6 | And it's faster |
| 07:05:43 | Bilgus | wat = way :) |
| 07:05:53 | [Saint] | ah. |
| 07:06:14 | [Saint] | But, yeah - perhaps you're looking at it through rose tinted glasses. |
| 07:06:33 | gs6 | It would be cool if there was a new sort of project that's just a music player without support for embedded devices |
| 07:06:52 | gs6 | 'Cause all the audio features of Rockbox are really cool |
| 07:06:58 | [Saint] | well, we do run as an SDL app my man. |
| 07:07:23 | [Saint] | You'll need to compile it yourself, however. |
| 07:07:58 | [Saint] | for context, the takeaway from that is that it is exactly what you're asking for. |
| 07:08:06 | gs6 | For Android?? |
| 07:08:10 | gs6 | SDL? |
| 07:08:20 | gs6 | Or just desktop? |
| 07:08:24 | [Saint] | Rockbox on generic x86/64, MIPS, ARM |
| 07:09:00 | gs6 | Oh, I don't expect SDL Android support to be very good |
| 07:09:18 | gs6 | Well, it's not in the Play store to try |
| 07:09:24 | [Saint] | There's no such thing, so, yes - you're quite right. |
| 07:09:29 | [Saint] | it wouldn't be very good. |
| 07:09:36 | gs6 | Oh |
| 07:09:53 | gs6 | I tried a Qt Android app and it was pretty garbage |
| 07:10:08 | Bilgus | VLC for android has plugins now |
| 07:10:12 | gs6 | Sadly, Android features are so tightly knitted to the UI |
| 07:10:19 | [Saint] | The reason why Rockbox never made it to the play store is multi faceted. |
| 07:10:34 | [Saint] | the primary reason is that we much target a specific resolution for the framebuffer. |
| 07:10:46 | gs6 | Yeah, I remember reading that |
| 07:10:55 | gs6 | Doesn't seem like a huge issue |
| 07:11:00 | [Saint] | So instead of a single app, there would be hundreds. |
| 07:11:08 | [Saint] | it's a very huge issue. |
| 07:11:14 | gs6 | That's got to be like 5% of what Rockbox does |
| 07:11:24 | gs6 | It's just the freakin' menu |
| 07:11:59 | gs6 | But sorry if I'm way off base |
| 07:12:06 | [Saint] | Well, given that it _won't even boot_ if the application and host don't agree on the framebuffer in modern Android, it is a massive issue. |
| 07:12:19 | [Saint] | you are, it makes it sound like we're just lazy. |
| 07:12:34 | [Saint] | there's many very real and fundamental reasons this never happened. |
| 07:12:59 | Bilgus | mainly because saint is lazy :p i'm sure of it |
| 07:13:20 | * | [Saint] nods |
| 07:13:51 | | Quit atsampson (Ping timeout: 240 seconds) |
| 07:15:05 | [Saint] | Technically speaking you could run a Debian armhf/el/eabi chroot in Android and run the sim or SDL app builds there. |
| 07:15:19 | [Saint] | but that's a hilarious chain of things just waiting to break. |
| 07:24:33 | | Quit TorC (Ping timeout: 260 seconds) |
| 07:35:28 | gs6 | It sounds like the core functionality and the UI are tightly coupled in Rockbox |
| 07:38:23 | | Join TorC [0] (~TorC@fsf/member/TorC) |
| 07:39:09 | gs6 | Another thing I'm curious about is how the decoding code compares to ffmpeg |
| 07:40:01 | gs6 | I wonder if its smaller and more efficient since it had to run on embedded devices |
| 07:42:10 | gs6 | I think it might be fun to refactor Rockbox and use the JNI to create an Android UI |
| 07:42:40 | gs6 | But I don't know if it would be easier to start from scratch |
| 07:42:52 | gs6 | Rockbox has a lot of cool features |
| 07:43:08 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 07:43:08 | | Quit pixelma (Quit: .) |
| 07:43:19 | | Join pixelma [0] (~pixelma@rockbox/staff/pixelma) |
| 07:43:20 | | Join amiconn [0] (~amiconn@rockbox/developer/amiconn) |
| 07:44:35 | gs6 | I think there might be a licensing issue though since Rockbox is GPL, right? |
| 07:44:59 | [Saint] | It is, but no, there wouldn't be. |
| 07:45:16 | gs6 | If you distributed an apk in the Play store, the user wouldn't be able to view the source |
| 07:45:23 | gs6 | Or change it |
| 07:45:27 | [Saint] | So what? |
| 07:45:38 | [Saint] | These are not mutually exclusive things. |
| 07:45:39 | gs6 | I think that might be against the GPL terms |
| 07:45:58 | [Saint] | Source msut be supplied to those distributed a binary in a reasonable format on request. |
| 07:46:02 | [Saint] | Not proactively. |
| 07:46:07 | gs6 | Oh really |
| 07:46:11 | [Saint] | Really really. |
| 07:46:18 | gs6 | Okay, that's good |
| 07:46:48 | [Saint] | fun fact: "reasonable format" is unreasonably (pun intended) vague. |
| 07:47:00 | [Saint] | Technically, you could print it out on A4 letterhead and mail it to them |
| 07:47:21 | gs6 | Well, if it was on Github with compilation instructions I think that would be sufficient |
| 07:47:37 | [Saint] | Entirely so. |
| 07:47:56 | [Saint] | As for how Rockbox compares to ffmpeg in the coded sense - basically identically. |
| 07:48:24 | gs6 | Does Rockbox predate ffmpeg? |
| 07:49:13 | gs6 | Maybe it would be better to just port mpv to Android |
| 07:49:18 | [Saint] | Yes. |
| 07:49:28 | [Saint] | Rockbox is about 16 years old now. |
| 07:50:08 | gs6 | But Rockbox has playlist and audio features not in mpv |
| 07:50:36 | [Saint] | You might want to look at Warble/librockbox. |
| 07:50:48 | gs6 | Oh, librockbox? |
| 07:50:53 | gs6 | That sounds cool |
| 07:50:57 | gs6 | Is that new? |
| 07:50:57 | [Saint] | It's in our source tree. It's a demo of a standalone playback library. |
| 07:51:07 | gs6 | Very cool |
| 07:51:08 | [Saint] | No. It's about 6 years old. |
| 07:51:21 | [Saint] | Spawned from our last GSOC. |
| 07:51:25 | gs6 | Was the Android Rockbox not built on that? |
| 07:51:49 | [Saint] | No. |
| 07:52:16 | gs6 | So maybe an Android UI and JNI bindings to librockbox could work |
| 07:52:25 | [Saint] | The Android port uses the same core code all the embedded ports do. |
| 07:52:43 | [Saint] | Honestly, you'd be better off just using android-ffmpeg. |
| 07:53:14 | [Saint] | it's infinitely more feature complete than librockbox. librockbox was just a proof of concept. |
| 07:53:19 | gs6 | Does ffmpeg have equalizer stuff and other signal processing? |
| 07:53:29 | [Saint] | Yes. |
| 07:53:40 | gs6 | Oh |
| 07:53:53 | gs6 | Yeah, I would love to have an android player based on ffmpeg |
| 07:54:04 | gs6 | I guess VLC might do that |
| 07:54:28 | gs6 | I just thought VLC for Android was crappy compared to Rockbox |
| 07:54:35 | gs6 | Much slower and less intuitive |
| 07:55:06 | [Saint] | You're not wrong about the slower part. |
| 07:55:13 | [Saint] | Intuitive might be arguable. |
| 07:55:27 | gs6 | I couldn't do some of the playlist stuff |
| 07:55:31 | [Saint] | I don't really think there's anything about our UI that's intuitive at all. |
| 07:55:57 | gs6 | It has been a while since I tried VLC |
| 07:56:00 | [Saint] | It's the best we can do with the absurd amount of granularity we have though. |
| 07:56:27 | [Saint] | it's hard to make a UI that holds several hundred settings intuitive. |
| 07:59:35 | gs6 | Just tried VLC |
| 07:59:39 | gs6 | It's so garbage |
| 07:59:53 | gs6 | I can't even explain the amount of shitty things going on |
| 08:00 |
| 08:00:29 | gs6 | There's a tooltip that keeps popping up and it cover up everything |
| 08:00:50 | gs6 | If I try to select VLC in the app switcher, it doesn't work and goes to my home screen |
| 08:01:11 | gs6 | When I play one file in a directory, it doesn't add the rest to the playlist |
| 08:01:21 | gs6 | It's laggy as af |
| 08:01:28 | gs6 | laggy af |
| 08:01:55 | gs6 | There are weird icons that don't say what they do |
| 08:02:52 | gs6 | The Rockbox UI is just a straightforward list. Sure, there are a lot of submenus and you have to backtrack a bit, but at least it's not doing annoying or unpredictable stuff |
| 08:03:48 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:05:04 | gs6 | Like "playback speed" is an icon of a dude running |
| 08:06:13 | [Saint] | The one obvious benefit with VLC is HW accelerated decoding on supported targets. So no matter what it's always going to be infinitely more efficient. |
| 08:08:00 | gs6 | Hm |
| 08:08:08 | gs6 | Well, I must be lacking it lol |
| 08:08:22 | gs6 | I have a rather old phone and rockbox is much smoother |
| 08:09:03 | gs6 | The UI of VLC is not so bad as I mess with it |
| 08:09:14 | gs6 | Starting to figure it out |
| 08:12:51 | gs6 | I don't see an option to set the file browser root |
| 08:15:15 | | Quit Moarc (Quit: i znowu NADMUCHAล BALONA) |
| 08:25:26 | | Join Moarc [0] (~chujko@a105.net128.okay.pl) |
| 08:38:47 | *** | Saving seen data "./dancer.seen" |
| 08:39:34 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 08:39:37 | | Quit wodz (Client Quit) |
| 08:39:56 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 08:46:32 | | Join petur [0] (~petur@91.183.48.77) |
| 08:46:32 | | Quit petur (Changing host) |
| 08:46:32 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 08:51:30 | | Join JdGordon_ [0] (~jonno@124-148-155-218.dyn.iinet.net.au) |
| 08:51:30 | | Quit JdGordon_ (Changing host) |
| 08:51:30 | | Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) |
| 09:00 |
| 09:13:05 | | Quit TorC (Ping timeout: 240 seconds) |
| 09:14:08 | | Join TorC [0] (~TorC@fsf/member/TorC) |
| 09:39:21 | | Quit TorC (Ping timeout: 245 seconds) |
| 09:50:24 | | Join xorly [0] (~xorly@wced-12-219-32-147.feld.cvut.cz) |
| 09:58:59 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 10:00 |
| 10:06:31 | pamaury | chrisjj: I'll send you a build for cd8b33327c9 |
| 10:19:36 | | Quit krnlyng (Ping timeout: 258 seconds) |
| 10:30:51 | | Quit elensil (Ping timeout: 240 seconds) |
| 10:32:16 | | Quit pamaury (Ping timeout: 245 seconds) |
| 10:32:52 | | Join krnlyng [0] (~liar@178.114.70.41.wireless.dyn.drei.com) |
| 10:37:17 | | Quit Tristitia (*.net *.split) |
| 10:37:17 | | Quit benedikt93 (*.net *.split) |
| 10:37:34 | | Join benedikt93 [0] (~quassel@unaffiliated/benedikt93) |
| 10:38:46 | | Quit scorche (*.net *.split) |
| 10:38:47 | | Quit mc2739 (*.net *.split) |
| 10:38:47 | | Quit K1773R (*.net *.split) |
| 10:38:49 | *** | Saving seen data "./dancer.seen" |
| 10:39:06 | | Quit prg318 (*.net *.split) |
| 10:39:06 | | Quit GodEater (*.net *.split) |
| 10:39:06 | | Quit rogeliodh (*.net *.split) |
| 10:39:09 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 10:39:19 | | Join GodEater [0] (~whoknows@176.253.28.187) |
| 10:39:19 | | Quit GodEater (Changing host) |
| 10:39:19 | | Join GodEater [0] (~whoknows@rockbox/staff/GodEater) |
| 10:39:29 | | Join scorche [0] (~scorche@rockbox/administrator/scorche) |
| 10:39:48 | | Join prg318 [0] (~prg318@deadcodersociety/prg318) |
| 10:40:12 | | Join Tristitia [0] (~tristitia@static-ip-69-64-50-196.inaddr.ip-pool.com) |
| 10:40:25 | | Join K1773R [0] (~K1773R@unaffiliated/k1773r) |
| 10:41:26 | | Join rogeliodh [0] (~rogeliodh@ec2-52-90-241-120.compute-1.amazonaws.com) |
| 10:48:58 | | Join elensil [0] (~edhelas@2001:1c02:1903:d800:611e:2ad2:8fd2:c667) |
| 10:49:56 | | Quit xorly (Ping timeout: 252 seconds) |
| 10:54:00 | | Join xorly [0] (~xorly@wced-12-219-32-147.feld.cvut.cz) |
| 10:54:30 | wodz | pamaury: beep_test opens /dev/icx_beep and then calls a few ioctl() ICX_SOUND_BEEP (0x620b4004) and ICX_BEEP_STATUS (0x6201c004) |
| 11:00 |
| 11:10:51 | | Join parchd [0] (~parchd@unaffiliated/parchd) |
| 11:21:50 | | Join TorC [0] (~TorC@fsf/member/TorC) |
| 11:29:32 | | Quit xorly (Ping timeout: 252 seconds) |
| 11:36:15 | | Join Piece_Maker [0] (~Acou_Bass@host-89-241-241-2.as13285.net) |
| 11:38:18 | | Quit Acou_Bass (Ping timeout: 260 seconds) |
| 11:38:18 | | Nick Piece_Maker is now known as Acou_Bass (~Acou_Bass@host-89-241-241-2.as13285.net) |
| 11:41:53 | | Join xorly [0] (~xorly@wifi-cl-57.feld.cvut.cz) |
| 11:42:21 | | Join robertd1 [0] (~root@201.242.214.237) |
| 12:00 |
| 12:20:33 | | Join pamaury [0] (~quassel@wks-50-63.mpi-sws.org) |
| 12:20:33 | | Quit pamaury (Changing host) |
| 12:20:33 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 12:23:31 | | Join Mihail [0] (25d4b372@gateway/web/cgi-irc/kiwiirc.com/ip.37.212.179.114) |
| 12:26:18 | Mihail | wodz: I want add scaling for CVDD2 on AMSv2 (http://forums.rockbox.org/index.php/topic,51616.0.html). But at low values of CVDD2 internal flash stop working. If I revert voltages to normal - it accept CMD0, CMD8 (response 0x1AA) but stop with timeout on ACMD41 (response 0x40ff8000). I try power off (MCI_PWREN) but internal flash and sd card always |
| 12:26:18 | Mihail | work, so probably both powered directly to CVDD2. Are you have idea how reset internal flash controller or what should I check/try? |
| 12:26:42 | wodz | I am not amsv2 guy, sorry |
| 12:26:47 | wodz | Mihail: ^ |
| 12:29:31 | Mihail | but you know well sd spec :) way to reset sd card without power off? |
| 12:30:21 | | Quit holyheels (Read error: Connection reset by peer) |
| 12:31:47 | wodz | Mihail: Other then usual cmd0 and 74+ clock cycles - no |
| 12:35:59 | | Quit gs6 (Read error: No route to host) |
| 12:36:01 | Mihail | I already try it, also try CMD0 with argument of 0xFFFFFFFA and 0xF0F0F0F0 (from emmc spec) - no success :( |
| 12:37:40 | Mihail | If you have time can you review http://gerrit.rockbox.org/r/#/c/1469/ ? |
| 12:38:51 | *** | Saving seen data "./dancer.seen" |
| 12:39:07 | | Quit xorly (Ping timeout: 258 seconds) |
| 12:40:34 | wodz | Mihail: Are you sure you want to panic on failed sd transfer? |
| 12:42:56 | Mihail | I want to remove this checking at all - count > 0 have no sense. But first check if we have this case. |
| 12:43:18 | Mihail | count < 0 |
| 12:43:55 | wodz | Mihail: I mean line 776 of gerrit task |
| 12:45:05 | wodz | aaa, it is just sanity check so it may make sense |
| 12:46:04 | Mihail | yes |
| 12:48:27 | Mihail | probably I should change it to "count < 1" as count == 0 also have no sense |
| 12:49:16 | | Quit Ruhan (Quit: Connection closed for inactivity) |
| 12:53:11 | | Join atsampson [0] (~ats@cartman.offog.org) |
| 13:00 |
| 13:02:10 | wodz | pamaury: radio_test binary uses some 'private' IOCTLs. According to the strings this are to access tuner registers, tuner GPIO2 ???, and perform reset. |
| 13:03:06 | wodz | pamaury: There are some standard IOCTLs as well, namely VIDIOC_G_TUNER and VIDIOC_S_TUNER |
| 13:04:19 | wodz | pamaury: Ah, and VIDIOC_QUERYCAP |
| 13:08:20 | | Join holyheels [0] (~holyheels@52d3d456.dynamic-ip.k-net.dk) |
| 13:09:50 | | Join xorly [0] (~xorly@wced-12-219-32-147.feld.cvut.cz) |
| 13:15:22 | | Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:6580:4f45:dca9:4816) |
| 13:17:39 | wodz | pamaury: 'private' IOCTLs are of type 'v' instead of v4l2 'V' |
| 13:27:41 | | Quit fulon (Ping timeout: 245 seconds) |
| 13:29:18 | chrisjj | pamaury: FYI, the last run of 7e0820fe2 (on the unit (Unit Q) where some previous runs crashed) has gone 10h with no crash. |
| 13:30:28 | chrisjj | Also be68b6a7bM-170108 (memDFS) on a second unit (Unit G) has run with no crashes - 8h so far. |
| 13:31:17 | chrisjj | So, mysterious variation. |
| 13:35:36 | | Quit parchd (Ping timeout: 245 seconds) |
| 13:49:21 | | Join mutnai [0] (6db90a3e@gateway/web/freenode/ip.109.185.10.62) |
| 14:00 |
| 14:00:09 | | Join skapazzo [0] (~skapazzo@151.9.205.1) |
| 14:01:35 | | Join Ruhan [0] (uid76353@gateway/web/irccloud.com/x-evdjrwapctrpofwt) |
| 14:11:37 | | Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) |
| 14:26:01 | | Quit xorly (Ping timeout: 245 seconds) |
| 14:32:50 | pamaury | chrisjj: that's weird |
| 14:33:13 | pamaury | it would interesting to bisect on the unit where it crashes though, to see if we can find a particular commit responsible |
| 14:34:03 | wodz | pamaury: sony's kernel module definitely supports 'v' IOCTLs but I can't find definition for this in sources |
| 14:34:22 | pamaury | wodz: not all ioctls are in the headers unfortunately |
| 14:34:39 | pamaury | it's good to know there exists ioctl to access registers directly though |
| 14:34:59 | pamaury | this means that we can either try to use v4l2 interface or directly the tuner and reuse some of our drivers, depending on what is best |
| 14:35:18 | wodz | pamaury: as well as it seems registers are exposed through /proc |
| 14:35:29 | pamaury | ah yes I remember that |
| 14:35:43 | pamaury | wodz: can you try to document this somewhere on the wiki ? Like SonyNWLinuxTuner ? |
| 14:36:23 | wodz | direct register access will have the benefit of bypassing region and dependence on nvp thing |
| 14:37:45 | pamaury | good point |
| 14:38:02 | pamaury | however we are not sure what tuners are in use |
| 14:38:15 | pamaury | I think it would be a good idea to gather a list of components for each player |
| 14:38:40 | pamaury | the soc is easy but for dac and tuner, it's |
| 14:38:43 | mutnai | you could go for sony nw-s10 series instead of nwz-e580. it supports FLAC , NC headphones included and 77 hours of battery, but no microSD slot. |
| 14:38:43 | pamaury | tricky |
| 14:38:54 | *** | Saving seen data "./dancer.seen" |
| 14:38:56 | mutnai | for Yogurt |
| 14:39:22 | wodz | The clean way would be to use standard v4l2 interface and let sony handle the burden |
| 14:39:47 | pamaury | mutnai: there is no 'instead', I'll support as many as I can. However I don't have a nw-s10, I would need at least someone with the device to run things on it for me |
| 14:39:53 | pamaury | wodz: agreed |
| 14:40:29 | wodz | pamaury: The only thing I am not sure is how 'compliant' sony's driver is |
| 14:43:43 | chrisjj | pamaury: Weird agreed. |
| 14:46:31 | chrisjj | Can we make PANIC send info somewhere apart from the screen? E.g. to \panic.txt? To USB? Even to audio out! |
| 14:46:55 | pamaury | mutnai: also the S10 is quite expensive |
| 14:47:28 | pamaury | chrisjj: not really, but we don't know for sure if it's a panic |
| 14:47:37 | pamaury | does the WEN have a LED ? |
| 14:47:44 | mutnai | sorry... this was for Yogurt, for yesterday discuss ) |
| 14:48:01 | chrisjj | The ZEN does have a LED. |
| 14:48:02 | pamaury | chrisjj: what I could do, for debug purposes, is to make backlight blink on panic |
| 14:48:09 | pamaury | and/or the LED |
| 14:48:14 | pamaury | that way it's easy to tell |
| 14:48:21 | wodz | hell, ioctl code in this sony's radio driver is convoluted :/ |
| 14:48:52 | chrisjj | I'd guess backlight blink on panic will be visible regardless of how messed up the LCD is. |
| 14:49:05 | chrisjj | LED blink on panic would certainly be visible. |
| 14:49:54 | | Quit paulk-blaze (Remote host closed the connection) |
| 14:50:06 | pamaury | chrisjj: ok, I'll look into it tonight. LED blinking on panic sounds like a good idea in general on target that have a LED |
| 14:50:18 | | Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) |
| 14:51:46 | chrisjj | Is the current LED behaviour due to .rockbox? Or some hardware process? |
| 14:53:02 | pamaury | it's controllable by software |
| 14:53:30 | pamaury | on the ZEN X-Fi it's basically a red-green led controlled by two PWN. On LED I think it's a (blue ?) LEd controlled by a PWM |
| 14:53:48 | pamaury | *On ZEN I think it's a blue LED |
| 14:54:03 | | Quit fs-bluebot (Ping timeout: 258 seconds) |
| 14:55:05 | chrisjj | Indeed I have only even seen the ZEN LED show blue. |
| 14:55:28 | | Quit bluebrother (Ping timeout: 248 seconds) |
| 14:56:42 | chrisjj | I know it is controllable by software, but I'm interested to if it is controll/ed/ by software when working under RB. I.e. it is RB itself that is turning the LED from dim to bright on start-up, and off on shut-down? |
| 14:56:55 | pamaury | Currently rockbox doesn't use LEDs, because I don't know what to do with them ^^ |
| 14:57:18 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 14:57:20 | pamaury | I think Creative's bootloader send them to some state on boot and we don't touch them but we could |
| 14:57:24 | pamaury | *set them |
| 14:57:38 | chrisjj | OK, as I suspected. So I take it the LED behaviour under RB is actually due to hardware e.g. the PWM running on auto. |
| 14:58:19 | pamaury | yeah but PWM can be changed, the point of PWN is that you setting a brightness setting and you let the hardware handle it |
| 14:58:59 | pamaury | however if you want blinking led, that requires software |
| 14:59:14 | pamaury | what would you use the LED for ? |
| 14:59:51 | chrisjj | I understand PWM. |
| 15:00 |
| 15:00:26 | chrisjj | What I don't know is what is causing the LED to go from dim to bright when RB starts. |
| 15:01:01 | | Quit jhMikeS (Ping timeout: 245 seconds) |
| 15:01:19 | wodz | pamaury: unless you can control PWM freq. With low freq you can set fill factor to 50% and voila - you have nice blinking led |
| 15:02:06 | pamaury | chrisjj: Creative's bootloader as I said |
| 15:02:18 | chrisjj | OK. |
| 15:02:59 | chrisjj | Then what is causing the LED to go from bright to off (as I see) upon this mystery crash to power-off?? |
| 15:03:02 | pamaury | wodz: ah yeah good point, I was more thinking about a slowing diming LED, indeed if you just want on/off, PWM can do it |
| 15:03:45 | pamaury | chrisjj: maybe the device simply powers off completely |
| 15:04:03 | wodz | on panic you don't need to be fancy with dimming |
| 15:04:28 | chrisjj | pamaury: OK, then that leaves the question of how a RB crash could power off the device completely. |
| 15:04:49 | pamaury | the watchdog can do that |
| 15:05:29 | pamaury | On imx233 I enable the watchdog. If the device crashes really hard (typically in interrupt context), the watchdog could trigger and reset the device |
| 15:05:38 | chrisjj | Ah, right... |
| 15:06:00 | chrisjj | And "reset the device" == put into the power-off state? |
| 15:08:26 | | Join fs-bluebot [0] (~fs-bluebo@xd9baf6fc.dyn.telefonica.de) |
| 15:09:14 | pamaury | chrisjj: I don't remember, I need to read the datasheet. I think it's a reset, so it reboots but then the bootloader notices that the user is not holding the power button so it disregards the boot and powers off |
| 15:09:33 | chrisjj | Figures. |
| 15:09:53 | chrisjj | A real PITA for debugging! |
| 15:10:25 | chrisjj | Can I ask: why is reset-on-watchdog in use? |
| 15:10:53 | wodz | good practice? |
| 15:12:18 | pamaury | good practice, if you reach this your device in unrecoverable anyway |
| 15:14:00 | chrisjj | Good practice /on stable commercial software/. |
| 15:14:11 | chrisjj | Can you think of any advantage on RB currently? |
| 15:14:51 | pamaury | can you think of any disadvantage ? |
| 15:15:08 | pamaury | it the reset button is not accessible that's useful |
| 15:17:55 | | Quit paulk-blaze (Remote host closed the connection) |
| 15:18:15 | chrisjj | I can think of a big disadvantage. |
| 15:18:20 | | Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) |
| 15:19:07 | chrisjj | "your device in unrecoverable anyway" but the PANIC info on screen is not unrecoverable. It stays... unless a watchdog reset wipes it. |
| 15:20:30 | chrisjj | reset on watchdog can make sense in release software on devices without accessible reset button, but on ZEN the reset button is accessible by paper clip. |
| 15:22:08 | | Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) |
| 15:22:23 | pamaury | chrisjj: you don't understand |
| 15:22:31 | pamaury | watchdog won't trigger on panic |
| 15:22:40 | chrisjj | Please clarify :-) |
| 15:22:41 | pamaury | watchdog triggers if the entire system freezes |
| 15:22:56 | chrisjj | Understood. |
| 15:23:08 | pamaury | if watchdog wasn't enabled, your device would go unresponsive, no panic, no thing |
| 15:23:46 | chrisjj | Only because if the software so chooses. |
| 15:24:16 | pamaury | ? |
| 15:24:28 | wodz | pamaury: How do you 'feed' watchdog? |
| 15:24:28 | pamaury | the software doesn't choose to crash |
| 15:24:46 | chrisjj | Software can choose to use the watchdog to trigger reset... or choose not to. |
| 15:25:11 | wodz | chrisjj: That is not the purpose of watchdog. The reset is side effect. |
| 15:25:16 | pamaury | wodz: I reset the watchdog on every timer IRQ iirc |
| 15:25:28 | pamaury | chrisjj: a watchdog only does reset |
| 15:25:55 | chrisjj | Understood. Still it is the software's choice. |
| 15:25:57 | pamaury | you cannot detect the watchdog triggering because by definition it means your software is malfunctioning |
| 15:26:09 | chrisjj | Understood. Anyway, I'm not trying to persuade you to change the RB choice. |
| 15:26:22 | wodz | pamaury: That what I thought. You shouldn't do that in IRQ. It may happen that firmware enters infinite loop with irqs on. This will not trigger watchdog. |
| 15:26:23 | pamaury | chrisjj: let it put differently: how does software detects that it is not working ? |
| 15:26:57 | chrisjj | Hey, you don't want to ask that of me. I'm an honours Computer Scientist :-) |
| 15:27:13 | pamaury | wodz: not sure what you mean. If the softwarre gets stuck in IRQ context, it will trigger because it is only reset when IRQ is entered |
| 15:27:23 | chrisjj | I'm trying to understand if there's some advantage in RB choosing to engage a watchdog to give reset on freeze. |
| 15:27:33 | pamaury | chrisjj: what else can you do ? |
| 15:27:34 | | Quit pamaury_ (Ping timeout: 240 seconds) |
| 15:27:46 | pamaury | the only other option to let it freeze |
| 15:28:08 | wodz | pamaury: I mean if software is stuck in main loop BUT irqs are unmasked it will fire indefinitely and hence watchdog will be happy |
| 15:28:11 | chrisjj | You can do nothing, let the s/w freeze and (hopefully) read the valuable PANIC info from the surviving LED display. |
| 15:28:48 | pamaury | wodz: I know but there is no easy way to detect that the 'userland' is frowen |
| 15:29:01 | pamaury | chrisjj: THERE IS NO PANIC ON FRICKING FREEZE |
| 15:29:21 | chrisjj | Understood. But is there a freeze after PANIC?? |
| 15:29:29 | wodz | pamaury: Feed watchog in some thread (UI?) |
| 15:30:04 | chrisjj | pamaury: recall what we're seeing. The device powered down after (what you suggested might be) a PANIC. |
| 15:30:45 | pamaury | chrisjj: then there is no panic, software gets stuckm, watchdog triggers and powers off. The panic screen disabled the watchdog obviously |
| 15:31:56 | chrisjj | Ah, if you're sure panic screen disables the watchdog, then I see no way the power-down state can be hiding a PANIC as (I think) you suggested. |
| 15:32:24 | pamaury | wodz: I knwo but that means we need so place in apps/ that would do that |
| 15:32:51 | chrisjj | FAOD, this is assuming "panic screen disabled the watchdog obviously" means disabled such that there will be no watchdog expiry and hence no reset cause by watchdog. |
| 15:32:56 | pamaury | chrisjj: you mentioned the screen was dark, it was not clear if it was a power-down |
| 15:33:31 | pamaury | chrisjj: you claim the LED is off but you only said that after I suggested it. And inddeed the LED being off seems to indicate it's a real power down |
| 15:33:36 | chrisjj | I actually said also that the state reponds to power press by entering power-up. |
| 15:33:52 | pamaury | yes but that's no indication |
| 15:34:02 | pamaury | because the panic screen will also reboot if you hit power |
| 15:34:16 | chrisjj | How so? I know no other state the reponds such. |
| 15:34:40 | pamaury | wodz: maybe we could have a 'software watchdog' that resets on thread switch ? |
| 15:35:00 | wodz | pamaury: ? |
| 15:35:19 | pamaury | to detect when a thread is stuck |
| 15:36:02 | pamaury | you setup a timer of expire after 10sec, and reset the timer on every thread switch. If the timer expires, panic |
| 15:36:22 | wodz | should work |
| 15:36:29 | chrisjj | pamaury: And does the panic screen turn off the LED?? I thought not. |
| 15:37:56 | wodz | pamaury: The canonical way to do that actually is that each thread sets bit in guard variable. When timer expires guard variable is checked if all bits are set. If not trigger some action (panic, reset, whatever) |
| 15:38:35 | pamaury | that would mean nontrivial changes in the threading code though no ? |
| 15:39:00 | wodz | Who said this is trivial change :-) |
| 15:39:02 | | Quit mutnai (Quit: Page closed) |
| 15:39:07 | pamaury | haha |
| 15:39:10 | wodz | embedded development is non trivial |
| 15:39:31 | pamaury | generally speaking having such a mecanism in rockbox in general would be nice |
| 15:39:49 | pamaury | it can use the tick task as a timer |
| 15:42:29 | chrisjj | pamaury: PANIC screen caused by the ZEN USB issue does /not/ turn off the LED. I'll continue to assume no PANIC turns off the LED, unless you advise otherwise. |
| 15:44:42 | wodz | pamaury: We do check stack guard on context switch. This shouldn't be too hard to extend to check/set guard bit as well. |
| 15:45:17 | pamaury | wodz: how does this work exactly ? Each thread has a variable and what/when set/checks the bit |
| 15:45:19 | pamaury | ? |
| 15:46:01 | pamaury | each thread sets its bit when it is switched to and regularly one checks if the bits are set and clear them, panic if on bit is not set ? |
| 15:46:48 | wodz | pamaury: Yes. There is one guard variable however. Like bitfield. |
| 15:52:01 | pamaury | ok |
| 15:54:27 | | Quit wodz (Quit: Ex-Chat) |
| 15:56:26 | | Quit rela (Ping timeout: 245 seconds) |
| 15:58:39 | chrisjj | pamaury: I confirm that the memDFS fail had LED off. Re your "you claim the LED is off but you only said that after I suggested it.", if you doubt my report, no problem. You should be able to confirm it on the device you have. If you need another device from me, just ask. |
| 16:00 |
| 16:01:12 | chrisjj | So, the fail state looks to me 100% like a power-off. And you've said the angered watchdog does reset to power-off. So I think it reasonable to conclude that this fail state is due to watchdog angered by e.g. freeze. |
| 16:05:28 | chrisjj | Re your 'what would you use the LED for ?', in PANIC I would blink it ... /if/ that could be done in hardware and no continued software execution, but https://www.rockbox.org/wiki/pub/Main/DataSheets/stmp35xx-ds-1-03.pdf suggests to me not (<< wodz). |
| 16:06:54 | pamaury | stmp35xx does not apply, you want to look for the stmp37xx datasheet, and yes it can be done |
| 16:07:00 | | Join fulon [0] (~vshyba@178.62.192.54) |
| 16:08:53 | chrisjj | I looked an could not find the datasheet for the ZEN's STMP3760. I did find your wiki note of differences, and saw no mention of any difference in PWM. |
| 16:09:40 | | Quit MrZeus (Ping timeout: 256 seconds) |
| 16:10:19 | pamaury | chrisjj: stmp3760 falls into the scope of stmp3700 |
| 16:11:34 | pamaury | https://www.rockbox.org/wiki/pub/Main/DataSheets/stmp37xx-ds-1-03.pdf |
| 16:14:16 | chrisjj | Thanks. Same applies. I don't see enough division for hardware LED blink. But if you say it can be done in hardware, I'm sure you're right :) |
| 16:15:39 | chrisjj | If you can add LED blink during PANIC screen, that would be great. Perhaps encode some sub-info in the blink rate? Shame the hardware can't do morse code to spell out the PANIC text! :) |
| 16:15:41 | pamaury | One uses PWM |
| 16:16:21 | pamaury | the output of the PWN goes to the gate of a transistor that controls the LED input. By changing the frequency and duty cycle, one can dim and blink the LED |
| 16:18:25 | chrisjj | Understood 100%. But to make it /blink/, one needs a long divider... which I don't see on this chip. |
| 16:21:10 | pamaury | chrisjj: there is plenty of room. The click is 24MHz, each channel has a local divider (CDIV) in range 1-1024 and then the PERIOD (measured in divided clock) can range from 1 to 65525 |
| 16:21:49 | pamaury | so you can basically reach blinking ~1Hz, if my math is correct |
| 16:22:59 | chrisjj | I make it 0.3Hz. Great! |
| 16:25:35 | chrisjj | Then seriously I think you could get three eye-resolvable bits of PANIC info in the pulse rate and width. |
| 16:29:20 | | Join Senji_ [0] (~Senji@85.187.103.250) |
| 16:34:37 | | Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) |
| 16:35:05 | chrisjj | If LED panic is going to go in core RB for users generally, perhaps the easiest encoding would be just rate, measured by eye by counting the number of pulses over e.g. 10secs. |
| 16:35:59 | pamaury | that seems way overkill to be honest. A blinking led is a good start |
| 16:37:56 | chrisjj | Fari enough. Esp. since I predict we're not going to see a blink in this case. We'll see dark - because the device is powered down. |
| 16:38:11 | chrisjj | BTW, is there a PNIC counter stored anywhere? |
| 16:38:56 | *** | Saving seen data "./dancer.seen" |
| 16:43:44 | | Quit paulk-blaze (Ping timeout: 248 seconds) |
| 16:48:58 | | Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) |
| 16:50:34 | | Quit paulk-blaze (Remote host closed the connection) |
| 16:54:19 | | Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) |
| 17:00 |
| 17:26:54 | | Join aude_ [0] (6df78c7b@gateway/web/freenode/ip.109.247.140.123) |
| 17:28:31 | | Join n3m9 [0] (~n3m9@ANantes-652-1-183-36.w2-1.abo.wanadoo.fr) |
| 17:28:35 | aude_ | hi. I recently lost my Clip Zip in a jacket that was stolen (not surprising, there was a Clip Zip with Rockbox in it after all). I'm looking for a new device. any recommendations? :) |
| 17:32:57 | | Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) |
| 17:38:16 | | Join MrZeus [0] (~MrZeus@81.144.218.162) |
| 17:40:01 | | Quit petur (Read error: Connection reset by peer) |
| 17:43:12 | | Quit pamaury (Remote host closed the connection) |
| 17:46:10 | | Join chrisb [0] (~chrisb@pool-71-175-247-154.phlapa.east.verizon.net) |
| 17:46:51 | | Quit pamaury_ (Ping timeout: 240 seconds) |
| 17:54:52 | | Quit paulk-blaze (Quit: Leaving) |
| 18:00 |
| 18:38:35 | | Join JanC_ [0] (~janc@lugwv/member/JanC) |
| 18:38:57 | *** | Saving seen data "./dancer.seen" |
| 18:39:48 | | Quit JanC (Killed (orwell.freenode.net (Nickname regained by services))) |
| 18:39:48 | | Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) |
| 18:47:48 | | Quit aude_ (Quit: Page closed) |
| 18:51:40 | | Join Senji [0] (~Senji@85.187.103.250) |
| 18:53:31 | | Quit Senji_ (Ping timeout: 240 seconds) |
| 19:00 |
| 19:16:01 | | Join lebellium [0] (~chatzilla@89-93-179-5.hfc.dyn.abo.bbox.fr) |
| 19:17:09 | | Join parchd [0] (~parchd@unaffiliated/parchd) |
| 19:18:53 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 19:19:03 | [Saint] | It really bugs that shit out of me that chrisjj chooses to argue with highly experienced embedded software developers based on nothing but the notion of how he believes things should work in fanciful chrisjj-land. |
| 19:19:20 | [Saint] | So much so, I'm very highly considering just removing the problem entirely. |
| 19:19:48 | [Saint] | Take that as fair warning my man. |
| 19:21:22 | comradekingu | There is a difference between walking in nature and being out to feed the trolls |
| 19:22:52 | chrisb | what's happening? |
| 19:23:06 | __builtin | chrisb: not you |
| 19:23:40 | chrisb | chrisjj != chrisb |
| 19:23:44 | chrisb | ok |
| 19:24:09 | __builtin | [Saint] and a bunch of others are rather annoyed by chrisjj's, uh, "behavior" |
| 19:24:23 | * | chrisb just updated two old sansa e250's to the latest release |
| 19:24:43 | | Part __builtin ("http://quassel-irc.org - Chat comfortably. Anywhere.") |
| 19:24:47 | | Join __builtin [0] (~xray@rockbox/developer/builtin) |
| 19:25:18 | [Saint] | At this point I find it basically impossible to believe that chrisjj isn't going out of his way to antagonize. |
| 19:25:57 | [Saint] | It's either that, or being entirely socially inept, and needing to take a step backwards and reevaluate things drastically. |
| 19:30:40 | | Quit Mihail (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 19:40:13 | | Join paulk-collins [0] (~paulk@gagarine.paulk.fr) |
| 19:41:39 | comradekingu | Seems he is just making conversation, what is the issue? |
| 19:41:59 | | Quit n3m9 (Read error: Connection reset by peer) |
| 19:44:02 | [Saint] | I find it pretty hard to believe anyone could read the backlog and say that, but so be it. |
| 19:44:36 | [Saint] | One supposes a lot of it is contextually sensitive with reference to historical action. |
| 19:52:49 | comradekingu | If you dont entertain the thought of being wrong, maybe you put too much faith in being right |
| 19:54:11 | * | gevaerts wonders how that statement is in any way relevant for #rockbox |
| 20:00 |
| 20:12:55 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 20:27:22 | | Join johnb2 [0] (~johnb2@p5B296F82.dip0.t-ipconnect.de) |
| 20:32:35 | johnb2 | Database->Autoupdate: am I right assuming, that this is done only once after boot or unplug from USb? |
| 20:35:13 | johnb2 | Mihail: as the forum is down again, would you mind giving the link to the clip+ build here on IRC? |
| 20:38:58 | *** | Saving seen data "./dancer.seen" |
| 20:40:57 | [Saint] | johnb2: you are both correct and incorrect. |
| 20:41:08 | [Saint] | There's another case, insertion of removable media. |
| 20:44:14 | chrisb | how can i determine the max removable memory the sansa e250 can address? |
| 20:45:49 | [Saint] | By looking at the sd specification and knowing that it is 4TB and we'll literally never hit that density. |
| 20:46:39 | [Saint] | which is a long winded way of saying that any capacity you throw at it will work under Rockbox. |
| 20:46:59 | chrisb | [Saint]: ok, thanks |
| 20:47:01 | [Saint] | The OF may or may not have arbitrary limitations. |
| 20:47:37 | chrisb | OF? |
| 20:49:55 | [Saint] | Original Firmware |
| 20:51:22 | johnb2 | Mihail: never mind, Firefox remembered the URL: http://knk.square7.ch/cvdd2/ |
| 20:55:15 | johnb2 | [Saint] |
| 20:55:46 | lebellium | pamaury: because of the standby mode, you can't get the boot selection screen once you used the OF -_- Same problem on yp-r0. We solved it by adding a reset function when you press power off several seconds. That way you don't need a pencil everytime to press the reset hole... I don't know if that would be possible on NWZ |
| 20:55:52 | | Join wodz [0] (~wodz@89.74.169.198) |
| 20:56:00 | johnb2 | thanks, and this is nothing relevant regarding power consumption on a flash based device, right? |
| 20:56:13 | | Quit alucryd (Remote host closed the connection) |
| 20:56:51 | pamaury | lebellium: you can plug usb, no need for reset |
| 20:56:55 | wodz | pamaury: http://paste.debian.net/908141 |
| 20:57:08 | pamaury | lebellium: I'm not sure it's possible to do that but I'll have a look |
| 20:57:14 | lebellium | pamaury: I mean when you're not at home |
| 20:57:18 | | Join alucryd [0] (~quassel@archlinux/developer/alucryd) |
| 20:58:16 | pamaury | lebellium: I know, I was teasing you ;) |
| 20:58:26 | johnb2 | relevant = significant |
| 20:58:28 | pamaury | and mentionning that usb "solves it" if you can |
| 20:58:38 | lebellium | pamaury: also I would display "Rockbox" first instead of "walkman" and make it the default selection after a short timeout |
| 20:58:48 | pamaury | wodz: ok, fmp doesn't seem very useful at first glance... |
| 21:00 |
| 21:00:01 | pamaury | lebellium: the bootloader will (when I implement it) remember the last user choice |
| 21:00:09 | pamaury | and only show the menu when switch is on |
| 21:00:14 | pamaury | at least that's my current plan |
| 21:00:15 | lebellium | nice :) |
| 21:03:00 | pamaury | I think it is possible install another program on the device to monitor the power button and start it from sysv init |
| 21:05:03 | chrisjj | pamaury: FWIW, 7e0820fe2 (on the unit (Unit Q) where some previous runs crashed) has now gone 17h with no crash. And be68b6a7bM-170108 (memDFS) on a second unit (Unit G) has gone 15h with no crash. |
| 21:06:54 | chrisjj | So even though resuls are no solid repeatable, they should give us enough battery_bench data to determine the memDFS saving, and perhaps enough crashed to determine the casue on a more-debuggable build. |
| 21:07:24 | chrisjj | pamaury: Is there a PANIC counter? |
| 21:07:42 | pamaury | no, why would there be ? |
| 21:08:45 | chrisjj | OK. Why? So after a reset we can see whether there had been a PANIC hidden by the failed LCD. |
| 21:09:47 | pamaury | I think you are a bit obsessed with the panic screen. May I remind you that the goal is to avoid panic and not counting how many of them you manage to achieve ? |
| 21:10:18 | [Saint] | Gotta catch 'em all, PANICmon. |
| 21:10:24 | chrisjj | Thanks, I am duly reminded :) |
| 21:10:38 | chrisjj | And avoiding this panic is exactly what I'd like to do. |
| 21:11:12 | chrisjj | You suggested this black screen is hiding a panic, but we don't know if it is. A panic counter would answer that. |
| 21:11:35 | chrisjj | However your blinking LED will answer it. |
| 21:11:49 | [Saint] | If you PANIC, there's no guarantee you can iterate the counter. |
| 21:11:53 | [Saint] | It's irrelevant. |
| 21:11:54 | pamaury | the LED blinking would answer that. I think we first need to try to run the commit before the lcd_fix |
| 21:12:05 | [Saint] | You'd have to know you were going to PANIC before you did. |
| 21:12:11 | [Saint] | And if you knew that, you wouldn't... |
| 21:12:26 | pamaury | we know that some recentish builds panic, and that the lcd_fix didn't, so the natural commit to try is the parent of the lcd_fix |
| 21:13:14 | [Saint] | the guts of what I'm saying is that there's no way to reliable implement a PANIC counter, even in a world where it was a rational thing to do. |
| 21:13:16 | chrisjj | OK. |
| 21:14:09 | chrisjj | Though it seems the panic cause is /subsequent/ for the lCD fix, no? |
| 21:14:16 | | Join Bray90820_ [0] (~bray90820@173-25-204-30.client.mchsi.com) |
| 21:14:19 | chrisjj | s/for the/to the/ |
| 21:14:40 | | Quit Bray90820 (Ping timeout: 248 seconds) |
| 21:15:02 | | Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) |
| 21:18:41 | pamaury | chrisjj: I want to rule out the possibility that lcd_fix is actually fixing some crash (elsewhere than in the bootloader) |
| 21:19:01 | pamaury | when we confirm that, we can properly bisect between this commit (known working) and HEAD |
| 21:19:31 | | Quit Bray90820_ (Ping timeout: 240 seconds) |
| 21:20:23 | chrisjj | Are you thinking that lcd_fix could have fixed a crash /and/ then that fix got busted by a subsequent commit? |
| 21:23:50 | | Quit alexweissman (Remote host closed the connection) |
| 21:23:57 | | Join Bray90820 [0] (~bray90820@173-25-204-30.client.mchsi.com) |
| 21:25:39 | pamaury | that's unlikely but you are the one that want to rigorously test everything usually |
| 21:28:18 | [Saint] | you mean to say you're not interested in the frequency and distribution of a PANIC that shouldn't happen anyway? |
| 21:28:22 | [Saint] | ...how could you! |
| 21:28:35 | [Saint] | </s> |
| 21:29:06 | * | gevaerts objects to this meaningless capitalisation! |
| 21:29:15 | gevaerts | panic is not an acronym! |
| 21:29:37 | __builtin | Power ANd Interrupts Cancelled |
| 21:29:45 | __builtin | :P |
| 21:30:02 | pamaury | chrisjj: ok, so let's assume that cd8b3332 work (the parent of lcd_fix) |
| 21:30:21 | chrisjj | OK (I'd guess it will)... |
| 21:30:52 | pamaury | your tests show that 7e0820fe2 and be68b6a7b have a problem right ? |
| 21:30:57 | chrisjj | Right. |
| 21:31:47 | chrisjj | (I'm still the one who wants to test everything rigourously! :-) ) |
| 21:33:12 | chrisjj | (PAmauryNotInControl ;-) ) |
| 21:41:51 | | Quit parchd (Ping timeout: 245 seconds) |
| 21:47:38 | chrisjj | pamaury, I'll be happy to test the build before the lcd_fix, but I'm interested to know how this helps pinpoint this crash that's appeared /after/ lcd_fix. |
| 21:50:12 | pamaury | I'm looking at commits in the range cd8b3332..7e0820fe2 and none of them seems relevant for such a crash :-/ |
| 21:51:27 | pamaury | let me build 8e82839f and send it to you, just to be sure |
| 21:56:55 | pamaury | chrisjj: https://www.dropbox.com/s/05hu8qoo5tdp4aq/rockbox_zen_8e82839f.zip?dl=0 |
| 22:00 |
| 22:01:42 | chrisjj | Thanks. Running OK so far on Unit Q. |
| 22:02:56 | wodz | pamaury: Do you have any idea what icx_sound_refclk0_change() can do? |
| 22:02:59 | chrisjj | FWIW, this reverts the start-up flash pattern to that of lcd_fix. |
| 22:04:51 | chrisjj | In particular, the second appearance of the CREATIVE word again has a 1D screendoor effect in white. I.e. every second pixel row is solid white, with the CREATIVE word in white on black showing one the other rows. |
| 22:06:07 | chrisjj | The flash pattern differs between units which appear identical hardware-wise, so goodness only knows the cause. This somewhat erodes precision in testing. |
| 22:07:51 | | Join froggymana [0] (~frogs@unaffiliated/froggyman) |
| 22:08:02 | | Quit froggyman (Ping timeout: 248 seconds) |
| 22:08:06 | | Nick froggymana is now known as froggyman (~frogs@unaffiliated/froggyman) |
| 22:10:49 | [Saint] | My understanding is that there's at least two distinct LCDs used. |
| 22:11:58 | pamaury | wodz: no clue, but part of the icx sound driver is available in the linux code iirc |
| 22:13:00 | wodz | pamaury: anyway there is private ioctl which radio_test associate with SETFREQ which calls this function |
| 22:13:31 | pamaury | well you could try to look in the em1 manuals if it matches something |
| 22:14:13 | pamaury | maybe it enables/changes the frequency used by the tuner (some tuners don't use a crystal but let the soc generate the clock for them) |
| 22:15:04 | | Quit chrisb (Ping timeout: 240 seconds) |
| 22:15:05 | wodz | pamaury: e47x don't use em1 AFAIK but something newer |
| 22:16:36 | pamaury | yeah but it's the evolution, that can still be interesting |
| 22:18:02 | pamaury | wodz: in arch/arm/mach-emxx/include/mach/icx_sound_fchg.h there is the function you mention |
| 22:18:32 | pamaury | and it is implemented in sound/arm/icx-beep.c |
| 22:18:49 | wodz | pamaury: yeah, just reading it |
| 22:19:02 | pamaury | it's not really obvious from the code what it does :D |
| 22:20:52 | pamaury | the header has this comment: |
| 22:20:53 | pamaury | REFCLKO(MCLK) : 11.2896 [MHz] ะตะตะต default |
| 22:20:53 | pamaury | REFCLKO(MCLK) : 10.7987 [MHz] |
| 22:21:13 | pamaury | and it definitely looks tied to tuner |
| 22:22:28 | wodz | pamaury: does si407x output digital or analog signal? |
| 22:22:56 | wodz | ah, line level analog output |
| 22:23:30 | pamaury | analog |
| 22:23:32 | pamaury | afaik |
| 22:24:23 | wodz | RCLK like of tuner needs 32.768kHz signal - maybe thats related |
| 22:25:07 | chrisjj | pamaury: 8e82839f has done bad on Unit Q. Screen black, audio silent, keys unresponsive, LED off. Any other observations you need? |
| 22:26:03 | | Quit tchan (Ping timeout: 246 seconds) |
| 22:30:26 | pamaury | chrisjj: no, that's weird |
| 22:30:36 | wodz | pamaury: Here I documented somewhat my findings about radio interface https://www.rockbox.org/wiki/SonyNWLinuxTuner |
| 22:30:42 | pamaury | so let me rebuild 8e82839f+lcd_fix |
| 22:31:34 | | Quit robertd1 (Ping timeout: 240 seconds) |
| 22:32:07 | | Join robertd1 [0] (~root@201.242.214.237) |
| 22:35:27 | lebellium | wodz: may the FM tuner have some unused RDS capabilities? |
| 22:36:48 | pamaury | chrisjj: https://www.dropbox.com/s/mo8yf7go15nxt3c/rockbox_zen_8e82839f_lcdfix.zip?dl=0 |
| 22:37:06 | wodz | lebellium: That depends which version of si407x they used actually. If this is si4072 then no, if it is si4073 then it supports RDS. Judging from driver disasm I think it may be si4073 |
| 22:38:53 | lebellium | is it Si470x like the Sansa Clip or really Si407x? I can't find much about the latter |
| 22:38:56 | pamaury | wodz: it could be that this rclk0 is internally multiplied (in the soc) by say 3 |
| 22:38:59 | *** | Saving seen data "./dancer.seen" |
| 22:39:08 | pamaury | giving a very good estimate of the 32768kHz |
| 22:39:45 | wodz | lebellium: It is easy to check actually r1 has chip id field. |
| 22:40:24 | wodz | lebellium: what you mean about real Si407x? |
| 22:41:04 | lebellium | I mean is Si407x a typo? |
| 22:41:21 | lebellium | I can't find anything about Si4072 on google |
| 22:41:34 | lebellium | Si470x is famous |
| 22:42:47 | wodz | ah, yes a typo. si470x |
| 22:43:25 | lebellium | Ok |
| 22:43:28 | lebellium | clearer to me now |
| 22:43:38 | lebellium | so it may have the same tuner as the Clip Zip |
| 22:44:52 | wodz | pamaury: Do you know if there is a way to trigger running radio_test with OF actually? |
| 22:45:04 | lebellium | Sony never offered RDS in OF but I never knew if it was an hardware issue or only a software matter |
| 22:45:11 | wodz | pamaury: like debug menu or something |
| 22:45:22 | pamaury | wodz: my guess is that radio_test is run by the service menu (which is a sort of debug menu) |
| 22:45:33 | pamaury | you can reach via a magic key combination described in the service manual |
| 22:45:33 | wodz | pamaury: how to enter this? |
| 22:45:47 | pamaury | alternatively, the rockbox bootloader gives you an option to run it |
| 22:45:56 | pamaury | wodz: https://docs.sony.com/release/MDSM/989350201_SM.pdf |
| 22:46:13 | pamaury | manual list here: rockbox.org/wikiSonyNW |
| 22:46:26 | pamaury | chrisjj: can you test the build I listed above ? (https://www.dropbox.com/s/mo8yf7go15nxt3c/rockbox_zen_8e82839f_lcdfix.zip?dl=0) |
| 22:46:26 | * | wodz reading |
| 22:49:38 | wodz | Heh, I am too slow touching buttons. I need some practice :P |
| 22:49:47 | chrisjj | Doing... |
| 22:50:24 | lebellium | wodz: I've done it so much time on E580 and A10 that I almost know the key combo by heart now :D |
| 22:50:30 | lebellium | many times* |
| 22:51:07 | lebellium | note that there was a mistake in the key combo of the E580 service manual |
| 22:51:15 | lebellium | hopefully it's not wrong in the E470 one |
| 22:51:54 | wodz | haha, how fancy |
| 22:52:10 | wodz | floating bubbles made my day :P |
| 22:53:44 | chrisjj | pamaury: That latest (8e82839feM-170110) on Unit Q shows the same fail. |
| 22:54:55 | pamaury | chrisjj: unless I made a mistake, this is the same code as the original lcd_fix |
| 22:57:21 | | Quit wodz (Quit: Leaving) |
| 22:59:24 | chrisjj | How "same"? They aren't binary identical: http://i.imgur.com/LjZCo1j.png |
| 23:00 |
| 23:03:09 | pamaury | we don't have reproducible builds, so that's expected, but it's the same source code |
| 23:03:31 | pamaury | unless the original lcd_fix is not the commit that I think it is |
| 23:03:48 | pamaury | can you just try https://www.dropbox.com/s/mo8yf7go15nxt3c/rockbox_zen_8e82839f_lcdfix.zip?dl=0 and report ? |
| 23:07:28 | | Quit Senji (Ping timeout: 252 seconds) |
| 23:09:31 | | Join StaticAmbience_ [0] (~Quassel@host217-42-102-78.range217-42.btcentralplus.com) |
| 23:10:09 | | Quit StaticAmbience (Ping timeout: 246 seconds) |
| 23:11:41 | | Join StaticAmbience [0] (~Quassel@host86-148-184-110.range86-148.btcentralplus.com) |
| 23:13:44 | | Quit petur (Remote host closed the connection) |
| 23:13:48 | | Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) |
| 23:13:52 | | Quit StaticAmbience_ (Ping timeout: 258 seconds) |
| 23:16:24 | | Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) |
| 23:16:25 | chrisjj | OK... |
| 23:18:32 | chrisjj | Hang on. That's the same one. |
| 23:19:43 | chrisjj | I did try the build of your [21:46] and my [21:53] was the report (same fail). |
| 23:20:27 | | Quit holyheels (Read error: Connection reset by peer) |
| 23:21:17 | chrisjj | BTW, that 'original lcd_fix' (the first successful LCD fix I know) is Version: 45697a0bf-161212. |
| 23:22:52 | pamaury | chrisjj: unless I am mistaken, 45697a0bf is 8e82839f + lcd fix (as an extra commit). Thus 45697a0bf is the (or should be the) same as 8e82839f_lcdfix.zip |
| 23:23:06 | chrisjj | I hear you. |
| 23:23:12 | pamaury | now I am worried because you are claiming that 45697a0bf doesn't have this backlight sleep crash but 8e82839f_lcdfix does... |
| 23:23:49 | chrisjj | Your [22:03] asks me to try the build that I already tried from [21:46]. |
| 23:24:54 | pamaury | chrisjj: yes, I was unsure if you saw my message |
| 23:25:07 | pamaury | then I realized I miss your "Doing..." message |
| 23:25:12 | chrisjj | OK, got you. I always check your messages before I write mine :-) |
| 23:25:38 | chrisjj | Yes, I am claiming that 45697a0bf doesn't have this fail that 8e82839f_lcdfix does. |
| 23:27:02 | chrisjj | I wouldn't like to call it a backlight sleep crash because I don't know it is really that. I know only that the device goes to what appears to be power-off state (so obviously backlight is off) without good cause. |
| 23:27:39 | chrisjj | BTW, '45697a0bf doesn't have this fail' is based on hundreds of sessions on six devices. |
| 23:34:11 | pamaury | chrisjj: can you retest https://www.dropbox.com/s/i04b1468tci9ju1/rockbox_zen_lcd.zip?dl=0 |
| 23:34:16 | pamaury | this is the original lcd fix, afaik |
| 23:34:21 | chrisjj | OK. |
| 23:37:12 | chrisjj | (The zip is binary-identical to the original of 2016-12-12.) |
| 23:40:07 | chrisjj | Your [22:34] on Unit Q is has run OK for 52secs. Continuing... |
| 23:44:56 | | Quit StaticAmbience (Quit: No Ping reply in 180 seconds.) |
| 23:46:22 | | Join StaticAmbience [0] (~Quassel@host86-148-184-110.range86-148.btcentralplus.com) |
| 23:52:45 | | Part robertd1 |
| 23:53:39 | chrisjj | Now 14min. |
| 23:56:02 | | Quit xorly (Ping timeout: 256 seconds) |
| 23:56:25 | chrisjj | pamaury, I'm thinking angry watchdog is the only way we know of RB putting the device into power-off, barring power key press. |
| 23:57:32 | chrisjj | You've said *PANIC* screen disables the watchdog, meaning I presume disables the reset effect of angry watchdog. |
| 23:58:53 | | Quit chrisjj (Quit: Page closed) |
icon identifies that the person is a core developer (has commit access).