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 | 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 2022-10-09

00:03:37 Join rogeliodh [0] (
00:24:06 Quit munkis (Ping timeout: 260 seconds)
00:37:10 Quit m01 (Quit: Konversation terminated.)
00:39:00othello7wait why is mpegplayer being removed?
00:39:09 Join m01 [0] (
00:44:01__builtinbuZz: heh, that was me asking about the 6G piezo_start() function
00:44:21__builtinI think I can walk you through what the code means:
00:44:56__builtinmy understanding is that timer A on the SoC is used in GPIO mode to output a digital signal to the piezo
00:45:49__builtinso the trick is configuring the timer to output the right square wave that you want
00:46:04__builtinCH23: ^
00:46:59__builtinthe code you see in piezo_start() is configuring timer A through a series of memory-mapped registers ("TA<XXX>")
00:49:59__builtinthe timer itself is driven from an external 12 MHz crystal (ECLK), which is then divided down to a 100 kHz clock by the configured prescaler values
00:51:02__builtinthe "cycles" argument to piezo_start() is the number of (1/100 kHz) cycles you want the square wave period to be
00:51:38__builtinso if you want a 1 kHz tone, you set cycles=100
00:51:57__builtin(100,000/1,000 = 100)
00:52:22__builtinand the "periods" argument is the number of full cycles to play for
00:53:20__builtinthe "periods" argument takes effect through the interrupt handler, INT_TIMERA, which I think gets called on each full cycle of the timer
00:54:33__builtinthe "force" parameter to piezo_button_beep isn't relevant at all here - that forces the method to spinlock until any previous tone has completed playing
00:54:51***Saving seen data "./dancer.seen"
00:57:55 Join munkis [0] (
01:01:10__builtinspeachy: re: mpegplayer, I think some wider discussion is warranted before deciding to remove it
01:06:23_bilgusi'm still not sure the use case there it seems a novelty at best
01:06:31__builtinthe only real maintenance burden it presented was the need to define keymaps for it during new ports, and it was still fully functional prior to being removed
01:07:18_bilguslike 1-3 " video can compete with phones not to mention the yuv routines
01:07:51__builtinsure - the YUV code is probably a couple KB of core code, but only on targets with plenty of RAM to spare to begin with
01:07:59_bilgusand asm
01:08:23__builtinmy stance on this kind of thing is "if ain't broke, don't fix it"
01:09:04__builtinI think there are still viable use-cases where audio+video playback on a media player is a good thing to have
01:09:52__builtinand there's probably a non-zero number of users still with little music videos encoded for playback on their devices
01:10:03_bilgusi think if thats the case it should probably carry its own routines and remove the burden from core at least
01:10:20_bilgusif possible
01:13:41__builtinI don't think that's technically desirable... it looks like the YUV code depends on lots of target-specific optimized blitting code
01:13:51__builtinwhich, sure, we could throw into apps/plugins
01:14:11__builtinbut it wouldn't make technical/logical sense to do so
01:15:04_bilgusi'm thinking more like ditch the hand assembly in favor of a slightly slower c routine
01:15:18_bilgusthats the big drawback imo
01:15:32_bilgusand maintenance/porting burden
01:15:34__builtinwhy do that? the hand assembly is already written and presumably still works
01:15:55__builtinso for existing targets, the maintenance burden ought to be zero, unless you run out of code space
01:16:17__builtinor majorly change the assumptions of the LCD code, but if you're doing that, you're in for a lot of work anyway
01:16:40__builtinand new targets can (and have, apparently) easily define a stub blit function to no-op it
01:17:21 Quit munkis (Ping timeout: 252 seconds)
01:17:41__builtin(and it looks like there was already a slow C fallback, as you describe)
01:17:54__builtinso new ports had the option of just falling back to that
01:18:31 Join munkis [0] (
01:18:43 Join dfkt [0] (
01:19:31_bilgusI still think that would be a decent compromise but will wait for speachy to state the onus
01:22:34__builtinI do think that the discussion about removing fully functional features ought to be had in a more visible venue (either mailing lists or forums)
02:49:01 Quit CH23 (Ping timeout: 246 seconds)
02:54:52***Saving seen data "./dancer.seen"
03:01:09 Join lebellium [0] (
03:28:37 Quit S|h|a|w|n (Read error: Connection reset by peer)
03:40:57 Quit rogeliodh (Quit: Ping timeout (120 seconds))
04:06:51 Join rogeliodh [0] (~rogeliodh@
04:40:48 Quit rogeliodh (Quit: Ping timeout (120 seconds))
04:42:52 Join rogeliodh [0] (
04:54:55***Saving seen data "./dancer.seen"
06:17:12 Quit amiconn (Quit: - Chat comfortably. Anywhere.)
06:17:14 Quit pixelma (Quit: .)
06:19:38 Join amiconn [0] (
06:19:38 Join pixelma [0] (
06:54:58***Saving seen data "./dancer.seen"
06:57:03 Join CH23 [0] (~CH23@revspace/participant/ch23)
07:14:53CH23hactar|ant, the iPhone 7 plus' taptic engine has some testpads, which when accessed, you only need the first and last one to connect to the ribbon pads where the piezo normally sits. here's a tutorial: and some pics of mine:
07:16:00CH23it feels really nice to use, and somehow still makes the same sound as it did with the piezo
08:26:01 Join amachronic [0] (~amachroni@user/amachronic)
08:35:53 Quit amachronic (Ping timeout: 252 seconds)
08:55:01***Saving seen data "./dancer.seen"
09:45:27 Quit michaelni (Ping timeout: 268 seconds)
09:58:22 Join michaelni [0] (
10:18:32rb-bluebotBuild Server message: New build round started. Revision d73aaf3d9e, 303 builds, 7 clients.
10:46:27rb-bluebotBuild Server message: Build round completed after 1675 seconds.
10:46:29rb-bluebotBuild Server message: Revision d73aaf3d9e result: 120 errors 0 warnings
10:55:02***Saving seen data "./dancer.seen"
11:02:18rb-bluebotBuild Server message: New build round started. Revision 70d5b2cd45, 303 builds, 7 clients.
11:09:27 Join S|h|a|w|n [0] (~shawn156@user/shawn/x-4432647)
11:21:39speachympegplayer was really not anything more than a tech demo, and its limitations are so severe (by modern standards) that it's useless as a selling point/feature.
11:26:00speachyit requires re-encoding videos for the specific device, which in turn has a (very) crappy and tiny screen.
11:26:58speachyI posted the original patchset over a year ago, and I recall a bunch of discussion at the time, though it largely withered into general apathy.
11:28:07speachyand yes, we've been fighting display code space on a lot of targets, and the plugin API has some prtty nasty things in it just to accomodate the mpegplayer plugin.
11:29:18speachythat was one of the reasons I dragged everthing forward to the (Then-)newer toolchains, and went through the pain and bugs uncovered by using -Os by default.
11:31:19rb-bluebotBuild Server message: Build round completed after 1742 seconds.
11:31:20rb-bluebotBuild Server message: Revision 70d5b2cd45 result: All green
11:31:59speachyyeah, my combined UL speed of "19" :D
11:32:32speachyI have another ...36 cores that I could light up for builders but what's the point, given that performance...
11:33:14_bilgusI'm just happy not to have to wait a whole day to compile the whole shebang
11:34:00speachy...If Ian had hit here we'd have lost 60% of our builders for a little while
11:34:31speachyplus the only ones that can handle the android and ibasso builds
11:35:22_bilgusre mpegplayer is it possible to self contain it, it'd hit performance but disconnect it from core −− I saw that there were c routines.. not saying you should do it but if someone is really passionate about it
11:36:48_bilgusI'm still of the thought that 3k for a single novelty plugin is too much even before looking at the asm burden
11:36:54speachyI'm of the strong opinion that we need to focus our limited efforts on making our core features kickass, as audio playback is the _only_ reason we'd attract new users.
11:37:35_bilgusudio and blind users
11:37:54speachya bottom-of-the-barrel smartphone (which is cheaper than any working rockbox-capable player you'd find these days) will do a far, far better job of video playback.
11:38:02speachyaudio and accessibility, exactly.
11:38:40speachyif we're going to go for a moonshot project it would be a bluetooth stack with AVRCP support.
11:38:48buZzi mostly want to build rockbox as application on a gcc from this millenium
11:38:59speachyon a gcc?
11:39:11_bilgusI'm still not impressed with bt audio TBH
11:39:17buZzeg. not gcc 4.x
11:39:30buZzbut gcc 8.x or higher
11:39:30speachyah, ok, I thought you meant something else
11:39:54buZz:) i'm one of the devs on Maemo Leste, and its still missing a 'nice' mediaplayer
11:40:11buZzthought rockbox might fit, but i dont really desire to build a ancient gcc just for a single application
11:40:28speachythe good news is thanks to the sim builds the core is quite fine with modern gcc, but there's always the bare-metal shenanigans.
11:40:49buZznice :) well, 'as application' doesnt have bare metal?
11:41:05buZzshould just be libsdl for everything i guess?
11:41:07speachyall of my buidlers are running Gcc 12.1 right now.
11:41:13buZzoh wait, is it libsdl1 ?
11:41:25speachyyes, we support a generic SDL target.
11:41:36speachylibSDL1, but yes.
11:41:48buZzmeh, libsdl1 is pretty ancient too
11:42:56speachymost of our hosted targets run on top of low-level linux APIs (eg fbdev, alsa, /dev/input) but sdl hides all of that
11:43:22speachyyou can use sdlcompat12 (?) which is a wrapper for SDL1 on top of SDL2 libs.
11:44:22buZzoh fancy
11:44:23speachythere's a good argument for not swithcing to SDL2 natively though, as IIRC the latter pretty much requires OpenGL.
11:44:40buZzyeah OpenGLES2 is the only output that works on my target device ;)
11:44:41speachyie there's no dumb fbdev display backend.
11:45:19buZzquite sure SDL2 still supports fbdev though?
11:46:01speachyat least not at the time I was experimenting with it. SDL2's display API is built around the notion of display lists instead of raw pixel buffers.
11:46:12buZzah, there's directfb , not fbdev
11:48:17speachyhuh, it directly supports kms/drm. Too bad we don't have even that on our hosted targets. :/
11:53:17braewoodsspeachy: what do we use for display on hosted? X? FB?
11:53:45speachyI think they all use fbdev.
11:54:01speachy(don't recall what the ibasso targets use)
11:54:46braewoodsI see. I was thinking SDL2 could be useful for RB general development on the desktop.
11:54:55braewoodsFor testing stuff without having to get out a hardware unit.
11:55:07speachyit wouldn't gain us anything over SDL1 beyond a more modern baseline.
11:55:23speachythe simulator builds already run on SDL.
11:55:50braewoodsAnd would be a massive undertaking to port to.
11:55:56speachy(and there's a generic SDL target allowing for an arbitrary (at compile-time) screen size meant for hosted use.
11:56:59speachyno, I don't think so. the only real work would be to change the existing SDL1 display code to run on SDL2, and since we only sling pixmaps around there wouldn't be much actual change wrt interfacing with SDL itself.
11:57:39speachy(I think input, audio, and threading APIs are unchanged or effectively so)
11:57:50braewoodsI see.
11:58:23speachywhat _would_ be more useful is a native pthead-based threading/semaphore backend.
11:58:44speachythat would make hosted targets a lot more responsive.
11:59:00braewoodsWouldn't that require mutexes and more?
11:59:48braewoodsIt reminds me of issues with GTK+ where it can get weird because of the single threaded event loop it uses.
12:00:04speachysure, but we already have them so...
12:00:24braewoodsApplications are expected to use threads on their own if they need them for application processing.
12:00:44braewoodsBackground threads so to speak.
12:00:59speachywe already are heavily threaded internally.
12:55:03***No seen item changed, no save performed.
12:55:10hactar|antch23 so it's that little module that goes where the battery traditionally sits? that's very cool. is that a common mod? i haven't heard of it
13:53:50CH23hactar|ant i'm not sure how common it is, i think it's slowly becoming a trend right now.
13:56:53hactar|antit fits so neatly in there
14:04:16CH23i have tried soldering to a case but it wouldn't take solder, to maximise the tranfer of vibration to the case. but it's already good this way
14:08:25hactar|antwouldn't that make it difficult to replace the hold switch if that was necessary?
14:09:52CH23there's just about enough space to do so
14:55:05***No seen item changed, no save performed.
15:23:41speachybuZz: I'm attempting to build a series of gcc8.5-based toolchains with binutils/etc from the same era. Arm's the complicated one as we diabled exceptions in the standard library.
15:24:00speachy...I'm thinking I should also enable g++ too
15:24:02buZzoh yeah, totally, all my targets are armv7 :)
15:24:28buZz(atm Nokia N900, Motorola Droid 4 and Pinephone)
15:26:24speachygetting everything onto gcc 4.9 was quite an adventure
15:46:41buZzyeah there's a lot of stuff around that doesnt really seem willing to be ported easily to >4
16:55:07***No seen item changed, no save performed.
17:02:21 Join amachronic [0] (~amachroni@user/amachronic)
17:09:45rb-bluebotBuild Server message: New build round started. Revision 4b8fe8acd1, 303 builds, 7 clients.
17:11:25 Quit advcomp2019 (Ping timeout: 250 seconds)
17:17:13amachronicspeachy: just curious, why pick gcc 8 if updating gcc? why not jump to 11 or 12?
17:18:31speachysplitting the difference with upstream, ie 4 major releases.
17:19:01speachythe most recent stuff (11 and 12 I think) require a C++11 environment.
17:19:17amachroniconly on the host.
17:20:17amachronicwhich according to gcc's C++11 status is complete since gcc 4.8
17:20:23speachyhad to start somewhere.
17:21:38amachronici just figure that updating compilers will expose the same few issues over and over
17:21:51amachronicre. aliasing, bad assumptions about volatile, w/e
17:21:54speachythings are in a lot better shape than when I dragged everything to 4.9 but we'll see. right off the gate with 8.5 X3 doesn't build cleanly. that's where I left it to get some outside work done
17:24:30speachyI _think_ our hosted targets should be okay with newer toolchains but we're stuck with older infrastructure (eg glibc, other system libs) and I don't want to have to patch those any more than necessary.
17:25:03speachyand ultimately the question is if we'll end up with slightly better optimized code or slightly more optimized bugs
17:25:44 Quit lebellium (Quit: Leaving)
17:27:43amachroniccompatibility between new gcc and old glibc and that could be a problem; i don't know much about it
17:28:09q3kit's pretty bad
17:28:28speachyI'm hopping that if anything shows up it'll be solved by forcing using -std=gnu99 or whatever instead of the newer stuff's gnu11
17:28:48q3knot as bad as the other way around (new glibc old gcc), but still bad
17:29:06speachyit's not as critical for hosted targets as they're pure userspace
17:29:16amachronicwe wouldn't have to compile glibc though, only link against it.
17:29:46speachyactually we have to build glibc −− that's the only way we get proper headers to link against.
17:29:54speachybuild against, I mean
17:30:05speachyalsa, zlib, and a couple others too
17:30:07amachronicwell, I know that :P
17:30:33amachronicbut _surely_ glibc and gcc can't screw up a simple C ABI too badly?
17:30:57speachys/glibc and gcc/random soc vendors and integrators/ :)
17:30:58q3khic sunt leones
17:31:04 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
17:32:56rb-bluebotBuild Server message: Build round completed after 1391 seconds.
17:32:57rb-bluebotBuild Server message: Revision 4b8fe8acd1 result: All green
17:33:41speachythe cross-compiler has special needs for glibc sources so it can bootstrap itself. :/
17:34:41amachronicthat tedious dance of building gcc+glibc+linux headers twice :(
17:35:23speachyand/or we could always see how well modern llvm handles things. :D
17:35:36q3kyeah i was gonna say, it might be worth investigating clang/llvm
17:35:47q3kalthough things aren't that great there either - but at least you get cross compilation for 'free'
17:36:43rb-bluebotBuild Server message: New build round started. Revision 4f9e4ddb99, 303 builds, 7 clients.
17:37:16speachythat said I should see how much of a PITA it owuld be to enable C++ (& libstdc++) on this iteration.
17:37:30q3kbootstrapping llvm itself is trivial, it gets messy around clang, it gets even worse around clang cross-compilation/sysroots (mostly because clang has a lot of 'smart' gcc/linux runtime compatibility), it becomes a cognitohazard around compiler-rt/libcxx, and libc is its own mess
17:37:53amachroniclast time I researched it, freestanding c++ is basically useless with gcc/libstdc++
17:38:28speachyoh? I find that interesting given how much of the vendor microcontroller world is built around C++ these days
17:39:20amachronicif you're able to work out how to do it then there's no reason it _shouldn't_ work
17:39:52amachronicbut allegedly freestanding libstdc++ lacks even basic facilities like <type_traits>
17:39:52q3kif you don't use the STL you just need a few shims for global constructors and new
17:40:08speachyI'm just thinking of (eg) some hypothetical future codec/library or random game (hola, __builtin) we want to integrate that utilizes C++.
17:40:31q3kthat would need a full blown c++ stdlib
17:40:58q3k(ie. either listdc++ or libcxx)
17:41:02speachyhah! I'm picturing a scummvm port to rockbox now.
17:41:22speachythat would be _really_ cool..
17:42:24speachythough even with sufficient-resolution screens it's going to be nigh-impossible to actually read any text or pixel-hunt objects..
17:43:55speachyafter I get the native mips 8.5 building cleanly (and hopefully generating a working jz4760/X3 binary) I'll see if I can get C++ turned on for the m68k toolchain. worst case I curl up in a ball in the corner while rocking and sucking my thumb.
17:44:46 Quit advcomp2019 (Ping timeout: 260 seconds)
17:45:01speachyanyway, time to go afk for a while again.
17:50:00CH23__builtin I missed your explanation, thank you! I'll give it a try.
17:50:54 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
17:50:56 Join advcomp2019_ [0] (~advcomp20@user/advcomp2019)
17:59:57rb-bluebotBuild Server message: Build round completed after 1394 seconds.
17:59:59rb-bluebotBuild Server message: Revision 4f9e4ddb99 result: All green
18:00:05 Join advcomp2019__ [0] (~advcomp20@user/advcomp2019)
18:01:18rb-bluebotBuild Server message: New build round started. Revision eaccdeeae2, 303 builds, 7 clients.
18:02:52 Quit advcomp2019 (Ping timeout: 265 seconds)
18:03:21 Quit advcomp2019_ (Ping timeout: 265 seconds)
18:03:45 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
18:05:36 Quit advcomp2019__ (Ping timeout: 268 seconds)
18:14:57 Quit advcomp2019 (Ping timeout: 265 seconds)
18:24:37rb-bluebotBuild Server message: Build round completed after 1399 seconds.
18:24:38rb-bluebotBuild Server message: Revision eaccdeeae2 result: All green
18:27:25rb-bluebotBuild Server message: New build round started. Revision f8e968991d, 303 builds, 7 clients.
18:33:36CH23so i just replaced "if (beep)" with "if (!beep)" on line 92 of piezo-6g.c, and removed lines 94 and 95. it seems the piezo still clicks as it should. what purpose do those extra lines serve? see:
18:36:45CH23it seems that's for the 'back' and 'forward' buttons or so.
18:38:12amachronicapparently nothing is using the beep=true case
18:39:04amachronicor force=true for that matter
18:49:51rb-bluebotBuild Server message: Build round completed after 1347 seconds.
18:49:53rb-bluebotBuild Server message: Revision f8e968991d result: All green
18:55:08***Saving seen data "./dancer.seen"
18:55:11 Join massiveH [0] (~massiveH@2600:4040:a993:4900:49a7:a7ac:d768:4f9d)
18:59:31 Quit amachronic (Quit: amachronic)
19:47:59 Join advcomp2019 [0] (~advcomp20@user/advcomp2019)
19:48:06 Join advcomp2019_ [0] (~advcomp20@user/advcomp2019)
20:24:42CH23for anyone who's also modding their iPod to have a taptic engine, with the iPhone 7 plus taptic engine, I get a fairly silent but heavy vibration by setting the following: in case the imgur link expires: "if (!beeping) { if (!beep) piezo_start(1000,1); } }"
20:31:44CH23__builtin the one thing I don't get, you said the 'cycles' parameter is in 1/100th kHz, so 1000 should be 10kHz, yet it appears to be much much lower than say 50
20:45:59CH23oh i see. i had headphone keyclick off.
20:46:09CH23on headphones it sounds about right
20:55:12***Saving seen data "./dancer.seen"
21:02:51 Quit tomato (Quit: The Lounge -
21:24:06 Quit CH23 (Ping timeout: 260 seconds)
21:37:15 Join tomato [0] (~tomato@user/tomato)
21:58:31 Quit hactar|ant (Quit: and it's always been the same / it's just a complicated game)
22:09:02 Join hactar|ant [0] (
22:44:24 Quit massiveH (Read error: Connection reset by peer)
22:46:49 Join massiveH [0] (~massiveH@2600:4040:a993:4900:49a7:a7ac:d768:4f9d)
22:55:14***Saving seen data "./dancer.seen"
22:55:37 Quit massiveH (Quit: Leaving)

Previous day | Next day