| 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] (~bilgus@cpe-107-11-237-184.columbus.res.rr.com) |
| 00:08:09 | | Quit _bilgus (Remote host closed the connection) |
| 00:09:27 | | Join _bilgus [0] (~bilgus@cpe-107-11-237-184.columbus.res.rr.com) |
| 00:22:15 | | Join massive_H [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) |
| 00:24:09 | | Quit massiveH (Ping timeout: 260 seconds) |
| 00:32:07 | | Quit Huntereb (Ping timeout: 252 seconds) |
| 00:34:23 | | Join Huntereb [0] (~Huntereb@142-196-011-243.res.spectrum.com) |
| 02:00 |
| 02:03:41 | *** | Saving seen data "./dancer.seen" |
| 02:17:52 | | Quit blofield (Ping timeout: 252 seconds) |
| 04:00 |
| 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@103.113.159.184) |
| 04:45:57 | | Join Soap_ [0] (~Soap@rockbox/staff/soap) |
| 04:49:12 | | Quit Soap (Ping timeout: 265 seconds) |
| 05:00 |
| 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:00 |
| 06:03:48 | *** | Saving seen data "./dancer.seen" |
| 06:06:06 | | Quit Rower () |
| 06:39:43 | | Join jdarnley [0] (~J_Darnley@d51a44418.access.telenet.be) |
| 06:40:12 | | Quit J_Darnley (Ping timeout: 240 seconds) |
| 08:00 |
| 08:03:49 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 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] (~bilgus@cpe-107-11-237-184.columbus.res.rr.com) |
| 10:00 |
| 10:03:52 | *** | Saving seen data "./dancer.seen" |
| 10:10:03 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
| 11:00 |
| 11:37:36 | | Join sv34we3s [0] (~shorty@097-088-119-211.res.spectrum.com) |
| 12:00 |
| 12:03:53 | *** | No seen item changed, no save performed. |
| 12:18:04 | | Join ufdm_ [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 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] (~bilgus@cpe-107-11-237-184.columbus.res.rr.com) |
| 12:20:23 | | Quit ufdm_ (Client Quit) |
| 12:20:34 | | Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 12:21:35 | | Join blofield [0] (~d@cpc156727-sgyl45-2-0-cust184.18-2.cable.virginm.net) |
| 12:38:55 | | Join PimpiN8 [0] (~PimpiN8@178.239.173.176) |
| 13:00 |
| 13:23:35 | | Quit f1refly (Quit: see ya in hell) |
| 13:24:53 | | Join f1refly [0] (~f1refly@p4fc475d7.dip0.t-ipconnect.de) |
| 14:00 |
| 14:03:55 | *** | Saving seen data "./dancer.seen" |
| 14:46:13 | | Join j--r [0] (e4fcc67eb1@jabberfr.org) |
| 14:46:36 | | Nick j--r is now known as Guest78327 (e4fcc67eb1@jabberfr.org) |
| 14:48:34 | | Nick Guest78327 is now known as j-r (e4fcc67eb1@jabberfr.org) |
| 14:49:06 | | Nick j-r is now known as jugendhacker (e4fcc67eb1@jabberfr.org) |
| 14:52:54 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 15:00 |
| 15:02:19 | | Join j--r[web] [0] (5df2ec1e@p5df2ec1e.dip0.t-ipconnect.de) |
| 15:05:18 | j--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:21 | dconrad | question: in the keymap parsing code in action.c, is the intent to prioritize actions before "falling through" to the next context? |
| 15:23:02 | dconrad | because it doesn't seem to do that... in fact, it seems to prioritize the "fall-through" contexts |
| 15:34:04 | dconrad | or maybe it's a quirk of the eros q? |
| 15:35:15 | | Quit sv34we3s (Quit: Konversation terminated!) |
| 15:46:57 | dconrad | no, 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:00 |
| 16:03:58 | *** | Saving seen data "./dancer.seen" |
| 16:13:52 | speachy | dconrad: 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:36 | speachy | j−−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:34 | j--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:11 | speachy | they seem to have either used 80386SX or 8051 cores in their embedded SoCs.. |
| 16:18:36 | j--r[web] | Looks like M7108 is more likely an ARM CPU... |
| 16:18:59 | speachy | dconrad: and any issues in it likely exist in other modal screens too. like what's used in the USB mode prompt.. |
| 16:19:35 | dconrad | yeah, 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:07 | dconrad | I discovered the ACTION_UNKOWN action wasn't being ignored |
| 16:20:20 | dconrad | (which might be on purpose?) |
| 16:21:17 | dconrad | however... 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:41 | dconrad | speachy: is it intentional to treat unknown actions as a "no" in the yes/no prompt? |
| 16:37:06 | dconrad | I could see an argument either way |
| 16:45:09 | | Join atsampson [0] (~ats@cartman.offog.org) |
| 16:47:23 | | Quit ats_ (Ping timeout: 260 seconds) |
| 17:00 |
| 17:22:36 | | Join j--r[web] [0] (5df2ec1e@p5df2ec1e.dip0.t-ipconnect.de) |
| 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] (~j--r@p2003000621cd5d42404207fffefd0a65.dip0.t-ipconnect.de) |
| 17:26:40 | | Quit j--r[web] (Client Quit) |
| 17:35:40 | | Join Acou_Bass [0] (~Acou_Bass@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net) |
| 17:36:37 | dconrad | 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:40 | fs-bluebot | Gerrit review #3425 at https://gerrit.rockbox.org/r/c/rockbox/+/3425 : Yes/No Screen: Ignore unknown actions by Dana Conrad |
| 17:38:55 | mendel_munkis | do all our targets use IEEE 754 floating point numbers? |
| 17:39:55 | | Join sv34we3s [0] (~shorty@097-088-119-211.res.spectrum.com) |
| 17:42:44 | gevaerts | mendel_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 | _bilgus | dconrad, the main issue is that the key code is non blocking |
| 17:43:36 | dconrad | _bilgus, I'm not sure what you mean? |
| 17:43:50 | _bilgus | it'll ptentially go through that switch 4 times in the case of hold or release |
| 17:44:33 | mendel_munkis | I 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 | _bilgus | I think I left some comments in there about it |
| 17:44:39 | dconrad | so something else is taking processor time away from it? |
| 17:44:59 | _bilgus | or you have a better match in a lower context |
| 17:45:29 | dconrad | well, it works, it's just that it doesn't register anything sometimes |
| 17:45:46 | dconrad | if there was a match at all, it would consider it a "no", right? |
| 17:45:50 | _bilgus | like 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 | _bilgus | that wouldn't be handled here |
| 17:46:55 | | Quit Acou_Bass (Read error: Connection reset by peer) |
| 17:46:57 | _bilgus | you'd have to check how that handler implements it |
| 17:47:20 | _bilgus | liek does it even look for ACTION_UNKNOWN or only NO and STD_CANCEL |
| 17:48:26 | __builtin | mendel_munkis: sdl plugins use hard float on the gigabeast |
| 17:48:41 | __builtin | several also use softfloat |
| 17:48:50 | __builtin | at least puzzles and sdl |
| 17:49:39 | _bilgus | the 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 | _bilgus | dconrad, 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] (~Acou_Bass@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net) |
| 17:51:43 | dconrad | ok, it just seems weird that it's only unresponsive on the USB prompt |
| 17:53:39 | _bilgus | eh there are events on USB |
| 17:53:53 | _bilgus | so it sends out a message asking everyone to release the disk |
| 17:54:19 | _bilgus | could be hanging there waiting or could be a bunch of spam in the button queue |
| 17:54:43 | _bilgus | should be able to ask it how many event are in the queue |
| 17:55:42 | _bilgus | it 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 | _bilgus | lets see what was the bug I think it skips events maybe |
| 17:58:05 | _bilgus | IDK 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:37 | dconrad | alright, if it was skipping events that does sound like it would explain it |
| 17:58:59 | dconrad | like it reliably gets the first event but then doesn't get the second so reliably? |
| 17:59:20 | dconrad | I'll try a timeout of 0 and just see what happens |
| 18:00 |
| 18:02:50 | | Join advcomp2019_ [0] (~advcomp20@65-131-176-93.sxct.qwest.net) |
| 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:22 | dconrad | hah, with a timeout of 0 it works every single time without issue |
| 18:04:34 | dconrad | swear to god |
| 18:05:04 | dconrad | though 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:13 | dconrad | showing my ignorance here but I don't quite get what the timeout and blocking/not blocking means in this case anyway |
| 18:11:50 | dconrad | ok, nevermind the comment above get_action_worker() has my answer |
| 18:13:06 | | Quit Acou_Bass (Quit: ZNC 1.8.2 - https://znc.in) |
| 18:13:28 | | Join Acou_Bass [0] (~Acou_Bass@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net) |
| 18:17:04 | | Quit Acou_Bass (Read error: Connection reset by peer) |
| 18:22:58 | | Join Acou_Bass [0] (~Acou_Bass@cpc95746-bolt17-2-0-cust360.10-3.cable.virginm.net) |
| 18:28:45 | | Quit ZincAlloy (Quit: Leaving.) |
| 18:34:25 | | Join amachronic [0] (~amachroni@82.132.185.6) |
| 18:35:21 | amachronic | speachy: I've done a linux static build of jztool now, same place as before |
| 18:43:41 | amachronic | and 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 | _bilgus | dconrad, I don't remember the why but I know I noted the fix wherever it is (in lua) |
| 19:00 |
| 19:01:30 | dconrad | somewhere in plugins/lua? |
| 19:02:04 | dconrad | because honestly changing it to be non-blocking seems to be working really well |
| 19:02:07 | _bilgus | yeah 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 - https://znc.in) |
| 20:00 |
| 20:04:01 | *** | Saving seen data "./dancer.seen" |
| 20:12:36 | speachy | mendel_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:23 | speachy | amachronic: 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] (~Natch@c-e070e255.014-297-73746f25.bbcust.telenor.se) |
| 21:00 |
| 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@208.38.228.17) |
| 21:50:22 | _bilgus | dconrad 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:34 | dconrad | no worries, actually if you want to take a look at g#3425 again, it's working really well for me |
| 21:52:20 | dconrad | but I don't know if I'm off-base or not for other devices |
| 21:55:12 | _bilgus | hmm in yesno.c the timeout would throw a timeout_event which would fall to the default: switch statement |
| 21:55:32 | _bilgus | that shows the default handler lets see what it does |
| 21:55:59 | dconrad | wouldn't defaulting to no work out anyway? |
| 21:57:34 | _bilgus | well that event on usb plug needs to be replied to to even connect to the USB |
| 21:57:35 | | Join fs-bluebot [0] (~fs-bluebo@55d498de.access.ecotel.net) |
| 21:58:07 | _bilgus | AH |
| 21:58:18 | _bilgus | i think you have yourself a race |
| 21:58:24 | dconrad | ? |
| 21:59:11 | _bilgus | the yes no prompt is popped on USB plug and the yes no needs to release the event |
| 22:00 |
| 22:00:24 | dconrad | I'm not sure I follow |
| 22:00:48 | dconrad | shouldn't it be ok to wait for user input to allow USB or not? |
| 22:01:02 | _bilgus | of course |
| 22:02:15 | _bilgus | so 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 | _bilgus | because the event system sends out sys_ events |
| 22:02:51 | dconrad | but then wouldn't it default to no while waiting for a "real" user event? |
| 22:03:12 | dconrad | which, according to testing I've done here, it definitely doesn't do |
| 22:04:00 | dconrad | or, you mean with a timeout of HZ*5 ? |
| 22:04:03 | *** | Saving seen data "./dancer.seen" |
| 22:04:44 | _bilgus | YESNO_USB i think |
| 22:05:45 | _bilgus | see now I need to look at the usb prompt part |
| 22:08:39 | _bilgus | dconrad, try the original yes no prompt with the usb part commented out if you would |
| 22:09:32 | _bilgus | maybe its spamming the queue |
| 22:09:44 | dconrad | just like, master branch but comment out lines 209 and 210? |
| 22:09:59 | _bilgus | since the yes no prompt is holding up the USB connect |
| 22:10:38 | dconrad | alright 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:03 | _bilgus | those |
| 22:11:27 | _bilgus | the other thing might be the need to catch the timeout explicitly |
| 22:11:50 | _bilgus | let me see what that event is I can never rem the macro |
| 22:12:36 | _bilgus | case SYS_TIMEOUT: Return NO |
| 22:13:47 | _bilgus | I wonder what happens if another yesno prompt is up and then the usb plug prompt gets called |
| 22:14:06 | dconrad | now there's a condition I haven't checked |
| 22:14:48 | _bilgus | I just put in a lua plugin that does the key code stuff |
| 22:15:06 | _bilgus | itll show those events |
| 22:15:25 | dconrad | alright, 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 | _bilgus | and you can look at the code its kinda pseudo fun house reflection of what happens on the c side in RB |
| 22:16:28 | _bilgus | I think the yes no prompt is probably outsmarting us |
| 22:19:10 | dconrad | so with those two lines commented out, it behaves the same, it's unresponsive to a button release |
| 22:19:22 | dconrad | no change, basically |
| 22:20:00 | dconrad | actions that cancel it are responsive |
| 22:20:03 | _bilgus | hmm I would have figured thast was the issue |
| 22:20:39 | dconrad | I mean, like I say it works when I make the get_action timeout non-blocking |
| 22:20:42 | _bilgus | oh the keymap |
| 22:21:03 | _bilgus | ACTION_YESNO_ACCEPT, BUTTON_PLAY, BUTTON_PLAY|BUTTON_REL, |
| 22:21:28 | _bilgus | no I think thats backwards |
| 22:21:33 | dconrad | aren't BUTTON_PLAY and BUTTON_PLAY|BUTTON_REL backwards? |
| 22:21:34 | dconrad | yeah |
| 22:22:01 | dconrad | right now I have ACTION_YESNO_ACCEPT, BUTTON_PLAY|BUTTON_REL, BUTTON_NONE |
| 22:22:07 | _bilgus | ACTION_YESNO_ACCEPT, BUTTON_PLAY|BUTTON_REL, BUTTON_PLAY |
| 22:22:10 | dconrad | which works with my gerrit patch |
| 22:22:25 | _bilgus | that pre button though |
| 22:22:45 | dconrad | I'm pretty sure I tried it every which way, but I can change it and try again |
| 22:22:59 | _bilgus | its going to tell the action system to wait to make a decision |
| 22:23:15 | _bilgus | ad you just expanded the key stuff |
| 22:23:28 | _bilgus | its touching new areas |
| 22:24:50 | _bilgus | or I should say by having the prebutton it tells it it doesn't need to wait |
| 22:26:30 | dconrad | ok, 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:42 | dconrad | which was the reason for my whole quest here in the first place haha |
| 22:26:48 | _bilgus | weird |
| 22:27:05 | _bilgus | need to look at the keymap |
| 22:27:21 | dconrad | I think I figured it out though |
| 22:27:29 | dconrad | took a while to read the code, but |
| 22:27:34 | _bilgus | there have been issues with order |
| 22:28:18 | dconrad | well, when the get_action() function can't find a valid action, it seems to return the ACTION_UNKNOWN action |
| 22:29:03 | dconrad | which was, as far as guisyncyesno_run's switch statement is concerned, is an action other than ACTION_YESNO_ACCEPT |
| 22:29:13 | dconrad | so it cancels out |
| 22:29:22 | _bilgus | yep the selective action stuff |
| 22:29:34 | _bilgus | ok so that and the keymap fix it then |
| 22:29:47 | dconrad | that's why I added the case ACTION_UNKNOWN: to just continue into another loop |
| 22:29:59 | dconrad | in other words, ignore it and keep looking |
| 22:30:19 | dconrad | yeah |
| 22:31:56 | _bilgus | tthe order 'bugs' they aren't bugs persay |
| 22:32:23 | _bilgus | but the order within that list matters as well as the fall through order |
| 22:32:37 | dconrad | yeah, I kinda figured out you can exploit them to be very specific, but you need to know the rules |
| 22:32:59 | _bilgus | yeah its why i'm stuck on that plugin atm |
| 22:33:02 | dconrad | in this case it didn't really seem to matter much once I made it ignore ACTION_UNKOWN |
| 22:33:39 | _bilgus | how to best allow that without the user FUBARing the context list |
| 22:34:02 | _bilgus | i'm thinking drop downs and checking for invalid combos |
| 22:34:30 | _bilgus | or like linit them based on the entered values |
| 22:34:41 | _bilgus | limit |
| 22:34:53 | dconrad | let me try my patch though to see what happens when a prompt comes up on top of another |
| 22:35:07 | dconrad | I didn't even think to check, quite the corner case though |
| 22:35:27 | _bilgus | indeed but it has been an issue before with other things |
| 22:36:52 | dconrad | in any case I kinda doubt my patch changes the behavior of that condition |
| 22:37:08 | dconrad | but we'll see |
| 22:38:16 | _bilgus | you should look at the commit https://gerrit.rockbox.org/r/c/rockbox/+/1674 |
| 22:38:38 | _bilgus | idk if the original code is clearer than after my rewrite |
| 22:39:36 | dconrad | ok, 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 | _bilgus | oh wait theres even older |
| 22:39:56 | dconrad | and it just immediately asks if I want to enter mass storage mode. I hit ok... |
| 22:40:06 | dconrad | and it comes up in mass storage mode |
| 22:40:09 | dconrad | seems ok? |
| 22:40:29 | dconrad | oop, stack underflow... viewportmanager |
| 22:40:42 | dconrad | after I unmounted from the computer and unplugged usb |
| 22:40:58 | dconrad | let me try that on master |
| 22:41:05 | _bilgus | ah |
| 22:41:32 | _bilgus | so it popped the vp 2x |
| 22:42:11 | _bilgus | it'll still do it |
| 22:42:21 | dconrad | yeah I kinda figure so |
| 22:43:02 | _bilgus | that means yesno needs to be aware of its own destruction |
| 22:43:27 | dconrad | I mean, it did wait for me to input something before going to the next prompt though |
| 22:43:38 | dconrad | so they were queued up |
| 22:43:38 | _bilgus | or really the caller but eh I don't think its ready for that |
| 22:43:58 | dconrad | ok, one more time |
| 22:44:20 | dconrad | oh, it cancelled out of both |
| 22:44:30 | dconrad | as soon as I put in the USB plug |
| 22:44:34 | _bilgus | well its displaying the yesno, it gets overwritten then kills them both but there is only one |
| 22:44:43 | dconrad | did not see that coming |
| 22:44:50 | _bilgus | so the bug covered the other bug |
| 22:45:22 | _bilgus | mmmm bc the usb canceled the first one maybe |
| 22:45:26 | dconrad | haha wouldn't be the first time I've uncovered a bug |
| 22:45:41 | dconrad | oh, yeah because of that if statement I commented out earlier |
| 22:45:52 | dconrad | maybe? |
| 22:46:20 | _bilgus | I'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:53 | dconrad | haha yeah I have a tendency to find bugs immediately at work too |
| 22:47:06 | dconrad | never trust a dev to bugcheck their own work |
| 22:47:25 | dconrad | same with all engineers, really... too ginger with their own creations |
| 22:47:58 | dconrad | so in any case, do you think my changes are sane? |
| 22:48:08 | _bilgus | nah its just you'd code for it if you had thought of it |
| 22:48:39 | _bilgus | sure but its just going to use more power |
| 22:48:51 | _bilgus | and its not fixing the underlying buf |
| 22:48:56 | _bilgus | bug |
| 22:49:18 | dconrad | the timeout thing you mean? |
| 22:49:26 | _bilgus | by not blocking you are just sopinning in that loop instead of allowing power savings |
| 22:49:34 | dconrad | hm, I see |
| 22:49:35 | _bilgus | yes |
| 22:49:51 | _bilgus | not all processors use it but quite a few do |
| 22:51:10 | dconrad | so you figure get_action() should actually need a bugfix for this? |
| 22:52:17 | _bilgus | no |
| 22:52:24 | _bilgus | the 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 | _bilgus | its not reentrant I think |
| 22:54:08 | _bilgus | the other part is your original issue thats fiuxed by the keymap prebutton and action_unknown with timeout HZ*5? |
| 22:54:38 | _bilgus | or is it still predicated on NO_BLOCK |
| 22:55:39 | dconrad | the action_unknown allowed it to accept a button_rel action at all |
| 22:56:04 | dconrad | the prebutton didn't seem to make a difference once I added action_unknown |
| 22:56:25 | dconrad | and then not blocking the timeout fixed unresponsiveness on usb prompt |
| 22:57:01 | dconrad | if that makes sense |
| 22:57:15 | _bilgus | I mean it should be pretty close to just as responsive as blocking/timeout/no block |
| 22:57:39 | _bilgus | frome human time perspective |
| 22:57:43 | dconrad | yeah |
| 22:57:53 | _bilgus | it still catches the stuff in the queue |
| 22:58:04 | dconrad | but what it does is it just seems to ignore it, try it a bunch of times and eventually it will go through |
| 22:58:40 | dconrad | no block makes it work first time, every time |
| 22:58:56 | _bilgus | ok do your action unknown and the keymap as a single commit |
| 22:59:18 | dconrad | alright |
| 22:59:35 | _bilgus | wait a bit on the no block |
| 23:00 |
| 23:00:05 | _bilgus | i'm kinda on a bunch of things atm but give me some time and i'll investigate that |
| 23:00:21 | _bilgus | its probably related to that lua omne |
| 23:00:27 | dconrad | what about moving the usb init? |
| 23:00:56 | dconrad | that was another bug my changes uncovered |
| 23:01:07 | _bilgus | yeah that too |
| 23:01:11 | dconrad | alright |
| 23:04:46 | _bilgus | mm SYS_TIMEOUT |
| 23:05:41 | _bilgus | well I guess it'd get caught by default and return NO |
| 23:06:45 | _bilgus | problem is there are other SYS events too |
| 23:07:21 | dconrad | ok, I pushed the new patchset |
| 23:07:29 | _bilgus | so it probably needs to check for a SYS even flag before it returns NO |
| 23:07:49 | dconrad | and noted the known issue in the commit message |
| 23:11:03 | dconrad | thanks for taking the time to look through it, I'm gonna get out of here |
| 23:11:42 | _bilgus | ok ill wait to push it till you are around |
| 23:11:52 | dconrad | alright, sweet |
| 23:12:06 | | Quit dconrad () |
icon identifies that the person is a core developer (has commit access).