--- Log for 04.02.121 Server: verne.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 24 days and 13 hours ago 00.37.59 Quit koniu (Remote host closed the connection) 00.38.24 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 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.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.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.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.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.20.04 Join FroggestSpirit [0] (18c0819f@24.192.129.159) 06.20.46 # speachy, 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.16 # for 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.48 # the 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.48 # a 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.22 # the input code & keymaps was functionally unchanged though there were general improvements taken from the other hosted targets. 06.48.03 # sound 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.19.42 Quit livvy (Remote host closed the connection) 07.20.02 Join livvy [0] (~livvy@gateway/tor-sasl/livvy) 07.27.45 # <_bilgus> I think I might look into adding some functionality to force save/rename on configuration instead of overwrite 07.28.56 # <_bilgus> not sure if thats clear or not lol 07.29.09 # no, not particularly! 07.29.42 # <_bilgus> basically for flash drives and flash with poor wear leaveling 07.30.17 # <_bilgus> start saving the files and do a delete of the old then rename 07.30.44 # <_bilgus> rather than overwrite 07.35.13 # don't know if that's any better for flash wear, but it's certianly _safer_ 07.50.09 *** Saving seen data "./dancer.seen" 08.17.44 # on 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.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.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.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.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.02.58 Join bibaheu [0] (~ismael@dbddwhys4dm0h1gdylvft-3.rev.dnainternet.fi) 13.10.28 # Hi, 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.50 # is it at least somewhat possible, or there's a clear reason for it to not work at all? 13.13.51 # usb 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.20 # there's an old patch series in gerrit to implement it; that would be a good starting point. 13.14.50 # https://gerrit.rockbox.org/r/c/rockbox/+/1009 13.15.22 # "only the fuze+ was tested" 13.15.53 # cool, I'll take a look 13.16.28 # I'm a total noob in rockbox dev, so first I'll go over the dev guide 13.16.36 # it'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.40 # speachy: 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.04 # simplest option is to just activate one role or profile at any given time 13.52.16 # it will be nice to have that problem 13.52.37 # we're already part way there with the option to choose charging only or enable UMS as well 13.52.38 # but yes, we'll have to limit ourselves to one or two profiles at any point in time. 13.53.34 # right now we only got 2 real drivers 13.57.03 # next would be to emulate a secure card reader or something like that haha 14.42.30 Quit vitt13 (Quit: Leaving) 14.53.52 Quit bibaheu (Ping timeout: 258 seconds) 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.52 # o.O 15.48.59 # rockbox already has UMS emulation 15.50.18 *** Saving seen data "./dancer.seen" 15.52.07 # what 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.37 # speachy the installation on the HifiWalker worked like a charm. 15.52.42 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 15.52.44 # excellent. 15.54.07 # "commence the botnet takeover." 15.54.09 # I find the screen quality inferior to the xduoo x3ii. Do you use a particular theme for readability on the H2? 15.54.10 # =p 15.54.33 # nothing in particular; I've barely used it beyond development & debug 15.58.43 # the x3ii's screen is larger but I find the overall form factor (and controls) of the H2 much nicer. 16.01.13 # I 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.20 # the 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.51 # (well, I suppose there are more on-screen elements owing to the larger number of "rows" for lists etc.. 16.04.05 # I think the basic problem with the screen lag is the blocking nature of the display updates. 16.04.36 # (should really happen in a separate thread. audio output too..) 16.12.45 # I was referring to the x3ii regarding the lag. 16.13.29 # yeah. lag is particularly noticable on the x3ii 16.13.53 # but it afflicts all of the hosted linux targets to some extent 16.16.23 Quit johnb7 (Quit: Nettalk6 - www.ntalk.de) 16.16.58 # it might help if we had full control over the linux parts 16.17.00 # but alas 16.17.10 # then again linux isn't usually optimized for latency 16.18.51 # this 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.11 # speachy: non-blocking APIs aren't an option 16.28.14 # ? 16.28.36 # ideally we'd have input, audio output, and display updates on independent threads. 16.28.54 # most system calls i've used allow you to use non-blocking variants of them in some manner 16.29.25 # braewoods: 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.29 # that latter is what's blocking. 16.29.50 Join tomato6 [0] (t0mato@gateway/vpn/mullvad/tomato) 16.29.53 # i see. 16.30.54 # i'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.10 # let the caller decide what it wants to happen 16.31.26 # mostly if there's a significant delay 16.31.30 # potential 16.31.41 # otherwise 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.49 # if i expect delays to be short lived 16.34.16 # some of the other hosted targets spawn their own threads for specific tasks already. 16.35.24 # but 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.37 # couldn't you implement that as an abstraction from the current threading code? 16.46.02 Quit vitt13 (Ping timeout: 256 seconds) 16.47.22 # yeah, that's the intent. 16.47.41 # ...map our internal threading API/behaviorisms to phread API calls. 16.48.08 # (that includes synchronization primitives too) 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.17 # speachy 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.33 # what 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.09 # with how we do our threading, I don't think ondemand works terribly well. 17.48.14 # since we never actually _idle_ 17.48.39 # but at the same time it's not clear that the x1000 kernel even implements cpufreq stuff. 17.48.57 # I 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.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.35 # The 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.07 # FroggestSpirit: I don't mean "enabled in the kernel", I mean "they probably didn't implement runtime frequency switching for the x1000" 18.50.26 # (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.55 # ahh, I gotcha. I'll turn that off then 18.51.25 # I think if it worked, ingenic/fiio would have enabled it, as it's "free" power savings. 18.52.34 # (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.33 # on 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.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.11 # FroggestSpirit: 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.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.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.05.32 Join f1reflyylmao [0] (~f1refly@2a01:c22:8822:c600:3470:4e7:9528:e9dc) 22.08.34 Quit f1refly (Ping timeout: 258 seconds) 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)