| 00:07:28 | *** | Saving seen data "./dancer.seen" |
| 00:37:11 | | Quit m01 (Quit: Konversation terminated.) |
| 00:39:43 | | Join m01 [0] (~quassel@vps-b172b88b.vps.ovh.net) |
| 01:00 |
| 01:22:45 | | Quit mrkrisprolls (Ping timeout: 265 seconds) |
| 02:00 |
| 02:07:30 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:07:32 | *** | No seen item changed, no save performed. |
| 05:00 |
| 05:12:48 | | Quit Nyaa (Quit: Leaving) |
| 05:13:10 | | Join Nyaa [0] (Nyaaori@cyberia.club/meow/nyaaori) |
| 06:00 |
| 06:07:36 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 08:01:36 | | Quit rogeliodh (Quit: The Lounge - https://thelounge.chat) |
| 08:01:58 | | Join rogeliodh [0] (~rogeliodh@rogeliodh.dev) |
| 08:07:40 | *** | Saving seen data "./dancer.seen" |
| 10:00 |
| 10:04:45 | | Join advcomp2019__ [0] (~advcomp20@user/advcomp2019) |
| 10:05:26 | | Quit speachy (Ping timeout: 246 seconds) |
| 10:07:43 | *** | Saving seen data "./dancer.seen" |
| 10:08:00 | | Quit advcomp2019_ (Ping timeout: 248 seconds) |
| 10:22:15 | | Join speachy [0] (~speachy@pineapple.shaftnet.org) |
| 10:22:15 | | Quit speachy (Changing host) |
| 10:22:15 | | Join speachy [0] (~speachy@rockbox/developer/speachy) |
| 10:22:15 | Mode | "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) |
| 11:00 |
| 11:12:57 | | Join Bobathan_ [0] (~admin@cpe-65-29-248-157.wi.res.rr.com) |
| 11:52:54 | | Join mrkrisprolls [0] (mrkrisprol@lecturify.net) |
| 12:00 |
| 12:07:45 | *** | Saving seen data "./dancer.seen" |
| 12:08:16 | braewoods | seems a good start to MTP. |
| 12:26:08 | rb-bluebot | Build Server message: New build round started. Revision bbef598817, 304 builds, 9 clients. |
| 12:26:08 | rb-bluebot | PictureFlow: Scroll through albums from track list by Christian Soffke |
| 12:44:34 | rb-bluebot | Build Server message: Build round completed after 1107 seconds. |
| 12:44:36 | rb-bluebot | Build Server message: Revision bbef598817 result: All green |
| 12:45:12 | rb-bluebot | Build Server message: New build round started. Revision 49b877470d, 304 builds, 9 clients. |
| 12:45:13 | rb-bluebot | PictureFlow: Add ability to go to last album by Christian Soffke |
| 12:59:42 | | Quit othello7 (Quit: othello7) |
| 13:00 |
| 13:03:33 | rb-bluebot | Build Server message: Build round completed after 1101 seconds. |
| 13:03:35 | rb-bluebot | Build Server message: Revision 49b877470d result: All green |
| 13:03:43 | rb-bluebot | Build Server message: New build round started. Revision 6e192dc28d, 304 builds, 8 clients. |
| 13:03:43 | rb-bluebot | hiby: the second drive for these is "USB" not "HD1" by Solomon Peachy |
| 13:19:43 | rb-bluebot | Build Server message: Build round completed after 961 seconds. |
| 13:19:45 | rb-bluebot | Build Server message: Revision 6e192dc28d result: All green |
| 13:19:54 | rb-bluebot | Build Server message: New build round started. Revision 31b8cd8f73, 304 builds, 9 clients. |
| 13:19:54 | rb-bluebot | PictureFlow: Remove menu items for "Return" and "Clear Playlist" by Christian Soffke |
| 13:24:11 | | Quit JanC (Ping timeout: 264 seconds) |
| 13:25:26 | | Join JanC [0] (~janc@user/janc) |
| 13:36:52 | rb-bluebot | Build Server message: Build round completed after 1019 seconds. |
| 13:36:54 | rb-bluebot | Build Server message: Revision 31b8cd8f73 result: All green |
| 13:52:51 | | Join lebellium [0] (~lebellium@2a01cb040610e00015084440b8c0863f.ipv6.abo.wanadoo.fr) |
| 14:00 |
| 14:07:47 | *** | Saving seen data "./dancer.seen" |
| 14:16:57 | | Join paulk-bis [0] (~paulk@vpn-0-22.aquilenet.fr) |
| 14:17:32 | | Quit paulk (Read error: Connection reset by peer) |
| 14:37:26 | | Quit JanC (Remote host closed the connection) |
| 14:37:40 | | Join JanC [0] (~janc@user/janc) |
| 15:00 |
| 15:12:25 | rb-bluebot | Build Server message: New build round started. Revision 028eafaeef, 304 builds, 9 clients. |
| 15:12:25 | rb-bluebot | Onplay: Fix items from Queue submenu appearing at top level by Christian Soffke |
| 15:27:21 | rb-bluebot | Build Server message: Build round completed after 896 seconds. |
| 15:27:22 | rb-bluebot | Build Server message: Revision 028eafaeef result: All green |
| 15:42:57 | braewoods | speachy, I can probably implement partial MTP support for like device properties. The main problem will be figuring out how to collect a file list since it seems MTP requires them to be fully enumerated upon request. |
| 15:43:37 | braewoods | I was hoping that it could be done gradually like on a per folder basis but seems not. |
| 15:44:20 | speachy | it doesn't make sense that every file on the device needs to be enumerated up front |
| 15:44:59 | braewoods | maybe i'm reading the spec wrong. I'll re-readi t. |
| 15:45:54 | braewoods | problem might be how to create valid file identifiers. |
| 15:47:36 | braewoods | Just GetNumObjects makes me think that. |
| 15:47:44 | braewoods | "This operation returns the number of objects on the device, or the subset defined by the |
| 15:47:44 | braewoods | first three parameters." |
| 15:50:55 | braewoods | Hm. |
| 15:53:39 | speachy | if the host asks the device to count the number of objects, then that's straightforward if a bit I/O intensive. |
| 15:54:11 | braewoods | yea, that's what I was thinking. |
| 15:54:39 | braewoods | The main issue I see is how I can map a 32 bit integer to and from some internal file mapping. |
| 15:54:54 | braewoods | It's not a file name so the usual thoughts don't apply. |
| 15:55:41 | braewoods | The IDs are device assigned in terms of meaning. |
| 15:56:05 | braewoods | Maybe there's one filesystem level stuff I can use. |
| 15:56:09 | braewoods | some* |
| 15:56:12 | speachy | you can just return unsupported if it asks you to enumerate the handles of everything |
| 15:56:38 | speachy | build a cache as you traverse the filesystem, one unique id per path encountered. |
| 15:56:40 | braewoods | Indeed we can. MTP has a way to enumerate what MTP operations you support. |
| 15:57:09 | braewoods | So in theory you should never receive a request for an unsupported operation. |
| 15:57:36 | speachy | use that for the upper 16 bits, and the lower 16 bits are the file in the filesystem storage order. |
| 15:57:39 | braewoods | In exclusive mode we got a fair amount of RAM to work with so I may be able to just use that. |
| 15:59:06 | speachy | ehere that gets fun is if you modify the filesystem in any way. |
| 15:59:17 | speachy | adding probably is ok, but deleting can change that ordering |
| 15:59:28 | braewoods | Oh right. |
| 15:59:35 | braewoods | Yea, same problem with an array. |
| 15:59:38 | speachy | basically you can see how this is intended to be mapped to a database rather than a native filesystem |
| 15:59:53 | braewoods | Doesn't rockbox have a file database? |
| 16:00 |
| 16:00:09 | speachy | it does, but there's nothing enforcing its use. |
| 16:00:27 | speachy | (or keeping it up-to-date if you add/remove files) |
| 16:00:58 | braewoods | True. I have some ideas. The issue I see is not mapping to storages but how to map to files. |
| 16:01:23 | braewoods | It's almost like these were intended to be looked up in an SQL database. |
| 16:02:43 | braewoods | I should probably not rely on a database... but there's a practical limit on how many unique files I can enumerate in memory. |
| 16:03:15 | braewoods | Rockbox runs on stuff with only a few megabytes of RAM to spare in the worst case. |
| 16:03:47 | speachy | the wip patch that was posted uses the existing dircache for this. |
| 16:03:53 | braewoods | I know. |
| 16:04:08 | speachy | the handle is literally just the pointer to the dircache entry |
| 16:04:30 | braewoods | But you said dircache isn't necessarily used or kept up to date though, right? |
| 16:04:53 | speachy | dircache is optional, I think it's on for everything but 2MB targets |
| 16:05:01 | speachy | database is different. |
| 16:05:24 | braewoods | how does dircache work with multidrive or multivolume? |
| 16:05:45 | speachy | they're just paths with a drive prefix. |
| 16:06:07 | speachy | there's nothign that says object IDs have to be persistent across MTP sessions. |
| 16:06:16 | braewoods | You are correct. |
| 16:06:25 | braewoods | But within one they must be consistent. |
| 16:06:39 | speachy | so doing this in exclusive mode, you never have to worry about anything changing underneath you. |
| 16:07:49 | *** | Saving seen data "./dancer.seen" |
| 16:08:16 | braewoods | I'll just disable MTP on devices that are too weak to work with it, mostly insufficient RAM. |
| 16:09:01 | braewoods | dircache, yea, i'll look into that later on. I'm still working on implementing MTP parsing and stuff to worry about this yet. |
| 16:10:38 | | Join JanC_ [0] (~janc@user/janc) |
| 16:10:50 | | Quit JanC (Killed (lead.libera.chat (Nickname regained by services))) |
| 16:10:50 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
| 16:20:53 | speachy | can't the old patch be used for that? |
| 16:21:39 | speachy | unpacking/parsing MTP packets is already there, why rewrite the wheel? |
| 16:33:39 | _bilgus | braewoods, could you hash the path for your id? collisions might be a bigger issue but I bet you could make it negligible spending enough cpu on a cryptographic hash |
| 16:50:58 | | Quit zem (Quit: and it's always been the same / it's just a complicated game) |
| 16:51:10 | braewoods | _bilgus, how would that help? I need to be able to convert it both ways. |
| 16:51:24 | braewoods | Hashes are normally one way. |
| 16:51:48 | _bilgus | yeah that wouldn't be fun in the other direction |
| 16:52:17 | braewoods | In MTP the object handles are 32 bit unsigned integers. The device decides how they are mapped. |
| 16:53:33 | braewoods | In some cases they are pointers. |
| 16:53:39 | braewoods | But only works on 32 bit targets. |
| 16:54:59 | braewoods | I can see why we never had MTP support before though. Probably the complexity involved. |
| 16:55:22 | | Quit JanC (Remote host closed the connection) |
| 16:55:25 | speachy | That, and UMS was more than sufficient. |
| 16:55:28 | braewoods | UMS in many ways is simpler. All the major complexity is on the OS side. |
| 16:55:40 | | Join JanC [0] (~janc@user/janc) |
| 16:56:51 | speachy | realistically MTP came about for devices which had far smaller storage than modern ones, with perhaps several hundred objects max. |
| 16:57:35 | braewoods | Its main advantage is protection of file system integrity. |
| 16:57:57 | speachy | doesn't really scale past that unless the files are managed in a true database. |
| 16:58:24 | braewoods | Yea I'm seeing that. On Linux gadget mode, it's usually limited to a predetermined set of directories. |
| 16:58:33 | speachy | yep. |
| 16:59:50 | braewoods | And the main advantage of MTP is that. If I want to be able to change device properties, I would probably have an easier time extending the HID driver. |
| 17:00 |
| 17:00:21 | braewoods | If that makes sense. |
| 17:00:22 | speachy | MTP was an offshoot of PTP, aka a way to directly connect printers to cameras. |
| 17:00:42 | braewoods | But if you want to transfer files, MTP or UMS is largely it. |
| 17:00:44 | speachy | without having to deal with external/removeable storage |
| 17:00:47 | braewoods | For USB anyway. |
| 17:01:24 | braewoods | I'm honestly thinking now MTP is probably a waste of time. |
| 17:01:49 | braewoods | It arguably duplicates existing functionality. |
| 17:01:52 | speachy | eh, I don't know if I'd go that far, but there's no denying that it's going to take work. |
| 17:02:52 | | Quit JanC (Remote host closed the connection) |
| 17:02:55 | braewoods | speachy, I see. Well, what would rockbox gain from it? |
| 17:03:10 | | Join JanC [0] (~janc@user/janc) |
| 17:03:19 | braewoods | It seems like it would just allow people to disconnect devices worry free for the most part. |
| 17:03:29 | braewoods | At most they risk corrupting a file that was in transit. |
| 17:03:50 | braewoods | In which case I would probably just delete it. |
| 17:04:05 | speachy | more filesystem integrity? Better integration into our database? Simultaneous operation and file transfer? |
| 17:05:01 | speachy | compatibility with more consumer electronic widgets that only speak MTP? |
| 17:05:31 | braewoods | I was looking at some MTP implementations for micro controllers. |
| 17:05:32 | speachy | (or their MTP implementation is a lot more robust than UMS) |
| 17:05:44 | braewoods | But they're in C++. |
| 17:05:48 | * | braewoods facepalms. |
| 17:05:58 | speachy | (I'm looking at you, most car headunits that insist on enumerating every.single.file. before allowing you to play anything) |
| 17:06:24 | braewoods | I think the best solution is going to be gradual implementation. |
| 17:06:30 | speachy | all of the microcontroller/cpu vendor-pushed dev environments are C++ focused |
| 17:06:59 | speachy | moar bloat == more pricey parts |
| 17:07:20 | speachy | (and it also makes abstraction layers/HALs simpler) |
| 17:07:46 | braewoods | Is that something I could get merged? Gradual work on MTP? |
| 17:08:27 | braewoods | It would remain disabled OFC until it is really ready. The main issue I see is how to make it work alongside UMS. |
| 17:08:41 | speachy | eh, that's just the final step |
| 17:09:09 | braewoods | I'll probably just disable support for MTP on devices with < 4 endpoints for now to simplify the WIP. |
| 17:10:21 | speachy | getting the MTP core done (object/request/response), integration into the USB layer, integration into our filesystem layers & other incremental functionalit. |
| 17:10:30 | braewoods | Anywho, can I get some of my initial work merged if I pull it out? It'll be hidden behind a macro for now. |
| 17:11:01 | speachy | I'd prefer to not merge anything to master until it does _something_ visible to users. |
| 17:11:18 | braewoods | Fair enough. |
| 17:11:36 | _bilgus | if you do it in a plugin |
| 17:11:51 | braewoods | Is that even an option right now? |
| 17:11:59 | speachy | _bilgus: I don't think the USB core is _that_ exposed. |
| 17:12:04 | _bilgus | but you'd at least need hooks in the API |
| 17:12:16 | * | speachy shudders. |
| 17:12:22 | _bilgus | heh |
| 17:12:23 | speachy | let's not open that can of worms. |
| 17:12:30 | braewoods | I'll keep working on it in core when I got some time. |
| 17:12:39 | braewoods | Here's my current WIP. |
| 17:12:53 | braewoods | braewoods/rockbox/commit/ee78369d3aa98ea41af9963f36f618c5b8d0cbd7">https://github.com/braewoods/rockbox/commit/ee78369d3aa98ea41af9963f36f618c5b8d0cbd7 |
| 17:12:54 | speachy | though there's a good argument for pulling out USB everything into plugins. |
| 17:13:02 | _bilgus | ^^^ |
| 17:13:06 | _bilgus | yep |
| 17:13:33 | speachy | would also make the sw/hw usb stuff easier to separate. |
| 17:13:40 | braewoods | sorry, this one |
| 17:13:41 | braewoods | braewoods/rockbox/commit/c41a1a1040ad6ffdf63e268077fa39130db280fa">https://github.com/braewoods/rockbox/commit/c41a1a1040ad6ffdf63e268077fa39130db280fa |
| 17:14:47 | braewoods | i added the string descriptor because some MTP initiators require one that contains MTP for device detection. |
| 17:15:31 | _bilgus | thats a pretty good damn start do you not have gerrit access? |
| 17:15:57 | braewoods | I'd have to dig out my account and was feeling lazy. |
| 17:16:52 | _bilgus | ah, anyway I do like the idea of moving usb to a plugin since its exclusive anyway |
| 17:17:14 | braewoods | All of it? |
| 17:17:23 | _bilgus | as much as possible |
| 17:17:49 | speachy | the core stack and hardware interface owuld need to stay in core |
| 17:18:16 | braewoods | Wouldn't that annoy users? Plugins usually require manual effort to launch. |
| 17:18:33 | _bilgus | on usb even core could launch |
| 17:18:39 | _bilgus | event* |
| 17:18:53 | speachy | no, we can launch a plugin any time we want, we control the horizontal and vertical here |
| 17:19:23 | speachy | but that's one bit of surgery I don't think is worth tackling right now. |
| 17:19:26 | braewoods | So we'd basically be making something akin to Linux gadget? |
| 17:19:39 | speachy | conceptually, sure. |
| 17:19:58 | speachy | we need to get the _current_ usb code back into a stable state for more of our targets. |
| 17:19:59 | braewoods | Allowing USB device code to be implemented in user space. Like reverse libusb. |
| 17:20:32 | _bilgus | thats a good point that it needs to be stable first |
| 17:20:54 | speachy | there's no userspace/kernelspace distintion here. more like dynamically loaded/unloaded modules. |
| 17:21:15 | speachy | or going old-sk00l, overlays. |
| 17:21:32 | _bilgus | but I envision the plugin doing the logo and key event stuff and likely the buffers |
| 17:22:29 | braewoods | I'll work on MTP but I'm not sure how to really implement it aside from it being a different option for "storage mode". |
| 17:22:33 | speachy | What I'd like to see is a rework of the USB layer to make the SW model primary and throw exceptions in there for the HW-managed approach, isntead of the mismash of the two. |
| 17:22:58 | braewoods | Isn't it mainly coldfire that is hardware USB? |
| 17:23:14 | speachy | IIRC the old iRiver targets are the only true HW USB (ie with dedicated USB-ATA) targets. |
| 17:23:20 | braewoods | And ironically we got some players that technically have *both*. |
| 17:23:41 | speachy | never supported the SW USB mode on the 3xx series |
| 17:23:45 | braewoods | Yea. |
| 17:23:47 | braewoods | For good reason. |
| 17:24:00 | braewoods | It would be slow even if you did implement it. |
| 17:24:03 | speachy | a lot of extra complexity for no real benefit. |
| 17:25:14 | braewoods | I also noted that our USB code would fall apart on big endian targets. |
| 17:25:41 | braewoods | No attempt is made to convert to USB endian order, we just assume it'll be the same as the host CPU. |
| 17:26:19 | braewoods | I guess that's not a real problem though as it's unlikely we'll ever have a big endian target with USB. |
| 17:26:36 | speachy | all of our ARMv4T targets are LE? Huh, I'd not have expected that. |
| 17:26:50 | braewoods | Apparently otherwise USB would be broken for sure. |
| 17:27:13 | braewoods | Bytes being out of order would break stuff, pretty much guaranteed. |
| 17:27:44 | braewoods | Most ARM implementations I've seen use little endian. Probably because USB is. |
| 17:28:01 | speachy | here's one bit of joy I've seen on some m68k designs −− sure teh processor is BE but they byteswap the iobus so the peripheral sees LE. |
| 17:28:13 | braewoods | Oh. lmao |
| 17:28:30 | speachy | so moral of the story −− you never really know. |
| 17:29:21 | speachy | then you have things like PPC which are bytesexual; individual memory regions can be set to be LE or BE, down to single-page granularity. |
| 17:29:34 | speachy | and naturally that includes I/O too. |
| 17:30:01 | braewoods | I own one PPC machine but it is 32 bit PPC so no modern Linux distribution runs on it. |
| 17:30:10 | braewoods | They could in theory but support was already dropped. |
| 17:30:58 | speachy | all of the modern stuff is pretty much LE-only, mostly to make badly written software easy to port. |
| 17:31:00 | braewoods | It's funny owning an efika 5200b and having nothing to run on it now other than outdated software. |
| 17:31:43 | braewoods | This may be a situation where Gentoo is the only sane option now. |
| 17:31:44 | braewoods | Lol |
| 17:32:26 | braewoods | Anywho I'll probably replace the old IDE drive in it with a CF card now. |
| 17:38:55 | speachy | it's a win-win |
| 17:39:23 | braewoods | Yea, it just happens to use the old IDE for laptop drives. |
| 17:45:43 | braewoods | It's just kinda funny they released a device with USB 1.1 max... in like 2008 or so. |
| 17:45:50 | braewoods | ._. |
| 17:46:11 | braewoods | I would have expected 2.0 but nope. |
| 17:50:15 | speachy | it uses an SoC that dates from 2002, regardless of when the actual product was introduced. |
| 17:50:28 | braewoods | Oh. I see. |
| 18:00 |
| 18:01:06 | speachy | huh, that entire SoC series was intended for automobiles. |
| 18:04:37 | speachy | so very long lifecycles |
| 18:07:50 | *** | Saving seen data "./dancer.seen" |
| 18:24:57 | | Quit JanC (Remote host closed the connection) |
| 18:25:10 | | Join JanC [0] (~janc@user/janc) |
| 18:47:00 | | Join massiveH [0] (~massiveH@2600:4040:a99f:1f00:5546:69a9:27ed:5726) |
| 18:58:09 | | Quit lebellium (Quit: Leaving) |
| 19:00 |
| 19:13:45 | | Quit JanC (Read error: Connection reset by peer) |
| 19:13:59 | | Join JanC [0] (~janc@user/janc) |
| 19:28:32 | | Quit paulk-bis (Ping timeout: 248 seconds) |
| 19:34:23 | | Join paulk-bis [0] (~paulk@vpn-0-22.aquilenet.fr) |
| 20:00 |
| 20:07:52 | *** | Saving seen data "./dancer.seen" |
| 20:24:52 | | Quit JanC (Remote host closed the connection) |
| 20:25:10 | | Join JanC [0] (~janc@user/janc) |
| 21:00 |
| 21:05:51 | | Quit JanC (Read error: Connection reset by peer) |
| 21:06:20 | | Join JanC [0] (~janc@user/janc) |
| 21:16:05 | | Quit Xeha (Ping timeout: 240 seconds) |
| 21:36:07 | | Join funman_ [0] (~fun@chui-pas.net) |
| 21:37:47 | | Join pookie [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) |
| 21:42:08 | | Quit JanC (Ping timeout: 240 seconds) |
| 21:42:10 | | Join JanC_ [0] (~janc@user/janc) |
| 21:42:24 | | Nick JanC_ is now known as JanC (~janc@user/janc) |
| 21:42:58 | | Quit GeekShadow (*.net *.split) |
| 21:42:59 | | Quit funman (*.net *.split) |
| 21:42:59 | | Quit olspookishmagus (*.net *.split) |
| 21:42:59 | | Quit dys (*.net *.split) |
| 21:48:14 | | Join GeekShadow [0] (~antoine@82-64-164-139.subs.proxad.net) |
| 22:00 |
| 22:07:56 | *** | Saving seen data "./dancer.seen" |
| 22:09:48 | | Quit JanC (Ping timeout: 264 seconds) |
| 22:13:44 | | Join JanC [0] (~janc@user/janc) |
| 23:00 |
| 23:00:58 | | Quit skipwich (Quit: DISCONNECT) |
| 23:02:23 | | Join skipwich [0] (~skipwich@user/skipwich) |
| 23:58:30 | | Join hactar|ant [0] (~zem@97.115.167.86) |
icon identifies that the person is a core developer (has commit access).