--- Log for 30.05.121 Server: tantalum.libera.chat Channel: #rockbox --- Nick: rb-logbot Version: Dancer V4.16 Started: 6 days and 16 hours ago 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] (~mendel_mu@ool-ae2cb250.dyn.optonline.net) 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] (~pidgin@li79-248.members.linode.com) 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@208.38.228.17) 09.50.20 Join user890104 [0] (~Venci@freemyipod.org) 09.56.00 Quit user890104 (Quit: user890104) 10.26.07 *** Saving seen data "./dancer.seen" 10.59.38 Join E14n [0] (~E14n@ac159148.ppp.asahi-net.or.jp) 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.53 # dconrad: just happened to notice your changes in gerrit, fyi that TLB refill exception is a null pointer dereference. 11.46.16 # if you still have the rockbox.map from that build you can trace down where it occurs. 11.48.58 # It seems to happen on any of the builds I'm trying, tbh I'm laser focused on the button thing right now 11.49.23 # if you're curious I can send it to you though 11.50.01 # (ps, I hope I'm not spamming your inbox with my notes on 3437!) 11.50.02 # nah it's alright I have had that happen to me too I just didn't bother investigating it either. 11.50.23 # I'm not CC'd on 3437 so no spamming here :) 11.50.28 # cool 11.50.54 # just a thought perhaps the issue with the USB screen is that the yesno dialog runs from the USB thread. 11.51.05 # yeah, that's kinda my thought 11.51.12 # maybe it causes something to be subtly broken 11.51.32 # my thought was maybe it needs a higher priority, but that doesn't seem to make a difference 11.52.23 # now 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.42 # which is obvs not a fix, but a clue 11.53.58 # I'm honestly just kind of out of my depth here, but I'm trying stuff anyway 11.54.50 # Well 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.44 # I wasn't sure if there were other usb stuff that might happen alongside the main usb thread or not 11.56.15 # perhaps 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] (~kiddyshaq@054494d0.skybroadband.com) 11.56.46 Part berylline 11.57.20 # could be, though I'm not sure where the main thread would be calling it from? 11.57.40 # oh, of get_action() 11.57.41 # well if the USB thread did not notify anybody then the main thread will be waiting in the menu or WPS or whereever 11.57.57 # oh, I see 11.57.59 # basically get_action is the idle loop 11.58.16 # (as rockbox is always waiting for key input) 11.58.46 # how does notifying another thread work? is that related to the activity stack? 11.59.06 Join JackDupp [0] (~dj@74.215.11.14) 11.59.18 # it's ad hoc depends on the thread from what I've seen. usually it's a queue. 11.59.36 # in case of USB it sends SYS_USB_CONNECTED and a lot of code watches for that. 11.59.49 # I see 12.00.52 # although 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.53 # I'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.01 # btw, holy moly are the usb defines a mess haha 12.03.10 # so confusing 12.03.13 # fortunately 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] (~E14n@ac159148.ppp.asahi-net.or.jp) 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] (~matrixirc@connolly.tech) 12.38.24 Quit CasBot (Remote host closed the connection) 12.38.37 Join CasBot [0] (~matrixirc@connolly.tech) 12.42.39 Quit CasBot (Remote host closed the connection) 12.43.01 Join CasBot [0] (~matrixirc@connolly.tech) 12.47.26 Quit CasBot (Remote host closed the connection) 12.47.50 Join CasBot [0] (~matrixirc@connolly.tech) 13.33.37 # amachronic, 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.12 # so basically "if (activity is USBSCREEN), then do not call get_activity()" 13.34.29 # and it breaks it completely, which.... does not jive with my understanding of how this all works??? 13.35.10 # er... get_activity() --> get_action() 13.37.27 # okaaay... it appears that would be expected 13.37.45 # because get_action might return SYS_USB_CONNECTED 13.37.45 # I don't think my understanding is correct haha 13.38.19 # or maybe not, rather default_event_handler takes the action and returns SYS_USB_CONNECTED. 13.39.05 # so if it doesn't call get_action() the main thread would block and I guess things freeze up. 13.39.19 # I guess I don't get why not calling get_action() from do_menu() would break calling get_action() from gui_syncyesno_run() 13.39.47 # me neither :P 13.40.01 # but IMHO the bug is having the USB thread do GUI work. 13.41.11 # er, 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.41 # but isn't the usb connect event not sent until after the yes/no screen? 13.42.02 # yeah as far as I can tell. 13.42.03 Join ats_ [0] (~ats@cartman.offog.org) 13.42.06 # hm, weird 13.42.12 # okay I see your point. 13.42.40 # re: 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.22 # boy this is /way/ deeper than I've ever been into a software codebase 13.43.45 # yes, 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.03 # half-implemented...? 13.44.08 Quit ats (Ping timeout: 265 seconds) 13.44.17 # more like, "it seems to work so let's merge it" 13.44.26 # yeah... 13.54.46 Join actinium [0] (~actinium@gateway/tor-sasl/actinium) 13.57.11 # dconrad: patch adding the USB prompt = g#2972 13.57.13 # 3Gerrit review #2972 at https://gerrit.rockbox.org/r/c/rockbox/+/2972 : 3usb: Add ability to prompt user about what to do upon usb insertion by Solomon Peachy 13.58.05 # aha 13.58.07 # looks like half implemented is the better explanation... 13.58.14 # boy, that's way newer than I expected 13.58.25 # at 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.32 # I figured it would've been added in like... 2005 or something 13.58.55 # LOL by "new" I meant "sometime after 2014" 13.59.14 # hmm, maybe I'll have to pick his brain about it 14.08.14 Nick ats_ is now known as ats (~ats@cartman.offog.org) 14.19.07 Nick mendel_munkis_ is now known as mendel_munkis (~mendel_mu@ool-ae2cb250.dyn.optonline.net) 14.19.20 # any idea what the reason for this is? 14.19.21 # https://gerrit.rockbox.org/r/plugins/gitiles/rockbox/+/refs/heads/master/apps/plugins/calculator.c#1541 14.20.03 # (ignoring 0 when it is the first digit of an operand) 14.24.40 # mendel_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] (~ats@cartman.offog.org) 15.23.44 # Build Server message: 3New build round started. Revision f63edb52ef, 297 builds, 10 clients. 15.34.37 # Build Server message: 3Build round completed after 654 seconds. 15.34.41 # Build Server message: 3Revision f63edb52ef result: All green 16.04.48 Quit dconrad (Remote host closed the connection) 16.17.11 Join dconrad [0] (~dconrad@208.38.228.17) 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] (~f1refly@pd954c92b.dip0.t-ipconnect.de) 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)