--- Log for 09.10.115 Server: sinisalo.freenode.net Channel: #rockbox --- Nick: logbot- Version: Dancer V4.16 Started: 22 days and 19 hours ago 00.00.58 # <[Saint]> The best I can do is assigning 0xABCD as the vendor ID and 0x1234 as the product ID. 00.01.20 # well HAVE_AGC built for the fuze+ lemme test it on target 00.01.49 # <[Saint]> For our purposes, it doesn't need to be a "real" (there's not really such a thing as a "fake" VID/PID) ID..it just needs to not be one that is recognized as an iPod. 00.03.00 # <[Saint]> TL;DR: most car head units, and all Apple Macs, see the USB VID/PID, see that it's an iPod, and flatly refuse to talk to the device in any other way. 00.03.32 # <[Saint]> Not having anywhere near complete IAP support makes that a very real problem. 00.03.38 # there was a plan to claim a free usb ID some time ago 00.03.50 # <[Saint]> There was indeed. 00.04.07 # <[Saint]> It needed a Swede, or at least active coordination with a Swede, though. 00.04.43 # <[Saint]> And both of those things were difficult to get at the time, and they haven't been made any less difficult as time goes by. 00.05.34 # <[Saint]> Those of us interested in keeping the project alive need to have some rather important discussions about what to do with Rockbox. 00.05.52 # It is not too late to apply 00.06.08 # yes I agree 00.06.17 # especially about the infrastructure 00.06.33 # <[Saint]> No, indeed not. But we really need it to be one of the original founders, or at least have one of them in the chain of communication. 00.06.38 # <[Saint]> ANd, yes. 00.07.03 # <[Saint]> We need to separate ourselves from the total dependence on Haxx infrastructure. 00.07.23 # agree, the major question is how 00.07.55 # basically I see either self-hosting or using free services like github or gitlab 00.08.04 # <[Saint]> I would be more than happy to host the build master. 00.08.42 # <[Saint]> And I think the only realistic option is moving to github for both versioning and regression/bug lodging. 00.09.32 # <[Saint]> The other issue, even though he swears it isn't an issue, is scorche hosting the forums entirely out of his own pocket. 00.09.41 # <[Saint]> That has bothered me for a loooooooooooooooong time. 00.10.40 # I am renting a server with a friend, we have plenty of power and space on it, I could run it I think 00.10.57 # <[Franklin]> the issue is whether it's long-term or not 00.12.00 # [Saint]: HAVE_AGC runs on fuze+ target, but I have to recode some music so I can test if it works 00.12.02 # [Franklin]: what exactly ? 00.12.14 # <[Franklin]> pamaury: is it a long term solution? 00.12.55 # I think so 00.13.18 # [Saint]: what was the reason to run the forum on a different server than the webserver by the way 00.13.29 # * [Franklin] thinks the project is too closely tied to haxx to break away completely 00.13.51 # <[Franklin]> maybe the website would continue to be hosted by them 00.13.51 # <[Saint]> pamaury: honestly, I have absolutely no idea. 00.14.21 # <[Saint]> Honestly. it's not tightly coupled to Haxx at all really. 00.14.22 # there is nothing we cannot reproduce, we have all the scripts and so on, the only thing is the domain name really 00.14.31 # <[Saint]> precisely. 00.16.07 # We should probably discuss this on the mailing list ? Explain the plan, discuss the different possibitlies for each service 00.16.12 # <[Saint]> I would sincerely doubt that they would be unwilling to release the domain. 00.16.23 # I am sure the Swedes will be happy to help us 00.16.39 # <[Saint]> And, yes. I've had a mail regarding this partially drafted for a while now. 00.17.07 # I mean the gerrit situation made it obvious that we *need* to do something 00.17.24 # <[Saint]> Basically, I think that /anything/ that has the decoupling of the Swedes as an end goal would be eagerly accepted. 00.17.42 # For the Iaudios AGC doesn't make sense for mic recording at minimum because there are only two gain settings - and I believe for line-in the steps are still too coarse to have good results with AGC 00.17.52 # there is will be technical questions on how exactly we migrate some services/bugs/patches and so on 00.18.01 # So it's not only software related 00.18.45 # Just as an example 00.19.24 # pixelma: how fine grained is the gain control on the iriver ? 00.22.12 # For mic it's only 0dB and 20dB, line-in is in 1.5dB steps from -34.5 to 12 dB 00.23.31 # <[Saint]> IS there some technical reason as to why the mic gain isn't able to be user controlled more finely? 00.23.49 # <[Saint]> Or is it just some lazy-ass define that could be changed trivially? 00.24.27 # [Saint]: usually mic gain is hardware controlled and on most target is it very coarse 00.24.53 # No... as pamaury says 00.25.01 # on the fuze+ I think you have four settings like 0dB, 10dB, 20dB and 40dB 00.25.41 # do we support different mic vs line-in gains ? 00.25.50 # <[Saint]> Doing it in software after the fact would be too expensive? 00.26.00 # <[Saint]> Not worth it? 00.27.02 # I guess not worth it but I'm no audio expert 00.27.07 # pamaury: from what I see on my M5 - yes, and see above 00.27.32 Quit pamaury (Remote host closed the connection) 00.27.47 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 00.31.04 # <[Saint]> prof_wolfff: debug builds on ipod6g appear to be broken 00.31.47 # <[Saint]> prof_wolfff: a bunch of errors in file_internal.c and file.c|o 00.32.35 # <[Saint]> just looks like type missmatches. 00.34.28 # <[Saint]> prof_wolfff: (logs) http://hastebin.com/ubejizupaz.pas 00.37.22 Join ulmutul [0] (~chatzilla@x5d8373d6.dyn.telefonica.de) 00.37.39 # <[Saint]> Hmmmm...another odd recording related define that is lacking for no obvious reason: 00.37.46 # <[Saint]> HAVE_HISTOGRAM 00.37.56 # <[Saint]> pixelma: any thoughts here? 00.38.21 # <[Saint]> again this only seems to exist for the iriver h* 00.38.43 *** Saving seen data "./dancer.seen" 00.41.00 # I believe screen estate or so, if it's for the H1x0 though then it may "just" not have been adapted to other screens. IIRC it was from some big recording patches that existed for the Irivers in unsupported builds for a while until petur committed them to main Rockbox 00.41.27 # <[Saint]> H100, H120, H300 00.42.22 # <[Saint]> I guess I'll do the same thing here and just blindly enable it. 00.42.25 # <[Saint]> See what happens. 00.42.50 # <[Saint]> screen realestate is no issue on the non-nano iPods. 00.45.00 Quit ZincAlloy (Quit: Leaving.) 00.45.02 # non-Mini I guess. The Nano's screen has already more pixels than the H1x0s 00.45.42 # IMO AGC sucks - at least for music recording; you always end up with a lot of compression and pumping artefacts that you can't remove. You get much better results if you record with plenty of headroom and compress afterwards (during playback). So it's not worth the effort (Just my 2 cents :) ) 00.46.01 # [Saint]: the forums thing isnt an issue =) 00.46.21 # But then there are other targets than Ipods 00.47.54 # for reference, i have offered to host the main site and so on in the past - there were concerns brought up about hosting everything in the US though 00.49.30 # the forums have always been a separate site - it initially started when Jeff from Misticriver dedicated a section to Rockbox - that eventually turned into a separate site 00.49.53 # there were many performance issues though and Jeff was really a separate entity 00.50.21 # i simply stood up and made the effort to transition away from that site and to stand up my own to fix the issues 00.50.35 # that grew to also hosting translate and themes 00.55.40 # <[Saint]> Hmmmm...since the clickwheel iPod keymaps are identical, I guess there is legitimately zero reason for the iPods to not all have AB repeat/AB hotkey 00.55.41 # I have mixed feeling about hosting the site in the US too although I don't know if it's a real risk or not 00.56.06 Quit [Franklin] (Ping timeout: 252 seconds) 00.56.07 # <[Saint]> It makes shit VERY difficult to adhere to EU regulations. 00.56.17 # <[Saint]> data access, etc. 00.56.45 # <[Saint]> Though, like you say, not sure if that's actually a real concern or a meta concern. 00.57.15 # <[Saint]> For my part, with my services, I just turn away anyone based in the EU. 00.57.17 # i believe the concerns were more around legality of codecs and such 00.57.25 # <[Saint]> right. 00.58.22 # [Saint]: I'm not sure I understand what you mean, hosting the US is okay or not okay ? 00.58.32 # * [Saint] enabled AB repeat and AB repeat hotkey for all the iPods. 00.58.40 # <[Saint]> pamaury: not OK, generally speaking. 00.58.47 # ok :) 00.59.15 # <[Saint]> data access and retention legislations are a royal PITA. 01.00.49 # <[Saint]> So much so that I ended up just cutting off the rest of the world from accessing my services about a year ago. 01.08.14 Join munch [0] (~munch@unaffiliated/munch) 01.08.46 Join [Franklin] [0] (~franklin@unaffiliated/franklin) 01.13.34 # prof_wolfff: you can get it from http://www.felixbruns.de/iPod/firmware/ 01.13.41 Quit ulmutul (Quit: ChatZilla 0.9.92 [Firefox 41.0.1/20150929144111]) 01.13.50 # my classic2g runs it 01.15.03 Quit munch (Quit: ZNC - http://znc.in) 01.16.50 # <[Saint]> that was a point release for some odd hardware substitution they did, was it not? 01.17.19 # <[Saint]> I recall doing some investigation on this a while ago, but perhaps I'm mixing it up. 01.23.11 Join munch [0] (~munch@2601:98a:302:955d:126f:3fff:fed7:41) 01.23.11 Quit munch (Changing host) 01.23.11 Join munch [0] (~munch@unaffiliated/munch) 01.26.31 # [Saint]: HAVE_HISTOGRAM compiles for fuze+ but I have no idea what I'm looking for it on the player 01.40.32 # <[Saint]> Jesus Christ patch can be really stupid sometimes. 01.40.53 # <[Saint]> rejecting a patch with a fuzz factor of a single line. 01.40.58 # <[Saint]> ....c'mon! 01.41.45 # <[Saint]> Fuck me for wanting each patch to be independent of each other, right? :-S 01.43.19 # [Saint]: any particular program suggestions to analyze and set replay gain data? 01.43.48 # <[Saint]> I use foobar2000 in WINE personally. 01.44.00 # <[Saint]> But that's solely a personal preference thing. 01.44.23 # <[Saint]> I just so happen to believe that foobar2000 is the best media player ever for a desktop environment. 01.44.34 # as long as it works, I give it a try 01.44.52 # <[Saint]> MusicBrainz Picard is another. Clementine will do it as well IIRC. 01.45.22 # <[Saint]> If you don't use MusicBrainz Picard, do so. 01.45.44 # * foolsh makes it so 01.45.47 # :P 01.45.57 # <[Saint]> It's the best metadata management and tagging tool like....ever. IMO. 01.45.58 Quit pamaury (Ping timeout: 265 seconds) 01.46.46 # <[Saint]> It uses the acoust.id audio signature and metadata databases. 01.47.08 # <[Saint]> makes tagging foolishly (foolsh-ishly?) easy. 01.47.50 # right up my alley then 01.48.08 # <[Saint]> You seriously never had replaygain tags until now? 01.48.36 # * foolsh admits he thumbs the volume buttons every track 01.48.55 # <[Saint]> GnnnnaaaaaaaAAAh! 01.50.10 # Lmao, I gave him a conniption 02.01.22 # <[Franklin]> ooh... g#1221 looks really interesting 02.01.28 # Saint: thanks, really never tried to build with (D)EBUG, i will try to solve it tomorrow, please tell me if you see any other problem, have you tried the bootloader? 02.01.34 # 3Gerrit review #1221 at http://gerrit.rockbox.org/r/1221 : 3iPod Classic: dual bootloader - v1 by Cástor Muñoz 02.01.41 # <[Franklin]> prof_wolfff: does it work (well)? 02.02.02 # <[Saint]> prof_wolfff: I have not, I am just going through now and checking off a couple of things that are disabled but have no reason to be. 02.02.28 # yes, it is functional but needs manual install, it is tested on iPod 80 and 160slim 02.02.50 # <[Franklin]> that's awesome 02.03.13 # <[Saint]> prof_wolfff: as it stands now, there's AB repeat and AB repeat WPS single-action support, FM tuner, and FM tuner RDS. 02.03.22 # <[Saint]> But I suspect I'll find more. 02.03.34 # user890104: i have the firmware but need to insert it into the iPod to get the decrypted hash, it is a priority for me 02.03.43 # <[Saint]> Just checking to see if AGC and recording histogram adds anything of value to us. 02.04.02 # <[Saint]> Now that there's IAP and serial, FM support should "Just Work". 02.04.28 # <[Saint]> I can only check to see if it compiles presently, need to find my FM remote tuner. 02.04.49 # i have not tried the FM support but a friend of me owns a radio remote so i could test it in the future 02.04.59 # * [Saint] nods 02.05.06 # prof_wolfff: i can install it on mine, then sideload emcore and dump the beginning of the hdd, is this going to help you? 02.05.19 # <[Saint]> thank you for committing the patch sets for this by the way prof_wolfff 02.05.23 # <[Saint]> it is appreciated. 02.05.32 # thanks 02.06.04 # <[Saint]> gerrit is largely useless now as it doesn't show dependencies anymore, and I didn't feel like going through the ~700+ possible iterations of the patch sets. :) 02.06.40 # user890104, i need the decripted NOR, offset 0x40 to 0x50, IIRC i could be done by spireader by TheSeven 02.07.18 # prof_wolfff: i can dump the flash with emcore, too 02.07.45 # i'll try it in a couple of minutes 02.08.08 # user890104: i you get a decripted copy, then the hash is at offset 0x40, length=16, if you add this hash to the bootloader then it should work 02.08.53 Join krabador [0] (~krabador@unaffiliated/krabador) 02.10.37 # user890104: the 0x40 offset if from start of NORBOOT, so it is 0x8000+0x40 from the start of the whole NOR 02.11.48 Quit munch (Quit: ZNC - http://znc.in) 02.12.11 Join munch [0] (~munch@c-174-55-32-16.hsd1.pa.comcast.net) 02.12.11 Quit munch (Changing host) 02.12.11 Join munch [0] (~munch@unaffiliated/munch) 02.17.56 # prof_wolfff: i remember that i have a backup of the whole NOR flash before any third-party changes 02.20.05 # user890104: it can serve if it is decrypted, encrypted copies are different on each device because each device uses its own UKEY 02.21.37 # user890104: if you cannot get it, i can send you tomorrow a .dfu to obtain it, is its more easy than decrypt it myself 02.22.14 # prof_wolfff: ok, thanks 02.22.23 # http://i.imgur.com/GJPmPrf.png 02.22.29 # this is what i have at the moment 02.22.47 # i guess it's encrypted 02.23.35 # <[Saint]> shit - I forget - how do we specify a custom version number/string at compile time? 02.23.58 Quit [Franklin] (Ping timeout: 272 seconds) 02.24.50 # user890104: the only way to verify is adding it to dualboot.c->of_sha[] and try to install the bootloader 02.25.03 Join jtdesigns01_ [0] (~jtdesigns@c-68-43-178-141.hsd1.mi.comcast.net) 02.25.32 # user890104: the bootloader will refuse to install if it don't find a known OF 02.26.11 # <[Saint]> make VERSION=EXPERIMENTAL -j 72 02.26.15 # <[Saint]> bah 02.27.41 # <[Saint]> Ah....Hmmm. 02.27.56 # <[Saint]> FM support needs more work than just enable CONFIG_FM_TUNER 02.28.10 # <[Saint]> Needs FM to be declared as a valid audio path too. 02.28.12 Quit jtdesigns01 (Quit: jtdesigns01) 02.29.26 # Saint: IIRC when doing the IAP patch there was some things to do for the FM tunner, i wil look at this in the future 02.29.26 Join [Franklin] [0] (~franklin@unaffiliated/franklin) 02.32.22 # <[Saint]> prof_wolfff: there's a slim chance I might beat you to it, but, I'd have to get you to overlook it anyway. 02.33.07 # <[Saint]> needs added to firmware/target/arm/s5l8702/audio-ipod6g.c 02.33.08 # :) 02.34.38 # i will borrow the remote FM from my friend, should be easy to test an fix it 02.34.54 # <[Saint]> what audio driver does the classic use? 02.34.59 # <[Saint]> wm8978? 02.35.11 # <[Saint]> bah - I shouldn't be so lazy. 02.35.30 # cs42l55 02.36.41 # <[Saint]> Oh lord... 02.36.51 # IIRC i leave things almost prepared for the FM 02.37.00 # <[Saint]> and of course nothing else uses it, so, the driver has no idea about AUDIO_SRC_FMRADIO 02.37.16 # <[Saint]> wonderful. 02.37.18 # <[Saint]> :-S 02.38.12 # <[Saint]> cs42l55 driver is really quite elegant, in a way. rather simplistic. 02.38.47 *** Saving seen data "./dancer.seen" 02.39.44 # <[Saint]> I suppose we don't have a datasheet for cs42l55 either, just to make things extra wonderful? 02.40.36 # <[Saint]> /* Ask Cirrus or maybe Apple what the hell this means */ 02.40.38 # <[Saint]> ... 02.40.44 # <[Saint]> I guess that answers that question. 02.42.14 # there is a datasheet for a similar CODEC, IIRC that stuff is internal initialization that depends on power voltages 02.42.20 # <[Saint]> Oh. Hmmm....apparently someone has one. 02.42.25 # HAVE_AGC is confirmed to work on fuze+, I would test the e2x0 but I gave mine away 02.42.37 # * foolsh looks at [Franklin] 02.43.06 # <[Saint]> foolsh: yeah, offhand I'm not seeing any reason for it to not be abled globally for anything with HAVE_RECORDING 02.43.15 # <[Saint]> *enabled 02.43.30 # <[Saint]> It kinda looks like the define just got forgotten about. 02.43.47 # <[Franklin]> ahem? 02.44.02 # <[Franklin]> what's up? 02.44.14 # <[Saint]> Looking through the source, one can see in various places, forgotten or far-too-similar, even occasionally identical but differently named, defines. 02.44.59 # "#define HAVE_AGC" in your firmware/export/config/$target will enable automatic replay gain 02.45.00 # Saint, user890104: i must go to bed now, i have to get up very early tomorrow, user890104 tell me if you need the .dfu, if so i will prepare it and send to you tomorrow 02.45.03 # <[Saint]> a list of all defines and their functions would be rather handy. I'll need to do that to do what I want to do anyway (template generation) 02.45.15 # <[Saint]> goodnight prof_wolfff. 02.45.18 # <[Saint]> o/ 02.45.42 # <[Franklin]> foolsh: how should I test it? 02.46.02 # prof_wolfff: gn, yes please upload it somewhere and PM me a link 02.46.22 # user890104: ok 02.51.34 Join adnap [0] (~adnap@cpe-24-28-68-235.austin.res.rr.com) 02.53.01 # [Franklin]: check your gmail 02.54.12 # use them with per track replay gain enabled should play them exactly the same volume, without it one is much softer 02.55.12 # Can the database_changelog.txt be changed to UTF-8? Unicode filepaths are messed up when exporting this file. 02.55.44 # It would be backwards compatible. 02.56.38 # Or rather, old database_changelog.txt files would be forward-compatible. 02.59.13 # <[Franklin]> foolsh: building 03.02.16 # [Franklin]: the setting is in Settings->Playback Settings->Replaygain 03.02.45 # change type to Track Gain 03.04.12 # I cranked preamp all the way but I don't think it matters, and there's Prevent Clipping duh why wouldn't you enable it 03.04.12 # <[Franklin]> ok 03.04.58 # * [Franklin] has some partial work on ducky 03.05.11 # <[Franklin]> jumping is partially there 03.05.20 Quit jtdesigns01_ (Quit: ZNC - 1.6.0 - http://znc.in) 03.05.59 # Ah sweet, I was thinking, should relative jumps be used instead of explicit, it seems it maybe "easier" to code 03.07.01 # <[Saint]> foolsh: I think there's some fundamental misunderstanding here. 03.07.28 # * foolsh isn't surprise 03.07.36 # <[Saint]> replaygain "Just Works", always has. 03.07.44 # <[Saint]> This is gain control for recording. 03.08.01 # AH thats a horse of a different color! 03.08.07 # <[Saint]> 'tis indeed. :) 03.08.24 # * foolsh sets off to record some things 03.08.44 # <[Franklin]> foolsh: that's a good point 03.08.57 # <[Saint]> Sorry I didn't click prior, I thought you wanted to view/modify gain after recording. 03.08.57 # <[Franklin]> maybe labels would be worth implementing 03.09.26 # [Saint]: so what does HAVE_HISTOGRAM do? 03.10.01 # <[Saint]> it should add a histogram to the recscreen. 03.10.12 Join jtdesigns01 [0] (~jon@c-68-43-178-141.hsd1.mi.comcast.net) 03.10.20 Part jtdesigns01 03.10.31 # [Franklin]: maybe, but jumping relative lines and checking for out of bounds might be all it needs 03.14.20 # <[Franklin]> nah 03.14.31 # <[Franklin]> that makes it too hard to maintain 03.14.54 # <[Franklin]> if you want to insert one line, you have to change all the offsets around it 03.15.04 Join jtdesigns01 [0] (~jon@c-68-43-178-141.hsd1.mi.comcast.net) 03.15.12 # okay, I leave it in your capable hands 03.15.32 # * [Franklin] senses some sarcasm, but OK :P 03.15.45 # no no, you read me wrong 03.15.53 # <[Franklin]> lol 03.15.59 # <[Franklin]> joking 03.16.16 # <[Franklin]> anyway, enabling AGC seems to have messed up the language strings 03.16.43 # <[Franklin]> where there should be "Games", there's "Only Unknown Types" instead 03.16.50 # really? thats interesting 03.17.10 # * [Franklin] tries a reboot 03.17.52 # <[Franklin]> still messed up 03.19.49 # [Saint]: A histogram does not show up in the fuze+ rec screen, maybe there's something else to that define 03.20.01 # [Franklin]: thats weird try a clean build 03.20.40 # <[Saint]> foolsh: going over the source a couple of times now it seems as though it has been either forgotten about or deliberately removed. 03.20.49 Join Google [0] (442bb28d@gateway/web/freenode/ip.68.43.178.141) 03.21.03 Quit Google (Client Quit) 03.21.05 # <[Saint]> unless I'm repeatedly missing it. 03.21.28 # <[Saint]> There's bits of it left in a couple of places, but, it doesn't actually seem to get used. 03.21.49 Join Google [0] (442bb28d@gateway/web/freenode/ip.68.43.178.141) 03.22.07 # Hello Everyone 03.22.13 Nick Google is now known as Guest31597 (442bb28d@gateway/web/freenode/ip.68.43.178.141) 03.22.26 # <[Franklin]> hello Guest31597 03.22.29 # seriuosly augustine? 03.22.34 # googel? 03.22.46 # (thats my brother messing with me) 03.22.58 # i know the ip address :P 03.23.33 # *google 03.23.54 # you finally bothered to check the userstring good job ROFL 03.24.27 # i'm waiting a newer rockbooox!!!! 03.24.28 # u spellt seriously wrong 03.24.36 # wheeeeen??? 03.24.38 # fool me once shame on you, fool me twice shame on me 03.24.39 # :D 03.24.40 # jtdesigns01: 03.24.52 # * foolsh asks the children to go play in #rockbox-community 03.25.14 # yeah about to say that myself 03.26.24 # foolsh, ok, stop joking. 03.27.15 # foolsh: sorry 03.28.06 # jtdesigns01: how is the DF coding going??? 03.28.55 # Guest31597: i am supposed to be writing a paper right now, you are too. bye. 03.29.06 # oops its not DF what is it? 03.29.12 # im done 03.29.20 Quit Guest31597 (Quit: Page closed) 03.32.07 Quit krabador (Quit: Take The Time) 03.34.08 # <[Franklin]> good night guys 03.34.22 # <[Franklin]> foolsh: will test it tomorrow 03.34.24 Quit [Franklin] (Quit: Lost terminal) 03.34.27 # o/ 03.37.02 Join test [0] (442bb28d@gateway/web/freenode/ip.68.43.178.141) 03.37.25 Nick test is now known as Guest31452 (442bb28d@gateway/web/freenode/ip.68.43.178.141) 03.44.09 Quit Guest31452 (Quit: Page closed) 03.55.43 Quit amiconn (Ping timeout: 246 seconds) 03.55.43 Quit pixelma (Ping timeout: 246 seconds) 04.02.07 Join FSanches [0] (~felipe@2804:14c:37:268b:487e:bfe2:30c2:3a2a) 04.02.27 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 04.02.37 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 04.03.08 Quit foolsh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 04.04.11 Join foolsh [0] (~quassel@c-69-245-208-80.hsd1.il.comcast.net) 04.15.25 Quit adnap (Remote host closed the connection) 04.16.20 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 04.19.35 Quit JdGordon_ (Ping timeout: 255 seconds) 04.38.49 *** Saving seen data "./dancer.seen" 04.49.35 Quit jtdesigns01 (Quit: ZNC - 1.6.0 - http://znc.in) 04.50.20 Join jtdesigns01 [0] (442bb28d@gateway/web/freenode/ip.68.43.178.141) 05.08.14 Quit jtdesigns01 (Ping timeout: 246 seconds) 05.32.15 Join nick_p [0] (~nick_p@82-69-105-120.dsl.in-addr.zen.co.uk) 05.34.53 Quit TheSeven (Disconnected by services) 05.35.06 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 05.35.11 Quit nick_p (Client Quit) 05.35.32 Join nick_p [0] (~nick_p@82-69-105-120.dsl.in-addr.zen.co.uk) 05.36.58 Quit nick_p (Client Quit) 05.48.25 Quit n1cky (Quit: leaving) 06.35.14 Quit ParkerR (Quit: Leaving) 06.38.52 *** Saving seen data "./dancer.seen" 06.44.43 Join ParkerR [0] (~ParkerR@unaffiliated/parkerr) 06.55.14 Quit ParkerR (Remote host closed the connection) 06.59.59 Join ParkerR [0] (~ParkerR@unaffiliated/parkerr) 08.12.16 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 08.15.07 # [Saint]: AFAIK AGC needs sufficiently fine grained gain steps which IS hardware depended. Putting this aside irivers Hxx are the only targets where someone cared enough to enable this. 08.22.37 Join ender` [0] (krneki@foo.eternallybored.org) 08.24.50 # About moving ifrastructure - I am definitely against hosting in US. We need to host in a country which does allow reverse engineering really. 08.26.12 # Speaking about build system - it works but is mainly unmaintained. It lacks a few features like test builds and release builds. There are alternatives. 08.38.54 *** Saving seen data "./dancer.seen" 08.45.50 Quit amiconn (Remote host closed the connection) 08.45.50 Quit pixelma (Remote host closed the connection) 08.47.52 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 08.47.54 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 09.02.33 Join petur [0] (~petur@rockbox/developer/petur) 09.36.38 Quit amiconn (Remote host closed the connection) 09.36.38 Quit pixelma (Remote host closed the connection) 09.37.00 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 09.37.00 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 09.52.50 Join b0hoon [0] (~quassel@62.87.184.82) 09.55.25 Join TheLemonMan [0] (~lemonboy@unaffiliated/thelemonman) 09.57.39 Join soap_ [0] (~soap@rockbox/staff/soap) 09.59.45 Quit soap (Ping timeout: 260 seconds) 10.22.08 Quit munch (Quit: ZNC - http://znc.in) 10.22.33 Join munch [0] (~munch@2601:98a:302:955d:126f:3fff:fed7:41) 10.22.33 Quit munch (Changing host) 10.22.33 Join munch [0] (~munch@unaffiliated/munch) 10.38.56 *** Saving seen data "./dancer.seen" 10.57.30 Join krabador [0] (~krabador@unaffiliated/krabador) 11.11.38 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 11.14.43 Quit JdGordon (Ping timeout: 272 seconds) 11.34.22 Quit williamtdr (Ping timeout: 264 seconds) 11.59.16 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.13.56 Join williamtdr [0] (uid27909@gateway/web/irccloud.com/x-rygzcgrvxwuadfwy) 12.33.45 Quit kvieta (Ping timeout: 260 seconds) 12.38.20 Join kvieta [0] (~kvieta@149.255.110.134) 12.39.00 *** Saving seen data "./dancer.seen" 13.28.27 Join pablo_pi_ [0] (~pablo@190.148.249.124) 13.31.17 Quit pablo_pi (Ping timeout: 255 seconds) 13.40.14 Join Aldem [0] (~Aldem@unaffiliated/aldem) 13.44.14 Quit krabador (Quit: Take The Time) 14.03.13 Join ZincAlloy [0] (~Adium@pD9FB6DF8.dip0.t-ipconnect.de) 14.03.59 Join stickyb1t [0] (~egon@msw13.pip.aber.ac.uk) 14.16.22 Quit shamus (Ping timeout: 264 seconds) 14.17.12 Quit stickyb1t (Ping timeout: 246 seconds) 14.17.22 Join shamus [0] (~shmaus@ip-206-192-194-12.marylandheights.ip.cablemo.net) 14.27.47 Part b0hoon ("GTG... Bye.") 14.39.01 *** Saving seen data "./dancer.seen" 15.19.41 # pamaury: I tried hard to simplify the logic in hwstub_server. I think there is still small glitch in HWSERVER_OPEN_DEV but I need to think harder about it. 15.22.11 Quit wodz (Quit: Leaving) 15.35.39 Join amayer [0] (~amayer@mail.weberadvertising.com) 16.01.54 Quit JanC (Ping timeout: 240 seconds) 16.15.49 Join JanC [0] (~janc@lugwv/member/JanC) 16.39.06 *** Saving seen data "./dancer.seen" 16.50.43 Quit petur (Quit: Leaving) 17.10.37 Quit amayer (Ping timeout: 240 seconds) 17.42.28 Join krabador [0] (~krabador@unaffiliated/krabador) 17.53.50 Quit Aldem (Read error: Connection reset by peer) 17.54.15 Quit rela (Quit: Leaving) 17.58.28 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 17.59.08 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 18.01.28 Join Aldem [0] (~Aldem@unaffiliated/aldem) 18.20.51 # wodz (logs): I need to study your patch carefully, I think there is a problem in the way you handle device and client disconnect 18.24.22 Join amayer [0] (~amayer@mail.weberadvertising.com) 18.26.38 Quit pamaury (Ping timeout: 272 seconds) 18.29.54 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 18.39.09 *** Saving seen data "./dancer.seen" 18.45.58 Join Strife89 [0] (~Strife89@2602:306:bce1:8c20:189d:ae30:aac:4f68) 18.46.21 Quit pamaury (Ping timeout: 246 seconds) 18.47.18 # When did the Rockbox project get a time machine? :) 18.48.17 # Tomorrow 18.51.31 # That doesn't make any tense. 18.56.53 # Sorry. That wasn't in-tense-ional 19.01.45 Join wodz [0] (~wodz@89-75-106-221.dynamic.chello.pl) 19.32.31 Join lebellium [0] (~chatzilla@89-93-179-187.hfc.dyn.abo.bbox.fr) 19.48.55 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 20.03.11 Quit krabador (Read error: No route to host) 20.03.23 Join krabador [0] (~krabador@host10-186-dynamic.42-79-r.retail.telecomitalia.it) 20.03.32 Quit krabador (Changing host) 20.03.32 Join krabador [0] (~krabador@unaffiliated/krabador) 20.14.27 Join nlogex [0] (~filip@dhcp-108-168-16-140.cable.user.start.ca) 20.14.29 Quit Strife89 (Quit: Leaving) 20.30.46 Join petur [0] (~petur@rockbox/developer/petur) 20.33.16 # pamaury: ping 20.39.05 # wodz: pong 20.39.10 *** Saving seen data "./dancer.seen" 20.40.03 # pamaury: You mean that reflist is not freed and hwstub device not released when necessary, right? 20.42.04 # not sure what you mean. What I have in mind is the following: 20.42.04 # - devices in reflist should not disappear unless the client has closed them 20.42.04 # - reflist must be destroyed and devices closed (or unref) when client quits 20.42.04 DBUG Enqueued KICK pamaury 20.42.04 # - devices that disappear from global list but are still in reflist could just be marked as "disconnected" and operations on them would always fail and the server would not actually perform the usb operation 20.42.36 # in other words, it is the responsability of the client to close a disconnected device 20.44.11 # with reflist not destroyed on disconnect I agree, clearly needs to be done 20.44.39 # but I don't see the point of holding reflist entry when device got disconnected 20.44.51 # because client still has a reference to it 20.45.34 # but calling any hwstub command after removing entry from reflist will fail with HWSTUB_INVALID_REF 20.45.50 # thats the sign for the client that device is not valid anymore 20.45.51 # except close 20.46.16 # maybe close should not fail but is bogus anyway 20.47.30 # if you get HWSTUB_INVALID_REF that means device is dead and you should clean on your side 20.48.17 # calling HWSERVER_GET_DEV_LIST is probably the most appropriate 20.48.35 # I mean to refresh list of devices available 20.48.41 # on client side 20.48.58 # yeah but client should still call close and thus making the server do some kind of 'auto-close' seems wrong. And I think this will actually make the design of server simpler 20.50.18 # I can't see how this will make server simpler. 20.51.15 Join mirak [0] (~mirak@5-49-128-198.hfc.dyn.abo.bbox.fr) 20.53.11 # you keep one global list of devices (some of them may have been disconnected). Each device has a reference counter: number of clients that hold a reference to it. Each client thread has a local list: this is a list of opened devices. Whener a client opens a device, the thread updates the ref count in the global list and adds it to its local list. whener it closes the device, it unref the global one and delete it from the local list. Now each 20.53.11 # global device has a ref count of 1 initially. One device disconnect (hotplug), you simply decrement this number. In all cases, when a device ref goes to 0, it is removed from the global list 20.54.53 # Ok but who is responsible for checking if ref count is 0? 20.57.20 # the function that unref 20.57.34 # (could be hotplug or client) 21.00.13 # ok but now look at such scenario: two clients opened the same device (so ref count is 3 in your scheme), the device got disconnected (ref count drops to 2), now client wants to do something and gets error. It would need to know why it is so to perform internal cleanup and close() 21.00.49 # why bother to issue usb transfer which will fail to tell client it failed? 21.01.20 # on disconnect, set a flag to mark the dev as disconnected 21.02.19 # you can as well check if the device with specific ref is present on devlist, no need for a flag 21.03.00 # I see the point however that reflist doesn't have to contain whole copy of dev info 21.03.59 # yeah, you have less copies, less allocation, less potential for bugs 21.04.15 # the only allocated data (dev list) is ref count so resource management is obvious 21.04.38 # I agree it is conceptually a bit weird at first but in the end I think it's just simpler 21.08.05 # I see it like this: 1) devlist is as now. It is mutex protected and updated by hotplug callback. 2) client builds up a list on opened refs (only refs, no structure copy) and operates on data from devlist (it is mutex protected anyway). 3) ref count is for holding device hwstub_open() ed only when needed. 21.08.11 Quit bluebrother (Disconnected by services) 21.08.16 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 21.08.16 Join fs-bluebot [0] (~fs-bluebo@x5ce24636.dyn.telefonica.de) 21.09.42 # When device is disconnected the entry from devlist is removed by hotplug callback. Next action from client will return HWERR_INVALID_REF since there is no such ref in list. 21.10.43 Quit fs-bluebot_ (Ping timeout: 255 seconds) 21.11.43 # how do you know the ref is not valid anymore ? 21.12.04 # search for node with this ref in devlist will fail 21.20.46 Join TheLemonMan [0] (~lemonboy@unaffiliated/thelemonman) 21.24.48 # I see your point, I just don't like it because it involves searches in two lists for each operation, one of them being mutex protected (and you need the mutex everytime) 21.25.29 # and it works only because you implement with lists, any other implementation (hash map for ref list for example) would basically not work 21.25.58 # but you are the one doing it so if you disagree with me just do it the way you want :) 21.29.38 # You might as well think I'm overthinking this ;) 21.29.54 # (which is kind of true since thinking all day is my job ^^) 21.32.47 # You need to protect global list (or any other book keeping system) with mutex anyway 21.33.42 # only for a few number of operations: open, close and hotplug 21.33.56 # the lists are short (realistically how many devices will be connected at once) and how many clients 21.35.03 # with my scheme, a device cannot disappear from the list as long as a client has opened it thus, thus any other operation is safe. In other words, the list is race-free for reading if you know the device is opened 21.35.19 # yeah I know the lists are short ^^ 21.36.34 # at the cost that you need to check if the node is not in 'disconnected' state on every operation 21.36.37 Quit mirak (Quit: Ex-Chat) 21.36.57 # yeah but that costs nothing 21.37.21 # (compared to the cost of doing a usb operation) 21.38.00 # In my scheme there is no usb operation on disconnected device either 21.38.56 # I think we will not agree on this one :) 21.40.26 # basically the difference is that you want to signal disconnection with flag and I want to signal it with failed search. 21.41.08 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 21.41.18 # since you need to perform search anyway I prefer my solution :-) 21.41.50 # but I only have one search, you have two :-p 21.43.18 # you still need to keep ref list per client, don't you? 21.43.36 # yeah but the list contains pointer to the global list 21.44.09 # ok, now I understand your idea 21.44.37 # yeah I should have said that, it was not obvious from my writing ^^ 21.45.03 # so you want to search only local list, then check validity of pointed node 21.46.42 Nick chardy is now known as chxr (chxr@procasur.inc.cl) 21.46.52 # yes 21.52.02 # that makes sense 21.57.10 Quit nlogex (Quit: WeeChat 1.3) 22.02.06 Join jtdesigns01 [0] (442bb28d@gateway/web/freenode/ip.68.43.178.141) 22.06.46 Quit jtdesigns01 (Client Quit) 22.08.02 Quit FSanches (Quit: Leaving.) 22.08.23 Join jtdesigns01 [0] (~jonathan@2601:400:8000:2669:cc2b:a290:f8f2:ea8a) 22.11.58 Nick krabador is now known as crabador (~krabador@unaffiliated/krabador) 22.22.00 Quit jtdesigns01 (Quit: Leaving) 22.22.23 Join jtdesigns01 [0] (~quassel@2601:400:8000:2669:230:bdff:fe71:cebd) 22.23.20 Quit jtdesigns01 (Client Quit) 22.24.28 Join jtdesigns01 [0] (~ggrt7@2601:400:8000:2669:230:bdff:fe71:cebd) 22.25.01 Quit jtdesigns01 (Client Quit) 22.27.19 Join jtdesigns01 [0] (~quassel@2601:400:8000:2669:230:bdff:fe71:cebd) 22.28.21 Quit petur (Quit: Leaving) 22.37.22 Join michaelni_ [0] (~michael@88-117-73-227.adsl.highway.telekom.at) 22.39.13 *** Saving seen data "./dancer.seen" 22.41.14 Quit michaelni (Ping timeout: 272 seconds) 22.48.07 Join suYin [0] (mysuyin@server2.shellfire.net) 22.53.49 Nick crabador is now known as krabador (~krabador@unaffiliated/krabador) 22.59.38 Quit wodz (Quit: Leaving) 23.01.19 Quit Rower (Ping timeout: 250 seconds) 23.01.51 Join Rower [0] (husvagn@d83-183-134-99.cust.tele2.se) 23.03.01 Quit krabador (Quit: Take The Time) 23.25.25 Quit ZincAlloy (Quit: Leaving.) 23.31.01 Quit amayer (Quit: Leaving) 23.44.29 Quit user890104 (Quit: .) 23.44.39 Join user890104 [0] (Venci@unaffiliated/user890104) 23.52.52 Quit ender` (Quit: There are two types of people in the world: those who can extrapolate from incomplete data.)