--- Log for 19.03.121 Server: beckett.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 13 days and 8 hours ago 00.24.27 *** Saving seen data "./dancer.seen" 02.07.39 Quit SovietShaman (Quit: Fuck this, I'm out) 02.08.28 Join SovietShaman [0] (quassel@024-217-039-226.res.spectrum.com) 02.24.28 *** Saving seen data "./dancer.seen" 02.46.31 Quit SovietShaman (Quit: Fuck this, I'm out) 02.48.11 Join CommunistWitchDr [0] (quassel@024-217-039-226.res.spectrum.com) 04.24.31 *** Saving seen data "./dancer.seen" 05.23.03 Join eevan [0] (~eevan@176.205.85.59) 05.23.43 Quit eevan (Client Quit) 05.24.23 Join eevan [0] (~eevan@176.205.85.59) 05.41.22 Part eevan ("Leaving") 05.43.37 Join eevan [0] (~eevan@176.205.85.59) 06.05.36 Quit eevan (Quit: Leaving) 06.06.38 Join eevan [0] (~eevan@176.205.85.59) 06.24.32 *** Saving seen data "./dancer.seen" 06.27.19 Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be) 06.28.56 Quit J_Darnley (Ping timeout: 240 seconds) 06.50.38 Quit Barlow (Ping timeout: 260 seconds) 07.27.22 Join Barlow [0] (~barlow@17-215-201-31.ftth.glasoperator.nl) 07.27.22 Quit Barlow (Changing host) 07.27.22 Join Barlow [0] (~barlow@unaffiliated/barlow) 07.48.12 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 08.24.34 *** Saving seen data "./dancer.seen" 08.33.29 # <_bilgus_> speach y re bad software makes great communities? 08.35.37 # <_bilgus_> I think rockbox is daunting at that first look at the source code but at least we have guides (even if somewhat out of date) 08.36.57 # <_bilgus_> Ithink its more just making it accessible and known and a look at gerrit lately says it or maybe we just broke enough stuff 08.40.48 Quit tchan1 (Quit: WeeChat 3.0.1) 08.41.07 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 08.46.48 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 08.52.39 Quit massiveH (Quit: Leaving) 09.00.08 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-205e-99a7-831f-0e9f.res6.spectrum.com) 09.19.23 Quit spectrumanalyst (Quit: Bye!) 09.22.40 Join spectrumanalyst [0] (~admin@198.46.152.45) 09.25.27 Join tchan1 [0] (~tchan@c-98-206-141-238.hsd1.il.comcast.net) 09.26.05 Quit tchan1 (Client Quit) 09.28.40 Join advcomp2019__ [0] (~advcomp20@65-131-187-233.sxct.qwest.net) 09.28.40 Quit advcomp2019__ (Changing host) 09.28.40 Join advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019) 09.29.20 Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be) 09.33.52 Quit tchan (*.net *.split) 09.33.52 Quit jdarnley (*.net *.split) 09.33.53 Quit michaelni (*.net *.split) 09.33.53 Quit advcomp2019_ (*.net *.split) 09.33.53 Quit Galois (*.net *.split) 09.37.28 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 09.42.02 Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) 10.24.38 *** Saving seen data "./dancer.seen" 10.52.32 Quit ufdm (Remote host closed the connection) 10.58.37 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) 11.23.53 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 11.26.28 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) 12.19.43 Quit Acou_Bass (Ping timeout: 260 seconds) 12.24.41 *** Saving seen data "./dancer.seen" 12.33.14 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 12.59.46 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 13.15.20 Quit Saijin_Naib (Disconnected by services) 13.15.24 Join Saijin-Naib [0] (~Saijin_Na@2603-7081-1d05-7230-205e-99a7-831f-0e9f.res6.spectrum.com) 13.37.46 Quit asaba (Quit: Relay server offline) 13.37.57 Join asaba [0] (~asaba@103.113.159.184) 14.12.50 Join advcomp2019 [0] (~advcomp20@65-131-187-233.sxct.qwest.net) 14.12.50 Quit advcomp2019 (Changing host) 14.12.50 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 14.13.47 Join advcomp2019_ [0] (~advcomp20@65-131-187-233.sxct.qwest.net) 14.13.47 Quit advcomp2019_ (Changing host) 14.13.47 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 14.16.09 Quit advcomp2019__ (Ping timeout: 264 seconds) 14.17.12 Quit advcomp2019 (Ping timeout: 246 seconds) 14.24.44 *** Saving seen data "./dancer.seen" 14.31.02 # <__builtin> "It has many subscribers and quite intense traffic at times." - rockbox.org/mail 14.32.57 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 14.33.19 Quit ufdm (Read error: Connection reset by peer) 14.34.17 # there's a mailing list? 14.34.31 # i think the forums have largely replaced them 14.39.12 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) 14.58.04 Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be) 14.59.06 Quit J_Darnley (Ping timeout: 256 seconds) 15.18.42 Join MrZeus [0] (~MrZeus@89.238.143.231) 15.49.48 Quit eevan (Read error: Connection reset by peer) 16.12.58 Join petur [0] (~petur@rockbox/developer/petur) 16.24.48 *** Saving seen data "./dancer.seen" 16.41.20 Quit Saijin-Naib (Read error: Connection reset by peer) 17.00.09 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-205e-99a7-831f-0e9f.res6.spectrum.com) 17.04.44 # <_bilgus_> We 'try' to run big changes through there 17.05.17 # <_bilgus_> a lot more people subscribed there than actually look at the forum I think 17.57.44 Quit Saijin_Naib (Disconnected by services) 17.57.48 Join Saijin-Naib [0] (~Saijin_Na@2603-7081-1d05-7230-205e-99a7-831f-0e9f.res6.spectrum.com) 18.10.03 Join advcomp2019__ [0] (~advcomp20@65-131-187-233.sxct.qwest.net) 18.10.03 Quit advcomp2019__ (Changing host) 18.10.03 Join advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019) 18.10.10 Join lebellium_ [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 18.10.10 Join fmlatghor [0] (~lcoogan@2601:5cd:8100:2890:9220:3aff:fe1a:350d) 18.10.52 Join mendelmunkis [0] (~mendelmun@ool-43568247.dyn.optonline.net) 18.11.36 Join rogeliodh9 [0] (~rogeliodh@rogeliodh.dev) 18.12.07 Quit rogeliodh (Read error: Connection reset by peer) 18.12.07 Nick rogeliodh9 is now known as rogeliodh (~rogeliodh@rogeliodh.dev) 18.12.56 Quit mendel_munkis_ (Read error: Connection reset by peer) 18.13.06 Quit advcomp2019_ (Ping timeout: 246 seconds) 18.13.06 Quit lebellium (Ping timeout: 246 seconds) 18.13.45 Quit benedikt93 (Ping timeout: 264 seconds) 18.14.22 Join benedikt93 [0] (~quassel@unaffiliated/benedikt93) 18.15.33 Quit Huntereb (Ping timeout: 246 seconds) 18.16.09 Quit Galois (Ping timeout: 264 seconds) 18.16.28 Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7:21e:37ff:fe4e:f43a) 18.24.49 *** Saving seen data "./dancer.seen" 18.58.13 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 18.59.29 Quit Galois (Remote host closed the connection) 19.00.17 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 19.22.09 Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 19.26.00 Quit petur (Remote host closed the connection) 19.55.10 Quit Acou_Bass (Quit: ZNC 1.8.2 - https://znc.in) 19.58.20 Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 20.00.40 Join dconrad [0] (d026e411@208.38.228.17) 20.23.46 # I'm looking at the softlock/backlight code in action.c, what's this unlock_combo about? It looks like it's set in do_auto_softlock() to whatever the last button pressed was? What's this intended to do? I don't quite understand 20.24.20 # as far as I can tell, if the autolock times out and locks, you can hit whatever the last button you pressed was to undo the lock, is that it? 20.24.52 *** Saving seen data "./dancer.seen" 20.38.25 # doesn't seem to work on my Hifi walker H2, so that must not be it, or it doesn't apply to this device 20.42.24 Quit lebellium_ (Quit: Leaving) 20.47.02 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 21.26.42 Quit fmlatghor (Quit: WeeChat 3.0.1) 21.34.13 Quit MrZeus (Ping timeout: 245 seconds) 21.58.43 # <_bilgus_> what it does is stores the last button pressed, since we can just scan for that button to unlock 21.59.06 # <_bilgus_> otherwiseyou'd have to look for the completed action 22.00.30 # <_bilgus_> IIRC it does first lock, first unlock, then auto lock 22.00.49 # <_bilgus_> and once in auto lock it will lock on backlight off 22.01.06 # <_bilgus_> if lock and unlock works that combo is being used 22.01.15 # <_bilgus_> @dconrad 22.02.46 # so the unlock_combo is used for all lock and unlock? 22.02.51 # <_bilgus_> yes 22.03.38 # <_bilgus_> so the action system works on top of the button system 22.04.08 # <_bilgus_> it implements the repeat/release signals as well 22.04.43 # <_bilgus_> but we try to shut down the action sys whil screen locked to save power 22.05.27 # <_bilgus_> so we store that last button and assume that is the button used to lock 22.06.52 # I think I understand 22.08.00 # <_bilgus_> I can explain more if you like what are you looking to do? 22.08.14 # so for instance in do_softlock(), the check if ((action is ACTION_STD_KEYLOCK) or (keys are locked and current button is the unlock combo) 22.08.53 # <_bilgus_> well the action is usually several keys or a key and a release or repeat 22.08.54 # the action_std_keylock is really for when the backlight is currently on, and the other condition is really for when the backlight is off? Or the same but locked/unlocked 22.09.34 # unlocked/locked* 22.09.39 # <_bilgus_> we just store the last button that was a part of that lock action 22.09.56 # <_bilgus_> well the back light is only really used here fr the auto lock 22.10.12 # <_bilgus_> you don't need the back light to do any lock or unlock 22.10.18 # I see 22.10.32 # <_bilgus_> it just uses that screen off notice to know to auto lock 22.10.47 # <_bilgus_> now selective key lock and backlight do a bit different 22.10.51 # well I submitted this on gerrit: https://gerrit.rockbox.org/r/q/status:open 22.10.59 # <_bilgus_> same mech 22.11.14 # and I wasn't sure if my check is sufficient or it should do something with the unlock_combo 22.11.28 # <_bilgus_> which number? 22.11.38 # it works on my device, but I'm sure it won't on some different one 22.11.48 # uhh 22.11.58 # 3240 22.12.02 # <_bilgus_> g#3240 22.12.04 # Gerrit review #3240 at https://gerrit.rockbox.org/r/c/rockbox/+/3240 : If backlight is off and keys are unlocked, power button wakes screen only by Dana Conrad 22.12.23 # <_bilgus_> if the screen was off it shouldn't do that 22.12.33 # <_bilgus_> let me check it might be a keymap issue 22.13.19 Quit Xeha (Ping timeout: 276 seconds) 22.13.49 # <_bilgus_> what device? 22.13.59 # hifi walker h2 / eros q 22.14.11 # a hibylinux device, I think 22.14.30 # so in that state, the action system is supposed to not even be running? 22.16.17 # <_bilgus_> oh it should be runningbut if there is an action mapping to the same as the ky lock then the action system can decide what to do 22.19.57 # <_bilgus_> hmm well we can't do a repeat event on the power button 22.20.10 # <_bilgus_> hmm let me see how I solved this the last time 22.20.46 # so my fix shouldn't work, yet it does? 22.22.39 # <_bilgus_> oh of course it does but actually there is a setting called first kypress activates backlight 22.24.09 # <_bilgus_> settings>general>display>lcd>first button press 22.24.20 # I thought I had that enabled, and it still did it 22.24.36 # let me test it real quick 22.24.40 # <_bilgus_> for sure shouldn't have 22.24.53 *** Saving seen data "./dancer.seen" 22.27.31 Join Xeha [0] (~Xeha@unaffiliated/xeha) 22.28.06 # <_bilgus_> with people wanting to place keylock in the main screen your patch prob has merit 22.28.51 # yeah, I built the master branch real quick and even with "first buttonpress turns on backlight only" turned on, it locks the keys when turning the LCD back on 22.30.39 # <_bilgus_> can you try adding this in the keymap? 22.30.53 # the first buttonpress feature works for all other keys, but not the lock/pwr button 22.32.38 # adding what? (was a file supposed to show up or something?) 22.32.47 # <_bilgus_> { ACTION_STD_KEYLOCK, BUTTON_POWER, BUTTON_POWER | BUTTON_REL }, 22.32.50 # ah 22.33.00 # <_bilgus_> sorry had to type it out 22.33.33 # oh, instead of BUTTON_NONE as the previous button? 22.33.38 # <_bilgus_> yes 22.33.47 # I'll give it a shot 22.33.48 # <_bilgus_> then the other try BUTTON_POWER|BUTTON_REL, BUTTON_POWER }, 22.33.56 # <_bilgus_> same pre part 22.35.55 # <_bilgus_> if that doesn't work then the patch will do but i needs to be pushed into the current logic if ((action == ACTION_STD_KEYLOCK) 22.35.55 # <_bilgus_> || (last->keys_locked && last->unlock_combo == cur->button)) 22.37.29 # <_bilgus_> so add brackets and check if ((!last->keys_locked) && (!is_backlight_on(false))) 22.37.54 # <_bilgus_> and don't forget the backlight define 22.40.31 # yeah, neither keymap change makes the behavior change 22.40.52 # I tried both states of first keypress as well for each change 22.41.33 # I can pretty easily move the check into the preexisting if statement 22.41.54 # <_bilgus_> yes that way its not increasing the amount of code in the hot path 22.42.06 # <_bilgus_> also add tour name to credits 22.42.10 # <_bilgus_> your* 22.42.17 # <_bilgus_> i'll be back in a it 22.42.19 # <_bilgus_> bit 22.42.23 # gotcha, thanks 23.02.33 Quit ac_laptop (Ping timeout: 246 seconds) 23.05.13 # <_bilgus_> ok I know why it does it Button power is special cased 23.05.21 # <_bilgus_> so yeah proceed on 23.06.07 # <_bilgus_> I did that with the original patch because it appears as if the player is hung if no buttons bring up the backlight 23.06.50 # that makes sense 23.07.07 # I uploaded a revision there 23.07.25 # <_bilgus_> that whole adventure was an exercise in breaking stuff 23.08.11 # hah, well it got there in the end 23.08.38 # some of this code has me chasing my tail trying to figure out how it works tbh 23.08.57 # I'm starting to "get it" 23.09.27 # <_bilgus_> already in the credits? 23.09.32 # yeah 23.09.46 # <_bilgus_> ok looks good to me we'll push it 23.09.55 # sick, thanks 23.10.54 # Build Server message: New build round started. Revision d5676fcd90, 293 builds, 9 clients. 23.11.16 # <_bilgus_> ok stick round long enough to make sure its still geen and all will be well 23.11.22 # <_bilgus_> green* 23.12.00 # (y) 23.15.09 # <_bilgus_> bout 10-12 mins make sure it didn't break anything else overtly 23.15.50 # yeah, I thought it would be near instantaneous but I suppose when you're building for this many targets... 23.16.10 # oh, quick question while I've got your ear 23.16.29 # <_bilgus_> I did it on my own machine for the selective backlight and softlock stuff since it was so easy to break half the targets 23.16.57 # <_bilgus_> but it took like 2 hours 23.17.39 # when you need to revise a gerrit patch and you run the command it gives you to download into detached HEAD state, 23.17.47 # <_bilgus_> go head actually always ask questions in chan and someone will answer if they know (eventually) 23.18.00 # does it matter what state your current git tree looks like? 23.18.34 # like, if you branch off for a fix and then upload and need to revise, should you checkout master, or leave it in your branch? 23.18.39 # <_bilgus_> depends how you pull it back n\let me grab my cheat sheet 23.19.04 # I thought I was good at git and then this threw a wrench in my understanding, hah 23.19.18 # <_bilgus_> if you upload but its not pushed then just continue on that branch and commit --amend 23.19.34 # without need to download it again? 23.19.50 # <_bilgus_> if it got pushed then co master then git pull --rebase and do a new branch 23.19.58 # <_bilgus_> yea 23.20.06 # ok, yeah I suppose that makes sense 23.20.10 # thanks 23.20.40 # <_bilgus_> yeah just if you mess up and do a commit --amend on a new branch i pulls you back to the previous commit 23.20.55 # <_bilgus_> so in that case delete everything and it will cancel 23.21.01 Join f1reflyylmao [0] (~f1refly@dynamic-095-116-000-128.95.116.pool.telefonica.de) 23.21.06 # <_bilgus_> ie all text in the commit 23.21.34 # oh, huh so that's how you cancel a commit 23.22.02 # <_bilgus_> now pulling back stuff in your branch I'd recommend grabbing git-review 23.22.16 # <_bilgus_> then you can use the gerrit id 23.22.44 Quit cockroach (Quit: leaving) 23.23.12 Quit f1refly (Ping timeout: 246 seconds) 23.23.12 Nick f1reflyylmao is now known as f1refly (~f1refly@dynamic-095-116-000-128.95.116.pool.telefonica.de) 23.23.32 # but a branch should basically be a single commit, because that's all that gets submitted to gerrit, right? 23.23.40 # the most recent commit 23.24.05 # or the whole chain will 23.24.16 # <_bilgus_> well I sometimes do a branch either mine or someone elses then do a checkout -b newbranch and that makes it a child of the first 23.24.38 # <_bilgus_> then in gerrit it will tie them together 23.24.48 # <_bilgus_> so they go lock step on commit 23.25.12 # <_bilgus_> or even several off that new 'master' commit 23.25.41 # god git can get complicated quick 23.25.56 # <_bilgus_> typically people like incremental changes but sometimes its just abig glob of ugly no matter what 23.26.28 # <_bilgus_> but one thing we try not to do is have whitespace changes mixed in with code 23.26.44 # <_bilgus_> split that into a different commit so is easy to follow 23.27.03 # <_bilgus_> then do a child off that with your code 23.27.38 # <_bilgus_> also when rebasing gerrit can't alwasy do the stuff git can do 23.27.48 # Build Server message: Build round completed after 1014 seconds. 23.27.50 # Build Server message: Revision d5676fcd90 result: All green 23.27.54 # <_bilgus_> woot 23.27.55 # I'm not sure I follow the whitespace thing 23.28.10 # so like you're on master, make a new branch 23.28.29 # <_bilgus_> so you run into a file with spaces at EOL or tabs instead of 4 spaces 23.28.49 # <_bilgus_> and you want to change that in addition to code 23.29.38 # <_bilgus_> so when we review we have to wade through the 50 lines that nolonger end in space and its hard to find the 6 lines of code that were chnagse 23.29.45 # <_bilgus_> so instead starting at mastwer 23.29.50 # <_bilgus_> git pull --rebase 23.30.00 # <_bilgus_> git checkout-b branchws 23.31.01 # <_bilgus_> do your whitespace changes git commit - whitespace changes bleh -> 23.31.45 # <_bilgus_> push head ref for master 23.32.00 # <_bilgus_> then checkout -b branch code 23.32.07 # <_bilgus_> rinse repeat 23.32.23 # <_bilgus_> thenj once in gerrit it will subit both 23.32.29 # <_bilgus_> when pushed.. 23.33.23 # so the "real" branch is a branch off the fake whitespace branch, and they get pushed separately, but they're somehow tied together still? 23.34.09 # <_bilgus_> you could always just push to master do the compile 23.35.14 # <_bilgus_> rebase then do code but instead you do it as a ws change commit and a child (or after the first one is submitted if you prefer) then the second one is applied on top 23.35.41 # huh, ok 23.35.55 # <_bilgus_> in gerrit it will be like 'hey you have a second commit here would you like to push them together?' 23.36.33 # <_bilgus_> or you know just don't do a bunch of unrelated ws changes 23.36.48 # ok, so gerrit is smart enough to know when one open commit follows another 23.36.51 # <_bilgus_> but thas not the only place it appliues 23.36.53 # also, yeah gotcha 23.37.22 # <_bilgus_> its comes into play when you have really big shit that touches a bunch of stuff 23.37.52 # <_bilgus_> then you can do a bit test and move onto a new branch to keep it organized 23.39.22 # <_bilgus_> but git sucks sometimes so i've had to hand rebuild trees when people change things in the middle of your patch -> child -> child chain so try to get them in gerrit to protect your work 23.39.35 # <_bilgus_> only an ass would push on a conflict thats WIP 23.41.45 # <_bilgus_> actually git is the thing that marks the parent child relations 23.41.57 # <_bilgus_> but gerrit picks it up yeah 23.42.34 # <_bilgus_> you can also do weird voodoo with rebasing ontop of new parents and it sometimes works 23.42.48 # <_bilgus_> (in gerrit) 23.54.25 Join ac_laptop [0] (~ac_laptop@186.2.247.129)