Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2023-05-26

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:15Mode"#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:16braewoodsseems a good start to MTP.
12:26:08rb-bluebotBuild Server message: New build round started. Revision bbef598817, 304 builds, 9 clients.
12:26:08rb-bluebotPictureFlow: Scroll through albums from track list by Christian Soffke
12:44:34rb-bluebotBuild Server message: Build round completed after 1107 seconds.
12:44:36rb-bluebotBuild Server message: Revision bbef598817 result: All green
12:45:12rb-bluebotBuild Server message: New build round started. Revision 49b877470d, 304 builds, 9 clients.
12:45:13rb-bluebotPictureFlow: Add ability to go to last album by Christian Soffke
12:59:42 Quit othello7 (Quit: othello7)
13:00
13:03:33rb-bluebotBuild Server message: Build round completed after 1101 seconds.
13:03:35rb-bluebotBuild Server message: Revision 49b877470d result: All green
13:03:43rb-bluebotBuild Server message: New build round started. Revision 6e192dc28d, 304 builds, 8 clients.
13:03:43rb-bluebothiby: the second drive for these is "USB" not "HD1" by Solomon Peachy
13:19:43rb-bluebotBuild Server message: Build round completed after 961 seconds.
13:19:45rb-bluebotBuild Server message: Revision 6e192dc28d result: All green
13:19:54rb-bluebotBuild Server message: New build round started. Revision 31b8cd8f73, 304 builds, 9 clients.
13:19:54rb-bluebotPictureFlow: 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:52rb-bluebotBuild Server message: Build round completed after 1019 seconds.
13:36:54rb-bluebotBuild 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:25rb-bluebotBuild Server message: New build round started. Revision 028eafaeef, 304 builds, 9 clients.
15:12:25rb-bluebotOnplay: Fix items from Queue submenu appearing at top level by Christian Soffke
15:27:21rb-bluebotBuild Server message: Build round completed after 896 seconds.
15:27:22rb-bluebotBuild Server message: Revision 028eafaeef result: All green
15:42:57braewoodsspeachy, 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:37braewoodsI was hoping that it could be done gradually like on a per folder basis but seems not.
15:44:20speachyit doesn't make sense that every file on the device needs to be enumerated up front
15:44:59braewoodsmaybe i'm reading the spec wrong. I'll re-readi t.
15:45:54braewoodsproblem might be how to create valid file identifiers.
15:47:36braewoodsJust GetNumObjects makes me think that.
15:47:44braewoods"This operation returns the number of objects on the device, or the subset defined by the
15:47:44braewoodsfirst three parameters."
15:50:55braewoodsHm.
15:53:39speachyif the host asks the device to count the number of objects, then that's straightforward if a bit I/O intensive.
15:54:11braewoodsyea, that's what I was thinking.
15:54:39braewoodsThe main issue I see is how I can map a 32 bit integer to and from some internal file mapping.
15:54:54braewoodsIt's not a file name so the usual thoughts don't apply.
15:55:41braewoodsThe IDs are device assigned in terms of meaning.
15:56:05braewoodsMaybe there's one filesystem level stuff I can use.
15:56:09braewoodssome*
15:56:12speachyyou can just return unsupported if it asks you to enumerate the handles of everything
15:56:38speachybuild a cache as you traverse the filesystem, one unique id per path encountered.
15:56:40braewoodsIndeed we can. MTP has a way to enumerate what MTP operations you support.
15:57:09braewoodsSo in theory you should never receive a request for an unsupported operation.
15:57:36speachyuse that for the upper 16 bits, and the lower 16 bits are the file in the filesystem storage order.
15:57:39braewoodsIn exclusive mode we got a fair amount of RAM to work with so I may be able to just use that.
15:59:06speachyehere that gets fun is if you modify the filesystem in any way.
15:59:17speachyadding probably is ok, but deleting can change that ordering
15:59:28braewoodsOh right.
15:59:35braewoodsYea, same problem with an array.
15:59:38speachybasically you can see how this is intended to be mapped to a database rather than a native filesystem
15:59:53braewoodsDoesn't rockbox have a file database?
16:00
16:00:09speachyit does, but there's nothing enforcing its use.
16:00:27speachy(or keeping it up-to-date if you add/remove files)
16:00:58braewoodsTrue. I have some ideas. The issue I see is not mapping to storages but how to map to files.
16:01:23braewoodsIt's almost like these were intended to be looked up in an SQL database.
16:02:43braewoodsI 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:15braewoodsRockbox runs on stuff with only a few megabytes of RAM to spare in the worst case.
16:03:47speachythe wip patch that was posted uses the existing dircache for this.
16:03:53braewoodsI know.
16:04:08speachythe handle is literally just the pointer to the dircache entry
16:04:30braewoodsBut you said dircache isn't necessarily used or kept up to date though, right?
16:04:53speachydircache is optional, I think it's on for everything but 2MB targets
16:05:01speachydatabase is different.
16:05:24braewoodshow does dircache work with multidrive or multivolume?
16:05:45speachythey're just paths with a drive prefix.
16:06:07speachythere's nothign that says object IDs have to be persistent across MTP sessions.
16:06:16braewoodsYou are correct.
16:06:25braewoodsBut within one they must be consistent.
16:06:39speachyso 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:16braewoodsI'll just disable MTP on devices that are too weak to work with it, mostly insufficient RAM.
16:09:01braewoodsdircache, 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:53speachycan't the old patch be used for that?
16:21:39speachyunpacking/parsing MTP packets is already there, why rewrite the wheel?
16:33:39_bilgusbraewoods, 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:10braewoods_bilgus, how would that help? I need to be able to convert it both ways.
16:51:24braewoodsHashes are normally one way.
16:51:48_bilgusyeah that wouldn't be fun in the other direction
16:52:17braewoodsIn MTP the object handles are 32 bit unsigned integers. The device decides how they are mapped.
16:53:33braewoodsIn some cases they are pointers.
16:53:39braewoodsBut only works on 32 bit targets.
16:54:59braewoodsI 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:25speachyThat, and UMS was more than sufficient.
16:55:28braewoodsUMS 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:51speachyrealistically MTP came about for devices which had far smaller storage than modern ones, with perhaps several hundred objects max.
16:57:35braewoodsIts main advantage is protection of file system integrity.
16:57:57speachydoesn't really scale past that unless the files are managed in a true database.
16:58:24braewoodsYea I'm seeing that. On Linux gadget mode, it's usually limited to a predetermined set of directories.
16:58:33speachyyep.
16:59:50braewoodsAnd 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:21braewoodsIf that makes sense.
17:00:22speachyMTP was an offshoot of PTP, aka a way to directly connect printers to cameras.
17:00:42braewoodsBut if you want to transfer files, MTP or UMS is largely it.
17:00:44speachywithout having to deal with external/removeable storage
17:00:47braewoodsFor USB anyway.
17:01:24braewoodsI'm honestly thinking now MTP is probably a waste of time.
17:01:49braewoodsIt arguably duplicates existing functionality.
17:01:52speachyeh, 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:55braewoodsspeachy, I see. Well, what would rockbox gain from it?
17:03:10 Join JanC [0] (~janc@user/janc)
17:03:19braewoodsIt seems like it would just allow people to disconnect devices worry free for the most part.
17:03:29braewoodsAt most they risk corrupting a file that was in transit.
17:03:50braewoodsIn which case I would probably just delete it.
17:04:05speachymore filesystem integrity? Better integration into our database? Simultaneous operation and file transfer?
17:05:01speachycompatibility with more consumer electronic widgets that only speak MTP?
17:05:31braewoodsI was looking at some MTP implementations for micro controllers.
17:05:32speachy(or their MTP implementation is a lot more robust than UMS)
17:05:44braewoodsBut they're in C++.
17:05:48*braewoods facepalms.
17:05:58speachy(I'm looking at you, most car headunits that insist on enumerating every.single.file. before allowing you to play anything)
17:06:24braewoodsI think the best solution is going to be gradual implementation.
17:06:30speachyall of the microcontroller/cpu vendor-pushed dev environments are C++ focused
17:06:59speachymoar bloat == more pricey parts
17:07:20speachy(and it also makes abstraction layers/HALs simpler)
17:07:46braewoodsIs that something I could get merged? Gradual work on MTP?
17:08:27braewoodsIt would remain disabled OFC until it is really ready. The main issue I see is how to make it work alongside UMS.
17:08:41speachyeh, that's just the final step
17:09:09braewoodsI'll probably just disable support for MTP on devices with < 4 endpoints for now to simplify the WIP.
17:10:21speachygetting the MTP core done (object/request/response), integration into the USB layer, integration into our filesystem layers & other incremental functionalit.
17:10:30braewoodsAnywho, 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:01speachyI'd prefer to not merge anything to master until it does _something_ visible to users.
17:11:18braewoodsFair enough.
17:11:36_bilgusif you do it in a plugin
17:11:51braewoodsIs that even an option right now?
17:11:59speachy_bilgus: I don't think the USB core is _that_ exposed.
17:12:04_bilgusbut you'd at least need hooks in the API
17:12:16*speachy shudders.
17:12:22_bilgusheh
17:12:23speachylet's not open that can of worms.
17:12:30braewoodsI'll keep working on it in core when I got some time.
17:12:39braewoodsHere's my current WIP.
17:12:53braewoodsbraewoods/rockbox/commit/ee78369d3aa98ea41af9963f36f618c5b8d0cbd7">https://github.com/braewoods/rockbox/commit/ee78369d3aa98ea41af9963f36f618c5b8d0cbd7
17:12:54speachythough there's a good argument for pulling out USB everything into plugins.
17:13:02_bilgus^^^
17:13:06_bilgusyep
17:13:33speachywould also make the sw/hw usb stuff easier to separate.
17:13:40braewoodssorry, this one
17:13:41braewoodsbraewoods/rockbox/commit/c41a1a1040ad6ffdf63e268077fa39130db280fa">https://github.com/braewoods/rockbox/commit/c41a1a1040ad6ffdf63e268077fa39130db280fa
17:14:47braewoodsi added the string descriptor because some MTP initiators require one that contains MTP for device detection.
17:15:31_bilgusthats a pretty good damn start do you not have gerrit access?
17:15:57braewoodsI'd have to dig out my account and was feeling lazy.
17:16:52_bilgusah, anyway I do like the idea of moving usb to a plugin since its exclusive anyway
17:17:14braewoodsAll of it?
17:17:23_bilgusas much as possible
17:17:49speachythe core stack and hardware interface owuld need to stay in core
17:18:16braewoodsWouldn't that annoy users? Plugins usually require manual effort to launch.
17:18:33_bilguson usb even core could launch
17:18:39_bilgusevent*
17:18:53speachyno, we can launch a plugin any time we want, we control the horizontal and vertical here
17:19:23speachybut that's one bit of surgery I don't think is worth tackling right now.
17:19:26braewoodsSo we'd basically be making something akin to Linux gadget?
17:19:39speachyconceptually, sure.
17:19:58speachywe need to get the _current_ usb code back into a stable state for more of our targets.
17:19:59braewoodsAllowing USB device code to be implemented in user space. Like reverse libusb.
17:20:32_bilgusthats a good point that it needs to be stable first
17:20:54speachythere's no userspace/kernelspace distintion here. more like dynamically loaded/unloaded modules.
17:21:15speachyor going old-sk00l, overlays.
17:21:32_bilgusbut I envision the plugin doing the logo and key event stuff and likely the buffers
17:22:29braewoodsI'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:33speachyWhat 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:58braewoodsIsn't it mainly coldfire that is hardware USB?
17:23:14speachyIIRC the old iRiver targets are the only true HW USB (ie with dedicated USB-ATA) targets.
17:23:20braewoodsAnd ironically we got some players that technically have *both*.
17:23:41speachynever supported the SW USB mode on the 3xx series
17:23:45braewoodsYea.
17:23:47braewoodsFor good reason.
17:24:00braewoodsIt would be slow even if you did implement it.
17:24:03speachya lot of extra complexity for no real benefit.
17:25:14braewoodsI also noted that our USB code would fall apart on big endian targets.
17:25:41braewoodsNo attempt is made to convert to USB endian order, we just assume it'll be the same as the host CPU.
17:26:19braewoodsI guess that's not a real problem though as it's unlikely we'll ever have a big endian target with USB.
17:26:36speachyall of our ARMv4T targets are LE? Huh, I'd not have expected that.
17:26:50braewoodsApparently otherwise USB would be broken for sure.
17:27:13braewoodsBytes being out of order would break stuff, pretty much guaranteed.
17:27:44braewoodsMost ARM implementations I've seen use little endian. Probably because USB is.
17:28:01speachyhere'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:13braewoodsOh. lmao
17:28:30speachyso moral of the story −− you never really know.
17:29:21speachythen 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:34speachyand naturally that includes I/O too.
17:30:01braewoodsI own one PPC machine but it is 32 bit PPC so no modern Linux distribution runs on it.
17:30:10braewoodsThey could in theory but support was already dropped.
17:30:58speachyall of the modern stuff is pretty much LE-only, mostly to make badly written software easy to port.
17:31:00braewoodsIt's funny owning an efika 5200b and having nothing to run on it now other than outdated software.
17:31:43braewoodsThis may be a situation where Gentoo is the only sane option now.
17:31:44braewoodsLol
17:32:26braewoodsAnywho I'll probably replace the old IDE drive in it with a CF card now.
17:38:55speachyit's a win-win
17:39:23braewoodsYea, it just happens to use the old IDE for laptop drives.
17:45:43braewoodsIt's just kinda funny they released a device with USB 1.1 max... in like 2008 or so.
17:45:50braewoods._.
17:46:11braewoodsI would have expected 2.0 but nope.
17:50:15speachyit uses an SoC that dates from 2002, regardless of when the actual product was introduced.
17:50:28braewoodsOh. I see.
18:00
18:01:06speachyhuh, that entire SoC series was intended for automobiles.
18:04:37speachyso 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)

Previous day | Next day