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 | 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 2021-11-18

00:10:57***No seen item changed, no save performed.
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] (
01:58:41 Quit ZincAlloy (Ping timeout: 265 seconds)
02:11:01***Saving seen data "./dancer.seen"
04:00:18aaronamm_bilgus Thank you so much so much for your suggestion. This is very useful. It time for me to learn Lua script.
04:00:27aaronammThanks again.
04:00:56aaronammBTW, I have post to the forum as well. I think I will post your suggest there.
04:01:33aaronammIt can be useful for others.
04:02:15aaronamm@braewoods I agree with you that is not convenient. It just my personal hobby.
04:02:53aaronammHere is my website, most contents are in Thai, some are English but Google translator should be okay.
04:05:15aaronammUsing 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:11aaronammIn fact, I usually use Net MD and here is my manual for Web MiniDisc.
04:11:02***No seen item changed, no save performed.
04:55:33 Quit aaronamm (Quit: Connection closed)
06:11:04***Saving seen data "./dancer.seen"
07:37:40 Quit munkis (Ping timeout: 265 seconds)
07:55:09 Join munkis [0] (
08:11:06 Quit munkis (Remote host closed the connection)
08:11:08***Saving seen data "./dancer.seen"
08:11:30 Join munkis [0] (
08:17:13munkiswell it took a year but someone complained about g#2960
08:17:16rb-bluebotGerrit review #2960 at : Quickscreen: don't apply glabal settings by Moshe Piekarski
08:18:32munkisaaalthough I think the bug in fs#13319 is the inverse of the report.
08:18:33rb-bluebot Default Sleep Timer Duration shows different behavior when changed from a shortcut (bugs, unconfirmed)
08:18:56munkisoh wait nvm different par tof the code
08:19:21munkis(although I still think the expected behavior is strange)
08:46:10 Join massiveH [0] (
09:48:00_bilgusmunkis not setting till later seems odd is it just missing the setting_save()
09:49:21 Join chris_s [0] (
09:49:40chris_sI 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_bilgusI 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_bilgusthe problem being that no one ever set a way to expand the menus without the user clicking them
10:03:11munkis_bilgus: i fell like changing the default timer length shouldn't suddenly affect a running timer.
10:05:11_bilgusIDK probably it should ask I think both might be desired depending on the user
10:07:47 Join chris_s [0] (
10:08:42 Join aaronamm [0] (~aaronamm@
10:09:43chris_sWould 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] (
10:13:59_bilgusyeah 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: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] (
11:42:44 Join asaba [0] (~asabas@
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: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:07:15 Join ZincAlloy [0] (
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] (
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] (
13:49:14 Join amachronic [0] (~amachroni@user/amachronic)
13:55:00 Join j-r [0] (
13:58:23amachronicspeachy: 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:55amachronici made a test build anyway which might give more useful logs if you'd like to try it
14:03:44rb-bluebotBuild 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:56rb-bluebotBuild Server message: Build round completed after 612 seconds.
14:13:58rb-bluebotBuild Server message: Revision 6e61e6f0c8 result: All green
14:14:55rb-bluebotBuild Server message: New build round started. Revision 701d4ba77e, 303 builds, 10 clients.
14:20:23 Quit aaronamm (Quit: Connection closed)
14:23:01speachyamachronic: 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:17speachyso I've been trying to get hardware sniffs but my sniffer is being churlish.
14:23:42amachronicwell, the build I made hopefully won't panic so you can do a normal log file dump from the debug menu.
14:24:02amachronicdebugging via panic is a PITA.
14:24:19rb-bluebotBuild Server message: Build round completed after 563 seconds.
14:24:20rb-bluebotBuild Server message: Revision 701d4ba77e result: All green
14:24:53speachyI've been adding additonal instrumentation to try and sort out the flow
14:25:39speachythat's my WIP notes from this
14:27:06speachythat's one of two panic sequences (by far the most common)
14:27:55amachronicmost likely its all some tiny deviation from the old behavior which I unintentionally created
14:28:20speachy... and the driver is doing something "special"
14:28:32amachronicmy test build has all requests logged, i used it on fs13315/fs13316 to sort out the mess on ipod.
14:28:56amachronicwhich turned out to be the ARC driver submitting endpoint completes for EP0 for every control packet
14:29:09amachronicor rather, setup packet
14:36:20amachronicdoing nothing on a zero-length send/recv sounds a bit odd though.
14:37:53amachronicbut I guess it must've worked before
14:44:52speachyok, I have a full logf if you want
14:48:27speachywe get what appears to be a spurious interrupt, then one with OUTPKTRDY, which feeds into the ctrl received 751
14:49:13speachydrv_recv, drv_send, ctrl handled 751, then the null ctrl req (twice) with the same arguments
14:53:12amachronichuh. it's hard to see what's wrong since we're missing most of the usb_core API side of things.
14:53:33speachyhmm, a GET_DESCRIPTOR seems comes in before the GET_INTERFACE is apparently handled/responded to
14:54:01amachronici am only guessing but maybe a new packet is getting submitted before the last one has been properly acked?
14:54:58amachronicthat'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:33speachyyeah... the driver/hardware would appear to be handling it.
15:00:24amachronicam I right that this is the jz47xx's USB controller?
15:00:30speachy... 4760, yes
15:01:04amachronic(I'm trying to figure out how they think setup transactions should be handled)
15:01:26speachyyeah. I did a lot of work on this thing but I didn't change the control stuff at all
15:02:12amachronicok. i also noticed the 4740 seems to be the same controller, yet we have two drivers. :/
15:02:42speachyno ability to test the newer driver on the -40 hardware. :
15:03:06speachyok, just disabled the "if control ep and null packet, skip" test.
15:05:04amachronicit 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:10:08amachronicyeah 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:33speachystill see the two null reqs but now there's something sent over between 'em.
15:21:56amachronicthe order of things should always be "ctrl received" - "ctrl handled" - "ctrl response" and it looks like that isn't happening.
15:25:38speachymaking sense of this mess seems to be a necessary prereq for reworking it to use the new API natively
15:25:40amachronicctrl received 765, req=0x6 shouldn't happen until *after* the recv/send pair right below it
15:26:13speachyyeah, this is why I want to see traffic sniffs
15:27:10amachronicI'm pretty sure it's just an "obvious" driver bug. there's nothing too crazy going on.
15:27:43amachronicone look at that EP0_handler ... I'm not surprised you're afraid to touch it :D
15:27:43speachythe control endpoints have a ton of special casing
15:28:04amachronicyep, and every controller has some special snowflake way of doing it.
15:44:51speachyI 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:36speachyand we nver check solely for DATAEND for EP0....
15:47:10amachronicthe comment in SETUPEND explains it's only for retried packets
15:47:30amachronicie. only if from the controller perspective, the request is being handled and a new one from the host interrupts it.
15:47:47amachronicDATAEND is something the CPU sets, not the controller
15:48:22amachroniceg. L317 and L330
15:48:34amachronicalso L246
15:49:18speachyREG_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:50speachyseems to happen after the drv_send()s
15:50:31amachronicaccording to the MUSB doc that's SOF = Set when a new frame starts.
15:54:18amachronicthis controller seems to provide a packet-at-a-time interface for EP0 much like the dwc2 controller.
15:55:01amachronicquestion is how do you figure out a setup packet arrived vs. a normal data packet or do you need to guess.
16:02:56amachronic... and it sounds like the driver needs to track that state itself.
16:03:12speachyand I suppose that's where things are going wonky
16:08:37 Join johnb5 [0] (
16:09:24amachronicthat MUSBMHDRC manual is reasonably clear about how to handle things.
16:09:40amachronicshould be easy to map onto the new API
16:11:17***Saving seen data "./dancer.seen"
16:12:31amachronicI'd just rip out all the EP0 handler bits and rewrite 'em. not worth the effort to refactor IMHO.
16:12:58speachyI was hoping to get it back to "working" first so it would be useful as a reference
16:13:01speachybut eh
16:13:02 Quit johnb5 (Ping timeout: 260 seconds)
16:15:16amachronicjust removing the panic should put it back to "working"
16:16:01amachronici figure the OS would retry if it got bogus data so bugs were silently papered over by retrying the request
16:17:37speachywithout the panic it comes up with HID but mass storage isn't working.
16:18:19speachy(it enumerates but doesn't find an actual drive)
16:19:28amachronicI did put in intentional deviations from the old behavior for control writes, which HID happens to exercise.
16:19:57amachronicturning off HID could make the drive appear
16:30:13 Join wsa [0] (
16:33:08amachronicoh well
16:34:22wsahi, I just pushed an updated patch of RDS support for the Sansa Clip+
16:34:58wsaI'll be around a little more in case somebody wants to discuss it
16:38:52wsaand 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:20speachythank you!
16:43:44 Quit amachronic (Quit: amachronic)
16:43:47speachylet's change the ypr0|1 rds polling to the same as the clip
16:44:00speachydonig it on every tick seems excessive.
16:44:22rb-bluebotBuild Server message: New build round started. Revision de0346065b, 303 builds, 10 clients.
16:46:32speachywsa: can you do that with #3972 and resubmit?
16:46:47wsais one tick the same on every target?
16:46:54wsaspeachy: sure thing
16:53:40wsaspeachy: oh wow, you merged it already, thanks!
16:54:17speachyit was a much cleaner approach than the original IMO
16:54:34speachywith no obvious issues, so.. why let it sit?
16:54:58speachy(the original patch all of this was based on has been in gerrit since 2012...)
16:55:33wsaYes, the improvements from one version to the next were always good, I think
16:55:49wsajust a pity it was always 5 years between the versions :/
16:56:15rb-bluebotBuild Server message: Build round completed after 713 seconds.
16:56:16rb-bluebotBuild Server message: Revision de0346065b result: All green
16:56:20rb-bluebotBuild Server message: New build round started. Revision 336ea51af6, 303 builds, 9 clients.
16:56:22speachyI'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:41wsaI wasn't sure if RDS_CFG_POLL was acceptable, I am glad it is...
16:57:13speachyit was that or add HAVE_RDS_POLL
16:57:20wsaspeachy: I am with you there
16:57:44speachysince we already had CONFIG_RDS as a bitmask, it was the right call IMO
16:58:01wsaI am definately not short of tasks, but having this device and seeing these RDS patches was an itch I just had to scratch
17:08:38rb-bluebotBuild Server message: Build round completed after 739 seconds.
17:08:39rb-bluebotBuild Server message: Revision 336ea51af6 result: All green
17:10:59wsafor the record, I also checked the GPIO ports when receiving RDS data for some other pin toggling indicating an RDS interrupt
17:11:05wsano surprise, there was none
17:19:24 Join cockroach [0] (~blattodea@user/cockroach)
17:30:06speachyamachronic: 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:49speachy(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: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] (
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@
18:52:27 Quit Solanacean_ (Ping timeout: 250 seconds)
19:02:14 Join tchan [0] (
20:11:20***Saving seen data "./dancer.seen"
21:13:38 Quit cockroach (Quit: leaving)
21:34:02 Quit j-r (Ping timeout: 240 seconds)
21:34:33 Join j-r [0] (
22:11:23***Saving seen data "./dancer.seen"

Previous day | Next day