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-16

00:03:39***No seen item changed, no save performed.
00:04:52 Quit _bilgus (Read error: Connection reset by peer)
00:05:32 Join _bilgus [0] (
00:08:09 Quit _bilgus (Remote host closed the connection)
00:09:27 Join _bilgus [0] (
00:22:15 Join massive_H [0] (
00:24:09 Quit massiveH (Ping timeout: 260 seconds)
00:32:07 Quit Huntereb (Ping timeout: 252 seconds)
00:34:23 Join Huntereb [0] (
02:03:41***Saving seen data "./dancer.seen"
02:17:52 Quit blofield (Ping timeout: 252 seconds)
04:03:44***Saving seen data "./dancer.seen"
04:31:17 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:55ba:3640:96e8:60e9)
04:38:20 Quit asaba (Quit: Relay server offline)
04:38:24 Join asabas [0] (~asaba@
04:45:57 Join Soap_ [0] (~Soap@rockbox/staff/soap)
04:49:12 Quit Soap (Ping timeout: 265 seconds)
05:37:04 Quit S|h|a|w|n (Read error: Connection reset by peer)
05:43:57 Join lebellium [0] (~lebellium@2a01:cb10:2e:2000:81e2:7ca6:b0b5:8b8a)
05:53:12 Join MrZeus_ [0] (~MrZeus@2a02:c7f:a0aa:4400:90e:2477:e043:c70f)
06:03:48***Saving seen data "./dancer.seen"
06:06:06 Quit Rower ()
06:39:43 Join jdarnley [0] (
06:40:12 Quit J_Darnley (Ping timeout: 240 seconds)
08:03:49***Saving seen data "./dancer.seen"
09:24:04 Join Soap [0] (~Soap@rockbox/staff/soap)
09:26:52 Quit _bilgus (Ping timeout: 252 seconds)
09:33:31 Join _bilgus [0] (
10:03:52***Saving seen data "./dancer.seen"
10:10:03 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
11:37:36 Join sv34we3s [0] (
12:03:53***No seen item changed, no save performed.
12:18:04 Join ufdm_ [0] (
12:18:56 Quit _bilgus (Remote host closed the connection)
12:18:58 Quit ufdm (Read error: Connection reset by peer)
12:19:13 Join _bilgus [0] (
12:20:23 Quit ufdm_ (Client Quit)
12:20:34 Join ufdm [0] (
12:21:35 Join blofield [0] (
12:38:55 Join PimpiN8 [0] (~PimpiN8@
13:23:35 Quit f1refly (Quit: see ya in hell)
13:24:53 Join f1refly [0] (
14:03:55***Saving seen data "./dancer.seen"
14:46:13 Join j--r [0] (
14:46:36 Nick j--r is now known as Guest78327 (
14:48:34 Nick Guest78327 is now known as j-r (
14:49:06 Nick j-r is now known as jugendhacker (
14:52:54 Join dconrad [0] (~dconrad@
15:02:19 Join j--r[web] [0] (
15:05:18j--r[web]Hi, just opened up a Grundig MPixx 1000 Series and found out that it uses a M7108 A1 by Ali Corporation, does anybody have experience with this Chip or a datasheet or something like this?
15:22:21dconradquestion: in the keymap parsing code in action.c, is the intent to prioritize actions before "falling through" to the next context?
15:23:02dconradbecause it doesn't seem to do that... in fact, it seems to prioritize the "fall-through" contexts
15:34:04dconrador maybe it's a quirk of the eros q?
15:35:15 Quit sv34we3s (Quit: Konversation terminated!)
15:46:57dconradno, wait I think its a small bug in the yesno screen code
15:47:40 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
16:03:58***Saving seen data "./dancer.seen"
16:13:52speachydconrad: the yesno code has been abused well beyond its original purpose, so it's probably not surprising that there are bugs in there
16:15:36speachyj−−r[web]: not that I'm aware of. Given that ALi was acquired by nvidia 15 years ago, the odds of finding anything are.. unlikel.
16:16:34j--r[web]speachy I'm currently searching a bit with google, maybe I could find a way to dump/flash the firmware as a starting point
16:17:11speachythey seem to have either used 80386SX or 8051 cores in their embedded SoCs..
16:18:36j--r[web]Looks like M7108 is more likely an ARM CPU...
16:18:59speachydconrad: and any issues in it likely exist in other modal screens too. like what's used in the USB mode prompt..
16:19:35dconradyeah, all I was trying to do was change the "yes" action from play to play(release), but it would take play as cancel
16:20:07dconradI discovered the ACTION_UNKOWN action wasn't being ignored
16:20:20dconrad(which might be on purpose?)
16:21:17dconradhowever... now the USB mode prompt is very unreponsive with play(release), all other prompts seem fine
16:30:22 Quit j--r[web] (Ping timeout: 240 seconds)
16:36:41dconradspeachy: is it intentional to treat unknown actions as a "no" in the yes/no prompt?
16:37:06dconradI could see an argument either way
16:45:09 Join atsampson [0] (
16:47:23 Quit ats_ (Ping timeout: 260 seconds)
17:22:36 Join j--r[web] [0] (
17:24:04 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:24:21 Quit lebellium (Quit: Leaving)
17:25:39 Join j--r [0] (
17:26:40 Quit j--r[web] (Client Quit)
17:35:40 Join Acou_Bass [0] (
17:36:37dconrad g#3425 if you (or anyone) wants to see if the unreponsive USB prompt with a button release is exclusive to the erosq
17:36:40fs-bluebotGerrit review #3425 at : Yes/No Screen: Ignore unknown actions by Dana Conrad
17:38:55mendel_munkisdo all our targets use IEEE 754 floating point numbers?
17:39:55 Join sv34we3s [0] (
17:42:44gevaertsmendel_munkis: The "traditional" targets don't have an FPU. The core and all of the codecs are pure fixed point, although some plugins do FP I believe
17:42:59_bilgusdconrad, the main issue is that the key code is non blocking
17:43:36dconrad_bilgus, I'm not sure what you mean?
17:43:50_bilgusit'll ptentially go through that switch 4 times in the case of hold or release
17:44:33mendel_munkisI am working on an existing FP plugin, and I wanted to make sure that if I do something which relys on the format it won't break on some random target.
17:44:36_bilgusI think I left some comments in there about it
17:44:39dconradso something else is taking processor time away from it?
17:44:59_bilgusor you have a better match in a lower context
17:45:29dconradwell, it works, it's just that it doesn't register anything sometimes
17:45:46dconradif there was a match at all, it would consider it a "no", right?
17:45:50_bilguslike this you have key1 and key1_rel but after fall through it sees another action that is key1 and button_none then it'll return that
17:46:26_bilgusthat wouldn't be handled here
17:46:55 Quit Acou_Bass (Read error: Connection reset by peer)
17:46:57_bilgusyou'd have to check how that handler implements it
17:47:20_bilgusliek does it even look for ACTION_UNKNOWN or only NO and STD_CANCEL
17:48:26__builtinmendel_munkis: sdl plugins use hard float on the gigabeast
17:48:41__builtinseveral also use softfloat
17:48:50__builtinat least puzzles and sdl
17:49:39_bilgusthe keymaps can care about order of actions within a context too in some particular circumstance that I can't recall ATM unless I managed to fix it (might have) been too long..
17:50:53_bilgusdconrad, there is also a weird bug in timeouts with one of those action functions hold on I ran into it in lua
17:51:28 Join Acou_Bass [0] (
17:51:43dconradok, it just seems weird that it's only unresponsive on the USB prompt
17:53:39_bilguseh there are events on USB
17:53:53_bilgusso it sends out a message asking everyone to release the disk
17:54:19_bilguscould be hanging there waiting or could be a bunch of spam in the button queue
17:54:43_bilgusshould be able to ask it how many event are in the queue
17:55:42_bilgusit could be the timeout of get action too I can't find it atm but if you try to use (0) the timeout_NO_BLOCK i think
17:56:33_bilguslets see what was the bug I think it skips events maybe
17:58:05_bilgusIDK I saw it the other day when I was working on lua so I might run into the comment about hwat the bug is
17:58:37dconradalright, if it was skipping events that does sound like it would explain it
17:58:59dconradlike it reliably gets the first event but then doesn't get the second so reliably?
17:59:20dconradI'll try a timeout of 0 and just see what happens
18:02:50 Join advcomp2019_ [0] (
18:02:51 Quit advcomp2019_ (Changing host)
18:02:51 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019)
18:04:00***Saving seen data "./dancer.seen"
18:04:22dconradhah, with a timeout of 0 it works every single time without issue
18:04:34dconradswear to god
18:05:04dconradthough I'm sure there's a reason it can't just be changed to 0 and call it good
18:05:55 Quit advcomp2019 (Ping timeout: 252 seconds)
18:10:13dconradshowing my ignorance here but I don't quite get what the timeout and blocking/not blocking means in this case anyway
18:11:50dconradok, nevermind the comment above get_action_worker() has my answer
18:13:06 Quit Acou_Bass (Quit: ZNC 1.8.2 -
18:13:28 Join Acou_Bass [0] (
18:17:04 Quit Acou_Bass (Read error: Connection reset by peer)
18:22:58 Join Acou_Bass [0] (
18:28:45 Quit ZincAlloy (Quit: Leaving.)
18:34:25 Join amachronic [0] (~amachroni@
18:35:21amachronicspeachy: I've done a linux static build of jztool now, same place as before
18:43:41amachronicand btw I made a mistake with the bootloader yesterday and built master with g3420 on top, hence, the revision isn't in the rockbox repo... I uploaded a new good build of bootloader.m3k from origin/master to fix that. binaries are identical in any event
18:59:43_bilgusdconrad, I don't remember the why but I know I noted the fix wherever it is (in lua)
19:01:30dconradsomewhere in plugins/lua?
19:02:04dconradbecause honestly changing it to be non-blocking seems to be working really well
19:02:07_bilgusyeah I'll look later IDR if it was a script or the actual engine
19:17:26 Quit amachronic (Quit: amachronic)
19:57:19 Quit Acou_Bass (Quit: ZNC 1.8.2 -
20:04:01***Saving seen data "./dancer.seen"
20:12:36speachymendel_munkis: our targets use whatever floating point representation that the compiler spits out. I don't think we actually care anywhere about the binary representation anywhere.
20:13:23speachyamachronic: I'll get to it later tonight. been driving for.. most of the day, it seems.
20:17:26 Quit Natch (Read error: Connection reset by peer)
20:22:25 Join Natch [0] (
21:04:59 Quit MrZeus_ (Ping timeout: 260 seconds)
21:19:38 Quit sv34we3s (Quit: Konversation terminated!)
21:21:43 Quit dconrad (Remote host closed the connection)
21:42:56 Quit bluebrother (Disconnected by services)
21:43:01 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother)
21:43:43 Quit fs-bluebot (Ping timeout: 252 seconds)
21:50:12 Join dconrad [0] (~dconrad@
21:50:22_bilgusdconrad logs Sorry I can't seem to find it now so it might be something thats already been fixed and I missed reverting it but I'll let you know if I run across it again
21:51:34dconradno worries, actually if you want to take a look at g#3425 again, it's working really well for me
21:52:20dconradbut I don't know if I'm off-base or not for other devices
21:55:12_bilgushmm in yesno.c the timeout would throw a timeout_event which would fall to the default: switch statement
21:55:32_bilgusthat shows the default handler lets see what it does
21:55:59dconradwouldn't defaulting to no work out anyway?
21:57:34_bilguswell that event on usb plug needs to be replied to to even connect to the USB
21:57:35 Join fs-bluebot [0] (
21:58:18_bilgusi think you have yourself a race
21:59:11_bilgusthe yes no prompt is popped on USB plug and the yes no needs to release the event
22:00:24dconradI'm not sure I follow
22:00:48dconradshouldn't it be ok to wait for user input to allow USB or not?
22:01:02_bilgusof course
22:02:15_bilgusso i'm thinking what is going on is you are sitting waiting for an event from the user but default: will be serviced
22:02:37_bilgusbecause the event system sends out sys_ events
22:02:51dconradbut then wouldn't it default to no while waiting for a "real" user event?
22:03:12dconradwhich, according to testing I've done here, it definitely doesn't do
22:04:00dconrador, you mean with a timeout of HZ*5 ?
22:04:03***Saving seen data "./dancer.seen"
22:04:44_bilgusYESNO_USB i think
22:05:45_bilgussee now I need to look at the usb prompt part
22:08:39_bilgusdconrad, try the original yes no prompt with the usb part commented out if you would
22:09:32_bilgusmaybe its spamming the queue
22:09:44dconradjust like, master branch but comment out lines 209 and 210?
22:09:59_bilgussince the yes no prompt is holding up the USB connect
22:10:38dconradalright hold on, I gotta go start the other computer back up
22:11:00_bilgus if(default_event_handler(button) == SYS_USB_CONNECTED)
22:11:01_bilgus return(YESNO_USB);
22:11:27_bilgusthe other thing might be the need to catch the timeout explicitly
22:11:50_bilguslet me see what that event is I can never rem the macro
22:12:36_bilguscase SYS_TIMEOUT: Return NO
22:13:47_bilgusI wonder what happens if another yesno prompt is up and then the usb plug prompt gets called
22:14:06dconradnow there's a condition I haven't checked
22:14:48_bilgusI just put in a lua plugin that does the key code stuff
22:15:06_bilgusitll show those events
22:15:25dconradalright, so I'm on master, gonna comment out lines 209 and 210 like you say, and set the ACTION_YESNO_ACCEPT to button release
22:15:43_bilgusand you can look at the code its kinda pseudo fun house reflection of what happens on the c side in RB
22:16:28_bilgusI think the yes no prompt is probably outsmarting us
22:19:10dconradso with those two lines commented out, it behaves the same, it's unresponsive to a button release
22:19:22dconradno change, basically
22:20:00dconradactions that cancel it are responsive
22:20:03_bilgushmm I would have figured thast was the issue
22:20:39dconradI mean, like I say it works when I make the get_action timeout non-blocking
22:20:42_bilgusoh the keymap
22:21:28_bilgusno I think thats backwards
22:21:33dconradaren't BUTTON_PLAY and BUTTON_PLAY|BUTTON_REL backwards?
22:22:10dconradwhich works with my gerrit patch
22:22:25_bilgusthat pre button though
22:22:45dconradI'm pretty sure I tried it every which way, but I can change it and try again
22:22:59_bilgusits going to tell the action system to wait to make a decision
22:23:15_bilgusad you just expanded the key stuff
22:23:28_bilgusits touching new areas
22:24:50_bilgusor I should say by having the prebutton it tells it it doesn't need to wait
22:26:30dconradok, with those two lines still commented out and with the pre button, it just cancels out of the prompt as soon as I press play
22:26:42dconradwhich was the reason for my whole quest here in the first place haha
22:27:05_bilgusneed to look at the keymap
22:27:21dconradI think I figured it out though
22:27:29dconradtook a while to read the code, but
22:27:34_bilgusthere have been issues with order
22:28:18dconradwell, when the get_action() function can't find a valid action, it seems to return the ACTION_UNKNOWN action
22:29:03dconradwhich was, as far as guisyncyesno_run's switch statement is concerned, is an action other than ACTION_YESNO_ACCEPT
22:29:13dconradso it cancels out
22:29:22_bilgusyep the selective action stuff
22:29:34_bilgusok so that and the keymap fix it then
22:29:47dconradthat's why I added the case ACTION_UNKNOWN: to just continue into another loop
22:29:59dconradin other words, ignore it and keep looking
22:31:56_bilgustthe order 'bugs' they aren't bugs persay
22:32:23_bilgusbut the order within that list matters as well as the fall through order
22:32:37dconradyeah, I kinda figured out you can exploit them to be very specific, but you need to know the rules
22:32:59_bilgusyeah its why i'm stuck on that plugin atm
22:33:02dconradin this case it didn't really seem to matter much once I made it ignore ACTION_UNKOWN
22:33:39_bilgushow to best allow that without the user FUBARing the context list
22:34:02_bilgusi'm thinking drop downs and checking for invalid combos
22:34:30_bilgusor like linit them based on the entered values
22:34:53dconradlet me try my patch though to see what happens when a prompt comes up on top of another
22:35:07dconradI didn't even think to check, quite the corner case though
22:35:27_bilgusindeed but it has been an issue before with other things
22:36:52dconradin any case I kinda doubt my patch changes the behavior of that condition
22:37:08dconradbut we'll see
22:38:16_bilgusyou should look at the commit
22:38:38_bilgusidk if the original code is clearer than after my rewrite
22:39:36dconradok, so with it warning me that I'm going to erase the dynamic playlist, I plugged in USB and nothing happened. I'm going to hit ok...
22:39:39_bilgusoh wait theres even older
22:39:56dconradand it just immediately asks if I want to enter mass storage mode. I hit ok...
22:40:06dconradand it comes up in mass storage mode
22:40:09dconradseems ok?
22:40:29dconradoop, stack underflow... viewportmanager
22:40:42dconradafter I unmounted from the computer and unplugged usb
22:40:58dconradlet me try that on master
22:41:32_bilgusso it popped the vp 2x
22:42:11_bilgusit'll still do it
22:42:21dconradyeah I kinda figure so
22:43:02_bilgusthat means yesno needs to be aware of its own destruction
22:43:27dconradI mean, it did wait for me to input something before going to the next prompt though
22:43:38dconradso they were queued up
22:43:38_bilgusor really the caller but eh I don't think its ready for that
22:43:58dconradok, one more time
22:44:20dconradoh, it cancelled out of both
22:44:30dconradas soon as I put in the USB plug
22:44:34_bilguswell its displaying the yesno, it gets overwritten then kills them both but there is only one
22:44:43dconraddid not see that coming
22:44:50_bilgusso the bug covered the other bug
22:45:22_bilgusmmmm bc the usb canceled the first one maybe
22:45:26dconradhaha wouldn't be the first time I've uncovered a bug
22:45:41dconradoh, yeah because of that if statement I commented out earlier
22:46:20_bilgusI've a buddy that I would hand my programs to to test he would find bugs in seconds after handing him the device
22:46:53dconradhaha yeah I have a tendency to find bugs immediately at work too
22:47:06dconradnever trust a dev to bugcheck their own work
22:47:25dconradsame with all engineers, really... too ginger with their own creations
22:47:58dconradso in any case, do you think my changes are sane?
22:48:08_bilgusnah its just you'd code for it if you had thought of it
22:48:39_bilgussure but its just going to use more power
22:48:51_bilgusand its not fixing the underlying buf
22:49:18dconradthe timeout thing you mean?
22:49:26_bilgusby not blocking you are just sopinning in that loop instead of allowing power savings
22:49:34dconradhm, I see
22:49:51_bilgusnot all processors use it but quite a few do
22:51:10dconradso you figure get_action() should actually need a bugfix for this?
22:52:24_bilgusthe yesno prompt
22:53:05 Quit Soap (Read error: Connection reset by peer)
22:53:05 Quit Soap_ (Read error: Connection reset by peer)
22:53:20_bilgusits not reentrant I think
22:54:08_bilgusthe other part is your original issue thats fiuxed by the keymap prebutton and action_unknown with timeout HZ*5?
22:54:38_bilgusor is it still predicated on NO_BLOCK
22:55:39dconradthe action_unknown allowed it to accept a button_rel action at all
22:56:04dconradthe prebutton didn't seem to make a difference once I added action_unknown
22:56:25dconradand then not blocking the timeout fixed unresponsiveness on usb prompt
22:57:01dconradif that makes sense
22:57:15_bilgusI mean it should be pretty close to just as responsive as blocking/timeout/no block
22:57:39_bilgusfrome human time perspective
22:57:53_bilgusit still catches the stuff in the queue
22:58:04dconradbut what it does is it just seems to ignore it, try it a bunch of times and eventually it will go through
22:58:40dconradno block makes it work first time, every time
22:58:56_bilgusok do your action unknown and the keymap as a single commit
22:59:35_bilguswait a bit on the no block
23:00:05_bilgusi'm kinda on a bunch of things atm but give me some time and i'll investigate that
23:00:21_bilgusits probably related to that lua omne
23:00:27dconradwhat about moving the usb init?
23:00:56dconradthat was another bug my changes uncovered
23:01:07_bilgusyeah that too
23:04:46_bilgusmm SYS_TIMEOUT
23:05:41_bilguswell I guess it'd get caught by default and return NO
23:06:45_bilgusproblem is there are other SYS events too
23:07:21dconradok, I pushed the new patchset
23:07:29_bilgusso it probably needs to check for a SYS even flag before it returns NO
23:07:49dconradand noted the known issue in the commit message
23:11:03dconradthanks for taking the time to look through it, I'm gonna get out of here
23:11:42_bilgusok ill wait to push it till you are around
23:11:52dconradalright, sweet
23:12:06 Quit dconrad ()

Previous day | Next day