--- Log for 26.11.113 Server: sendak.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 19 days and 18 hours ago 00.01.53 # indeed 00.02.38 # Build Server message: 3Build round completed after 483 seconds. 00.02.54 # ah, you put empty registers 00.03.29 # the parser is pretty stupid and if you don't put any field in it, it will not be treated as a register with no instanciation 00.04.06 # actually this: 00.04.06 # 00.04.06 # is invalid: the addr="0x00" part will be ignored 00.04.22 # why? 00.04.48 # because it's not in the spec 00.05.38 # but why? missing or something else? 00.05.44 # there is a different between a register and instanciation of that register: basically defines a register "kind" and defines an instance of this kind at a particular address 00.06.08 # so the correct way is: 00.06.08 # 00.06.17 # I see 00.06.44 # and qeditor only display instanciation of the registers 00.06.53 # so if there no , it doesn't show anything 00.07.10 # yeah the format was not really conceived for a human to write ^^ 00.07.18 # blah, a lot of typing then 00.07.48 # maybe we could add support for such "shortcut" we are commonplace 00.07.57 # *when they are 00.08.13 Quit Zagor (Quit: Clint excited) 00.08.18 # that should be easy 00.09.35 # That would save me a lot of typing 00.10.11 # ok, I'll give it a try, wait for 5 min 00.18.08 Join Tukeke [0] (~Tukeke@unaffiliated/hlvsv) 00.23.00 # wodz: pushing to gerrit... 00.23.45 # g#679 00.23.48 # 3Gerrit review #679 at http://gerrit.rockbox.org/r/679 : 3regtools: add shortcut notation for simple register in the desc files by Amaury Pouly (changes/79/679/1) 00.27.44 # pamaury: works as expected 00.29.17 # sleep() 00.29.22 Quit wodz (Quit: Leaving) 00.29.49 # Build Server message: 3New build round started. Revision f04d3c5, 243 builds, 34 clients. 00.33.50 # <[Saint]> JdGordon: http://forums.rockbox.org/index.php/topic,43661.msg221576.html#msg221576 ...really? 00.34.03 # <[Saint]> Core functionality fails, and your answer is to edit the .wps? 00.35.13 # <[Saint]> JdGordon: perhaps you parsed OP's statement incorrectly? To be clear, OP is saying that "clear backdrop" fails, which has been reported by a few people, the answer to this is *not* to edit the .wps :) 00.36.37 # Build Server message: 3Build round completed after 409 seconds. 00.38.18 Join Cultist_ [0] (~CultOfThe@c-24-12-53-28.hsd1.il.comcast.net) 00.38.21 Quit Cultist (Read error: Connection reset by peer) 00.40.28 # [Saint]: clear backdrop is for the colour 00.40.38 # its got nothing to do with the backdrop image in the wps 00.41.18 # <[Saint]> ...errrr...no? 00.41.46 # <[Saint]> It clears the backdrop. 00.41.48 Nick Cultist_ is now known as Cultist (~CultOfThe@c-24-12-53-28.hsd1.il.comcast.net) 00.42.07 # no it doesnt? 00.42.16 # <[Saint]> As far as I am aware it has always behaved in this fashion. 00.42.28 # <[Saint]> I just tested it, and it certainly does clear the backdrop. 00.42.58 # It won't clear a wps-specified backdrop 00.43.06 # <[Saint]> It just did. 00.43.40 # <[Saint]> I just loaded up cabbiev2, selected clear backdrop from the theme settings - bam, no backdrop. 00.43.59 # <[Saint]> As far as I was aware this was intended functionality. 00.44.06 # in the menus or wps? 00.44.21 # <[Saint]> both. 00.44.28 # Also, I seem to remember that the cabbie backdrop is *not* wps-specified 00.45.14 # <[Saint]> It is. 00.45.26 # ah, no, i was mistaken 00.45.35 # it clears the backdrop image specified in the .cfg 00.48.13 # <[Saint]> FWIW, this has been reported before - but I have never been able to reproduce it reliably. 00.48.29 # <[Saint]> I don't think it has been reported in an official capacity, I'll have a look. 00.49.24 # <[Saint]> Oh - can someone do me a favor and close out http://www.rockbox.org/tracker/task/12903?project=1&type=2&order=dateopened&sort=desc as "not a bug"? Thanks. 00.50.45 # <[Saint]> AH, that reminds me, there is also another issue with backdrops that I believe has been reported officially. 00.51.06 # <[Saint]> Sometimes when applying a theme the backdrop won't take until the device is rebooted. 00.51.18 # * [Saint] looks 00.51.50 # <[Saint]> Ah, yes, copper reported this a while ago: 00.51.51 # <[Saint]> http://www.rockbox.org/tracker/task/12892 00.52.21 # hmmm 00.52.35 # the backgrounds do some fancy complex stuff so yeah, there might be a bug :p 00.53.28 # <[Saint]> I had a look the other day but I got distracted. 00.54.15 Quit Tukeke (Quit: Tukeke) 00.54.21 # <[Saint]> I was checking to see why buflib thinks there's a bitmap background loaded when the background is only being drawn by the background viewport color. 00.54.54 # <[Saint]> I'm fairly sure that is a bug as well, but I get lost in the theme engine so easily. 00.55.36 Quit lonoxmont (Ping timeout: 272 seconds) 00.56.27 # <[Saint]> Even using the fallback theme, which most certainly doesn't have a bitmap backdrop, you can see the allocation in the buflib allocation debug screen. 00.56.52 Join lonoxmont [0] (~lonoxmont@71-95-40-15.dhcp.rvsd.ca.charter.com) 00.57.32 # <[Saint]> Hmmmm. Clearing the backdrop doesn't purge the buflib allocation. 00.58.02 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131118212339]) 00.58.07 # <[Saint]> I guess dynamically unloading objects is a bit too much to ask. 00.58.08 Quit bertrik (Remote host closed the connection) 01.11.10 Quit pamaury (Ping timeout: 246 seconds) 01.31.35 Join foolsh [0] (~foolsh@c-24-14-134-34.hsd1.in.comcast.net) 01.37.19 # [Saint]: once i et my internet at home working I'll investigate (If im reminded :p ) 01.37.31 Join treaki_ [0] (~treaki@p4FF4A216.dip0.t-ipconnect.de) 01.37.40 # its quite likely its broken when i added the background layer thing which requires a backdrop image buffer 01.39.25 # <[Saint]> ahhhh, right. 01.39.53 Quit treaki__ (Ping timeout: 252 seconds) 01.40.00 # <[Saint]> I just noticed it when I was trying to make a config that allocates as little to RAM as possible. 01.40.25 *** Saving seen data "./dancer.seen" 01.40.29 # * JdGordon will also be more motivated once his 5.5g is working again 01.40.39 # <[Saint]> And a 320x240 bitmap isn't /huge/ I know, but every little bit counts. 01.40.51 # <[Saint]> WHat's up with your Video? 01.41.17 # <[Saint]> WHat do you need to get it working again? I may have asked this before but I can't remember - I may have some spares for you. 01.42.54 # <[Saint]> BBIAB 01.43.27 Quit [Saint] (Remote host closed the connection) 01.44.34 Join [Saint] [0] (~saint@rockbox/user/saint) 01.55.40 Quit Cultist (Read error: Connection reset by peer) 01.55.59 Join Cultist [0] (~CultOfThe@c-24-12-53-28.hsd1.il.comcast.net) 02.26.09 # Can anyone tell why it is that a new target needs file view plug-ins to be ported, as opposed to just recompiled? 02.31.33 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 02.41.46 Quit onder` (Ping timeout: 245 seconds) 02.42.52 Join onder` [0] (~onder@dyn-dsl-to-76-75-119-170.nexicom.net) 02.45.37 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 02.47.57 Quit ikeboy (Remote host closed the connection) 03.12.00 # chrisjj_: Most rockbox plugins need *very* specific changes added to them in order to support new targets, they will not compile without errors until those specific changes are added 03.22.06 # foolsh: Sure, but is that really true for mere file view plug-ins? Can't they just write to a generic virtual screen buffer? 03.29.30 # And how would the user interact with that plugin? What about hardware limitations that are present on some targets and not others. It's those kinds changes that are specific to the individual targets. Rockbox is very hardware specific with it's code, generic workings are extremely hard to implement without *a lot* of overhead code to support them. 03.40.28 *** Saving seen data "./dancer.seen" 03.45.03 Quit krabador (Quit: Sto andando via) 03.54.11 Quit froggymana (Quit: ZNC - http://znc.in) 04.16.43 Quit Cultist (Read error: Connection reset by peer) 04.17.08 Join Cultist [0] (~CultOfThe@c-24-12-53-28.hsd1.il.comcast.net) 04.28.01 Quit amiconn (Disconnected by services) 04.28.01 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.28.01 Quit pixelma (Disconnected by services) 04.28.02 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.28.05 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.28.05 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.53.54 Join onder`_ [0] (~onder@dyn-dsl-to-76-75-119-170.nexicom.net) 04.55.04 Quit onder` (Ping timeout: 246 seconds) 04.55.11 Nick onder`_ is now known as onder` (~onder@dyn-dsl-to-76-75-119-170.nexicom.net) 05.02.16 Quit TheSeven (Disconnected by services) 05.02.29 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 05.05.47 # foolsh: OK, I had thought that the I/O for a file viewer was simple enough to be generalised, esp. since there are no real-time requirements to challenge the code overhead. I guess not. Thanks. 05.26.13 Quit foolsh (Ping timeout: 246 seconds) 05.31.19 Quit [Saint] (Remote host closed the connection) 05.32.27 Join [Saint] [0] (~saint@rockbox/user/saint) 05.39.24 Quit [Saint] (Remote host closed the connection) 05.40.28 Join [Saint] [0] (~saint@rockbox/user/saint) 05.40.32 *** Saving seen data "./dancer.seen" 06.15.57 Quit cmhobbs (Remote host closed the connection) 06.32.59 Nick SuperBrainAK is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) 06.50.59 Join foolsh [0] (~foolsh@c-24-14-134-34.hsd1.in.comcast.net) 07.02.58 Join mortalis [0] (~kvirc@213.33.220.118) 07.38.02 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 07.40.34 *** Saving seen data "./dancer.seen" 08.21.02 Join ender` [0] (krneki@foo.eternallybored.org) 08.22.13 Quit krnlyng (Ping timeout: 240 seconds) 08.22.43 Join krnlyng [0] (~liar@83.175.90.24) 08.27.13 Quit krnlyng (Ping timeout: 240 seconds) 08.32.01 Join kugel [0] (~kugel@193.174.67.16) 08.32.01 Quit kugel (Changing host) 08.32.01 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.36.56 Join LinusN [0] (linus@giant.haxx.se) 08.52.10 Part LinusN 08.57.29 Join Zagor [0] (~bjst@sestofw01.enea.se) 08.57.29 Quit Zagor (Changing host) 08.57.29 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 09.06.03 Join LinusN [0] (linus@giant.haxx.se) 09.06.25 Quit kevku (Ping timeout: 245 seconds) 09.06.26 Quit TBCOOL (Ping timeout: 272 seconds) 09.26.06 Part LinusN 09.33.26 Join petur [0] (5bb7304d@rockbox/developer/petur) 09.40.38 *** Saving seen data "./dancer.seen" 09.54.15 Quit kugel (Ping timeout: 240 seconds) 09.54.37 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 09.56.23 # chrisjj_: You are missing the point probably. What is missing to make plugins work on new target is keymap. Each target has different number of keys, different physical location of keys and different combos allowed. You need to go through and define keymaps. Thats lots of work (and rather boring one) 09.59.11 Join kevku [0] (~kevku@2a01:d0:ffff:34a::8:3) 10.11.25 Quit [Saint] (Remote host closed the connection) 10.12.36 Join [Saint] [0] (~saint@rockbox/user/saint) 10.18.04 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.24.37 Join krnlyng [0] (~liar@83.175.90.24) 10.26.57 Join W0rmDr1nk [0] (~wormdrink@unaffiliated/wormdrink) 10.45.57 Join TBCOOL [0] (~tb@c-ec94e555.09-273-73746f44.cust.bredbandsbolaget.se) 10.46.30 # Looking at onda's exception handler code for me it seems it does excessive context save. s0-s8 are guaranteed by convention to be preserved across the call to C function. 10.46.54 Join LinusN [0] (linus@giant.haxx.se) 10.50.23 Join lebellium [0] (~chatzilla@80.215.199.181) 10.51.12 # hmm, it also should not use sp to save context but I guess this is not important in rb 10.55.44 Quit [Saint] (Remote host closed the connection) 10.56.54 Quit pamaury (Ping timeout: 272 seconds) 10.56.59 Join [Saint] [0] (~saint@rockbox/user/saint) 11.12.21 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.13.10 # lebellium: with my fix, the nwe360 is doing much better: I'm already at 13 hours and still plenty of battery 11.15.12 # pamaury: which fix? 11.15.33 # don't leave sd card in TRAN mod 11.16.38 Join kugel [0] (~kugel@rockbox/developer/kugel) 11.21.47 Quit kugel (Ping timeout: 245 seconds) 11.24.33 Join markun [0] (~markun@rockbox/developer/markun) 11.25.15 # pamaury: sounds good :D 11.31.51 # what is TRAN mod? 11.32.38 # TRAN mode, that's one of the many possible states of the SD card. You must be in TRAN mode to be able to transfer any data 11.34.08 # pamaury: is it for internal eMMC? 11.34.39 # both eMMC and SD. But the effect seems much more important on SD 11.34.46 # unfortunately, the specification is quite vague about power management. In eMMC card you can explicitely put the card in to sleep (which we don't yet) but in SD cards you can't. Many will just automatically enter sleep but some don't apparently. 11.35.56 # Does nwe360 have sd slot? I recall sonys hesitant to put card slot in their players 11.36.13 # no 11.36.27 # wodz: internal SD 11.36.50 # No Sony mp3 player has a SD slot. Only a few very old models have a MS slot 11.37.50 Quit [Saint] (Remote host closed the connection) 11.38.58 Join [Saint] [0] (~saint@rockbox/user/saint) 11.40.42 *** Saving seen data "./dancer.seen" 11.59.04 Join efyx [0] (~efyx@163.137-67-87.adsl-dyn.isp.belgacom.be) 12.09.45 # I see that chrisjj has modified a lot of things in TargetStatus, could someone had a look, it seems like a pretty big edit 12.16.14 # * wodz looking 12.20.02 # It seems to be mostly reshufle of the stuff in the table. He sorted targets by name 12.20.07 # It *looks* like an attempt to alphabetize the tables, instead of using the sort 12.20.10 # yup 12.21.05 Quit efyx (Remote host closed the connection) 12.22.06 # I wonder why Toshiba Gigabeat is after Archoses :P 12.23.20 Join efyx [0] (~efyx@163.137-67-87.adsl-dyn.isp.belgacom.be) 12.27.12 # he just gathered models of the same brand together 12.27.20 # but no alphabetical order 12.27.23 # so it's a bit strange 12.28.25 # I suspect it's sorted on link 12.28.44 # I mean, the gigabeat wiki page is GigabeatFX, not ToshibaGigabeatFX 12.29.01 # indeed 12.29.03 # that was my impression too 12.30.03 # but if we display Philips and Toshiba and not only Gigabeat and GoGear, I would rather sort by full name 12.31.56 # lebellium: Its a wiki you know... 12.34.16 Quit advcomp2019 (Read error: Connection reset by peer) 12.34.43 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 12.37.32 # wodz: sure, but that doesn't keep from asking the others if they agree with you :) 12.44.37 Join einhirn [0] (~Miranda@p4FC77E10.dip0.t-ipconnect.de) 13.03.30 Join kugel [0] (~kugel@rockbox/developer/kugel) 13.05.32 Quit TBCOOL (Ping timeout: 246 seconds) 13.11.00 Quit kugel (Ping timeout: 246 seconds) 13.20.51 Quit amiconn (Ping timeout: 264 seconds) 13.21.27 Quit pixelma (Ping timeout: 264 seconds) 13.22.36 Join amiconn [0] (amiconn@rockbox/developer/amiconn) 13.23.08 Join pixelma [0] (pixelma@rockbox/staff/pixelma) 13.40.44 *** Saving seen data "./dancer.seen" 14.26.22 Join cmhobbs [0] (~cmhobbs@ip70-178-52-92.ks.ks.cox.net) 14.26.22 Quit cmhobbs (Changing host) 14.26.22 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 14.38.56 Join amayer [0] (~amayer@mail.weberadvertising.com) 14.41.55 Join TBCOOL [0] (~tb@c-ec94e555.09-273-73746f44.cust.bredbandsbolaget.se) 14.48.26 Quit cmhobbs (Ping timeout: 272 seconds) 14.55.04 Quit pamaury (Read error: Connection reset by peer) 14.58.47 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 15.04.12 Join Narod [0] (Narod@p5DDDB3D9.dip0.t-ipconnect.de) 15.11.42 Quit wodz (Quit: Leaving) 15.17.35 # lebellium: ever heard of the YP-CP3 ? 15.18.07 # pamaury: I reviewed it and own it of course : 15.18.09 # :) 15.18.39 # of course :) how is it ? 15.18.51 # here is my review 15.18.55 # http://labo.generationmp3.com/2009/10/30/test-et-video-du-samsung-cp3/ 15.19.02 # it's one of the worst mp3 players I have reviewed 15.19.32 # ah thanks, very thorough review as usual 15.19.58 # why is it that bad ? is it the shape or the software ? 15.20.34 Quit kevku (Ping timeout: 245 seconds) 15.21.09 # the software mainly. But maybe the hardware too since the Samsung R&D told me they could not get the video format ratio respected (can only play any video full screen) because the CPU is not powerful enough 15.21.18 # I don't know if that's true or if they were too lazy 15.21.36 # do you know the cpu ? I don't think you have the service manual for this one 15.22.24 # It's the only Samsung player with a Rockchip CPU :) RK2706B 15.23.20 # oh, really ?! I'm going to contact the vendor right away then, I found a cheap one on leboncoin 15.23.31 # Samsung decided that a player designed for the Chinese and Russian market doesn't deserve a good hardware and software. You know, developing countries only need bad products :) 15.23.56 # When I saw the interface I thought it looked familiar, now I know why ^^ 15.25.02 # unfortunately I have no recovery tool or service manual for this one 15.25.11 # I only have the firmwares 15.25.14 # lebellium: needs moar RMAA :) 15.26.12 # I'm not familiar with RMAA :) 15.26.35 # for a reviewer, that's basically a crime 15.30.44 # pamaury: funny fact: Since the R&D was not able/did not want to fix the screen ratio for videos, they released firmware 2.10 to fix only one minor thing I reported. A typo in some languages "insert mircoSD" instead of "insert microSD". It's the most useless firmware release I have experienced... 15.31.35 # That's a bit off-topic but I have many funny anecdotes about stupid sammy :) 15.32.33 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 15.40.46 *** Saving seen data "./dancer.seen" 15.43.49 # haha, most useless firmware release ever 15.45.01 # I don't know how much different from a generic RK27 it is 15.45.37 # but I assume the port would be quite easy 15.45.43 Join pretty_function [0] (~sigBART@123.252.213.221) 15.47.37 # and it could be used on SD since there is no NAND support yet 15.49.54 # yeah exactly 15.50.15 # my guess it's that they hardly modified the generic design 15.50.26 # but first I need to be able to buy this mp3 ^^ 15.51.50 # but the battery seems to be good quality 15.52.06 # I haven't turned it on for months 15.52.12 # and now the battery is still full 15.57.47 Part LinusN 15.58.02 # BTW, is your E360 still running? 15.59.47 # yeah 16.00.09 # 15 hour and battery voltage is still at ~3.8V, that's pretty good 16.00.47 # so that would fix the issue on both NWZ and Fuze+? 16.01.30 # probably yeah 16.03.33 Join einhirn_ [0] (Miranda@bsod.vpn.tu-clausthal.de) 16.06.14 Quit einhirn (Ping timeout: 272 seconds) 16.13.04 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 16.15.30 Quit mortalis (Ping timeout: 252 seconds) 16.19.19 # pamaury: your no TRAN mode changes, are they on Gerrit? 16.20.48 # Guess not I don't see em, no biggie just bored 16.21.47 # no, it's a revert of a commit basically 16.22.04 Quit FOAD (Ping timeout: 245 seconds) 16.22.09 # I'm waiting for the benches to end before comitting 16.23.21 # On a side note I think FS#12899 might be in the lcd driver 16.23.21 # http://www.rockbox.org/tracker/task/12899 3[fuze+] screen jumps navigating in upside-down mode (bugs, unconfirmed) 16.30.31 Quit pretty_function (Remote host closed the connection) 16.30.58 Join pretty_function [0] (~sigBART@123.252.213.221) 16.34.20 Join Strife89 [0] (~Strife89@2602:306:250e:659:d58b:ab68:54c9:efdd) 16.35.13 # foolsh: omg, some people really use the upside mode ?! 16.35.20 # ok I'll try that when the bench ends 16.35.51 Quit pretty_function (Ping timeout: 264 seconds) 16.35.59 # can someone close FS#12858 ? 16.36.00 # http://www.rockbox.org/tracker/task/12858 3Mpegplaye freeze sansa fuze plus (bugs, unconfirmed) 16.36.22 # It's no longer a bug and was never confirmed by anyone besides for me 16.38.52 # Wow, that was fast. Thanks. 16.39.45 # I'm always fast at closely bugs ;) 16.49.53 Join FOAD [0] (~foad@unaffiliated/foad) 16.52.21 Quit Zagor (Quit: Clint excited) 16.53.01 Quit Strife89 (Ping timeout: 240 seconds) 16.53.15 Quit ikeboy (Remote host closed the connection) 16.53.21 Join Strife89 [0] (~Strife89@2602:306:250d:18b9:d58b:ab68:54c9:efdd) 16.56.46 Quit mc2739 (Quit: leaving) 16.58.38 # Build Server message: 3New build round started. Revision cbed7ec, 243 builds, 33 clients. 17.04.29 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 17.05.48 # Build Server message: 3Build round completed after 430 seconds. 17.10.28 Join krabador [0] (~krabador_@unaffiliated/krabador) 17.37.20 Quit markun (Ping timeout: 252 seconds) 17.40.50 *** Saving seen data "./dancer.seen" 17.43.50 Quit FOAD (Quit: I'll be back) 17.44.07 Join FOAD [0] (~foad@unaffiliated/foad) 17.59.31 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 18.09.47 Quit petur (Ping timeout: 250 seconds) 18.21.10 Join pretty_function [0] (~sigBART@123.252.213.221) 18.21.50 Quit krabador (Ping timeout: 260 seconds) 18.27.21 Quit einhirn_ (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 18.33.54 Join futurisk [0] (futurisk@9mm.607hosting.us) 18.36.58 Join krabador [0] (~krabador_@unaffiliated/krabador) 18.40.28 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 18.43.40 Quit foolsh (Quit: foolsh) 18.48.03 Join CaptainKewl [0] (captainkew@207-237-110-248.c3-0.nyr-ubr2.nyr.ny.cable.rcn.com) 18.52.19 Join lorenzo92 [0] (~chatzilla@host160-157-dynamic.24-79-r.retail.telecomitalia.it) 18.53.03 # I'm happy to see that there is a port-party (especially by pamaury) :D 18.53.42 # pamaury: what did you modify to fix the battery drain on the cited targets? 18.54.19 # don't put SD/eMMC in TRAN mode all the time 18.55.34 # TRAN mode prevents the card from going to some internal low-power mode, or something like that? 18.57.20 # apparently 18.58.27 # interesting, not audio related stuff at all ^^ 18.58.37 Quit W0rmDr1nk (Ping timeout: 240 seconds) 18.59.08 # so afterwards we should also see if setting a "0" bias (not -50% that should decrease audio quality) affects battery life too 19.00.20 # feel free a do a battery bench ^^ but maybe after I commit this fix and we make sure it's the only regression 19.23.21 # wodz: "that doesn't keep from asking the others if they agree with you" Which others? And where should one ask? 19.23.50 Quit lorenzo92 (Ping timeout: 272 seconds) 19.32.48 Quit lebellium (Read error: Connection reset by peer) 19.37.06 Quit Strife89 (Quit: Heading out) 19.38.05 Quit pretty_function (Remote host closed the connection) 19.38.33 Join pretty_function [0] (~sigBART@123.252.213.221) 19.40.51 *** Saving seen data "./dancer.seen" 19.42.59 Quit pretty_function (Ping timeout: 240 seconds) 19.44.43 Join lorenzo92 [0] (~chatzilla@host219-104-dynamic.0-79-r.retail.telecomitalia.it) 19.52.43 Quit futurisk (Quit: leaving) 19.56.44 # lebellium: "I would rather sort by full name" Thanks for the suggestion. Now done. 20.03.24 Join Water [0] (~chatzilla@adsl-68-253-225-181.dsl.dytnoh.ameritech.net) 20.09.13 Quit Water (Quit: ChatZilla 0.9.90.1 [Firefox 25.0.1/20131112160018]) 20.34.10 # This freescale code is a nightmare, I don't know if I'll ever succeed in reversing the OF FTL 20.37.59 Quit chrisjj_ (Ping timeout: 250 seconds) 20.42.50 Join lebellium_gs2 [0] (~lebellium@80.215.1.98) 20.58.50 Quit pamaury (Ping timeout: 272 seconds) 21.00.00 Quit DormantBrain (Remote host closed the connection) 21.02.30 Join DormantBrain [0] (~andy@2001:470:8:a61::5f92:59a1) 21.02.48 Quit y4n (Quit: MOTHER EUROPA CALLING ME!) 21.02.54 Nick DormantBrain is now known as SuperBrainAK (~andy@2001:470:8:a61::5f92:59a1) 21.06.13 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 21.06.23 Join kugel [0] (~kugel@91-66-52-103-dynip.superkabel.de) 21.06.23 Quit kugel (Changing host) 21.06.23 Join kugel [0] (~kugel@rockbox/developer/kugel) 21.13.02 Quit kugel (Ping timeout: 264 seconds) 21.14.50 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 21.16.24 Join einhirn [0] (Miranda@bsod.vpn.tu-clausthal.de) 21.40.52 *** Saving seen data "./dancer.seen" 21.54.11 # lebellium_gs2: nwz has reached 20h and still going...I'm not sure it will reach 30h but it's still quite an improvement 21.54.57 # pamaury: great, that's already twice as much :) 22.00.38 Quit krabador (Quit: Sto andando via) 22.01.55 Join chrisjj [0] (561bb732@gateway/web/freenode/ip.86.27.183.50) 22.04.50 Quit bluebrother (Disconnected by services) 22.04.54 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 22.05.50 Quit kevku (Ping timeout: 260 seconds) 22.06.49 # pamaury: I've just pushed g#680 to gerrit to try and work around the 0xEE thing 22.06.58 Quit fs-bluebot (Ping timeout: 272 seconds) 22.07.33 Quit ikeboy (Quit: ikeboy) 22.07.52 # According to http://msdn.microsoft.com/en-us/library/windows/hardware/ff537430%28v=vs.85%29.aspx , "If there is no string descriptor at 0xEE, or the string descriptor at that index is not a valid OS string descriptor, Windows assumes that the device does not contain any OS feature descriptors", so that should behave exactly the same as a STALL on the windows side, except that it won't kill our devices if we have issues with STALL 22.08.30 Join fs-bluebot [0] (~fs-bluebo@g231121044.adsl.alicedsl.de) 22.08.44 # Hmm 22.08.46 # g#680 22.08.48 # 3Gerrit review #680 at http://gerrit.rockbox.org/r/680 : 3Return a valid USB string descriptor for index 0xEE. by Frank Gevaerts (changes/80/680/1) 22.08.51 # Ah, better :) 22.11.04 Join markun [0] (~markun@rockbox/developer/markun) 22.15.55 Join krabador [0] (~krabador_@unaffiliated/krabador) 22.16.14 # gevaerts: yeah that's what I suggested when saying we could return an empty string 22.16.26 # Yes 22.16.40 # I went for a non-empty one because we have three just lying around anyway :) 22.16.56 # sure :) 22.16.58 # That saves a byte or four I think 22.17.28 # I'm actually thinking that we should just push that and tell people to test current builds 22.18.00 # what's the problem with STALL, we can't stall on some platforms, or stall works too good? 22.19.06 # We don't recover from stall properly on at least ams 22.19.25 # It's not at all clear why 22.19.37 # And windows causes a stall on first connect by default these days 22.19.45 # hm 22.20.37 # I'd rather have the stall fixed than avoiding it and hope it never happens in any other scenario, but I realise the truth is probably that noone will fix ams usb thoroughly 22.21.29 # Well, it shouldn't ever happen in normal operation. 22.21.37 # This 0xee thing really is a weird exception 22.21.58 # And what g#680 does is perfectly valid 22.21.59 # 3Gerrit review #680 at http://gerrit.rockbox.org/r/680 : 3 by Frank Gevaerts (changes/80/680/1) 22.22.35 Join kugel [0] (~kugel@91-66-52-103-dynip.superkabel.de) 22.22.35 Quit kugel (Changing host) 22.22.35 Join kugel [0] (~kugel@rockbox/developer/kugel) 22.22.38 # bertrik: that's not even the problem, the problem is that no one knows how to recover from this STALL, it seems like a hardware bug 22.22.49 # probably with a workaround but we need to find it 22.23.09 # I'm still disassembling amsv2 ROM but it's really difficult 22.23.20 # I don't clearly remember how a stall get cleared 22.23.31 # host sends a "clear stall", right? 22.23.41 # Well, there definitely is a workaround, the OF doesn't have the problem 22.23.41 # on the control endpoint 22.23.51 # bertrik: this is on EP0, so it gets auto-cleared 22.24.42 # should, but doesn't? something like that? 22.24.50 # Yes 22.25.02 # The hardware is documented as doing this automatically 22.25.20 # But while it seems to actually clear the STALL, nothing else then still works 22.25.24 # pamaury: have you looked at it with the USB analyzer? 22.26.15 # bertrik: someone has. See FS#12910 22.26.15 # http://www.rockbox.org/tracker/task/12910 3Sansa zip clip fails to enumerate over USB under Windows. (bugs, unconfirmed) 22.26.18 # I seem to remember that USB mass storage relies quite heavily on stall too 22.26.30 # but that's on the bulk endpoints 22.27.09 # It doesn't really. You have to stall on error conditions, but those shouldn't happen anyway 22.28.39 Quit chrisjj (Quit: Page closed) 22.30.53 # gevaerts: how do I interpret that log? non-indented is host, indented is device? 22.31.19 Join chrisjj [0] (561bb732@gateway/web/freenode/ip.86.27.183.50) 22.31.57 # bertrik: have a look at the second image. That one is a bit clearer and actually shows the issue 22.32.06 # indented means the actual packets 22.32.52 # This software actually allows you to collapse entire transfers you don't care about 22.34.07 # chrisjj_ lebellium: re http://www.rockbox.org/wiki/TargetStatus , I see your previous edit left some targets out of order. If there was a reason for this, do please let me know and accept my apologies for 'correcting' it :) 22.36.39 # gevaerts: are the NAKs significant in the second log? 22.36.52 # chrisjj: there was no reason :) so no problem 22.37.15 # bertrik: yes. Apparently they don't ever stop 22.39.46 # NAKs happen automatically when the host sends an IN packet and the device controller has nothing to send, in the device controllers I know 22.40.05 # Yes 22.42.04 Quit einhirn (Ping timeout: 272 seconds) 22.42.28 # lebellium_gs2: OK! Thanks. 22.45.44 # What's the closest thing to a datasheet we have for the AMS usb controller? 22.47.02 # STM32F4xxx 22.47.19 # For anyone not bored by documentation detail :) do you too find http://www.rockbox.org/wiki/TargetStatus table column headers fail to sort? 22.52.37 Join einhirn [0] (~Miranda@p4FC77E10.dip0.t-ipconnect.de) 22.56.17 # i don't know if it's relevant but the ROM of the clip+ has few puzzling pieces of code: 22.56.17 # 1) it handles the SOF interrupt but does nothing of it, simply clear it 22.56.17 # 2) it handles IN token on empty fifo interrupt on IN endpoints but does nothing of it either 22.57.51 # 3) it handles OUT token with ep disabled and does nothing 23.01.05 Quit kugel (Ping timeout: 240 seconds) 23.08.18 Nick alecjw_ is now known as alecjw (~wright@cpc8-cmbg14-2-0-cust680.5-4.cable.virginm.net) 23.08.26 Quit alecjw (Changing host) 23.08.26 Join alecjw [0] (~wright@fsf/member/alecjw) 23.23.02 Quit markun (Ping timeout: 252 seconds) 23.23.37 # the AMS usb driver seems full of all kinds of hacky comments 23.24.07 Join wodz [0] (~wodz@87-207-223-0.dynamic.chello.pl) 23.24.57 # pamaury: This samsung rk2706b dap looks pretty much like reference design with small twist. 23.25.09 # well, maybe not full, but there are some things I'd like to be sure of, like is EP2 really an alias for EP0, like it says? 23.26.05 # wodz: yeah indeed 23.26.23 # bertrik: what ?! 23.26.33 Quit amayer (Quit: Leaving) 23.26.47 # As far as I can tell video is decoded on DSP core which is rather powerful. The lcdif has hw scaling block so I would say samsung R&D did poor job OR rockchip didn't support them with proper documentation. 23.27.07 # decoders are in binary form in SDK 23.27.30 # and no free toolchain nor documentation is available for ZSP500 core 23.29.09 # yeah I pretty much stalled on the zsp, it would be nice to work on it but so many things to do 23.29.14 # and I guess writing a decoder on this dsp would not be trivial 23.29.32 # bertrik: where did you find this comment ? 23.29.57 # pamaury: we could offload some stuff to dsp cop BUT form most audio arm core is enough so why bother 23.30.22 # *for 23.30.37 # usb-drv-as3525 line 159 23.31.11 # exactly 23.31.11 # it's just fun to be able to use the whole hardware though 23.32.04 # this is not the driver for amsv2 23.33.01 # Anyone knows MIPS? I can't wrap my head around exception dispatcher. Every implementation I saw saves whole set of GPRs but according to my understanding s0-s8 registers are saved anyway in function prologue if it wants to use it. This would save 9 registers push/pop on every exception (irq) 23.33.06 # the bug we are talking about affects sansa AMSv2 as far as I know 23.33.25 # wodz: sorry I don't :( 23.34.38 Quit lorenzo92 (Ping timeout: 272 seconds) 23.34.57 # pamaury: argh, sorry 23.35.21 # pamaury: I would also like to fully utilize the hardware but there are less exotic functions to implement 23.36.04 # like NAND... 23.36.16 # and this MIPS thingy caught my attention... 23.36.31 # like USB 23.36.45 # also... 23.37.53 # I swear it, if I meet the guy who wrote the Sansa AMS ROM, I will kill him 23.38.17 # There should be a law to forbid writing usb drivers likes this one 23.40.53 *** Saving seen data "./dancer.seen" 23.44.00 Join markun [0] (~markun@rockbox/developer/markun) 23.58.01 # yeah, I understood how irq dispatch work on this ROM: irq_handler() calls usb_globals->handle_irq() whichs calls this->thing->handle_irq() which calls this->sub->hwdrv->handle_irq() 23.58.09 # that's perfectly sensible now