--- 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 #       <braewoods> 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 #       <braewoods> at least that tells us that MTP will only work on the same targets that also support HID
00.06.26 #       <braewoods> i'm probably going to develop MTP using PP devices
00.06.42 #       <braewoods> 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 #       <braewoods> speachy: any idea what the wikipedia page on the H300 is talking about?
04.34.25 #       <braewoods> https://en.wikipedia.org/wiki/Iriver_H300_series
04.34.31 #       <braewoods> 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 #       <braewoods> 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 #       <braewoods> oh. so that's what's going on.
06.27.47 #       <braewoods> no-one implemented the usb otg driver for the H300.
06.28.16 #       <braewoods> i wonder why.
06.28.26 #       <braewoods> well that's one feature missing.
06.28.38 #       <braewoods> so it is incomplete in this sense
06.28.48 #       <braewoods> as it stands the media/host port is useless
06.29.58 #       <gevaerts> 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 #       <braewoods> gevaerts: i guess so.
06.31.38 #       <braewoods> i'll add it to a list of stuff i might try though.
06.31.48 #       <braewoods> but it just means i can't use my h300s for testing usb stuff.
06.32.11 #       <braewoods> main point of it would be MTP support
06.32.20 #       <braewoods> but, chicken or the egg?
06.32.29 #       <braewoods> i'll get MTP support working on other OTG targets first
06.33.51 #       <gevaerts> 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 #       <gevaerts> Also, I *think* that one is actually restricted to full speed?
06.35.26 #       <braewoods> gevaerts: no idea. i'll test MTP on my unmodded H320.
06.35.34 #       <braewoods> if it is then it'll be super slow
06.35.48 #       <braewoods> the chip it uses claims to support 2.0
06.36.09 #       <braewoods> just i'd like to make it work if possible since the OF had it
06.36.20 #       <braewoods> but i can see why it is absent
06.36.38 #       <braewoods> when the first driver was implemented there was nothing to really use it yet in RB usb stack
06.36.57 #       <braewoods> but now there is, the HID driver
06.37.09 #       <braewoods> which was implemented in 2009 it appears
06.37.34 #       <gevaerts> https://www.rockbox.org/wiki/UsbOnTheGoSupport has some details
06.37.44 #       <gevaerts> 2.0 != high speed
06.37.54 #       <braewoods> gevaerts: i saw it earlier. i'll look into it later.
06.38.03 #       <gevaerts> The host and device
06.38.03 #       <gevaerts> controllers are compliant with Universal Serial Bus Specification Rev. 2.0, supporting
06.38.06 #       <gevaerts> data transfer at full-speed (12 Mbit/s) and low-speed (1.5 Mbit/s).
06.38.10 #       <braewoods> but you're right. if that's all it can do
06.38.11 #       <gevaerts> (from the chip data sheet)
06.38.17 #       <braewoods> not much point
06.38.22 #       <braewoods> it's slower than the data port
06.39.11 #       <gevaerts> 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 #       <gevaerts> It's been a *long* time since I did USB...
06.39.54 #       <braewoods> wow. it won't even do 2.0 speeds.
06.40.00 #       <braewoods> so why did iriver bother with it?
06.40.10 #       <braewoods> it's pretty useless if it can't do 2.0 speeds
06.40.28 #       <braewoods> i can see now why no one bothered
06.40.29 #       <gevaerts> Didn't you need MTP for some DRM stuff?
06.40.36 #       <braewoods> yea, windows DRM.
06.40.42 #       <braewoods> playsforsure.
06.40.46 #       <braewoods> all pointless now though.
06.40.53 #       <gevaerts> Maybe they had plans involving that?
06.41.04 #       <braewoods> they implemented it in the US firmware
06.41.07 #       <braewoods> but nowhere else
06.41.24 #       <braewoods> hm.
06.41.34 #       <braewoods> if i get bored i might work on it but i can see now why it was low priority.
06.41.43 #       <braewoods> it's only useful for low bandwidth use cases.
06.42.26 #       <gevaerts> 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 #       <braewoods> if you're going to do that you may as well just use a real PC
06.42.57 #       <braewoods> no seriously... lol
06.44.36 #       <braewoods> so the OTG on this is of limited interest
06.44.42 #       <braewoods> i can see now why it was never finished
06.44.48 #       <braewoods> hm
06.47.22 #       <gevaerts> I think petur was involved in that? Maybe he still remembers some of the context
06.47.57 #       <gevaerts> It was before my time though. I came in with USB on the PP502x targets
06.48.13 #       <braewoods> no idea
06.48.18 #       <braewoods> doesn't matter for now
06.48.42 #       <braewoods> i just laugh at retaining DRM support on these anyway
06.48.52 #       <braewoods> 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 #       <petur> 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 #       <braewoods> petur: ah. i was just coming along to pick up the pieces to make the h300 a better port.
06.51.03 #       <braewoods> so to speak
06.51.34 #       <braewoods> it appears the h300 has 2 hardware revisions that make OTG work differently
06.51.36 #       <petur> I have some sample driver code I got from the manufacturer even (mailed them at the time)
06.51.45 #       <braewoods> i see.
06.51.50 #       <braewoods> is that on the wiki?
06.52.07 #       <petur> the problem was 1) I was just getting back into embedded at that time and 2) I knew nothing of USB
06.52.21 #       <speachy> 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 #       <petur> I have most sitting on my NAS drive, not sure what made it to the rockbox site...
06.53.14 #       <braewoods> anyway i was planning to look into adding OTG support for the H300 later on
06.53.22 #       <braewoods> petur: can you look for it sometime?
06.53.34 #       <braewoods> right now i'm focused on trying to implement MTP
06.53.42 #       <braewoods> which i already have stuff i can test it with
06.53.54 #       <braewoods> and honestly OTG is of limited use without more stuff to use it really
06.56.42 #       <petur> braewoods: https://www.rockbox.org/wiki/UsbOnTheGoSupport at the bottom has the sample code
06.57.32 #       <petur> I´ll try to look if I have any other stuff tonight
06.58.06 #       <braewoods> petur: ok. good. thanks.
07.01.19 #       <petur> np
07.04.23 #       <braewoods> though seems even with OTG rockbox is limited to slave role
07.04.49 #       <braewoods> the stack isn't setup for host
07.04.57 #       <speachy> yep.
07.05.04 #       <braewoods> just OTG enables more slave roles?
07.05.12 #       <braewoods> seems to be the case
07.05.48 #       <speachy> 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 #       <braewoods> and what would be the use case?
07.06.16 #       <braewoods> rockbox is primarily targeted to a slave role
07.06.18 #       <braewoods> as it stands
07.06.18 #       <speachy> plugging in external storage is the main one
07.06.34 #       <speachy> using an external DAC (all the vogue these days)
07.06.54 #       <braewoods> hm
07.07.18 #       <speachy> those features are already there "For free" for the hosted platforms.
07.08.08 #       <braewoods> well i'm honestly not interested in the complexity of developing a host stack...
07.08.17 #       <braewoods> for native targets
07.08.56 #       <braewoods> 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 #       <braewoods> not counting hosted
07.09.09 #       <braewoods> or Linux based ones
07.09.13 #       <speachy> not that I recall.
07.09.33 #       <braewoods> as i thought. most of them seem to only take the slave role.
07.10.09 #       <braewoods> not surprised honestly
07.10.22 #       <braewoods> they were mainly intended as an extension of your PC, MAC, or other host
07.11.11 #       <braewoods> i have an idea for other slave roles
07.11.23 #       <braewoods> but we may need a way to regulate how much we expose at once
07.11.50 #       <braewoods> 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 #       <braewoods> 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 #       <braewoods> passthrough or so
07.13.05 #       <speachy> braewoods: g#1009
07.13.05 #       <braewoods> but not sure what else would be practical
07.13.07 #       <fs-bluebot_> 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 #       <braewoods> oh.
07.13.16 #       <braewoods> lol
07.15.10 #       <braewoods> i guess since many of them used OTG style usb connectors
07.15.20 #       <braewoods> err
07.15.22 #       <braewoods> didn't use
07.15.27 #       <braewoods> anyway
07.16.12 #       <speachy> hmm.  I need to see what it will take to enable C++ in our toolchains.
07.16.37 #       <braewoods> why would we need C++?
07.16.44 #       <braewoods> i thought rbutil was all that used it
07.17.59 #       <speachy> primarily for the hosted targets where c++ libraries are more common
07.18.05 #       <braewoods> Oh.
07.18.32 #       <braewoods> i just know from using C++ that it has problems being used in embedded
07.18.52 #       <braewoods> the automatic behaviors it has can cause a lot of headaches.
07.19.03 #       <speachy> yeah, it's not ideal.  but if it lets us reuse stable code, that's a net win.
07.19.28 #       <braewoods> i think arduino gets away with it because they throw away the entire standard library to use their own
07.19.42 #       <braewoods> so they can tweak what automatic behaviors get used in classes
07.19.49 Join    Stanley00 [0] (~stanley00@unaffiliated/stanley00)
07.20.12 #       <braewoods> i think you'd have to do that in any case to develop with it in embedded
07.20.28 #       <braewoods> simply because you don't want it trying to be clever and screwing you over
07.22.44 #       <gevaerts> 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 #       <speachy> the USB-IF really, really jumped the shark when it came to naming and figuring out what is supported.
07.23.43 #       <speachy> USB 2.0 was quasi-sane, but everything since then has been a dumpster fire
07.25.11 #       <speachy> 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 #       <braewoods> hm
07.28.29 #       <braewoods> mtp sure supports a lot of stuff we don't need
07.28.55 #       <braewoods> like misc. metadata options
07.29.04 #       <braewoods> mainly want MTP for file control and that's it
07.36.34 #       <petur> 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 #       <braewoods> petur: there was an iriver h380?
07.42.25 #       <braewoods> 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 #       <petur> yeah, a 340 with a bigger disk (installed myself)
07.42.31 #       <braewoods> Oh.
07.42.33 #       <braewoods> I see.
07.42.37 #       <petur> :)
07.42.55 #       <braewoods> I couldn't test on the H100 though since it's super rare
07.43.01 #       <braewoods> is that one of your units?
07.43.08 #       <braewoods> one of the H110 or so
07.43.21 #       <braewoods> i only have H120s and H320s
07.43.43 #       <petur> yeah but I´m hanging on to it because it is my only device that can record off optical
07.44.11 #       <braewoods> if you have a H110 still i'd ask you to test the new bootloader on it
07.44.28 #       <braewoods> I tested the related bootloader, H120.
07.44.45 #       <braewoods> it works fine but i can't test the H100 one because the hardware is so hard to find
07.45.07 #       <braewoods> same with H320
07.45.35 #       <braewoods> https://forums.rockbox.org/index.php/topic,53654.0.html
07.45.42 #       <petur> checked, I have an h120
07.45.45 #       <braewoods> Oh.
07.45.50 #       <braewoods> Ok then nevermind.
07.45.57 #       <braewoods> I figure the H100 is just unpopular.
07.46.08 #       <braewoods> can't say i'm surprised. it was a smaller unit.
07.46.15 #       <braewoods> the people who bought these wanted more space.
07.46.47 #       <braewoods> 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 #       <braewoods> petur: do you have any of the rare H300 remotes in your collection?
07.48.07 #       <braewoods> i read reports that they work but impossible to test them
07.48.07 #       <petur> I have two: with and without display
07.48.23 #       <petur> they can go too
07.48.25 #       <braewoods> so you have both of them?
07.48.28 #       <petur> yup
07.48.33 #       <braewoods> how rare.
07.48.45 #       <braewoods> if you feel up to it, i'd like to confirm that they work properly with modern RB builds
07.48.51 #       <braewoods> i don't know if i even live near you lol
07.49.35 #       <petur> well... I was part of rockbox dev team and focussed on iRiver, so... ;)
07.49.51 #       <braewoods> i'm mostly coming along later to pick up the pieces
07.49.56 #       <petur> where are you located?
07.50.03 #       <braewoods> north america
07.50.11 #       <petur> Belgium here
07.50.15 #       <braewoods> ah, i figured.
07.50.40 #       <braewoods> 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 #       <gevaerts> 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 #       <braewoods> it would help, gevaerts, but if it's this hard to find it may not be practical enough to matter
07.52.02 #       <braewoods> the most common unit in the H100 series i see show up for sale is the H120
07.52.12 #       <braewoods> H140 is rarer but i still see it sometimes
07.52.15 #       <braewoods> H100 is the rarest
07.52.21 #       <braewoods> i've never seen one to date
07.53.40 #       <braewoods> hm
07.53.52 #       <gevaerts> https://www.rockbox.org/wiki/RockboxTesting
07.53.57 #       <gevaerts> No H110 though
07.55.21 #       <braewoods> i did finally find an hdd6330 unit after a few months of searching
07.55.32 #       <braewoods> it was mislabeled as an hdd1630
07.55.32 #       <petur> I see I forgot to add my H120
07.56.06 #       <braewoods> i found the hdd6330 interesting due to how it has so much RAM
07.56.11 #       <braewoods> 64M
07.57.21 #       <braewoods> anyway my bootloader project is complete it appears
07.57.42 #       <braewoods> at least until the next step can be realized
07.58.20 #       <braewoods> petur: i gotta thank whoever added the reset cookie to the crt0.S code
07.58.30 #       <braewoods> it allowed me to fix the H300 bootloader
07.58.38 #       <braewoods> it saved my unit from being bricked
07.59.26 #       <petur> heh, I once bricked mine, gave it to Linus for reflashing (soldering) and got it back a few years later :)
07.59.57 #       <petur> but that was me in a hurry flashing the wrong file
08.07.38 #       <braewoods> petur: yea. i don't think anyone could easily undo it today.
08.07.43 #       <braewoods> the tools are much rarer.
08.08.01 #       <braewoods> so it's good the bootloader has rescue code
08.08.20 #       <braewoods> it can boot the OF or the rockbox rom image
08.08.44 #       <braewoods> though now that i think about it
08.08.58 #       <braewoods> the rockbox rom image is useless for recovering from a bad flash
08.09.07 #       <braewoods> since you can't flash while booted from ROM
08.09.26 #       <braewoods> so still should use the OF
08.09.34 ***     Saving seen data "./dancer.seen"
08.09.42 #       <braewoods> but
08.09.47 #       <speachy> boot from rom, ROLO the ram binary, and then flash?
08.09.47 #       <braewoods> i guess you can use it to do rolo
08.09.50 #       <braewoods> yea
08.10.31 #       <braewoods> that's why i saw no point in adding support for the RAM image there
08.10.37 #       <gevaerts> When flashing, always make sure to check both the file and the device
08.11.00 #       <braewoods> gevaerts: iriver_flash does most of that. the main thing it can't do is test if it still can boot.
08.11.13 #       <gevaerts> 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 #       <braewoods> i refactored iriver_flash and added some more sanity checks the original author never had
08.12.01 #       <braewoods> like checking the rockbox image to make sure it matches the expected model string
08.12.13 #       <braewoods> useful for making sure they aren't mixing h100, h120, h300 builds up
08.12.23 #       <braewoods> though unlikely it could save someone's bacon
08.13.19 #       <braewoods> 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 #       <braewoods> :)
08.15.16 #       <braewoods> speachy: something else that occurred to me. MTP could be useful to exfilitrate debugging information over USB.
08.15.38 #       <braewoods> it is rather vague about resources so we could define some for exporting other info.
08.18.11 #       <braewoods> i'll see if i can find a mtp library that handles most of the hard work
08.18.26 #       <braewoods> why reinvent the wheel if there's one that can be reworked a bit?
08.19.16 #       <braewoods> trouble is most are heavily tied to their intended environment
08.20.06 #       <gevaerts> Well, that could work. We do have USB serial debugging though if you want that sort of thing today :)
08.20.17 #       <braewoods> just an idea i had for now.
08.20.28 #       <braewoods> right now i just care about uh
08.20.36 #       <braewoods> getting this to work
08.20.39 #       <braewoods> for its main purpose
08.21.35 #       <gevaerts> Main purposes are boring :)
08.21.51 #       <braewoods> indeed.
08.22.03 #       <braewoods> still it would be interesting to expose other things as MTP resources
08.22.15 #       <braewoods> like the current ROM image
08.22.19 #       <braewoods> on some targets
08.23.02 #       <speachy> 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 #       <gevaerts> speachy: that's there though
08.24.42 #       <speachy> oh?  we have a CDC/serial-over-usb interface?
08.24.48 #       <braewoods> speachy: usb_serial
08.24.53 #       <speachy> (how did I miss that?)
08.24.56 #       <braewoods> i saw it when i was poking around
08.25.02 Quit    mutax (Read error: Connection reset by peer)
08.25.03 #       <gevaerts> firmware/usbstack/usb_serial.c
08.25.45 #       <gevaerts> And of course calls to that in firmware/logf.c
08.26.02 #       <gevaerts> You need USB_ENABLE_SERIAL
08.26.23 #       <speachy> ah, I see that now
08.28.53 #       <speachy> I'm going to add that to the configure advanced options.
08.30.07 #       <gevaerts> Maybe test if it still works first :)
08.31.02 #       <speachy> pfft, if it compiles that means it works, right?
08.31.31 #       <speachy> though it obviously won't work on any of these newfangled hosted targets
08.31.36 #       <gevaerts> 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 #       <braewoods> 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 #       <braewoods> 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 #       <speachy> well, it builds on everything I have here
08.49.56 #       <speachy> with one fix for hosted targets
08.53.05 #       <fs-bluebot_> Build Server message: New build round started. Revision 7c87467, 293 builds, 9 clients.
09.04.40 #       <braewoods> we could start incorporating C11 stuff into RB if useful
09.04.46 #       <braewoods> namely _Generic or _Static_assert
09.16.34 #       <fs-bluebot_> Build Server message: Build round completed after 1410 seconds.
09.16.42 #       <fs-bluebot_> 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 #       <mendel_munkis> how big of an issue are the changes in 3035?
09.33.36 #       <speachy> pretty minor I'd think.
09.33.57 #       <mendel_munkis> can I commit it as is?
09.33.58 #       <speachy> well, the manual is now the last holdout for swcodec/lcd_bitmap stuff
09.34.27 #       <speachy> don't see why not
09.35.19 #       <fs-bluebot_> Build Server message: New build round started. Revision 0aa7028, 293 builds, 9 clients.
09.35.57 #       <mendel_munkis> btw the way gerrit handles timeing out is irritating.
09.38.23 #       <speachy> I think the underlying issue is some sort of www server or tcp stack configuration I haven't quite figured out
09.51.46 #       <fs-bluebot_> Build Server message: Build round completed after 987 seconds.
09.51.49 #       <fs-bluebot_> Build Server message: Revision 0aa7028 result: All green
09.51.53 #       <fs-bluebot_> Build Server message: New build round started. Revision 473aa61, 293 builds, 9 clients.
09.59.07 #       <mendel_munkis> how do I make a new wiki page?
10.01.59 #       <speachy> 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 #       <mendel_munkis> thanks
10.05.18 #       <braewoods> speachy: seems rb has partial support for utf16/ucs2... but decode only
10.05.44 #       <braewoods> but realistically we need it to support mtp fully
10.05.57 #       <braewoods> unless
10.06.02 #       <braewoods> fat32 has no unicode?
10.06.14 #       <speachy> fat32 doesn't care one way or another
10.06.38 #       <braewoods> it's easy to encode ASCII as utf16
10.06.44 #       <braewoods> just not sure how we'd handle the rest
10.07.10 #       <fs-bluebot_> Build Server message: Build round completed after 918 seconds.
10.07.15 #       <fs-bluebot_> Build Server message: Revision 473aa61 result: All green
10.08.16 #       <speachy> wait, does mtf say "utf-16" or "ucs-2"?
10.08.27 #       <braewoods> let me look
10.08.42 #       <speachy> utf16 <->utf8 is straightforward.
10.08.58 #       <braewoods> Strings in PTP (and thus MTP) consist of standard 2-byte Unicode characters as defined
10.08.59 #       <speachy> ucs-2 is 16-bit only, and thus is at best a subset of utf-16/utf-8
10.09.00 #       <braewoods> by ISO 10646.
10.09.15 #       <braewoods> that's all it says
10.09.36 ***     Saving seen data "./dancer.seen"
10.10.07 #       <braewoods> it's UCS
10.10.08 #       <speachy> 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 #       <speachy> utf16 was added later in an amendment.
10.11.41 #       <braewoods> we could probably get by with just BMP support
10.11.42 #       <speachy> fwiw, it looks like at least the andtoid mtp code actually implements utf16.
10.11.44 #       <speachy> 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 #       <braewoods> it appears rbunicode already does what i need
10.17.12 #       <braewoods> unless that's somehow wrong?
10.19.23 #       <speachy> yeah, handling the BMP must suffice, because that's all that can be done with MTP.
10.19.41 #       <braewoods> could we reuse utf16 for ucs2
10.19.49 #       <braewoods> support for that is in RB unicode already
10.20.12 #       <speachy> we could; the question is what the MTP initiator supports.
10.20.29 #       <braewoods> i'll see what libmtp does
10.20.49 #       <speachy> (I'd be surprised if anything widely deployed doesn't support UTF-16)
10.21.27 #       <braewoods> libmtp uses ucs2
10.21.29 #       <braewoods> so
10.21.33 #       <braewoods> via iconv
10.21.51 #       <braewoods> so we'd need our own routine
10.22.01 #       <speachy> I wound't personally bother at this point.
10.22.20 #       <braewoods> i'll look into it later but i'd copy it from somewhere else honestly
10.22.28 #       <braewoods> as long as the license is GPL compatible and documented
10.27.40 #       <braewoods> Oh.
10.27.52 #       <braewoods> utf8encode / utf8decode works in terms of ucs2
10.27.54 #       <braewoods> great
10.27.56 #       <braewoods> we already got it
10.37.17 #       <mendel_munkis> does anyone know if the IAUDIO X5 joystick does diagonals?
10.46.27 #       <braewoods> 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 #       <braewoods> i'm thinking of making MTP api internally to allow for different implementation of storage options
10.47.05 #       <braewoods> not just the obvious one
10.47.18 #       <speachy> okay, I managed to get approval to come into the $dayjob lab to perform "maintainence"
10.48.11 #       <speachy> 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 #       <braewoods> interesting.
11.19.19 #       <braewoods> the H300's OTG chip has a driver for the linux kernel
11.19.22 #       <braewoods> that may be useful
11.20.46 #       <mendel_munkis> _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 #       <speachy> 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 #       <mendel_munkis> 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 #       <karinka> I also have a iriver H20, it's kinda dead
12.43.58 #       <karinka> The HDD works, just needs a new battery
12.44.11 #       <karinka> *H320
12.44.32 #       <karinka> Which should be coming soon
12.46.34 #       <braewoods> karinka: well i released an updated bootloader that enables some new stuff that used to be H100 exclusive.
12.47.11 #       <braewoods> it seems the h300 is only missing one thing to be complete at this point
12.47.14 #       <braewoods> OTG support
12.49.10 #       <braewoods> karinka: which means you can probably CF mod your h320 now if you wanted
12.52.51 #       <speachy> karinka: so what issues with the H2 did you run into?
12.54.30 Quit    lebellium (Quit: Leaving)
12.58.33 #       <karinka> Still new to IRC so bear with me
12.59.16 #       <karinka> 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 #       <karinka> It crashes
12.59.32 #       <braewoods> what build?
12.59.54 #       <karinka> 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 #       <braewoods> i'll try it with mine
13.03.45 #       <speachy> probably the audio buffer underrunning and not recovering
13.04.13 #       <braewoods> not happening on my h320
13.04.20 #       <braewoods> karinka: can you describe the exact process?
13.04.33 #       <speachy> no, it's going to be a problem with the hiby-based hosted targets
13.04.47 #       <braewoods> oh
13.04.53 #       <braewoods> it's not about the H320
13.04.55 #       <braewoods> i see
13.05.32 #       <karinka> hang on ill put a fresh copy on it
13.06.25 #       <karinka> gotta find my m3k first
13.18.58 #       <karinka> Okay I can't reproduce it with a fresh install, it must have something to do with my settings
13.19.23 #       <speachy> database reinit?
13.20.00 #       <speachy> still, this does seem to indicate that there's still a playback underrun scenario that's not recoverable
13.20.58 #       <speachy> (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 #       <braewoods> kinda interesting. the OTG on the H300 sucks but... it at least has a chance of being supported
13.21.47 #       <karinka> sucks?
13.21.49 #       <braewoods> the OTG for the other coldfire targets either don't exist or have a totally undocumented chip
13.21.56 #       <braewoods> karinka: it's limited to usb 1.1
13.22.03 #       <braewoods> so it's going to be slow
13.22.24 #       <karinka> ah, well yeah its old
13.22.34 #       <braewoods> oddly enough some stuff around same era support 2.0
13.22.48 #       <braewoods> so... yea
13.23.07 #       <braewoods> the h300 is a weird one. it supports OTG on a separate USB port.
13.23.14 #       <karinka> do you have a good resource on how to do the CF mod for the H320?
13.23.26 #       <braewoods> https://www.rockbox.org/wiki/CFModGuide
13.23.40 #       <braewoods> it's not specific but it tells you what you need.
13.24.00 #       <braewoods> the h320 like the h120 uses a 50 pin adapter
13.24.07 #       <braewoods> 50 pin hard drive 1.8"
13.24.07 #       <karinka> Excellent, exactly what I need
13.24.16 #       <karinka> Thanks
13.24.18 #       <braewoods> so you need an adapter
13.24.31 #       <braewoods> just uh note, all the adapters i could find in recent days have a jumper
13.24.35 #       <braewoods> that sticks up
13.24.43 #       <braewoods> that will cause problems when you go to reassemble
13.24.56 #       <braewoods> and you need the jumper set or you have issues
13.24.58 #       <braewoods> with rockbox
13.25.05 #       <karinka> Okay, I'll have to look into it more
13.25.17 #       <braewoods> if the jumper is bridged, it sets master mode
13.25.19 #       <braewoods> otherwise slave mode
13.25.33 #       <braewoods> best option is to cut the jumper and solder it so it will remain low profile
13.25.45 #       <braewoods> if that's not an option you can bend the jumper over and find some other way to permanently bridge it
13.26.12 #       <braewoods> but it works fine
13.26.20 #       <braewoods> i've only CF modded my h120s but it works
13.26.34 #       <braewoods> as for batteries? the replacements all have really long cables so
13.26.39 #       <braewoods> you need to get creative with it
13.26.50 #       <karinka> Yeah, I haven't even opened it yet, but the battery is at like 3.9 volts or something, so yeah
13.26.54 #       <braewoods> for my H320
13.27.02 #       <karinka> I have a battery on the way, should be easy enough
13.27.05 #       <braewoods> i flipped the battery over on its side
13.27.12 #       <braewoods> reaching the terminal is the hardest part
13.27.13 #       <karinka> I'm familiar with opening stuff up
13.27.27 #       <braewoods> i mean flipped battery over so the cable was underneath
13.27.31 #       <karinka> ah
13.27.34 #       <braewoods> probably won't work too well if you do a CF mod though
13.27.40 #       <braewoods> it doesn't use as much space
13.27.51 #       <braewoods> so you'll need to think of some other way to keep it from moving around
13.27.54 #       <braewoods> tape perhaps
13.28.24 #       <braewoods> but that's just what i've observed from opening it
13.28.26 #       <braewoods> previously
13.28.33 #       <braewoods> i found the H320 more difficult than the H12
13.28.35 #       <braewoods> h120
13.28.39 #       <braewoods> so be careful with it
13.29.10 #       <braewoods> h320 is really in its case... you have to pry it out somehow
13.29.14 #       <braewoods> the board
13.29.16 #       <braewoods> or so
13.29.23 #       <braewoods> makes me a bit leery
13.29.32 #       <braewoods> h120 is kinda flat so
13.29.38 #       <braewoods> easy to disassemble and lift out
13.29.58 #       <braewoods> i like that i could pry it apart without having to stress the plastic
13.30.03 #       <braewoods> but h320... ugh.
13.30.14 #       <braewoods> it's really in there
13.30.16 #       <braewoods> lol
13.30.34 #       <karinka> yeah sounds kinda like opening a phone to me lol
13.30.39 #       <braewoods> be sure to pry off in the direction of the back
13.30.46 #       <braewoods> don't try to pry the front off
13.30.55 #       <braewoods> though it seems there's a seam there
13.31.04 #       <braewoods> you may damage it if you try to force it open that early
13.31.22 #       <karinka> Is there a, like, a video or something showing it being done?
13.31.26 #       <braewoods> yes
13.31.29 #       <braewoods> somewhere
13.31.35 #       <karinka> Okay ill have a look
13.31.41 #       <karinka> Soon
13.31.52 #       <braewoods> https://www.youtube.com/watch?v=8IcRb9sZqz8
13.32.04 #       <braewoods> https://www.youtube.com/watch?v=grMrrdPm-TU
13.32.06 #       <braewoods> this is the h120
13.32.08 #       <karinka> Excellent
13.32.09 #       <braewoods> much easier =p
13.32.40 #       <braewoods> it comes apart very easily
13.33.13 #       <karinka> Yeah, ive tried to replace the battery in a Nexus 4 before, so I got all to tools
13.33.30 #       <karinka> *tried i failed lol
13.33.41 #       <braewoods> i find the H120 caps out around 13 MB/s in sequential block write mode
13.33.45 #       <braewoods> with a CF card
13.33.55 #       <braewoods> probably similar for the H320
13.34.18 #       <braewoods> more realistic to get maybe 10 MB/s when you access the filesystem
13.34.47 #       <braewoods> you can go for either a real CF card or use an adapter for SD card
13.35.18 #       <braewoods> in either case LBA48 is supported so you can install much larger drives
13.35.21 #       <braewoods> up to 2TB in theory
13.35.24 #       <karinka> ah looks easy enough, its not like the battery is glued to the damn case like the Nexus
13.35.31 #       <karinka> just have to be careful
13.35.35 #       <speachy> ok, I think I have another missing buffer underrun recovery scenario covered.
13.35.36 #       <braewoods> it's taped down or held down
13.40.33 #       <karinka> Okay, that sounds fine
13.40.58 #       <karinka> Gotta do some shit, but I'll definetly check out how to reproduce the H2 bug
13.45.37 #       <braewoods> karinka: be sure your bootloader is up to date before you do CF mod. the older ones had reports of issues.
13.45.44 #       <braewoods> 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 #       <braewoods> speachy: for bulk transfers over USB, what's the largest payload transfer_complete callback will receive?
14.38.28 #       <braewoods> speachy: the max packet size?
14.38.53 #       <speachy> an individual USB packet is 512B max, but UMS block sizes can be up to 64K.
14.39.12 #       <speachy> git diff
14.39.30 #       * speachy smacks laggy sloppy focus
14.40.54 #       <fs-bluebot_> Build Server message: New build round started. Revision 3027cea, 293 builds, 9 clients.
14.42.49 #       <speachy> karinka: this build running should make underruns less likely and recover better when it does happen.
14.44.29 #       <speachy> (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 #       <fs-bluebot_> Build Server message: Build round completed after 1252 seconds.
15.01.53 #       <fs-bluebot_> Build Server message: Revision 3027cea result: All green
15.02.09 #       <karinka> Okay
15.02.43 #       <speachy> https://build.rockbox.org/data/rockbox-aigoerosq.zip  (fresh out of the oven!)
15.08.35 #       <karinka> Thanks for the link :)
15.09.35 #       <karinka> do i need to update the bootloader aswell?
15.11.12 #       <speachy> the bootloader hasn't been updated since October 17th.   But if you're not using that version, I highly recommend it.
15.18.04 #       <karinka> i think im using the latest one, but i'll check
15.18.47 #       <speachy> 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 #       <ulmutul> 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 #       <braewoods> ulmutul: i see.
17.36.33 #       <braewoods> but not very relevant today
17.36.59 #       <braewoods> i don't know why anyone would want their photos on their media player?
17.42.11 #       <ulmutul> 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 #       <ulmutul> 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 #       <karinka> i just recieved my battery for the h320
18.35.45 #       <karinka> i cant seem to find the battery replacement page, just want to double check its the right one
18.35.50 #       <karinka> can anyone link?
18.38.55 #       <braewoods> karinka: there's no page, just a video.
18.39.23 #       <braewoods> https://www.youtube.com/results?search_query=h320+battery+replacement
18.39.25 #       <braewoods> take your pick
18.39.45 #       <braewoods> i recall you need to unscrew some side stuff first
18.39.49 #       <braewoods> philips head
18.40.06 #       <braewoods> then need to pry  the back cover off
18.40.10 #       <braewoods> don't mess with the front
18.42.00 #       <braewoods> fortunately you just need to pry the board up enough to reach the terminal.
18.42.03 #       <braewoods> it's on the side
18.42.05 #       <braewoods> 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 #       <karinka> ah okay, thanks
19.06.33 Quit    karinka (Quit: karinka)
19.29.07 #       <braewoods> interesting. the hdd6330 has a tv output. o.O
19.29.52 #       <braewoods> and the chip has a datasheet
19.30.41 #       <braewoods> 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 #       <Strife89> michael@kiruria:~/git/rockbox/tools$ make descramble.c \ make: Nothing to be done for 'descramble.c'.
20.40.03 #       <Strife89> I could swear I've built this before
20.41.14 #       <Strife89> I have binaries for mkboot and scramble
20.42.05 #       <Strife89> (Trying to patch an iRiver FW with the new bootloader)
20.45.51 #       <Strife89> Oh now I see, it just wants "make"
20.56.32 #       <karinka> battery replacement is done, just waiting for it to charge to see if its still alive
20.56.50 #       <karinka> its been sitting on my shelf for years, hopefully it was just the battery
20.57.11 #       <karinka> it was reporting like, 3.93 volts or something when i tried it the other day
20.59.03 #       <karinka> does the h320 have any indicators that its charging?
21.05.46 #       <Strife89> It won't at first, if the battery is extrememly drained
21.06.04 #       <Strife89> But normal behavior is to eventually turn on the screen and show a charging animation
21.06.52 #       <Strife89> 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 #       <Strife89> 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 #       <karinka> just confirmed its charging
22.30.32 #       <karinka> 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 #       <karinka> okay to update the bootloader i need to patch the ofw?
23.48.35 #       <karinka> found the info i need i think
23.48.49 #       <karinka> 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)