--- Log for 08.10.115 Server: sinisalo.freenode.net Channel: #rockbox --- Nick: logbot- Version: Dancer V4.16 Started: 21 days and 19 hours ago 00.00.12 # I think it would be better to somehow "post" the disconnect events to the thread 00.01.19 # Server thread is actually separate process 00.01.36 # But generally I agree with you. 00.02.52 # ah right, hum 00.03.33 # one way I see is to have a list of "pending deletion" 00.04.04 # and the event loop process the deletion before looking at the events 00.04.12 # and you need to protect this by mutexes 00.05.14 # or myabe simpler, if this is possible, have a boolean to say "something change" and on each change, poll each device to see if it's still connected (but I don't know if this information by the libusb API 00.08.50 # But change is caused by unplug. Nothing can save you. 00.09.25 # what do you mean ? 00.09.45 # I hope (and guess) that libusb will just fail if you send a request to a disconnect device 00.10.02 # the problem is that if you free the device in the hotplug event and right after it, use in the thread... 00.10.22 # ah, you mean that it will segfault when callback frees the structure, hmm 00.10.50 # yeah the event loop will access a freed structure, and crash 00.11.23 # i mean this is theoretical but concurrency is always dangerous, you have to think about it long enough to be sure ;) 00.14.06 # There is other possibility. Instead of sharing dev_node_t between dev_list and reflist make it separate copies. Use only reflist one in 'client process'. If request fails check if global copy is still there - if not delete from reflist 00.15.34 # yeah should works too, I like this idea :) 00.16.24 # I think libusb has an error define for disconnected device 00.16.29 # like LIBUSB_ERR_DISCONNECTED 00.17.19 # LIBUSB_ERROR_NO_DEVICE 00.17.23 # just checked ;) 00.17.45 # ok so this should work then 00.19.09 Join jtdesigns01 [0] (~jonathan@2601:400:8000:2669:8534:77a1:38bf:4ff4) 00.19.44 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 00.34.42 Quit wodz (Quit: Leaving) 00.34.51 Quit ender` (Quit: Revised log levels proposal: "fyi," "wtf," and "omg.") 00.38.18 *** Saving seen data "./dancer.seen" 00.47.51 # <[7]> prof_wolfff: just saw your DMA patch 00.48.12 # <[7]> IIRC (and it's been quite a while ago), dma_get_peak_buffer is used by visualization plugins and that kind of thing 00.48.33 # <[7]> it's supposed to return audio data as close as possible to the current playback position 00.49.06 # <[7]> the name probably originates from a VU meter display on the archoses or something 01.03.39 # 7: i need to look closely to this function, IIRC the problem is that the internal double buffer are not consecutive positions, i think i leave it as it because didn't find a place where it is used and test it 01.04.25 # <[7]> I guess some plugins such as vu meter will use it 01.07.17 Quit pamaury (Ping timeout: 240 seconds) 01.09.29 # i see it is used by pcm_calculate_peaks() but cannot find any utility using it, will see at the vu-meter more closely, IIRC i tried it in the past with no problems 01.16.00 # 7: ATM i am testing the vu-meter and it works (apparently) well, anyways i am adding to my TODO list to review the dma_get_peak_buffer() function, it should be used from somewhere... 01.17.36 # or it could be related with SWCODEC 01.20.47 Join [Franklin] [0] (~franklin@unaffiliated/franklin) 01.23.37 # <[Franklin]> can someone merge g#1206 please? 01.23.47 # <[Franklin]> just a bug fix 01.25.13 # * foolsh wonders where our ircbot friend is at tonight? 01.25.54 # ircbot friend? 01.26.14 # <[Franklin]> jtdesigns01: there's usually (sometimes?) a bot in here 01.26.22 # <[Franklin]> called fs-bluebot 01.26.24 # yeah, it's real useful 01.26.46 # he seems to come in and out 01.26.49 # oh, i see 01.27.06 # post a gerrit task number i.e. g#1206 and it will post back useful info and links 01.27.13 # for autocompleting "g#1206" 01.27.18 # ditto 01.27.45 # when a patch is merged it will give build farm stats to 01.28.21 # <[Franklin]> jtdesigns01: how's your SWDF plugin coming along? 01.28.56 # still totally confused about the random "undefined instruction" errors 01.29.30 # <[Franklin]> try building it in the simulator to debug 01.29.40 # <[Franklin]> and if it doesn't build in the simulator, it's a bug! :P 01.30.04 # i dont get any crashes in the simulator 01.30.18 # <[Franklin]> that's a start 01.30.41 # <[Franklin]> try putting some splash instructions at key points so you can narrow down where the crash is then 01.30.54 # brilliant 01.31.13 # jtdesigns01: where is this? I'll build it to and see what comes of it 01.31.19 # * [Franklin] is too lazy to debug any other way 01.31.29 # there is no other way 01.31.32 # ;) 01.31.50 # g#1215 01.31.56 # http://gerrit.rockbox.org/r/#/c/1215/ 01.32.49 # you will have to remove the extra parentheses on line 19 01.33.05 # alright 01.33.35 # i commited before saving. [[facepalm]] 01.33.54 # <[Franklin]> so commit again ;) 01.34.02 # You can push as many times as you need 01.34.13 # yeahyeahyeah 01.34.35 # open this file with it https://web.archive.org/web/20141123172909/http://www.df-21.net/downloads/contests/ovarid.zip 01.34.47 # (its a viewer) 01.35.12 # (not the zip file, the file in it :D) 01.35.30 # <[Franklin]> speaking of which... 01.35.41 # * [Franklin] tossed around the idea of an archive viewer a while back 01.36.21 # okey dokey 01.42.33 # well it builds so there is hope :) 01.46.25 # jtdesigns01: so it flashes something about there being four files and then presents with me with a list SECBASE.(INF,GOL,LEV,O) but I can't seem to do anyhting else 01.47.11 # yeah, just exit and retry a couple of times. 01.47.15 # Ah the third time I run it I get the undefined instruction so that's kind of wierd, 01.48.00 # not releasing some ram properly somewhere maybe? 01.49.16 # is bm.h supposed to be blank? 01.50.01 # its not fully implemented yet 01.50.19 # you don't say :P 01.50.29 # ^ a joke 01.50.38 # lol 01.54.19 # so what is the expected out put? 01.55.28 # at this point it is only supposed to display the list and not crash :) 01.55.56 # after i get the crash fixed, you will be able to click on the entries in the list and view them. 01.56.02 # * [Franklin] takes a look at it 01.56.46 # <[Franklin]> there might be a bug on line 19 01.57.06 # <[Franklin]> oh, never mind 01.57.27 # <[Franklin]> but you still shouldn't assume type sizes, ever 01.58.26 # in my local copy i dont 01.58.32 # will push 01.59.14 # never mind, wont push, its too broken 01.59.31 # too many unfinished changes that didnt work 02.01.08 # <[Franklin]> jtdesigns01: you're also allocating list_array on the stack 02.01.33 # <[Franklin]> that might not be a problem with mastern being small, but as it grows, it could become a problem 02.01.48 # <[Franklin]> the stack size is relatively small in rockbox, 4K IIRC 02.02.16 # yeah it always dies immediately on huge files 02.02.25 # just straight die 02.02.34 # not undefined insatruction 02.02.42 # but that is to be excpectyed 02.03.07 # afk for a little bit will be back 02.06.29 # <[Franklin]> foolsh: I'll get the ducky code commented so it's a bit easier to understand 02.11.21 # <[Franklin]> and add some instructions while I'm at it... 02.23.17 # ok, i`m back 02.23.23 # find anything out? 02.23.26 Quit ps-auxw (Ping timeout: 246 seconds) 02.23.37 # * foolsh will get manual entry ironed out some time in the next week 02.23.46 # * foolsh is off to bed 02.24.04 Quit aevin (Ping timeout: 240 seconds) 02.24.04 # see ya foolsh 02.25.05 Join aevin [0] (eivindsy@unaffiliated/aevin) 02.25.58 # <[Franklin]> \o foolsh 02.29.26 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 02.29.46 Quit uwe_ (Ping timeout: 255 seconds) 02.36.53 Join uwe_ [0] (~uwe_@dslb-088-067-177-159.088.067.pools.vodafone-ip.de) 02.38.21 *** Saving seen data "./dancer.seen" 02.42.45 # [Franklin]: is it possible that I could be somehow using up more ram each time i run my plugin? 02.43.10 # because it often takes a couple of runs before it crashes 02.46.26 # <[Franklin]> try allocating globally and find out 02.46.31 # <[Franklin]> actually, never mind 02.46.37 # allocating globally? 02.46.39 # <[Franklin]> that won't work because it's dynamically allocated 02.46.58 # <[Franklin]> (place it in global scope so it's not on the stack) 02.47.09 # i see 02.47.12 # <[Franklin]> it might be the dynamic alloc that's failing 02.47.30 # <[Franklin]> try writing a malloc function using the plugin buffer 02.47.43 # whew! 02.47.56 # that sounds... interesting 02.48.02 # * [Franklin] has one ready to use 02.48.09 # <[Franklin]> just let my pastebin it 02.48.13 # <[Franklin]> *me 02.48.47 # oh, btw it never crashes before the list in my experience 02.49.24 # <[Franklin]> if that's the case, try narrowing it down more 02.49.40 # <[Franklin]> place splashes on every other line if you have to! 02.49.44 # will do, gonna add some splashes 02.50.00 # lol thx 02.50.50 # <[Franklin]> btw, here's a quick 'n dirty malloc: http://pastebin.com/ELP8L5Yp 02.53.51 # <[Franklin]> should be self-contained 02.54.56 # <[Franklin]> just remove the call to error() 03.26.52 # [Franklin], when the error happens, it happens on the first call to synclist_draw 03.27.51 # <[Franklin]> every time? 03.28.12 # pretty sure 03.28.29 # <[Franklin]> ok, dig deeper! 03.28.40 # yep checking the get name cb now 03.29.07 # <[Franklin]> well, you declared a function inside a function 03.29.10 # * [Franklin] has never seen that before 03.30.05 # <[Franklin]> I don't think it's technically allowed 03.30.17 # <[Franklin]> so you probably shouldn't do it 03.30.34 # <[Franklin]> they're a GCC extension, it seems 03.32.51 # <[Franklin]> try moving it out to global or file scope and test it 03.38.52 # that may actually have solved it 03.39.51 # but now i have to rewrite more stuff out of the main function so that i can dynamically allocate the list_array 03.40.26 # right now i`m just setting it to 200 long 03.44.45 # time for bed now, thanks for the great suggestions 03.45.20 # i will rewrite the necessary parts, and then push sometime tomorrow (hopefully) 03.45.31 # thanks! 03.45.34 Quit jtdesigns01 (Quit: Leaving) 03.51.30 Quit [Franklin] (Remote host closed the connection) 03.59.33 Quit JanC (Ping timeout: 240 seconds) 04.12.20 Join Strife89 [0] (~Strife89@adsl-98-80-221-246.mcn.bellsouth.net) 04.13.03 Join JanC [0] (~janc@lugwv/member/JanC) 04.13.12 Join goom [0] (~go4m@cpe-66-25-153-174.satx.res.rr.com) 04.38.14 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 04.38.23 *** Saving seen data "./dancer.seen" 04.41.27 Quit JdGordon_ (Ping timeout: 250 seconds) 05.10.51 Quit prof_wolfff (Ping timeout: 244 seconds) 05.11.18 Join prof_wolfff [0] (~prof_wolf@89.141.51.203.dyn.user.ono.com) 05.23.01 Quit djukon (Ping timeout: 272 seconds) 05.35.54 Quit [7] (Disconnected by services) 05.36.03 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.46.32 Quit FSanches (Quit: Leaving.) 05.49.50 Join djukon [0] (transitor@gateway/shell/insomnia247/x-dgrvbavwlvqswkvg) 05.51.12 Part djukon 06.04.11 Quit Strife89 (Ping timeout: 272 seconds) 06.07.51 Quit kvieta- (Excess Flood) 06.09.17 Join kvieta [0] (~kvieta@149.255.110.134) 06.38.24 *** Saving seen data "./dancer.seen" 07.13.25 Quit jtdesigns01bot (Ping timeout: 240 seconds) 07.20.20 # prof_wolfff: /* iPod Classic: decrypted hashes for known OFs */ 07.20.23 # /* TODO?: v2.0.1 */ 07.20.36 # does this mean it won't install on 2.0.1? 07.20.49 # my ipod classic 2g has this version 08.02.53 Quit goom (Quit: Leaving) 08.04.36 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 08.27.26 Quit pixelma (Remote host closed the connection) 08.27.26 Quit amiconn (Remote host closed the connection) 08.27.37 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 08.27.42 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 08.34.25 Join ender` [0] (krneki@foo.eternallybored.org) 08.38.25 *** Saving seen data "./dancer.seen" 08.57.31 Join jtdesigns01bot [0] (~jonathan@c-68-43-178-141.hsd1.mi.comcast.net) 09.02.01 Join petur [0] (~petur@91.183.48.77) 09.02.01 Quit petur (Changing host) 09.02.01 Join petur [0] (~petur@rockbox/developer/petur) 09.34.01 Join fs-bluebot [0] (~fs-bluebo@f053153133.adsl.alicedsl.de) 09.40.28 # user890104: i was not sure if 2.0.1 was used by any device, but knowing that i will try to add the hash for 2.0.1 ASAP, i suppose i can use my devices (1G and 3G) to get it, it i can not get it i will ask you to try it on your 2G device 09.40.33 Join pedro_angelo [0] (~pedro_ang@177.179.234.23) 10.38.27 *** Saving seen data "./dancer.seen" 10.47.29 Join ztcptxm1bx [0] (~pedro_ang@177.179.234.23) 10.47.45 Quit ztcptxm1bx (Remote host closed the connection) 10.47.45 Quit pedro_angelo (Remote host closed the connection) 11.17.47 Quit Petri152 (Ping timeout: 264 seconds) 11.18.10 Join Petri152 [0] (~Petri152@petritrebs.ca) 11.58.16 Join FSanches [0] (~felipe@2804:14c:37:268b:7409:d0db:e96a:3912) 12.15.13 # pamaury: (log) I updated g#1222. There is still a lot to do but 1) I realized that fork() creates complete separate copy so global variables can't be shared between so I switched to pthreads and protected devlist with mutex. 2) I hit nasty limitation of hotplug support in libusb. You need to call libusb_handle_events_completed() periodically otherwise events are not passed down to the callback function. 12.15.24 # 3Gerrit review #1222 at http://gerrit.rockbox.org/r/1222 : 3Extend hwstub_server so it can be used as generic backend by Marcin Bukat 12.16.09 # pamaury: (log) I wonder how hotplug worked in qeditor. Maybe making other libusb calls is ok as well. 12.38.31 *** Saving seen data "./dancer.seen" 13.20.39 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 13.25.03 # wodz: you are right, I don't know how it works without calling libusb_handle_events_completed() regularly 13.26.53 # wodz: there is still too much code duplication, this is make it hard to check everything, now there that there is a lot of sync going on 13.29.41 # I need to review this code carefully 13.58.02 # I agree, but I wanted to have logic in place before thinking how to refactor this 14.18.51 Join jtdesigns01 [0] (~jonathan@2601:400:8000:2669:44e0:9b5a:3db7:c548) 14.27.00 Quit FSanches (Excess Flood) 14.27.44 Join FSanches [0] (~felipe@2804:14c:37:268b:7409:d0db:e96a:3912) 14.36.17 Quit utrack (Ping timeout: 240 seconds) 14.38.33 *** Saving seen data "./dancer.seen" 14.39.36 Join utrack [0] (~u@unaffiliated/utrack) 14.56.20 Quit cmhobbs (Ping timeout: 255 seconds) 15.13.32 Join stickyb1t [0] (~egon@msw13.pip.aber.ac.uk) 15.20.14 Quit wodz (Quit: Leaving) 15.22.45 Quit stickyb1t (Ping timeout: 246 seconds) 15.23.41 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 15.26.56 Quit JdGordon (Ping timeout: 256 seconds) 15.39.06 Join amayer [0] (~amayer@mail.weberadvertising.com) 15.57.21 Quit petur (Quit: Leaving) 16.36.11 Quit jtdesigns01 (Remote host closed the connection) 16.38.34 *** Saving seen data "./dancer.seen" 16.46.44 Join ZincAlloy [0] (~Adium@p5B2FD250.dip0.t-ipconnect.de) 16.53.48 Quit [Saint] (Remote host closed the connection) 16.56.00 Join [Saint] [0] (~hayden@rockbox/staff/saint) 17.11.56 Join jtdesigns01 [0] (~Thunderbi@2601:400:8000:2669:b4fe:516a:6cd7:1d55) 18.04.53 Quit uber (Ping timeout: 265 seconds) 18.12.45 Join stickyb1t [0] (~egon@msw13.pip.aber.ac.uk) 18.17.44 Quit stickyb1t (Ping timeout: 240 seconds) 18.21.05 Join uber [0] (~uber@unaffiliated/uber) 18.38.37 *** Saving seen data "./dancer.seen" 18.41.10 Join stickyb1t [0] (~egon@msw13.pip.aber.ac.uk) 18.50.17 Join petur [0] (~petur@rockbox/developer/petur) 18.55.29 Quit stickyb1t (Ping timeout: 240 seconds) 19.06.03 Quit pamaury (Ping timeout: 246 seconds) 19.10.48 Join ps-auxw [0] (~arneb@p50875EF1.dip0.t-ipconnect.de) 19.20.26 Quit orly_owl (Quit: leaving) 19.22.01 Join orly_owl [0] (~david@unaffiliated/orly-owl/x-3167833) 19.22.24 Join krabador [0] (~krabador@unaffiliated/krabador) 19.33.37 Quit shamus (Read error: Connection reset by peer) 19.34.23 Join shamus [0] (~shmaus@ip-206-192-194-12.marylandheights.ip.cablemo.net) 19.36.39 Quit shamus (Read error: Connection reset by peer) 19.37.04 Join shamus [0] (~shmaus@ip-206-192-194-12.marylandheights.ip.cablemo.net) 19.55.27 Join stickyb1t [0] (~egon@avondaleaber.plus.com) 20.04.50 Quit stickyb1t (Quit: Konversation terminated!) 20.05.04 Join stickyb1t [0] (~egon@avondaleaber.plus.com) 20.06.52 Quit stickyb1t (Read error: Connection reset by peer) 20.38.40 *** Saving seen data "./dancer.seen" 20.39.47 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 20.48.03 Quit krabador (Quit: Take The Time) 20.57.54 Join lebellium [0] (~chatzilla@89-93-179-187.hfc.dyn.abo.bbox.fr) 21.06.50 Join krabador [0] (~krabador@unaffiliated/krabador) 21.07.47 Quit bluebrother (Disconnected by services) 21.07.52 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 21.08.06 Join fs-bluebot_ [0] (~fs-bluebo@x5ce7793b.dyn.telefonica.de) 21.10.25 Quit fs-bluebot (Ping timeout: 250 seconds) 21.11.22 Join bp0 [0] (~bp@unaffiliated/bp0) 21.13.43 Quit krabador (Ping timeout: 256 seconds) 21.15.50 Join krabador [0] (~krabador@unaffiliated/krabador) 21.16.45 Quit bp0 (Quit: Leaving) 21.16.47 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 21.24.53 Join o43 [0] (~antonio@c-50-167-171-132.hsd1.ga.comcast.net) 21.45.46 Quit krabador (Quit: Take The Time) 21.54.45 Join krabador [0] (~krabador@unaffiliated/krabador) 22.11.31 Quit bertrik (Remote host closed the connection) 22.11.41 Quit o43 (Quit: Lost terminal) 22.30.42 Quit FSanches (Quit: Leaving.) 22.30.48 # <[Saint]> prof_wolfff: you around hun? 22.31.23 # <[Saint]> Sorry. Nevermind. 22.38.42 *** Saving seen data "./dancer.seen" 22.53.52 Join stickyb1t [0] (~egon@avondaleaber.plus.com) 22.54.34 Quit stickyb1t (Client Quit) 22.55.05 Join stickyb1t [0] (~egon@avondaleaber.plus.com) 22.56.44 Quit ender` (Quit: You do not need a parachute to skydive. You only need a parachute to skydive twice.) 23.07.56 Quit petur (Quit: Leaving) 23.26.31 Quit krabador (Quit: Take The Time) 23.30.17 # <[Saint]> Why is it that only the iriver H* have automatic gain control enabled? 23.30.47 # <[Saint]> Is this hardware dependent (it doesn't /appear/ to be...? 23.31.20 # [Saint]: no idea 23.32.02 # <[Saint]> This mess and confusion might be the kicker I need to finally do a proper target define template 23.32.38 # <[Saint]> the way we handle (or rather, the way we absolutely, completely, and totally do not handle...) defines in the source tree is rather annoying. 23.33.41 # which define controls AGC ? 23.33.57 # <[Saint]> just a brief look seems to suggest that there's several defines with very similar, or even identical functions, that could be condensed. 23.34.05 # <[Saint]> ummmm, HAVE_AGC 23.34.57 # <[Saint]> grep tells me that it's only actually used by the iriver H* 23.35.16 # <[Saint]> But, offhand, I can't seem to find any reason /why/ this is so. 23.35.56 Quit stickyb1t (Read error: Connection reset by peer) 23.36.12 Join stickyb1t [0] (~egon@avondaleaber.plus.com) 23.36.36 Quit stickyb1t (Client Quit) 23.37.08 # <[Saint]> Touching every single target config, and pretty much every area of the source, isn't ideal - and it's not necessarily something I /want/ to do...but I think it's high time that we had a nice template for new ports with nicely sectioned out defines. 23.37.56 # <[Saint]> Doing so would also give me a chance to clean them up and make sure they are applied in a uniform fashion. 23.38.33 # <[Saint]> Hmmm. 23.38.58 # it is not unlikely that there is target specific code in recording.c 23.39.14 # <[Saint]> I might wrap a little ncurses UI around a script to generate target templates. 23.39.54 # <[Saint]> Is uniform and consistent target configs a thing that people might want? Or is it not worth stepping on everything for the sake of a little (a lot, really) more readability? 23.40.46 # <[Saint]> You can trace the source backwards in a few areas where cutting and pasting target define blocks has backfired on people. 23.44.13 # rather than a ncurses UI, I think the first work would be to have a template config with the list of ALL possible defines (which are not target specific of course) with a description of what it does 23.44.59 # it is also quite possible that some define are not independent and could be simplified but that's a major work I think 23.46.03 # <[Saint]> Ah, yes, I should probably stop assuming that people are aware of my thought process. 23.46.34 # <[Saint]> Yes. The aformentioned massive list of all possible defines is indeed a prerequisite of the ncurses wrapper I was thinking of. 23.47.46 # <[Saint]> If you get the time to look at this, even though I know it's not your particular area of expertise, it would be nice if someone could either confirm or deny my suspicion that there's no obvious good reason for automatic gain control to be disabled on everything except the irivers. 23.48.08 # <[Saint]> I understand that is a reasonably big ask, but I would sincerely appreciate it. 23.48.41 # <[Saint]> I can follow most of the code in recording.c, but there's a few blocks I'm not entirely sure of. 23.49.11 Quit amayer (Quit: Leaving) 23.49.19 # <[Saint]> tracking just HAVE_AGC gives me no reason to believe it should be hardware/device dependent. 23.50.47 # <[Saint]> It almost seems as though it was just entirely forgotten about. 23.51.23 # yeah, I was never aware there was AGC for recording ^^ 23.51.34 # HAVE_AGC isn't the most informative define 23.51.44 # <[Saint]> Nor was I until about ~10 minutes ago. 23.51.53 # I guess the trivial check is to try and add HAVE_AGC to a random target and see if it compiles/work 23.52.03 # * [Saint] nods 23.52.07 # <[Saint]> Doing that now. :) 23.53.57 # <[Saint]> I discovered this by accident adding a define for supplying a fake USB vendor/product ID for the iPods 23.54.08 Join [Franklin] [0] (~franklin@unaffiliated/franklin) 23.54.36 # * [Saint] knows how to define definite defines 23.54.40 # <[Saint]> #define USB_USE_ALTERNATE_VID_PID 23.54.48 # <[Saint]> ...no one's going to ask what that does. 23.55.00 Quit lebellium (Quit: ChatZilla 0.9.92 [Firefox 42.0/20151005144425]) 23.55.12 # <[Saint]> (and, yes, I do realize that this is never going to make it into mainline) 23.55.13 # <[Franklin]> lol 23.55.36 # <[Franklin]> so what's the point then? 23.56.38 # <[Saint]> I've been supplying custom builds for ipod6g for an eternity. Just making life a bit easier on myself. 23.57.17 # <[Saint]> Essentially just to combat USB car audio and Apple Mac devices that are "too smart" for their own good. 23.57.24 # <[Franklin]> so there's no "generic" VID/PID combo out there? 23.57.30 # <[Saint]> No.