--- Log for 13.07.111 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 days and 4 hours ago 00.12.25 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 00.16.41 Quit ReimuHakurei (Read error: Connection reset by peer) 00.16.51 Join ReimuHakurei [0] (~reimu@74.112.212.15) 00.18.30 Quit benedikt93 (Quit: Bye ;)) 00.27.37 Quit ricemark20 (Remote host closed the connection) 00.27.47 Quit Viperfang (Ping timeout: 255 seconds) 00.29.26 Join ricemark20 [0] (~mark@99-20-182-188.lightspeed.elgnil.sbcglobal.net) 00.32.56 Join z35 [0] (~z35@ool-44c2aff0.dyn.optonline.net) 00.33.16 Quit ReimuHakurei (Read error: Connection reset by peer) 00.33.24 Nick z35 is now known as zchs (~z35@ool-44c2aff0.dyn.optonline.net) 00.34.06 Quit bertrik (Read error: Operation timed out) 00.34.41 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 00.34.41 Quit bertrik (Changing host) 00.34.41 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 00.36.18 Join ReimuHakurei [0] (~reimu@74.112.212.15) 00.36.18 Join Scromple [0] (~Simon@115-64-195-104.tpgi.com.au) 00.37.55 Join krazykit [0] (~krazykit@206.183.185.8) 00.39.02 Quit bertrik (Ping timeout: 255 seconds) 00.39.06 Quit leavittx (Read error: Operation timed out) 00.42.25 Join Viperfang [0] (~Viperfang@external.viperfang.net) 00.45.57 Quit GermanMushroom (Quit: Ik ga weg) 00.52.41 # saratoga: hm? 01.05.51 Quit AlexP (Remote host closed the connection) 01.09.40 Join AlexP [0] (~alex@rockbox/staff/AlexP) 01.11.24 Quit ender` (Quit: I sometimes wish lipstick really would.) 01.19.03 Quit GeekShadow (Quit: The cake is a lie !) 01.19.48 Nick Farthen is now known as finn (~Farthen@static.225.178.40.188.clients.your-server.de) 01.25.25 # TheSeven: did you find a better fix for the usb issues? 01.25.40 # your fix seems to be working perfectly fine 01.26.57 # maybe the issues reported on nano2g's with my patch are rockbox specific then 01.27.54 # n1s, what issue are you having? 01.28.58 # Viperfang: connecting usb would hang the ipod completely, i made a patch that fixes it for me but some nano 2g users reported that it made usb conncetions less reliable on their players 01.28.59 # i've tested the same patch on my nano2g, and passed it to several other people, nobody noticed a regression 01.29.35 # mine does that occasionally 01.29.42 # the code has made its way into freemyipod svn in the meantime, so i'd expect bug reports to come up with the next emcore release, if at all 01.29.48 # (Classic 2nd gen) 01.30.03 # that's probably a different, software-side issue though 01.30.23 # the one we're talking about was 100% reproducible, USB connections never worked unless booted through DFU 01.30.30 # TheSeven: ok, i'll keep an eye out for that and wait a bit longer 01.30.37 # It did it all the time until the disk was partitioned instead of having the filesystem directly on the disk 01.31.12 # i have testing builds with the patch applied both to emcore and rockbox lying around in case you find some testers 01.31.27 # and you might want to do regression testing for the rockbox bootloader, as i've only tested it with emcore 01.31.29 Join CaptainKewl [0] (captainkew@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 01.31.45 # Viperfang: that's a purely pc-side issue then 01.32.53 # heh, we have rgb666 on the ipod classic as well! 01.33.58 # let's see if rgb666 is sufficient to get away without dithering, while maintaining reasonably good picture quality 01.34.37 # What android package do I need to compile rockbox? 01.37.02 Nick finn is now known as Farthen (~Farthen@static.225.178.40.188.clients.your-server.de) 01.38.18 # TheSeven: is a bad rockbox bootloader recoverable on the nano2g? 01.38.28 # yes 01.38.50 # on the nano2g this works like on the old ipods 01.39.00 # i just need to find a voulonteer then :) 01.39.26 # the bootloader is just written to the firmware partition, and disk mode is still accessible no matter what nonsense we're doing :) 01.39.57 # that is very nice :) 01.40.38 Quit n1s (Remote host closed the connection) 01.51.39 *** Saving seen data "./dancer.seen" 01.51.58 # * TheSeven starts to understand how all those lcds *really* work 02.05.44 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 02.11.57 Join Horschti [0] (~Horscht@xbmc/user/horscht) 02.13.22 Join Rob2222 [0] (~Miranda@p5DE4BC14.dip.t-dialin.net) 02.14.53 Quit Horscht (Ping timeout: 250 seconds) 02.17.10 Quit Rob2223 (Ping timeout: 260 seconds) 02.26.35 Quit CaptainKewl (Ping timeout: 250 seconds) 02.29.58 Quit liar (Quit: hallowed are the ori!) 02.31.47 Quit robin0800 (Quit: Leaving) 02.46.07 Join fdinel [0] (~Miranda@modemcable036.124-131-66.mc.videotron.ca) 03.05.10 Join robin0800 [0] (~robin0800@genkt-050-079.t-mobile.co.uk) 03.05.45 Quit keyb_gr (Ping timeout: 258 seconds) 03.14.08 Join kyle [0] (~Phalangee@96-40-242-33.dhcp.eucl.wi.charter.com) 03.14.40 Nick kyle is now known as Guest31298 (~Phalangee@96-40-242-33.dhcp.eucl.wi.charter.com) 03.16.42 Nick Guest31298 is now known as Phalangees (~Phalangee@96-40-242-33.dhcp.eucl.wi.charter.com) 03.17.37 Quit Rob2222 (Quit: Rob2222) 03.23.52 Quit bluebroth3r (Ping timeout: 252 seconds) 03.24.11 Quit fs-bluebot (Ping timeout: 255 seconds) 03.25.22 Join fs-bluebot [0] (~fs-bluebo@g224237141.adsl.alicedsl.de) 03.25.47 Join bluebrother [0] (~dom@g224237141.adsl.alicedsl.de) 03.25.48 Quit bluebrother (Changing host) 03.25.48 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 03.28.18 Quit pamaury (Remote host closed the connection) 03.34.05 # wtachi: saratoga: rockbox isnt going to use librbcodec directly? 03.34.37 # * JdGordon suggests libs/rbcodec 03.40.10 # JdGordon: no, it is 03.40.30 # root.make includes rbcodec.make, which builds librbcodec.a, which is then linked into rockbox 03.41.16 # http://www.rockbox.org/irc/log-20110712#22:11:04 worries me 03.41.47 # but ok, if it is going to use the .a then you should pull all the code out of apps/ 03.45.02 # saratoga was doubtful, while I think having its own directory is cleaner 03.45.10 # I'm going to bring it up in my next ML post 03.45.50 # use the libs folder already there 03.51.40 *** Saving seen data "./dancer.seen" 03.52.40 Quit MethoS- (Remote host closed the connection) 03.57.27 Join mshathlonxp [0] (~athlonmpp@5ad4efa9.bb.sky.com) 03.58.45 Quit Zarggg (Quit: Rebooting client...) 03.58.46 Join msh [0] (~athlonmpp@5ad4efa9.bb.sky.com) 03.59.39 Quit mshathlonxp (Disconnected by services) 03.59.44 Nick msh is now known as mshathlonxp (~athlonmpp@5ad4efa9.bb.sky.com) 04.03.16 Join Gamefreak264 [0] (~kecj@unaffiliated/gamefreak264) 04.03.26 Join Keripo [0] (~Keripo@c-76-28-198-27.hsd1.wa.comcast.net) 04.04.06 Quit mshathlonxp (Ping timeout: 240 seconds) 04.08.10 Join mshathlonxp [0] (~athlonmpp@5ad4efa9.bb.sky.com) 04.08.34 Quit TheSeven (Disconnected by services) 04.08.48 Join [7] [0] (~TheSeven@rockbox/developer/TheSeven) 04.09.18 # <[Saint]> Anyone have an opinion on the "cleanest"/best way to include a .nomedia file in the /rockbox dir on RaaA? 04.10.16 # <[Saint]> I'm wondering: a: Generate it as needed, or b: copy it as needed from somewhere in the source as required. 04.10.46 # * [Saint] is sick of seeing all the .wps related images in his Gallery ;D 04.12.01 # <[Saint]> (and if I read a commit right...we _should_ be able to do themeable keyclick, track skip beep, tones in the future...so we don't want those being picked up by Google Music and Friends either) 04.14.35 Quit fs-bluebot (Ping timeout: 255 seconds) 04.15.43 Join fs-bluebot [0] (~fs-bluebo@g224237222.adsl.alicedsl.de) 04.16.19 Quit bluebrother (Ping timeout: 252 seconds) 04.17.51 # jhMikeS: speaking of which... whats does themeable tones mean? 04.17.53 Join bluebrother [0] (~dom@g224237222.adsl.alicedsl.de) 04.17.54 Quit bluebrother (Changing host) 04.17.54 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 04.18.06 # load a .wav and play it for the keyclock/whatever? 04.19.19 # <[Saint]> JdGordon: That's what I assumed, yeah. I guessed it wouldn't be limited to . though, we'd probably have the full reign of all the supported codecs since the playback engine is handling it. 04.30.35 Quit sasquatch (Ping timeout: 260 seconds) 04.33.57 Quit pixelma (Disconnected by services) 04.33.59 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.34.01 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.34.18 Quit amiconn (Disconnected by services) 04.34.18 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.34.36 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.37.15 Quit ricemark20 (Quit: Leaving) 04.39.48 Nick Gamefreak264 is now known as Taco_Princess (~kecj@unaffiliated/gamefreak264) 04.40.29 Quit scorche (Disconnected by services) 04.40.37 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 04.40.37 Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) 04.42.44 Join ricemark20 [0] (~mark@99-20-182-188.lightspeed.elgnil.sbcglobal.net) 04.42.54 Quit ricemark20 (Remote host closed the connection) 05.07.28 Join Strife89 [0] (~Strife89@69.85.112.241) 05.09.08 Quit robin0800 (Quit: Leaving) 05.09.47 Join robin0800 [0] (~robin0800@genkt-057-207.t-mobile.co.uk) 05.11.06 Quit ender| (Ping timeout: 240 seconds) 05.13.28 Quit robin0800 (Client Quit) 05.13.56 Join robin0800 [0] (~robin0800@genkt-050-079.t-mobile.co.uk) 05.17.33 Quit factor (Read error: Connection reset by peer) 05.22.21 Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche) 05.24.15 Join ender| [0] (~ender1@2a01:260:4094:1:225:90ff:fe2a:83dc) 05.31.22 Quit mc2739 (Quit: leaving) 05.31.24 Quit ps-auxw (Read error: Operation timed out) 05.31.45 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 05.31.51 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 05.33.55 Join Scromple_ [0] (~Simon@115-64-195-104.tpgi.com.au) 05.34.41 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 05.35.17 Join factor [0] (~factor@74.197.205.204) 05.35.42 Quit Horschti (Quit: Verlassend) 05.36.02 Quit Scromple (Ping timeout: 255 seconds) 05.42.48 Quit Strife89 (Quit: Reboot) 05.51.44 *** Saving seen data "./dancer.seen" 06.01.15 Quit phanboy_iv (Read error: Connection reset by peer) 06.05.51 Quit factor (Read error: Connection reset by peer) 06.07.59 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 06.08.47 Join Strife89 [0] (~Strife89@69.85.112.241) 06.23.40 Join factor [0] (~factor@74.197.205.204) 06.32.40 Quit Strife89 (Ping timeout: 240 seconds) 06.38.51 Quit robin0800 (Quit: Leaving) 07.10.45 Join sasquatch [0] (~username@46.115.20.120) 07.36.10 Quit factor (Ping timeout: 240 seconds) 07.51.47 *** Saving seen data "./dancer.seen" 08.04.34 Quit ReimuHakurei (Read error: Connection reset by peer) 08.04.54 Join ReimuHakurei [0] (~reimu@74.112.212.15) 08.20.13 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 08.20.13 Join factor [0] (~factor@74.197.205.204) 08.21.15 Join Rob2222 [0] (~Miranda@p4FFF29D5.dip.t-dialin.net) 08.27.35 Join antil33t [0] (~antil33t@124-197-33-15.callplus.net.nz) 08.28.50 Quit tchan (Read error: Connection reset by peer) 08.29.43 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 08.33.53 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 08.43.18 Join ender` [0] (~ender@foo.eternallybored.org) 08.46.30 Join stripwax_ [0] (~Miranda@87-194-34-169.bethere.co.uk) 08.48.02 Quit stripwax (Ping timeout: 240 seconds) 08.57.45 Quit user890104 () 09.02.15 # Has the android port been improved in the past few months? 09.05.23 # Downloading the latest build and will decide for myself 09.05.39 # <[Saint]> There has been multiple commits that touch it...if thats what you're asking. 09.05.49 # <[Saint]> Its still in active development. 09.06.41 # it's still not what I'd call polished 09.07.06 # it looks more or less how I remember it being a few months ago 09.07.21 # <[Saint]> the look won't change. 09.07.34 # Oh 09.07.42 # I was thinking maybe the UI would be tweaked for android 09.07.56 # <[Saint]> that's far from being terribly important at this stage. 09.08.12 # I don't personally think that the UI works very well with touch controls 09.08.22 # <[Saint]> I'm working on a theme for it...but real life and sickness has got in the way lately. 09.08.24 # anyway, what are the major things being ironed out right nwo on the android port? 09.08.25 # Taco_Princess: the plan is to make a "rockbox library" and a separate android client which uses this library. 09.08.46 # but this will take a while 09.09.03 # <[Saint]> Taco_Princess: what resolution is your device? 09.09.15 # <[Saint]> I may have a theme that you'll find a lot better than the present one. 09.09.34 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 09.09.41 Quit bertrik (Changing host) 09.09.41 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 09.09.58 Quit BHSPitMonkey (Quit: Ex-Chat) 09.10.29 # I have a droid incredible 09.10.36 # which I think is 480x800? 09.10.41 Quit Unhelpful (Ping timeout: 255 seconds) 09.10.41 # <[Saint]> 480x800? 09.10.45 # <[Saint]> yeah..one sec. 09.10.49 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 09.12.57 # <[Saint]> Taco_Princess: Extract http://www.datafilehost.com/download-79c8dae1.html to your sd card, then boot Rockbox and select "DEFAULT" from Settings - Theme Settings - Browse Theme Files 09.15.04 # Eh... Thanks. I already uninstalled rockbox though. I didn't really see myself using it alot. 09.15.22 # I like it for dedicated music players 09.15.28 # but it doesn't seem a good fit for android 09.15.31 # atleast not for me 09.16.25 # <[Saint]> Yeah...I mean who wants to be able to play ~~25+ different codecs anyway, and have the finest control that any media player for Android offers anyway, right? ;) 09.17.20 # No, I'm not bashing what you're doing. It just isn't to my tastes. 09.17.48 # <[Saint]> I was being sarcastic, don't mind me. :D 09.19.05 Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.) 09.21.23 Join [Saint] [0] (~Saint]@202.180.121.188) 09.23.28 # Taco_Princess: you are not alone. many of us core devs would like a native android UI too. it just takes a lot of work. 09.25.25 Quit T44 (Read error: Connection reset by peer) 09.28.15 Quit boghog (Ping timeout: 260 seconds) 09.33.46 Join lebellium [0] (~chatzilla@i02m-212-194-176-149.d4.club-internet.fr) 09.34.02 Quit Scromple_ (Read error: Connection reset by peer) 09.34.16 Quit lebellium (Client Quit) 09.37.29 Quit [Saint] (Remote host closed the connection) 09.38.16 Quit bertrik (Ping timeout: 246 seconds) 09.38.37 Join [Saint] [0] (~Saint]@202.180.121.188) 09.41.07 Quit [Saint] (Read error: Connection reset by peer) 09.41.57 Join [Saint] [0] (~Saint]@202.180.121.188) 09.50.18 Join boghog [0] (~aphax@53537DC3.cm-6-4b.dynamic.ziggo.nl) 09.51.49 *** Saving seen data "./dancer.seen" 10.04.00 Join FoH [0] (~foh@adsl-98-83-121-150.bhm.bellsouth.net) 10.09.38 Quit Keripo (Ping timeout: 240 seconds) 10.18.34 Quit wtachi (Quit: &) 10.21.02 Quit mc2739 (Read error: Connection reset by peer) 10.23.31 Quit stripwax_ (Quit: http://miranda-im.org) 10.25.29 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 10.36.04 Join LinusN [0] (~linus@giant.haxx.se) 10.37.34 Join mdipolt2 [0] (~mdipolt@85-126-127-58.static.xdsl-line.inode.at) 11.02.21 Join Keripo [0] (~Keripo@c-24-16-134-250.hsd1.wa.comcast.net) 11.29.50 Join Keripo1 [0] (~Keripo@c-76-28-198-27.hsd1.wa.comcast.net) 11.31.50 Quit Keripo (Ping timeout: 258 seconds) 11.38.45 Quit antil33t () 11.47.37 Join XPMUser [0] (~XPMUser@exchange.it-partner.de) 11.47.49 Join Viperfang_ [0] (~Viperfang@external.viperfang.net) 11.47.50 Quit Viperfang (Ping timeout: 255 seconds) 11.47.58 Quit XPMUser (Client Quit) 11.48.13 Quit krazykit (Ping timeout: 255 seconds) 11.48.16 Join krazykit` [0] (~krazykit@206.183.185.8) 11.51.50 *** Saving seen data "./dancer.seen" 11.53.43 Join Viperfang__ [0] (~Viperfang@external.viperfang.net) 11.54.05 Join user890104 [0] (~Venci@213.226.63.147) 11.55.54 Join Farthen_ [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 11.55.54 Quit Farthen (Disconnected by services) 11.56.30 Quit [Saint] (Quit: Quit...) 11.57.56 Join [Saint] [0] (~Saint]@202.180.121.188) 12.05.31 Quit Viperfang_ (Ping timeout: 255 seconds) 12.05.31 Quit fs-bluebot (Ping timeout: 255 seconds) 12.05.32 Quit boghog (Ping timeout: 255 seconds) 12.14.18 Join fs-bluebot [0] (~fs-bluebo@g224237222.adsl.alicedsl.de) 12.14.26 Join boghog [0] (~aphax@53537DC3.cm-6-4b.dynamic.ziggo.nl) 12.17.24 Quit Taco_Princess (Ping timeout: 252 seconds) 12.20.55 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 12.20.56 Quit pamaury (Changing host) 12.20.56 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.25.24 Quit eGen_ (Quit: ... gettin' screew my wife ....) 12.25.47 Join eGen_ [0] (generat0r@gate.mmdecin.cz) 12.32.25 Quit n17ikh (Ping timeout: 240 seconds) 12.37.00 Join GermanMushroom [0] (~c@s5146db6a.adsl.wanadoo.nl) 12.38.35 Join n17ikh [0] (~n17ikh@c-174-56-150-44.hsd1.sc.comcast.net) 12.38.50 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 12.49.26 Quit Keripo1 (Quit: Leaving.) 12.51.03 Nick Viperfang__ is now known as Viperfang (~Viperfang@external.viperfang.net) 12.52.22 # undefined reference to 'main' trying to build the sims... http://pastebin.com/UcQZAdtf 12.52.26 # anyone seen that recently? 13.17.50 Quit simonlnu (Ping timeout: 276 seconds) 13.28.43 Quit ruskie (Excess Flood) 13.35.52 Join ricemark20 [0] (~mark@99-20-182-188.lightspeed.elgnil.sbcglobal.net) 13.42.44 Quit stripwax (Quit: http://miranda-im.org) 13.51.54 *** Saving seen data "./dancer.seen" 13.54.38 Quit n17ikh (Ping timeout: 255 seconds) 13.57.10 Quit sasquatch (Ping timeout: 240 seconds) 13.58.41 Join sasquatch [0] (~username@46.115.20.120) 13.59.36 Join n17ikh [0] (~n17ikh@c-174-56-150-44.hsd1.sc.comcast.net) 14.02.02 Join ruskie [0] (ruskie@sourcemage/mage/ruskie) 14.02.13 Quit [Saint] (Quit: Quit...) 14.04.55 Join [Saint] [0] (~st.lasciv@202.180.121.188) 14.06.02 Quit [Saint] (Client Quit) 14.06.35 Join [Saint] [0] (~st.lasciv@202.180.121.188) 14.14.25 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 14.22.18 Quit ricemark20 (Remote host closed the connection) 14.22.26 Quit stripwax (Quit: http://miranda-im.org) 14.23.57 Join msh [0] (~athlonmpp@5ad4efa9.bb.sky.com) 14.24.05 Join ricemark20 [0] (~mark@99-20-182-188.lightspeed.elgnil.sbcglobal.net) 14.26.05 Quit mshathlonxp (Ping timeout: 240 seconds) 14.28.39 Nick msh is now known as mshathlonxp (~athlonmpp@5ad4efa9.bb.sky.com) 14.31.05 # <[7]> has anyone ever seen an LCD freak out if you don't write enough dark pixels to it? 14.34.34 # nope 14.39.42 # <[7]> if i slowly fill a part of the screen with white, contrast will steadily decrease, and at some point the LCD will shut off completely and won't go on any more until i soft reset it, even if i write black pixels again 14.40.28 # <[7]> if the number of black pixels drops below ~20% it will shut off 14.40.33 # [7]: yes, I've seen that 14.40.54 # <[7]> at 37% black pixels contrast is perfectly fine 14.40.55 # but it was a software error in higher level code 14.41.11 # <[7]> so the range from 20-40% seems to affect contrast 14.41.33 # <[7]> kugel: something going wrong during panel init? or what do you mean? 14.42.27 # it displayed garbage, the problem was IIRC in bmp code (so that's most probably not your problem) 14.42.53 # <[7]> yeah, but that wouldn't affect the contrast of pixels not being written to, right? 14.43.23 # <[7]> yesterday i had the same issue the other way round: too much black => panel shuts off 14.44.08 # <[7]> also, if i suddenly write a huge pile of white pixels, contrast will stay normal for a quarter of a second and then drop to almost zero 14.44.27 # <[7]> this seems to suggest that something's wrong with one of those charge pumps or something 14.46.05 # <[7]> anyway, being able to poke at the lcd from the command line or python scripts is worth a lot :) 14.46.51 # <[7]> it's terribly inefficient - but hey, it works :) 14.46.53 # <[7]> at least for testing 14.51.34 Quit Xerion (Read error: Connection reset by peer) 14.52.08 Join Xerion [0] (~xerion@5419A766.cm-5-2c.dynamic.ziggo.nl) 15.03.50 # can someoen try building the sims please? codecs arent linking for me... 15.07.07 # is that the SDL (200) 15.07.17 # <[Saint]> no. 15.07.28 Quit krazykit` (Read error: Operation timed out) 15.07.53 # sdl is actually what i shold have said :) 15.07.53 # smis/s 15.08.03 # dl will be the same for that though 15.08.15 # <[Saint]> heh...mind reader ;) 15.08.36 # and terrible ssh lag causing horrible typos 15.11.17 # <[Saint]> gah.... 15.11.24 Quit ricemark20 (Remote host closed the connection) 15.11.29 # * [Saint] flips over to ubuntu to build JdGordon his bloody sim ;) 15.11.39 Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.) 15.12.11 # hmm, cba to configure sdl 15.12.24 Join leavittx [0] (~leavittx@89.221.199.187) 15.13.01 Join ricemark20 [0] (~mark@99-20-182-188.lightspeed.elgnil.sbcglobal.net) 15.13.14 Quit GermanMushroom (Quit: Ik ga weg) 15.13.27 Join OY1R [0] (~Reggy@212.55.55.61) 15.13.55 Join [Saint] [0] (~Saint]@202.180.121.188) 15.14.49 # <[7]> JdGordon: use a sane IRC client then :) 15.15.05 # * JdGordon thought ssh+screen+irssi was sane? 15.15.12 # its my shit net connection 15.15.56 # How can i convert avi and or mp4 files to be playable on an Ipod ? 15.16.45 Quit mshathlonxp (Ping timeout: 240 seconds) 15.21.19 # make that an ipod gen5 with rockbox installed. 15.22.38 # <[Saint]> OY1R: WinFF 15.22.48 # ipod classic 5th gen 15.23.03 # <[Saint]> there's no such thing 15.23.17 # <[Saint]> what you have is a 5th gen, a Video...not a Classic 15.23.28 # Oh 15.24.04 # <[Saint]> And the application you want to convert your media painlessly is called WinFF 15.24.11 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 15.24.15 # <[Saint]> google it. It has presets for all Rockbox targets 15.29.20 Quit OY1R (Ping timeout: 276 seconds) 15.29.25 # * JdGordon fears every cabbie.wps is going to need updating pretty soon 15.29.39 # <[Saint]> why? 15.30.21 # <[Saint]> draw ordering going back in won't (or _shouldn't_) break anything in cabbie. 15.30.38 # <[Saint]> iirc I was bloody careful not to overlap *anything* 15.31.50 # we'll find out :) 15.32.32 # <[Saint]> It won't even break my RaaA cabbie that *does* rely on some overlapped images 15.32.56 # tiny bit of image corruption in e200's cabbie 15.33.03 # <[Saint]> (because the images that overlap do so for a reason, and the transparency used means it doesn't matter which is drawn overtop of the other) 15.33.19 # shuffle icon 15.33.57 # <[Saint]> image corruption? what would be causing that? that sounds like something other than simply draw ordering is breaking things. 15.34.51 # you're going to love this... 15.35.00 # %?ps<%xd(D)> 15.35.11 Join Taco_Princess [0] (~kecj@unaffiliated/gamefreak264) 15.36.04 # <[Saint]> I kinda hope someone else steps up if cabbie *does* break...I really don't have the time of late. I've either been too busy or too sick or too in hospital to finish the RaaA cabbie I'm workign on. And that's up the top of my todo. 15.36.25 Join OY1R [0] (~Reggy@212.55.55.61) 15.36.27 # <[Saint]> JdGordon: what's wrong there...? 15.36.39 # I'm not sure, but I know you *hate* that style 15.36.40 # dissconnected 15.36.56 # OY1R: we have logs.. 15.37.06 # <[Saint]> JdGordon: Hmmm....? Um, no? there's a very high likelyhood I wrote that ;) 15.37.20 # [14:31:05] <[7]> has anyone ever seen an LCD freak out if you don't write enough dark pixels to it? 15.37.33 # JdGordon: sim/sdl/w32sim builds work fine here 15.37.34 # really? unlikely.. the rest of the file uses the old conditional syntax 15.37.45 # mc2739: thanks, yeah, issue with my checkout, its working for me again 15.37.49 # <[Saint]> the syle I *hate* is pointless inclusion of the false param when it's unneeded. (is. %?XX 15.38.03 # If it's a normally-black lcd (which I guess it is) this means the charge pump is too weak (probably because of settings) to supply all pixels 15.38.22 # yea i see thanks. 15.38.24 # The complete shutoff is probably some protective circuit for the charge pump and/or the panel itself 15.38.33 # <[7]> amiconn: it's normally-white 15.38.47 # the connection onboard is ok for speed but kinda unstable at times. 15.39.01 # Hmm, that's odd 15.39.17 # <[7]> so it's a bit weird that the more load the charge pump has, the better the constrast will get 15.39.28 # <[Saint]> JdGordon: what res is the e200? 15.39.38 # <[7]> so i'd assume that it's just some wrongly-set regulation parameters for the charge pump 15.39.42 # <[Saint]> also...what do you mean by "old conditional syntax"? 15.40.37 # do i need to install anything special on rockbox in order to view the videos ? 15.40.39 # The 1st/2nd Gen LCD (greyscale) has a similar problem (contrast depends on amount of black pixels, pixel bleeding). Rockbox has improved charge pump settings compared to the OF, but even those cannot avoid the effect completely 15.40.50 # <[Saint]> "%?ps<%xd(D)>" is what all of the cabbies I updated are using...I don't get what's 'wrong" there. 15.40.57 # (this is passive matrix, hence the bleeding) 15.40.58 # <[Saint]> JdGordon: ^ 15.41.53 Quit ricemark20 (Remote host closed the connection) 15.42.06 # <[7]> amiconn: the panel itself stays on after that shutoff, it's just that the contrast drops to a barely visible value 15.42.50 # <[7]> you can only tell that there's still content on the screen from one specific angle, and from that angle you'll see bleeding along the rows as well 15.43.08 # <[7]> so this also tells me that something is wrong with the charge pump 15.43.18 # <[7]> too bad i don't have a datasheet for that bugger 15.43.34 Join ricemark20 [0] (~mark@99-20-182-188.lightspeed.elgnil.sbcglobal.net) 15.43.35 # <[7]> vendor 0x38, device 0xc4, in case you've ever seen that 15.44.08 # [Saint]: nothing is "wrong" there... i need to fix this bug :) 15.44.10 # <[7]> the general protocol matches this controller: http://displaytech-us.com/pdf/application/TFT_DriverIC/ILI9340.pdf 15.44.26 # <[7]> however some of the configuration registers don't match 15.44.42 # <[Saint]> JdGordon: I was wondering what "the old conditional syntax" is...all the cabbies I updates have pretty much identical code. 15.44.55 # <[Saint]> *s/updates/updated/ 15.46.15 # <[7]> for example, registers e0/e1 are blue gamma control, e2/e3 green, e4/e5 red, each one of them gets 11 bytes of data 15.46.47 # [Saint]: %?bc<%xd(Ba)|%xd(Bb)> 15.47.51 # <[Saint]> that's perfectly fine if there's two cases in the condition...that also isn't anything to do with shuffle. I'm confused. 15.48.24 # never mind 15.49.05 Join mshathlonxp [0] (~athlonmpp@5ad4efa9.bb.sky.com) 15.49.21 # <[Saint]> iirc, %?bc is...hold? which has an image for the open/closed lock. shuffle just displays in the true case as the "backdrop" for it is (where possible) incorperated into the backdrop. 15.50.39 # <[Saint]> ht main thing that confised my was "old conditional syntax"...as, afaik, there's only ever been the one. So, the "old" syntax is still the "new/current" syntax for conditions. 15.50.49 # <[Saint]> gah! 15.51.04 # <[Saint]> *the, *confused, *me 15.51.14 # conditional syntax for display subimages 15.51.57 *** Saving seen data "./dancer.seen" 15.52.25 # <[Saint]> it's the *new* style (the one that's used in like...~2 places in the source) that I hate. 15.52.43 Quit leavittx (Read error: Operation timed out) 15.53.01 # and we've come full circle 15.53.20 # <[Saint]> I much prefer the "long winded" style...as you don't have to have the subimages ordered in any particular way, and can display them out of sync. 15.54.44 Join leavittx [0] (~leavittx@89.221.199.187) 15.58.25 Quit mshathlonxp (Ping timeout: 240 seconds) 16.00.20 Quit OY1R (Ping timeout: 276 seconds) 16.01.16 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 16.02.07 Join Strife89 [0] (~Strife89@69.85.112.241) 16.17.40 Join mshathlonxp [0] (~athlonmpp@cpc9-pete9-2-0-cust168.4-4.cable.virginmedia.com) 16.37.40 Part LinusN 16.40.13 Join GermanMushroom [0] (~c@s5146db6a.adsl.wanadoo.nl) 16.42.30 Join msh [0] (~athlonmpp@cpc9-pete9-2-0-cust168.4-4.cable.virginmedia.com) 16.42.45 Quit mshathlonxp (Ping timeout: 240 seconds) 16.44.15 Nick msh is now known as mshathlonxp (~athlonmpp@cpc9-pete9-2-0-cust168.4-4.cable.virginmedia.com) 16.49.01 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 16.50.10 Quit Strife89 (Quit: Leaving home-away-from-home base.) 16.55.25 Quit einhirn (Ping timeout: 250 seconds) 16.56.35 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 17.09.15 Part Zagor 17.09.25 Quit mshathlonxp (Ping timeout: 240 seconds) 17.10.48 # what does HAVE_BUTTON_DATA means ? 17.13.41 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.19.43 Join simonlnu [0] (FfSxKw0M6Z@unaffiliated/simonrvn) 17.41.56 Quit sasquatch (Ping timeout: 276 seconds) 17.42.45 Join sasquatch [0] (~username@46.115.20.120) 17.45.18 Join stripwax_ [0] (~Miranda@87-194-34-169.bethere.co.uk) 17.45.20 Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) 17.45.26 # pamaury: ping 17.45.46 # pong 17.46.56 Quit stripwax (Ping timeout: 264 seconds) 17.48.54 # do I need to somehow initialize usb serial driver in rb? 17.49.29 # no, it is done by the core 17.49.40 # usb_core.c, on set config 17.49.43 # iirc 17.49.50 # or something similar anyway 17.51.14 # weird. 17.51.58 *** Saving seen data "./dancer.seen" 17.52.14 # why ? 17.54.40 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 17.54.41 # I added printf("active: %d, length: %d", active, length) at the begining of usb_serial_send() and I always get active=0 17.55.19 Quit factor (Read error: Connection reset by peer) 17.55.59 # pamaury:^ 17.57.04 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 17.58.23 # when do you call it ? 17.58.51 Quit stripwax_ (Ping timeout: 258 seconds) 17.59.12 # if active=false it means that init_connection is never called so you never receive/process the set config packet 17.59.21 # or your driver is not enable 18.00.29 # omg, tweaking the s3c2440 target is a real nightmare 18.00.56 # pamaury: http://www.pastie.org/2207884 - this is my bootloader code. 18.01.41 # the device enumerates correctly 18.02.54 # this is to be expected: when you call usb_serial_send, the device has not yet completely enumerated, so the driver has not been completely initialized 18.03.12 # except if this hacky sleep(HZ/2) does the work 18.03.28 # HZ*2 18.03.36 # but this doesn't seem to matter 18.04.10 # what's the less hacky solution? 18.05.11 # it's doesn't really matter, I think it's buffered correctly so calling it at any time should do 18.05.34 # but you data wiull be discarded :-/ 18.06.23 # if it wasn't the bootloader, you could listen to messages but I'm not sure it works in the bootloader 18.06.49 # so if I were you, I would replace yield(); by usb_serial_send("bla"); sleep(HZ / 2); 18.06.56 # and delete this sleep(HZ / 2) 18.07.16 # lets try 18.08.55 # this doesn't work - active is never 1 18.09.52 # then you device doesn't enumerate properly 18.10.07 # or the driver is not enabled 18.10.49 # see usb_core.c: USB_REQ_SET_CONFIGURATION is the request which trigger the init_connection 18.10.56 # see if it is received 18.11.06 # and check that the serial driver is actually enabled 18.11.15 # pamaury: http://www.pastie.org/2207937 - output from lsusb -v 18.11.29 # so it *does* enumerate 18.11.49 # complete enumerate ends when sending the set configuration packet 18.12.52 # what about dmesg ? any error ? 18.13.09 Join factor [0] (~factor@74.197.205.204) 18.14.07 # pamaury: wireshark shows host->device SET CONFIGURATION Request and device->host SET CONFIGURATION Response 18.14.24 # dmesg doesn't show any error 18.14.53 # then the serial driver is not initialized, that could happen if usb_serial_request_endpoints fails for example 18.15.06 # you should really debug usb_serial to see what is called and what is the result 18.15.34 # than it shouldn't show bulk endpoints in lsusb isn't it? 18.15.36 Quit stripwax (Quit: http://miranda-im.org) 18.16.36 # good point 18.17.06 # then check that USB_REQ_SET_CONFIGURATION is processsed and see why it doesn't call the init_connection of usb_serial 18.19.56 # good catch - USB_REQ_SET_CONFIGURATION is not processed. Where should I dig? 18.20.57 Join wtachi [0] (~wtachi@65.190.12.236) 18.22.34 # what mean of debugging do you have ? 18.22.39 # lcd 18.22.53 # I would suggest to dump all control requests in usb_core_control_request 18.23.14 # that's probably too much but you wrap up, only the last one will be interesting 18.23.58 # output to lcd is painfully slow so I guess I'll hit timing issues 18.24.58 # possible, you should try and see :) 18.25.10 # it's true that printf is not really fast 18.25.29 # what exactly is interesting? what fields of req? 18.25.54 # at least bmRequestType and bRequest; wValue is interesting too 18.26.30 # you could always hack something to buffer the output and print it in the main loop of your bootloader 18.27.21 Join msh [0] (~athlonmpp@5ad4ef88.bb.sky.com) 18.31.06 # pamaury: http://www.pastie.org/2208030 18.32.24 # Does someone know if the "toolset" field on tools/configure is actually used ? I doesn't seem to really work :-/ 18.33.07 # set configuration is never received by the device 18.33.19 # it's request 9 18.34.05 Quit mystica555_ (Ping timeout: 240 seconds) 18.34.24 # I don't understand this at all than 18.35.24 # first two requests are get device desc, then get config desc, then various strings 18.35.37 # does this match the wireshark output ? 18.36.05 Quit msh (Ping timeout: 240 seconds) 18.36.34 Join mshathlonxp [0] (~athlonmpp@5ad4ef88.bb.sky.com) 18.37.22 # yes 18.38.06 # but wireshark show also SET CONFIGURATION Request and SET CONFIGURATION Response at the very end 18.39.14 Join msh [0] (~athlonmpp@5ad4ef88.bb.sky.com) 18.39.17 # with which status ? 18.40.39 # Response is with URB status: Success (0) 18.40.45 Quit mshathlonxp (Ping timeout: 240 seconds) 18.40.54 Nick Farthen_ is now known as Farthen (~Farthen@static.225.178.40.188.clients.your-server.de) 18.43.22 Quit mdipolt2 (Ping timeout: 264 seconds) 18.43.25 Quit msh (Ping timeout: 240 seconds) 18.45.54 # then your driver might be buggy 18.52.29 Join mshathlonxp [0] (~athlonmpp@5ad4ef88.bb.sky.com) 18.59.33 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 18.59.40 Quit bertrik (Changing host) 18.59.40 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 19.04.03 # OF doesn't handle other standard request than bRequest == 6 at all 19.04.53 # that seems unlikely 19.05.22 # that is the fact - I am reading OF usb code 19.05.43 # you can't have working usb if you just implement this; and your device is not compliant with the spec 19.06.22 # perhaps the hardware handles everything else ? 19.08.01 # that would explain why wireshark sees the response 19.08.28 # but that would be really weird 19.08.41 # because the hardware cannot really process this one correctly 19.08.45 # hey - its chinese chip :-) 19.09.54 # pamaury: is it possible to send arbitrary crafted control packet to the device? 19.10.23 # of course 19.10.33 # use libusb 19.11.05 # so I guess I have to send known setup request and look how does it look on the device 19.11.11 # you can inspire from this: https://github.com/pamaury/pa-tools/blob/master/usb_debug/usb_debug.c 19.34.39 Join mark___ [0] (~mark@99-20-182-188.lightspeed.elgnil.sbcglobal.net) 19.35.25 Quit ricemark20 (Read error: Connection reset by peer) 19.38.47 # pamaury: how can I set bConfigurationValue field with libusb_control_transfer ? 19.38.50 Join kevku [0] (x@2001:470:28:773:babe:feed:dead:beef) 19.39.37 # it's the low byte of wValue or something similar, there is no such field int he setup packet 19.42.18 # sending this: http://www.pastie.org/2208324 doesn't trigger SETUP interrupt 19.43.14 # try with other values of wValue like 2 19.45.11 # the same, but I accidently set bmRequestType to 0x41 and this triggers SETUP interrupt 19.46.58 # then I would except the chip to have a dedicated interrupt when it receives a set config 19.47.22 # at least datasheet doesn't mention one 19.47.57 # hum see, in dev_info 19.48.14 # there is cfg_number 19.48.21 # and dev_en 19.48.42 # so it's handled by hardware 19.48.57 Join Rob2223 [0] (~Miranda@p4FFF29D5.dip.t-dialin.net) 19.49.14 Join Horscht [0] (~Horscht@xbmc/user/horscht) 19.50.10 # set address is handled in hardware also 19.50.58 # now how to make use of this in rb than 19.52.01 *** Saving seen data "./dancer.seen" 19.52.38 Quit Rob2222 (Ping timeout: 252 seconds) 19.55.02 # what is csr_done ? 19.55.50 # did you get some code for the rk27xx or not ? 19.56.19 # I have OF SDK 19.56.34 # is there code for usb ? 19.56.39 # yes 19.57.20 # csr_done is set by the driver after usb reset/soft disconnect-reconnect cycle 19.58.16 # could you send it to me ? perhaps I can have a look and see how it's done; otherwise we'll have to hack something ugly 20.13.00 Join Keripo [0] (~Keripo@c-76-28-198-27.hsd1.wa.comcast.net) 20.16.04 # wodz: could you see if setting rx0voiden does something ? 20.17.25 # sure 20.19.58 # pamaury: no this doesn't change anything 20.21.27 # it doesn't generate any interrupt ? 20.26.27 # I don't see any unusual irq 20.28.46 Join serenity [0] (~serenity@p4FC68EDF.dip0.t-ipconnect.de) 20.28.51 # hi 20.28.58 # could you dump dev_info at regular intervals ? 20.31.46 # hmm we are probably interested of the change during enumeration right? 20.32.59 # yes, it could be possible to use a tick task to monitor this register 20.34.32 Join MethoS- [0] (~clemens@134.102.106.250) 20.35.17 # in fact I would even go for a little more complicated scheme 20.36.54 Quit mark___ (Remote host closed the connection) 20.41.00 Join ricemark20 [0] (~mark@99-20-182-188.lightspeed.elgnil.sbcglobal.net) 20.42.19 Quit ricemark20 (Remote host closed the connection) 20.48.05 # pamaury: distinct values logged: 0x700000, 0x100000, 0x1000cd 20.51.25 # the code is like this http://www.pastie.org/2208663 20.51.43 # wodz: could you try to set dev_info to 0xffffffff on init (I know it's RO but try anyway :)) 20.54.33 # pamaury: doesn't work 20.55.51 # it seems to be truly RO 20.57.40 # I have another idea but I need to check something 20.59.08 # there is one comment in my blog you should know about: "Is there a port of rb for the desktop? It has so much features desktop programs don't have." 21.01.35 # serenity: SDL RaaA is something like this (in some sense) 21.01.58 # oh, will have a look 21.03.10 Join robin0800 [0] (~robin0800@149.254.61.165) 21.23.23 Join sideral [0] (~sideral@rockbox/developer/sideral) 21.24.25 # pamaury: whats the idea? 21.26.20 # using two configurations in way that config 0 is never used but only config 1. This way, when config 1 is chosen, the register is updated accordingly 21.27.27 # I don't get 21.28.51 # the register is set 0 on reset. But the default config is 0 too, so you can't know when the set configuration request is sent 21.29.27 # aa now I understand 21.29.29 Join Strife89 [0] (~Strife89@69.85.112.241) 21.33.53 Quit mikroflops (Read error: Operation timed out) 21.38.19 Join mikroflops [0] (~yogurt@h-34-156.a238.priv.bahnhof.se) 21.38.38 # hum, I'm a bit puzzled 21.40.38 # pamaury: sending SET CONFIGURATION request changes cfg_num in DEV_INFO and doesn't trigger irq so this is handled purely by hardware 21.41.48 # yes, but the values you showed me don't reflect a configuration cfg_num of 0 even though the rockbox's first config has number 1 21.41.53 # so it's a bit strange 21.42.50 # the values I showed you all have cfg_num = 0 21.43.08 # yes, so this is strange 21.43.30 # could you see with wireshark what is the wValue associated with set configuration ? 21.44.22 # but sending this: libusb_control_transfer(hdev, 0, 9, 1, 0, 0, 0, 512) changes this register 21.44.53 # although only cfg_num=0 or cfg_num=1 is accepted 21.46.21 # I'm interested in the value sent by the kernel 21.46.49 Quit robin0800 (Read error: Connection timed out) 21.47.24 # interesting - kernel sends wValue = 1 and this doesn't change DEV_INFO. 21.47.47 Join robin0800 [0] (~robin0800@149.254.61.37) 21.47.57 # but initial cfg_num (before our usb reset) is 1 21.48.03 Part serenity ("Konversation terminated!") 21.50.00 # and sending packet like described above changes cfg_num in DEV_INFO 21.50.44 # could you change bConfigurationValue in usb_core.c to something else ? 21.52.02 *** Saving seen data "./dancer.seen" 21.52.04 # hmm it ignores first request for some reason. You have to send it twice to take effect 21.55.26 # it doesn't like bConfigurationValue = 3 21.55.43 # what do you mean ? 21.57.07 # if I choose 0 or 1 I can influence DEV_INFO by sending twice the request, 2, 3 is completely ignored (although wireshark shows successful response) 21.59.17 # this core is weird at best :-) 22.02.09 # indeed 22.02.55 # hum, wait, there is bit 7 is dev_info which might be interested 22.03.49 # can you dump dev_info on each irq ? 22.04.08 # ok 22.10.25 # pamaury: 22.10.47 Join serenity [0] (~serenity@p4FC68EDF.dip0.t-ipconnect.de) 22.11.10 # DEV_INFO captured in ISR is always 0x100000 but captured at the end of main() is 0x1000e0 22.11.41 # so. RB → Ipod Nano, Ipod Nano → Car Stereo, Controlling Car Stereo → Ipod doesn't work 22.12.14 # I know for the set_address command there is a special sequence in some USB chipsets 22.12.25 # wodz: end of main ? but you have an infinite loop :-/ 22.12.39 # hmm first two calls of ISR have 0x700000 actually 22.12.40 # so the response to the set_address command is still sent as a response from address 0, IIRC 22.12.49 # pamaury: just befor while(1) 22.13.07 Quit benedikt93 (Quit: Bye ;)) 22.13.56 Quit GermanMushroom (Ping timeout: 264 seconds) 22.14.07 # bertrik: this is not about set address, this is about set configuration 22.14.15 Quit [Saint] (Ping timeout: 246 seconds) 22.14.31 # just a suggestion, there could be a similar mechanism 22.15.18 # I can't think of a reason why hardware would ever care about the confiuration number 22.15.39 # meh, it's a chinese chip ! ;) 22.16.08 Join [Saint] [0] (~st.lasciv@202.180.121.188) 22.19.46 # pamaury: there is Start Of Frame interrupt source which is masked 22.20.11 # yes but it's not interesting, and far too high rate 22.20.17 # wodz: I doubt you want that 22.21.37 Quit saratoga (Ping timeout: 252 seconds) 22.22.08 Part serenity ("Konversation terminated!") 22.23.09 Quit robin0800 (Quit: Leaving) 22.31.05 # hmm, it looks like the whole SoC is build around Socle's platform - they have ARM7-ej core in offer, in SDK there are references to Socle 22.31.24 # what is a Socle ? 22.32.21 # http://www.socle-tech.com.tw/en/service_47.html 22.36.03 # does it help ? 22.38.16 # no 22.42.15 # could you try something ugly for me ? 22.42.56 # in usb_serial_get_config_descriptor, replace ep_out by ep_in 22.43.02 # heh 22.43.04 # and see what linux says 22.43.08 # :) 22.44.32 # so ep_in will be twice right? 22.44.36 # yes 22.46.45 # linux says OOPS :-) 22.46.53 # cool 22.47.06 # now use wireshark to see if it sends a set configuration 22.47.13 # sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:1a.7/usb1/1-3/1-3:1.0/ep_82' 22.47.37 # and than Call Trace follows 22.47.40 Join robin0800 [0] (~robin0800@149.254.60.33) 22.49.29 # yes it sends set configuration 22.49.49 # but DEV_INFO reads as 0x700000 22.51.00 # hum, I would like to make sure linux doesn't send set configuration to see if the bit 7 of dev_info is relevant 22.59.23 Quit sideral (Ping timeout: 246 seconds) 23.06.08 Quit kevku (Ping timeout: 264 seconds) 23.08.08 Join user890104_ [0] (~Venci@213.226.63.155) 23.10.11 Quit user890104 (Ping timeout: 276 seconds) 23.12.32 Join basti [0] (~basti@xdsl-89-0-71-102.netcologne.de) 23.13.26 Nick user890104_ is now known as user890104 (~Venci@213.226.63.155) 23.15.26 # hi there. is it possible to change the keybindings for the sansa clip in the source code? i would like to acticvate the key lock when "home" is pressed long, like in thr original soft/firmware 23.15.40 Quit leavittx (Ping timeout: 240 seconds) 23.16.47 Quit robin0800 (Quit: Leaving) 23.17.20 Join robin0800 [0] (~robin0800@149.254.60.33) 23.24.52 # basti: it is possible. Look at apps/keymaps/keymap-clip.c 23.31.41 Quit MethoS- (Read error: Connection reset by peer) 23.31.56 Join MethoS- [0] (~clemens@134.102.106.250) 23.35.35 # I think this is about the clip+, since the clip has a hardware keylock 23.37.10 # the question was about clip 23.38.48 # don't they use the same keymap file still? 23.46.58 Quit domonoky (Read error: Connection reset by peer) 23.52.00 Join ReimuHakurei_ [0] (~reimu@74.112.212.15) 23.52.05 Quit ReimuHakurei (Read error: Connection reset by peer) 23.52.07 *** Saving seen data "./dancer.seen" 23.55.01 Quit ReimuHakurei_ (Read error: Connection reset by peer) 23.55.17 Join ReimuHakurei_ [0] (~reimu@74.112.212.15)