--- Log for 06.12.112 Server: card.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 day and 23 hours ago 00.01.04 # the classic is neither stable nor unstable, its unusable at the moment 00.01.12 # we'll call it unstable once we have a bootloader 00.02.19 Quit Gallomimia (Quit: I am likely going to change locations) 00.03.56 *** Saving seen data "./dancer.seen" 00.04.40 # hey guys hold off on this )) its just the words game. so its easy to mix up for foreigner. sorry if i offend someone. gevaerts, thanks about cows place :) 00.06.32 # webguest93: You didn't offend anyone, and nor was it my intention to offend. I was just trying to make sure we were on the same page and not expecting things that weren't the case 00.06.58 # thanks Alex. appreciate it 00.07.00 # saratoga, any word when bootloader is planned to be out? 00.07.27 # nobody is working on it at the moment as far a sI know 00.07.29 # when someone writes one 00.07.57 # alex what about freemyipod guys? 00.08.23 # They aren't us 00.08.49 # It'd be nice to have our own, and one that isn't necessarily as full featured as emcore 00.09.02 # i know. but still they doing great job. and there is no updates for a year them on this 00.09.03 # Well, the main freemyipod guy is a Rockbox developer too 00.09.46 Quit kevku (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) 00.10.50 Join Topy44 [0] (kvirc@f048074041.adsl.alicedsl.de) 00.11.05 # yeah they're some of us 00.11.17 Quit ender (Quit: With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925) 00.12.19 # this is grt 00.29.14 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 00.33.18 Quit yuriks (Ping timeout: 260 seconds) 00.37.35 Join Ward [0] (~Mirandaha@bpb01-1-88-162-4-186.fbx.proxad.net) 00.37.42 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 00.37.59 Nick Ward is now known as Guest56546 (~Mirandaha@bpb01-1-88-162-4-186.fbx.proxad.net) 00.38.06 Quit Wardo (Ping timeout: 246 seconds) 00.42.08 Part speckmade 00.48.31 Quit bertrik (Ping timeout: 244 seconds) 00.53.16 Quit webguest93 (Quit: CGI:IRC (Ping timeout)) 00.55.03 # hey would you guys have any recomendations for a sansa fuze theme for rockbox? trying to find one thats pretty bright with low brightness settings and i don't really use album artwork so thats not really a big deal 00.55.44 # i'd like to find one that will display the title and track info at the bottem wile browseing though the menu 00.56.23 # <[Saint]> DIY 00.56.42 # <[Saint]> this is why we have an extensive user controllable theme engine :) 00.57.03 # ah well i supose its not that difficult then 00.57.15 # a cupple hours max to get started good? 00.57.50 # i supose ill make plans to find one XD 00.58.03 # <[Saint]> Depends how you learn, give the themeing section in the manual a read and see how you feel about it. 00.58.10 # guess ill get by with what i have untill then 00.58.12 # alright 00.58.32 # i thank you 01.08.54 Quit dan_a (Ping timeout: 246 seconds) 01.26.59 Quit pamaury (Ping timeout: 260 seconds) 01.34.34 Join yuriks [0] (~yuriks@opentyrian/developer/yuriks) 01.48.13 Quit Jack87 (Ping timeout: 240 seconds) 01.52.32 Join Jack87 [0] (Jack87@nasadmin/admin/jack87) 02.03.09 Quit yuriks (Ping timeout: 260 seconds) 02.03.59 *** Saving seen data "./dancer.seen" 02.07.29 Join Gallomimia [0] (~Gallo@d216-232-229-219.bchsia.telus.net) 02.08.01 Quit XavierGr (Ping timeout: 245 seconds) 02.16.10 Quit Guest56546 (Read error: Connection reset by peer) 02.22.16 Join ytong95 [0] (~73879eca@www.haxx.se) 02.22.39 # is it possible to play DFF file in rockbox??? 02.25.59 Quit SuperBrainAK (Ping timeout: 264 seconds) 02.29.00 Quit ytong95 (Quit: CGI:IRC (EOF)) 02.29.49 Join kam [0] (~18907436@www.haxx.se) 02.34.45 Quit kam (Quit: CGI:IRC (Ping timeout)) 02.38.26 Join kam [0] (~18907436@www.haxx.se) 02.38.48 Join eckoit [0] (~ryan@d173-181-71-88.abhsia.telus.net) 02.42.04 Part eckoit 02.43.23 Quit kam (Quit: CGI:IRC (Ping timeout)) 02.44.16 Join kam [0] (~chatzilla@user-0c90t1m.cable.mindspring.com) 02.47.58 # been using rockbox for a couple of years now. it's great. thanks to all the folks involved... 02.48.55 # i have a accessibility improvement suggestion: cut/copy the .talk files so they follow the .mp3 to the destination 02.49.42 # that way they will be spoken in the new location rather than turning into "file 1" 02.52.24 # <[Saint]> You're talking about when you cut/copy/paste a file from within Rockbox? 02.52.45 # <[Saint]> ...that may actually be a sane check to make. 02.53.42 # <[Saint]> But I think its generally expected that you use a PC to move files around, and in that case can re-run the utility. 03.00.57 Quit Topy44 (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/) 03.04.12 # yes, using the cut/copy/paste features in rockbox 03.08.59 # maybe "delete" should be added to the list, but it's a very minor annoyance to have extra unused .talk files left behind 03.11.45 # <[Saint]> As I said, I think its expected that one should use the utility to clean up/recover from this, but the checks to do this when moving at file within Rockbox manually should be incredibly trivial to make, and it is a sane thing to do. 03.12.29 # <[Saint]> ...now, the interesting part is, that doesn't necessarily mean it'll happen. As someone needs to actually do the work, but this may inspire someone, or even yourself :) 03.14.01 Join Topy44 [0] (kvirc@g228231108.adsl.alicedsl.de) 03.18.34 # I'm probably not the best candidate for messing with the Rockbox code but I suppose it would be interesting to dig into it a bit. But, don't let this stop an interested expert from implementing the change. 03.19.54 Quit Rower85 (Quit: Hmmm...) 03.30.47 # I need to leave but I'll check the IRC log later to see if there's any further discussion on this. Thanks for listening (and the suggestions) 03.31.38 Part kam 03.59.04 Join amayer [0] (~alex@72.25.51.135) 04.01.17 Quit [Saint] (Remote host closed the connection) 04.04.00 *** Saving seen data "./dancer.seen" 04.10.45 Join [Saint] [0] (~quassel@rockbox/user/saint) 04.12.30 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.12.30 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.12.30 Quit amiconn (Disconnected by services) 04.12.30 Quit pixelma (Disconnected by services) 04.12.32 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.17.18 Quit shamus (Read error: Connection reset by peer) 04.18.11 Join shamus [0] (~shamus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 04.28.03 Quit shamus (Quit: chaos reigns within reflect repent and reboot order shall return) 04.29.32 Join shamus [0] (~shamus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 04.37.17 Join TheSphinX_ [0] (~briehl@p579CC459.dip.t-dialin.net) 04.37.53 Join SuperBrainAK [0] (~Andy@97-124-80-200.phnx.qwest.net) 04.39.19 Quit [Saint] (Remote host closed the connection) 04.40.41 Quit TheSphinX^ (Ping timeout: 244 seconds) 04.48.53 Quit GodEater (Ping timeout: 240 seconds) 04.56.12 Join GodEater [0] (~bibble@2a01:348:6:2c6::2) 04.56.12 Quit GodEater (Changing host) 04.56.12 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 05.13.33 Join eckoit [0] (~ryan@50.65.10.24) 05.16.12 Quit the-kyle (Ping timeout: 246 seconds) 05.18.28 Quit Gallomimia (Read error: Connection reset by peer) 05.20.25 Join Gallomimia [0] (~Gallo@d216-232-229-219.bchsia.telus.net) 05.26.57 Quit TheSeven (Disconnected by services) 05.27.08 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 05.35.14 Join the-kyle [0] (~kyle@cpe-024-211-185-030.nc.res.rr.com) 05.37.24 Quit Gallomimia (Ping timeout: 252 seconds) 05.48.04 Join yuriks [0] (~yuriks@opentyrian/developer/yuriks) 05.51.43 Join Gallomimia [0] (~Gallo@d216-232-229-219.bchsia.telus.net) 05.54.10 Quit prof_wolfff (Ping timeout: 255 seconds) 06.01.18 Quit Gallomimia (Read error: Connection reset by peer) 06.01.36 Join Gallomimia_ [0] (~Gallo@d216-232-229-219.bchsia.telus.net) 06.03.15 Join dongs [0] (1000@l212168.ppp.asahi-net.or.jp) 06.03.21 # does rockbox have voice activated recording stuff 06.03.22 Quit SuperBrainAK (Quit: pbly going to sleep /_\) 06.03.49 Quit froggyman (Ping timeout: 256 seconds) 06.04.03 *** Saving seen data "./dancer.seen" 06.07.23 Join Topy44|2 [0] (kvirc@g228162124.adsl.alicedsl.de) 06.09.13 Quit Gallomimia_ (Read error: Connection reset by peer) 06.10.00 Join Gallomimia [0] (~Gallo@d216-232-229-219.bchsia.telus.net) 06.10.31 Quit Topy44 (Ping timeout: 252 seconds) 06.11.22 # anyone know? lol 06.11.43 Quit nosa-j (Ping timeout: 255 seconds) 06.13.16 # hm looks like its got some convoluted trigger system 06.13.18 # without preview 06.13.42 Quit Gallomimia (Read error: No route to host) 06.14.25 Join nosa-j [0] (~m00k@184.76.254.130) 06.19.21 Join Gallomimia [0] (~Gallo@d216-232-229-219.bchsia.telus.net) 06.52.15 Join Scr0mple [0] (~Simon@161.43.73.67) 06.54.31 Quit Scromple (Ping timeout: 252 seconds) 06.56.26 Part eckoit 07.05.27 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 07.11.54 # do i have to run make every time i change a line of code when compiling a binary for my ipod? 07.11.56 # or do i just run that once then run "make zip" to create the binary? 07.12.29 Quit perrikwp_ (Read error: Connection reset by peer) 07.13.52 Join perrikwp [0] (~quassel@cpe-075-177-082-185.triad.res.rr.com) 07.15.21 # amayer: err, make zip might work, but its safer to do make && make zip 07.16.41 # JdGordon: thanks 07.26.48 Part amayer 07.26.53 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 07.44.49 Quit Scr0mple (Quit: Leaving) 08.04.06 *** Saving seen data "./dancer.seen" 08.05.35 Quit ps-auxw (Ping timeout: 264 seconds) 08.10.39 Quit yuriks (Ping timeout: 260 seconds) 08.12.02 Join kevku [0] (x@2001:470:28:773::3) 08.15.53 Join ps-auxw [0] (~arneb@p4FF7F1B1.dip.t-dialin.net) 08.30.57 Join ender1 [0] (krneki@foo.eternallybored.org) 08.31.51 Quit funman (Ping timeout: 246 seconds) 08.32.41 Join Zagor [0] (~bjst@sestofw01.enea.se) 08.32.42 Quit Zagor (Changing host) 08.32.42 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 08.34.21 Join funman [0] (~fun@rockbox/developer/funman) 08.37.45 Join wodz [0] (~wodz@89-76-32-53.dynamic.chello.pl) 08.42.18 Join yuriks [0] (~yuriks@opentyrian/developer/yuriks) 08.46.02 # pamury: (log) http://pastie.org/5487628 <- Here it is clear that one faked packet is not handled by usb stack. It looks like one event is lost somehow. 08.48.53 # and the last line is kinda strange 08.57.08 Join funman_ [0] (~fun@rockbox/developer/funman) 09.00.44 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 09.00.52 Quit funman (Ping timeout: 265 seconds) 09.02.31 Join einhirn [0] (~Miranda@2001:638:605:4:99fe:a96a:893:b2b5) 09.04.39 Join melmothX [0] (~melmoth@unaffiliated/melmothx) 09.07.54 Join petur [0] (~petur@rockbox/developer/petur) 09.08.40 Quit bertrik (Read error: Operation timed out) 09.08.47 Join LinusN [0] (~linus@giant.haxx.se) 09.17.35 Quit wodz (Ping timeout: 264 seconds) 09.19.33 Quit LjL (*.net *.split) 09.19.33 Quit uwe_mobile (*.net *.split) 09.19.41 Join uwe_mobile [0] (~uwe@static.88-198-8-117.clients.your-server.de) 09.20.01 Join LjL [0] (~ljl@unaffiliated/ljl) 09.21.15 Quit einhirn (Ping timeout: 245 seconds) 09.27.08 Quit melmothX (Quit: bau) 09.41.05 Quit freqmod (Ping timeout: 276 seconds) 09.42.12 Join freqmod [0] (~quassel@cm-84.215.142.108.getinternet.no) 09.51.31 Quit linuxguy4 (Ping timeout: 248 seconds) 09.53.13 Join linuxguy3 [0] (~timj@24-148-61-208.c3-0.lem-ubr1.chi-lem.il.cable.rcn.com) 10.00.11 Quit kevku (Ping timeout: 264 seconds) 10.04.09 *** Saving seen data "./dancer.seen" 10.05.46 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.18.38 Join bebna [0] (~a.fasold@94.101.33.114) 10.19.05 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 10.19.22 Part bebna 10.20.08 Quit solarcloud (Ping timeout: 265 seconds) 10.27.00 Quit KiwiCam (Remote host closed the connection) 10.40.27 Quit pamaury (Ping timeout: 246 seconds) 10.41.04 Join kevku [0] (x@2a01:d0:ffff:34a::2) 10.44.30 Join bebna [0] (~a.fasold@94.101.33.114) 10.51.16 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 10.52.51 Quit jhMikeS (Ping timeout: 252 seconds) 11.02.14 Join webguest99 [0] (~1f8088fc@www.haxx.se) 11.07.39 Quit webguest99 (Quit: CGI:IRC (Ping timeout)) 11.15.11 Join [Saint] [0] (~quassel@rockbox/user/saint) 11.16.59 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.22.16 # pamaury: look up the logs 11.22.25 Part dongs 11.23.06 # wodz: strange indeed 11.25.48 # wodz: could you add logf in the whole path of the packet ? That is it usb_thread() (case USB_TRANSFER_COMPLETION) and usb_signal_transfer_completion() ? I can't see how it can disappear this way 11.26.55 # the only suspicious queue operation here is in usb_status_event() 11.28.05 # pamaury: ok but not today probably. 11.28.22 # ok no problem. If I have time I'll try. Is your code on gerrit ? 11.29.58 # pamaury: did you see the existing ypr0tools directory? 11.30.06 # can samsungtools be merged with it? 11.30.10 # yes, no 11.30.33 Quit [Saint] (Ping timeout: 240 seconds) 11.30.37 # afaict, the only "common" tool is MuonEncrypt which only does the actual encrypt/decrypt without handling the headers 11.30.39 # why not? 11.30.50 # and for which there is no source code 11.31.08 # the ypr0 rom is a plain cramfs rootfs image 11.31.42 # the tool you've written can replace MuonEncrypt 11.32.22 # not exactly because MuonEncrypt doesn't look for headers, all samsung upgrades have a small header before the data 11.33.58 # pamaury: oh right. there's also a shell script which handles the headers 11.34.04 # in ypr0tools I mena 11.34.20 # (unpack-firmware.sh) 11.34.43 # yeah, that's what I kind of understood looking at it. I thought that it would be nicer to have a tool that handles everything and which is not ypr0 specific 11.34.57 # I agree with that 11.35.09 # perhaps we should somehow merge the directories or something 11.35.21 # especially to eventually enable rbutil support 11.35.34 # pamaury: that's what I just asked for :) 11.36.01 # the ypr0 could use your tools instead of the scripts in ypr0tools 11.36.22 # if you can do that then you could move the ypr0tools dir in the samsungtool dir ? 11.37.15 # I don't know how general samsungtool is. I suspect it handles all the "yepp" (yp) players. 11.38.20 # Is the samsungtool missing some feature currently or can you rewrite all the .sh scripts with it ? 11.38.30 # * pamaury thinks it misses the archive creation 11.38.31 # I haven't looked at it yet 11.40.10 # ypr0tools has the cramfs-tools sources included to create the rootfs. the rest is, iirc, just attaching the md5sums and concatenating the images 11.41.03 # Ok, then I think I will enhance the samsungtool so that it can create an image (and not only extract it) and then I'll let you rewrite the scripts since you understand them better than I 11.42.02 Quit Rower85 (Quit: Hmmm...) 11.43.00 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 11.44.01 Quit Rower85 (Client Quit) 11.44.29 Join webguest03 [0] (~1f809429@www.haxx.se) 11.45.26 Quit webguest03 (Client Quit) 11.48.39 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 11.49.39 Quit Rower85 (Client Quit) 11.49.50 Join [Saint] [0] (~quassel@rockbox/user/saint) 11.50.25 Join XavierGr [0] (XavierGr@rockbox/staff/XavierGr) 11.55.06 Quit [Saint] (Read error: Connection reset by peer) 11.55.19 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 12.02.14 # pamaury: No, the code is not on gerrit. It is basically last version I pastebined with udc_tick_task() registered in connect interrupt + logf() tweaks. 12.02.41 # could you pastebin it please ? in case I have time to look at it 12.04.12 *** Saving seen data "./dancer.seen" 12.08.14 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 12.15.11 Join solarcloud [0] (~solarclou@178.16.15.26) 12.19.40 Join Topy44 [0] (kvirc@f048141097.adsl.alicedsl.de) 12.19.45 # pamaury: http://pastebin.com/4fMD2zeJ + tick_add_task(udc_tick_task) at the end of usb connect interrupt handler + logf() tweaks 12.20.05 # kugel: done, there are now two tools: fwdecrypt to extract and fwcrypt to create 12.20.12 # wodz: thanks 12.22.59 Quit Topy44|2 (Ping timeout: 248 seconds) 12.31.57 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 12.34.04 # pamaury: that writes a single "subimages"? 12.34.11 # the ypr0 has 4 of those 12.34.38 Quit bluebrother^ (Ping timeout: 260 seconds) 12.35.13 Quit fs-bluebot (Ping timeout: 240 seconds) 12.36.56 Join fs-bluebot [0] (~fs-bluebo@g224239097.adsl.alicedsl.de) 12.40.24 Nick Belzebub_ is now known as Belzebub (~torrentow@195.117.144.66) 13.03.30 Quit markun (Remote host closed the connection) 13.09.00 Quit petur (Quit: *plop*) 13.14.17 # kugel: the archive format is a header plus an encrypted blob, the format of the blob is not specified 13.14.42 # but if you want to be able to "glue" things together I can add some support for that 13.16.35 # except if the r0 has a different format of course 13.18.36 # let me check with a R0 rom file. For now I checked the Q2, T10, Z5 and another one 13.20.38 # wow, it has a completely different header 13.27.07 # pamaury: really? what's different? 13.44.10 Join melmothX [0] (~melmoth@unaffiliated/melmothx) 13.52.54 Join WalkGood [0] (~4@unaffiliated/walkgood) 14.04.14 *** Saving seen data "./dancer.seen" 14.05.22 # kugel: everything except the encryption method, the R0 has a text header and support several subfiles whereas the others have a binary header with only one file 14.06.07 # see the yp-q2 for example: http://www.samsung.com/us/support/owners/product/YP-Q2JEB/XAA 14.08.49 # pamaury: ah, ok 14.09.09 # actually I find the format of the R0 quite stupid 14.11.49 Join amayer_ [0] (~amayer@mail.weberadvertising.com) 14.16.02 Join prof_wolfff [0] (~prof_wolf@213.37.219.103.dyn.user.ono.com) 14.42.05 # pamaury: that's unfortunate, I hoped we could use your tools to simplify rbutil enablement (the shell scripts suck in this regard) 14.45.49 # I guess I could add specific support for the r0 in the tool if really want i 14.45.49 # t 15.07.21 Quit Elfish (Ping timeout: 246 seconds) 15.07.57 Quit XavierGr (Read error: Connection reset by peer) 15.13.32 Join XavierGr [0] (XavierGr@rockbox/staff/XavierGr) 15.15.24 Join Elfish [0] (amba@2a01:4f8:100:90a1:abc:abc:abc:abc) 15.17.09 Quit zoktar (Ping timeout: 260 seconds) 15.23.17 Quit kevku (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) 15.26.02 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 15.28.21 Join dfkt [0] (dfkt@unaffiliated/dfkt) 15.31.07 Join solarcloud-3scre [0] (~solarclou@178.16.15.26) 15.38.21 Quit solarcloud-3scre (Quit: Leaving) 15.41.03 Join solarcloud_3scre [0] (~solarclou@178.16.15.26) 15.55.33 Quit wodz (Quit: Leaving) 16.04.16 *** Saving seen data "./dancer.seen" 16.15.00 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 16.18.42 Join pretty_function [0] (~sigBART@123.252.212.229) 16.19.38 Join eckoit [0] (~ryan@50.65.10.24) 16.41.26 Nick funman_ is now known as funman (~fun@rockbox/developer/funman) 16.48.01 Join kevku [0] (x@2001:470:28:773::3) 17.04.32 # is there any USB OTG code in rockbox, and if there isn't - are there any plans/ideas to support it at some point? 17.05.47 # user890104: no, there could be some interest, I am myself very interested in usb but we don't have so many players with otg support. For example the clip+ controller could support otg (don't know if the hardware does) but we already have problem for the device driver part ! 17.06.13 # do you have any pratical application for it ? 17.08.07 # Host mode/ otg is nice e.g. if you're on a longer trip and want to backup photos from your camera 17.08.13 # pamaury: mass storage transfer, from/to usb sticks or cameras 17.08.48 # more generally your question is related to usb host because supporting usb otg implies support usb host which we don't. I have one device which has a usb host port so at some point I might have a look at it but that's very speculative. 17.09.11 # so basicly my question is about otg+msc 17.09.35 # * amiconn used this once with his H340 (in OF, where copying multiple files but *not* the whole folder is really cumbersome - you have to copy each file individually) 17.09.43 # i have an ipod classic, which supports otg iirc 17.10.45 # There are several devices rockbox is running on which support host mode in hardware. Some of the host controllers don't have public datasheets, unfortunately 17.10.50 # * user890104 uses his sony xperia go phone to transfer music from/to his ipod 17.11.06 # E.g. the H300 one does have public documentation, the one in the X5 doesn't 17.12.43 # I think the two most promissing controllers for otg are the one of the as3525 (amsv2=clip+,clipzip) and the usb arc (many devices actually but not all otg) because we have some documentation 17.13.16 # so if there's complete otg support one day on a target, the usb otg stack can be reused and we only need a low-level driver to support it on other targets, right? 17.13.55 # there is another problem which is that even devices that have a controller that does host/otg may not actually be wired up right 17.13.57 # if there otg support, we can reuse our stack for the device/slave part but we need to implement the host/master part 17.14.03 # this is where you get a lot of weird adapters and shit involved :) 17.14.18 # obviously if their original firmware actually uses/supports host mode then it should be wired right 17.14.24 # (but, er, sadly it's not guaranteed) 17.14.33 # (sometimes you need device-specific cables for it) :/ 17.14.38 # yeah, I'm quite afraid a lot of them are not wired properly 17.14.54 # you need the software controlled pullups on the data lines and all that 17.15.07 # and for "real" OTG where it's negotiated between the two you need the fifth line wired right too 17.15.39 # though most devics don't bother doing that and just have some way toa ctivate host mode in the UI instead# 17.16.23 # in any case, the first step is to support host mode on device which have a real host adapter 17.16.29 # my xperia cable has the fifth pin connected to GND 17.16.49 # this should be "real" OTG 17.16.54 # pamaury: yah, that saves messing about with the actual otg spec weirdness that most devices don't do right anwyay 17.17.14 # right, and that's already quite a bunch of code to write 17.19.06 # user890104: that's the right kind of cable, yes, but not all devices actaully have the hardware to tell whether the ID pin is grounded or not :) 17.22.23 # Torne: well, a developer who wants to test it, can solder some wires 17.22.43 # unless the chip package makes it impossible to do that at home 17.22.45 # it's not always about soldering wires 17.22.57 # you need to be able to pull the data lines up on the host PHY end 17.23.11 # and if the device doesn't have the facility to do that you are probably screwed. 17.23.21 # ah, i see 17.23.22 # anyway. yes, it's possible for some devices 17.23.34 # anything where it already works in the OF is obviously possible 17.23.45 # Other than that we don't really know because it's a pain to determine whether it works without testing :p 17.25.07 # there should be an easy way to test it, right? for example setting the proper usb registers and using a logic analyzer to see if the expected signal is being sent? 17.25.43 # or at least if there's 5.0V provided on the power pins 17.26.00 # you have an interesting definition of easy 17.26.05 # it's not about the power pins, it's about the data pins 17.26.22 # so yes, you would need to write at least enough code to be able to get the controller into the right mode 17.26.30 # Having to use weird adapters is not a big problem imo. The N900 requires that too (because host mode isn't supported officially) 17.26.32 # whcih we don't have 17.26.32 # i mean without writing all of the communication code, just initializing otg mode 17.26.49 # right, but it's still not something that someone can just do right now 17.27.23 # i mean in general, if there's a datasheet available 17.27.52 # for example, if i have a datasheet for my ipod classic's usb controller, i can attempt that 17.30.23 # chaning some memory-mapped USB and PMU registers shouldn't be that hard 17.30.31 # changing* 17.32.05 # btw: i also have a nano2g, nano3g and nano4g 17.32.33 # well, you would surprized by how usb can be painful even if you think you have the documentation, but surely you can try if you know how to program. 17.33.59 # i have written some simple lcd/sensor/stepper/ethernet drivers in C, so i'm interested in writing usb drivers 17.42.14 Quit Zagor (Quit: Clint excited) 17.53.09 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.54.03 Quit pretty_function (Remote host closed the connection) 17.56.53 Quit Unhelpful (Ping timeout: 240 seconds) 18.00.22 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 18.04.19 *** Saving seen data "./dancer.seen" 18.07.30 Quit shamus (Read error: Connection reset by peer) 18.07.51 Join shamus [0] (~shamus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 18.20.32 Join wodz [0] (~wodz@89-76-32-53.dynamic.chello.pl) 18.25.22 Join Robin0800 [0] (~quassel@cpc1-brig15-2-0-cust755.3-3.cable.virginmedia.com) 18.27.21 # pamaury: could you write once again where you'd like to have logf()? 18.27.45 # could you add logf in the whole path of the packet ? That is it usb_thread() (case USB_TRANSFER_COMPLETION) and usb_signal_transfer_completion() ? I can't see how it can disappear this way 18.28.25 # I'll be home in one hour (perhaps a bit more) and should have time to look at this issue finally 18.29.50 # (maybe) I'll have in something like 2h from now. Maybe we will be able to do joint effort 18.31.07 Quit Gallomimia (Read error: Connection reset by peer) 18.31.28 Join Gallomimia [0] (~Gallo@d216-232-229-219.bchsia.telus.net) 18.32.39 Join n1s [0] (~n1s@nl118-168-30.student.uu.se) 18.32.39 Quit n1s (Changing host) 18.32.39 Join n1s [0] (~n1s@rockbox/developer/n1s) 18.46.35 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 18.58.14 Quit n1s (Read error: Connection timed out) 18.58.40 Join qshdulh [0] (~6c2692b1@www.haxx.se) 18.58.41 # hi 18.58.42 Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche) 18.59.01 # is someone here ? 19.01.39 # theres almost 100 people here 19.01.41 Quit qshdulh (Client Quit) 19.07.02 Join froggyman [0] (~me@unaffiliated/froggyman) 19.15.34 Join einhirn [0] (~Miranda@p4FC754BF.dip0.t-ipconnect.de) 19.15.59 Quit einhirn (Client Quit) 19.16.10 Join einhirn [0] (Miranda@bsod.vpn.tu-clausthal.de) 19.16.45 Quit Gallomimia (Read error: Connection reset by peer) 19.17.15 Join Gallomimia [0] (~Gallo@d216-232-229-219.bchsia.telus.net) 19.17.27 Join KiwiCam [0] (~quassel@101.98.163.139) 19.19.23 Quit Robin0800 (Read error: Connection reset by peer) 19.20.38 Quit WalkGood (Quit: restart) 19.22.26 Join WalkGood [0] (~4@unaffiliated/walkgood) 19.22.28 Quit WalkGood (Client Quit) 19.22.54 Join WalkGood [0] (~4@adsl-108-132-98-206.mia.bellsouth.net) 19.22.54 Quit WalkGood (Changing host) 19.22.54 Join WalkGood [0] (~4@unaffiliated/walkgood) 19.37.58 Join n1s [0] (~n1s@nl118-168-30.student.uu.se) 19.38.01 Quit n1s (Changing host) 19.38.01 Join n1s [0] (~n1s@rockbox/developer/n1s) 19.45.29 Quit zoktar (Quit: -) 19.48.06 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 19.49.02 Quit hype (Quit: ["Textual IRC Client: www.textualapp.com"]) 19.49.48 Quit froggyman (Ping timeout: 255 seconds) 20.04.20 *** Saving seen data "./dancer.seen" 20.05.00 Join froggyman [0] (~me@unaffiliated/froggyman) 20.08.17 # pamaury: http://pastie.org/5490053 20.08.46 Quit saratoga (Ping timeout: 245 seconds) 20.09.29 Quit pamaury (Read error: Operation timed out) 20.09.51 Quit yuriks (Ping timeout: 256 seconds) 20.11.50 # pamaury: (log) the code which produce such log is on gerrit 20.15.41 Join Wardo [0] (~Mirandaha@bpb01-1-88-162-4-186.fbx.proxad.net) 20.19.37 Join SuperBrainAK [0] (~Andy@97-124-80-200.phnx.qwest.net) 20.21.06 Quit shamus (Ping timeout: 255 seconds) 20.22.24 Join shamus [0] (~shamus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 20.28.06 Quit WalkGood (Quit: ♪ ♫ ♪ ♫ ♪ ♫ ♪) 20.29.46 # pamaury: forcing return at the end of 'set address poll' in udc_tick_task() so SET ADDRESS and SET CONFIGURATION faked packets are not passed in the same tick helps a bit. In dmesg I have [472383.610595] usb 1-1.1: config 1 has no interfaces? though. 20.34.38 # pamaury: http://pastie.org/5490165 20.35.21 Quit thegeek (Ping timeout: 250 seconds) 20.37.43 Quit y4n (Quit: AMIGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAHAHAHAAAAAAAAAAAAHAHAAA) 20.41.58 Join saratoga [0] (123e0c9c@gateway/web/freenode/ip.18.62.12.156) 20.44.09 Join thegeek [0] (thegeek@2.36.34.95.customer.cdi.no) 20.45.46 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 20.45.46 Quit pamaury (Changing host) 20.45.46 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 20.46.03 Quit akaWolf (Ping timeout: 255 seconds) 20.52.47 # pamaury: ping 20.59.23 # wodz: pong 20.59.26 # free time \o/ 20.59.36 # bertrik: I've got the zen x-fi3, thanks ! 21.01.20 # pamaury: see logs 21.02.01 # I have no idea why two posts to usb_queue in row give such strange effect 21.02.58 # And don't understand why I still get 'no interfaces'. 21.03.19 # ok, let me check, I have a theory 21.14.54 # wodz: I found out ! 21.14.59 # this is pretty stupid actually 21.15.12 # in usb_core_control_request: it uses a static completion event per endpoint 21.15.30 # so if you send two setup packets, the second one will overwrite the first :-/ 21.17.45 # haha, this kills the idea of queues :-) 21.17.54 # exactly ! 21.18.20 # so actually that's a more general problem: for you to send fake packets, you would need to be able to "lock" the stack because the set config or set addr can actually overwrite a legitimate setup ! 21.18.38 # oh 21.20.12 # can we do all this in another way and make usb stack aware that SET ADDRESS and SET CONFIGURATION are all handled by hardware? 21.20.15 # so unfortunately, I can think of only solution to cleanly handle this: have the usbstack explicitely support this kind of quirks by having, say, usb_core_notify_set_addr() and usb_core_notify_set_config() 21.20.25 # yes that's what I mean 21.20.41 Quit sakax (Ping timeout: 260 seconds) 21.21.49 # Perhaps something like #define USB_SETUP_QUIRKS or similar which is define for the rk27xx 21.23.04 # anyway, current behavior is IMO design flaw 21.23.32 # yeah, I admit this is really unexpected 21.24.06 # although in a way this is surprizing because you can't get a new wetup before you finished the previous one 21.24.14 # same thing for usb transfers if you don't queue them 21.25.14 # anyway, you've done a great job here, this is frustrating to loose so much time on this stupid issue 21.25.41 # maybe thats the reason of strange timing dependency in our usb? 21.26.28 # might be, I'm actually trying to think about cases where such an issue could happen 21.26.39 # it is clear that such design can only cause pain and havoc 21.27.03 # gevaerts: ping 21.29.03 # ok, I think I'll wait until you sort things out 21.29.49 # pamaury: pong 21.31.19 # you used to know the usbstack pretty well, we've encountered an interesting issue here in usb_core_control_request: it uses a static array for completion events, which means that if you notify, say, a setup transfer and then another one, the second will simply erase the first. Same thing for any kind of transfer completion. Do you know why it was designed this way ? Shouldn't we change this ? This seems like a dangerous design 21.32.04 # In which cases can you get a second setup transfer before you handled the previous one? 21.32.21 Join sakax [0] (~sakax@d8D862498.access.telenet.be) 21.35.44 # In a normal situation, never. But we encountered this issue because the rk2xx handles some request in pure hardware and we send "fake" packets to the stack to notify thing such as set address and set config. But who knows ?! 21.36.43 # The hardware things should probably be handled directly somehow, i.e. without fake packets 21.36.48 Part eckoit 21.36.48 # It also makes makes the use of a "queue" rather pointless 21.37.45 # Which queue do you mean? 21.38.24 # usb_queue 21.38.56 # I 21.39.05 # 'm not sure I see the problem, really 21.39.29 # We can't handle more than one *setup* request simultaneously, because that's not what USB does 21.40.19 # And as far as I can see we *can* handle more than one non-control transfer at the same time 21.41.01 # the current code can handle one event on each endpoint 21.41.14 # Yes 21.43.07 Quit wodz (Quit: Leaving) 21.44.35 # I know that in theory this can't happen but I'm susipicous about such a design. 21.44.41 # Don't bother. 21.45.57 # If it does happen, the only sensible thing to do is to stall or something like that 21.50.16 # If the hardware wants to deal with some specific requests itself, the best thing to do is to support *that* directly, not to try to fake packets in a racy way and then complicate the rest of the code to work around the artificial race conditions 21.50.57 # I know, it's just that I wasn't aware of this design until now 21.54.05 # I'd say we move everything apart from usb_drv_send() out of the USB_REQ_SET_ADDRESS and USB_REQ_SET_CONFIGURATION cases (or are there more?) in request_handler_device() to their own functions, and then if needed the driver can call them directly 21.54.47 # I assume you can get *some* indication from the hardware that it has handled those requests? 21.55.54 # yes, it's awkward but we can do it, wodz manage to get something working 21.56.35 # and of course the usbstack must not usb_drv_send/recv on such cases because the transaction is already done 21.57.16 # I don't understand why they designed the hardware in such a way 21.57.26 # Yes, that's why the usb_drv_send() stays inside request_handler_device(), so it only gets done if we actually see the SET_ADDRESS or SET_CONFIGURATION 21.57.43 # Do you get an interrupt, or is this polling? 21.58.55 # polling 21.58.57 # polling 21.59.13 # Because if you detect those things asynchronously from the rest of usb_core, you might get a GET_DESCRIPTOR before you've set up everything 21.59.25 # hm 22.01.19 # Maybe we need to check for those "invisible" requests whenever a control request we *do* see comes in, so we don't get them out of order 22.01.36 # Besides the polling, I mean. You still need that 22.01.56 Quit shamus (Ping timeout: 255 seconds) 22.02.21 Join shamus [0] (~shamus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 22.02.57 Part LinusN 22.03.25 Quit pamaury (Remote host closed the connection) 22.03.38 # * gevaerts thinks that if the hardware insists on doing this sort of thing itself, it should use interrupts... 22.04.22 *** Saving seen data "./dancer.seen" 22.14.03 Join yuriks [0] (~yuriks@opentyrian/developer/yuriks) 22.15.54 Quit soap (Quit: soap) 22.27.44 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 22.27.44 Quit pamaury (Changing host) 22.27.44 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 22.29.03 # we handle this (well I hope wodz did) by checking if a flag modification happened when handling a new setup. 22.45.58 Quit shamus (Quit: chaos reigns within reflect repent and reboot order shall return) 22.46.48 Quit einhirn (Ping timeout: 260 seconds) 22.53.12 Quit melmothX (Quit: bau) 22.59.53 Quit Wardo (Ping timeout: 240 seconds) 23.00.48 Join shamus [0] (~shamus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 23.15.21 Join soap [0] (~soap@cpe-174-102-96-10.woh.res.rr.com) 23.15.21 Quit soap (Changing host) 23.15.21 Join soap [0] (~soap@rockbox/staff/soap) 23.15.23 Quit amayer_ (Ping timeout: 246 seconds) 23.15.28 Quit Gallomimia (Ping timeout: 244 seconds) 23.30.10 Quit n1s (Quit: Ex-Chat) 23.47.41 Quit kevku (Ping timeout: 260 seconds) 23.48.59 Join Scromple [0] (~Simon@119.225.209.134) 23.58.08 Join OthnielGraichen [0] (~4b5c3302@www.haxx.se)