--- Log for 18.11.120 Server: barjavel.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 11 days and 14 hours ago 00.04.22 # speachy: i found something stupid while looking through MTP sources. apparently MTP responders are expected to allocate 3 usb endpoints but the interrupt one isn't actually used that i can tell. but you still need it to be detected as an MTP endpoint by clients like libmtp. 00.05.48 # at least that tells us that MTP will only work on the same targets that also support HID 00.06.26 # i'm probably going to develop MTP using PP devices 00.06.42 # seems unlikely any coldfire will support it due to missing hardware or so? 00.09.26 *** Saving seen data "./dancer.seen" 01.15.52 Join karinka [0] (~karinka@n114-75-91-109.bla3.nsw.optusnet.com.au) 01.18.09 Quit pixelma (Quit: .) 01.18.09 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 01.19.19 Join amiconn [0] (jens@rockbox/developer/amiconn) 01.19.19 Join pixelma [0] (marianne@rockbox/staff/pixelma) 01.28.46 Quit karinka (Quit: karinka) 01.28.54 Join karinka [0] (~karinka@n114-75-91-109.bla3.nsw.optusnet.com.au) 01.30.24 Quit karinka (Client Quit) 01.31.44 Join karinka [0] (~karinka@n114-75-91-109.bla3.nsw.optusnet.com.au) 01.33.20 Quit karinka (Client Quit) 01.33.49 Join karinka [0] (~karinka@n114-75-91-109.bla3.nsw.optusnet.com.au) 02.09.27 *** Saving seen data "./dancer.seen" 02.24.57 Join kugel [0] (~kugel@ip5b40cea7.dynamic.kabel-deutschland.de) 02.24.58 Quit kugel (Changing host) 02.24.58 Join kugel [0] (~kugel@rockbox/developer/kugel) 02.28.14 Quit St3ak (Ping timeout: 264 seconds) 02.34.24 Join St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net) 02.53.11 Join petur [0] (~petur@rockbox/developer/petur) 02.56.06 Quit karinka (Quit: karinka) 02.56.19 Join karinka [0] (~karinka@n114-75-91-109.bla3.nsw.optusnet.com.au) 03.20.16 Quit karinka (Quit: karinka) 03.20.17 Join karinka [0] (~karinka@n114-75-91-109.bla3.nsw.optusnet.com.au) 03.22.24 Join ender| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3) 03.30.07 Quit karinka (Quit: karinka) 03.30.15 Join karinka [0] (~karinka@n114-75-91-109.bla3.nsw.optusnet.com.au) 03.31.03 Quit ufdm (Read error: Connection reset by peer) 03.31.16 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) 03.34.27 Join prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net) 03.38.36 Quit prof_wolfff (Ping timeout: 240 seconds) 03.39.01 Quit ufdm (Quit: Leaving) 04.09.29 *** Saving seen data "./dancer.seen" 04.33.57 # speachy: any idea what the wikipedia page on the H300 is talking about? 04.34.25 # https://en.wikipedia.org/wiki/Iriver_H300_series 04.34.31 # North American models can be modified to support USB OTG by means of a small internal soldering job, an external modified cable, or a USB transfer box. International firmware is also required. 04.34.45 # No specifics about what it means. 04.50.19 Join ubervison [0] (~ubervison@2a02:aa12:b106:1b80:4978:337a:24bd:4bbc) 06.09.31 *** No seen item changed, no save performed. 06.12.57 Quit CommunistWitchDr (Ping timeout: 272 seconds) 06.17.43 Quit Stanley00 (Remote host closed the connection) 06.19.25 Quit Moarc (Ping timeout: 264 seconds) 06.27.36 # oh. so that's what's going on. 06.27.47 # no-one implemented the usb otg driver for the H300. 06.28.16 # i wonder why. 06.28.26 # well that's one feature missing. 06.28.38 # so it is incomplete in this sense 06.28.48 # as it stands the media/host port is useless 06.29.58 # A lot of work for not *that* much useful results 06.30.45 Join SovietShaman [0] (quassel@024-217-039-226.res.spectrum.com) 06.31.28 # gevaerts: i guess so. 06.31.38 # i'll add it to a list of stuff i might try though. 06.31.48 # but it just means i can't use my h300s for testing usb stuff. 06.32.11 # main point of it would be MTP support 06.32.20 # but, chicken or the egg? 06.32.29 # i'll get MTP support working on other OTG targets first 06.33.51 # If it *actually* does proper OTG. My impression has always been that in marketing "OTG" means "Host on a thing you'd normally think of as device". Not sure though 06.34.14 # Also, I *think* that one is actually restricted to full speed? 06.35.26 # gevaerts: no idea. i'll test MTP on my unmodded H320. 06.35.34 # if it is then it'll be super slow 06.35.48 # the chip it uses claims to support 2.0 06.36.09 # just i'd like to make it work if possible since the OF had it 06.36.20 # but i can see why it is absent 06.36.38 # when the first driver was implemented there was nothing to really use it yet in RB usb stack 06.36.57 # but now there is, the HID driver 06.37.09 # which was implemented in 2009 it appears 06.37.34 # https://www.rockbox.org/wiki/UsbOnTheGoSupport has some details 06.37.44 # 2.0 != high speed 06.37.54 # gevaerts: i saw it earlier. i'll look into it later. 06.38.03 # The host and device 06.38.03 # controllers are compliant with Universal Serial Bus Specification Rev. 2.0, supporting 06.38.06 # data transfer at full-speed (12 Mbit/s) and low-speed (1.5 Mbit/s). 06.38.10 # but you're right. if that's all it can do 06.38.11 # (from the chip data sheet) 06.38.17 # not much point 06.38.22 # it's slower than the data port 06.39.11 # I think OTG is one of those areas where speed and spec versions aren't as correlated as in the rest of USB, as in OTG was defined in the 2.0 era, not in the 1.1 era 06.39.42 # It's been a *long* time since I did USB... 06.39.54 # wow. it won't even do 2.0 speeds. 06.40.00 # so why did iriver bother with it? 06.40.10 # it's pretty useless if it can't do 2.0 speeds 06.40.28 # i can see now why no one bothered 06.40.29 # Didn't you need MTP for some DRM stuff? 06.40.36 # yea, windows DRM. 06.40.42 # playsforsure. 06.40.46 # all pointless now though. 06.40.53 # Maybe they had plans involving that? 06.41.04 # they implemented it in the US firmware 06.41.07 # but nowhere else 06.41.24 # hm. 06.41.34 # if i get bored i might work on it but i can see now why it was low priority. 06.41.43 # it's only useful for low bandwidth use cases. 06.42.26 # Of course if you get the host side working you can attach HID devices to it, which would be useful. I mean, surely doom plays better with a proper keyboard :) 06.42.52 # if you're going to do that you may as well just use a real PC 06.42.57 # no seriously... lol 06.44.36 # so the OTG on this is of limited interest 06.44.42 # i can see now why it was never finished 06.44.48 # hm 06.47.22 # I think petur was involved in that? Maybe he still remembers some of the context 06.47.57 # It was before my time though. I came in with USB on the PP502x targets 06.48.13 # no idea 06.48.18 # doesn't matter for now 06.48.42 # i just laugh at retaining DRM support on these anyway 06.48.52 # the service was shut down ages ago so it doesn't matter anymore 06.49.40 Join Moarc [0] (~chujko@a105.net128.okay.pl) 06.50.21 # yeah, I looked at it, you can find pictures of one of the first devcons where I´m figuring out the connections ;) 06.51.00 # petur: ah. i was just coming along to pick up the pieces to make the h300 a better port. 06.51.03 # so to speak 06.51.34 # it appears the h300 has 2 hardware revisions that make OTG work differently 06.51.36 # I have some sample driver code I got from the manufacturer even (mailed them at the time) 06.51.45 # i see. 06.51.50 # is that on the wiki? 06.52.07 # the problem was 1) I was just getting back into embedded at that time and 2) I knew nothing of USB 06.52.21 # karinka, thanks for the offer; the h2 is in reasonably decent shape, but auditing/fixing keymaps and writing the device-specific stuff for the manual needs to be done. There ar e a few platform-level quirks too. 06.53.08 # I have most sitting on my NAS drive, not sure what made it to the rockbox site... 06.53.14 # anyway i was planning to look into adding OTG support for the H300 later on 06.53.22 # petur: can you look for it sometime? 06.53.34 # right now i'm focused on trying to implement MTP 06.53.42 # which i already have stuff i can test it with 06.53.54 # and honestly OTG is of limited use without more stuff to use it really 06.56.42 # braewoods: https://www.rockbox.org/wiki/UsbOnTheGoSupport at the bottom has the sample code 06.57.32 # I´ll try to look if I have any other stuff tonight 06.58.06 # petur: ok. good. thanks. 07.01.19 # np 07.04.23 # though seems even with OTG rockbox is limited to slave role 07.04.49 # the stack isn't setup for host 07.04.57 # yep. 07.05.04 # just OTG enables more slave roles? 07.05.12 # seems to be the case 07.05.48 # no reason why it can't be done; it's just nobody saw the point in implemting the master/host side of the stack (and the various protocols on top) 07.06.05 # and what would be the use case? 07.06.16 # rockbox is primarily targeted to a slave role 07.06.18 # as it stands 07.06.18 # plugging in external storage is the main one 07.06.34 # using an external DAC (all the vogue these days) 07.06.54 # hm 07.07.18 # those features are already there "For free" for the hosted platforms. 07.08.08 # well i'm honestly not interested in the complexity of developing a host stack... 07.08.17 # for native targets 07.08.56 # i have to ask though. did any of the OFs for these devices with OTG ever support being connected as a host? 07.09.06 # not counting hosted 07.09.09 # or Linux based ones 07.09.13 # not that I recall. 07.09.33 # as i thought. most of them seem to only take the slave role. 07.10.09 # not surprised honestly 07.10.22 # they were mainly intended as an extension of your PC, MAC, or other host 07.11.11 # i have an idea for other slave roles 07.11.23 # but we may need a way to regulate how much we expose at once 07.11.50 # some of these chips have a limited # of endpoints and i could see us exhausting that if we try to do too much at once 07.12.36 # speachy: i could see adding usb audio which would let the PC output to the audio ports that the RB device has 07.12.47 # passthrough or so 07.13.05 # braewoods: g#1009 07.13.05 # but not sure what else would be practical 07.13.07 # Gerrit review #1009 at https://gerrit.rockbox.org/r/c/rockbox/+/1009 : Add USB Audio 1.0 support (EXPERIMENTAL) by Amaury Pouly 07.13.12 # oh. 07.13.16 # lol 07.15.10 # i guess since many of them used OTG style usb connectors 07.15.20 # err 07.15.22 # didn't use 07.15.27 # anyway 07.16.12 # hmm. I need to see what it will take to enable C++ in our toolchains. 07.16.37 # why would we need C++? 07.16.44 # i thought rbutil was all that used it 07.17.59 # primarily for the hosted targets where c++ libraries are more common 07.18.05 # Oh. 07.18.32 # i just know from using C++ that it has problems being used in embedded 07.18.52 # the automatic behaviors it has can cause a lot of headaches. 07.19.03 # yeah, it's not ideal. but if it lets us reuse stable code, that's a net win. 07.19.28 # i think arduino gets away with it because they throw away the entire standard library to use their own 07.19.42 # so they can tweak what automatic behaviors get used in classes 07.19.49 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 07.20.12 # i think you'd have to do that in any case to develop with it in embedded 07.20.28 # simply because you don't want it trying to be clever and screwing you over 07.22.44 # Hmmm, I'm vaguely remembering something about the Gigabeat F having host if you have a dock... That might be high speed. 07.23.26 # the USB-IF really, really jumped the shark when it came to naming and figuring out what is supported. 07.23.43 # USB 2.0 was quasi-sane, but everything since then has been a dumpster fire 07.25.11 # USB "2.0" features are indepdenent of high speed; but every 2.0-capable USB interface I've seen actually supports high speed -- but typically requiring an external PHY to do it. Which often/usually isn't necessary. 07.28.24 # hm 07.28.29 # mtp sure supports a lot of stuff we don't need 07.28.55 # like misc. metadata options 07.29.04 # mainly want MTP for file control and that's it 07.36.34 # which reminds me... I should be distributing some hardware to maintainers of iRiver: remotes, cases and an H10. Maybe also my h380 07.41.29 # petur: there was an iriver h380? 07.42.25 # the units i got i had to buy on ebay. i used them to help produce a new set of bootloaders because they really needed them. 07.42.27 # yeah, a 340 with a bigger disk (installed myself) 07.42.31 # Oh. 07.42.33 # I see. 07.42.37 # :) 07.42.55 # I couldn't test on the H100 though since it's super rare 07.43.01 # is that one of your units? 07.43.08 # one of the H110 or so 07.43.21 # i only have H120s and H320s 07.43.43 # yeah but I´m hanging on to it because it is my only device that can record off optical 07.44.11 # if you have a H110 still i'd ask you to test the new bootloader on it 07.44.28 # I tested the related bootloader, H120. 07.44.45 # it works fine but i can't test the H100 one because the hardware is so hard to find 07.45.07 # same with H320 07.45.35 # https://forums.rockbox.org/index.php/topic,53654.0.html 07.45.42 # checked, I have an h120 07.45.45 # Oh. 07.45.50 # Ok then nevermind. 07.45.57 # I figure the H100 is just unpopular. 07.46.08 # can't say i'm surprised. it was a smaller unit. 07.46.15 # the people who bought these wanted more space. 07.46.47 # the fact the H300 only came in 20+ GB units makes me think the H100's 10/15 GB didn't sell well. 07.46.59 Quit Stanley00 () 07.47.49 # petur: do you have any of the rare H300 remotes in your collection? 07.48.07 # i read reports that they work but impossible to test them 07.48.07 # I have two: with and without display 07.48.23 # they can go too 07.48.25 # so you have both of them? 07.48.28 # yup 07.48.33 # how rare. 07.48.45 # if you feel up to it, i'd like to confirm that they work properly with modern RB builds 07.48.51 # i don't know if i even live near you lol 07.49.35 # well... I was part of rockbox dev team and focussed on iRiver, so... ;) 07.49.51 # i'm mostly coming along later to pick up the pieces 07.49.56 # where are you located? 07.50.03 # north america 07.50.11 # Belgium here 07.50.15 # ah, i figured. 07.50.40 # you can just test it. i don't think i'll need it. i only could find the more common H100 remotes though. 07.51.03 # I'm pretty sure there's a wiki page that lists devices with who has one. Hopelessly outdated of course, but if I could remember what that page was, it might still help with tracking down a H100 07.51.38 # it would help, gevaerts, but if it's this hard to find it may not be practical enough to matter 07.52.02 # the most common unit in the H100 series i see show up for sale is the H120 07.52.12 # H140 is rarer but i still see it sometimes 07.52.15 # H100 is the rarest 07.52.21 # i've never seen one to date 07.53.40 # hm 07.53.52 # https://www.rockbox.org/wiki/RockboxTesting 07.53.57 # No H110 though 07.55.21 # i did finally find an hdd6330 unit after a few months of searching 07.55.32 # it was mislabeled as an hdd1630 07.55.32 # I see I forgot to add my H120 07.56.06 # i found the hdd6330 interesting due to how it has so much RAM 07.56.11 # 64M 07.57.21 # anyway my bootloader project is complete it appears 07.57.42 # at least until the next step can be realized 07.58.20 # petur: i gotta thank whoever added the reset cookie to the crt0.S code 07.58.30 # it allowed me to fix the H300 bootloader 07.58.38 # it saved my unit from being bricked 07.59.26 # heh, I once bricked mine, gave it to Linus for reflashing (soldering) and got it back a few years later :) 07.59.57 # but that was me in a hurry flashing the wrong file 08.07.38 # petur: yea. i don't think anyone could easily undo it today. 08.07.43 # the tools are much rarer. 08.08.01 # so it's good the bootloader has rescue code 08.08.20 # it can boot the OF or the rockbox rom image 08.08.44 # though now that i think about it 08.08.58 # the rockbox rom image is useless for recovering from a bad flash 08.09.07 # since you can't flash while booted from ROM 08.09.26 # so still should use the OF 08.09.34 *** Saving seen data "./dancer.seen" 08.09.42 # but 08.09.47 # boot from rom, ROLO the ram binary, and then flash? 08.09.47 # i guess you can use it to do rolo 08.09.50 # yea 08.10.31 # that's why i saw no point in adding support for the RAM image there 08.10.37 # When flashing, always make sure to check both the file and the device 08.11.00 # gevaerts: iriver_flash does most of that. the main thing it can't do is test if it still can boot. 08.11.13 # Otherwise you end up like me, with a bricked bluetooth controller, because somehow that wasn't compatible with the experimental firmware I tried to send to this meizu device :) 08.11.43 # i refactored iriver_flash and added some more sanity checks the original author never had 08.12.01 # like checking the rockbox image to make sure it matches the expected model string 08.12.13 # useful for making sure they aren't mixing h100, h120, h300 builds up 08.12.23 # though unlikely it could save someone's bacon 08.13.19 # the bootloaders are already protected by the checksum table so it won't do much for that but it does validate the RAM/ROM images 08.13.21 # :) 08.15.16 # speachy: something else that occurred to me. MTP could be useful to exfilitrate debugging information over USB. 08.15.38 # it is rather vague about resources so we could define some for exporting other info. 08.18.11 # i'll see if i can find a mtp library that handles most of the hard work 08.18.26 # why reinvent the wheel if there's one that can be reworked a bit? 08.19.16 # trouble is most are heavily tied to their intended environment 08.20.06 # Well, that could work. We do have USB serial debugging though if you want that sort of thing today :) 08.20.17 # just an idea i had for now. 08.20.28 # right now i just care about uh 08.20.36 # getting this to work 08.20.39 # for its main purpose 08.21.35 # Main purposes are boring :) 08.21.51 # indeed. 08.22.03 # still it would be interesting to expose other things as MTP resources 08.22.15 # like the current ROM image 08.22.19 # on some targets 08.23.02 # implement a CDC interface and stream debug data out that 08.23.28 # * gevaerts never installed debian on a laptop from a rockbox device with experimental USB code that exported a disk image! 08.24.21 # speachy: that's there though 08.24.42 # oh? we have a CDC/serial-over-usb interface? 08.24.48 # speachy: usb_serial 08.24.53 # (how did I miss that?) 08.24.56 # i saw it when i was poking around 08.25.02 Quit mutax (Read error: Connection reset by peer) 08.25.03 # firmware/usbstack/usb_serial.c 08.25.45 # And of course calls to that in firmware/logf.c 08.26.02 # You need USB_ENABLE_SERIAL 08.26.23 # ah, I see that now 08.28.53 # I'm going to add that to the configure advanced options. 08.30.07 # Maybe test if it still works first :) 08.31.02 # pfft, if it compiles that means it works, right? 08.31.31 # though it obviously won't work on any of these newfangled hosted targets 08.31.36 # You make some excellent points there! 08.32.05 Join prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net) 08.34.05 # from reading the MTP spec it's probably possible to achieve async operations... but only if you support multiple sessions or so 08.34.41 # we're probably only going to support single session due to limited resources 08.44.14 Join mutax [0] (~mutax@ip5f590aa6.dynamic.kabel-deutschland.de) 08.44.45 # well, it builds on everything I have here 08.49.56 # with one fix for hosted targets 08.53.05 # Build Server message: New build round started. Revision 7c87467, 293 builds, 9 clients. 09.04.40 # we could start incorporating C11 stuff into RB if useful 09.04.46 # namely _Generic or _Static_assert 09.16.34 # Build Server message: Build round completed after 1410 seconds. 09.16.42 # Build Server message: Revision 7c87467 result: All green 09.24.30 Quit speachy (Quit: WeeChat 2.9) 09.25.41 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 09.26.32 Join speachy [0] (~speachy@209.2.65.77) 09.32.15 # how big of an issue are the changes in 3035? 09.33.36 # pretty minor I'd think. 09.33.57 # can I commit it as is? 09.33.58 # well, the manual is now the last holdout for swcodec/lcd_bitmap stuff 09.34.27 # don't see why not 09.35.19 # Build Server message: New build round started. Revision 0aa7028, 293 builds, 9 clients. 09.35.57 # btw the way gerrit handles timeing out is irritating. 09.38.23 # I think the underlying issue is some sort of www server or tcp stack configuration I haven't quite figured out 09.51.46 # Build Server message: Build round completed after 987 seconds. 09.51.49 # Build Server message: Revision 0aa7028 result: All green 09.51.53 # Build Server message: New build round started. Revision 473aa61, 293 builds, 9 clients. 09.59.07 # how do I make a new wiki page? 10.01.59 # type in an unknown page (/wiki/SomeNewPage) or on an existing page, create a reference to the new page (basically any CamelCase word is treated as such) and then click on the link that gets created. 10.02.17 # thanks 10.05.18 # speachy: seems rb has partial support for utf16/ucs2... but decode only 10.05.44 # but realistically we need it to support mtp fully 10.05.57 # unless 10.06.02 # fat32 has no unicode? 10.06.14 # fat32 doesn't care one way or another 10.06.38 # it's easy to encode ASCII as utf16 10.06.44 # just not sure how we'd handle the rest 10.07.10 # Build Server message: Build round completed after 918 seconds. 10.07.15 # Build Server message: Revision 473aa61 result: All green 10.08.16 # wait, does mtf say "utf-16" or "ucs-2"? 10.08.27 # let me look 10.08.42 # utf16 <->utf8 is straightforward. 10.08.58 # Strings in PTP (and thus MTP) consist of standard 2-byte Unicode characters as defined 10.08.59 # ucs-2 is 16-bit only, and thus is at best a subset of utf-16/utf-8 10.09.00 # by ISO 10646. 10.09.15 # that's all it says 10.09.36 *** Saving seen data "./dancer.seen" 10.10.07 # it's UCS 10.10.08 # since it says "2-byte" that's nearly guaranteed to be UCS-2 10.10.43 Quit prof_wolfff (Ping timeout: 260 seconds) 10.10.59 # utf16 was added later in an amendment. 10.11.41 # we could probably get by with just BMP support 10.11.42 # fwiw, it looks like at least the andtoid mtp code actually implements utf16. 10.11.44 # https://android.googlesource.com/platform/external/libmtp/+/refs/heads/ics-plus-aosp/src/unicode.c 10.16.37 # <_bilgus__> hmm that could be handy in lua 10.16.51 # it appears rbunicode already does what i need 10.17.12 # unless that's somehow wrong? 10.19.23 # yeah, handling the BMP must suffice, because that's all that can be done with MTP. 10.19.41 # could we reuse utf16 for ucs2 10.19.49 # support for that is in RB unicode already 10.20.12 # we could; the question is what the MTP initiator supports. 10.20.29 # i'll see what libmtp does 10.20.49 # (I'd be surprised if anything widely deployed doesn't support UTF-16) 10.21.27 # libmtp uses ucs2 10.21.29 # so 10.21.33 # via iconv 10.21.51 # so we'd need our own routine 10.22.01 # I wound't personally bother at this point. 10.22.20 # i'll look into it later but i'd copy it from somewhere else honestly 10.22.28 # as long as the license is GPL compatible and documented 10.27.40 # Oh. 10.27.52 # utf8encode / utf8decode works in terms of ucs2 10.27.54 # great 10.27.56 # we already got it 10.37.17 # does anyone know if the IAUDIO X5 joystick does diagonals? 10.46.27 # speachy: i think i'm going to only go for MTP storage stuff but i have some ideas for how i will abstract it at all 10.46.58 # i'm thinking of making MTP api internally to allow for different implementation of storage options 10.47.05 # not just the obvious one 10.47.18 # okay, I managed to get approval to come into the $dayjob lab to perform "maintainence" 10.48.11 # would be a good time to do upgrades on my server too, which means.. downtime. 10.58.35 Quit _bilgus__ (Remote host closed the connection) 10.59.41 Join _bilgus__ [0] (~bilgus@2605:a000:1301:89f6:71ab:2e9f:7f39:8176) 10.59.44 # <_bilgus__> mendel_munkis, no clue but you can add the button code to debug menu (if not already there) and see if it does multi press 11.01.06 # <_bilgus__> https://gerrit.rockbox.org/r/c/rockbox/+/2967/1/firmware/target/hosted/agptek/debug-agptek.c 11.02.49 Quit massiveH (Quit: Leaving) 11.10.46 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 11.19.08 # interesting. 11.19.19 # the H300's OTG chip has a driver for the linux kernel 11.19.22 # that may be useful 11.20.46 # _bilgus__: I had to ask because I don't have one. I am trying to make a set of kemaps and knowing what key combos are available across targets is the first set. (but thanks for the advoce regardless) 11.22.03 Quit _bilgus__ (Remote host closed the connection) 11.22.35 # key combos in general are... not something that can be assumed. 11.25.51 Join _bilgus [0] (~bilgus@2605:a000:1301:89f6:71ab:2e9f:7f39:8176) 11.30.55 # on targets with enough keys that can be worked around 12.09.37 *** Saving seen data "./dancer.seen" 12.34.03 Quit petur (Quit: Connection reset by beer) 12.39.29 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 12.43.44 # I also have a iriver H20, it's kinda dead 12.43.58 # The HDD works, just needs a new battery 12.44.11 # *H320 12.44.32 # Which should be coming soon 12.46.34 # karinka: well i released an updated bootloader that enables some new stuff that used to be H100 exclusive. 12.47.11 # it seems the h300 is only missing one thing to be complete at this point 12.47.14 # OTG support 12.49.10 # karinka: which means you can probably CF mod your h320 now if you wanted 12.52.51 # karinka: so what issues with the H2 did you run into? 12.54.30 Quit lebellium (Quit: Leaving) 12.58.33 # Still new to IRC so bear with me 12.59.16 # If you go from playing a song via a file, then switch to a song via the database, the song stops and I have to restart the player 12.59.24 # It crashes 12.59.32 # what build? 12.59.54 # The latest dev one i think 13.00.13 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 13.00.14 # i'll try it with mine 13.03.45 # probably the audio buffer underrunning and not recovering 13.04.13 # not happening on my h320 13.04.20 # karinka: can you describe the exact process? 13.04.33 # no, it's going to be a problem with the hiby-based hosted targets 13.04.47 # oh 13.04.53 # it's not about the H320 13.04.55 # i see 13.05.32 # hang on ill put a fresh copy on it 13.06.25 # gotta find my m3k first 13.18.58 # Okay I can't reproduce it with a fresh install, it must have something to do with my settings 13.19.23 # database reinit? 13.20.00 # still, this does seem to indicate that there's still a playback underrun scenario that's not recoverable 13.20.58 # (and ratehr than try to find and hack in a workaround, I'd rather just push playback buffer refilling into a separate thread) 13.21.32 # kinda interesting. the OTG on the H300 sucks but... it at least has a chance of being supported 13.21.47 # sucks? 13.21.49 # the OTG for the other coldfire targets either don't exist or have a totally undocumented chip 13.21.56 # karinka: it's limited to usb 1.1 13.22.03 # so it's going to be slow 13.22.24 # ah, well yeah its old 13.22.34 # oddly enough some stuff around same era support 2.0 13.22.48 # so... yea 13.23.07 # the h300 is a weird one. it supports OTG on a separate USB port. 13.23.14 # do you have a good resource on how to do the CF mod for the H320? 13.23.26 # https://www.rockbox.org/wiki/CFModGuide 13.23.40 # it's not specific but it tells you what you need. 13.24.00 # the h320 like the h120 uses a 50 pin adapter 13.24.07 # 50 pin hard drive 1.8" 13.24.07 # Excellent, exactly what I need 13.24.16 # Thanks 13.24.18 # so you need an adapter 13.24.31 # just uh note, all the adapters i could find in recent days have a jumper 13.24.35 # that sticks up 13.24.43 # that will cause problems when you go to reassemble 13.24.56 # and you need the jumper set or you have issues 13.24.58 # with rockbox 13.25.05 # Okay, I'll have to look into it more 13.25.17 # if the jumper is bridged, it sets master mode 13.25.19 # otherwise slave mode 13.25.33 # best option is to cut the jumper and solder it so it will remain low profile 13.25.45 # if that's not an option you can bend the jumper over and find some other way to permanently bridge it 13.26.12 # but it works fine 13.26.20 # i've only CF modded my h120s but it works 13.26.34 # as for batteries? the replacements all have really long cables so 13.26.39 # you need to get creative with it 13.26.50 # Yeah, I haven't even opened it yet, but the battery is at like 3.9 volts or something, so yeah 13.26.54 # for my H320 13.27.02 # I have a battery on the way, should be easy enough 13.27.05 # i flipped the battery over on its side 13.27.12 # reaching the terminal is the hardest part 13.27.13 # I'm familiar with opening stuff up 13.27.27 # i mean flipped battery over so the cable was underneath 13.27.31 # ah 13.27.34 # probably won't work too well if you do a CF mod though 13.27.40 # it doesn't use as much space 13.27.51 # so you'll need to think of some other way to keep it from moving around 13.27.54 # tape perhaps 13.28.24 # but that's just what i've observed from opening it 13.28.26 # previously 13.28.33 # i found the H320 more difficult than the H12 13.28.35 # h120 13.28.39 # so be careful with it 13.29.10 # h320 is really in its case... you have to pry it out somehow 13.29.14 # the board 13.29.16 # or so 13.29.23 # makes me a bit leery 13.29.32 # h120 is kinda flat so 13.29.38 # easy to disassemble and lift out 13.29.58 # i like that i could pry it apart without having to stress the plastic 13.30.03 # but h320... ugh. 13.30.14 # it's really in there 13.30.16 # lol 13.30.34 # yeah sounds kinda like opening a phone to me lol 13.30.39 # be sure to pry off in the direction of the back 13.30.46 # don't try to pry the front off 13.30.55 # though it seems there's a seam there 13.31.04 # you may damage it if you try to force it open that early 13.31.22 # Is there a, like, a video or something showing it being done? 13.31.26 # yes 13.31.29 # somewhere 13.31.35 # Okay ill have a look 13.31.41 # Soon 13.31.52 # https://www.youtube.com/watch?v=8IcRb9sZqz8 13.32.04 # https://www.youtube.com/watch?v=grMrrdPm-TU 13.32.06 # this is the h120 13.32.08 # Excellent 13.32.09 # much easier =p 13.32.40 # it comes apart very easily 13.33.13 # Yeah, ive tried to replace the battery in a Nexus 4 before, so I got all to tools 13.33.30 # *tried i failed lol 13.33.41 # i find the H120 caps out around 13 MB/s in sequential block write mode 13.33.45 # with a CF card 13.33.55 # probably similar for the H320 13.34.18 # more realistic to get maybe 10 MB/s when you access the filesystem 13.34.47 # you can go for either a real CF card or use an adapter for SD card 13.35.18 # in either case LBA48 is supported so you can install much larger drives 13.35.21 # up to 2TB in theory 13.35.24 # ah looks easy enough, its not like the battery is glued to the damn case like the Nexus 13.35.31 # just have to be careful 13.35.35 # ok, I think I have another missing buffer underrun recovery scenario covered. 13.35.36 # it's taped down or held down 13.40.33 # Okay, that sounds fine 13.40.58 # Gotta do some shit, but I'll definetly check out how to reproduce the H2 bug 13.45.37 # karinka: be sure your bootloader is up to date before you do CF mod. the older ones had reports of issues. 13.45.44 # plus the OF hates CF cards. 13.46.44 Quit karinka (Quit: karinka) 14.02.16 Join karinka [0] (~karinka@n114-75-91-109.bla3.nsw.optusnet.com.au) 14.09.39 *** Saving seen data "./dancer.seen" 14.38.21 # speachy: for bulk transfers over USB, what's the largest payload transfer_complete callback will receive? 14.38.28 # speachy: the max packet size? 14.38.53 # an individual USB packet is 512B max, but UMS block sizes can be up to 64K. 14.39.12 # git diff 14.39.30 # * speachy smacks laggy sloppy focus 14.40.54 # Build Server message: New build round started. Revision 3027cea, 293 builds, 9 clients. 14.42.49 # karinka: this build running should make underruns less likely and recover better when it does happen. 14.44.29 # (and report the number of underruns we'ce seen on debug screen) 14.56.05 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) 15.01.47 # Build Server message: Build round completed after 1252 seconds. 15.01.53 # Build Server message: Revision 3027cea result: All green 15.02.09 # Okay 15.02.43 # https://build.rockbox.org/data/rockbox-aigoerosq.zip (fresh out of the oven!) 15.08.35 # Thanks for the link :) 15.09.35 # do i need to update the bootloader aswell? 15.11.12 # the bootloader hasn't been updated since October 17th. But if you're not using that version, I highly recommend it. 15.18.04 # i think im using the latest one, but i'll check 15.18.47 # the BL's tools menu has the version at the bottom, and it's also in System/Debug/HW Info 15.34.07 Join advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019) 15.37.22 Quit advcomp2019_ (Ping timeout: 260 seconds) 15.47.49 Join prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net) 16.09.40 *** Saving seen data "./dancer.seen" 16.33.32 Quit Rower () 16.38.42 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 16.40.16 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 16.46.13 Quit Rower () 16.48.29 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 17.06.37 Join ulmutul [0] (~ulmutul@dslb-084-061-084-221.084.061.pools.vodafone-ip.de) 17.26.53 Nick amiconn is now known as Guest38565 (jens@rockbox/developer/amiconn) 17.26.54 Join amiconn_ [0] (jens@rockbox/developer/amiconn) 17.26.54 Quit Guest38565 (Killed (egan.freenode.net (Nickname regained by services))) 17.26.54 Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn) 17.27.02 Quit XDjackieXD (Ping timeout: 260 seconds) 17.27.23 Join XDjackieXD [0] (~jackie@irc.chaosfield.at) 17.28.12 Quit braewoods (Ping timeout: 260 seconds) 17.28.45 Join braewoods [0] (~braewoods@learnprogramming/staff/braewoods) 17.30.06 Quit ubervison (Quit: Leaving) 17.35.44 # braewoods: some of the PP targets support OTG as host (for transfering pictures from a camera to the device). At least the Samsung YH925 and the Packard Bell Vibe500 are capable, and IIRC the HDD6330 can also do it. 17.36.08 # ulmutul: i see. 17.36.33 # but not very relevant today 17.36.59 # i don't know why anyone would want their photos on their media player? 17.42.11 # bank in the days SD cards were much smaller in capacity, and on a long trip you could backup your pictures to the player's HDD. 17.43.04 # Only the "big" players supported it (with 30 GB disk space), the smaller ones (e.g. Samsung YH820) didn't. 17.56.28 Quit kugel (Ping timeout: 260 seconds) 17.57.20 Join kugel [0] (~kugel@ip5b413823.dynamic.kabel-deutschland.de) 17.57.20 Quit kugel (Changing host) 17.57.20 Join kugel [0] (~kugel@rockbox/developer/kugel) 18.02.56 Quit ulmutul (Quit: Leaving) 18.09.42 *** Saving seen data "./dancer.seen" 18.12.25 Quit __builtin (Quit: No Ping reply in 180 seconds.) 18.13.04 Join __builtin [0] (~quassel@rockbox/developer/builtin) 18.19.16 Quit Rower (Ping timeout: 240 seconds) 18.35.20 # i just recieved my battery for the h320 18.35.45 # i cant seem to find the battery replacement page, just want to double check its the right one 18.35.50 # can anyone link? 18.38.55 # karinka: there's no page, just a video. 18.39.23 # https://www.youtube.com/results?search_query=h320+battery+replacement 18.39.25 # take your pick 18.39.45 # i recall you need to unscrew some side stuff first 18.39.49 # philips head 18.40.06 # then need to pry the back cover off 18.40.10 # don't mess with the front 18.42.00 # fortunately you just need to pry the board up enough to reach the terminal. 18.42.03 # it's on the side 18.42.05 # of the board 18.44.12 Quit Acou_Bass (Ping timeout: 272 seconds) 18.44.37 Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 19.05.01 # ah okay, thanks 19.06.33 Quit karinka (Quit: karinka) 19.29.07 # interesting. the hdd6330 has a tv output. o.O 19.29.52 # and the chip has a datasheet 19.30.41 # that might be interesting to try to support. RB output to a large screen. 19.38.53 Quit paulk-leonov (Ping timeout: 268 seconds) 19.38.56 Quit Acou_Bass (Ping timeout: 265 seconds) 19.41.29 Join paulk-leonov [0] (~paulk-leo@leonov.paulk.fr) 19.43.05 Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 19.53.22 Quit bluebrother (Disconnected by services) 19.53.26 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 19.54.57 Join fs-bluebot [0] (~fs-bluebo@55d4a836.access.ecotel.net) 19.57.49 Quit fs-bluebot_ (Ping timeout: 264 seconds) 20.00.02 Quit _bilgus (Ping timeout: 264 seconds) 20.02.15 Join _bilgus [0] (~bilgus@65.186.35.190) 20.09.20 Join karinka [0] (~karinka@n114-75-91-109.bla3.nsw.optusnet.com.au) 20.09.46 *** Saving seen data "./dancer.seen" 20.39.42 # michael@kiruria:~/git/rockbox/tools$ make descramble.c \ make: Nothing to be done for 'descramble.c'. 20.40.03 # I could swear I've built this before 20.41.14 # I have binaries for mkboot and scramble 20.42.05 # (Trying to patch an iRiver FW with the new bootloader) 20.45.51 # Oh now I see, it just wants "make" 20.56.32 # battery replacement is done, just waiting for it to charge to see if its still alive 20.56.50 # its been sitting on my shelf for years, hopefully it was just the battery 20.57.11 # it was reporting like, 3.93 volts or something when i tried it the other day 20.59.03 # does the h320 have any indicators that its charging? 21.05.46 # It won't at first, if the battery is extrememly drained 21.06.04 # But normal behavior is to eventually turn on the screen and show a charging animation 21.06.52 # Just wrote 3027cead01 to the disk and rebooted my H320, and now it hangs at the main menu before drawing the menu items 21.07.48 # Naturally, this is not inspiring much confidence since I only upgraded my build in order to flash the new v8 bootloader :) 21.15.04 Join Misanthr- [0] (~Misanthro@91.240.64.146) 21.16.05 Quit Misanthropos (Ping timeout: 272 seconds) 21.16.05 Nick Misanthr- is now known as Misanthropos (~Misanthro@91.240.64.146) 21.36.25 Quit ac_laptop (Quit: WeeChat 2.9) 21.36.41 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 22.09.47 *** Saving seen data "./dancer.seen" 22.17.37 Quit prof_wolfff (Ping timeout: 264 seconds) 22.26.23 # just confirmed its charging 22.30.32 # ill be sure to update the bootloader once its fully charged 22.36.36 Quit ac_laptop (Ping timeout: 240 seconds) 23.13.16 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 23.41.41 # okay to update the bootloader i need to patch the ofw? 23.48.35 # found the info i need i think 23.48.49 # not sure what ofw to patch 23.49.42 Quit mendel_munkis (Ping timeout: 256 seconds) 23.53.50 Join mendelmunkis [0] (~mendelmun@ool-435680b7.dyn.optonline.net) 23.56.55 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)