| 00:00:04 | braewoods | wasn't that _bilgus's work? |
| 00:00:19 | braewoods | oh |
| 00:00:22 | braewoods | something else |
| 00:00:56 | braewoods | this_is_a_nick: ask speachy about it since they authored it |
| 00:01:13 | mendel_munkis | from a quick look it doesn't seem so. |
| 00:01:21 | | Quit TheSeven (Disconnected by services) |
| 00:01:31 | | Join [7] [0] (~quassel@rockbox/developer/TheSeven) |
| 00:01:42 | _bilgus | this_is_a_nick, actually would a hotkey work? |
| 00:02:13 | mendel_munkis | _bilgus: the rocker has otkeys? |
| 00:02:30 | _bilgus | wps has a hotkey |
| 00:02:49 | mendel_munkis | huh. it's cut off in the diff so I didn't notice. |
| 00:03:21 | mendel_munkis | but yeah if you don't want to recompile setting the hotkey is your best bet |
| 00:03:55 | _bilgus | this_is_a_nick, Settings>General Settings>Hotkey |
| 00:05:37 | this_is_a_nick | I don't have the Hotkey option. Is it available for the agptek rocker? |
| 00:06:05 | _bilgus | should be let me check |
| 00:06:18 | *** | Saving seen data "./dancer.seen" |
| 00:06:27 | this_is_a_nick | I have something called "Set Wps Context Plugin". is that it? |
| 00:07:06 | mendel_munkis | _bilgus: the keymap doesn't have a hotkey listed for the WPS |
| 00:07:31 | _bilgus | sure enough it doesn't have a wps hotkey |
| 00:08:08 | this_is_a_nick | I was thinking to add the pitchscreen to the shortcuts, but I couldn't figure out the syntax for the pitchscreen item. |
| 00:08:09 | _bilgus | ok this_is_a_nick ya got me lets wait for speachy lol |
| 00:11:36 | _bilgus | this_is_a_nick how about selecT+right |
| 00:11:57 | _bilgus | we can make that a hotkey |
| 00:12:41 | braewoods | hm. |
| 00:14:57 | braewoods | v3.4 to v3.5 looks promising |
| 00:15:01 | braewoods | let's test it |
| 00:16:55 | this_is_a_nick | does the rocker register 2 keys at once? I don't see any mapping that uses 2 keys. |
| 00:17:21 | _bilgus | one way to find out right? |
| 00:17:52 | braewoods | _bilgus: confirmed. something between v3.4 and v3.5 broke it |
| 00:18:12 | _bilgus | nice |
| 00:19:08 | braewoods | and wouldn't you know it... this was the release where the h300 code was restructured |
| 00:19:19 | braewoods | from being the h300 target to being the iriverh300 target |
| 00:19:36 | braewoods | probably something broke in the rework |
| 00:20:22 | braewoods | now to attempt a bisect to find when this started |
| 00:20:29 | braewoods | see if it works if i build the commit before it |
| 00:21:18 | braewoods | incidently these players don't seem brickable as long as you still have the OF installed |
| 00:21:38 | braewoods | so probably best to test new bootloaders on this setup |
| 00:22:44 | braewoods | _bilgus: feels like i'm doing ye old binary search |
| 00:22:58 | braewoods | take the half point, rebuild, see what changes |
| 00:23:04 | braewoods | or something |
| 00:23:18 | _bilgus | binary tree |
| 00:23:24 | _bilgus | voodoo |
| 00:29:19 | braewoods | _bilgus: i know git supports checking out Nth commit before the given one |
| 00:29:23 | braewoods | what about after? |
| 00:29:51 | braewoods | e.g., git checkout TAG~10 |
| 00:29:56 | braewoods | 10 commits before tag |
| 00:30:13 | mendel_munkis | braewoods: every commit has a single parent but can have multiple children therefore it is impossible |
| 00:30:21 | braewoods | i see. |
| 00:30:23 | braewoods | ok. |
| 00:34:58 | braewoods | _bilgus: i'm also assuming i may need to fix it multiple times. it's been 10 years, it may be more than one bug at work. |
| 00:36:38 | braewoods | one thing at a time though |
| 00:36:49 | braewoods | ok. first bisect on tools/configure |
| 00:36:53 | braewoods | let's see where it takes me |
| 00:37:37 | _bilgus | hard to guess at this point |
| 00:38:58 | braewoods | interesting. this one also fails to boot. |
| 00:39:12 | braewoods | so let's see where that leaves us... |
| 00:44:31 | braewoods | ~300 commits after 3.4 |
| 00:46:31 | braewoods | second bisect |
| 00:46:35 | braewoods | let's see where this takes me |
| 00:46:48 | braewoods | i did a bisect on bootloader/ firmware/ |
| 00:49:54 | braewoods | good thing i worked on iriver_flash. i couldn't see myself doing this without it. |
| 00:51:30 | braewoods | ok this bisect works |
| 00:51:39 | braewoods | time to mark the new range |
| 00:58:41 | | Quit this_is_a_nick (Remote host closed the connection) |
| 01:00 |
| 01:07:04 | _bilgus | so rocker doesn't let you do select and another key but volup+voldn works |
| 01:08:54 | braewoods | well i've narrowed it down to a range of 31 commits |
| 01:09:00 | braewoods | time to do a new bisect on that region |
| 01:18:54 | braewoods | maybe found something |
| 01:19:10 | braewoods | some changes to the iriver H300 LCD code |
| 01:19:43 | braewoods | time to try the commit right before it |
| 01:28:18 | _bilgus | huh build hook fail? |
| 01:28:43 | braewoods | ok. commit before boots. |
| 01:28:51 | braewoods | time to try the commit that looks like the bad one |
| 01:30:44 | braewoods | found the commit |
| 01:31:58 | braewoods | _bilgus: see anything odd in e13c6001332882291363bdf2f1155875439fe187 ? |
| 01:33:13 | _bilgus | have a link to it can't seem to jump to it |
| 01:34:21 | _bilgus | nm I got it |
| 01:34:44 | braewoods | https://github.com/Rockbox/rockbox/commit/e13c6001332882291363bdf2f1155875439fe187 |
| 01:36:26 | _bilgus | yeah so it was switched to dma for the lcd |
| 01:36:58 | _bilgus | maybe they are at different addresses or are they the same chip under the covers? |
| 01:37:09 | * | braewoods shrugs |
| 01:37:36 | braewoods | time to dig into it i guess |
| 01:37:46 | braewoods | the easiest is to revert it but |
| 01:38:04 | braewoods | perhaps better just to find out why it is broken |
| 01:38:31 | _bilgus | yes dont revert stuff that old |
| 01:38:41 | _bilgus | if def around maybe |
| 01:40:30 | | Join advcomp2019_ [0] (~advcomp20@65-131-145-101.sxct.qwest.net) |
| 01:40:30 | | Quit advcomp2019_ (Changing host) |
| 01:40:30 | | Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) |
| 01:43:59 | | Quit advcomp2019 (Ping timeout: 260 seconds) |
| 01:47:08 | _bilgus | mcf5249 do they both use this chip? |
| 01:47:50 | braewoods | that's the cpu |
| 01:47:52 | braewoods | and yes |
| 01:54:15 | braewoods | strangely this code seems to pose no problem to HEAD normal builds |
| 01:56:04 | braewoods | _bilgus: what's the icode section? I saw the commit removed ICODE_ATTR |
| 01:56:49 | _bilgus | too low level for me |
| 01:58:04 | braewoods | welp |
| 01:58:18 | braewoods | guess i'm going to be figuring this puppy out |
| 01:58:27 | braewoods | what exactly broke if nothing else |
| 01:58:51 | braewoods | honestly i'll probably just disable it in the BL since it doesn't seem to be an issue for the main firmware |
| 01:59:15 | _bilgus | thats a valid option |
| 01:59:31 | braewoods | indeed and i don't really know DMA either |
| 01:59:36 | braewoods | and the BL doesn't need to be super optimized |
| 01:59:43 | braewoods | it just has a job to do |
| 01:59:47 | _bilgus | try to do the same for the 120 too so they match ifpossible |
| 02:00 |
| 02:00:10 | braewoods | funny story |
| 02:00:15 | _bilgus | dma just does the increment and copy for you |
| 02:00:19 | braewoods | the H100 doesn't use DMA on the lcd |
| 02:00:34 | _bilgus | you set up a len and start address it handles the rest and signals when done |
| 02:00:43 | _bilgus | hmm. |
| 02:00:54 | _bilgus | isn't that handy |
| 02:01:10 | braewoods | that's probably why it still works |
| 02:01:21 | braewoods | maybe we should just remove DMA from the h300 |
| 02:04:29 | braewoods | seems the only serious user of DMA in the iriver coldfire ports is the h300 lcd |
| 02:05:02 | braewoods | so... it appears the bootloaders broke due to someone's overzealous optimizations |
| 02:05:25 | braewoods | DMA seems to be problematic on here |
| 02:05:30 | braewoods | so maybe it's best to disable it entirely |
| 02:05:38 | braewoods | at least for the LCD |
| 02:05:59 | braewoods | speachy: thoughts? |
| 02:06:12 | braewoods | anyway i'll look into it more tomorrow |
| 02:06:17 | braewoods | at least i narrowed it down |
| 02:06:22 | *** | Saving seen data "./dancer.seen" |
| 02:12:48 | braewoods | speachy: i see 2 solutions. disable DMA for all h300 LCD builds or only disable it for the bootloader. |
| 02:13:01 | braewoods | though i'm not sure what this optimization even gets us |
| 02:13:14 | braewoods | LCDs probably don't take that much cpu time |
| 02:13:55 | _bilgus | you would be amazed |
| 02:14:09 | _bilgus | if it works in rb i'd leave it |
| 02:14:21 | _bilgus | just remove from BL |
| 02:20:04 | | Join _bilgus_ [0] (~bilgus@2605:a000:1301:89f6:9df0:ddb9:3c1c:cc8f) |
| 02:20:58 | | Quit _bilgus (Read error: Connection reset by peer) |
| 02:21:21 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 02:28:39 | | Quit _bilgus_ (Remote host closed the connection) |
| 02:29:56 | | Join _bilgus [0] (~bilgus@2605:a000:1301:89f6:3480:14c5:505:7e2f) |
| 02:39:43 | | Quit _bilgus (Remote host closed the connection) |
| 02:41:26 | | Join _bilgus [0] (~bilgus@2605:a000:1301:89f6:3480:14c5:505:7e2f) |
| 03:00 |
| 03:31:48 | braewoods | ok test patch appears to work |
| 03:31:52 | braewoods | i'll refine it more tomorrow |
| 03:32:09 | braewoods | then i'll need to update it for head |
| 03:32:13 | braewoods | and test it as i go forward |
| 03:32:23 | braewoods | slow work but i don't want to take any chances |
| 03:33:03 | | Join prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net) |
| 03:33:13 | braewoods | i basically need to disable the DMA code on bootloaders |
| 03:33:32 | | Quit lonoxmont (Ping timeout: 272 seconds) |
| 03:33:51 | _bilgus | great that you found it though |
| 03:34:31 | braewoods | _bilgus: i'm probably going to create a DMA macro for this file that depends on BOOTLOADER value. otherwise it's rather unclear why it is there. |
| 03:34:44 | braewoods | and there's a ton of code to put in conditionals |
| 03:35:05 | braewoods | e.g., LCD_USE_DMA or something |
| 03:35:08 | _bilgus | or just give it its own sourcefile in the bootloader |
| 03:35:21 | braewoods | eh? |
| 03:35:37 | _bilgus | it should be as simple as including a .c file by the same name as the .h and it'll pull it in |
| 03:35:52 | _bilgus | placed in the bootloaders/ path |
| 03:36:18 | braewoods | isn't that a problem for long term maintenance? |
| 03:36:36 | braewoods | you seem to be advocating for copy pasta? |
| 03:36:57 | _bilgus | versus if defs or a broken implementation? |
| 03:37:42 | | Quit prof_wolfff (Ping timeout: 258 seconds) |
| 03:37:55 | braewoods | how is it better than ifdefs? |
| 03:38:14 | _bilgus | its at least solidly separate |
| 03:38:51 | braewoods | true |
| 03:38:57 | braewoods | just code duplication and all |
| 03:39:03 | _bilgus | if you have tons of ifdefs then split it in two within the same file same thing but in the same file I guess |
| 03:39:17 | | Join petur [0] (~petur@199.59.5.11) |
| 03:39:17 | | Quit petur (Changing host) |
| 03:39:17 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 03:39:19 | _bilgus | ifdefs make the code so damn hard to follow |
| 03:39:34 | braewoods | yet often necessary |
| 03:39:43 | | Join lonoxmont [0] (~lonoxmont@024-180-058-254.res.spectrum.com) |
| 03:40:39 | braewoods | i'll see what i can cook up |
| 03:40:53 | braewoods | it seems to be fine on the regular rockbox so |
| 03:40:58 | braewoods | i guess it should keep the DMA code for that. |
| 03:41:04 | _bilgus | see I can see dma really coming in handy in transferring files |
| 03:41:21 | _bilgus | figure the cpu is free to do other things while waiting |
| 03:41:45 | braewoods | coldfire already uses 2 DMA channels |
| 03:41:46 | _bilgus | but really we disable this kind of stuff in the bootloaders Ive touched |
| 03:42:08 | braewoods | i suspect the issue is it tries to setup the DMA stuff too early and it fucks stuff up |
| 03:42:14 | _bilgus | granted they are extremely space constrained but still |
| 03:42:49 | braewoods | bootloaders are running very early after all |
| 03:43:27 | braewoods | it messes with the interrupt vectors to install DMA3 |
| 03:43:35 | braewoods | so maybe that's no buena in the bootloader |
| 03:43:45 | _bilgus | quite possible |
| 03:43:55 | _bilgus | or something not setup yet |
| 03:44:47 | braewoods | either way reliability matters more than speed in the bootloader |
| 03:45:30 | _bilgus | fosho |
| 03:45:50 | braewoods | bootloaders in my experience are the most fickle things i've ever worked with |
| 03:46:49 | braewoods | there was even a grub2 bug that made it hang on fairly recent intel atom boards |
| 03:47:03 | braewoods | they did some weird stuff in that board |
| 03:47:10 | braewoods | and they had to workaround the quirks or so to avoid the hang |
| 03:47:18 | braewoods | apollo lake is still a mess |
| 03:48:04 | _bilgus | well they go through that so you don't have to |
| 03:48:28 | braewoods | on the bright side grub2 is a late stage bootloader so it can be fixed |
| 03:48:34 | braewoods | no brick risk |
| 03:48:52 | _bilgus | lower you go the more it looks like voodoo.. |
| 03:49:02 | braewoods | though it's kinda funny... |
| 03:49:36 | braewoods | most linux bootloaders now have their own kernel so to speak |
| 03:49:40 | _bilgus | the bootloader hasn't been upgraded since 2006? |
| 03:49:47 | braewoods | which one? |
| 03:49:49 | braewoods | h300? |
| 03:49:51 | _bilgus | h33 |
| 03:49:53 | braewoods | correct |
| 03:50:00 | braewoods | last reports of it working were from 2008 or 2009 |
| 03:50:07 | braewoods | so i had to narrow it down |
| 03:50:13 | braewoods | it took like 20 or so builds |
| 03:50:47 | braewoods | but once i am able to build a working bootloader from HEAD |
| 03:50:56 | braewoods | i will be pushing the fixes |
| 03:51:14 | braewoods | then i can commence with my actual development |
| 03:51:20 | braewoods | but this was a showstopper i had to address first |
| 03:51:29 | _bilgus | welcome to the rabbit holes |
| 03:52:14 | braewoods | main problem with my quest to update these suckers is... |
| 03:52:34 | braewoods | the H100 bootloader is untestable due to how rare that player is. the H120 and H140 are far more common. |
| 03:52:44 | braewoods | but it is heavily related to the H120 |
| 03:52:46 | braewoods | so |
| 03:52:54 | braewoods | if the H120 works there's a pretty good chance the H100 does too |
| 03:54:42 | braewoods | i can see why |
| 04:00 |
| 04:06:25 | *** | Saving seen data "./dancer.seen" |
| 04:36:23 | | Quit kakaka (Ping timeout: 240 seconds) |
| 04:50:01 | | Join kakaka [0] (~koniu@gateway/tor-sasl/koniu) |
| 05:00 |
| 05:08:11 | | Quit Skyrider (Quit: ZNC - 1.6.0 - http://znc.in) |
| 05:17:07 | braewoods | _bilgus: joy. i'm going to have to do more bisecting. |
| 05:17:18 | braewoods | i've only scraped the tip of the iceberg |
| 05:30:10 | | Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) |
| 05:40:14 | braewoods | ok. testing again with my last patch for the first problem. |
| 05:40:25 | braewoods | then i get to jump ahead and see what happens |
| 05:59:56 | braewoods | ok. i traced it up to 3.7-final... all working... |
| 06:00 |
| 06:00:08 | braewoods | 3.8-final changes the toolchain |
| 06:00:16 | * | braewoods ponders. |
| 06:02:11 | braewoods | guess i'll upgrade to a newer VM base |
| 06:06:26 | *** | Saving seen data "./dancer.seen" |
| 06:19:28 | braewoods | heh. |
| 06:19:38 | braewoods | gentoo meme. so you like scrolling walls of text. |
| 06:25:27 | | Quit Stanley00 () |
| 06:31:32 | braewoods | v3.8-final works |
| 06:35:23 | braewoods | v3.9-final works |
| 06:37:03 | braewoods | v3.10-final works... yaw |
| 06:45:54 | braewoods | v3.11-final works somehow or other |
| 06:48:04 | braewoods | v3.12-final works... |
| 07:00 |
| 07:01:32 | braewoods | v3.13-final works |
| 07:02:10 | braewoods | now the biggest jump so far |
| 07:02:12 | braewoods | v3.14-final |
| 07:03:50 | braewoods | works. surprisingly. |
| 07:08:15 | braewoods | huh. v3.15-final works too with the patch applied |
| 07:11:22 | braewoods | so what else is responsible? |
| 07:11:24 | braewoods | hm |
| 07:20:22 | braewoods | going to test it on code before the toolchain upgrade |
| 07:23:38 | braewoods | check. |
| 07:23:48 | braewoods | well that's as far as i can go with this VM |
| 07:25:41 | | Quit S|h|a|w|n (Read error: Connection reset by peer) |
| 07:26:18 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 07:27:23 | | Join t0mato [0] (t0mato@gateway/vpn/mullvad/t0mato) |
| 07:31:50 | braewoods | going to see if i can reproduce it in a container |
| 07:45:50 | speachy | braewoods: good worl hunting that down, but I agree with bilgus that reverting lcd dma globally is not the way to proceed. |
| 07:46:37 | braewoods | speachy: indeed. i've trace it as far back as working to e91f89a410dc4639dbe78f392c11b2a44ff9036a with my current draft patch. |
| 07:47:10 | braewoods | now i just need to find out what commit broke it since then |
| 07:47:13 | speachy | my guess is that something the lcd dma code depends on isn't initialized yet −− perhaps something as basic as global interrupts. |
| 07:47:39 | braewoods | well if you have a better idea of how to fix it... my patch just disables it for the bootloader. |
| 07:47:45 | braewoods | but leaves it for the rest |
| 07:51:28 | speachy | the most likely culprit is the toolchain update |
| 07:51:50 | speachy | oh, just make sue you're re-running configure each time you jump forward. |
| 07:52:05 | braewoods | i am |
| 07:52:08 | braewoods | i clean up each time |
| 07:52:39 | braewoods | the other possibility is the LCD refactor for _bilgus is breaking it |
| 07:52:46 | braewoods | we'll see |
| 07:53:05 | braewoods | i'm trying a point before i started modifying H300 code in master |
| 07:55:53 | braewoods | ok need to build new toolchain |
| 07:58:29 | braewoods | while i'm at it i'll see if there's any traps in my bootloader |
| 08:00 |
| 08:02:26 | speachy | g#2965 is the next bit of PCM API exorcism |
| 08:05:27 | braewoods | speachy: good news. the toolchain is not at fault. |
| 08:06:01 | braewoods | next up... i'll checkout the commit right before the big LCD overhaul |
| 08:06:16 | speachy | did you every try using git-bisect? |
| 08:06:27 | *** | Saving seen data "./dancer.seen" |
| 08:06:49 | braewoods | speachy: yes. |
| 08:06:54 | braewoods | it's interesting. |
| 08:07:29 | braewoods | just seems difficult to use if you don't know what files to monitor... |
| 08:07:59 | speachy | if anything, it's simpler. |
| 08:08:14 | speachy | remember git operates on the entire tree. |
| 08:08:38 | speachy | give it a start point, and and end point, it'll do the binary search for you, all you have to do is tell it if the entire tree is "Good" or "Bad" |
| 08:08:59 | braewoods | i see |
| 08:09:15 | speachy | narrowing it down to a given file or subset might reduce the search speace but it still operates the same way |
| 08:11:01 | speachy | huh, bluebot's offline. |
| 08:13:31 | braewoods | on the bright side this did give me a lot of good testing for the BL flashing for the h300 |
| 08:13:41 | braewoods | so it was valuable in a sense |
| 08:16:49 | | Join prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net) |
| 08:22:35 | | Join fs-bluebot [0] (~fs-bluebo@55d44e28.access.ecotel.net) |
| 08:30:17 | | Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) |
| 08:32:47 | braewoods | speachy: found the breakage point. it's after the commit with the LCD overhaul. |
| 08:33:04 | braewoods | i'll do some digging to find out more about it |
| 08:41:25 | braewoods | last known working commit for the h300 bootloader with my patch... |
| 08:41:27 | braewoods | 12f3ed1699d6bef25bed90ba95cbcc1a6bb4934a |
| 08:46:29 | braewoods | joy. |
| 08:47:12 | braewoods | _bilgus: perhaps you have some ideas? it breaks somewhere between 12f3ed1699d6bef25bed90ba95cbcc1a6bb4934a and ada919fc1122c314b239212a40d15c5ab131becd |
| 08:55:49 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 09:00 |
| 09:07:00 | braewoods | decided to stage the fix for the first part |
| 09:07:15 | braewoods | g#2968 |
| 09:07:16 | fs-bluebot | Gerrit review #2968 at http://gerrit.rockbox.org/r/2968 : h300: fix one long-standing bootloader bug by James Buren |
| 09:27:08 | braewoods | best theory i have for now is the changes to FBADDR |
| 09:27:22 | braewoods | it involves 2 pointer dereferences whereas the old one didn't use any |
| 09:38:04 | braewoods | hm. |
| 09:38:08 | braewoods | looking at H120... |
| 09:38:24 | braewoods | its lcd update functions are marked with this ICODE_ATTR macro |
| 09:38:37 | braewoods | that old commit i partially undid? it removed that. |
| 09:38:48 | braewoods | i wonder if that is playing a part. |
| 09:39:05 | braewoods | but i can find no explaination for what the icode section does |
| 09:39:09 | braewoods | or what it is for |
| 09:39:40 | braewoods | speachy: do you have any idea what the ICODE_ATTR is used for? |
| 09:39:44 | braewoods | why it is important or isn't? |
| 09:42:39 | _bilgus | I'd start looking very closely what the screen size macro are doing |
| 09:43:30 | braewoods | _bilgus: which one? |
| 09:44:11 | _bilgus | the width and height wait it works as a firmware image but not in the bootloader? |
| 09:44:29 | braewoods | _bilgus: correct |
| 09:44:50 | braewoods | it has the same basic behavior as the DMA code i patched out for it |
| 09:44:56 | braewoods | a frozen white screen |
| 09:45:06 | _bilgus | lets have a look maybe its out of bounds and somehow doesn't carch it in the bootloader |
| 09:45:40 | braewoods | i'll try a few things myself |
| 09:45:46 | _bilgus | yeah thats odd maybe we made a faulty assumption, me and jens with the dma code |
| 09:45:57 | braewoods | i have one idea already |
| 09:46:13 | _bilgus | catch it, sorry sun is in my eyes |
| 09:46:16 | braewoods | _bilgus: but do you know what the ICODE_ATTR does? |
| 09:46:25 | braewoods | the icode section is not well defined |
| 09:46:33 | braewoods | i can find nothing about it anywhere |
| 09:47:17 | _bilgus | no thats lower level than I mess with frequently its either going to be stuff that needs fast ram or perhaps within a memory range' |
| 09:58:58 | _bilgus | braewoods, FIRST THING LINE 209 |
| 09:59:02 | _bilgus | oops |
| 09:59:06 | braewoods | ? |
| 09:59:23 | _bilgus | iriver h300.c |
| 09:59:27 | _bilgus | font_init(); |
| 09:59:39 | _bilgus | the font isn't set before init |
| 10:00 |
| 10:00:07 | _bilgus | should be FOR_NB_SCREENS(i) |
| 10:00:07 | _bilgus | global_status.font_id[i] = FONT_SYSFIXED; |
| 10:00:07 | _bilgus | font_init(); |
| 10:00:24 | _bilgus | then remove the lcd set font later on |
| 10:02:09 | braewoods | _bilgus: so what's the proposed solution? |
| 10:02:18 | _bilgus | ^ |
| 10:02:31 | braewoods | i'm confuse. |
| 10:02:34 | braewoods | confused |
| 10:03:03 | braewoods | FOR_NB_SCREENS(i) ? |
| 10:03:15 | _bilgus | sorry currently its font init then sets the font for the lcd should be the screens macro set the fonts then init |
| 10:03:48 | _bilgus | its a macro expands to for screen=0; screen < screens< screen++ |
| 10:04:09 | braewoods | _bilgus: one problem. the h120 bootloader does the same thing but it still works. |
| 10:04:39 | _bilgus | yeah but probably getting lucky its initd to 0 in icode attrib |
| 10:05:01 | braewoods | ok. i'll try it your way. |
| 10:05:08 | braewoods | where do we put this... |
| 10:05:44 | _bilgus | here i'll pastebin it for you |
| 10:06:22 | braewoods | the risk is low in any case |
| 10:06:28 | *** | No seen item changed, no save performed. |
| 10:06:40 | braewoods | but if this works then we should patch the other BL too |
| 10:06:56 | | Join MrZeus [0] (~MrZeus@2a02:c7f:70d0:6a00:519d:4ff6:24c7:b643) |
| 10:07:34 | _bilgus | https://pastebin.com/ChyYuSCH |
| 10:07:40 | _bilgus | just copy pasta |
| 10:11:38 | | Quit bonfire (Remote host closed the connection) |
| 10:11:43 | braewoods | erm |
| 10:11:43 | _bilgus | next i'd try removing the stuff for the remote lcd just to narrow it down |
| 10:11:55 | braewoods | is this even intended for bootloader use? |
| 10:11:56 | | Join bonfire [0] (~bonfire@c-24-2-109-9.hsd1.ut.comcast.net) |
| 10:12:04 | braewoods | it's defined in an apps header |
| 10:12:17 | _bilgus | yes it should work but let me look a little closer |
| 10:14:27 | _bilgus | no you are right they all do it.. |
| 10:15:04 | _bilgus | I figured smoking gun removing from initialized ram |
| 10:15:30 | _bilgus | thats probably what it'll end up being my guess |
| 10:16:25 | _bilgus | huh font init also brings in buflib |
| 10:17:42 | | Quit michaelni (Remote host closed the connection) |
| 10:19:18 | _bilgus | so mainlcd is a colr 16 bit display that is pretty common code there but the remote lcd OTOH not so well tested |
| 10:21:33 | braewoods | i'll try taking it out. |
| 10:21:47 | braewoods | though |
| 10:22:08 | braewoods | i still don't know how it broke. |
| 10:23:34 | braewoods | _bilgus: that code you showed isn't going to help me... since it's not even part of the bootloader. |
| 10:23:42 | braewoods | the reference objects and such |
| 10:24:34 | _bilgus | https://pastebin.com/KKm8Akvv |
| 10:24:46 | _bilgus | there is with the remote display removed |
| 10:26:27 | _bilgus | I'll start looking at the font init stuff it pulls in bufferlib so pretty good candidate |
| 10:27:16 | braewoods | well i think i'd need your help for this regardless since the LCD rework was yours |
| 10:28:56 | _bilgus | yeah but I think its just a canary |
| 10:29:10 | _bilgus | once that works bet the dma code can go back in |
| 10:29:33 | braewoods | maybe it can, maybe it can't. that wasn't working prior to your changes. |
| 10:30:05 | _bilgus | true but this works in the fw but not in bootloader is an odd thing |
| 10:31:08 | braewoods | _bilgus: no change with that on head |
| 10:31:38 | braewoods | but incidently both breakages involve changes to the LCD code at some level |
| 10:32:27 | braewoods | ok. restored again from a bad bootloader. |
| 10:34:44 | braewoods | _bilgus: you got an H300 at all? |
| 10:35:34 | _bilgus | doh printf redirect still calls the remote lcd stuff can you try that again but remove HAVE_REMOTE_LCD & HAVE_REMOTE_LCD_TICKING from iriver300.h? |
| 10:35:56 | _bilgus | no itd be much easier if I did |
| 10:36:34 | braewoods | _bilgus: you live in US? |
| 10:37:05 | _bilgus | yeah midwest |
| 10:37:10 | braewoods | hm. |
| 10:37:23 | braewoods | i have a second H320 since I didn't know if i'd need a spare for my work. |
| 10:37:35 | braewoods | if it would help i can send it to you. |
| 10:38:42 | braewoods | when i got it the battery was dead so i had to replace it. |
| 10:38:46 | braewoods | but it works now |
| 10:39:06 | | Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) |
| 10:39:44 | _bilgus | last resort perhaps I still have a rocker that I need to send back |
| 10:40:01 | braewoods | ah. honestly i'd consider this a gift if you want to keep it. |
| 10:40:16 | _bilgus | although I'm pretty much done with needing physical hardware on that one now |
| 10:40:47 | braewoods | i can include an H100 remote too in pretty good condition |
| 10:40:49 | _bilgus | nah I have enough devices scattered as is |
| 10:40:52 | braewoods | ok. |
| 10:41:04 | braewoods | in tht case |
| 10:41:08 | braewoods | i'll try again.brb |
| 10:42:16 | speachy | _bilgus: another round of PCM exorcism: g#2965 |
| 10:42:18 | fs-bluebot | Gerrit review #2965 at http://gerrit.rockbox.org/r/2965 : pcm: Further cleanup of unused bits of the PCM ACPI: by Solomon Peachy |
| 10:43:48 | | Quit massiveH (Quit: Leaving) |
| 10:46:34 | braewoods | _bilgus: ok. i'm trying again. |
| 10:46:37 | braewoods | moment |
| 10:47:08 | braewoods | i'm testing against HEAD since it's not that far from the LCD changes |
| 10:47:59 | _bilgus | speachy nice, I assume there are users for the pcm peak stuff? |
| 10:48:05 | speachy | nope. |
| 10:48:31 | braewoods | _bilgus: still white screen |
| 10:48:40 | speachy | they've long since been migrated to the mixer_channel_peak stuff instead |
| 10:49:28 | _bilgus | even better :) |
| 10:49:53 | braewoods | i wonder if this is partly because the H300 is color while H12 is grayscale |
| 10:49:57 | | Quit emacsomancer (Quit: WeeChat 2.9) |
| 10:49:59 | braewoods | H120 |
| 10:50:00 | speachy | and several of the PCM drivers never actually implemented the pcm_peak stuff, heh. |
| 10:50:57 | _bilgus | braewoods, what I will do is go through the bootloader and make it work without any lcd and then we can try adding stuff back in till it breaks again |
| 10:51:02 | | Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net) |
| 10:51:13 | braewoods | _bilgus: ok. keep me apprised. |
| 10:51:40 | braewoods | i did find some stuff but maybe that workaround isn't necessary |
| 10:52:05 | _bilgus | will you be available this eve I have to head back to work but I'll be free in like 10 hrs from now |
| 10:52:15 | braewoods | _bilgus: probably |
| 10:53:00 | _bilgus | I'll try to get something easy with some ifdefs once we reach that point it'll hopefully just jump out |
| 10:53:20 | braewoods | we shouldn't need to modify crt0.S |
| 10:53:26 | braewoods | i'm pretty sure it is not at fault at all |
| 10:53:56 | braewoods | plus if it was malfunctioning more coldfire ports would have issue |
| 10:53:58 | braewoods | issues |
| 10:54:31 | _bilgus | it might still be figure if it was getting set to zero before and now its not perhaps someone forgot to init something important |
| 10:54:52 | braewoods | the code hasn't been modified in ages |
| 10:55:02 | braewoods | so... |
| 10:55:09 | speachy | this code specifically hasn't, but it depends on other code which has. |
| 10:55:24 | braewoods | either way |
| 10:55:27 | _bilgus | yeah since it last worked in 2006 and with a similar issue to boot |
| 10:55:52 | braewoods | i was able to make it work in a 2009 source code |
| 10:56:02 | braewoods | and then i found a commit that caused that white screen regression |
| 10:56:15 | braewoods | and tracing forward, that patch worked until you changed the LCD code |
| 10:56:20 | braewoods | in that recent commit |
| 10:56:32 | braewoods | no idea how it broke this time |
| 10:57:17 | braewoods | i was inclined just to play it safe since bootloaders are a pita to deug |
| 10:57:19 | braewoods | debug |
| 10:57:40 | braewoods | anyway my other plans are shelved until we find a solution for these issues |
| 10:57:52 | _bilgus | It doesn't seem like it currently but its actually the desired result |
| 10:57:56 | braewoods | either way the bootloader on H300 doesn't seem to like LCDs for some reason |
| 10:58:30 | _bilgus | we want these bugs to pop out early instead of silent corruption |
| 10:58:47 | braewoods | _bilgus: my offer stands if you find this too difficult to do remotely. i can ship you my other unit. |
| 10:59:10 | fs-bluebot | Build Server message: New build round started. Revision 388adff, 293 builds, 8 clients. |
| 10:59:29 | speachy | hmm, is the vbrfix plugin still relevant now that archos is gone? |
| 11:00 |
| 11:00:20 | _bilgus | might have to its so much easier to have it for hardware issues but we'll see what falls out first |
| 11:01:01 | _bilgus | no clue what it does speachy |
| 11:01:30 | speachy | "This plugin adds/fixes the Xing VBR header in an MP3 file." |
| 11:02:45 | speachy | "The Xing header contains information about the vbr stream, to calculate average bit rate and to more accurately fw/rew throught the stream" |
| 11:08:39 | braewoods | at least i can eliminate the toolchain |
| 11:08:57 | braewoods | the new coldfire one works fine for commits prior to the LCD overhaul |
| 11:09:16 | braewoods | last known one to work with my patch is |
| 11:09:31 | braewoods | the one immediately before the first big LCD patch |
| 11:09:35 | braewoods | the framebuffer commit |
| 11:10:06 | braewoods | _bilgus: how you want to do this? i can take bootloaders you've built and flash them. |
| 11:10:15 | _bilgus | braewoods, is that a clean vm? |
| 11:10:17 | braewoods | that way we can eliminate problems due to source differences |
| 11:10:44 | braewoods | _bilgus: define clean? i deleted the original toolchain prior to upgrading it. |
| 11:10:56 | braewoods | and i'm not using VMs for builds |
| 11:10:58 | braewoods | containers |
| 11:11:01 | _bilgus | ie no user info in it |
| 11:11:14 | braewoods | ah. no. just the unprivileged builder. |
| 11:11:29 | _bilgus | oh nm then I was gonna say upload it to a file host and I'd grab it but nm |
| 11:12:05 | _bilgus | I try to keep old stuff around for these things |
| 11:12:24 | braewoods | do you want me to give you a container that's setup for RB coldfire? |
| 11:12:32 | braewoods | access to one |
| 11:13:00 | _bilgus | nah I have my toolchain set up here and this nifty 2x faster laptop :p |
| 11:13:13 | braewoods | ok |
| 11:13:29 | braewoods | i've been building remotely on my LAN server and just copying the blobs over the network for testing |
| 11:13:29 | _bilgus | and my new rig should be here sometime soon so just better and better :D |
| 11:13:57 | braewoods | for the record, LXC containers work great for RB building |
| 11:14:08 | _bilgus | haha I almost did that with my rig at home but then the realization of slow internet speeds here tempered that expectation |
| 11:14:24 | braewoods | actually |
| 11:14:43 | braewoods | it's LAN only for me so i got gigabit speed. |
| 11:15:13 | braewoods | but yea, that's why i rent a dedicated server |
| 11:15:25 | braewoods | their bandwidth is ridiculiously cheap compared to what we get |
| 11:16:15 | braewoods | _bilgus: one of my thoughts was whether the FBADDR macro was derferencing a null ptr |
| 11:16:21 | braewoods | since i didn't know how it got initialized |
| 11:16:32 | braewoods | the original code was an address with arithmetic |
| 11:16:36 | braewoods | no dereferences |
| 11:16:55 | braewoods | but with no debugger |
| 11:17:01 | braewoods | all i got is wild guesses lol |
| 11:17:10 | braewoods | all i know is the LCD seems to be having trouble |
| 11:17:25 | braewoods | all the issues with the h300 BL point to the LCD |
| 11:18:05 | _bilgus | I'm sure you are right but why not elsewhere thats odd stuff |
| 11:19:07 | _bilgus | especially since it works in fw makes me think its a failure to init |
| 11:19:54 | speachy | eg the dma engine itself |
| 11:20:01 | speachy | those usually require independent init/setup |
| 11:20:41 | _bilgus | oh braewoods were you testing with the dma stuff still removed? |
| 11:20:59 | braewoods | _bilgus: yes. |
| 11:21:00 | speachy | yes he is |
| 11:21:07 | _bilgus | oh good lol |
| 11:21:37 | _bilgus | so i'll build it off that commmit you have up |
| 11:22:01 | braewoods | it was modified a bit to reflect changes to the LCD code for H300 |
| 11:22:16 | braewoods | though i don't know what broke it specifically |
| 11:22:24 | fs-bluebot | Build Server message: Build round completed after 1394 seconds. |
| 11:22:36 | fs-bluebot | Build Server message: Revision 388adff result: All green |
| 11:23:09 | braewoods | it can easily be flipped by changing the ifdefs |
| 11:23:11 | braewoods | if need be |
| 11:23:28 | fs-bluebot | Build Server message: New build round started. Revision b912ad5, 293 builds, 8 clients. |
| 11:23:36 | braewoods | for now i consider it a WIP because there's other issues it needs to be reconciled with |
| 11:24:38 | braewoods | _bilgus: though this is a lot less painful thanks to the iriver_flash changes i made |
| 11:24:49 | braewoods | iriver_flash is a lot faster than the OF is at flashing |
| 11:34:47 | _bilgus | braewoods, do I need to do anything special making the bootloader or just the bootloader.iriver file? |
| 11:35:12 | braewoods | i've been using the generated bootloader.iriver |
| 11:35:35 | braewoods | i added that support in a previous commit |
| 11:35:46 | braewoods | but you'll have to add it manually if working with something older |
| 11:35:52 | braewoods | i mean |
| 11:35:57 | braewoods | bootoutput to configure |
| 11:37:42 | _bilgus | https://www.mediafire.com/file/y2pzk30qfseuj3j/bootloader.iriver/file |
| 11:38:01 | _bilgus | its off your g#2968 |
| 11:38:04 | fs-bluebot | Gerrit review #2968 at http://gerrit.rockbox.org/r/2968 : h300: fix one long-standing bootloader bug by James Buren |
| 11:38:11 | braewoods | with what chnges? |
| 11:38:19 | _bilgus | so in this ver all lcd stuff is disabled |
| 11:38:27 | braewoods | ok. |
| 11:38:53 | braewoods | let me rebuild my rockbox |
| 11:39:19 | _bilgus | button prompts are intact so do try select or whatever keys normally if its not doing anything |
| 11:39:55 | braewoods | ok |
| 11:40:55 | braewoods | gimme a few minutes |
| 11:41:04 | braewoods | i have to rebuild RB for each BL build |
| 11:41:08 | braewoods | due to the lookup table |
| 11:42:09 | _bilgus | g#2969 |
| 11:42:11 | fs-bluebot | Gerrit review #2969 at http://gerrit.rockbox.org/r/2969 : h300 Boiotloader lcd WIP by William Wilgus |
| 11:42:52 | _bilgus | what lookup table seems bad to be tied in that manner |
| 11:44:01 | braewoods | _bilgus: tried it. white screen again. |
| 11:44:13 | braewoods | i used the rescue feature. |
| 11:44:23 | _bilgus | sur ethe backlight is on but it should boot |
| 11:44:31 | fs-bluebot | Build Server message: Build round completed after 1264 seconds. |
| 11:44:33 | fs-bluebot | Build Server message: Revision b912ad5 result: All green |
| 11:44:43 | braewoods | _bilgus: no progress. but if you insist I can wait longer. |
| 11:44:49 | braewoods | i'll reflash it |
| 11:45:15 | braewoods | _bilgus: oh, and, it's the table used by detect_valid_bootloader |
| 11:45:27 | braewoods | it's a safety feature but just gets in the way during development |
| 11:45:32 | _bilgus | got ya |
| 11:47:36 | braewoods | _bilgus: tried again. it's just hung. nothing happens like it should. |
| 11:47:48 | braewoods | it should boot to RB but i don't even hear the hard drive spinning |
| 11:50:20 | _bilgus | that worries me let me double check that I got all the lcd things |
| 11:51:25 | braewoods | on the bright side i don't think bricking is a serious worry due to the cookie checks |
| 11:51:45 | braewoods | i can hit reset and if i power it back on quickly enough |
| 11:51:51 | braewoods | it trips the cookie and boots the OF |
| 11:51:55 | _bilgus | thank goodness well I see one last spot the logf |
| 11:52:40 | braewoods | intended or not it wouldn't be feasible to explore this issue without it |
| 11:52:41 | _bilgus | oh nm its ifdefd out |
| 11:53:21 | braewoods | it's just weird how the BL behaves normally when my patch is applied but doesn't otherwise |
| 11:53:44 | | Quit petur (Quit: Connection reset by beer) |
| 11:53:50 | braewoods | _bilgus: would it help if we started from the last known good commit? |
| 11:54:24 | _bilgus | not yet it really worries me that pulling out the lcd code didn't fix it |
| 11:54:43 | braewoods | indeed |
| 11:55:08 | _bilgus | i'll try disabling everything not needed to boot |
| 11:55:21 | speachy | what about disabling LCD_REMOTE entirely for the bootloader? |
| 11:55:28 | braewoods | tried it |
| 11:55:38 | speachy | (eg maybe that relies on i2c or something else not initialized yet) |
| 11:55:39 | speachy | ah |
| 11:55:41 | braewoods | i commented it out and the build failed |
| 11:55:46 | braewoods | when i was doing it |
| 11:56:09 | braewoods | still strange that one optimization commit broke stuff |
| 11:56:15 | braewoods | why it did is beyond me |
| 11:56:23 | braewoods | all it did was add some mutex stuff and the like |
| 11:56:44 | speachy | oh! one thing to consider −− grep the bootloader elf dump for traps |
| 11:56:52 | braewoods | i did already |
| 11:56:56 | speachy | ok |
| 11:57:22 | speachy | so -fno-delete-null-pointer-checks is enabled? |
| 11:57:29 | speachy | (could easily lead to other bugs) |
| 11:57:32 | braewoods | you enabled it globally, remember? |
| 11:57:46 | speachy | I don't recall when it was added vs the commits you're examining |
| 11:57:49 | braewoods | although it isn't enabled in the last good commit |
| 11:58:03 | braewoods | either way no traps |
| 11:58:16 | braewoods | plus a lot of the BL's critical sections are in ASM |
| 12:00 |
| 12:01:09 | braewoods | oui. working with the ROM chips is simple compared to this. |
| 12:02:48 | _bilgus | https://www.mediafire.com/file/y2pzk30qfseuj3j/bootloader.iriver/file |
| 12:03:03 | braewoods | so what's different now? |
| 12:03:17 | _bilgus | new one I'm updating the gerrit commit as well |
| 12:03:26 | _bilgus | this disable the backlight completely |
| 12:03:44 | _bilgus | in addition to the lcd |
| 12:04:43 | braewoods | ok. moment. |
| 12:06:31 | *** | Saving seen data "./dancer.seen" |
| 12:06:51 | braewoods | that works |
| 12:06:55 | braewoods | though it's pitch black |
| 12:07:16 | _bilgus | oh? |
| 12:07:21 | braewoods | yea. |
| 12:07:25 | _bilgus | that is odd |
| 12:07:26 | braewoods | the screen is 100% dark |
| 12:07:32 | braewoods | until RB finishes loading |
| 12:07:48 | _bilgus | it looks to me like the assumption is that the device turns on the screen at boot |
| 12:08:17 | _bilgus | now why does that give issues with the lcd code .... |
| 12:08:30 | braewoods | well it may not matter but i did notice one difference from the 2006 bootloader and the functional ones i built |
| 12:08:41 | braewoods | the screen remains white in the V5 bootloader |
| 12:08:45 | _bilgus | ok so we will reenable the lcd coide but leave the backlight off |
| 12:08:45 | braewoods | the background |
| 12:09:11 | _bilgus | still wont see anything but if it works... |
| 12:09:21 | braewoods | but in the newer ones it |
| 12:09:35 | braewoods | is black |
| 12:09:39 | braewoods | dark background |
| 12:09:44 | braewoods | like black on white in the old |
| 12:09:48 | braewoods | and white on black in then ew |
| 12:09:52 | braewoods | kinda weird |
| 12:09:56 | braewoods | i thought just a color change |
| 12:10:02 | braewoods | but maybe it is significant? |
| 12:10:12 | braewoods | but it dates back to 2008 |
| 12:10:15 | braewoods | so not really new |
| 12:11:06 | braewoods | _bilgus: there's one major difference in this one; i heard the HD spin up |
| 12:11:15 | braewoods | and then after like 10s it booted finally |
| 12:11:19 | braewoods | screen came on |
| 12:11:26 | _bilgus | good lets hope this one does too |
| 12:11:44 | braewoods | brb |
| 12:12:02 | _bilgus | same link |
| 12:13:00 | speachy | there is interaction between backlight and lcd code |
| 12:13:26 | speachy | (eg baclkight off -> lcd disable) |
| 12:14:13 | speachy | this interaction was responsible for one of the wonkier bugs in the hosted linux stuff |
| 12:14:29 | _bilgus | sounds like a good guess |
| 12:14:30 | braewoods | brb |
| 12:14:35 | braewoods | waiting for trasnfer |
| 12:15:01 | braewoods | but yer right, i should probably disable the bootloader safeties for this |
| 12:15:06 | _bilgus | nbd I'll have to continue later on but this is PROGRESS! |
| 12:15:07 | braewoods | the one that requires recompiles |
| 12:15:09 | braewoods | anyway |
| 12:16:14 | braewoods | _bilgus: boots. |
| 12:16:21 | _bilgus | speachy I see it for hw_on and off i'll look into that a little closer |
| 12:16:28 | braewoods | the backlight seems to be responsible. |
| 12:16:39 | _bilgus | ok super excited lets see if I can get one more out |
| 12:16:40 | speachy | probably it's being enabled before the LCD code is ready |
| 12:17:08 | braewoods | if this works i'll try a build with the DMA workaround disabled |
| 12:17:25 | braewoods | it may have just been a race condition or so |
| 12:17:36 | braewoods | which is even more obvious in async code |
| 12:17:58 | braewoods | it's possible they're both the same bug |
| 12:18:05 | braewoods | just manifested differently |
| 12:20:42 | _bilgus | eh sorry gonna have to be a bit later I think its lcd_update but I'll need to work therough the math to see if its the area |
| 12:20:55 | braewoods | ok |
| 12:23:22 | _bilgus | PROIGRESS! |
| 12:31:31 | _bilgus | braewoods, last one for now same link |
| 12:31:47 | _bilgus | this one reenables everything but blocks the activation event |
| 12:35:42 | speachy | in other news, I have a PineCube now |
| 12:36:02 | speachy | haven't had time do anything other than unbox it, but yay! |
| 12:36:32 | speachy | (I have a couple of other boards still en route from Eastern Elbonia) |
| 12:37:55 | _bilgus | they do good work but I hear the air travel leaves something to be desired |
| 12:38:42 | speachy | given the estimated delivery dates, I think the delivery involves the back of a Yak. |
| 12:39:33 | _bilgus | http://www.engineeringwellness.com/wp-content/uploads/2015/05/elbonia0.png |
| 12:39:58 | * | speachy snickers. |
| 12:44:05 | | Quit Rower () |
| 12:46:38 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 12:46:54 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 12:51:37 | braewoods | _bilgus: ok. i'll try. |
| 12:55:14 | braewoods | _bilgus: no good |
| 12:55:18 | braewoods | same issue |
| 12:55:26 | braewoods | hangs, no spin up, etc |
| 12:58:41 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
| 13:00 |
| 13:00:43 | braewoods | TheLemonMan: so what's your special power? does lemonade come out of your nostrils on demand? |
| 13:01:58 | | Quit Rower (Ping timeout: 258 seconds) |
| 13:18:37 | | Quit atsampson (Ping timeout: 272 seconds) |
| 13:53:40 | | Join atsampson [0] (~ats@cartman.offog.org) |
| 13:56:11 | | Join amsomniac [0] (~nadya@2601:181:8300:4db::b45) |
| 14:00 |
| 14:06:34 | *** | Saving seen data "./dancer.seen" |
| 14:10:25 | | Quit ac_laptop (Ping timeout: 264 seconds) |
| 14:19:20 | | Join lebellium_ [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 14:20:50 | | Quit amsomniac (Quit: Leaving.) |
| 14:23:13 | | Quit lebellium (Ping timeout: 260 seconds) |
| 14:40:06 | | Quit _bilgus (Read error: Connection reset by peer) |
| 14:41:09 | | Join _bilgus [0] (~bilgus@2605:a000:1301:89f6:3480:14c5:505:7e2f) |
| 15:00 |
| 15:01:07 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 15:05:08 | mendel_munkis | speachy: do you know if there is any reason for the quickscreen to do a global settings apply? |
| 15:05:11 | mendel_munkis | sorry for repeating the question I just want to make sure I am not missing something |
| 15:14:20 | | Quit _bilgus (Read error: Connection reset by peer) |
| 15:19:44 | | Join _bilgus [0] (~bilgus@2605:a000:1301:89f6:3480:14c5:505:7e2f) |
| 15:24:43 | | Quit _bilgus (Read error: Connection reset by peer) |
| 15:35:30 | speachy | mendel_munkis: not offhand, but I confess to never looking at (or even using) the quickscreen functionality |
| 15:41:49 | mendel_munkis | alright. in that case I will commit and watch for complaints. |
| 16:00 |
| 16:06:38 | *** | Saving seen data "./dancer.seen" |
| 16:23:58 | fs-bluebot | Build Server message: New build round started. Revision 362f7a3, 293 builds, 8 clients. |
| 16:25:50 | speachy | mendel_munkis: if quickscreen can change settings (and still saves them unconditionally) then it does follow that itshould actually apply said changed settings? |
| 16:26:32 | speachy | Another way of looking at it; what's the problem that led to that patch? |
| 16:29:17 | mendel_munkis | the specific issue was quickscreen applying back/foreground colors which led to several plugins having messed up graphics |
| 16:30:51 | speachy | hmm. seems that the changed settings are being saved still though? |
| 16:30:51 | mendel_munkis | I am not sure if there are other settings that can cause similar difficulties, but from what I've seen every quickscreen settable setting is A special cased B has a callback or C is checked at use time |
| 16:30:56 | mendel_munkis | yes |
| 16:31:57 | mendel_munkis | meaning that if I change a setting the global setting will change just the current context doesn't have to worry about things changing from underneath |
| 16:43:13 | fs-bluebot | Build Server message: Build round completed after 1155 seconds. |
| 16:43:15 | fs-bluebot | Build Server message: Revision 362f7a3 result: All green |
| 16:49:14 | | Quit ac_laptop (Ping timeout: 264 seconds) |
| 17:00 |
| 17:31:14 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 17:56:05 | | Quit lebellium_ (Quit: Leaving) |
| 18:00 |
| 18:06:40 | *** | Saving seen data "./dancer.seen" |
| 18:07:16 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
| 18:09:03 | | Quit livvy (Ping timeout: 240 seconds) |
| 18:13:28 | | Join livvy [0] (~livvy@gateway/tor-sasl/livvy) |
| 18:24:28 | | Quit sh4 (Ping timeout: 260 seconds) |
| 18:24:59 | | Join sh4 [0] (shapeless@unaffiliated/sh4) |
| 19:00 |
| 19:02:19 | | Quit bluebrother (Disconnected by services) |
| 19:02:24 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
| 19:02:37 | | Join fs-bluebot_ [0] (~fs-bluebo@55d4bacc.access.ecotel.net) |
| 19:05:16 | | Quit fs-bluebot (Ping timeout: 256 seconds) |
| 19:48:54 | | Quit prof_wolfff (Ping timeout: 256 seconds) |
| 19:59:58 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 20:00 |
| 20:00:40 | | Join fs-bluebot [0] (~fs-bluebo@55d41ec8.access.ecotel.net) |
| 20:03:13 | | Quit bluebrother^ (Ping timeout: 246 seconds) |
| 20:03:18 | | Quit fs-bluebot_ (Ping timeout: 260 seconds) |
| 20:06:43 | *** | Saving seen data "./dancer.seen" |
| 20:11:55 | | Join _bilgus [0] (~bilgus@2605:a000:1301:89f6:3480:14c5:505:7e2f) |
| 20:16:50 | | Quit _bilgus (Ping timeout: 264 seconds) |
| 20:24:09 | | Join _bilgus [0] (~bilgus@2605:a000:1301:89f6:3480:14c5:505:7e2f) |
| 20:30:17 | | Join prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net) |
| 20:34:52 | | Quit ac_laptop (Ping timeout: 256 seconds) |
| 20:37:43 | _bilgus | braewoods, still around? https://app.mediafire.com/k80ixab17xng4 |
| 20:38:12 | _bilgus | that one does the lcd update with a for loop |
| 20:57:47 | | Quit MrZeus (Ping timeout: 272 seconds) |
| 20:57:48 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 21:00 |
| 21:08:17 | | Quit ac_laptop (Ping timeout: 265 seconds) |
| 21:59:33 | | Join amsomniac [0] (~nadya@c-75-68-250-81.hsd1.vt.comcast.net) |
| 22:00 |
| 22:02:02 | | Quit prof_wolfff (Ping timeout: 260 seconds) |
| 22:06:46 | *** | Saving seen data "./dancer.seen" |
| 22:57:59 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 23:00 |
| 23:48:02 | braewoods | _bilgus: sorry, back up. |
| 23:48:14 | braewoods | _bilgus: went sleep for awhile |
| 23:54:45 | | Join Huntereb [0] (~Huntereb@174.226.11.73) |
icon identifies that the person is a core developer (has commit access).