| 00:16:49 | braewoods | \o/ |
| 00:16:59 | braewoods | success. i erased and reprogrammed the boot sector with the same contents. |
| 00:17:04 | braewoods | WP# is not active. |
| 00:17:44 | | Quit TheSeven (Ping timeout: 240 seconds) |
| 00:18:25 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 00:29:13 | braewoods | well then |
| 00:29:20 | braewoods | after my latest commit is accepted... |
| 00:29:33 | braewoods | time to review the bootloader flashing again |
| 00:29:42 | braewoods | and then work up the courage to test it |
| 00:29:54 | braewoods | the main danger section |
| 00:30:50 | braewoods | i'll do the second erase/reprogram test tomorrow, see if the bootloader can be reprogrammed through RB |
| 00:40:19 | *** | Saving seen data "./dancer.seen" |
| 00:44:42 | braewoods | speachy: please approve g#2932 ? i tested it to ensure it is working. |
| 00:44:43 | fs-bluebot | Gerrit review #2932 at http://gerrit.rockbox.org/r/2932 : iriver_flash: rewrite how the flash commands wait for the ROM by James Buren |
| 01:00 |
| 01:30:29 | fs-bluebot | Build Server message: New build round started. Revision f65e410, 293 builds, 8 clients. |
| 01:31:38 | _bilgus | you knowit highlights him every time you do that right? I assume you've tested this by your statements but mark it next time and it flags em for review in gerrit |
| 01:37:10 | _bilgus | and I see you are already in the credits excellent |
| 01:37:11 | braewoods | Ph/ |
| 01:37:14 | braewoods | Oh. |
| 01:47:39 | _bilgus | mendel_munkis, I'm gonna optimize your patch a bit |
| 01:48:24 | mendel_munkis | it slows it down? |
| 01:52:13 | fs-bluebot | Build Server message: Build round completed after 1304 seconds. |
| 01:52:15 | fs-bluebot | Build Server message: Revision f65e410 result: All green |
| 01:53:01 | _bilgus | still building and testing whats here already but I can tell you what to do if you prefer |
| 01:53:17 | mendel_munkis | please do. |
| 01:55:54 | _bilgus | so instead of checking the flip bits every time instead make it a function pointer prototype (void) lcd_write_fn(int x y w h) at top of file static this prototype lcd_write_function = (*int default function of prototype) |
| 01:57:23 | _bilgus | then in update rect call it as (*lcd_write_fn)(x, y, w, h); |
| 01:57:59 | _bilgus | when you get to the place where flip bits is set then you can set lcd_write_fn to the flipped write fn |
| 01:58:00 | mendel_munkis | ah I wanted to be able to scale it up to two checks which would require four functions. |
| 01:58:16 | _bilgus | thats fine its still going to be faster |
| 01:58:20 | mendel_munkis | true. |
| 01:59:00 | _bilgus | but i'll test what you already have and give you whatever logs the test plugins spit out |
| 01:59:41 | mendel_munkis | interesting. 3b75f987 (it's not in gerrit) is meant to remove warnings but causes them on my machine. does it make sense to standardize using large format specifiers and cast up in debugf and logf? |
| 01:59:59 | _bilgus | ignore them |
| 02:00 |
| 02:00:39 | mendel_munkis | ignoreing warnings is not a habit I want to get into. |
| 02:00:44 | _bilgus | its because there are several different printf functions in flight or something along those lines |
| 02:01:04 | _bilgus | then dont run debugf and logf builds? |
| 02:01:14 | mendel_munkis | I thought it was because of word size on different machines. |
| 02:02:25 | _bilgus | don't think so its been like 6 years since I investigated it and it was the fact some printf specifiers didn't exist or were cast because they didn't exist |
| 02:02:40 | _bilgus | IIRC |
| 02:03:22 | braewoods | mendel_munkis: it's rare for the basic types to vary in size. long and long long are exceptions though. |
| 02:03:51 | mendel_munkis | guess what types I tend to see the warnings on. |
| 02:04:01 | mendel_munkis | long and long long |
| 02:04:11 | _bilgus | I mean feel free to go through and alter the stuff to ifdef around the weird shit and remember you aren't supposed to chanmge code operation in debug builds either or just ignore it when debugf and logf builds are enabled |
| 02:04:16 | braewoods | because long differs from 32 or 64 bits |
| 02:04:26 | braewoods | long long is generally 64 bits even on 32 bit platforms |
| 02:04:41 | braewoods | depends how it's used. |
| 02:04:44 | braewoods | if it's printf, easy fix. |
| 02:04:51 | braewoods | specify the right format for the size |
| 02:05:18 | mendel_munkis | the problem is that ifferent machine seem to want different formats. |
| 02:05:21 | _bilgus | and then get into a low mem target that doesn't implement and oops |
| 02:05:34 | braewoods | mendel_munkis: example? |
| 02:06:07 | braewoods | %ld for example is for "long int" |
| 02:06:08 | mendel_munkis | git commit 3b75f987 he changed the specifier to remove a warning. this causes a warning on my build machine |
| 02:06:27 | mendel_munkis | specificly %lx vs %x |
| 02:06:56 | _bilgus | we have no 64 bit machines do we? and who is he? |
| 02:07:15 | braewoods | long will vary.. it's usually the longest native type. |
| 02:07:25 | braewoods | it's equal to long long on most 64 bit targets i know of |
| 02:07:34 | braewoods | int on most 32 bit targets |
| 02:07:45 | mendel_munkis | Sebastian Leonhardt |
| 02:07:47 | _bilgus | long and int are = in 32 bit land |
| 02:08:02 | braewoods | one exception is win64. it's a weird one. |
| 02:08:08 | mendel_munkis | ok. |
| 02:08:10 | braewoods | long is 32 bit still |
| 02:08:16 | _bilgus | yeah I try to forgot about windows |
| 02:08:27 | mendel_munkis | I just knew i was seeing warnings every time i build a debug build. |
| 02:08:31 | braewoods | but why would that matter? the simulator? |
| 02:09:12 | _bilgus | thats the only place but we don't talk about fight i mean simulators |
| 02:09:34 | braewoods | huh |
| 02:09:41 | braewoods | the input is |
| 02:09:53 | braewoods | uint32_t |
| 02:10:03 | braewoods | so... why would it cause an error with... %x? |
| 02:10:13 | braewoods | err |
| 02:10:15 | braewoods | warning |
| 02:10:25 | braewoods | mendel_munkis: what's the warning you get? |
| 02:10:47 | braewoods | %x expects an unsigned int |
| 02:10:47 | mendel_munkis | warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] |
| 02:11:05 | mendel_munkis | apparently my gcc thinks uint32_t is a long |
| 02:11:14 | braewoods | what's the target platform? |
| 02:11:21 | mendel_munkis | fuze+ |
| 02:11:31 | braewoods | so you're generating code for fuze+? |
| 02:11:36 | mendel_munkis | yup |
| 02:11:37 | braewoods | not simulator or w/e? |
| 02:11:41 | mendel_munkis | nope |
| 02:12:00 | braewoods | oh, right. i guess they're technically different types. |
| 02:12:10 | braewoods | even if equivalent |
| 02:12:26 | braewoods | best solution is probably to cast it |
| 02:12:30 | braewoods | suppress the stupid warning |
| 02:12:38 | braewoods | we're not dealing with 64 bit types |
| 02:12:44 | mendel_munkis | thats what I was originally suggesting |
| 02:13:02 | mendel_munkis | i wasjust thinking of casting up instead of down. |
| 02:13:17 | braewoods | for that target it wouldn't really be any different |
| 02:13:19 | mendel_munkis | this is the edge case where casting down shouldn't lode data |
| 02:13:24 | braewoods | printf kinda sucks for the stdint.h types |
| 02:13:33 | braewoods | afaik it was never updated for proper support |
| 02:13:34 | rudi_s | The proper solution would be to use the appropriate string constants from inttypes.h (if supported by the target). |
| 02:13:42 | braewoods | that exists? |
| 02:14:10 | braewoods | huh. TIL. |
| 02:14:10 | rudi_s | Yeah, https://en.wikipedia.org/wiki/C_data_types#inttypes.h |
| 02:14:29 | braewoods | but wow is this ugly and hard to read. |
| 02:14:48 | rudi_s | Yeah, but it works and is correct. PRIu32 for uint32_t |
| 02:15:10 | braewoods | it's weird how size_t and ssize_t have printf formats but these do not |
| 02:15:11 | mendel_munkis | does our GCC support C99? |
| 02:15:18 | braewoods | yes it does. C99 is really old. |
| 02:16:54 | braewoods | mendel_munkis: this exploits a lesser known feature people tend to forget about. C compilers will concatenate string literals that are only separated by whitespace. |
| 02:17:01 | braewoods | "a" "b" => "ab" |
| 02:17:47 | rudi_s | Also without whitespace "a""b" -> "ab" |
| 02:18:10 | mendel_munkis | what exploits that? |
| 02:18:24 | rudi_s | PRI* from inttypes.h |
| 02:18:55 | rudi_s | PRIu32 is just the appropriate printf string for the target architecture, e.g "lu" or similar |
| 02:19:38 | _bilgus | and stack ovfl at head for test viewports that will need to be investigated |
| 02:19:46 | braewoods | mendel_munkis: it's used in advanced level CPP stuff. |
| 02:20:02 | braewoods | mendel_munkis: i also use it for breaking strings across multiple lines. it's good for readability. |
| 02:20:30 | mendel_munkis | I was trying to figure why it relevant to the conversation. I understand how it's usefull. |
| 02:20:35 | braewoods | oh. |
| 02:20:39 | braewoods | nevermind then. |
| 02:20:47 | mendel_munkis | no worries. thanks for the ideas |
| 02:20:58 | braewoods | the macros exploit this feature |
| 02:21:01 | braewoods | that's why i mentioned it |
| 02:21:08 | braewoods | otherwise they make no sense |
| 02:21:33 | braewoods | because it's the only way to construct string literals at compile time |
| 02:22:20 | braewoods | i've just never seen these before. |
| 02:22:32 | braewoods | i just assumed there was no proper solution. |
| 02:22:40 | braewoods | since i'd never seen it done in actual source code. |
| 02:26:10 | mendel_munkis | _bilgus: why *int not *(void)? |
| 02:26:22 | rudi_s | I think the reason why they haven't proper printf() formats is that size_t/ssize_t is part of the C language and uint32_t is only a typedef. And it means you're still compatible with "older" compilers because they don't need to learn the new format specs. |
| 02:26:45 | rudi_s | But it's annoying. |
| 02:26:49 | _bilgus | mendel context? |
| 02:26:52 | braewoods | rudi_s: size_t is still a typedef... it's not a builtin type. |
| 02:27:02 | braewoods | though moot point since it's included in stddef.h or so |
| 02:27:31 | mendel_munkis | you suggested doing lcd_write_function = (*int default function of prototype) at the top of the file |
| 02:27:37 | braewoods | i suspect it's just there since it was there in ANSI C |
| 02:27:39 | rudi_s | But the concept of size_t is defined in the language AFAIK. But yeah, I don't know the actual reason either. |
| 02:28:37 | _bilgus | oh sorry i was typing it on the fly itd be (void)(*fn)(int int int int) |
| 02:28:57 | mendel_munkis | also why are there HAVE_LCD_FLIP ifdefs in the fuzeplus lcd driver |
| 02:29:04 | mendel_munkis | ok. thank you |
| 02:29:26 | _bilgus | so you can take it out to see if its the issue |
| 02:29:34 | mendel_munkis | d'oh |
| 02:30:06 | _bilgus | but for god sakes don't go throwing them all over try to keep it contained |
| 02:30:45 | _bilgus | lol daggers for the eyes i tell ya |
| 02:40:21 | *** | No seen item changed, no save performed. |
| 02:48:49 | _bilgus | mendel looking at numbers we are down from a year a go probably mostly from the framebuffer patch |
| 02:48:52 | _bilgus | https://pastebin.com/unY6k4ee |
| 02:49:45 | _bilgus | but bad news the test fps plugin left weird artifacts and glitched rhythmically till finished unlike the broken main stuff |
| 02:49:51 | _bilgus | mendel_munkis, |
| 02:54:19 | mendel_munkis | huh just ran it with g#2909 as the parent and it looks fine. |
| 02:54:21 | fs-bluebot | Gerrit review #2909 at http://gerrit.rockbox.org/r/2909 : Whitespace cleanup on fb_viewport Rewrite by William Wilgus |
| 02:55:42 | _bilgus | 2909? |
| 02:55:57 | _bilgus | thats a ways back |
| 02:56:31 | _bilgus | maybe something to do with the test_vp crash then |
| 02:58:17 | mendel_munkis | yeah. (that was the head when I was working) when it's upside I think there may be a single line artifact at the side of the screen nearest the power button but otherwise everything looks normal. |
| 02:59:19 | _bilgus | ok I'll try to find that tomorrow then |
| 02:59:39 | mendel_munkis | I am rebuilding off of current head and will take a look. |
| 02:59:52 | _bilgus | it looks like it .5 fps slower after your patch whatever that means |
| 03:00 |
| 03:00:17 | mendel_munkis | it means it introduces a ngligable delay. |
| 03:01:54 | mendel_munkis | nope it still looks normal on my device after rebasing. |
| 03:02:03 | mendel_munkis | are you using a theme? |
| 03:06:45 | _bilgus | just cabbie |
| 03:07:02 | _bilgus | hmm thats odd |
| 03:07:55 | mendel_munkis | unless that square in the middle isn't meant to be there? |
| 03:08:02 | _bilgus | does test_viewport plugin crash? |
| 03:08:32 | mendel_munkis | yup |
| 03:08:50 | mendel_munkis | Stkov main |
| 03:11:20 | _bilgus | weirderstill then idk have to revisit once I get it right number are meaningless till then |
| 03:13:22 | mendel_munkis | I may have accidently fixed a bug while updating. maybe try patchset 3 |
| 03:13:36 | _bilgus | its probably clear_viewport not taking into account a smaller buffer though its supposed to |
| 03:24:42 | _bilgus | well it crash and hard locked on this try so I guess thats it for tonight |
| 03:38:18 | | Join petur [0] (~petur@78-21-55-218.access.telenet.be) |
| 03:38:18 | | Quit petur (Changing host) |
| 03:38:18 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 03:39:44 | | Join p3tur [0] (~petur@199.59.5.111) |
| 03:39:44 | | Quit p3tur (Changing host) |
| 03:39:44 | | Join p3tur [0] (~petur@rockbox/developer/petur) |
| 03:43:03 | | Quit petur (Ping timeout: 268 seconds) |
| 03:43:44 | edhelas | the latest build fixes all the issues I had on my iPod theme :) |
| 04:00 |
| 04:06:38 | | Nick p3tur is now known as petur (~petur@rockbox/developer/petur) |
| 04:40:22 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:15:34 | Airwave | _bilgus: f65e410497 fixes the theme issue I had! |
| 05:25:51 | wodz | speachy: Running wheezy in chroot on my laptop did the trick. I was able to debug bluez4 bt code with gdb and run it under valgrind. I am more or less ready to publish it somewhere. The missing part is rockbox UI, extension of crosscompile env to include dbus and glib and tweaks to link rockbox with thouse libs. |
| 05:30:18 | | Join johnb3 [0] (~johnb2@p5b3af6e4.dip0.t-ipconnect.de) |
| 05:33:59 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 06:00 |
| 06:19:43 | | Quit livvy (Ping timeout: 240 seconds) |
| 06:23:42 | | Join livvy [0] (~livvy@gateway/tor-sasl/livvy) |
| 06:33:44 | | Quit pamaury (Ping timeout: 240 seconds) |
| 06:40:24 | *** | Saving seen data "./dancer.seen" |
| 06:45:44 | | Join prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net) |
| 07:00 |
| 07:04:47 | speachy | wodz: glad to hear it! bilgus is theoretically working on the UI side. so on the x-compile stuff, I guess we need to add it? should it be part of the "toolchain" vs part of the build? |
| 07:05:22 | wodz | I'd extend toolchain. Easy stuff. |
| 07:17:05 | speachy | ok. just requires a bit of coordination with teh builders |
| 07:24:14 | speachy | the alsa template needs to be added as part of the filesystem patcher.. hopefully the OF doesn't blow it away |
| 07:24:51 | speachy | this is just audio, correct? no AVRCP (controls and metadata)? |
| 07:29:29 | wodz | speachy: I coded just audiosink part of a2dp. Controls should be easy to add. Don't know about metadata. |
| 07:34:53 | speachy | ok |
| 07:36:14 | speachy | do you remember the exact bluez and glib version we need to match what's on these things? |
| 07:36:38 | speachy | and dbus |
| 07:49:05 | wodz | speachy: My notes about crosscompiling http://paste.debian.net/1169069/ |
| 07:49:26 | wodz | speachy: I don't think we need bluez to crosscompile. All interactions are through DBus |
| 07:49:55 | speachy | ok |
| 07:50:43 | wodz | should be easy to intergrate in rockboxdev.sh |
| 07:52:51 | speachy | yep, I think so. |
| 08:00 |
| 08:03:25 | | Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) |
| 08:22:42 | | Join MrZeus_ [0] (~MrZeus@2a02:c7f:70d0:6a00:a0ce:6e20:7667:79ed) |
| 08:30:47 | wodz | speachy: wodz/9048a3e411bfe473f938e0214d0b0ee6">https://gist.github.com/wodz/9048a3e411bfe473f938e0214d0b0ee6 |
| 08:30:50 | | Quit Stanley00 (Remote host closed the connection) |
| 08:40:27 | *** | Saving seen data "./dancer.seen" |
| 08:41:20 | wodz | speachy: looks like bluez4 has very limited AVRCP capabilities |
| 08:41:50 | speachy | limited is better than none! |
| 08:45:46 | speachy | on glib now |
| 08:52:19 | | Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 09:00 |
| 09:08:32 | speachy | $%@#$ it's wanting aclocal-1.15 |
| 09:10:51 | wodz | speachy: dmesg says input: 80:C7:55:63:59:D6 as /devices/virtual/input/input2 |
| 09:11:12 | speachy | wodz: oooo, sweeet. :D |
| 09:11:21 | wodz | speachy: so somehow it handles playback controls present in headset |
| 09:13:02 | speachy | ok, our /dev/input/* poll code can't handle variable number of devices. but that's relatively easy to fix. |
| 09:29:37 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 09:31:05 | | Quit Rower () |
| 09:41:43 | wodz | speachy: Interestingly /dev/input/event2 is created BUT org.bluez.Input.GetProperties on the device returns it is not connected and Connect returns Error org.bluez.Error.NotSupported |
| 09:42:04 | wodz | speachy: bluez4 dbus api doesn't mention the possiblity of such error :P |
| 09:43:05 | speachy | interesting! |
| 09:45:41 | speachy | fortuantely there are a ton of cheap bluetooth protocol analyzers these days. |
| 09:57:36 | | Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) |
| 10:00 |
| 10:06:35 | speachy | wodz: libffi is installing its headers into $sysroot/usr/lib/libffi-3.2.1/include |
| 10:06:56 | speachy | despite −−includedir=/usr/include on the ./configure invocation |
| 10:07:15 | wodz | speachy: I know |
| 10:07:59 | wodz | ee wait, newer version should have it fixed |
| 10:18:20 | speachy | it's still broken in 3.2.1; it's installed to 'includesdir' and that's fixed at '$(libdir)/@PACKAGE_NAME@-@PACKAGE_VERSION@/include' |
| 10:18:45 | speachy | simplest solution is to just create a symlink or something. :/ |
| 10:23:17 | wodz | indeed |
| 10:23:40 | wodz | I think I simply moved the files |
| 10:25:47 | wodz | speachy: https://github.com/libffi/libffi/issues/459 |
| 10:25:57 | wodz | speachy: It states issue is fixed |
| 10:26:50 | speachy | wodz: it's certianly fixed in v3.3 |
| 10:27:17 | speachy | but anyway. symlinked in the rbdev.sh script now, time to see if glib shits another brick |
| 10:28:46 | speachy | ok, it wants libelf too |
| 10:31:16 | wodz | how is that it didn't want it here? |
| 10:32:01 | speachy | ../../glib-2.46.2/gio/gresource-tool.c:32:20: fatal error: libelf.h: No such file or directory |
| 10:32:47 | speachy | (re-trying with 2.46.1) |
| 10:33:39 | | Quit massiveH (Quit: Leaving) |
| 10:36:50 | speachy | yeah, same issue. |
| 10:39:23 | | Quit livvy (Ping timeout: 240 seconds) |
| 10:40:28 | *** | Saving seen data "./dancer.seen" |
| 10:46:26 | | Join johnb3 [0] (~johnb2@p5b3af6e4.dip0.t-ipconnect.de) |
| 10:56:13 | speachy | adding '−−disable-libelf' seems to be doing the trick. |
| 10:56:23 | speachy | I guess I had the libelf headers on my build system when you didn't. |
| 11:00 |
| 11:03:05 | speachy | dbus is blowing up because it wants expat |
| 11:05:39 | speachy | configure: error: Explicitly requested expat but expat not found |
| 11:13:20 | _bilgus | Haven't started the UI yet still fixing the last of the fires |
| 11:21:57 | braewoods | kinda interesting. i think the most difficult to repair iriver supported by RB is the 5/6G H10 |
| 11:22:26 | braewoods | why? it uses a hard to find battery type.. it's removeable though so you might be able to repair it with new cells or so. no idea how it is put together. |
| 11:22:47 | braewoods | and the HDD interface is very unusual. there's no adapters to upgrade the capacity. |
| 11:23:56 | _bilgus | < edhelas, Airwave > Awesome, thanks for testing! |
| 11:24:42 | edhelas | o/ |
| 11:27:08 | _bilgus | HA the build I replaced on the fuze+ while testing the lcd was almost to the day exactly a year ago |
| 11:27:24 | _bilgus | https://pastebin.com/unY6k4ee |
| 11:29:10 | _bilgus | the lcd functions are up to 30% slower as well |
| 11:29:27 | _bilgus | some of that for sure changing the vp code |
| 11:34:46 | speachy | @!^% dbus is still trying to use x11 |
| 11:37:40 | speachy | okay! got it finally. now for a full end-end build |
| 11:40:58 | braewoods | speachy: i did some research for the H300... there's two strategies i could use for embedding RB in ROM. it needs about 1.2MB for both images right now. the OF leaves 1.48MB unused between the bootloader region we use and the end of the OF |
| 11:41:11 | braewoods | so it could conceivably fit in the unused space |
| 11:41:24 | braewoods | but the H100 doesn't allow co-existence due to space limitations |
| 11:41:31 | braewoods | what do you think i should go for? |
| 11:42:04 | braewoods | the same strategy for the H300 would mean more space for RB |
| 11:42:08 | braewoods | but |
| 11:42:15 | braewoods | eh |
| 11:42:31 | speachy | I'd not bother trying to coexist. |
| 11:42:43 | braewoods | me too. ok. i'll keep same approach. |
| 11:42:51 | braewoods | to maintain behavior across ports. |
| 11:43:27 | braewoods | i can't see the RB core becoming close to 2MB though |
| 11:43:41 | braewoods | but i split up the address space so it can use the full rom space |
| 11:44:24 | braewoods | after i successfully boot the current BL, i'll need to test its existing features to see what work is left |
| 11:44:42 | braewoods | main thing i know to implement is support for booting RB from ROM/RAM like the H1x0 bootloader does |
| 11:46:31 | _bilgus | braewoods, If you start running out of room for your bootloader two options another bootstrap layer or see what can be discarded/pared from the bootloader side |
| 11:47:05 | _bilgus | I fear theres very little left to get rid of but maybe that device will be less demanding |
| 11:47:05 | speachy | wodz: g#2935 |
| 11:47:08 | fs-bluebot | Gerrit review #2935 at http://gerrit.rockbox.org/r/2935 : WIP: Add libraries to native MIPS toolchain to enable bluetooth by Solomon Peachy |
| 11:47:47 | _bilgus | so this puts the backend in so excited I might just put it at the front of my list |
| 12:00 |
| 12:05:07 | braewoods | _bilgus: existing one fits just fine for the H100.. i don't think space is a concern. |
| 12:05:12 | braewoods | i've got 10k to work with. |
| 12:05:24 | braewoods | but we'll see |
| 12:05:36 | braewoods | you also saved a ton of space with the printf strip down |
| 12:06:02 | braewoods | the H100/H300 bootloaders to date have used the last 64K of the ROM |
| 12:06:07 | braewoods | so that's what i intend to work around |
| 12:06:14 | braewoods | since changing the location now would be difficult |
| 12:06:33 | braewoods | and not much point in it if the bootloader still fits |
| 12:16:14 | | Quit pamaury (Ping timeout: 272 seconds) |
| 12:16:41 | speachy | wodz: when I try to launch it, I get: Discovering |
| 12:16:46 | speachy | Discovering : 1 |
| 12:16:50 | speachy | Segmentation fault |
| 12:33:25 | speachy | somewhere within g_main_loop_run(loop) |
| 12:34:08 | speachy | it leaves adapter_property_value_changed(), and goes boom. |
| 12:35:52 | mendel_munkis | bilgus: you said that patchset 2 on 2928 was .5 fps slower? |
| 12:36:08 | mendel_munkis | because I'm testing patchset 3 at .6 fps slower |
| 12:39:17 | mendel_munkis | never mind that. today my DD build is running at the same speed. |
| 12:40:29 | *** | Saving seen data "./dancer.seen" |
| 12:40:51 | edhelas | _bilgus what is the final goal of this theme/ui refactoring ? mostly to cleanup the code or is there some glitches/performances issues fixes involved ? |
| 12:46:24 | | Join p3tur [0] (~petur@rockbox/developer/petur) |
| 12:49:27 | speachy | edhelas: It started out as some bug/glitch hunting, and became a bit more along the way. |
| 12:50:11 | _bilgus | edhelas, first goal get it working right OFC after that I plan to rip out most of the custom implementations in the plugins |
| 12:50:23 | _bilgus | and finally expansion |
| 12:50:26 | | Quit MrZeus_ (Ping timeout: 264 seconds) |
| 12:50:39 | | Quit petur (Ping timeout: 268 seconds) |
| 12:51:13 | _bilgus | core was tied to screen width buffers its now able to handle any buffer |
| 12:58:54 | _bilgus | and performance nah but once right I'll try to optimize so its onlt 10-15% hit on lcd functions |
| 13:00 |
| 13:02:50 | mendel_munkis | bilgus: did you figure out why it was glitching on your machine? |
| 13:03:01 | _bilgus | mendel_munkis, between runs testing tends to bounce a bit, mostly true for anything doing multitasking of some sort |
| 13:03:17 | _bilgus | No I won't get back to it till tongiht |
| 13:03:24 | braewoods | _bilgus: so why did you trade performance away? |
| 13:03:59 | braewoods | in either case, each port's screen dimensions are fixed |
| 13:04:03 | braewoods | though they differ |
| 13:04:08 | _bilgus | I didn't but I'm not going to optimize till everything works PROPERLY |
| 13:04:13 | speachy | braewoods: I think folks tend to prefer glitch-free displays (and no crashing) over raw speed! |
| 13:04:21 | _bilgus | exactly |
| 13:04:38 | mendel_munkis | braewoods: bear in mind that runninga variation of head I am getting over 60 fps |
| 13:04:57 | mendel_munkis | speedis only important up to a certain point |
| 13:05:08 | speachy | some of the stuff I fixed in that trap/udf hunt was of the "WTF did this never crash before?" variety. |
| 13:05:30 | braewoods | _bilgus: i'm reminded of this whenever someone says "exactly": https://assets.amuniversal.com/554247b06d6301301d80001dd8b71c47 |
| 13:05:34 | _bilgus | people have kept trying to squeeze every performance for years and left a unmaintainable mess in places |
| 13:05:36 | braewoods | lol |
| 13:05:57 | _bilgus | love dilbert |
| 13:06:15 | speachy | plus abandoning support for the original Archos player and its charcell screen let us scrap some API choices. |
| 13:06:29 | * | _bilgus is loving that |
| 13:06:32 | | Join wodz_home [0] (~wodz@89-64-78-138.dynamic.chello.pl) |
| 13:06:46 | _bilgus | a lot of ugly just POOF |
| 13:07:01 | wodz_home | speachy: Lovely. g_main_loop_run(loop) is glib function :-) |
| 13:07:53 | speachy | ...which shouldn't be doing anything other than sleeping waiting for events... |
| 13:09:50 | wodz_home | yeah |
| 13:10:07 | speachy | even if I botched the cross compiled library somehow, it's actually running on the original. |
| 13:10:45 | wodz_home | speachy: Interesting thing is I tested this on my agptek and on chroot with wheezy on my laptop. |
| 13:10:50 | speachy | though now that I think about it, I'm actually running this on an ErosQ, which might not have the exact same versions of everything. |
| 13:11:34 | wodz_home | speachy: Are there update images available for ErosQ so I could look? |
| 13:11:45 | speachy | nope, libdbus 1.10.2 |
| 13:12:07 | speachy | wodz_home: there's a patched one sitting on d.r.o/bootloaders/aigo |
| 13:12:43 | wodz_home | speachy: Maybe I'll find some time and look into this |
| 13:13:20 | wodz_home | gtg |
| 13:13:24 | | Quit wodz_home (Quit: Leaving) |
| 13:18:02 | | Join MrZeus_ [0] (~MrZeus@2a02:c7f:70d0:6a00:a0ce:6e20:7667:79ed) |
| 13:59:07 | | Quit p3tur (Quit: Connection reset by beer) |
| 14:00 |
| 14:04:51 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 14:08:47 | | Join amiconn_ [0] (jens@rockbox/developer/amiconn) |
| 14:08:47 | | Nick amiconn is now known as Guest51137 (jens@rockbox/developer/amiconn) |
| 14:08:47 | | Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn) |
| 14:09:36 | | Join pixelma_ [0] (marianne@rockbox/staff/pixelma) |
| 14:09:37 | | Nick pixelma is now known as Guest93120 (marianne@rockbox/staff/pixelma) |
| 14:09:37 | | Nick pixelma_ is now known as pixelma (marianne@rockbox/staff/pixelma) |
| 14:10:04 | | Quit Guest51137 (Ping timeout: 240 seconds) |
| 14:10:05 | | Quit Guest93120 (Ping timeout: 240 seconds) |
| 14:26:50 | | Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) |
| 14:40:30 | *** | Saving seen data "./dancer.seen" |
| 14:44:00 | | Join Misanthropos [0] (~Misanthro@91.240.65.7) |
| 15:00 |
| 15:36:25 | braewoods | ok... confirmed that the H320 flash rom can be reprogrammed in 3 key areas |
| 15:36:41 | braewoods | so there's no WP to worry about. |
| 15:36:44 | braewoods | hw wise |
| 16:00 |
| 16:01:56 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 16:08:24 | braewoods | it seems in theory the iAudio and MPIO coldfire ports could also support boot from rom but |
| 16:08:28 | braewoods | they're so rare |
| 16:08:43 | braewoods | supporting them is probably impractical even if possible |
| 16:08:49 | braewoods | plus their OFs don't seem to care about CF cards |
| 16:09:06 | braewoods | it's mainly the H100 and H300 series that benefits from complete OF replacement |
| 16:09:23 | braewoods | since the OF is worthless if you want to upgrade your storage to flash |
| 16:09:56 | | Join b0hoon [0] (3e57ec73@62.87.236.115) |
| 16:12:13 | b0hoon | speachy: hi. something is wrong with builclient.pl after last update. The build dirs stay and my vms refuse to build because of free space on disk. |
| 16:13:19 | speachy | b0hoon: oh yuck. okay, I see it on mine too. |
| 16:13:42 | speachy | fixed one bug and broke something else |
| 16:14:42 | speachy | the basic problem is that the master process was nuking the slave/builder process before the slave had finished uploading things, causing wasted build rounds. |
| 16:15:58 | speachy | I moved the cleanup out of the master, into the slave process. What I think is happening now is that when a build is cancelled, the slave is killed outright so nothing cleans up the leftover. |
| 16:16:16 | | Quit vvrng (Ping timeout: 256 seconds) |
| 16:18:00 | b0hoon | so additional code. master should check if slave lives, and rm the dir? |
| 16:18:48 | speachy | ohwait, it's not removing the dir at all due to $CWD being in the wrong place. |
| 16:18:50 | speachy | oops. |
| 16:20:02 | speachy | and upon cancel it is cleaning up properly. |
| 16:20:07 | speachy | okay, I'll push this out in a few. |
| 16:20:36 | b0hoon | speachy: thanks |
| 16:20:57 | speachy | thanks for the report. I have oodles fo space on my builders so I'd have never noticed |
| 16:21:38 | b0hoon | np. i have vds set up as 50GB |
| 16:21:59 | speachy | okay, updated on the master, and the next build will push out an updated client. |
| 16:23:18 | b0hoon | allright. |
| 16:25:34 | | Part b0hoon |
| 16:30:49 | speachy | 8.2, 12, and 25GB of build-* dirs on my builders, yowch. |
| 16:31:24 | | Quit Rower (Ping timeout: 256 seconds) |
| 16:32:24 | | Quit MrZeus_ (Read error: Connection reset by peer) |
| 16:32:48 | | Join MrZeus_ [0] (~MrZeus@2a02:c7f:70d0:6a00:a0ce:6e20:7667:79ed) |
| 16:40:35 | *** | Saving seen data "./dancer.seen" |
| 16:41:54 | fs-bluebot | Build Server message: New build round started. Revision 96f82f8, 293 builds, 8 clients. |
| 16:57:19 | fs-bluebot | Build Server message: Build round completed after 924 seconds. |
| 16:57:26 | fs-bluebot | Build Server message: Revision 96f82f8 result: All green |
| 17:00 |
| 17:13:45 | | Quit mendel_munkis (Ping timeout: 240 seconds) |
| 17:16:51 | | Join mendel_munkis [0] (~mendelmun@ool-435680b7.dyn.optonline.net) |
| 17:17:44 | | Quit prof_wolfff (Ping timeout: 240 seconds) |
| 17:40:28 | braewoods | next change, g#2936 |
| 17:40:30 | fs-bluebot | Gerrit review #2936 at http://gerrit.rockbox.org/r/2936 : iriver_flash: revise cfi_read_id and cfi_get_flash_info by James Buren |
| 17:41:06 | braewoods | and tested on both H320 and H120 |
| 17:41:13 | braewoods | both are detected correctly |
| 17:52:07 | | Join ubervison [0] (~ubervison@2a02:aa12:b106:1b80:4978:337a:24bd:4bbc) |
| 17:52:22 | | Quit ubervison (Remote host closed the connection) |
| 17:52:44 | | Join ubervison [0] (~ubervison@2a02:aa12:b106:1b80:4978:337a:24bd:4bbc) |
| 18:00 |
| 18:02:39 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 18:07:50 | | Quit Stanley00 (Ping timeout: 264 seconds) |
| 18:40:36 | *** | Saving seen data "./dancer.seen" |
| 18:46:04 | _bilgus | braewoods, couple comments on your commit |
| 18:50:12 | _bilgus | first one you ignore I see it in the commit message second one though just for clarity won't even need a comment |
| 18:53:08 | braewoods | _bilgus: i think the parts i removed were from some ARCH code since those ROM chips were used in them. |
| 18:53:18 | | Quit lebellium (Quit: Leaving) |
| 18:56:41 | _bilgus | oh yeah quite possible |
| 18:58:05 | braewoods | _bilgus: done with the revisions i think? |
| 18:58:46 | braewoods | note the removed ones were all less than 1MiB |
| 18:59:00 | braewoods | and that's below what the H120 and H100 even supported |
| 18:59:03 | braewoods | o |
| 18:59:04 | braewoods | so |
| 18:59:13 | braewoods | they're not even useful for this plugin |
| 18:59:24 | braewoods | plus they were used in, as you said, removed targets |
| 18:59:52 | braewoods | https://www.rockbox.org/wiki/DataSheets |
| 19:00 |
| 19:00:02 | braewoods | SST SST39VF020 |
| 19:00:32 | braewoods | all arch devices i believe |
| 19:01:52 | fs-bluebot | Build Server message: New build round started. Revision f1bfbb5, 293 builds, 8 clients. |
| 19:02:04 | _bilgus | there ya go |
| 19:02:29 | braewoods | thanks |
| 19:02:55 | braewoods | speachy: i found some more SH references. decompressor/link.lds and apps/plugins/chessbox/chessbox.make |
| 19:03:08 | braewoods | firmware/decompressor/link.lds |
| 19:03:10 | braewoods | i mean |
| 19:04:11 | braewoods | _bilgus: i was reading in the m68k docs... apparently they do tolerate misaligned instructions but there's a performance penalty. |
| 19:04:27 | braewoods | but i can't see that being a problem in RB. GCC is supposed to take care of that. |
| 19:04:37 | braewoods | only maybe in raw ASM |
| 19:04:48 | _bilgus | we run into it on occasion |
| 19:05:04 | braewoods | ah. |
| 19:05:06 | _bilgus | my last one was arm in the buflib |
| 19:05:15 | braewoods | what's ARM d? |
| 19:05:16 | braewoods | do |
| 19:05:21 | | Join prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net) |
| 19:05:26 | braewoods | some architectures have no tolerance for it |
| 19:05:36 | braewoods | others just suffer performance penalty |
| 19:05:46 | _bilgus | talk about a hard to find bug, arm has none I think its on 4b |
| 19:06:03 | braewoods | interesting thing i found when i was revising the flash code |
| 19:06:16 | braewoods | the structure had to introduce padding to align the 32 bit field |
| 19:06:24 | braewoods | so my changes to it aren't using any more memory |
| 19:06:30 | braewoods | just using the space that used to go to padding |
| 19:06:45 | _bilgus | yeah I like wehn reordering structs get you free space |
| 19:07:07 | braewoods | GCC does have -Wpadded but that's probably better in more recent versions |
| 19:07:15 | braewoods | but for some structs you're stuck with it |
| 19:07:22 | _bilgus | but TBH plugins are memory constrained to a point but there is enough to afford to waste some on most targets |
| 19:07:35 | braewoods | yea. |
| 19:08:03 | braewoods | ideally you would arrange fields by size |
| 19:08:11 | braewoods | but that's tricky in C at times due to platform differences |
| 19:08:55 | speachy | braewoods: arm<v5 can't handle unaligned instructions or data. |
| 19:09:09 | braewoods | probably for the best |
| 19:09:10 | speachy | armv6 can handle it (via OS-level trap handler) |
| 19:09:17 | braewoods | in general you don't want that. |
| 19:09:23 | speachy | armv7 can handle it fine (with a penalty) |
| 19:09:36 | _bilgus | I don't think you'll run into differing sizes for the data types in this codebase |
| 19:09:48 | braewoods | i mainly ran into it when writing code for desktop Linux |
| 19:09:51 | _bilgus | or at least I haven't yet |
| 19:10:18 | _bilgus | I must say I prefer arm ASM over x86 and mips |
| 19:10:25 | braewoods | _bilgus: another random trivia. is the signedness of char always the same? |
| 19:11:00 | speachy | braewoods: wrt sh references, make a note of 'em please, I don't have the bandwdith to deal with them tonight. |
| 19:11:02 | _bilgus | on everything I have touched yes but its no guarantee AFAIK |
| 19:11:07 | braewoods | speachy: ok |
| 19:11:26 | braewoods | _bilgus: correct. the standard says this is implementation defined. |
| 19:11:33 | braewoods | x86 linux? it's signed. arm Linux? It's unsigned. |
| 19:12:26 | braewoods | it's why you should use cast to unsigned at times if you really intend it to be treated as an array of bytes |
| 19:12:39 | braewoods | there's only a few cases i can think of where the signedness is irrelevant |
| 19:13:13 | braewoods | e.g., copying the bytes as is |
| 19:13:40 | braewoods | most bitwise operations (shifts...) |
| 19:13:53 | braewoods | anyway |
| 19:14:00 | braewoods | just another trivia i've learned |
| 19:14:09 | braewoods | i was surprised it isn't defined |
| 19:14:19 | braewoods | while all other integer types default to signed |
| 19:14:34 | _bilgus | ok so the crash for test_viewports.rock is due to the small buffer I bet the font size is larger than the vp |
| 19:18:22 | fs-bluebot | Build Server message: Build round completed after 990 seconds. |
| 19:18:25 | fs-bluebot | Build Server message: Revision f1bfbb5 result: All green |
| 19:27:32 | | Quit prof_wolfff (Ping timeout: 272 seconds) |
| 19:27:41 | _bilgus | hey hey worked a treat |
| 19:29:49 | braewoods | next i'm going to consolidate the checksum algorithms. |
| 19:29:57 | braewoods | the same algorithm is used 3 times in this program. |
| 19:35:11 | | Quit pamaury (Ping timeout: 268 seconds) |
| 19:36:53 | braewoods | _bilgus: does RB implement memcmp? |
| 19:37:06 | braewoods | and yes it does |
| 19:37:34 | braewoods | on second thought |
| 19:37:47 | braewoods | direct memory comparison is better than checksums... but the firmware loader still needs that |
| 19:38:15 | braewoods | ok. different approach. |
| 19:39:50 | _bilgus | braewoods, have a look at plugins.h it doesn't have everything but most of what is implemented |
| 19:40:02 | braewoods | _bilgus: yea i see it. |
| 19:40:13 | braewoods | i just realize the people who wrote this originally reinvented memcmp in a few places |
| 19:40:19 | _bilgus | I pretty much have it open any time I'm doing a plugin |
| 19:40:41 | braewoods | if you're just doing byte by byte comparisons |
| 19:40:48 | braewoods | then memcmp is usually more optimized |
| 19:43:18 | Airwave | _bilgus: No problem, thanks for fixing! |
| 19:44:26 | Airwave | Only remaining UI issue I have that's popped up recently is that the top bar shows 10x the dB value that the settings menu does, e.g. if the settings menu says 40.5 dB, then top bar says 405 dB. Minor issue though. |
| 19:52:10 | _bilgus | I thought speachy fixed that? |
| 19:56:57 | speachy | yeah.. thought I fixed that. |
| 19:58:44 | speachy | will double-check |
| 20:00 |
| 20:00:35 | _bilgus | hmm puts_scroll will happily overflow buffers I should probably make it aware of the new fb stuff |
| 20:03:15 | | Quit genevino (Quit: Great minds discuss ideas. Average minds discuss events. Small minds discuss people.) |
| 20:03:29 | speachy | it appears to work on the x3ii (which has the same volume config key crap as the rocker) |
| 20:10:34 | fs-bluebot | Build Server message: New build round started. Revision 44023eb, 293 builds, 8 clients. |
| 20:11:40 | speachy | Airwave: it seems to work for me, but the build going now fixes the volume adjustment from within list context to respect to the hw step size. |
| 20:24:58 | Airwave | speachy: Okay, I'll try it out when it finishes building |
| 20:26:28 | fs-bluebot | Build Server message: Build round completed after 953 seconds. |
| 20:26:30 | fs-bluebot | Build Server message: Revision 44023eb result: All green |
| 20:26:54 | fs-bluebot | Build Server message: New build round started. Revision 07fcced, 293 builds, 8 clients. |
| 20:36:16 | braewoods | g#2937 |
| 20:36:18 | fs-bluebot | Gerrit review #2937 at http://gerrit.rockbox.org/r/2937 : iriver_flash: revise load_firmware_file function by James Buren |
| 20:36:40 | braewoods | tested as well |
| 20:39:13 | Airwave | speachy: Issue is still present in 44023eb |
| 20:39:44 | | Join fs-bluebot_ [0] (~fs-bluebo@55d45183.access.ecotel.net) |
| 20:40:28 | | Quit bluebrother (Disconnected by services) |
| 20:40:33 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
| 20:40:37 | *** | Saving seen data "./dancer.seen" |
| 20:40:57 | | Quit rogeliodh (Quit: The Lounge - https://thelounge.chat) |
| 20:41:37 | | Join rogeliodh [0] (~rogeliodh@rogeliodh.dev) |
| 20:41:45 | _bilgus | can't see it in cabbie but can in that theme from lebellium |
| 20:41:52 | | Quit fs-bluebot (Ping timeout: 246 seconds) |
| 20:55:01 | Airwave | Interesting |
| 20:55:45 | _bilgus | probably just a spacing issue |
| 20:56:05 | _bilgus | its probably set up for 2 digits |
| 20:57:54 | _bilgus | nope that was just a straight bug in the scrolling function |
| 20:58:56 | _bilgus | it just got covered up because it just wrote outside the vp to the framebuffer I imagine scrolling lines at end of screen would have crashed in the old code |
| 20:59:25 | _bilgus | Probably still a few more of these lurking |
| 21:00 |
| 21:01:08 | Airwave | Huh interesting |
| 21:07:25 | speachy | Airwave: I was able to recreate it on the X3ii, which led to my original fix. I don't know why it's not displaying correctly on the Rocker. |
| 21:09:33 | Airwave | How odd |
| 21:11:07 | speachy | yeah, uisim does its own thing wrt sound settings, can't use that. |
| 21:29:26 | | Quit MrZeus_ (Ping timeout: 264 seconds) |
| 21:33:34 | speachy | _bilgus: are you able to trigger the volume wonkiness? |
| 21:50:33 | | Quit Tsesarevich (Write error: Connection reset by peer) |
| 21:50:57 | | Join Tsesarevich [0] (Tsesarevic@fluxbuntu/founder/joejaxx) |
| 21:59:24 | _bilgus | on yesterdays version I've got something i'm working on atm but i'll investigate next |
| 22:00 |
| 22:09:48 | | Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) |
| 22:30:41 | braewoods | ok. that's enough for now. i'll wait for review. |
| 22:36:29 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 22:40:40 | *** | Saving seen data "./dancer.seen" |
| 23:00 |
| 23:24:27 | | Quit Stanley00 (Read error: Connection reset by peer) |
| 23:24:55 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 23:39:26 | | Quit Stanley00 (Read error: Connection reset by peer) |
| 23:39:56 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 23:53:38 | | Join Stanley|00 [0] (~stanley00@unaffiliated/stanley00) |
| 23:55:09 | | Join Stanley00_ [0] (~stanley00@unaffiliated/stanley00) |
| 23:57:16 | | Quit Stanley00 (Ping timeout: 268 seconds) |
| 23:58:24 | | Quit Stanley|00 (Ping timeout: 240 seconds) |
icon identifies that the person is a core developer (has commit access).