| 00:26:52 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:38:48 | | Quit othello7 (Ping timeout: 252 seconds) |
| 02:00 |
| 02:26:53 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:04:18 | | Quit jacobk (Ping timeout: 248 seconds) |
| 04:05:10 | | Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
| 04:26:57 | *** | Saving seen data "./dancer.seen" |
| 04:41:59 | | Quit jj5 (Ping timeout: 255 seconds) |
| 05:00 |
| 05:42:53 | | Quit 077AAUFXW (Ping timeout: 252 seconds) |
| 06:00 |
| 06:14:51 | | Join lebellium [0] (~lebellium@2a01cb0405d07f009cb1aad8c9d3c7da.ipv6.abo.wanadoo.fr) |
| 06:27:01 | *** | Saving seen data "./dancer.seen" |
| 06:33:23 | | Quit lebellium (Quit: Leaving) |
| 06:59:42 | | Join Xeha [0] (~Xeha@user/Xeha) |
| 07:00 |
| 07:37:44 | | Join jj5 [0] (~jj5@100.80.216.139.dynamic.dsl.dv.iprimus.net.au) |
| 08:00 |
| 08:09:53 | | Quit kugel_ (Ping timeout: 255 seconds) |
| 08:17:53 | | Join kugel [0] (~kugel@ip4d146a3a.dynamic.kabel-deutschland.de) |
| 08:27:02 | *** | Saving seen data "./dancer.seen" |
| 08:54:10 | speachy | I have another change cooking that should make it easier to set things up on a ipod5g/6g with an unformatted SSD. |
| 08:57:54 | speachy | we have to infer the virtual sector size from the filesystem, but when there is no filesystem, we end up reporting the storage device's logical sector size. |
| 09:00 |
| 09:33:50 | _bilgus_ | ah that probably relieve some of the difficulty for people setting them up |
| 09:37:26 | speachy | I'm thinking so. Unfortunately the pre-classic ipods still need the firmware/bootloader/partitioning set up in a special way, and itunes is the "best" way to set that way up. |
| 09:40:25 | _bilgus_ | I think i'm going to make way to just disable dirplay |
| 09:42:46 | _bilgus_ | currently the audio_play() stuff requires a playlist to play a single track with dirplay disabled it will play a track from the file browser then return to the filebrowser when complete |
| 09:44:18 | _bilgus_ | also add a fn audio_play_file() with a busy wait loop to get it loaded, that i'd like to expose to plugins |
| 09:45:28 | _bilgus_ | have it working in the sim but on device it doesn't yet |
| 10:00 |
| 10:27:05 | *** | No seen item changed, no save performed. |
| 10:31:47 | | Join paulk-bis [0] (~paulk@vpn-0-22.aquilenet.fr) |
| 10:31:50 | | Quit paulk (Read error: Connection reset by peer) |
| 11:00 |
| 11:27:13 | | Join chris_s [0] (~chris_s@2a09:bac2:2a60:2478::3a2:3c) |
| 11:48:15 | | Quit rogeliodh9101 (Quit: The Lounge - https://thelounge.chat) |
| 11:48:36 | | Join rogeliodh9101 [0] (~rogeliodh@rogeliodh.dev) |
| 12:00 |
| 12:12:03 | | Quit JanC (Ping timeout: 276 seconds) |
| 12:12:35 | | Join JanC [0] (~janc@user/janc) |
| 12:27:06 | *** | Saving seen data "./dancer.seen" |
| 12:54:34 | | Quit chris_s (Quit: Client closed) |
| 13:00 |
| 13:30:44 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 13:52:04 | | Quit JanC (Ping timeout: 245 seconds) |
| 13:53:35 | | Join JanC [0] (~janc@user/janc) |
| 14:00 |
| 14:27:07 | *** | Saving seen data "./dancer.seen" |
| 14:57:47 | | Join JanC_ [0] (~janc@user/janc) |
| 14:57:47 | | Nick JanC is now known as Guest3452 (~janc@user/janc) |
| 14:57:47 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
| 14:59:45 | | Quit Guest3452 (Ping timeout: 260 seconds) |
| 15:00 |
| 15:03:47 | | Quit hactar|ant (Quit: and it's always been the same / it's just a complicated game) |
| 15:18:26 | | Quit Natch (Read error: Connection reset by peer) |
| 15:44:05 | | Quit JanC (Ping timeout: 260 seconds) |
| 15:48:02 | | Join JanC [0] (~janc@user/janc) |
| 16:00 |
| 16:12:49 | | Quit JanC (Ping timeout: 252 seconds) |
| 16:27:10 | *** | Saving seen data "./dancer.seen" |
| 16:42:54 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 16:43:36 | dconrad | update: I got the hp/lo detect on the hw4 erosq working, and with that I believe that's all the hardware nominally working |
| 16:44:32 | dconrad | there might be some extra gpios to set but we're at a baseline of working |
| 16:44:55 | speachy | oh wow, that's awesome, didn't realize you got the button input working too |
| 16:45:04 | dconrad | and of course ironing out the kinks of the axp2101 |
| 16:45:32 | speachy | I think it's still wise to have everything in a single build, even though that complicates things for us (you) |
| 16:45:52 | dconrad | yeah, turns out if one button definition is wrong it can cause our button system to not work at all, I guess because it's now a button combo? |
| 16:45:54 | speachy | (otherwise, an endless series of "doesn't work" support posts...) |
| 16:46:17 | speachy | hmm? you mean some sort of matrix or is it an ADC thing? |
| 16:47:04 | | Join JanC [0] (~janc@user/janc) |
| 16:47:19 | dconrad | like, if we have a button defined as pb5 but it's actually pb6, then pb5 will be low all the time, and now our button system thinks it's being pressed all the time |
| 16:47:40 | dconrad | and of course none of the button mapping will match |
| 16:47:48 | dconrad | easily fixed though |
| 16:47:49 | speachy | ah, yeah. standard GPIO drama |
| 16:47:51 | dconrad | yup |
| 16:48:34 | dconrad | I'm with you, definitely want to keep it a single build |
| 16:49:00 | dconrad | Need to figure out how to dynamically change GPIO definitions though |
| 16:49:39 | speachy | two sets of functions? |
| 16:49:56 | speachy | each with their own definitions, based on the hw type passed in by the bootloader? |
| 16:50:37 | dconrad | I can't say I understand the system well enough to say yet haha |
| 16:50:58 | dconrad | but dynamically changing, for instance, the stuff in gpio-target.h |
| 16:51:43 | dconrad | no technical reason it can't be done, but the macros are magic to me still |
| 16:52:49 | speachy | eg DEFINE_GPIO(USB_DETECT_V4, GPIO_PD(3), GPIOF_INPUT) and you'd use USB_DETECT_V4 (vs V3 or whatever) elsewhere. |
| 16:53:28 | dconrad | yeah, exactly - but we're setting inputs/outputs/pullup resistors, etc., so need to figure out how to change the hardware registers for that stuff |
| 16:53:47 | dconrad | it might be that I can just straight up run that macro again...? |
| 16:54:03 | dconrad | like in an if statement |
| 16:54:05 | speachy | yep, amacrhonic did a good job making all of that stuff dynamic so you can just call the appropriate function with a different ID. |
| 16:54:21 | dconrad | oh, well that should be easy then! |
| 16:54:48 | speachy | DEFINE_GPIO() is just a static definition; it's not automagically used by anything; all references are explicit. |
| 16:55:15 | dconrad | I see, I thought it was getting pulled into something else |
| 16:56:35 | dconrad | will I need to chase down where all gpio-target.h is included then? (my understanding of nonstandard C is lackluster... can I somehow do an if statement within the header file...?) |
| 16:56:51 | speachy | hmm, may need to create multiple GPIO_PINGROUPs, one per variation. |
| 16:57:13 | speachy | since it does look like gpio_init() statically walks that entire table to set things up. |
| 16:57:34 | dconrad | but once we're past gpio_init() I can freely change things...? |
| 16:57:43 | speachy | I believe so. |
| 16:57:47 | dconrad | gotcha |
| 16:58:36 | speachy | basically if you make gpio_init() take an argument instead of using a static global table that should suffice. |
| 16:59:00 | speachy | will probably still need to special-case the erosq though. |
| 16:59:11 | dconrad | sure |
| 16:59:17 | dconrad | I'll give it a shot |
| 16:59:31 | speachy | C (and CPP) allows for all sorts of sins. :D |
| 16:59:50 | speachy | but all of this _is_ (generally) standard C99. |
| 17:00 |
| 17:00:36 | dconrad | yeah, there's just a lot of times I run into mysterious magic macros in rockbox it seems |
| 17:01:05 | dconrad | particularly the x1000 register system header files, I can't make heads or tails of those |
| 17:01:48 | dconrad | but I guess that's why it's abstracted away as a macro |
| 17:02:08 | speachy | yeah, that's the key to our portability/configurability. it's "standard" insofar as the constructs are all part of C99, but we do make heavy use of them for our conveneince/sanity |
| 17:03:02 | speachy | The gryrations I've gone through to add variable-size sector support in our storage/filesystem layers... and then make it all disableable at runtime for (near) zero penalty. :D |
| 17:03:31 | speachy | still need some ipod5g/6g guinea pigs to smoke test things. |
| 17:03:38 | * | speachy pokes the channel inqusitively. |
| 17:03:48 | dconrad | I've been keeping an eye on that, its quite the task to clean that mess up |
| 17:04:44 | dconrad | so good job, as long as it works haha |
| 17:06:03 | speachy | I do wish this effort was relevant to more modern platforms. |
| 17:07:13 | speachy | but it is leaving us well-positioned for eventual eXFAT and SDUC support. |
| 17:08:03 | speachy | the SD "layer" is effectively "every platform implements it from scratch in its SD controller driver." |
| 17:08:07 | * | dconrad gets visibly excited for exFAT |
| 17:08:48 | dconrad | anything that makes things "just work" more often |
| 17:08:59 | speachy | my goal is a common SD state/logic/etc layer with only the low-level I/O handled by the controller drivers. |
| 17:09:29 | speachy | ...once we have that, adding SDUC will be pretty easy. |
| 17:11:17 | speachy | exFAT is going to be a decent amount of work. But on ATA-based targets that boot off of said ATA device, exFAT (and GPT partitioning) will mean no more ability to boot/use the factory firmware. |
| 17:12:06 | speachy | I'm not sure if that will even be possible for any HDD-based ipod other than the 6g/7g. |
| 17:13:43 | | Join Everything [0] (~Everythin@178-133-144-57.mobile.vf-ua.net) |
| 17:15:00 | speachy | exFAT is also probably too large for some of the bootloaders. |
| 17:16:00 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 17:18:25 | speachy | I'm amazed the erosq family has continued to be produced (and improved) |
| 17:18:42 | speachy | ...too bad we can't get an in with their technical folks. |
| 17:18:43 | | Quit cstine (Quit: The Lounge - https://thelounge.chat) |
| 17:19:27 | | Join cstine [0] (~cstine@150.136.136.191) |
| 17:19:56 | | Join Natch [0] (~natch@c-92-34-7-158.bbcust.telenor.se) |
| 17:24:53 | dconrad | yeah I'm really surprised this player has lasted this long, and something like the m3k was killed so early |
| 17:25:22 | dconrad | I guess they can sell these in high enough quantity it makes sense |
| 17:25:29 | dconrad | and somehow they're not shovelware?? |
| 17:27:33 | dconrad | maybe they're catering to the hifi community in china primarily |
| 17:28:26 | speachy | I think the m3k was intended to be "cheap". But this one, being sold by at least three OEMs, has the demand/production to keep going... |
| 17:28:44 | speachy | (the m3k's factory firmware was... _awful_) |
| 17:29:19 | speachy | (as in it would destroy its own onboard flash pretty rapidly) |
| 17:29:31 | dconrad | yeah, but it was a "real" hifi brand, fiio |
| 17:29:51 | dconrad | I guess they didn't get the volume they wanted with it |
| 17:36:27 | dconrad | I do like that with the x1000 native ports, assuming no hardware failure of jacks/switches, they have the potential to work for a long time like the ipods |
| 17:36:42 | dconrad | since we /never/ do write operations on the nand |
| 17:37:07 | dconrad | if the sd card reaches its end of life just pop a new one in |
| 17:37:45 | dconrad | and the batteries are generic enough |
| 17:41:09 | speachy | yeah, since we won't touch the onboard flash at all during normal operation. The hosted stuff does do a little writing on each bootup (mounts the rootfs writeable) |
| 17:41:26 | speachy | but that's not something we could change and still allow booting into the OF. |
| 17:42:03 | speachy | the hardware itself is pretty physically robust too (not sure about the wheel in the long run) |
| 17:58:33 | | Quit dconrad (Remote host closed the connection) |
| 18:00 |
| 18:27:11 | *** | Saving seen data "./dancer.seen" |
| 18:48:23 | | Join massiveH [0] (~massiveH@2600:4040:a982:5400:655d:e0ba:3827:986c) |
| 18:54:50 | | Quit Everything (Quit: leaving) |
| 19:00 |
| 19:35:58 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 19:38:52 | | Quit dconrad (Remote host closed the connection) |
| 20:00 |
| 20:27:13 | *** | Saving seen data "./dancer.seen" |
| 20:40:01 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 21:00 |
| 21:21:18 | | Quit jacobk (Ping timeout: 276 seconds) |
| 22:00 |
| 22:03:22 | | Quit Moriar (Quit: Leaving.) |
| 22:07:28 | | Quit dconrad (Remote host closed the connection) |
| 22:27:17 | *** | Saving seen data "./dancer.seen" |
| 22:28:01 | | Quit othello7 (Quit: othello7) |
| 22:29:23 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 22:41:32 | | Join dconrad [0] (~dconrad@152.117.104.232) |
| 22:46:14 | | Quit dconrad (Ping timeout: 260 seconds) |
| 22:53:54 | | Quit othello7 (Remote host closed the connection) |
| 23:00 |
| 23:02:28 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 23:21:09 | | Quit othello7 (Remote host closed the connection) |
| 23:21:14 | | Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
| 23:22:58 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 23:58:09 | | Join dconrad [0] (~dconrad@152.117.104.232) |
icon identifies that the person is a core developer (has commit access).