| 00:10:57 | *** | No seen item changed, no save performed. |
| 01:00 |
| 01:21:10 | | Quit rb-bluebot (Ping timeout: 256 seconds) |
| 01:21:18 | | Join rb-bluebot [0] (~rb-bluebo@rockbox/bot/utility) |
| 01:30:51 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:6ca0:4ab:b2e9:a1f) |
| 01:35:29 | | Quit ZincAlloy (Ping timeout: 265 seconds) |
| 01:54:05 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 01:58:41 | | Quit ZincAlloy (Ping timeout: 265 seconds) |
| 02:00 |
| 02:11:01 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:00:18 | aaronamm | _bilgus Thank you so much so much for your suggestion. This is very useful. It time for me to learn Lua script. |
| 04:00:27 | aaronamm | Thanks again. |
| 04:00:56 | aaronamm | BTW, I have post to the forum as well. I think I will post your suggest there. |
| 04:01:25 | aaronamm | https://forums.rockbox.org/index.php/topic,54047.0.html |
| 04:01:33 | aaronamm | It can be useful for others. |
| 04:02:15 | aaronamm | @braewoods I agree with you that is not convenient. It just my personal hobby. |
| 04:02:53 | aaronamm | Here is my website, most contents are in Thai, some are English but Google translator should be okay. |
| 04:03:03 | aaronamm | https://onlyminidisc.com/ |
| 04:05:15 | aaronamm | Using Net MD is a good way to transfer music. However, there are some people who believe transfer 1:1 is the best sound quality. This is my a little resource what if I can make auto tracking 1:1 correctly. |
| 04:06:11 | aaronamm | In fact, I usually use Net MD and here is my manual for Web MiniDisc. |
| 04:06:27 | aaronamm | https://onlyminidisc.com/net-md/web-mini-disc-manual |
| 04:11:02 | *** | No seen item changed, no save performed. |
| 04:55:33 | | Quit aaronamm (Quit: Connection closed) |
| 06:00 |
| 06:11:04 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:37:40 | | Quit munkis (Ping timeout: 265 seconds) |
| 07:55:09 | | Join munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
| 08:00 |
| 08:11:06 | | Quit munkis (Remote host closed the connection) |
| 08:11:08 | *** | Saving seen data "./dancer.seen" |
| 08:11:30 | | Join munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
| 08:17:13 | munkis | well it took a year but someone complained about g#2960 |
| 08:17:16 | rb-bluebot | Gerrit review #2960 at https://gerrit.rockbox.org/r/c/rockbox/+/2960 : Quickscreen: don't apply glabal settings by Moshe Piekarski |
| 08:18:32 | munkis | aaalthough I think the bug in fs#13319 is the inverse of the report. |
| 08:18:33 | rb-bluebot | https://www.rockbox.org/tracker/task/13319 Default Sleep Timer Duration shows different behavior when changed from a shortcut (bugs, unconfirmed) |
| 08:18:56 | munkis | oh wait nvm different par tof the code |
| 08:19:21 | munkis | (although I still think the expected behavior is strange) |
| 08:46:10 | | Join massiveH [0] (~massiveH@ool-4a5862ee.dyn.optonline.net) |
| 09:00 |
| 09:48:00 | _bilgus | munkis not setting till later seems odd is it just missing the setting_save() |
| 09:48:01 | _bilgus | ? |
| 09:49:21 | | Join chris_s [0] (~chris_s@ip-95-223-74-199.hsi16.unitymediagroup.de) |
| 09:49:40 | chris_s | I think the Settings menu does additional work in the callback method to actually change the running timer duration |
| 09:55:22 | | Quit chris_s (Quit: Connection closed) |
| 09:56:25 | _bilgus | I was thinking the current way where we emulate the menu item isn't so great but I don't know that pulling you to the menu is possible (currently not) |
| 09:58:24 | _bilgus | the problem being that no one ever set a way to expand the menus without the user clicking them |
| 10:00 |
| 10:03:11 | munkis | _bilgus: i fell like changing the default timer length shouldn't suddenly affect a running timer. |
| 10:05:11 | _bilgus | IDK probably it should ask I think both might be desired depending on the user |
| 10:07:47 | | Join chris_s [0] (~chris_s@ip-95-223-74-199.hsi16.unitymediagroup.de) |
| 10:08:42 | | Join aaronamm [0] (~aaronamm@146.88.46.49) |
| 10:09:43 | chris_s | Would probably make sense to change the name to "Sleep Timer Duration" (i.e. remove the "default") |
| 10:10:07 | | Quit chris_s (Client Quit) |
| 10:11:11 | *** | Saving seen data "./dancer.seen" |
| 10:13:34 | | Join chris_s [0] (~chris_s@ip-95-223-74-199.hsi16.unitymediagroup.de) |
| 10:13:59 | _bilgus | yeah default makes it sound like it should have the behaviour munkis is saying |
| 10:14:00 | | Quit chris_s (Client Quit) |
| 10:17:05 | | Quit massiveH (Quit: Leaving) |
| 11:00 |
| 11:24:06 | | Quit paulcarroty (K-Lined) |
| 11:24:08 | | Quit kadoban (K-Lined) |
| 11:24:10 | | Quit blbro[m] (K-Lined) |
| 11:24:11 | | Quit MayeulC (K-Lined) |
| 11:35:03 | | Join kadoban [0] (~kadoban@user/kadoban) |
| 11:38:29 | | Quit zizzy (Ping timeout: 264 seconds) |
| 11:39:45 | | Quit asaba (Quit: Relay server offline) |
| 11:40:03 | | Quit hook54321 (Read error: Connection reset by peer) |
| 11:41:49 | | Join zizzy [0] (sid385519@lymington.irccloud.com) |
| 11:42:44 | | Join asaba [0] (~asabas@103.113.159.250) |
| 11:43:28 | | Join paulcarroty [0] (~paulcarro@2001:470:69fc:105::216) |
| 11:43:28 | | Join MayeulC [0] (~mayeulc@2001:470:69fc:105::35e) |
| 11:43:40 | | Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7) |
| 11:45:37 | | Join hook54321 [0] (sid149355@user/hook54321) |
| 11:59:31 | | Quit kadoban (Quit: Client limit exceeded: 20000) |
| 12:00 |
| 12:00:04 | | Quit paulcarroty (Quit: Client limit exceeded: 20000) |
| 12:00:06 | | Quit MayeulC (Quit: Client limit exceeded: 20000) |
| 12:11:14 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 13:07:15 | | Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) |
| 13:11:47 | | Quit ZincAlloy (Ping timeout: 264 seconds) |
| 13:12:29 | | Quit munkis (Remote host closed the connection) |
| 13:12:54 | | Join munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) |
| 13:29:33 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:dc45:d26:4c5d:c799) |
| 13:29:55 | | Quit j-r (Remote host closed the connection) |
| 13:31:23 | | Join lebellium [0] (~lebellium@2a01cb04012c09005939187678873d1a.ipv6.abo.wanadoo.fr) |
| 13:49:14 | | Join amachronic [0] (~amachroni@user/amachronic) |
| 13:55:00 | | Join j-r [0] (~j-r@p2003000623cebf71404207fffefd0a65.dip0.t-ipconnect.de) |
| 13:58:23 | amachronic | speachy: so the x3 is still panicking on USB insert and you got a log of that? |
| 13:58:32 | | Join kadoban [0] (~kadoban@user/kadoban) |
| 13:58:32 | | Join paulcarroty [0] (~paulcarro@2001:470:69fc:105::216) |
| 13:58:32 | | Join MayeulC [0] (~mayeulc@2001:470:69fc:105::35e) |
| 13:59:55 | amachronic | i made a test build anyway which might give more useful logs if you'd like to try it |
| 14:00 |
| 14:00:03 | amachronic | https://drive.google.com/file/d/1bs6lMfekT9KF25AAWJCOix7T-x6FA46D/view?usp=sharing |
| 14:03:44 | rb-bluebot | Build Server message: New build round started. Revision 6e61e6f0c8, 303 builds, 10 clients. |
| 14:11:16 | *** | Saving seen data "./dancer.seen" |
| 14:12:27 | | Join jschwart [0] (~quassel@2001:985:2c6e:0:b00b:32ff:fe28:5567) |
| 14:13:56 | rb-bluebot | Build Server message: Build round completed after 612 seconds. |
| 14:13:58 | rb-bluebot | Build Server message: Revision 6e61e6f0c8 result: All green |
| 14:14:55 | rb-bluebot | Build Server message: New build round started. Revision 701d4ba77e, 303 builds, 10 clients. |
| 14:20:23 | | Quit aaronamm (Quit: Connection closed) |
| 14:23:01 | speachy | amachronic: yeah, I've been trying to wade into it. the screen's so tiny that there's only a handful of logged lines |
| 14:23:17 | speachy | so I've been trying to get hardware sniffs but my sniffer is being churlish. |
| 14:23:42 | amachronic | well, the build I made hopefully won't panic so you can do a normal log file dump from the debug menu. |
| 14:24:02 | amachronic | debugging via panic is a PITA. |
| 14:24:19 | rb-bluebot | Build Server message: Build round completed after 563 seconds. |
| 14:24:20 | rb-bluebot | Build Server message: Revision 701d4ba77e result: All green |
| 14:24:53 | speachy | I've been adding additonal instrumentation to try and sort out the flow |
| 14:25:33 | speachy | amachronic: https://www.shaftnet.org/~pizza/x3.txt |
| 14:25:39 | speachy | that's my WIP notes from this |
| 14:27:06 | speachy | that's one of two panic sequences (by far the most common) |
| 14:27:55 | amachronic | most likely its all some tiny deviation from the old behavior which I unintentionally created |
| 14:28:20 | speachy | ... and the driver is doing something "special" |
| 14:28:32 | amachronic | my test build has all requests logged, i used it on fs13315/fs13316 to sort out the mess on ipod. |
| 14:28:56 | amachronic | which turned out to be the ARC driver submitting endpoint completes for EP0 for every control packet |
| 14:29:09 | amachronic | or rather, setup packet |
| 14:36:20 | amachronic | doing nothing on a zero-length send/recv sounds a bit odd though. |
| 14:37:53 | amachronic | but I guess it must've worked before |
| 14:44:52 | speachy | ok, I have a full logf if you want |
| 14:45:02 | amachronic | sure |
| 14:46:17 | speachy | https://www.shaftnet.org/~pizza/logf-1.txt |
| 14:48:27 | speachy | we get what appears to be a spurious interrupt, then one with OUTPKTRDY, which feeds into the ctrl received 751 |
| 14:49:13 | speachy | drv_recv, drv_send, ctrl handled 751, then the null ctrl req (twice) with the same arguments |
| 14:53:12 | amachronic | huh. it's hard to see what's wrong since we're missing most of the usb_core API side of things. |
| 14:53:33 | speachy | hmm, a GET_DESCRIPTOR seems comes in before the GET_INTERFACE is apparently handled/responded to |
| 14:54:01 | amachronic | i am only guessing but maybe a new packet is getting submitted before the last one has been properly acked? |
| 14:54:58 | amachronic | that'd explain why zero-length send/recv being a no-op works −− the driver is acking the packet before the core has handled it |
| 14:55:33 | speachy | yeah... the driver/hardware would appear to be handling it. |
| 15:00 |
| 15:00:24 | amachronic | am I right that this is the jz47xx's USB controller? |
| 15:00:28 | amachronic | https://dl.linux-sunxi.org/users/tom/musbmhdrc_pspgUSB.pdf |
| 15:00:30 | speachy | ... 4760, yes |
| 15:01:04 | amachronic | (I'm trying to figure out how they think setup transactions should be handled) |
| 15:01:26 | speachy | yeah. I did a lot of work on this thing but I didn't change the control stuff at all |
| 15:02:12 | amachronic | ok. i also noticed the 4740 seems to be the same controller, yet we have two drivers. :/ |
| 15:02:42 | speachy | no ability to test the newer driver on the -40 hardware. : |
| 15:03:06 | speachy | ok, just disabled the "if control ep and null packet, skip" test. |
| 15:05:04 | amachronic | it seems setting DataEnd is how you tell the controller the request is handled so I guess it's being set too early by the driver |
| 15:09:59 | speachy | https://www.shaftnet.org/~pizza/logf-2.txt |
| 15:10:08 | amachronic | yeah any non-data request won't wait until the usb stack acks so the driver will just proceed ahead with a new packet. |
| 15:10:33 | speachy | still see the two null reqs but now there's something sent over between 'em. |
| 15:21:56 | amachronic | the order of things should always be "ctrl received" - "ctrl handled" - "ctrl response" and it looks like that isn't happening. |
| 15:25:38 | speachy | making sense of this mess seems to be a necessary prereq for reworking it to use the new API natively |
| 15:25:40 | amachronic | ctrl received 765, req=0x6 shouldn't happen until *after* the recv/send pair right below it |
| 15:26:13 | speachy | yeah, this is why I want to see traffic sniffs |
| 15:27:10 | amachronic | I'm pretty sure it's just an "obvious" driver bug. there's nothing too crazy going on. |
| 15:27:43 | amachronic | one look at that EP0_handler ... I'm not surprised you're afraid to touch it :D |
| 15:27:43 | speachy | the control endpoints have a ton of special casing |
| 15:28:04 | amachronic | yep, and every controller has some special snowflake way of doing it. |
| 15:44:51 | speachy | I don't see a SETUPEND ever triggered, and that's what triggers teh transfer_complete() call for blockning EP0 writes (which I think is all of them) |
| 15:46:36 | speachy | and we nver check solely for DATAEND for EP0.... |
| 15:47:10 | amachronic | the comment in SETUPEND explains it's only for retried packets |
| 15:47:30 | amachronic | ie. only if from the controller perspective, the request is being handled and a new one from the host interrupts it. |
| 15:47:47 | amachronic | DATAEND is something the CPU sets, not the controller |
| 15:48:22 | amachronic | eg. L317 and L330 |
| 15:48:34 | amachronic | also L246 |
| 15:48:50 | speachy | ok. |
| 15:49:18 | speachy | REG_USB_INTRUSB has bit 3 set (ie 0x08) in some of the interrupts, that's not handled (or even documented) in the jz headers. |
| 15:49:50 | speachy | seems to happen after the drv_send()s |
| 15:50:31 | amachronic | according to the MUSB doc that's SOF = Set when a new frame starts. |
| 15:54:18 | amachronic | this controller seems to provide a packet-at-a-time interface for EP0 much like the dwc2 controller. |
| 15:55:01 | amachronic | question is how do you figure out a setup packet arrived vs. a normal data packet or do you need to guess. |
| 16:00 |
| 16:02:56 | amachronic | ... and it sounds like the driver needs to track that state itself. |
| 16:03:05 | speachy | yep |
| 16:03:12 | speachy | and I suppose that's where things are going wonky |
| 16:08:37 | | Join johnb5 [0] (~johnb2@p5b3aff7b.dip0.t-ipconnect.de) |
| 16:09:24 | amachronic | that MUSBMHDRC manual is reasonably clear about how to handle things. |
| 16:09:40 | amachronic | should be easy to map onto the new API |
| 16:11:17 | *** | Saving seen data "./dancer.seen" |
| 16:12:31 | amachronic | I'd just rip out all the EP0 handler bits and rewrite 'em. not worth the effort to refactor IMHO. |
| 16:12:38 | speachy | yeah |
| 16:12:58 | speachy | I was hoping to get it back to "working" first so it would be useful as a reference |
| 16:13:01 | speachy | but eh |
| 16:13:02 | | Quit johnb5 (Ping timeout: 260 seconds) |
| 16:15:16 | amachronic | just removing the panic should put it back to "working" |
| 16:16:01 | amachronic | i figure the OS would retry if it got bogus data so bugs were silently papered over by retrying the request |
| 16:17:37 | speachy | without the panic it comes up with HID but mass storage isn't working. |
| 16:18:00 | amachronic | oh. |
| 16:18:19 | speachy | (it enumerates but doesn't find an actual drive) |
| 16:19:28 | amachronic | I did put in intentional deviations from the old behavior for control writes, which HID happens to exercise. |
| 16:19:57 | amachronic | turning off HID could make the drive appear |
| 16:30:13 | | Join wsa [0] (~wsa@p5486cca9.dip0.t-ipconnect.de) |
| 16:30:14 | speachy | nope |
| 16:33:08 | amachronic | oh well |
| 16:34:22 | wsa | hi, I just pushed an updated patch of RDS support for the Sansa Clip+ |
| 16:34:58 | wsa | I'll be around a little more in case somebody wants to discuss it |
| 16:38:52 | wsa | and as the RDS polling is now generic, if someone could test the conversion of the Samsung YPR0/1 which I also pushed... that would be awesome |
| 16:40:20 | speachy | thank you! |
| 16:43:44 | | Quit amachronic (Quit: amachronic) |
| 16:43:47 | speachy | let's change the ypr0|1 rds polling to the same as the clip |
| 16:44:00 | speachy | donig it on every tick seems excessive. |
| 16:44:22 | rb-bluebot | Build Server message: New build round started. Revision de0346065b, 303 builds, 10 clients. |
| 16:46:32 | speachy | wsa: can you do that with #3972 and resubmit? |
| 16:46:47 | wsa | is one tick the same on every target? |
| 16:46:54 | wsa | speachy: sure thing |
| 16:52:01 | wsa | done |
| 16:53:40 | wsa | speachy: oh wow, you merged it already, thanks! |
| 16:54:17 | speachy | it was a much cleaner approach than the original IMO |
| 16:54:34 | speachy | with no obvious issues, so.. why let it sit? |
| 16:54:58 | speachy | (the original patch all of this was based on has been in gerrit since 2012...) |
| 16:55:33 | wsa | Yes, the improvements from one version to the next were always good, I think |
| 16:55:49 | wsa | just a pity it was always 5 years between the versions :/ |
| 16:56:15 | rb-bluebot | Build Server message: Build round completed after 713 seconds. |
| 16:56:16 | rb-bluebot | Build Server message: Revision de0346065b result: All green |
| 16:56:20 | rb-bluebot | Build Server message: New build round started. Revision 336ea51af6, 303 builds, 9 clients. |
| 16:56:22 | speachy | I've been distrated by other stuff lately but what really got me involved with rockbox was not wanting to see a large pile of third-party contributions/patches/etc continue to languish |
| 16:56:41 | wsa | I wasn't sure if RDS_CFG_POLL was acceptable, I am glad it is... |
| 16:57:13 | speachy | it was that or add HAVE_RDS_POLL |
| 16:57:20 | wsa | speachy: I am with you there |
| 16:57:44 | speachy | since we already had CONFIG_RDS as a bitmask, it was the right call IMO |
| 16:58:01 | wsa | I am definately not short of tasks, but having this device and seeing these RDS patches was an itch I just had to scratch |
| 17:00 |
| 17:08:38 | rb-bluebot | Build Server message: Build round completed after 739 seconds. |
| 17:08:39 | rb-bluebot | Build Server message: Revision 336ea51af6 result: All green |
| 17:10:59 | wsa | for the record, I also checked the GPIO ports when receiving RDS data for some other pin toggling indicating an RDS interrupt |
| 17:11:05 | wsa | no surprise, there was none |
| 17:19:24 | | Join cockroach [0] (~blattodea@user/cockroach) |
| 17:30:06 | speachy | amachronic: btw the 4740 vs 4760 share the same licensed core, but the -40 only has 5 endpoints and the -60 seems to have the full set of 16. |
| 17:30:49 | speachy | (another difference is that the -40 can't do an INTERRUPT OUT endpoint..) |
| 17:32:49 | | Quit ZincAlloy (Quit: Leaving.) |
| 17:34:23 | | Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:c52c:f3a1:3b3b:ea2b) |
| 18:00 |
| 18:11:19 | *** | Saving seen data "./dancer.seen" |
| 18:12:11 | | Quit wsa (Quit: ...) |
| 18:15:32 | | Quit lebellium (Ping timeout: 240 seconds) |
| 18:19:00 | | Join lebellium [0] (~lebellium@2a01cb04012c09005939187678873d1a.ipv6.abo.wanadoo.fr) |
| 18:26:13 | | Quit ZincAlloy (Quit: Leaving.) |
| 18:38:32 | | Quit lebellium (Quit: Leaving) |
| 18:44:01 | | Quit tchan (Ping timeout: 265 seconds) |
| 18:50:53 | | Join Solanacean [0] (solanacean@176.214.16.178) |
| 18:52:27 | | Quit Solanacean_ (Ping timeout: 250 seconds) |
| 19:00 |
| 19:02:14 | | Join tchan [0] (~tchan@c-98-206-141-238.hsd1.il.comcast.net) |
| 20:00 |
| 20:11:20 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:13:38 | | Quit cockroach (Quit: leaving) |
| 21:34:02 | | Quit j-r (Ping timeout: 240 seconds) |
| 21:34:33 | | Join j-r [0] (~j-r@p2003000623cebf96404207fffefd0a65.dip0.t-ipconnect.de) |
| 22:00 |
| 22:11:23 | *** | Saving seen data "./dancer.seen" |
icon identifies that the person is a core developer (has commit access).