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).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2021-02-04

00:37:59 Quit koniu (Remote host closed the connection)
00:38:24 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
01:00
01:20:28 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
01:50:00***Saving seen data "./dancer.seen"
02:00
02:50:25 Quit Natch (Remote host closed the connection)
02:56:01 Join Natch [0] (~natch@c-b471e255.014-297-73746f25.bbcust.telenor.se)
03:00
03:17:15 Nick f1reflyylmao is now known as f1refly (~f1refly@dynamic-077-008-096-160.77.8.pool.telefonica.de)
03:50:03***Saving seen data "./dancer.seen"
04:00
04:28:04 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
04:40:08 Quit pamaury (Ping timeout: 256 seconds)
04:47:21 Join petur [0] (~petur@rockbox/developer/petur)
04:56:00 Quit petur (Ping timeout: 256 seconds)
05:00
05:43:00 Quit usvi (Remote host closed the connection)
05:48:54 Join pamaury [0] (~pamaury@maths.r-prg.net.univ-paris7.fr)
05:48:54 Quit pamaury (Changing host)
05:48:54 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
05:50:07***Saving seen data "./dancer.seen"
06:00
06:20:04 Join FroggestSpirit [0] (18c0819f@24.192.129.159)
06:20:46FroggestSpiritspeachy, do you still have the xvortex rockbox source? i wanted to poke around it for a couple of things
06:24:21 Quit FroggestSpirit (Client Quit)
06:25:33 Join FroggestSpirit [0] (18c0819f@d192-24-159-129.try.wideopenwest.com)
06:26:25 Quit FroggestSpirit (Client Quit)
06:39:16speachyfor the m3k you mean? I should still have a copy somewhere. it wasn't complete, and took quite a bit of surgery to port to the development head.
06:40:48speachythe primary functional difference that I didn't carry over was the (very hacky) split-root stuff; where .rockbox vs the music/etc stuff lived under different parts of the filesystem.
06:43:48speachya good argument could be made about putting that functionality back in for hosted targets, but as a general rule we've learned that wearing out the onboard flash _will_ happen and eventually brick your device under "normal" usage.
06:47:22speachythe input code & keymaps was functionally unchanged though there were general improvements taken from the other hosted targets.
06:48:03speachysound code saw a lot of changes, due to a combination of nasty bugs and a partial rewrite of the alsa driver I did a while back
06:52:26 Join Huntereb [0] (~Huntereb@174.226.1.140)
07:00
07:19:42 Quit livvy (Remote host closed the connection)
07:20:02 Join livvy [0] (~livvy@gateway/tor-sasl/livvy)
07:27:45_bilgusI think I might look into adding some functionality to force save/rename on configuration instead of overwrite
07:28:56_bilgusnot sure if thats clear or not lol
07:29:09speachyno, not particularly!
07:29:42_bilgusbasically for flash drives and flash with poor wear leaveling
07:30:17_bilgusstart saving the files and do a delete of the old then rename
07:30:44_bilgusrather than overwrite
07:35:13speachydon't know if that's any better for flash wear, but it's certianly _safer_
07:50:09***Saving seen data "./dancer.seen"
08:00
08:17:44speachyon the other hand, it's not like we're using flash-aware filesystems.
08:31:34 Join MrZeus [0] (~MrZeus@194.37.96.103)
08:33:36 Quit mendelmunkis (Ping timeout: 258 seconds)
09:00
09:01:18 Join MrZeus_ [0] (~MrZeus@194.37.96.103)
09:05:01 Quit MrZeus (Ping timeout: 276 seconds)
09:12:44 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
09:49:09 Quit jschwart (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)
09:50:12***Saving seen data "./dancer.seen"
10:00
10:00:08 Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato)
10:00:37 Join jschwart [0] (~quassel@2001:985:2c6e:0:b00b:32ff:fe28:5567)
10:28:42 Quit paulk-leonov (Ping timeout: 272 seconds)
10:29:23 Join paulk-leonov [0] (~paulk-leo@vpn-0-22.aquilenet.fr)
10:38:35 Quit pamaury (Quit: Konversation terminated!)
10:40:42 Quit massiveH (Quit: Leaving)
10:50:25 Quit bluebrother (Ping timeout: 240 seconds)
10:53:05 Quit akaWolf (Ping timeout: 240 seconds)
10:53:59 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
11:00
11:22:08 Join vitt13 [0] (~vitt13@46.158.211.0)
11:23:03 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
11:35:09 Quit k1w1 (Quit: k1w1)
11:36:02 Join k1w1 [0] (~k1w1@unaffiliated/k1w1)
11:39:04 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf)
11:50:14***Saving seen data "./dancer.seen"
12:00
12:01:27 Join mendelmunkis [0] (~mendelmun@ool-43568247.dyn.optonline.net)
12:17:56 Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
12:24:28 Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be)
12:26:12 Quit J_Darnley (Ping timeout: 246 seconds)
12:30:54 Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be)
12:31:43 Quit jdarnley (Ping timeout: 276 seconds)
12:44:51 Quit bluebrother (Ping timeout: 272 seconds)
12:55:08 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
13:00
13:02:58 Join bibaheu [0] (~ismael@dbddwhys4dm0h1gdylvft-3.rev.dnainternet.fi)
13:10:28bibaheuHi, I had an idea of porting the qemu usb audio "hardware" to rockbox, so my sansa can work as an USB sound card
13:10:50bibaheuis it at least somewhat possible, or there's a clear reason for it to not work at all?
13:13:51speachyusb audio requires a controller that can handle isochronous transfers, but assuming the specific sansa model you're thinking of supports that, then there's no inherent reason why it's not possible.
13:14:20speachythere's an old patch series in gerrit to implement it; that would be a good starting point.
13:14:50speachyhttps://gerrit.rockbox.org/r/c/rockbox/+/1009
13:15:22speachy"only the fuze+ was tested"
13:15:53bibaheucool, I'll take a look
13:16:28bibaheuI'm a total noob in rockbox dev, so first I'll go over the dev guide
13:16:36speachyit's a feature that would be quite good to have in general, but it is a pretty substantial undertaking.
13:45:01 Quit Huntereb (Ping timeout: 272 seconds)
13:50:17***Saving seen data "./dancer.seen"
13:51:40braewoodsspeachy: if rockbox acquires more USB roles we will need to regulate which can be active because of limited hardware endpoints...
13:51:46 Quit J_Darnley (Ping timeout: 258 seconds)
13:52:01 Join jdarnley [0] (~J_Darnley@d51a44418.access.telenet.be)
13:52:04braewoodssimplest option is to just activate one role or profile at any given time
13:52:16speachyit will be nice to have that problem
13:52:37braewoodswe're already part way there with the option to choose charging only or enable UMS as well
13:52:38speachybut yes, we'll have to limit ourselves to one or two profiles at any point in time.
13:53:34braewoodsright now we only got 2 real drivers
13:57:03bibaheunext would be to emulate a secure card reader or something like that haha
14:00
14:42:30 Quit vitt13 (Quit: Leaving)
14:53:52 Quit bibaheu (Ping timeout: 258 seconds)
15:00
15:03:06 Join johnb7 [0] (~johnb2@p5b3af896.dip0.t-ipconnect.de)
15:32:15 Join vitt13 [0] (~vitt13@46.158.211.0)
15:41:49 Join bonfire [0] (~bonfire@c-24-2-109-9.hsd1.ut.comcast.net)
15:48:52braewoodso.O
15:48:59braewoodsrockbox already has UMS emulation
15:50:18***Saving seen data "./dancer.seen"
15:52:07vitt13what about m3k ak4376 kernel driver? since custom kernel in developing can we use new driver like v2.0 (but for kernel 4.9) https://github.com/realme-kernel-opensource/realme6Pro-kernel-source/blob/master/audio-kernel/asoc/codecs/ak4376/ak4376.c ? at least v1.1 is published https://github.com/vijaymalav564/lockdown_kernel_realme2pro/blob/hmp/sound/soc/codecs/ak4376.c for kernel 3.18.20
15:52:37johnb7speachy the installation on the HifiWalker worked like a charm.
15:52:42 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
15:52:44speachyexcellent.
15:54:07braewoods"commence the botnet takeover."
15:54:09johnb7I find the screen quality inferior to the xduoo x3ii. Do you use a particular theme for readability on the H2?
15:54:10braewoods=p
15:54:33speachynothing in particular; I've barely used it beyond development & debug
15:58:43speachythe x3ii's screen is larger but I find the overall form factor (and controls) of the H2 much nicer.
16:00
16:01:13johnb7I use the xduoo only at home and I am fine with form factor, the only drawback is the relative lag of the UI.
16:02:20speachythe lag seemed worse for me on the x3ii than the h2, but given the screens ahve the same number of overall pixels, it shouldn't really matter.
16:02:51speachy(well, I suppose there are more on-screen elements owing to the larger number of "rows" for lists etc..
16:04:05speachyI think the basic problem with the screen lag is the blocking nature of the display updates.
16:04:36speachy(should really happen in a separate thread. audio output too..)
16:12:45johnb7I was referring to the x3ii regarding the lag.
16:13:29speachyyeah. lag is particularly noticable on the x3ii
16:13:53speachybut it afflicts all of the hosted linux targets to some extent
16:16:23 Quit johnb7 (Quit: Nettalk6 - www.ntalk.de)
16:16:58braewoodsit might help if we had full control over the linux parts
16:17:00braewoodsbut alas
16:17:10braewoodsthen again linux isn't usually optimized for latency
16:18:51speachythis is more due to how we did threading −− we basically emulate threads instead of using the native OS stuff, so a blocked syscall on one blocks everything.
16:28:11braewoodsspeachy: non-blocking APIs aren't an option
16:28:14braewoods?
16:28:36speachyideally we'd have input, audio output, and display updates on independent threads.
16:28:54braewoodsmost system calls i've used allow you to use non-blocking variants of them in some manner
16:29:25speachybraewoods: speaking of the display updates in particular, we do the updates via mmap'd buffers, but trigger an ioctl when we want the kernel to do the repaint
16:29:29speachythat latter is what's blocking.
16:29:50 Join tomato6 [0] (t0mato@gateway/vpn/mullvad/tomato)
16:29:53braewoodsi see.
16:30:54braewoodsi've started designing library APIs and i will include blocking / non-blocking in some cases if i expect it could be a contention point
16:31:10braewoodslet the caller decide what it wants to happen
16:31:26braewoodsmostly if there's a significant delay
16:31:30braewoodspotential
16:31:41braewoodsotherwise i tend to just use blocking APIs
16:31:45 Quit tomato (Ping timeout: 240 seconds)
16:31:45 Nick tomato6 is now known as tomato (t0mato@gateway/vpn/mullvad/tomato)
16:31:49braewoodsif i expect delays to be short lived
16:34:16speachysome of the other hosted targets spawn their own threads for specific tasks already.
16:35:24speachybut rather than continuing to do that piecemeal I've been dusting off the "native pthread threading" code that's actually in-tree, albeit highly incomplete.
16:45:37braewoodscouldn't you implement that as an abstraction from the current threading code?
16:46:02 Quit vitt13 (Ping timeout: 256 seconds)
16:47:22speachyyeah, that's the intent.
16:47:41speachy...map our internal threading API/behaviorisms to phread API calls.
16:48:08speachy(that includes synchronization primitives too)
17:00
17:00:09 Quit lebellium (Quit: Leaving)
17:18:43 Quit livvy (Ping timeout: 268 seconds)
17:18:49 Join livvy_ [0] (~livvy@gateway/tor-sasl/livvy)
17:24:06 Join FroggestSpirit [0] (18c0819f@d192-24-159-129.try.wideopenwest.com)
17:25:17FroggestSpiritspeachy I was mainly asking about the partition thing, although that makes sense about wear on the flash
17:25:29 Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be)
17:25:31 Quit jdarnley (Ping timeout: 276 seconds)
17:39:33FroggestSpiritwhat kind of CPU govenor is recommended? I was trying ondemand
17:40:23 Join tomato6 [0] (t0mato@gateway/vpn/mullvad/tomato)
17:43:04 Quit tomato (Ping timeout: 276 seconds)
17:43:05 Nick tomato6 is now known as tomato (t0mato@gateway/vpn/mullvad/tomato)
17:48:09speachywith how we do our threading, I don't think ondemand works terribly well.
17:48:14speachysince we never actually _idle_
17:48:39speachybut at the same time it's not clear that the x1000 kernel even implements cpufreq stuff.
17:48:57FroggestSpiritI added it in the custom kernel
17:50:19***Saving seen data "./dancer.seen"
17:56:34 Join tomato8 [0] (t0mato@gateway/vpn/mullvad/tomato)
17:57:46 Quit tomato (Disconnected by services)
17:57:47 Nick tomato8 is now known as tomato (t0mato@gateway/vpn/mullvad/tomato)
18:00
18:24:41 Join tomato2 [0] (t0mato@gateway/vpn/mullvad/tomato)
18:26:25 Quit tomato (Ping timeout: 240 seconds)
18:26:25 Nick tomato2 is now known as tomato (t0mato@gateway/vpn/mullvad/tomato)
18:30:35FroggestSpiritThe button stuff is going good, I'm just trying to figure out the best way to handle the center scroll/click, so it doesn't accidently click when meaning to scroll. It's already set to do that, but I want to add longpress for that
18:34:28 Quit toruvinn (Ping timeout: 272 seconds)
18:35:28 Join toruvinn [0] (~toruvinn@87-205-128-186.adsl.inetia.pl)
18:48:07speachyFroggestSpirit: I don't mean "enabled in the kernel", I mean "they probably didn't implement runtime frequency switching for the x1000"
18:50:26speachy(and even if implemented, the abiltiy to switch without audio glitches is another matter. the x1000's predecessors couldn't manage this FWIW, and even when switching, the power saving turned out to be negligable.
18:50:55FroggestSpiritahh, I gotcha. I'll turn that off then
18:51:25speachyI think if it worked, ingenic/fiio would have enabled it, as it's "free" power savings.
18:52:34speachy(the codec, power supplies, clocks/plls, system busses, ram, etc all need to be constantly going; it turns out the actual CPU core is relatively minor...)
18:54:33FroggestSpiriton the rockbox side, how does BUTTON_REPEAT work? is it triggered when the button is held a certain period of time?
18:57:49 Quit pamaury (Ping timeout: 276 seconds)
19:00
19:05:59 Quit koniu (Remote host closed the connection)
19:06:23 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
19:14:56 Join livvy [0] (~livvy@gateway/tor-sasl/livvy)
19:15:31 Quit livvy_ (Remote host closed the connection)
19:31:11speachyFroggestSpirit: yes.
19:41:30 Quit bluebrother (Disconnected by services)
19:41:35 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother)
19:50:20***Saving seen data "./dancer.seen"
20:00
20:12:02 Quit MrZeus_ (Ping timeout: 258 seconds)
20:23:32 Quit FroggestSpirit (Quit: Connection closed)
20:33:03 Quit Barlow (Ping timeout: 246 seconds)
20:38:20 Join Barlow [0] (~barlow@unaffiliated/barlow)
21:00
21:09:05 Quit Barlow (Ping timeout: 240 seconds)
21:13:58 Quit bonfire (Read error: Connection reset by peer)
21:16:15 Join Barlow [0] (~barlow@17-215-201-31.ftth.glasoperator.nl)
21:16:15 Quit Barlow (Changing host)
21:16:15 Join Barlow [0] (~barlow@unaffiliated/barlow)
21:50:23***Saving seen data "./dancer.seen"
22:00
22:05:32 Join f1reflyylmao [0] (~f1refly@2a01:c22:8822:c600:3470:4e7:9528:e9dc)
22:08:34 Quit f1refly (Ping timeout: 258 seconds)
23:00
23:02:14 Quit ac_laptop (Ping timeout: 258 seconds)
23:22:57 Quit MonTaGaTnoM (Read error: Connection reset by peer)
23:23:22 Join MonTaGaTnoM [0] (~shawn156@unaffiliated/shawn156)
23:50:24***Saving seen data "./dancer.seen"
23:58:30 Quit emacsomancer (Ping timeout: 246 seconds)

Previous day | Next day