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 2016-11-07

00:02:43 Quit cc___ (Ping timeout: 260 seconds)
00:09:14 Quit paulk-collins (Quit: Leaving)
00:35:45__builtincan someone test g#1413 on a slow target with cpu boosting available?
00:35:46fs-bluebot_Gerrit review #1413 at : XWorld: some fixes by Franklin Wei
00:36:07*__builtin is trying to avoid boosting the cpu all the time to save power
00:38:30[Saint]There's a couple of targets where boosted vs. unboosted doesn't really provide a great deal of saings.
00:38:43[Saint]Classic would be a pretty decent example.
00:38:49[Saint]Perhaps the best example.
00:38:55__builtinmmh, I beg to differ
00:39:06[Saint]Well, you're free to do so.
00:39:15__builtinunboosted with smooth scaling gives absymal performance
00:39:45[Saint]trading more cpu time at a lesser clock for less cpu time at a higher clock on the classic doesn't really provide much savings at all.
00:40:07__builtinmaybe 50% target frame rate, while boost gives around 200-300% target fps
00:40:51__builtinoh wait, you mean power-wise, right?
00:40:58[Saint]have you actually measured how much power you're actually saving on the classic?
00:41:01[Saint]and, yes, yes I do.
00:41:41[Saint]you did say 'to save power', should I have parsed that differently?
00:42:45__builtinsorry, I misunderstood what you said
00:42:49[Saint]N2G is another one where the benfits or caveats of scaling can be debated I believe.
00:43:15[Saint]mainly because it is difficult to get a universally stable underclock.
00:43:33__builtinso are you saying that boost doesn't drain all that more battery than no boost?
00:44:26[Saint]For some targets, yes. For others where a great deal of time has been spent on clocks/divisors/voltages, it makes a large difference.
00:46:01 Quit ender` (Quit: Two possibilities exist: Either we are alone in the Universe, or we are not. Both are equally terrifying. — Arthur C. Clarke)
00:46:24__builtinhmm, so should I try to make boosting more selective or just forgo the notion altogether and boost all the time?
00:46:50[Saint]I think in the context of this type of plugin if you need to boost to get realtime you may as well do so because the savings overall aren't going to be very significant.
00:47:06[Saint]I doubt people are really spending hours at a time on any given plugin.
00:48:19***Saving seen data "./dancer.seen"
00:48:35[Saint]based on frame rates alone as long as you're pushing around 30fps no one is going to actually see a difference anyway.
00:48:58[Saint]30fps and 300fps are for all intents identical.
00:49:25__builtinactually the game was written to run at around 10-12fps anyhow
00:49:50[Saint]ah, right - one of the many games of the era that tie events to frame rate?
00:50:08[Saint]modern games still occasionally do that and it boggles my mind.
00:50:14__builtinin fact it varies throughout
00:50:23[Saint]for legacy games it is way more forgivable.
00:51:37*__builtin will remove the selective boost code then
00:52:11 Quit JanC (Ping timeout: 260 seconds)
00:52:32 Join JanC [0] (~janc@lugwv/member/JanC)
00:54:03[Saint]If we're talking about running the clocks boosted or unboosted full-time, then yeah - that'll definitely impact.
00:54:27[Saint]But in the context of a plugin where people aren't likely to be running it for extended periods I don't really think it matters a lot.
00:54:38[Saint]If you need to boost to get acceptable gameplay, you may as well.
00:55:11__builtinwell the thing is it doesn't always have to boost for full frame rate
00:55:42__builtinthe classic for example runs the game at faster than the target frame rate in some cases
00:56:09__builtinbut then slower than the target rate in others (with fancy scaling turned on, for example)
00:56:27[Saint]well, neither does mpegplayer - for instance. but it does. I think this is primarily because the impact is so small, and the complexity to do otherwise is fairly large.
00:56:52[Saint]somewhat of a tradeoff, I guess.
00:56:55__builtinyeah, I guess that's right
00:59:28__builtinbut it should still unboost when it comes to menus and other lightweight tasks, so I need to fix that
01:07:19[Saint]If you ask me, I think we're doing scaling wrong for the 'high power' targets.
01:07:27[Saint]But Doing It Right(TM) is a lot of work.
01:08:09[Saint]Intermediate scaling is very hard to practically impossible to implement without walking across pretty much everything.
01:09:06[Saint]I think we need at least three scaling levels and an interchangeable governor system.
01:10:39 Quit michaelni (Ping timeout: 260 seconds)
01:13:04 Join michaelni [0] (
01:18:40 Quit michaelni (Quit: Leaving)
01:30:54 Join michaelni [0] (
01:36:32 Quit krabador (Quit: Leaving)
01:40:59 Quit ulmutul (Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923])
01:45:21 Join shamus [0] (
02:00:57__builtinalright then, could someone merge g#1413 now?
02:00:59fs-bluebot_Gerrit review #1413 at : XWorld: some fixes by Franklin Wei
02:03:18 Quit ZincAlloy (Quit: Leaving.)
02:20:27 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
02:20:51 Join fs-bluebot [0] (
02:23:07 Quit fs-bluebot_ (Ping timeout: 250 seconds)
02:23:51 Quit bluebrother^ (Ping timeout: 268 seconds)
02:24:34 Quit krnlyng (Ping timeout: 250 seconds)
02:37:29 Join krnlyng [0] (
02:48:20***Saving seen data "./dancer.seen"
03:25:53 Join saratoga [0] (123e11e0@gateway/web/freenode/ip.
03:26:36saratoga[Saint]: pamaury: I added a special workaround for multi-volume targets not long before the file system rework
03:27:19saratogait basically checked when parsing ambiguous paths to see if using the internal or external storage made more sense based on the current working directory
03:27:22[Saint]saratoga: aha - so I was right in remembering it working?
03:27:32saratogai didn't notice that it was removed during the file system rework until recently
03:27:45[Saint]thank you, I thought I was going mental.
03:29:15saratogaprobably not too hard to put back (its only a few lines) but I haven't had time to look at it
03:29:45[Saint]my main issue is having to familiarize myself with the fs code again.
03:30:00[Saint]it's significantly more complex now.
03:41:00 Quit shamus (Quit: chaos reigns within reflect repent and reboot order shall return)
03:46:09saratogai don't have time to play with this now, but it looks pretty trivial to add back the old behavior
03:48:59 Quit [Saint] (Ping timeout: 260 seconds)
03:56:14 Join Bilgus [0] (ae6611d9@gateway/web/freenode/ip.
03:58:50 Join [Saint] [0] (77e01fae@rockbox/staff/saint)
03:59:20__builtinhmm, well looks like I figured out how to bypass the code wheel verification
03:59:25__builtinon all versions of the game
04:24:34Bilgus[Saint]: I got the button selection done if you have time you minds telling me what you think?
04:30:53 Join Harbec [0] (
04:32:15Harbecjust installed rockbox on an ipod classic 6th generation, thanks to whoever did the tutorial!
04:41:35[Saint]did you use the dualboot bootloader (Yes.) or Freemyipod's emCORE (No.)?
04:44:26[Saint]Excellent. The reason I ask is that if you're on a Windows based machine you need to know that at this stage USB still isn't particularly solid and if you have problems you should force Apple Dick Mode or the original firmware for USB.
04:44:43[Saint]Argh, that was unfortunate.
04:44:56Harbecstill makes sense
04:45:58saratogaisn't USB stable now? i have never succeeded in crashing the same driver on AMS
04:46:13[Saint]ANd with emCORE it is quite possible to get yourself in to a situation where you need to remove the battery if it gets deep discharged.
04:46:37HarbecI had no bugs/unstable issues yet, I will keep you inform if I find one
04:46:38[Saint]saratoga: I'm still getting reports of people having write corruption on batch transfers under Windows.
04:46:50saratogawith a stock hard drive?
04:47:20TheSeven[Saint]: really? there should be a universal way of recovering from a deep discharged battery situation (100mA charge with lock switch on)
04:48:02TheSevenalso with a strong power supply it can actually boot up despite a completely flat/nonpresent battery
04:48:22***Saving seen data "./dancer.seen"
04:48:44TheSevenand emcore has quite some sophisticated code to handle this situation in an end-user friendly way (but not sure if that was ever officially released)
04:48:46[Saint]TheSeven: does this assume an official power supply? perhaps that's the issue I bounced off.
04:48:48 Quit michaelni (Ping timeout: 268 seconds)
04:49:17TheSevenlock + plug in, leave it sitting for 10min, attempt to boot it, should work with any USB power source
04:49:34TheSevenit should stay off when plugging it in, it will charge at 100mA
04:50:21[Saint]I was trying that with my laptops and they just won't supply any power to it at all, I was watching it with an inline meter to make sure I wasn't crazy.
04:50:36[Saint]works with an apple wall wart or a 'dumb' charger though.
04:50:52TheSevenhmm, that might be more of a laptop USB suspend thing then
04:51:09[Saint]Hmmm, possible.
04:51:59[Saint]I really need to motivate myself and acquire time and available effort to backport that deep discharge protection to the other ipods.
04:52:09[Saint]it is insanely useful.
04:53:10 Quit Harbec ()
04:54:35 Part chrisb ("rcirc on GNU Emacs")
05:01:53 Join michaelni [0] (
05:15:01 Join soap_ [0] (~soap@rockbox/staff/soap)
05:17:05 Quit soap (Ping timeout: 260 seconds)
05:20:00 Quit smoke_fumus (Quit: KVIrc 4.2.0 Equilibrium
05:20:49 Quit soap_ (Ping timeout: 260 seconds)
05:21:08 Join soap [0] (~soap@rockbox/staff/soap)
05:25:19 Join soap_ [0] (~soap@rockbox/staff/soap)
05:26:25 Quit soap (Ping timeout: 260 seconds)
05:30:08 Join soap [0] (~soap@rockbox/staff/soap)
05:32:12 Quit soap_ (Ping timeout: 260 seconds)
05:39:57 Quit ParkerR (Ping timeout: 260 seconds)
05:40:33 Join ParkerR [0] (
05:42:35 Quit ParkerR (Changing host)
05:42:35 Join ParkerR [0] (~ParkerR@unaffiliated/parkerr)
06:17:56 Quit TheSeven (Ping timeout: 260 seconds)
06:18:21 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
06:48:26***Saving seen data "./dancer.seen"
06:55:10 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627)
07:00:24 Quit cc___ (Ping timeout: 260 seconds)
07:21:05 Join dfkt [0] (~dfkt@unaffiliated/dfkt)
07:23:56 Quit dfkt_ (Ping timeout: 256 seconds)
07:27:52 Quit Bilgus (Quit: Page closed)
08:03:14 Join wodz [0] (
08:25:03 Join ender` [0] (
08:30:12 Quit ruhans (Quit: Connection closed for inactivity)
08:43:10 Nick GodEater` is now known as GodEater (~whoknows@
08:43:35 Quit GodEater (Changing host)
08:43:36 Join GodEater [0] (~whoknows@rockbox/staff/GodEater)
08:48:29***Saving seen data "./dancer.seen"
08:50:59 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
08:51:24 Quit amiconn (Quit: - Chat comfortably. Anywhere.)
08:51:24 Quit pixelma (Quit: .)
08:54:02 Join pixelma [0] (~pixelma@rockbox/staff/pixelma)
08:54:03 Join amiconn [0] (~amiconn@rockbox/developer/amiconn)
09:08:17 Quit pamaury (Ping timeout: 252 seconds)
09:10:53 Join petur [0] (~petur@
09:10:53 Quit petur (Changing host)
09:10:53 Join petur [0] (~petur@rockbox/developer/petur)
09:54:30 Join elensil [0] (~edhelas@2001:1c02:1903:d800:1b5:ba26:8c63:1529)
10:05:59 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
10:08:33wodzpamaury: I looked at atj hwstub. The commit 0e2b4908 switched driver from polling to irq. I swear it was tested but apparently doesn't work.
10:09:14wodzpamaury: BUT with pre 0e2b4908 which enumerates correctly I still can't connect with recentish hwstub_shell
10:13:37 Join MrZeus [0] (~MrZeus@
10:18:42pamaurywodz: if my memory serves, usb on atj never worked before 0e2b4908
10:20:44wodzpamaury: Not true. It didn't work before we realized that you have to do 4byte transfers to fifo *always* and that was included in initial commit of hwstub for atj
10:22:24pamauryok maybe, but even then I doubt the usb code in the library is to blame
10:22:43*pamaury suggest wireshark or a usb analyzer
10:23:55wodzpamaury: I definitely will try to trace it but I am rather short with time
10:24:49 Quit MrZeus (Quit: Leaving)
10:24:54pamauryyou can always instrument the usb library code with printf to see where it fails
10:25:05 Join MrZeus [0] (~MrZeus@
10:25:15pamauryI guess more debug printing is always useful (it's always hidden behind a verbose switch)
10:27:05wodzpamaury: First I'll try to reconstruct working setup (aka old stub + old tools). Then I can move forward to fix whats broken
10:29:16wodzpamaury: BTW. Can't we recompile soc lib and hwstub lib *always* when compiling tools? Increase in compile time will be tiny compared to time spent on debugging whats not working
10:29:24pamaurywodz: I don't remember when of all this was modified but there was a change in the protocol some time ago. IIrc, the new one mayb use slightly more forms of transfers (like control IN with long payloads)
10:29:48pamaurywodz: yeah, if you want to add the require make -C all over the place just go on
10:30:27wodzI am trying to avoid editing makefiles as long as I can :P
10:32:14pamauryok I'll do it
10:32:32pamauryI have acquired a taste for makefile if one could say
10:32:40pamauryI guess I stared too long at too many of them
10:34:28wodzpamaury: So if I revert 0e2b4908 (which touches atj usb driver only) the stub in theory should work with recent tools, right? Assuming of course that this fixes driver problem
10:34:45pamauryI guess so
10:46:26 Quit girafe (Quit: Leaving)
10:48:31***Saving seen data "./dancer.seen"
10:49:43pamaurywodz: try g#1415
10:49:45fs-bluebotGerrit review #1415 at : hwstub/tools: always run make for the libraries by Amaury Pouly
11:34:53 Join paulk-minnie [0] (~paulk@
12:01:30 Quit paulk-minnie (Ping timeout: 265 seconds)
12:06:24wodzpamaury: I'll keep it in mind to test
12:14:36 Join paulk-minnie [0] (~paulk@
12:16:48 Join robertd1 [0] (~as@
12:31:06 Quit paulk-minnie (Ping timeout: 250 seconds)
12:46:43 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:e9f9:9b6e:b6c5:21f0)
12:48:35***Saving seen data "./dancer.seen"
13:03:03[Saint]pamaury: Oh, not sure if you saw the logs or not?
13:03:10[Saint]Turns out we were both right.
13:03:33[Saint]You had your historical hat on, and I had my fairly-recent (in the grand scheme of things) hat on.
13:04:26[Saint]walking relative paths across internal and external storage was added by saratoga shortly before JhMikeS did the filesystem rework.
13:07:41pamaury[Saint]: if I read the commit saratoga's mention correctly, this has (mostly) nothing to do with relative paths, it's just a problem with playlist code?
13:08:39pamaurybut I admit I don't quite understand this commit anyway, I have zero knowledge of playlist code
13:10:32pamauryalso this commit sees unrelated to how the FS works/is implemented, except for the volume prefix which is still the same as before I think
13:10:53pamauryor do I misunderstand what you mean by relative paths?
13:16:04[Saint]pretty hard to imagine that could be the case.
13:17:27[Saint]the easy way of understanding it is that if a playlist wanted /1/2/3/4.mp3 but this doesn't reside on the internal, but /2/3/4.mp3 resided on external, it could 'Just Work'..
13:18:24[Saint]I was fairly sure it always used to work this way, but, apparently I was mistaken and it was a relatively (excuse the accidental pun) recent addition.
13:20:14[Saint]from memory it decided what path to attempt to use based on where the playlist resided on but I would need to actually look at the code for that.
13:20:55[Saint]without that behavior, you need to use absolute paths, which can be kinda cumbersome - but maybe this is subjective.
13:21:36pamaury[Saint]: you mean the opposite: the playlist wants /2/3/4.mp3 but the file is in /microSD/2/3/4.mp3 ?
13:22:05[Saint]ah, yes. sorry.
13:22:20pamauryok I see what you mean. But this is not a FS problem
13:22:37pamauryI mean the FS can only for file where you ask it to :)
13:22:42pamaury*only look
13:22:52[Saint]Wel, it is in so far as it is a direct regression from that filesystem rework.
13:23:23[Saint]it isn't a 'filesystem problem' per se, sut it used to work, and it no longer does, and the reason why is that massive FS rework.
13:23:28 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll)
13:23:30pamaurybut why was this code from playlist removed then? Since it's unrelated to the fs
13:24:03[Saint]No idea. Have you seen that commit?
13:24:24[Saint]It walks over a bunch of places that have no obvious, or a tenuous connection to the filesystem.
13:24:39[Saint]hundreds of files in thousands of places.
13:25:14pamaurywhich commit?
13:26:05pamauryyeah the commit should have been splitted, I don't object that
13:26:08pamaurybut it doesn
13:26:14pamaury't remove this code from playlist
13:28:09[Saint]No, it does't. It doesn't function as expected though, and I nailed that commit down as the catalyst.
13:28:37[Saint]I never meant to imply that it was deliberate.
13:30:27pamauryah my mistake, the FS rework did change a lot of things in playlist.c to replace most path string code with common functions. And apparently this feature got lost.
13:31:02pamauryI guess it just need to be put back there
13:31:31 Join Bilgus [0] (ae6611d9@gateway/web/freenode/ip.
13:31:46pamauryI think hidding it behind multivolume is broken though, since then we also got support for things like RaaA where the very notion of root is...unclear
13:32:44pamauryI'll have a quick try maybe tonight or later this week, this doesn't look particularly hard
13:34:13[Saint]is very clear in RaaA.
13:34:39[Saint] / is very clear in RaaA.
13:34:57[Saint]It will always be /sdcard or any one of the backwards compatible links thereto.
13:36:14BilgusPamaury: I got that commit up still some formatting changes to do and I've been going through button_target files found quite a few button_ I didn't have
13:36:24[Saint]the notion of what 'sdcard' is in Android, be it internal, or external, is ambiguous.
13:36:31[Saint]But this doesn't matter for our purposes.
13:36:39pamauryBilgus: I don't know if you see pixelma suggestion
13:36:59pamauryshe suggests (and I think she is right) that instead of masking buttons, we should be masking context actions
13:38:06Bilgusanyway I can go through and check what has been loaded against the cat_value mask
13:38:18[Saint]Oh. Hah. I see what I did just now...well, that was stupid.
13:38:21Bilgusremove dups.
13:38:33[Saint]I generated a diff between the same iteration of $file
13:38:38Bilguscontex actions huh
13:38:48[Saint]yes, yes it was removed. I see that now.
13:39:00[Saint]idiot cloudy haze removed.
13:39:06pamauryBilgus: the advantage of masking actions are: 1) no need to know the button (it's just the button used for the action) 2) more sematic (talks about the intended action)
13:40:01[Saint]won't that make the UI stuff a mess because users will have no idea what a button context is but know presicely what the HW key will be?
13:40:58[Saint]basically I'm saying "won't that make for a bunch of magic required to turn the contexts back in to buttons so we can show it to the user?"
13:41:04 Quit elensil (Ping timeout: 260 seconds)
13:41:19Bilguscould use a show me the key I press feature
13:41:24pamaury[Saint]: no for the user it's easy, you say "in WPS, do you want to enable the following actions when soft-locked: Volume +/-, Play, ..."
13:41:40pamaurywhich internally translated to ACTION_WPS_VOLUP
13:41:58[Saint]you really think they'll want that much granularity?
13:42:08[Saint]IMO I think they'll just want VOL+
13:42:12Bilgusin some cases yes
13:42:17pamauryplay and skip is very useful too
13:42:24pamauryI could use that
13:42:53[Saint]Hmmm, I guess. It just makes the UI from elegant to pretty damn convoluted.
13:43:04[Saint]the simple picker is now...not.
13:43:09 Join TheLemonMan [0] (~root@unaffiliated/thelemonman)
13:43:15pamauryWell it's still simple
13:43:24pamauryit's basically the same thing
13:43:37pamauryAnd anyway I expect this will only apply to the WPS
13:43:42Bilgusthe selection is the easy part the hard part is going to be catching the actions at the right time
13:43:55[Saint]I doubt it.
13:44:05pamauryyeah, I think the UI will be pretty clear, be it with keys or actions
13:44:06[Saint]It should also apply with FMS.
13:44:25[Saint]because tune/autotune would be just as useful as seek/skip, no?
13:44:46[Saint]recscreen too, arguably.
13:44:53Bilgusand ffs how long till record too
13:45:00pamaurydo we even have soft lock in those screens ?
13:45:00[Saint]gets messy pretty quick.
13:45:13[Saint]FMS yes, idea.
13:45:19pamaurywell no, because if you allow some keys in all screens then it gets messy
13:45:32pamauryfor example if you don't want to enable skip/prev in fm but you want it in wps
13:45:54pamaury(or if the skip/prev keys in wps have a completely different meaning then skip/prev)
13:46:32[Saint]If you ask me (I'm aware no one did) the idea of a partial user-defined softlock is vomit-in-mouth gross.
13:47:06Bilgusthey can go under sub menus to keep it somewhat tidy but that is a lot of screen and settings to traverse I'd be more worried about the converse where I wanted consistent action between them
13:47:12pamaurywhy? You complain the other ignore you but you ignore them when they want a useful feature
13:47:39[Saint]Once again in English?
13:48:30Bilgusok how about I make a context aware picker as well under a different commit and we can see which looks better
13:50:24Bilgusthe complex part again will be behind the scenes grabbing the actions for selective backlight and softlock
13:51:02[Saint]To be clear, I'm not a fan full stop, I think a softlock should lock keys, all keys, except the combination required to unlock it.
13:51:14[Saint]I think it should be entirely analogous to a HW lock.
13:51:40[Saint]But I'm *really* not a fan of making it foolishly complex and insanely granalar.
13:51:45pamaury[Saint]: do you have any softlock target? If you, I am really surprised you say so
13:51:54[Saint]I do.
13:52:25pamaurywell then clearly we don't have the same use cases. For the fuze+, this would be very nice. And for other targets too
13:52:34[Saint]I always saw this happening, basically.
13:52:45[Saint]opening the floodgates for it to become foolishly complex.
13:52:53pamaury[Saint]: if we go in this direction, I could plain remove the database
13:53:01 Join elensil [0] (~edhelas@2001:1c02:1903:d800:1b5:ba26:8c63:1529)
13:53:09Bilgustouchscreen devices with some real keys is the only place I don't agree ^Fuze+ Yes!
13:53:10pamauryit's complicated, unmainted, unused by the devs, has myriads of crazy options, shoul
13:53:13wodzpersonally I'd expect lock to do ehm. locking. Not semi locking, custom locking or whatever.
13:53:16[Saint]IMHO, anyone who actually knows they want this to be as granular as you want it to be should be perfectly capable of making it happen on their own time.
13:53:49[Saint]I sincerely doubt Joe User really gives much of a shit to be honest.
13:54:10pamaurywell we have different views. But just to give you an example, take the Fiio's, the OF has this setting
13:54:15[Saint]If they did I would see them wanting buttons over contexts just so they aren't constantly forgetting what is applied in what screen.
13:54:42[Saint]historically what the OF does or doesn't do has had pretty much zero consequence on Rockbox.
13:54:56[Saint]We've even thrown this at users before several times in a "so what?" fashion.
13:55:00pamauryYou are saying use Joe doesn't care, if it was the case I doubt the OF would have it
13:55:49[Saint]If you think any firmware has features because they believe the end users all deeply care about it - I've got some news for you about how the majority see Rockbox.
13:56:09[Saint]It was likely similar to this, here. Some dev wanted it and no one in QC said no.
13:56:13pamauryHonestly how is this complicated:
13:56:14pamauryWPS: volume +/-, play, prev/next
13:56:14pamauryFM: volume +/-, skip
13:56:14DBUGEnqueued KICK pamaury
13:56:14pamaurySeems obvious to me how it works
13:56:45[Saint]if it were formatted that way, I might agree.
13:56:57[Saint]But it will need to be a single colum list with subheaders.
13:57:05pamauryyeah that's how it should be
13:57:30wodzpamaury: I probably miss your usecase but why do you see semi locking as desired feature?
13:57:37pamauryBilgus reused the filesystem selector code, which supports subelements I think
13:58:00pamaurywodz: you can soft-lock the target (lock touchpad) and still use volume +/- without unlocking
13:58:17[Saint]which is exactly how a lock should not work.
13:58:24[Saint]locks should...lock.
13:58:29wodzpamaury: +1
13:58:40pamaurywhich is exactly how it should work, because touchpad is VERY different from physical buttons
13:58:40wodzI mean lock should lock period.
13:58:47pamauryif you have it in your pocket, that's a life saver
13:59:06[Saint]unwanted button presses are a lifesaver?
13:59:08[Saint]Who knew?
13:59:16[Saint]"its a feature(TM)"
13:59:22pamaury[Saint]: no one forces you to enable it
13:59:51[Saint]This is true, but every 'feature because feature' needs clear discussion.
14:00:00pamauryAll smartphones do that, maybe everyone has become dumb about what locking means
14:00:02[Saint]we got in this mess because of exactly this reasoning.
14:00:11[Saint]now we have a million fucking settings that no one uses.
14:00:22[Saint]except the one guy who added it.
14:00:22pamaurythis feature is asked very often
14:00:32pamauryfor the fuze+ at least
14:00:36BilgusI want it for backlighting
14:01:00Bilguswell target wise atleast
14:01:08wodzpamaury: does fuze+ have hw buttons for vol+/vol- ?
14:01:21Bilgusby context makes sense there
14:01:24pamaurythose are the only physical buttons with power
14:01:42BilgusI have a fuze+ and that is its downfall
14:02:06Bilgusno clip and constantly unlock to change vol
14:02:22[Saint]how often do you need to change volume?
14:02:28[Saint]do you not use replaygain?
14:03:33wodzI state once more, personally I think this is bad design (TM) to not lock *some* buttons.
14:03:53[Saint]I absoilutely agree.
14:04:02[Saint]sans spelling mistakes.
14:04:06BilgusI repaired my clip+ over it..
14:04:47[Saint]serious question, if the stated case seems to be volume - how often does this actually happen?
14:05:02pamauryI don't understand you guys, you are basically saying that a feature like what all smartphones have and everyone uses is useless, I don't get it.
14:05:06[Saint]I pick a comfortable listening volume and this literally never changes.
14:05:19pamauryI change volume quite often, call me strange if you want
14:05:34Bilgusfor me probably 20-30x an 8hr day
14:05:43[Saint]a smartphone WILL NOT activate the HW volume buttons unless the screen is awake.
14:05:52[Saint]So you need to activate the lockscreen anyway.
14:05:58[Saint]may as well unlock at that point.
14:06:12[Saint]so - no.
14:06:13pamaurythat's not true, most smartphone let you change the volume when screen is locked
14:06:14[Saint]very no.
14:06:37[Saint]Yes, but you still need to wake the screen.
14:06:50pamaurythat's the WHOLE point
14:06:54[Saint]I know of no phone that acts like this.
14:06:58[Saint]AOSP sure as shit doesn't.
14:07:17[Saint]note, I am saying *wake* the screen, not unlock.
14:07:44[Saint]with the screen not powered on, HM bottums are all dead in every phone I own.
14:07:53[Saint]With the exception of 'long power == hard reset".
14:08:09[Saint]*HW buttons, bah - spelling.
14:08:20Bilgushtf do you wake the screen on say the fuze+ lol auto relock would be the next 'feature'
14:08:48[Saint]therein lies the clusterfuck of why this sucks.
14:09:04[Saint]its bad idea UX turtles all the way down.
14:09:50pamaury[Saint]: you know what? Forget about it, we'll do it as usual: a patch on gerrit so that users "that know what they are doing" can download it and apply it
14:09:57pamaurythis has worked oh so well so far
14:10:25[Saint]so - what I said about ten minutes ago then?
14:10:26Bilgusbutton remap will be the next thing and that is the real cluster
14:10:41pamauryI just don't want to argue anymore
14:11:10[Saint]Bilgus: yeah - that's a messy one, before the weird touchscreen on this it was kinda a NODO.
14:11:29[Saint]But this touch panel made the concept of what was or wasn't a button kinda ambiguous.
14:11:42Bilgusstill a no in my book that is needlessly complex to the nth
14:14:01BilgusI'm off Ill look at this later on and see which direction to go
14:14:14 Quit Bilgus ()
14:14:18[Saint]actually, I think it may have been 'demoted' by way of protracted discussion from a NODO to a DoItRight.
14:14:44[Saint]It isn't like we use the HW buttons as they're labelled 100% of the time anyway.
14:17:52 Quit thrillho_ (Ping timeout: 250 seconds)
14:24:49 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury)
14:35:38 Quit pamaury_ (Ping timeout: 250 seconds)
14:45:33[Saint]I want to say it, just so it is absolutely crystal clear, and it doesn't matter if anyone already knows it or if they believe it or not, but it isn't personal.
14:45:40[Saint]It's never personal.
14:46:21[Saint]I know I have a way of wording things that is like the verbal equivalent of brutalist architecture, and I work to change this where I can, but I am fallible.
14:47:39[Saint]I just think that each of us has a certain duty to protect a project that we love from what we passionately believe are for lack of a better way of putting it, bad ideas. And I realize what constitutes a bad idea is subjective.
14:48:37***Saving seen data "./dancer.seen"
14:48:47[Saint]If I came up with something that you thought was a truly bad or poorly thought out idea on my part, I'd expect people to challenge me on it at least as passionately.
14:50:13[Saint]I really think we need to concentrate on removing or unifying a bunch of settings.
14:51:15[Saint]To add more I think it needs to be a _reaaaally_ good idea and essentially free, or preferably at a negative binsize.
14:57:35pamauryI still believe that allowing some keys on soft-lock is a good idea. I don't believe that there exists free features
15:02:21 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll)
15:10:13sthlately there's been bricked xduoo x3
15:10:28sthapparently they all ran the unofficial port
15:10:44[Saint]I guess it is somewhat like Schroedinger's Feature.
15:11:27[Saint]A feature that exists in states of being both shit, and great, until it is observed.
15:12:30pamaurysth: I can't see that in the forums, was that reported elsewhere?
15:12:49sthheadfi, xduoo x3 rockbox thread
15:12:53sthit's a recent thing
15:13:10sthmight be a bad batch of flash chips
15:13:19[Saint]I didn't think it was really possible to brick an Xduo X*?
15:13:34[Saint]Barring actual hardware failure I mean.
15:14:13pamauryIt's impossible to really brick it but it might be hard to recover
15:14:31wodzxduoo x3 unoficial port was RaaA, no?
15:14:39pamauryno it's a native port
15:14:40sthit's random apparently
15:14:44[Saint]Oh. Sorry. Did you mean it just incidentally, or is the implication that it is Rb related?
15:14:46sthjust happened one day
15:15:09[Saint]I can't seem to find it, broken google-fu.
15:15:30[Saint]is it "there's a bricked Xduo" or "Rb bricked an Xduo"?
15:15:40sthit seems no one really know what caused it
15:15:58 Quit thrillho_ (Ping timeout: 256 seconds)
15:16:10sthit's a bricked x3 that just happens to run rb, might be rb related or not
15:16:37[Saint]thank you. sorry, I made that needlessly hard.
15:16:54wodzah, ok. So currently it has the same status as dying clips I'd say
15:17:16sthit sorta started here:
15:17:24sthhaven't been following it
15:17:27[Saint]yeah, sad fact of life is that nands just occasionally shit the bed.
15:17:55sththing is with rb it doesn't even use internal storage
15:18:05[Saint]I guess it could be arguable deep down as to if there was a software cause in some unicorn-rare case though.
15:18:38[Saint]but without a bunch of hardware to brick and a repeatable method by which to brick it...well, yeah.
15:19:00 Join amayer [0] (
15:29:04wodzthe guy who reported bricked xduoo x3 reports a few pages later that after taking apart and disconnecting battery the player was back to life.
15:29:12 Quit wodz (Quit: Leaving)
15:29:12 Quit advcomp2019_ (Ping timeout: 250 seconds)
15:40:36 Join paulk-collins [0] (
15:44:16 Join Fa1th [0] (~Fa1th@
15:45:55 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
15:58:29 Quit amayer (Remote host closed the connection)
15:59:36 Join Bilgus [0] (
16:01:41 Join amayer [0] (
16:03:36BilgusPAmaury: the underlying code for the backlight and soft lock arent terribly huge wonder if [saint] etc. Would be ok with the button masks being added and then back to the plugin idea..
16:05:12[Saint]plugins don't really have any business governing system settings IMO.
16:06:08[Saint]I don't believe we have any that do so.
16:06:40BilgusIt would pull it out of the main binary though and make it pretty easy for those that don't care to get rid of it
16:07:22pamauryBilgus: I suggest you keep with whatever approach you like at the moment and when you have something working, put it on gerrit. The plugin is not going to solve the problem, what [Saint] is against the concept itself
16:08:38[Saint]I have my opinions about how a softlock should act, but I want it known for the record that I was pretty cool with the idea until it got really convoluted.
16:09:44[Saint]and, shit, why does what I think even matter? heaps of things I dslike with a passion got in anyway because no one cares what any one person thinks and no should they.
16:10:46[Saint]*nor should they
16:11:10pamaurywell it's going to be tricky. [Saint] is for buttons and pixelma said she was more for actions.
16:11:22BilgusAlready up ill fix the dup buttons issue hopefully tonight and then work on a context version
16:13:21[Saint]this whole concept of softlock action is a really touchy subject. This is far from the first time there's been a heated discussion about dynamic or selective softlock.
16:13:35BilgusTrying to please everyone always gets you in trouble so whats the least disliked?
16:13:39[Saint]It just so happens to be that there are approximately equal camps on both sides.
16:14:04gevaerts[Saint]: but is it resistively touchy or capacitively touchy?
16:14:40[Saint]gevaerts: hm? in what context sorry?
16:15:13[Saint]hardy har.
16:15:15gevaerts[Saint]: sorry, my brain sees jokes where there may not be any :)
16:16:35[Saint]Bilgus: myself personally if i accept that it is going to happen as an immutable fact, I would prefer it to be button based and in-core.
16:17:28[Saint]button based because state dependant context is a bit much in my honest opinion and in-core because We Just Don't Do That (TM) with plugins.
16:17:38pamauryI guess I can settle for buttons, in the end I think it's just more complicated and more code but meh
16:18:44[Saint]plugins that modify system behavior opens somewhat of a floodgate that it seems like we've been really careful to keep closed.
16:19:35[Saint]I believe we want it to Just Work even if you happen to build without plugins, or remove them, or end up in some screwing pluginAPI mismatch.
16:22:12pamauryyeah the plugin is a bad idea
16:22:27pamauryand it requires code in core anyway to filter the buttons
16:25:51 Join krabador [0] (~krabador@unaffiliated/krabador)
16:28:08 Quit Bilgus (Ping timeout: 250 seconds)
16:32:20 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury)
16:32:43 Join Bilgus [0] (
16:33:38BilgusPAmaury ok so buttons it is have you decided what you want to do on the button names?
16:35:26 Quit Bilgus (Remote host closed the connection)
16:35:48 Quit Rower (Ping timeout: 260 seconds)
16:39:43 Join Bilgus [0] (
16:41:02 Join ZincAlloy1 [0] (~Adium@2a02:8108:8b80:1700:e9f9:9b6e:b6c5:21f0)
16:41:52 Join amiconn_ [0] (~amiconn@rockbox/developer/amiconn)
16:41:52 Nick amiconn is now known as Guest87200 (~amiconn@rockbox/developer/amiconn)
16:41:52 Quit Guest87200 (Killed ( (Nickname regained by services)))
16:41:52 Nick amiconn_ is now known as amiconn (~amiconn@rockbox/developer/amiconn)
16:42:28 Quit Ivoah (Ping timeout: 250 seconds)
16:42:52 Quit ZincAlloy (Ping timeout: 250 seconds)
16:43:12 Quit pixelma (Disconnected by services)
16:43:12 Join pixelma_ [0] (~pixelma@rockbox/staff/pixelma)
16:43:18 Quit Slasheri (Ping timeout: 250 seconds)
16:44:03pamauryBilgus: well since we are going for buttons this is going to be tricky. Either you do it by hands for all targets, or you use a script and derive names semi-automatically
16:48:03BilgusI like the script idea the ifdefs are already getting unwieldly but how does that fit into compiling.. Seamlessly i hope. or do it in button_target for each
16:48:04pamaury_and it's going to be massively tricky anyway since some button-target.h are shared between targets with some ifdef sometimes
16:48:33pamaury_Bilgus: I guess you create a huge list in some dedicated file in the settings
16:48:39***Saving seen data "./dancer.seen"
16:48:49pamaury_which is generated by a script the very first time, and then edited by hand
16:49:08 Join Ivoah [0] (uid49352@gateway/web/
16:49:42BilgusTrying what i have atm on a few sims its not too bad and once i finish dup removal its just a case of defining the special names first
16:50:11pamaury_Another option is to given up putting all keys (since most of them won't ever be used) and focus on a the few that matter
16:50:28pamaury_probably either to do with some grepping
16:50:51pamaury_other I can dig up a script I wrote some time ago that could tell use whic defines exist for each build (more or less)
16:51:03pamaury_(if I can find it)
16:54:09 Join Slasheri [0] (
16:54:09 Quit Slasheri (Changing host)
16:54:09 Join Slasheri [0] (~miipekk@rockbox/developer/Slasheri)
16:54:11pamaury_hum it doesn't quite to the job but can be modified, wait a minute
16:54:16pamaury_that could save a lot of time
16:56:49BilgusK that would be helpful. Lastnight i got through 5 pages of the online source searching for button_ with 50+ to go
17:02:09BilgusI think just default to a standard list if there isn't a special define in button_target and then we only have to define for special targets but maybe just better to define for each kinda torn on whats going to be better
17:05:17 Join Rower [0] (
17:06:19 Quit Bilgus (Ping timeout: 244 seconds)
17:06:50 Quit petur (Quit: Connection reset by beer)
17:07:23pamaury_here is the script but it's tricky to run and require many toolchains: pamaury/2ff88a35c5866d2cd62e8a796f297447"> and
17:07:23pamaury_And here is the result (partial only): pamaury/385b38342a1562e854e478ba62390212">
17:08:00pamaury_however it's probably more manageable if you focus on a few buttons
17:11:11 Join Bilgus [0] (
17:11:58BilgusIll have to catch up in log. My lunch is over ill be back to my dev machine in 6hrs
17:14:50 Quit Bilgus (Read error: Connection reset by peer)
17:32:01 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.")
17:45:50saratogathe stuff i did isn't exactly relative paths, its just handling ambiguous paths
17:45:57saratogalike C:\music\file.mp3
17:46:22saratogathe original behavior was to always guess that C:\ was the root, but that failed if you had an SD card with the music on it
17:46:59saratogaso i changed it to guess that "C:\" should refer to whatever volume the playlist was on, which is right 99% of the time
17:49:38pamaury_yeah, this needs to be redone, the FS rework simply removed the code
17:49:58pamaury_I wasn't aware of this feature, since I don't use playlists
18:01:56 Quit elensil (Quit: Leaving.)
18:05:07 Quit pamaury (Remote host closed the connection)
18:08:11 Quit dfkt (Disconnected by services)
18:08:16 Join dfkt_ [0] (~dfkt@unaffiliated/dfkt)
18:08:26 Quit dfkt_ (Remote host closed the connection)
18:08:50 Quit pamaury_ (Ping timeout: 244 seconds)
18:19:20 Join dfkt [0] (~dfkt@unaffiliated/dfkt)
18:21:50 Quit toli (Ping timeout: 256 seconds)
18:28:14 Join toli [0] (~toli@
18:28:24 Join Senji [0] (
18:29:19 Quit rela__ (Quit: Leaving)
18:29:40 Join rela [0] (~x@pdpc/supporter/active/rela)
18:32:35 Quit Senji (Client Quit)
18:48:40***Saving seen data "./dancer.seen"
18:49:47 Quit Kruppt (Quit: Leaving)
18:55:59 Join girafe [0] (
18:57:48 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
19:25:33 Join Kruppt [0] (
19:26:04 Join lebellium [0] (
19:51:09 Join SJXwcLvbMwrBRBsD [0] (
19:51:13 Quit SJXwcLvbMwrBRBsD (K-Lined)
19:59:29 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627)
20:16:04 Join Link8 [0] (
20:18:17 Quit Link8 (Remote host closed the connection)
20:19:29 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll)
20:23:56 Quit thrillho_ (Ping timeout: 240 seconds)
20:26:37 Join smoke_fumus [0] (
20:36:40 Quit Kruppt (Quit: Leaving)
20:48:43***Saving seen data "./dancer.seen"
20:51:04 Quit pamaury (Ping timeout: 244 seconds)
20:51:27 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
20:59:33 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll)
21:04:20 Quit thrillho_ (Ping timeout: 248 seconds)
21:24:58 Quit amiconn (Quit: No Ping reply in 64 seconds.)
21:25:08 Join amiconn [0] (~amiconn@rockbox/developer/amiconn)
21:38:46 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll)
21:43:43 Quit thrillho_ (Ping timeout: 260 seconds)
22:04:04 Join Bilgus [0] (ae6611d9@gateway/web/freenode/ip.
22:04:44BilgusPAmaury that is a lot of buttons nice script though
22:05:08pamauryyeah, that's why I suggest to focus on a few buttons
22:10:17BilgusI think I can tweak that to spit out a pre formatted list but I'm leaning towards a standard list in the file and a table in each button_target
22:11:43pamauryI don't know which one is better, because spreading this info all around the place is not great
22:12:05CtcpIgnored 1 channel CTCP requests in 0 seconds at the last flood
22:12:05*pamaury thinks actions would be so much simpler
22:14:04Bilgusfar fewer variables it the overall scheme of things
22:17:55BilgusIll finish up the button one with what I have already
22:19:09BilgusWhat if we didn't present the actions as individual contexts and instead merged all the similar actions across all contexts that applied
22:20:21pamauryyeah I was thinking that
22:20:33 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll)
22:20:58pamauryit's probably easy, I think volume is always ACTION_WPS_VOL{UP,DOWN} and then one needs to gather PLAY and SKIP for several screens
22:21:10[Saint]Bilgus: what IRC client do you use?
22:21:45[Saint](hint: you should be able to type the first letter of a nick, and then press [Tab] to auto-complete it)
22:22:06Bilgususing web atm
22:22:14[Saint]{Just [Tab] by itself should autocomplete nicks based on last-spoken-order}
22:22:35[Saint]The latter is hit and miss on any given client, the former should always work.
22:23:09[Saint]I just noticed that you must've typed out PAmaury by hand.
22:23:16[Saint]So I thought I'd give a heads up.
22:23:51[Saint]No one knows how to spell pamaury or gevaerts without nick completion :p
22:23:59gevaertsI know both!
22:24:30gevaertsIt's names like Siant that cause me trouble
22:24:30[Saint]geveeaeaaerts: Shuush, you do not!
22:24:32Bilgusits been twenty years since I Irc'd those scripts were always a source of entertainment
22:24:49[Saint]Hah, jokes on you, I highlight on siant and sanit. :p
22:25:28 Quit thrillho_ (Ping timeout: 265 seconds)
22:25:36*gevaerts tries stain
22:25:49gevaertsMight be more appropriate :)
22:28:53[Saint]Seems like the Freenode QWebIRC client doesn't do last-spoken-order completing with [Tab] alone.
22:29:28[Saint]It is doing some crazy completion of just '/command foo'
22:32:19Bilguspamaury: I think the action one would only make sense with the WPS I mean why do you need any other context?
22:33:30Bilgus[Saint]: actions are going to be more useful and less code in the end
22:34:19Bilgushave you seen the number of variabilities across the targets?
22:34:21[Saint]behind the scenes, perhaps - I still feellike contexts shouldn't be presented to the user for selection.
22:35:30[Saint]WPS_NEXT/WPS_FF/FMS_SEEK/FMS_* and friends should all be presented under a single 'BUTTON_NEXT' option, IMO.
22:35:49Bilgusdon't present them as contexts
22:36:30[Saint]right, but do you understand what I'm hinting at? Call it 'FF', call it 'Next'...hell, call it Frank for all I care.
22:36:44[Saint]Just group them instead of having the absurdly granular options.
22:39:29BilgusI think I'd go for the WPS name and then make it carry over to the others
22:48:44***Saving seen data "./dancer.seen"
22:53:40Bilgusunfortunately all the action codes are incremented by 1 so that wipes out the mask
22:54:32 Join Guest66888 [0] (
22:56:29Bilguscould multiply each context by 64 and make a new mask
22:57:39 Quit Guest7162 (Ping timeout: 244 seconds)
22:59:32pamauryBilgus: the mask does not need to related to actions directly
22:59:54Bilgusno but it does need to be related to the buttons
23:00:21pamauryyou can create your own mask: MASK_ACTION_VOL = 1, MASK_ACTION_PLAY = 2, MASK_ACTION_SKIP = 4. And then the setting is the OR of that and in the filter code you just decode the mask
23:00:26 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll)
23:00:32pamauryonly a few actions are interesting anyway
23:00:57pamauryand they will correspond to several actions so it's just better
23:02:28Bilgusif you are ok with having a separate function to do that then sounds good
23:03:24Bilgusif you use the pre defined contexts it can all be done bitwise
23:03:29 Quit utrack (Ping timeout: 250 seconds)
23:04:23pamauryI mean that encoding of the setting should reflect what the user chooses, not how its implemented
23:04:47 Quit thrillho_ (Ping timeout: 250 seconds)
23:05:11Bilgusk easier on my end more complex on the back
23:05:21pamauryso the use can choose a bitmap of "Volume +/-", "play" and "skip/prev" then the setting should be a bitmak of 3 items (like those above I listed). Then only in the implemention of the setting (in the button handling code I guess) you related those with the actual context and action
23:05:27pamauryyeah exactly
23:05:41pamaurybecause if we want to change the implementation, this is far easier
23:06:26Bilgusyeah no point in choosing vol up / down
23:10:31 Join utrack [0] (
23:18:33 Join rela_ [0] (
23:22:04 Quit rela (Ping timeout: 260 seconds)
23:26:49 Quit lebellium (Quit: ChatZilla 0.9.92 [Firefox 49.0.2/20161019084923])
23:28:16 Join shamus [0] (
23:35:07 Quit The_Prospector (Quit: when in doubt, kernel panic)
23:36:57 Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman)
23:40:44 Join thrillho_ [0] (~Luke@unaffiliated/rockandorroll)
23:42:59 Quit paulk-collins (Quit: Leaving)
23:45:55 Quit thrillho_ (Ping timeout: 268 seconds)

Previous day | Next day