| 00:20:26 | | Join eevan [0] (~eevan@telesto.hot-chilli.net) |
| 00:20:50 | | Nick eevan is now known as Guest70559 (~eevan@telesto.hot-chilli.net) |
| 00:29:08 | | Quit koniu (Remote host closed the connection) |
| 00:29:37 | | Join koniu [0] (~koniu@gateway/tor-sasl/koniu) |
| 00:31:05 | | Quit ufdm_ (Quit: Leaving) |
| 00:40:46 | | Nick Guest70559 is now known as eevan (~eevan@telesto.hot-chilli.net) |
| 00:43:27 | | Quit massiveH (Quit: Leaving) |
| 00:49:59 | | Quit eevan (Remote host closed the connection) |
| 00:50:20 | | Join eevan [0] (~eevan@telesto.hot-chilli.net) |
| 00:54:07 | __builtin | hmm... a python port would be interesting |
| 00:54:18 | __builtin | what do you think, _bilgus_? |
| 00:58:21 | braewoods | fmlatghor: if i had to guess, spectrum internet hurt him. ;p |
| 01:00 |
| 01:21:48 | *** | Saving seen data "./dancer.seen" |
| 01:22:33 | | Quit jdarnley (Ping timeout: 256 seconds) |
| 01:25:47 | | Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be) |
| 03:00 |
| 03:01:49 | | Part eevan |
| 03:29:09 | | Join eevan [0] (~eevan@telesto.hot-chilli.net) |
| 03:29:32 | | Nick eevan is now known as Guest77754 (~eevan@telesto.hot-chilli.net) |
| 03:30:08 | | Nick Guest77754 is now known as eevan (~eevan@telesto.hot-chilli.net) |
| 03:34:50 | | Part eevan |
| 03:40:47 | braewoods | speachy: huh so mtp supports functional modes so it can change at the protocol level |
| 03:43:53 | braewoods | ok, i think i see a solution |
| 03:44:10 | braewoods | mtp doesn't require exclusive disk access |
| 03:44:32 | braewoods | but it should have a form of pseudo exclusive disk access when the initiator wants to perform operations |
| 03:44:56 | braewoods | so we need to lock the UI mode in this situation |
| 03:45:15 | braewoods | we don't need exclusive access like the MSC driver does |
| 03:45:20 | | Join eevan [0] (~eevan@telesto.hot-chilli.net) |
| 03:47:22 | braewoods | we can let the initiator switch functional modes if the situation allows |
| 03:47:25 | braewoods | or user can do so |
| 03:47:54 | braewoods | but we would have to start in exclusive mode since that's what MTP requires |
| 04:00 |
| 04:04:58 | | Quit J_Darnley (Ping timeout: 260 seconds) |
| 04:09:24 | braewoods | speachy: does rockbox have anything builtin for time formatting? |
| 04:09:53 | braewoods | i need something to support formatting and parsing for MTP |
| 04:09:57 | braewoods | if it already exists then great |
| 04:10:01 | | Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 04:10:02 | braewoods | if not i'll have to improvise |
| 04:21:52 | *** | Saving seen data "./dancer.seen" |
| 04:49:31 | | Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) |
| 05:00 |
| 05:09:08 | | Quit eevan (Remote host closed the connection) |
| 05:23:38 | braewoods | speachy: i noticed usb is a little endian bus yet RB does not appear to do anything to ensure the multibyte units it sends over USB are in this same byte order... |
| 05:23:56 | braewoods | i assume this means the usb software stack is unusable if the host cpu is big endian |
| 05:42:55 | braewoods | interesting |
| 05:43:07 | braewoods | only one port that might be impacted, if the OTG chip was supported |
| 05:43:15 | braewoods | the rest are all unfinished ports |
| 05:43:34 | braewoods | or have either no OTG chips or ones with no datasheet |
| 05:43:41 | braewoods | the iriver H300 is the only one that might be impacted |
| 05:44:01 | braewoods | so i'd need support for big endian as well |
| 05:44:08 | braewoods | not just the dual port problem |
| 05:44:36 | braewoods | from researching it appears this dual USB port problem is mostly a coldfire problem |
| 05:44:54 | braewoods | plus a few gigabeat F/X series |
| 05:57:14 | | Join eevan [0] (~eevan@telesto.hot-chilli.net) |
| 06:00 |
| 06:21:55 | *** | Saving seen data "./dancer.seen" |
| 06:22:44 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 07:00 |
| 07:09:50 | | Quit J_Darnley (Ping timeout: 256 seconds) |
| 07:11:07 | | Part eevan |
| 07:12:10 | | Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 07:18:25 | | Quit Barlow (Quit: leaving) |
| 08:00 |
| 08:00:16 | | Quit pamaury (Ping timeout: 256 seconds) |
| 08:01:33 | | Join pamaury [0] (~pamaury@rockbox/developer/pamaury) |
| 08:01:34 | braewoods | speachy: one question about usb driver buffers. MTP specifies only one party can be sending on either data line at a time |
| 08:02:02 | braewoods | so conceivably i could use a single buffer to read the IO stream into since the protocol doesn't allow flows to be fixed |
| 08:02:45 | braewoods | but would this cause problems? i don't know if the usb send/recv functions would read/write to the buffer when i didn't expect them to |
| 08:02:49 | braewoods | let alone finish using them |
| 08:22:00 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:00:42 | | Join Barlow [0] (~barlow@unaffiliated/barlow) |
| 09:16:11 | speachy | braewoods: remember that all USB stuff is host-initiated. so if there are multiple operations in flight, it's because the host did it. |
| 09:16:56 | braewoods | speachy: so my data will sit in a buffer until the host requests it? |
| 09:17:29 | speachy | given that you'll only have data in your buffer because the host asked for it, yes. |
| 09:18:10 | speachy | and yes, it will sit there staged until the host sends the "Read from the BULK OUT" endpoint. |
| 09:19:29 | braewoods | speachy: next question, if i call the send/recv function with a buffer larger than packet size, will the driver callback be called multiple times or what? |
| 09:20:18 | speachy | the low-level driver is supposed to handle that internally, only calling the upper level's callback once the transfer is completed (or failed) |
| 09:21:12 | braewoods | so |
| 09:21:31 | braewoods | once all the data has been sent or the read buffer partially filled? |
| 09:22:01 | braewoods | depends how much traffic is being generated on one end |
| 09:46:11 | | Quit koniu (Ping timeout: 268 seconds) |
| 09:50:02 | | Join koniu [0] (~koniu@gateway/tor-sasl/koniu) |
| 09:56:34 | speachy | when the logical operation is "complete" |
| 09:56:55 | speachy | each transfer has a defined size, known in advance by the sender. |
| 09:57:40 | braewoods | speachy: ok |
| 10:00 |
| 10:00:51 | braewoods | speachy: i also noticed usb_storage allocates a relatively large buffer, 64k on many targets, usually in the IRAM |
| 10:01:05 | braewoods | how much does that leave for something like MTP? |
| 10:01:57 | braewoods | i'm assuming i will need to allocate my io buffers in IRAM as well |
| 10:06:45 | | Quit Xeha (Ping timeout: 246 seconds) |
| 10:07:04 | speachy | you could always just re-use the usb_storage buffer. |
| 10:07:11 | speachy | it's not like both will be using it simultaneously |
| 10:07:29 | | Join Xeha [0] (~Xeha@unaffiliated/xeha) |
| 10:16:58 | | Join MrZeus_ [0] (~MrZeus@89.238.130.71) |
| 10:22:03 | *** | Saving seen data "./dancer.seen" |
| 10:27:48 | | Quit GeekShadow (Changing host) |
| 10:27:48 | | Join GeekShadow [0] (~antoine@82-64-164-139.subs.proxad.net) |
| 10:27:57 | | Quit GeekShadow (Changing host) |
| 10:27:57 | | Join GeekShadow [0] (~antoine@unaffiliated/geekshadow) |
| 10:36:53 | braewoods | speachy: that'll require refactoring |
| 10:36:59 | braewoods | speachy: it's currently private |
| 10:37:15 | speachy | doesn't matter right now anyway. IRAM is purely optimization (or for targets that need to DMA out of IRAM) |
| 10:38:04 | braewoods | in any case i'm planning to try to use MTP for other things than just file transfers |
| 10:38:24 | braewoods | i discovered you can do a lot with it |
| 10:38:45 | braewoods | it has some device properties i could tie to RB internals like the RTC |
| 10:39:00 | braewoods | in theory allowing the host to set the RTC |
| 10:39:17 | braewoods | that could be useful for synchronizing the RTC |
| 10:39:54 | braewoods | given the lack of networking that seems like a useful feature |
| 10:40:48 | edhelas | braewoods do you think that some optimizations can be done afterward regarding the rockbox db reindex and MTP ? |
| 10:41:08 | edhelas | basically if I transfer only a few new songs, to directly add them to the internal DB |
| 10:41:17 | braewoods | edhelas: possibly, i'm not sure. |
| 10:41:26 | braewoods | MTP does mean we can know exactly what was changed |
| 10:41:56 | braewoods | right now i'm just planning out how to roll it out |
| 10:42:04 | edhelas | okay :) |
| 10:42:11 | braewoods | the most promising reference implementation so far is one that was written for microcontrollers |
| 10:42:29 | braewoods | closest target to rockbox |
| 10:42:39 | braewoods | the rest run in Linux userspace |
| 10:43:20 | braewoods | in any case i'll worry about file IO performance later |
| 10:43:29 | braewoods | i don't know how slow it will be but |
| 10:43:43 | braewoods | i'll compare it to how slow UMS is at file copying |
| 10:43:54 | braewoods | best benchmark i can think of |
| 10:44:44 | braewoods | my main concern is integrating with dircache and all |
| 10:44:55 | braewoods | otherwise enumerating the files is going to be slow |
| 10:48:13 | braewoods | edhelas: i'm also exploring the possibility of having a secondary mode to MTP, some basic remote control possibilities for playback |
| 10:48:36 | braewoods | may as well make the most of this work |
| 10:48:56 | braewoods | it's easier to use MTP to add that extra stuff than implement something else |
| 11:00 |
| 11:04:09 | | Quit pamaury (Ping timeout: 246 seconds) |
| 11:21:56 | _bilgus_ | __builtin, I think micro python could be done given initiative, assuming enough ram |
| 11:24:47 | | Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) |
| 11:53:40 | | Quit Saijin_Naib (Disconnected by services) |
| 11:53:50 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-855f-b256-ad1a-e2c8.res6.spectrum.com) |
| 12:00 |
| 12:20:26 | | Quit Saijin_Naib (Ping timeout: 264 seconds) |
| 12:22:06 | *** | Saving seen data "./dancer.seen" |
| 12:27:22 | | Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 12:28:23 | | Quit J_Darnley (Ping timeout: 245 seconds) |
| 12:33:52 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-855f-b256-ad1a-e2c8.res6.spectrum.com) |
| 12:37:39 | speachy | oh, here's a thorny bug just reported. fs#13272 |
| 12:37:40 | fs-bluebot_ | https://www.rockbox.org/tracker/task/13272 xDuoo X3ii: sound setting for max-vol-limit is ignored (bugs, unconfirmed) |
| 12:38:23 | speachy | it's because the max-vol-limit expecte dB, but the hardware uses db/10. and major mismatch. |
| 12:38:38 | speachy | normal settings don't have a notion of decimalization. |
| 12:41:26 | | Quit Saijin_Naib (Disconnected by services) |
| 12:41:30 | | Join Saijin-Naib [0] (~Saijin_Na@2603-7081-1d05-7230-855f-b256-ad1a-e2c8.res6.spectrum.com) |
| 12:57:16 | fs-bluebot_ | Build Server message: New build round started. Revision 92a0ab8789, 293 builds, 9 clients. |
| 13:00 |
| 13:15:43 | fs-bluebot_ | Build Server message: Build round completed after 1107 seconds. |
| 13:15:52 | fs-bluebot_ | Build Server message: Revision 92a0ab8789 result: All green |
| 13:15:53 | fs-bluebot_ | Build Server message: New build round started. Revision 6b39e23074, 293 builds, 9 clients. |
| 13:19:10 | | Join johnb3 [0] (~johnb2@p4fd10236.dip0.t-ipconnect.de) |
| 13:26:26 | | Quit Saijin-Naib (Ping timeout: 264 seconds) |
| 13:28:06 | | Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 13:28:56 | | Quit jdarnley (Ping timeout: 256 seconds) |
| 13:30:21 | fs-bluebot_ | Build Server message: Build round completed after 870 seconds. |
| 13:30:23 | fs-bluebot_ | Build Server message: Revision 6b39e23074 result: All green |
| 13:30:24 | fs-bluebot_ | Build Server message: New build round started. Revision 99383a0f9b, 293 builds, 9 clients. |
| 13:46:46 | fs-bluebot_ | Build Server message: Build round completed after 981 seconds. |
| 13:46:48 | fs-bluebot_ | Build Server message: Revision 99383a0f9b result: All green |
| 13:57:42 | | Quit KalBot (Remote host closed the connection) |
| 13:57:47 | | Quit johnb3 (Ping timeout: 256 seconds) |
| 13:58:00 | | Join KalBot [0] (~matrixirc@connolly.tech) |
| 14:00 |
| 14:22:10 | *** | Saving seen data "./dancer.seen" |
| 14:31:28 | | Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) |
| 15:00 |
| 15:09:55 | | Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 15:12:01 | | Quit J_Darnley (Ping timeout: 256 seconds) |
| 16:00 |
| 16:05:57 | __builtin | we definitely have enough ram on most, if not all targets |
| 16:06:11 | __builtin | minus the tiny 2 or 8MB targets |
| 16:11:21 | | Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) |
| 16:12:23 | | Quit jdarnley (Ping timeout: 260 seconds) |
| 16:12:39 | | Join chrisb [0] (~chrisb@unaffiliated/chrisb) |
| 16:22:12 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:15:51 | | Quit cockroach (Quit: leaving) |
| 17:24:00 | chrisb | any way to repair the selector wheel on a sansa e200 ? |
| 17:24:49 | | Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de) |
| 17:28:39 | chris_s | I wanted to create a repo on Github to use the current version of Rockbox as a starting point for a few more opinionated changes I'd like to keep track of and potentially offer to others, like remove boot logo/shutdown message, simplify a lot of menu entries, turn off wrap around in menus, turn off reset when Hold function is activated, change the |
| 17:28:40 | chris_s | iPod keymap to more closely resemble the OF etc. Little details like that. |
| 17:28:40 | chris_s | So, mainly things that I'm guessing aren't fit for inclusion in the main Rockbox repo (although I intend to put anything up on Gerrit that I think has potential to be included). |
| 17:28:41 | DBUG | Enqueued KICK chris_s |
| 17:28:41 | chris_s | What's the proper etiquette here? Is it fine to clone −−bare the current version and upload to a new Github repo from that. I would leave pretty much everything intact, expect put a new name in the Readme and mention that it's a (barely) modified version of Rockbox, licensed under the same terms. I'm assuming it's fine that all of the contributors |
| 17:28:41 | chris_s | and git history would still appear in the new repo? |
| 17:28:42 | *** | Alert Mode level 1 |
| 17:28:42 | chris_s | I first thought about forking, but that doesn't seem to make much sense when the original repository is read-only and thus doesn't accept pull requests? |
| 17:38:13 | fmlatghor | chris_s: So do you want your changes to be accepted, or do you just want to make a fork? |
| 17:38:43 | *** | Alert Mode OFF |
| 17:40:02 | fmlatghor | It's licensed under gplv2, so it's fine if you fork it, you just have to keep it free software and keep credits/copyright of the original project. I don't see anything wrong doing that. If it's just for your own personal preferences, you don't _have_ to share it, but I get it if you want to. |
| 17:40:06 | | Join calebccff [0] (~calebconn@connolly.tech) |
| 17:40:06 | calebccff | chris_s: forking the readonly github mirror seems like the most sensible approach. If you want to propose patches you can just add the gerrit as a new remote and push them there. |
| 17:40:20 | chris_s | I think a lot of these changes are unlikely to be accepted but would still be useful to a subset of users (like myself) |
| 17:40:36 | fmlatghor | I see. |
| 17:40:47 | calebccff | I'd argue that if you're planning on making changes that you think improve the UX for you and potentially others, upstream would probably want those changes |
| 17:40:55 | chris_s | Yes, I've proposed patches in Gerrit and will continue to do so for things that have potential to be accepted |
| 17:41:52 | calebccff | There's some disconnect between "I'd like to make this changes to improve the experience" <-> "I don't think these changes will be accepted upstream so I won't bother preparing / submitting patches" |
| 17:44:53 | calebccff | Certainly stuff like disabling scroll wrapping and modifying the iPod key maps would be nice additions. I've noticed certainly some of the nuance of navigation on the iPod classic is lost because all iPods use the same bindings (it's just, CLICKWHEEL). |
| 17:45:04 | | Quit lebellium (Quit: Leaving) |
| 17:45:30 | chris_s | I guess there's no reason to not *also* upload my changes to Gerrit. It just seems like decisions like the iPod keymap have been made based on having a shared experience across different players which is not something I would want to focus on in my own build |
| 17:46:27 | chris_s | So I'd rather have the Menu button go up a level and return to the browser from the WPS when it'S pressed instead of going to the root menu |
| 17:49:18 | calebccff | chris_s: most of these things sound like they could just be added to the settings menu, you could add an API to support keymap profiles and then build in an OF vs Rockbox iPod profile and give the user an option to switch between them. Or not even go that far, and just add the option to make the menu button behave like it does in OF |
| 17:49:42 | calebccff | The former sounds like it would actually be a net-gain for RB, customisable controls would be awesome to have |
| 17:51:39 | chris_s | I guess, although I don't know how much work that would be, plus documenting the resulting behavior could become a hassle |
| 17:54:39 | calebccff | Forking and making hard-coded changes requires that setup your own releases and maintain them, or force users to build RB themselves, it also means if you stop maintaining it then everyone using your custom build suddenly stops being able to update and keep your customisations. In the long run making changing that can land upstream and benefit everyone is the much better approach imho, once it's done it's done and you aren't duplicating infrastructure |
| 17:54:39 | calebccff | that already exists |
| 17:55:35 | calebccff | Of note, if you wanted to work on making those changes in a configurable way I'd totally be down to contribute, being able to customise the controls and a few of the other bits you mentioned would be really nice. But, it wouldn't be worth switching to a fork for |
| 18:00 |
| 18:03:23 | fmlatghor | I tried both diska and diskb |
| 18:03:40 | fmlatghor | Boosted MSX2 EN |
| 18:05:26 | fmlatghor | the command I sued was `diskmanipulator create 0.dsk 720` |
| 18:05:35 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-855f-b256-ad1a-e2c8.res6.spectrum.com) |
| 18:07:55 | | Quit Saijin_Naib (Disconnected by services) |
| 18:07:59 | | Join Saijin-Naib [0] (~Saijin_Na@2603-7081-1d05-7230-855f-b256-ad1a-e2c8.res6.spectrum.com) |
| 18:20:27 | chris_s | calebccff: Good points. I may have been unclear before. I'm *already* using a modified build with these (and a few more) changes, so it isn't any additional work for me to publish and offer them to others. I then may or may not add to them in the future. So it's basically just a question of whether I keep that to myself or at least provide the |
| 18:20:27 | chris_s | option for others to see the code changes. Probably wouldn't even bother with releases but require people to build their own version, which still seems better than nothing. But maybe it's easy enough for anyone who is able to compile their own build to make these minor adjustments (or adjustments that fit their preferences) themselves. |
| 18:22:15 | *** | Saving seen data "./dancer.seen" |
| 18:22:19 | | Quit Saijin-Naib (Read error: Connection reset by peer) |
| 18:23:25 | | Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-9806-e0a6-26b3-5304.res6.spectrum.com) |
| 18:24:42 | fmlatghor | Sorry I sent this to the wrong channel |
| 18:25:04 | calebccff | chris_s: well, it is of course your choice. I don't really see the point in forking just to make customisations that should just be included as user configurable settings |
| 18:37:00 | chris_s | The problem is that you end up adding tons of options. How do you reconcile an attempt to simplify the UI with the requirement to add more settings? There's always a tradeoff here. The advantage of an "opionated" version is that you can throw out lots of stuff. |
| 18:59:06 | fmlatghor | chris_s: If you want to make an opinionated version, then good. If you want to make it so others can use your changes without using a fully different version than what they're already using −− you'll also have to maintain a new version of rb. I don't know, sorry, it just seems to me like it would be better if the majority of it was available for main users of rb, and if someone wanted to, they |
| 18:59:08 | fmlatghor | could use your version. |
| 19:00 |
| 19:04:43 | chris_s | yeah |
| 19:08:36 | | Quit chris_s (Quit: Connection closed) |
| 19:08:51 | | Join christian [0] (~christian@2a02:908:1e5:43c0:7c8c:cdb7:195e:8fcc) |
| 19:09:05 | | Quit christian (Client Quit) |
| 19:18:27 | | Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de) |
| 19:18:33 | chris_s | thanks for your feedback! |
| 19:18:48 | | Quit chris_s (Client Quit) |
| 19:32:26 | speachy | chris_s: have a look at Igor Poretsky's fork, he's already done some of the changes you're talking about (or at least similar changes) |
| 19:33:45 | speachy | all else being equal I'd prefer to have stuff in the mainline than not, but as calebccff said, it's Free Software. As long as you don't claim to be "The One True RockBox(tm)" then it's all good. |
| 19:33:57 | fmlatghor | I think he letf speachy |
| 19:33:59 | fmlatghor | *left |
| 19:34:11 | speachy | he'll be back, and he checks the logs too. :) |
| 19:34:18 | fmlatghor | oh I didn't know that |
| 19:36:04 | fs-bluebot_ | Build Server message: New build round started. Revision 2d8e0f7c90, 293 builds, 9 clients. |
| 19:37:10 | | Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de) |
| 19:37:28 | chris_s | speachy: ok, thanks. Indeed, I should use a proper IRC client (instead of the web version) one of these days so I don't have to check the logs incessantly... :D |
| 19:38:06 | fmlatghor | Weechat best client :) |
| 19:38:55 | speachy | at the end of the day, the more folks hacking on Rockbox the better. We have very few contributiors as it is, and I'd greatly prefer to keep everyone under the same roof. |
| 19:40:22 | chris_s | (y) |
| 19:41:08 | speachy | chris_s: your changes thus far have all been pretty sane, and reasonable in intent. |
| 19:41:13 | fmlatghor | I would like to contribute to rockbox, but I have no idea which dap to buy. |
| 19:41:24 | speachy | bbiaf |
| 19:43:13 | fmlatghor | hmm? |
| 19:46:20 | | Join jleightcap [0] (~jleightca@c-174-60-161-106.hsd1.pa.comcast.net) |
| 19:54:32 | chris_s | One of the later iPods seems like a safe choice (Mini, 4g, 5g, or classic – I'm actually a fan of the monchrome displays), but I think everybody probably has their own preference and I have zero experience with any other players. The classic is supposedly a pain to get into if you want to upgrade the battery or storage. |
| 19:54:57 | fs-bluebot_ | Build Server message: Build round completed after 1132 seconds. |
| 19:54:59 | fs-bluebot_ | Build Server message: Revision 2d8e0f7c90 result: All green |
| 19:58:06 | calebccff | can confirm, spent 5 hours cracking open my classic. once you get the technique down it's ok though. well worth it, fantastic device |
| 20:00 |
| 20:02:22 | speachy | fmlatghor: the list of supported and unstable targets on the main page is a good place to start |
| 20:03:19 | speachy | chris_s: one thing I should point out −− have a look at https://build.rockbox.org/dev.cgi |
| 20:04:09 | speachy | we get a good running indication of the size impact of each addition |
| 20:04:59 | speachy | it's not as critical as it once was but on targets with less RAM it matters. |
| 20:06:13 | chris_s | ok, makes sense :/ |
| 20:10:14 | fmlatghor | speachy: yea I was trying to filter stuff out of that, but I ended up just starting over because the ones I was left with were hard to find at good prices |
| 20:12:31 | chris_s | why would the binary size change after a manual update (043e8a0c) or am I reading this incorrectly? |
| 20:17:05 | chris_s | (and RAM as well) |
| 20:17:11 | | Quit jleightcap (Ping timeout: 265 seconds) |
| 20:17:34 | | Join jleightcap [0] (~jleightca@2601:98a:300:49c:e5dd:6237:21b5:94af) |
| 20:19:25 | braewoods | fmlatghor: and what are you looking for? |
| 20:19:52 | braewoods | i rebuild old RB compatible players from time to time |
| 20:20:29 | braewoods | waiting on a yh-925 and its parts right now since it might be better than my current players for USB development due to the hardware reset button it has |
| 20:21:57 | braewoods | i still own some units i have finished my development work for |
| 20:22:10 | braewoods | or just keep around to test that RB is still working |
| 20:22:17 | *** | Saving seen data "./dancer.seen" |
| 20:22:35 | braewoods | there's a risk some ports break from changes we do |
| 20:29:01 | fmlatghor | braewoods: I'm looking for a cheap player. I just want to be able to play flacs and mp3s, being able to display album art would be nice, but not required. |
| 20:29:16 | braewoods | fmlatghor: define cheap |
| 20:29:24 | fmlatghor | I don't know, what's cheap for you? |
| 20:29:42 | braewoods | less than $100 with all included parts to repair to proper working order again |
| 20:29:42 | fmlatghor | Just not $200? |
| 20:29:56 | fmlatghor | braewoods: basically |
| 20:30:14 | braewoods | album art... you'd want a color screen if you want that |
| 20:30:17 | fmlatghor | well something like that |
| 20:30:35 | fmlatghor | braewoods: Well I don't need that. If it's cheaper without it, then I'd be fine with that. |
| 20:30:55 | braewoods | there's a lot of models. do you want USB OTG? |
| 20:31:01 | braewoods | not all RB targets support it |
| 20:31:21 | braewoods | it enables access to the software driven stack, like the HID driver |
| 20:31:44 | fmlatghor | I'm still not sure why I'd want usb otg |
| 20:31:59 | braewoods | there's not much use for it right now but in time there will be |
| 20:32:05 | fmlatghor | For example, I don't even know what the HID driver is |
| 20:32:09 | braewoods | i'm working on extending the available driver set with things like MTP |
| 20:32:35 | braewoods | HID, it lets rockbox pretend to be an input device so you can send input events to your host |
| 20:32:37 | braewoods | PC |
| 20:32:39 | braewoods | w/e |
| 20:32:42 | braewoods | mouse, etc |
| 20:32:52 | fmlatghor | I think I understand somewhat. |
| 20:32:58 | fmlatghor | and why would you want to do this? |
| 20:33:25 | braewoods | no reason really, it's not all that useful. i extended it recently to add battery reporting on Linux. |
| 20:33:46 | fmlatghor | w/e is whatever? |
| 20:33:48 | braewoods | i plan to add some kind of remote control over USB later for supported targets |
| 20:33:50 | braewoods | yea |
| 20:34:08 | braewoods | if you don't care then not worth going into |
| 20:34:12 | fmlatghor | had to look that one up 😅 |
| 20:34:20 | fmlatghor | No I don't think that's worth it for me |
| 20:34:37 | fmlatghor | It sounds cool, but I don't need cool |
| 20:34:44 | braewoods | the iriver h100 series is pretty easy to service for the most part |
| 20:34:51 | braewoods | has lots of outputs |
| 20:34:55 | braewoods | grayscale screen though |
| 20:35:01 | braewoods | the internal storage can be CF modded |
| 20:35:14 | braewoods | it has USB UMS |
| 20:35:20 | braewoods | hardware usb basically |
| 20:35:26 | braewoods | uses standard ports for everything |
| 20:35:32 | braewoods | no proprietary dock connector |
| 20:35:50 | fmlatghor | sounds great |
| 20:36:00 | fmlatghor | I am looking for it on ebay at the moment |
| 20:36:37 | braewoods | the H120 and H140 are the common models |
| 20:36:46 | braewoods | though i've seen H120 more often |
| 20:37:17 | braewoods | it has fm radio i believe |
| 20:37:19 | braewoods | no RTC chip |
| 20:37:27 | fmlatghor | what about AM? |
| 20:37:35 | braewoods | no rockbox ports have AM radio support |
| 20:37:51 | fmlatghor | Well unfortunately there aren't many good radio stations I know of, only a handful good ones |
| 20:38:21 | braewoods | just need to be careful, there's overpriced units on ebay |
| 20:38:31 | fmlatghor | braewoods: That would be the steal though 🤣 |
| 20:38:40 | braewoods | lol |
| 20:38:49 | fmlatghor | AM is pretty wacky though |
| 20:39:05 | braewoods | i bought the yh-925 for usb development |
| 20:39:10 | fmlatghor | whenever I have a radio in front of me I just browse AM |
| 20:39:14 | braewoods | no radio chip in it |
| 20:39:22 | braewoods | no idea why |
| 20:39:24 | braewoods | but w/e |
| 20:39:32 | braewoods | don't need it for my intended use |
| 20:39:37 | fmlatghor | Wish I could use my calculator for music, but that would be inconvenient, even though it would be possible to make it possibel. |
| 20:39:41 | fmlatghor | *possible |
| 20:42:00 | braewoods | fmlatghor: would you prefer to buy one of my old units that I already repaired? |
| 20:42:10 | fmlatghor | braewoods: SUre |
| 20:42:16 | fmlatghor | *Sure |
| 20:42:27 | fmlatghor | How should we do this? |
| 20:42:38 | braewoods | well i'll start with what i still have |
| 20:42:44 | fmlatghor | Alright |
| 20:43:09 | braewoods | i have 2 iriver h120s that i replaced the battery and upgraded the storage on |
| 20:43:18 | braewoods | i used them for testing my new bootloader work |
| 20:43:29 | braewoods | the OF is no longer compatible with them, not that it matters |
| 20:43:34 | braewoods | they have 64GB CF cards installed |
| 20:43:44 | braewoods | you can upgrade it by replacing the card |
| 20:43:53 | braewoods | but you need special screw driver to open these |
| 20:44:17 | braewoods | some torx screwdriver |
| 20:44:39 | fmlatghor | yea I'll just put in my microsd card if that's possible |
| 20:44:42 | braewoods | oh, i guess you could buy a sansa fuze+ from amazon... they still have some new old stuck |
| 20:44:53 | braewoods | you might be able to with a CF adapter |
| 20:45:10 | braewoods | just these older players have more expandability |
| 20:45:28 | fmlatghor | I see (Discontinued by Manufacturer) |
| 20:45:35 | braewoods | https://www.amazon.com/SanDisk-Sansa-Player-Discontinued-Manufacturer/dp/B0041G62RY |
| 20:45:43 | fmlatghor | It looks sorta like a phone |
| 20:45:47 | braewoods | you can upgrade via SD card |
| 20:45:48 | speachy | chris_s: when stuff gets submitted together in gerrit, it only does a single build that can cover more than one individual commit |
| 20:46:18 | braewoods | fmlatghor: it kinda is but you can boot from the SD card to prevent wearing out the internal flash |
| 20:46:41 | braewoods | the battery is soldered so it won't be easy to replace if it wears out |
| 20:46:53 | fmlatghor | ah so it does support flac without rockbox, but I intend to use free software not the proprietary garbage it comes with |
| 20:47:09 | speachy | fmlatghor: depends on your budget ultimately, but if you want something that's available new now, you're basically limited to the xduoo x3ii, eros q/k (and clones), and (eventually) the fiio m3k too. |
| 20:48:17 | braewoods | fmlatghor: i use a barrel jack to usb adapter to charge my iriver h120, same voltage just no need for the original bulky ac adapter |
| 20:48:36 | braewoods | i have a fuze+ |
| 20:48:45 | braewoods | it's good for testing OTG |
| 20:48:56 | braewoods | but i ran into problems where i couldn't reset it once |
| 20:49:08 | braewoods | my code broke it and i couldn't even reset it |
| 20:49:13 | braewoods | had to let the battery die to salvage things |
| 20:49:50 | braewoods | i do not recommend the philips gogear ports |
| 20:49:57 | braewoods | royal pain to service and very cramped inside |
| 20:50:02 | braewoods | compared to the iriver h120 for example |
| 20:50:25 | braewoods | the simpler battery also helps |
| 20:50:40 | speachy | fmlatghor: so ultimately it comes down to your budget and what you want to do with it. it really should be something you want to use, or you won't be inclined to try to hack it and make it better. |
| 20:50:56 | braewoods | fmlatghor: the iriver H120 can replace the proprietary OF entirely even the bootloader |
| 20:51:08 | braewoods | it's one of the few port where we can do that |
| 20:51:19 | fmlatghor | speachy: true, I tend to hack on the hardware I own that I like the most |
| 20:51:36 | speachy | I find it very hard to recommand the fuze+ due to it's awful controls. |
| 20:51:39 | braewoods | the fuze+ isn't too hackable |
| 20:51:58 | braewoods | speachy is right, it's awkward to use but doable |
| 20:52:08 | braewoods | the iriver h120 is pretty nice even though it lacks RTC and USB OTG |
| 20:52:08 | fmlatghor | hmmm |
| 20:52:22 | braewoods | the YH-925 has some good things too, just no FM radio |
| 20:52:26 | speachy | my main criteria are native line out and controls that are easily operable without looking. |
| 20:52:46 | speachy | and a battery that lasts at least four hours. |
| 20:52:52 | braewoods | ah, not many have line out |
| 20:52:54 | braewoods | the h120 does |
| 20:53:10 | braewoods | unless you consider headphones to be line out |
| 20:53:17 | fmlatghor | well I use my phone now, but I really don't like my phone, so that's why I am here now |
| 20:53:36 | braewoods | the H120 is a good port, even if it lacks some features |
| 20:53:52 | fmlatghor | Ok I will consider that one |
| 20:54:02 | braewoods | just not much to develop on it at this point |
| 20:54:05 | braewoods | only drawack lol |
| 20:54:06 | speachy | h1xx and h3xx are really mature, stable platforms. Just limited by the inevitable march of time. |
| 20:54:29 | fmlatghor | I see, so not much hacking on them, but good players |
| 20:54:31 | braewoods | i largely solved the main issue those ports had |
| 20:54:40 | braewoods | their bootloaders hadn't been updated with modern fixes |
| 20:54:59 | braewoods | the only thing the H300 is missing is OTG support |
| 20:55:08 | braewoods | but it's a weird player that makes it unlikely to be implemented |
| 20:55:23 | braewoods | the OTG chip is documented but |
| 20:55:33 | braewoods | it has 2 micro usb ports |
| 20:55:43 | braewoods | so integrating that with the RB stack won't be easy |
| 20:55:47 | braewoods | RB assumes at most one usb port |
| 20:55:56 | braewoods | so that's one issue |
| 20:56:13 | braewoods | the other issues is it would mean a split hardware/software usb stack |
| 20:56:41 | braewoods | not to mention the iriver h300 is big endian whch probably means fixes to the usb stack we have |
| 20:56:53 | braewoods | to ensure the byte we write over usb are little endian |
| 20:58:40 | speachy | braewoods: all this assumes fmlatghor is interested in hacking the USB stack. |
| 20:58:59 | fmlatghor | Yes, the question is do I want to do that |
| 20:59:09 | speachy | fmlatghor: was there something specific of interest that led you to this? |
| 20:59:18 | fmlatghor | led me to what? |
| 20:59:23 | fmlatghor | the h120? |
| 20:59:26 | speachy | to rockbox, that is. |
| 20:59:34 | speachy | and/or the desire to hack on it |
| 21:00 |
| 21:00:42 | fmlatghor | What lead me to rockbox is because a while a go I found a link to rb in a subreddit thread. My desire to hack rb is just because I like to hack the devices I own, mainly calculators and limited hardware. |
| 21:01:10 | fmlatghor | I actually forgot how I found it until recently when I read the backlog (in my client). |
| 21:01:44 | speachy | pick a player that appeals to you (price +interface-wise) and as you use it, I'm sure you'll find yourself wanting to poke at or otherwise tweak things. |
| 21:02:15 | speachy | and if you want to undertake somethign ambitious, patches welcome. :D |
| 21:03:07 | fmlatghor | speachy: That is good advice; I will have to look more at the devices you and braewoods recommended. |
| 21:03:27 | fmlatghor | speachy: heh I would love to submit patches, but I don't think my code is ready to see the world. |
| 21:05:08 | braewoods | fmlatghor: no prior C experience |
| 21:05:09 | speachy | remember you don't _have_ to contribute anything |
| 21:05:10 | braewoods | ? |
| 21:05:30 | speachy | as long as you find rockbox useful |
| 21:08:29 | | Quit chris_s (Quit: Ping timeout (120 seconds)) |
| 21:24:08 | fmlatghor | braewoods: you didn't have prior, or I don't? |
| 21:25:36 | fmlatghor | speachy: well, yes, I don't have to contribute anything −− I probably won't unless something's broken and I want to fix it, or some optimising. I doubt I'll really want much new features. |
| 21:41:46 | | Quit MrZeus_ (Ping timeout: 260 seconds) |
| 21:53:50 | braewoods | fmlatghor: i was asking if you'd ever used C before basically. |
| 21:53:58 | braewoods | fmlatghor: since most of RB is C... |
| 21:53:58 | fmlatghor | braewoods: I have |
| 21:54:25 | fmlatghor | I just don't think I'm very good at it and need to gather more experience. |
| 21:54:54 | braewoods | i've used it for years in user space just not too familiar with embedded C |
| 21:58:16 | braewoods | i have to say though it was kinda weird working on the bootloader |
| 21:58:37 | braewoods | writes to special memory locations triggers hardware side effects is an odd experience |
| 21:59:03 | braewoods | in userspace writes to memory don't do things like that |
| 21:59:17 | braewoods | you have to perform system calls to cause things to happen external to your program |
| 22:00 |
| 22:22:20 | *** | Saving seen data "./dancer.seen" |
| 22:34:29 | braewoods | fmlatghor: just look through the old targets that are stable, just note some are much rarer than others |
| 22:34:29 | fmlatghor | me |
| 22:34:32 | fmlatghor | oops |
| 22:34:57 | braewoods | i managed to arrange to buy a gigabeat S series off another developer. they're super rare. |
| 22:35:13 | braewoods | there's only 2 on ebay, $120+ |
| 22:35:20 | braewoods | assuming that's even a reasonable price |
| 22:35:41 | braewoods | it's a very featureful player though for its age. |
| 22:35:49 | braewoods | 64MB of RAM |
| 22:36:04 | braewoods | FM radio with RDS (few rockbox targets support it) |
| 22:36:16 | fmlatghor | I've considered getting one of the monochrome ones because of how it looks, but yea hard to find |
| 22:36:16 | braewoods | etc |
| 22:36:36 | braewoods | you want monochrome? |
| 22:36:38 | fmlatghor | Reminded me of the z80 series monochrome ticalcs |
| 22:36:47 | fmlatghor | I mean, kinda, but I don't need it |
| 22:36:50 | braewoods | you might like the YH-920, it's grayscale |
| 22:36:51 | fmlatghor | just how I don't need album art |
| 22:36:56 | fmlatghor | but I like it |
| 22:36:59 | braewoods | but has fm radio |
| 22:37:18 | braewoods | there's still plenty to innovate on the general USB stack |
| 22:37:40 | braewoods | i'm currently working on MTP |
| 22:37:49 | braewoods | eventually i would like to see if we can add USB Audio |
| 22:38:01 | braewoods | the use for it is somewhat obvious |
| 22:45:14 | | Join ac_laptop [0] (~ac_laptop@186.2.247.129) |
| 22:58:06 | | Quit calebccff (Quit: Idle timeout reached: 10800s) |
| 23:00 |
| 23:00:57 | | Quit ac_laptop (Ping timeout: 246 seconds) |
| 23:18:55 | | Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) |
| 23:28:46 | | Join f1reflyylmao [0] (~f1refly@dynamic-077-003-195-217.77.3.pool.telefonica.de) |
| 23:29:19 | | Quit f1refly (Ping timeout: 272 seconds) |
| 23:29:19 | | Nick f1reflyylmao is now known as f1refly (~f1refly@dynamic-077-003-195-217.77.3.pool.telefonica.de) |
icon identifies that the person is a core developer (has commit access).