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 2021-05-30

00:25:49***Saving seen data "./dancer.seen"
01:02:21 Quit Arsen (Changing host)
01:02:21 Join Arsen [0] (~arsen@managarm/dev/Arsen)
01:44:55 Join mendel_munkis_ [0] (
01:47:34 Quit mendel_munkis (Ping timeout: 264 seconds)
02:25:52***Saving seen data "./dancer.seen"
03:04:43 Join daswf8526 [0] (~daswf852@user/daswf852)
03:05:12 Join daswf8522 [0] (~daswf852@user/daswf852)
03:06:18 Quit daswf852 (Ping timeout: 264 seconds)
03:09:45 Quit daswf8526 (Ping timeout: 268 seconds)
03:10:29 Quit daswf8522 (Ping timeout: 265 seconds)
03:13:52 Join daswf852 [0] (~daswf852@user/daswf852)
03:15:54 Join daswf8523 [0] (~daswf852@user/daswf852)
03:20:14 Quit daswf852 (Ping timeout: 268 seconds)
03:20:15 Nick daswf8523 is now known as daswf852 (~daswf852@user/daswf852)
04:04:11 Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:d888:b44d:5bcf:1ff3)
04:25:56***Saving seen data "./dancer.seen"
04:35:16 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
06:25:59***No seen item changed, no save performed.
06:56:38 Quit bertrik (Quit: "This incident will be reported")
07:32:20 Join pablocastellano1 [0] (
07:34:30 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
07:35:37 Quit pablocastellanos (Ping timeout: 268 seconds)
08:26:04***Saving seen data "./dancer.seen"
08:45:25 Quit pablocastellano1 (Quit: Leaving.)
08:45:37 Join pablocastellanos [0] (~pidgin@user/pablocastellanos)
09:26:24 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
09:37:44 Join dconrad [0] (~dconrad@
09:50:20 Join user890104 [0] (
09:56:00 Quit user890104 (Quit: user890104)
10:26:07***Saving seen data "./dancer.seen"
10:59:38 Join E14n [0] (
11:19:23 Quit pablocastellanos (Ping timeout: 268 seconds)
11:20:58 Join pablocastellanos [0] (~pidgin@user/pablocastellanos)
11:45:07 Join amachronic [0] (~amachroni@user/amachronic)
11:45:53amachronicdconrad: just happened to notice your changes in gerrit, fyi that TLB refill exception is a null pointer dereference.
11:46:16amachronicif you still have the from that build you can trace down where it occurs.
11:48:58dconradIt seems to happen on any of the builds I'm trying, tbh I'm laser focused on the button thing right now
11:49:23dconradif you're curious I can send it to you though
11:50:01dconrad(ps, I hope I'm not spamming your inbox with my notes on 3437!)
11:50:02amachronicnah it's alright I have had that happen to me too I just didn't bother investigating it either.
11:50:23amachronicI'm not CC'd on 3437 so no spamming here :)
11:50:54amachronicjust a thought perhaps the issue with the USB screen is that the yesno dialog runs from the USB thread.
11:51:05dconradyeah, that's kinda my thought
11:51:12amachronicmaybe it causes something to be subtly broken
11:51:32dconradmy thought was maybe it needs a higher priority, but that doesn't seem to make a difference
11:52:23dconradnow that I have the timing down, I can kinda get it to work more often, it just seems like it needs to be held a little longer
11:52:42dconradwhich is obvs not a fix, but a clue
11:53:58dconradI'm honestly just kind of out of my depth here, but I'm trying stuff anyway
11:54:50amachronicWell I am looking at the usb ask dialog and I think it runs before it notifies any other thread that the USB was plugged.
11:55:44dconradI wasn't sure if there were other usb stuff that might happen alongside the main usb thread or not
11:56:15amachronicperhaps it's a reentrant call of get_action −− USB and main thread calling it simultaneously −− which I don't think would work.
11:56:38 Join berylline [0] (
11:56:46 Part berylline
11:57:20dconradcould be, though I'm not sure where the main thread would be calling it from?
11:57:40dconradoh, of get_action()
11:57:41amachronicwell if the USB thread did not notify anybody then the main thread will be waiting in the menu or WPS or whereever
11:57:57dconradoh, I see
11:57:59amachronicbasically get_action is the idle loop
11:58:16amachronic(as rockbox is always waiting for key input)
11:58:46dconradhow does notifying another thread work? is that related to the activity stack?
11:59:06 Join JackDupp [0] (~dj@
11:59:18amachronicit's ad hoc depends on the thread from what I've seen. usually it's a queue.
11:59:36amachronicin case of USB it sends SYS_USB_CONNECTED and a lot of code watches for that.
11:59:49dconradI see
12:00:52amachronicalthough I'm talking about the native USB not sure how hosted USB works tbh. must be mostly the same in terms of how it interacts with the GUI code though
12:01:53dconradI'm kind of confused about the usb defines, but I /think/ the hosted still has "full_usbstack" so yeah I think they should be the same for this
12:03:01dconradbtw, holy moly are the usb defines a mess haha
12:03:10dconradso confusing
12:03:13amachronicfortunately I got to use an existing driver for the M3K's USB so I didn't have to understand it either :)
12:05:38 Quit E14n (Ping timeout: 268 seconds)
12:12:10 Join E14n [0] (
12:13:26 Part E14n
12:26:08***Saving seen data "./dancer.seen"
12:35:44 Quit CasBot (Remote host closed the connection)
12:37:39 Join CasBot [0] (
12:38:24 Quit CasBot (Remote host closed the connection)
12:38:37 Join CasBot [0] (
12:42:39 Quit CasBot (Remote host closed the connection)
12:43:01 Join CasBot [0] (
12:47:26 Quit CasBot (Remote host closed the connection)
12:47:50 Join CasBot [0] (
13:33:37dconradamachronic, so here's something weird - if I add a check to see if the current activity is ACTIVITY_USBSCREEN and do not call get_action() from do_menu() if so, it breaks all button events in the yes/no screen
13:34:12dconradso basically "if (activity is USBSCREEN), then do not call get_activity()"
13:34:29dconradand it breaks it completely, which.... does not jive with my understanding of how this all works???
13:35:10dconrader... get_activity() −−> get_action()
13:37:27amachronicokaaay... it appears that would be expected
13:37:45amachronicbecause get_action might return SYS_USB_CONNECTED
13:37:45dconradI don't think my understanding is correct haha
13:38:19amachronicor maybe not, rather default_event_handler takes the action and returns SYS_USB_CONNECTED.
13:39:05amachronicso if it doesn't call get_action() the main thread would block and I guess things freeze up.
13:39:19dconradI guess I don't get why not calling get_action() from do_menu() would break calling get_action() from gui_syncyesno_run()
13:39:47amachronicme neither :P
13:40:01amachronicbut IMHO the bug is having the USB thread do GUI work.
13:41:11amachronicer, sorry, I think I do understand why not calling get_action in the main thread breaks things: that's how it gets notified of the USB connect event
13:41:41dconradbut isn't the usb connect event not sent until after the yes/no screen?
13:42:02amachronicyeah as far as I can tell.
13:42:03 Join ats_ [0] (
13:42:06dconradhm, weird
13:42:12amachronicokay I see your point.
13:42:40dconradre: USB thread doing gui work: that sounds really logical, some sort of signal between threads to have it call the yes/no screen?
13:43:22dconradboy this is /way/ deeper than I've ever been into a software codebase
13:43:45amachronicyes, the whole asking functionality is "new". I figure whoever did it didn't want to sort out the mess of understanding all the signaling involved.
13:44:08 Quit ats (Ping timeout: 265 seconds)
13:44:17amachronicmore like, "it seems to work so let's merge it"
13:54:46 Join actinium [0] (~actinium@gateway/tor-sasl/actinium)
13:57:11amachronicdconrad: patch adding the USB prompt = g#2972
13:57:13rb-bluebot_Gerrit review #2972 at : usb: Add ability to prompt user about what to do upon usb insertion by Solomon Peachy
13:58:07amachroniclooks like half implemented is the better explanation...
13:58:14dconradboy, that's way newer than I expected
13:58:25amachronicat least speachy is still around to ask about it :)
13:58:27 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
13:58:32dconradI figured it would've been added in like... 2005 or something
13:58:55amachronicLOL by "new" I meant "sometime after 2014"
13:59:14dconradhmm, maybe I'll have to pick his brain about it
14:08:14 Nick ats_ is now known as ats (
14:19:07 Nick mendel_munkis_ is now known as mendel_munkis (
14:19:20mendel_munkisany idea what the reason for this is?
14:20:03mendel_munkis(ignoring 0 when it is the first digit of an operand)
14:24:40amachronicmendel_munkis: maybe to avoid hassle with leading zeros?
14:26:11***Saving seen data "./dancer.seen"
14:45:33 Quit ats (Quit: PSU swap)
14:46:39 Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7)
15:13:28 Join ats [0] (
15:23:44rb-bluebot_Build Server message: New build round started. Revision f63edb52ef, 297 builds, 10 clients.
15:34:37rb-bluebot_Build Server message: Build round completed after 654 seconds.
15:34:41rb-bluebot_Build Server message: Revision f63edb52ef result: All green
16:04:48 Quit dconrad (Remote host closed the connection)
16:17:11 Join dconrad [0] (~dconrad@
16:22:03 Quit dconrad (Ping timeout: 272 seconds)
16:26:12***Saving seen data "./dancer.seen"
16:32:49 Quit actinium (Ping timeout: 252 seconds)
16:40:47 Quit f1refly (Read error: Connection reset by peer)
16:42:30 Join f1refly [0] (
16:42:33 Quit lebellium (Quit: Leaving)
16:43:49 Quit amachronic (Quit: amachronic)
18:26:16***Saving seen data "./dancer.seen"
18:36:57 Quit kadoban (Quit: quit)
20:26:20***Saving seen data "./dancer.seen"
22:26:21***No seen item changed, no save performed.
23:14:13 Join daswf8528 [0] (~daswf852@user/daswf852)
23:15:56 Quit daswf852 (Ping timeout: 268 seconds)
23:15:56 Nick daswf8528 is now known as daswf852 (~daswf852@user/daswf852)

Previous day | Next day