--- Log for 29.01.113 Server: pratchett.freenode.net Channel: #rockbox --- Nick: Guest87001 Version: Dancer V4.16 Started: 12 days and 4 hours ago 00.03.08 Join lebellium_ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 00.03.55 Quit lebellium_ (Read error: Connection reset by peer) 00.04.27 Join lebellium_ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 00.04.31 Quit lebellium (Ping timeout: 255 seconds) 00.04.38 Nick lebellium_ is now known as lebellium (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 00.10.24 Quit kevku (Ping timeout: 245 seconds) 00.13.54 Quit prof_wolfff (Ping timeout: 256 seconds) 00.15.32 Quit olspookishmagus (Read error: Operation timed out) 00.18.26 Join olspookishmagus [0] (~pookie@91.132.63.143) 00.18.51 Nick olspookishmagus is now known as Guest39127 (~pookie@91.132.63.143) 00.23.26 Quit jhMikeS (Ping timeout: 256 seconds) 00.26.57 Quit lebellium (Quit: ChatZilla 0.9.89 [Firefox 19.0/20130123083802]) 00.34.07 Quit bertrik (Remote host closed the connection) 01.09.08 Join pamaury_ [0] (~quassel@rockbox/developer/pamaury) 01.10.36 Quit pamaury (Ping timeout: 252 seconds) 01.12.14 Nick pamaury_ is now known as pamaury (~quassel@rockbox/developer/pamaury) 01.15.14 Quit Guest39127 (Quit: You only grow when you are alone.) 01.16.03 Quit pamaury (Quit: this->disconnect()) 01.16.39 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 01.25.17 Quit pamaury (Ping timeout: 276 seconds) 01.25.48 Quit fs-bluebot (Ping timeout: 260 seconds) 01.25.52 Quit bluebrother (Ping timeout: 255 seconds) 01.27.13 Join fs-bluebot [0] (~fs-bluebo@g224237101.adsl.alicedsl.de) 01.28.03 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 01.32.26 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 01.35.43 Join CaptainKewl [0] (~captainke@207-237-110-248.c3-0.nyr-ubr2.nyr.ny.cable.rcn.com) 01.36.38 Quit ben007 (Ping timeout: 256 seconds) 01.40.25 Quit [Saint] (Remote host closed the connection) 01.42.40 Join [Saint] [0] (~saint@rockbox/user/saint) 01.46.01 Join foolsh [0] (~foolsh@nc-76-0-169-20.dhcp.embarqhsd.net) 01.47.49 Quit pamaury (Ping timeout: 244 seconds) 01.48.33 Join ben007 [0] (~smartben@nc-76-0-169-20.dhcp.embarqhsd.net) 01.50.52 Quit foolsh (Client Quit) 01.53.04 Join foolsh [0] (~foolsh@nc-76-0-169-20.dhcp.embarqhsd.net) 01.55.09 # <[Saint]> What does the option "(D)ebug" do in configure? 01.55.40 # <[Saint]> also "S(m)all C lib"... 01.56.50 # It builds rockbox with debug symbols included usually they are not it makes the files smaller with out the debug stuff added 01.57.52 # <[Saint]> Aha, thanks...I was just kinda answering my own question (wrt: debug builds at least) as you answered. 01.58.12 # <[Saint]> But your answer is a whole lot more concise and easier to understand :) 01.58.18 *** Saving seen data "./dancer.seen" 01.58.48 # the small clib I know is well a smaller clib alternative but I don't know the exact merits of it 01.59.25 # <[Saint]> Right, that's how my question should have been phrased. 01.59.31 Join froggymana [0] (~me@sca20378.nebula.msoe.edu) 01.59.35 Quit froggymana (Changing host) 01.59.35 Join froggymana [0] (~me@unaffiliated/froggyman) 01.59.44 # <[Saint]> Not "what is foo?" but "what is the point in/benefit of foo?" 02.02.03 Join krabador [0] (~krabador_@host29-182-dynamic.52-79-r.retail.telecomitalia.it) 02.04.14 Quit froggymana (Read error: Connection reset by peer) 02.07.40 Quit krabador (Remote host closed the connection) 02.17.14 Join froggymana [0] (~me@dhcp-155-92-103-232.nebula.msoe.edu) 02.17.15 Quit froggymana (Changing host) 02.17.15 Join froggymana [0] (~me@unaffiliated/froggyman) 02.17.52 Quit froggymana (Read error: Connection reset by peer) 02.22.17 Join foo|sh [0] (~foolsh@nc-76-0-169-20.dhcp.embarqhsd.net) 02.23.10 Quit foo|sh (Client Quit) 02.23.24 Join foo|sh [0] (~foolsh@nc-76-0-169-20.dhcp.embarqhsd.net) 02.23.45 Quit ben007 (Ping timeout: 252 seconds) 02.24.00 Quit foolsh (Ping timeout: 255 seconds) 02.24.23 Part foo|sh 02.24.43 Join foolsh [0] (~foolsh@nc-76-0-169-20.dhcp.embarqhsd.net) 02.40.50 # * foolsh wonders exactly what the merits of small clib are anyways, is it functionally the same as the regular clib? 02.41.09 Join DmL [0] (~acdc5b42@www.haxx.se) 02.41.31 # Are any of the fuze+ devs around? 02.41.46 # or perhaps Saratoga? 02.43.07 # Anyway, I have a bit of an interesting question, maybe someone here would like to think about: 02.44.06 # On Fuze+ in rockboy, pressing the menu button to go to the menu works flawlessly in the default screen mode, but often crashes in the rotate left (but not rotate right) screen mode! 02.45.31 # That's what I'm working on, I think its an memory alignment problem I was going to file a bug report after I gathered more info, 02.46.25 # I just isolated it to that case today. I tried to reproduce it on the sim, but wasn't able to. Now I wonder if I had the screen rotate option set. 02.46.49 # I've currently on my local repo got a similar function coded into the infoNes plugin 02.50.24 # but also if the screen is unscaled it works fine on left rotate 02.50.51 # So I was basically hoping to port alot of rockboy's functions, but i thought i should work on that bug first. 02.51.00 # that's good info, thanks 02.51.45 # I'm not much of a programmer, but I bet I could make some progress by looking at the different cases and seeing how things are done. 02.52.37 # Have yo made any headway identifying where the problem is? I'm still struggling with understanding the flow of the program. For isntance, what does it execute when the menu opens? 02.53.12 # I rewrote the do_menu to simply exit, and i get the data abort then as well. 02.53.34 # (I don't hae the code in front of me right now and don;t rember the exact name of the function) 02.54.43 # I've only started on it last night, scaled with maintained aspect ratio works fine too, it only crashes when it's stretched across the whole screen 02.56.40 # only four files "lcd.c, menu.c, rockmacros.h, sys_rockbox.c" even mention rotate 02.57.07 # Yeah, the problem seems very localized, . 02.57.44 # When I changed the menu to just exit cleanly it still crashed, but only after displaying the "closing rockboy" splash 02.58.05 # It might be else where like in the frame buffer driver 02.59.30 # at this point i've only played around with some plugins 03.03.17 # i don't know much about how the drivers and such are laid out, or even where they are in the source 03.03.23 # whats more my brother has a fuze+ (red) that works fine no matter what rote option is set mine a black fuze+ 03.03.26 # I've been wanting to conatct Amaury, but haven't had a chance yet. 03.03.36 # hmm, mine's blue. 03.03.40 # rotate* not rote 03.03.57 # 8gb 03.04.47 # 4gb 03.04.53 # nothing there 03.05.44 # have you noticed also you can get to the menu *during gameplay* on many color games, but almost never on classic ones 03.06.26 # (that is, it usually *does not* work evn for color games during menus or splash screens) 03.06.31 # yes some times but most often it just fails 03.07.07 Join krabador [0] (~mint@host29-182-dynamic.52-79-r.retail.telecomitalia.it) 03.08.59 # alright, i'll be back in a few minutes 03.09.06 # i'm currently installing linux on a VM 03.10.54 Join TheSphinX^ [0] (~briehl@p5B323A64.dip.t-dialin.net) 03.13.45 Quit TheSphinX_ (Ping timeout: 245 seconds) 03.19.42 Join saratoga [0] (123e1f35@gateway/web/freenode/ip.18.62.31.53) 03.19.49 # DmL: we have a download link for a ready made VM image if you prefer 03.26.00 Quit foolsh (Ping timeout: 256 seconds) 03.27.57 # i used that for a while, but I've got some weird hardware issues with ubuntu. 03.28.30 # i've already setup the uild environment a couple of times 03.28.44 # at this point, what i really need is a crash course on exporting patches 03.29.07 # cause i have some fixes that bring infones to work with head 03.29.17 # and adds a couple of features 03.32.25 # how do you have hardware issues with a virtual machine? 03.32.43 # anyway, the development guide explains how to upload stuff to gerrit 03.32.53 # we tend not to use patches anymore since we moved to git 03.33.54 Quit saratoga (Quit: Page closed) 03.35.38 # SO GEso gerrit would be the place to put unofficial patches? 03.39.48 Join foolsh [0] (~foolsh@nc-76-0-169-20.dhcp.embarqhsd.net) 03.45.35 # Ah, my brother's fuze+ does data abort just like mine and DmT's, he had the screen scaled but aspect ratio maintained with the left rotation 03.47.35 # yeah, if you scale with aspect it still works 03.47.43 # so it seems only one mode is in error 03.48.37 # He told me it did not, but he's not as curios about stuff. Well it's some where in that area Dmt 03.51.42 # @Saratoga regarding the virtual machine, there were a couple of issues. One was I tried to update the image and it did so incompletely, and secondly the Vmachine just runs this laptop too hard. Thirdly, booting into actual linux leaves me with video and ACPI issues. 03.58.21 *** Saving seen data "./dancer.seen" 04.01.57 Join TheSphinX_ [0] (~briehl@p579CCCF3.dip.t-dialin.net) 04.05.12 Quit TheSphinX^ (Ping timeout: 240 seconds) 04.07.33 # I'm looking in lcd.c in rockboy where all the ifdef(s) sort out the screen offsets and rotation values and I was wondering, does any other targets have the same screen dimensions 320 x 240 and might have the same issue 04.11.33 # i thinnk the ipod and the hrivier do 04.11.40 # have that screen resolution i mean 04.11.58 # but not vertically, I don't think 04.12.09 # ie, in portrait mode, rather than landscape 04.15.59 Join |akaWolf| [0] (~akaWolf@188.134.9.161) 04.16.45 # Thanks DmL, seems the fuze+ sim works flawlessly without error rotated stretched or what ever, I don't think it's in the software I think its in the hardware and that sucks even more. 04.18.01 # i will take a look at the code in a few minutes, there must be something significantly different about rotating left versus right. It might be as simple as it corrupting the config file or something. 04.18.36 # otherwise the bug might be specific enough that amaury could look at the lcd driver and see something 04.19.56 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.19.56 Quit pixelma (Disconnected by services) 04.19.58 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.19.58 Quit amiconn (Disconnected by services) 04.19.58 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.20.00 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.23.40 Join amayer [0] (~alex@h16.24.25.72.ip.windstream.net) 04.35.03 # Sometimes my config file doesn't get written when I change the rotation and scale option, I can then open rockboy after a hardreset with my old settings, but sometimes it does and I erase the option file to get rockboy to work again 04.38.24 # yes, if it crashes with the data abort it hasn't written the config file 04.38.56 # which leads me to believe it has something to do with the one option and how the file is saved, rather than the hardware, or general rockbox software itelf 04.40.48 # although I suppose it must have 8something* to do with the hardware, since it doesn't seem to happen on other hardware 04.47.24 Part amayer 04.50.19 Quit krabador (Quit: Leaving) 05.00.15 # * foolsh set off to collect option files and diff them 05.04.51 # I just noticed another thing about this bug, when able to get back to the menu without an abort pressing the keys seem to be laggy as hell 05.12.52 Quit [7] (Disconnected by services) 05.12.54 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.16.18 # true, i remember that happening as well 05.19.21 Quit foolsh (Ping timeout: 256 seconds) 05.27.16 Join JbstormburstADV [0] (~6274d0f5@www.haxx.se) 05.33.31 # If anyone's there, I'm curious at the moment how extensive the Rockbox support is for the iPod Classic 7G. Also, does anyone have an idea if we'll ever see it dual-boot? 05.34.11 Quit TheSphinX_ (Ping timeout: 245 seconds) 05.34.31 Join TheSphinX^ [0] (~briehl@p579CCD1A.dip.t-dialin.net) 05.37.43 Join foolsh [0] (~foolsh@nc-76-0-169-20.dhcp.embarqhsd.net) 05.38.51 Quit JbstormburstADV (Quit: CGI:IRC) 05.43.31 Join TheSphinX_ [0] (~briehl@p579CCC7B.dip.t-dialin.net) 05.44.58 Quit TheSphinX^ (Read error: Operation timed out) 05.58.24 *** Saving seen data "./dancer.seen" 06.14.26 Join stryaponoff [0] (~stryapono@host-46-50-149-227.bbcustomer.zsttk.net) 06.17.44 Quit pandrew (Remote host closed the connection) 06.35.12 Quit SuperBrainAK (Quit: pbly going to sleep /_\) 06.50.25 # <[Saint]> "I am curious about , but the extent of my curiosity is limited to a ~5 minute window" 06.50.28 # <[Saint]> >_> 06.54.36 # <[Saint]> A while ago, I added support for ROYGBIV color scheme in lamp.rock, but it got shot down...does anyone think it is worth me trying again? 06.55.17 # why was it shot down? 06.55.22 # <[Saint]> I don't think it was the implementation that was disliked, I didn't reinvent the wheel...I think it was just that no one saw the reason to have these colors, but, I don't see a reason not to. 06.56.04 # <[Saint]> part of my patch was committed, I also assed support for dimming the backlight. 06.56.12 # <[Saint]> whoops. *added. 06.59.50 Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 07.03.46 # Actually more colors for lamp.rock seems only logical, but what about stepping slowly through all colors by pressing a button. 07.03.56 # And what about brightness? 07.04.21 # <[Saint]> brightness is already available for scrollwheel targets, not sure if I added it for anything else. 07.04.37 # <[Saint]> I don't _think_ so...maybe I did. 07.04.45 # <[Saint]> It was ~2 years ago or so. 07.05.43 # <[Saint]> << >> changes the color, and scrolling forwards and backwards changes the brightness. 07.06.01 # Ah now wonder I can't find the brightness button on my fuze+ could map it to volume keys I guess 07.06.02 # <[Saint]> until I added that, it was locked at full brightness. 07.07.40 # No I found it it's up down but the steps are so small you can't tell until the fourth or fifth time it's pressed 07.07.48 # * [Saint] is doing a rough White/Red/Orange/Yellow/Green/Blue/Indigo/Violet/Black patch for it now. 07.08.04 Join TheSphinX^ [0] (~briehl@p5B321CF1.dip.t-dialin.net) 07.08.21 # <[Saint]> Ohhhhh...I see, it probably behaves poorly on button-based targets that rely on button_repeat 07.08.29 # add a colour wheel! 07.08.34 Quit shamus (Ping timeout: 256 seconds) 07.08.48 # <[Saint]> nuts to that ;) 07.09.03 # All the colors! 07.09.35 # <[Saint]> WROYGBIVB is enough for anyone! 07.09.42 Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 07.09.44 # <[Saint]> Hell..I can't even tell several of them apart! :P 07.10.20 # <[Saint]> Internet color codes 07.10.32 # <[Saint]> whoops, irc != google 07.10.38 Join mortalis [0] (~mortalis@195.34.194.126.kalibroao.ru) 07.10.57 Quit TheSphinX_ (Ping timeout: 245 seconds) 07.15.02 # I added colours to my build too, I can definitely see that plus brightness being generally useful. 07.15.33 # <[Saint]> brightness should be there already... 07.15.58 # <[Saint]> I don't distinctly recall adding it for non-scrollwheel targets, but, I doubt it would've been committed if I didn't. 07.15.58 # up and down DmL but you have to press them a few times 07.16.12 # a custom color from the menu (ala the font color-chooser) would be cool, too 07.16.22 # <[Saint]> baby steps ;) 07.16.35 # <[Saint]> I'll see if I can get some basic colors in first. 07.16.44 # <[Saint]> (other than boring old red) 07.17.20 # oh that's cool, i didn't know there was brightness 07.18.21 # <[Saint]> :) 07.18.39 # <[Saint]> There wasn't exactly a huge fuss about it when it was committed. 07.19.14 # <[Saint]> How responsive the brightness does/doesn't feel for non-scrollwheel targets is probably quite target dependant too. 07.19.19 # i use the lamp all the time 07.19.31 # <[Saint]> Some targets have a lot less/more steps in their brightness scale than others do. 07.19.44 # that's prolly what's going on with the fuze+ 07.19.56 # <[Saint]> from 16~32, iirc. 07.20.01 # it enumerates like 80 steps but there's really only 20 or something 07.20.11 # <[Saint]> Ahhhhh, whoah. 07.20.19 # <[Saint]> the Fuze+ has *that* many? Wow. 07.20.40 # yeah, in "brightness" menu setting, it goes from 0 -80 07.20.57 # (o is worse than useless since fuze+ screen is not reflective) 07.21.05 Join TheSphinX_ [0] (~briehl@p5B321B9F.dip.t-dialin.net) 07.21.39 # Yeah, a quick, very unscientific count puts me around 25 increments. 07.22.03 # So in the lamp app I have to push the button 3 or 4 times before I notice any change 07.23.47 Quit TheSphinX^ (Ping timeout: 248 seconds) 07.25.02 # * [Saint] will test and push this patch after he finishes his dinner 07.25.20 # hehe 07.25.20 # DmL, has your fuze+'s 3x3 pad ever stop working making you have to power cycle to get it back again? Mine does, I'm just wondering 07.25.32 # yeah, occasionally 07.25.46 # they mention that on the wiki 07.26.11 # that's the other thing I want to do 07.26.20 # Gotcha, I should go reread that page 07.26.43 # does rockbox support arbitrary numbers of butons? 07.27.16 # cause I want to make the 3x3 touchpad more like 9x9 07.28.59 # do the sections have to be rectangles or can they be polygons? 07.32.47 # DmL: what do you actually want to do? 07.33.19 # On the fuze+ the touchpad is setup as a simple 3x3 grid 07.33.26 # 3x3 is plenty for fake buttons, you could use the pixel coords to do smarter button handling though 07.33.53 # which maps to Back, Up, Play, Left, Select, Right, BottomLeft, Down, Bottomight 07.34.23 # but I would like the action buttons to be smaller 07.34.35 # and the direction buttons to fan out getting larger away from the middle 07.34.56 # and to maybe have a zone on the edges where both are triggered 07.35.23 # I don't mind looking into it myself, I was just wondering if the button shapes could be easily arbitrary, or if they had to be rectabgles 07.35.58 # or I could simulate it by having multiple zones trigger a single button 07.36.13 Join melmothX [0] (~melmoth@unaffiliated/melmothx) 07.36.24 # currently only rectangles are supported (and only 3x3 in the touchpad->button code)... skins can use coords to have as many button areas as they want 07.36.35 # but i dont know if that mode is suppoerted on the fuze yet or not 07.36.56 # but the skin buttons wouldn't be visible to plugins 07.37.02 # correct 07.37.17 # where is the touchpad button code located? 07.37.42 # not sure :) 07.37.48 # heh 07.37.56 # i wish there was an API : D 07.38.59 Join DmL_ [0] (~acdc5b42@www.haxx.se) 07.39.57 # add one :) 07.40.03 # this would be easier if I had a stable dev environment 07.40.22 # then you just need to add keymaps for your new psudobuttons 07.40.30 # hehe, add an API to the iki? sounds like a nice long term project for somebody like me who is only marginally code-worthy 07.40.57 # but yeah, that's what I was thinking, find where the buttons are enumerated, add a couple 07.41.17 # can different button areas trigger the same button press? 07.41.29 # alternately can a button area trigger two different buttons? 07.42.27 # yes, no 07.42.57 Quit DmL (Quit: CGI:IRC (Ping timeout)) 07.43.48 # I have a hard enough times with my big-ol-fat fingers as it is. (grep)ing through the rockbox/firmware directory should help you find what you need DmL 07.45.30 # well, I'm thinking specifically for the game plugins 07.45.38 Quit Rower (Quit: Hmmm...) 07.45.38 # it would be nice to be able to travel diagonals 07.46.39 # so I could define an "FUZEPLUS_UPLEFT" 07.46.56 # and then in rockboy, infones, doom, etc trigger their pad buttons appropriately. 07.47.19 # i guess it wouldn't need to trigger two in rockbox itself, rather just have a unique button there 07.48.03 # Oh man the button mapping ifdef s in the plugins are nasty, they need tamed badly before we add even more 07.48.19 # I guess I'll go do that huh? 07.48.48 # heheh 07.49.00 # well, this is mostly for my own good 07.49.09 # i use my fuze+ like most folks use their phones I guess 07.49.29 # i never go anywhere without it, and use it as my pimary gaming, ebook, and music platform 07.49.49 # i'm not a good enough coder to contribute yet, but if I get any of this working really satisfactorily, I would consider commiting 07.49.59 # action games still suck in rockboy unless you map A and B to the volume keys, cause you can't press two buttons on the touch pad at once 07.50.06 # for instance I would make it a menu option to add the buttons or not, I think 07.50.26 # yes, that's how I play them, and it works very well for me, VOL buttons as A and B 07.50.47 # and now that paumary got the cpu scaling i, rockboy and infones run at full speed 07.51.46 Nick DmL_ is now known as DmL (~acdc5b42@www.haxx.se) 07.52.30 # Has infones been pushed to master? 07.52.40 # no, I got it compiling myself 07.53.05 # and it runs really well, plays alot of games 07.53.30 # i could probably double the compatibility if I could figure out how to flip the masking bits 07.53.49 # it seems masking is working in games like Metroid, but it's exactly backwards 07.53.55 # Where is the patch? 07.54.08 # the infones patch that I used? 07.54.26 # yes or similar 07.56.33 # heh, I can't find it now, gimme a sec 07.57.09 # take your time, was it in flyspray?, I'll go check. 07.58.25 *** Saving seen data "./dancer.seen" 07.58.54 # ok, starting here 07.58.55 # http://www.rockbox.org/tracker/task/2911 07.59.24 # the very last patch: http://www.rockbox.org/tracker/task/2911?getfile=20189 07.59.26 # <[Saint]> If you've worked on it yourself, shouldn't you rather push a patch from your local tree? 07.59.41 # <[Saint]> 'git diff origin/master master" or so. 08.00.07 # well, I would except a) I dunno how to do that and b) it's on a linux partition on my laptop, which is currently misbehaving 08.00.24 # it's the simplest thing in the world to get it working hto 08.00.38 Join TheSphinX^ [0] (~briehl@p579CC535.dip.t-dialin.net) 08.00.58 # besides adding a button mapping for the fuzeplus, all I had to do was fix a couple of calls to (if I recall right) play_pcm_data 08.01.15 # <[Saint]> If you're not setup to use gerrit, then just "git diff > diff_name.diff", if you are setup to use gerrit, then "git diff origin/master master > diff_name.diff" 08.01.39 # ah, that's what I was trying to figure out earlier 08.01.51 # is there an easy way to seperate stuff out? when I do a local commit, i just did -a 08.01.57 # so I have a ton of unrelated stuff in there too 08.02.16 # <[Saint]> not non-trivially, no. 08.02.18 # i supose if what I'm doing is actually useful, then I could get setup with gerrit 08.02.19 # commit early and commit often 08.02.24 # * [Saint] nods 08.02.26 # yeah, I don't mind redoing the work 08.02.28 # <[Saint]> and use branches. 08.02.36 # <[Saint]> branches are your friend. 08.02.54 # <[Saint]> (for seperating different patch sets) 08.02.58 # so I branch for my work with infones, branch for rockboy, branch for my button code? 08.03.07 # * [Saint] nods 08.03.23 # or so, branch for getting infones working with head, branch for adding the screen rotation code? 08.03.40 # cause i do have screen rotatoin also 90% working 08.03.47 Quit TheSphinX_ (Ping timeout: 264 seconds) 08.03.53 # <[Saint]> http://www.rockbox.org/wiki/UsingGit is a great start to figure out the workflow. 08.04.13 # <[Saint]> http://www.rockbox.org/wiki/UsingGit#How_do_branches_work_63 08.05.27 # k, i'll look into that 08.05.34 # while I have you helpful folks here, wo 08.05.57 # would it be better, since I want to do like 8 variations on solitaire, to add them to the current plugin, or make them all their own plugins? 08.06.23 # (have like a emnu item to select which variation you want to play) 08.07.21 # <[Saint]> It would be betetr to have them all as one plugin, IMO, with a selection menu at run-time. 08.07.34 # yeah, that's what I was thinking 08.07.52 # right now there are patches for freecell and spider, which I also have working, and they re-use like 80% of their code 08.08.12 # not to mention they're all referencing the same card fx anyway 08.10.40 # is it worthwhile to ask some questions about how rockbox organizes the framebuffer? 08.11.28 # i notice it's a linear array of type y * width + x, i was wondering though, where (0,0) would be located. I assume upper-left of the screen? 08.12.34 # * [Saint] nods 08.12.42 # <[Saint]> 0.0 is always top/left 08.13.01 # awesome 08.13.25 # i assume it will just fail if you try to write outside the bounds 08.14.46 # <[Saint]> iiuc, yes. but I _think_ negative values are accepted. 08.15.00 # <[Saint]> (useful for alignment) 08.15.06 # I wonder if that's why I see some overflow on certain plugins 08.15.12 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 08.15.13 Quit joshin (Ping timeout: 252 seconds) 08.15.42 # btw, thanks [Saint] for the work you do, I see your name on the forums alot. I've been pretty excited to get started mucking about with the source, love the software, and friendly names like yours are a big reason I haven't been able to get rb outta my head the last couple months 08.16.34 # <[Saint]> My nick is actually supposed to be ironic, heh, I am *far* from a saint ;) 08.16.40 # <[Saint]> But, I'm glad I can help. 08.16.44 # heh, that's cool 08.17.23 # i know alot of projects that say "do it yourself" and ya'll say it too, but you make it actually possible 08.17.37 # it's all very accessible 08.18.15 # <[Saint]> I know what you mean there, actually. Some "open" projects, while open source, have very hostile communities. 08.18.28 # <[Saint]> One of the things I enjoy about this project is the community. 08.19.04 # i was sorta hesitant to actually get involved, since I'm not actually a coder, but it looks like I might actually be able to contribute 08.19.57 # especially I've got some confidence now since I was able to get linux and the repositary up and running, get a few patches compiling, add a few features I've wanted 08.20.01 # <[Saint]> I very much dislike the "Hey guys, can I get some help? How do I do ?"; "Hahahaha, f*ck off, n00b" type "developers" and members. 08.20.11 # <[Saint]> I have always found Rockbox to be very welcoming. 08.20.25 # yup, and the dev guides are amazingly complete 08.21.21 # no i just need to learn the code and write the API guide for you guys :P 08.21.56 Quit zamboni () 08.22.27 # <[Saint]> Yes. Someone with absolutely zero experience should be perfectly capable of setting up an environment, and patching and compiling their own build in an hour or less. The docs are evry straightforward. 08.22.44 # <[Saint]> *very 08.23.05 # they even taught me about linux in the process 08.28.07 # foolsh, where you able to compile it? 08.29.17 # still setting up git branches and registering in gerrit and all that about to patch it in 08.30.35 # the only real gotcha is the play_pcm_data func 08.30.56 # it's called twice, you just have to add one argument to the call 08.31.18 # mint is almost installed on my vm 08.31.29 # i'll try and make a patch real quick when it finishes 08.31.55 Part stryaponoff ("I need to go. Have a nice day!") 08.33.27 # cool, Hunk #1 succeeded at 1 with fuzz 2 08.34.09 # yup 08.34.24 # that's the CATEGORIES file or something 08.38.04 Join joshin [0] (~josh@ip68-0-152-212.tc.ph.cox.net) 08.38.05 Quit joshin (Changing host) 08.38.05 Join joshin [0] (~josh@unaffiliated/joshin) 08.49.08 # make finished without error now to just go back and make it work with the fuze+, thank DmL 08.53.18 # yar man 08.58.15 Nick TheJacquerie is now known as radio23 (radio23@newelite.bshellz.net) 09.00.55 # * [Saint] added g390 09.01.15 # * [Saint] prods fs-bluebot 09.01.22 # <[Saint]> ...bah! 09.01.37 # <[Saint]> http://gerrit.rockbox.org/r/#/c/390/ - Change I0b2f6376: Additional colors for lamp.rock 09.02.02 # <[Saint]> go nuts fellas 09.02.45 # <[Saint]> bluebrother: is fs-bluebot feeling a bit ill lately? Or did I botch the syntax? 09.03.00 # <[Saint]> test g#390 09.03.02 # Gerrit review #390 at http://gerrit.rockbox.org/r/390 : Additional colors for lamp.rock by Hayden Pearce (changes/90/390/1) 09.03.08 # <[Saint]> Ahhhh, I did. 09.03.27 # <[Saint]> I could'ver sworn the # wasn't necessary 09.03.41 # <[Saint]> *could've 09.06.37 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 09.07.23 Join petur [0] (~petur@rockbox/developer/petur) 09.10.27 # ./woohoo 09.10.39 # connected to gerrit 09.11.25 # <[Saint]> If you feel like testing/reviewing the above linked patch, I wouldn't beat you off with a stick 09.12.02 # <[Saint]> *very* trivial patch...very trivial. 09.12.27 # I dunno if I'm a good one to review, but I will definitely test it as soon my git is cloned and I have re-re-re-re-compiled the arm gcc libs etc 09.13.04 # <[Saint]> If you have already compiled the toolchains, there should be no need to do so again. 09.13.17 # <[Saint]> they exist outside of the repo 09.13.19 # unless I'm working on a fresh install on a different machine : ) 09.13.26 # <[Saint]> Aha, yes. :) 09.13.38 # <[Saint]> You can just copy them over, too. 09.13.53 # <[Saint]> unless you're going from 32->64bit 09.13.54 # the other install isn't exactly... reachable at the moment 09.14.00 # <[Saint]> Ah. 09.14.05 # actually, yes, I'm going that too 09.14.13 # <[Saint]> Aha, right. 09.14.30 # <[Saint]> (word of advice, skip the YP-RO toolchain ;)) 09.14.31 # didn't even think about that 09.14.50 # are the compilers needed for the sims? 09.15.06 # <[Saint]> No, just sdl-stuffs 09.15.27 # k, then i'll just do the ARM i think, whichever one it is for the fuze+ 09.16.44 # <[Saint]> re: YP-R0 toolchain: it is a nightmarish mix of unlisted dependencies, and each time it fails, there's no way to just start over without trashing what was already sucessfully compiled. 09.16.56 # <[Saint]> I never managed to get it to compile on Ubuntu 64bit 09.17.20 # <[Saint]> I did on Ubuntu 32bit, but only after figuring out ~15 or so undocumented dependencies 09.18.10 # <[Saint]> unless you're planning on adding this machine to the build farm, I would skip toolchains for any target(s) you're not planning on compiling for in the near future. 09.20.40 # that was sorta my thinking, too 09.20.47 # what's the build farm? 09.22.06 # <[Saint]> Its our distributed build client. That's how we get all the builds done so quickly after each commit 09.22.12 # aha 09.23.06 # <[Saint]> A reasonably large group of powerful to not-so-powerful machines get distributed a build each, and get fed more tasks if they complete the job they get issued before the current round finishes. 09.23.18 # <[Saint]> rinse, repeat, until the current round is finished. 09.23.39 # <[Saint]> That's how we pump out ~30something+ builds in ~2 minutes :) 09.23.50 # <[Saint]> http://www.rockbox.org/wiki/BuildClient 09.25.15 # clever 09.25.21 # <[Saint]> clients eventually get issued a score, based on how well they handle the tasks they are issued, and then the more capable machines get issued more work. 09.25.36 # <[Saint]> And yes, it is. It is very awesome. 09.25.59 # <[Saint]> I marvelled at the idea when I first discovered it. 09.26.07 Quit Raptors (Ping timeout: 244 seconds) 09.26.30 Join Zagor [0] (~bjst@sestofw01.enea.se) 09.26.30 Quit Zagor (Changing host) 09.26.30 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 09.26.37 # <[Saint]> The real beauty of it is that build clients can come and go as they please, and the only result is that the build round will take slightly longer. 09.27.02 # I'll definitely have to sign up when I have my 16 core computer setup 09.27.06 # <[Saint]> It is very rare that the only clients left connected atren't capable of compiling for each target, but it has happened before. 09.27.57 # <[Saint]> and then, it all ends up here: http://build.rockbox.org/dev.cgi 09.28.27 # <[Saint]> this is a table of the last N rounds completed, with deltas for binary size increase, etc. 09.28.39 # ah, so THAT's what that page is 09.28.45 # * [Saint] nods 09.29.33 # just one more evidence of this project's extreme yooser-friendliness 09.30.00 Join Wardo [0] (~Mirandaha@176-120-190-109.dsl.ovh.fr) 09.30.03 # <[Saint]> heh :) 09.31.55 # alright, building arm 09.31.55 # the next step is to make it browser based and faster than ever :) 09.32.24 Join kevku [0] (~kevku@2a01:d0:ffff:34a::8:3) 09.32.40 # so once I get all this working 09.32.46 # i want to make a branch 09.32.54 # then patch your your lamp patch into it 09.33.30 Join Raptors [0] (~whoneedsa@216-58-33-203.cpe.distributel.net) 09.33.32 # then do I do another branch with all the patches applied, or do I somehow compile more than one branch into a single set of binaries? 09.34.17 # <[Saint]> you would need to do another branch with all applied if you wanted to do that. 09.34.48 # <[Saint]> afaik there's no way to merge all the current branches in that fashion. 09.34.49 # so if I find your patch useful 09.34.56 # <[Saint]> but I'm hardly a git-poweruser. 09.35.03 # i apply it and say, my newly minted infones patch 09.35.13 # to a new branch call ALLCHANGES or something? 09.35.57 # <[Saint]> If you applied it, and didn;t find it useful, you can always revert the patch...if you just wanted to keep everything in the same branch. 09.36.22 # i'm just trying to wrap my HEAD (waa waa waa) around this 09.36.23 # <[Saint]> applying a patch that has already been applied is automatically detected and assumes you want to undo the patch. 09.36.30 # cause last time I applied like 10 patches 09.36.44 # and that wouldn't be useful from a contributing standpoint 09.36.56 # and didn't track the changes at all 09.38.00 Quit Raptors (Ping timeout: 244 seconds) 09.38.20 # <[Saint]> if you apply a patch that has already been applied to the current tree, patch will prompt you about this, and ask if you want to assume the "-R" (reverse) flag. Alternatively, you just add the -R flag to the patch command. 09.38.25 Join Raptors [0] (~whoneedsa@216-58-33-203.cpe.distributel.net) 09.38.37 # so if I apply it to the wrong branch, that's pretty easy to undo 09.38.41 # <[Saint]> so: "patch -p0 -R < name_of_patch.diff" 09.38.49 # it seems like last time I applied something from gerrit, it made a new branch anyway 09.38.58 # <[Saint]> errr, -p1 for a git patch 09.39.39 # so the < is like an input symbol or something 09.40.47 # cause I think i remember getting that backwards once, and it wiped the contents of the .patch 09.40.54 # <[Saint]> yes. "patch < patch.diff" installs a patch with that name, "patch > patch.diff" will create a patch with that name from the currently tracked changes on the branch 09.41.48 # <[Saint]> and, re: gerrit...you probably hit "cherry-pick" instead of "patch" or so. 09.41.57 # <[Saint]> which, iiuc, will create a new branch. 09.42.05 # which seems like a good thing to do 09.42.28 # is there a way to just make a .patch from gerrit? 09.43.30 # <[Saint]> Yes, there are four buttons above the list of files for the current patch set: checkout; pull; cherry-pick; patch 09.43.32 Join LinusN [0] (~linus@giant.haxx.se) 09.44.04 # <[Saint]> each of them will print a command to enter to do the desired action. 09.44.56 # I make a new branch then use git pull 09.45.22 # <[Saint]> cherry-pick creates the branch automagically, iiuc. 09.45.42 # don't forget to checkout your new branch if you do it that way 09.45.45 Quit Raptors (Ping timeout: 244 seconds) 09.45.47 # ah! 09.46.32 # <[Saint]> gitref.org is a great resource 09.46.40 Join Raptors [0] (~whoneedsa@216-58-33-203.cpe.distributel.net) 09.46.52 # <[Saint]> It got me through a lot of the basics of git that aren;t immediately obvious or basic. :) 09.48.02 # the closest I've been to any of this stuff before is using tortoiseSVN in windows : ) 09.48.12 # not that i don't like the command line 09.48.55 # * foolsh knows they will have to pry his command line from his cold dead fingers 09.49.44 # kids today with their IDEs and stuff 09.49.49 # <[Saint]> there are a LOT of GUI frontends for git these days. 09.50.00 # <[Saint]> Many suck, badly, some are quite awesome. 09.50.12 # it never even ocurred to me to look for one 09.50.18 # <[Saint]> git-gui is pretty good. 09.50.34 # would that help me in setting up my branches? 09.50.51 # the only one i'm really worried about is the initial infones patch adds like 20 files 09.51.03 # <[Saint]> Yes and no. I find doing it manually helps one to understand the workflow a lot better. 09.51.17 # <[Saint]> Rather than an application possibly taking steps for you behind the scenes. 09.51.20 # but surely i don't need to add each file one at a time? 09.51.28 # <[Saint]> No. 09.51.47 # <[Saint]> "git add ." 09.52.08 # <[Saint]> that'll add anything that isn;t currently tracked. 09.52.25 # but i need a branch arg for that too, yeah? 09.52.43 # <[Saint]> I'm not sure what you're getting at. 09.53.01 # so i've got my clean rockbox 09.53.06 # The flow goes like this ( git branch infones | git checkout infones | patch -p0 < ../infones.patch | git add ./apps/plugins/infones/* | git commit " 09.53.07 # <[Saint]> you would do that from within the branch. 09.53.10 # git branch lamp 09.53.18 # patch > etc 09.53.26 # git branch infones_base 09.53.34 # right ok 09.53.47 # darnit 09.53.54 # gotta get that > right 09.54.02 # alright, this is awesome, guys 09.55.20 # * [Saint] highly recommends reading from http://gitref.org/ 09.55.49 # <[Saint]> it is geared towards new users, so it is worded in a way that most people should be able to understand, and isn;t too overwhelming. 09.56.39 # <[Saint]> there are links on the left side of the gitref main page that you can use to easily look up information on specific tasks. 09.56.55 # <[Saint]> ie. branching, checkout, commit, etc. 09.57.00 # [Saint], black? really? can't wait to see this. Come on computer compile faster! 09.57.30 # black, eh 09.57.33 # <[Saint]> foolsh: it's actually not as non-useful as one might think. :) 09.57.40 # yeah, I'm on pay 6 of that website now, I think 09.57.43 # page* 09.57.56 # <[Saint]> I use it when I only need enough light to just see what I'm doing and don;t want to blind myself. 09.58.15 # * [Saint] stabs his ; key in the face 09.58.20 # * foolsh nods 09.58.23 # <[Saint]> be ', dammit! 09.58.29 *** Saving seen data "./dancer.seen" 09.59.12 # <[Saint]> It wouldn;t surprise me if I'm asked to remove black from that task, but, we'll see. 09.59.46 # I want to remove 0 as a selectable option for brightness 09.59.52 # that's gotten me into trouble a couple times 10.00.43 # <[Saint]> Ah, yeah, screens that aren't visible with the backlight off... 10.00.50 # <[Saint]> I can see that being interesting. 10.01.55 # guh, its 4AM here and I have a 9:15 conference call guh 10.02.16 # <[Saint]> Whoop. Bedtime. :) 10.02.25 # <[Saint]> *whoops 10.02.27 # one would think so 10.03.13 # [Saint], I like the colors patch, useful if you're viewing samples at different wave lenghts of light. I tried it out on the pattern of my blanket. Very cool 10.05.53 Join jhMikeS [0] (~jethead71@50.4.240.19) 10.05.53 Quit jhMikeS (Changing host) 10.05.53 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 10.12.20 Join redhot [0] (~kvirc@195.238.92.36) 10.12.26 # Howdy people! 10.14.19 Quit foolsh (Read error: Connection reset by peer) 10.14.49 # [Saint]: with the latest build the new 10-band EQ is enabled on all targets or only on most powerful ones? 10.15.10 # <[Saint]> All that use the EQ 10.15.27 # <[Saint]> so...iirc, everything except the Archos' 10.15.48 # ok, thank you 10.16.17 # <[Saint]> The CPU usage increase is quite trivial. 10.16.35 # <[Saint]> +~5MHz for realtime 10.16.44 # i like the sound of that 10.17.03 # * [Saint] is popular today :) 10.17.35 # * DmL is full of puns. 10.17.49 Join foolsh [0] (~foolsh@nc-76-0-169-20.dhcp.embarqhsd.net) 10.17.55 # <[Saint]> Well, it /just/ got committed...so it is available in the source as of now, or via the development snapshot builds. 10.18.20 # buts its merged? 10.18.22 # <[Saint]> Oh, derp...hahaha, yes, nice one :) 10.18.30 # <[Saint]> I didn't parse that as a pun initially. 10.19.37 Quit TheSphinX^ (Read error: Operation timed out) 10.25.59 Join TheSphinX^ [0] (~briehl@p5B3235AA.dip.t-dialin.net) 10.44.22 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.47.37 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 10.48.39 # DmL: foolsh: what is the problem with lcd and rotation ? 10.51.23 # in rockboy, when you choose from the menu options "rotate left" and "scaled" they set properly, return to gameplay and try to re-enter the menu and you will get a data-abort on all classic games and most color games 10.51.51 # it does not do that for any other combination of menu items 10.52.25 # it's been confirmed on 3 different fuze+ (4gb and 8gb) 10.53.31 # i tried to reproduce it in the sim, but i don't think I knew the specific menu option to trigger it when I tried it 10.53.49 # I tried the sim and every combination works fine 10.54.13 # i tried it in a dev build, and it data aborted without loading a game 10.55.19 # i tried a version of the menu code that just exited the plugin on pressing the menu button, and it data aborted after showing the "closing rockboy" splash 10.55.54 # (thanks for all your hard work by the way) 10.55.57 # * DmL bows. 10.57.42 # arthus1 10.57.44 # whoops 10.58.51 Nick radio23 is now known as TheJacquerie (radio23@newelite.bshellz.net) 11.00.23 Join bebna [0] (~a.fasold@94.101.33.114) 11.01.32 # DmL: did you get meaningful backtrace on abort? 11.02.45 # in other words, did it tell me adress and such? yes 11.02.58 # i can give you the whole error 11.03.04 # I don't have a MAP handy at the moment 11.04.05 # without .map its meaningless 11.04.23 # foolsh probably has one 11.04.37 # Well, an elf file is just as good :) 11.04.41 # i can make one as soon as the cross-compiler finishes 11.04.44 # it will be plugin .map most probably 11.04.51 # gevaerts: right, even better 11.04.59 # hmm 11.05.14 # <[Saint]> you need the .map file for the exact revision of the same target build 11.05.46 # well, foolsh could give you the address and the map 11.06.01 # * [Saint] wonders why it isn't included in the dev snapshots 11.06.06 # i can post tomorrow once my compilter is working again 11.06.12 # <[Saint]> it is shipped with releases, no? 11.06.23 # <[Saint]> re: map file(s) 11.06.30 # i don't see it in the zip 11.07.32 # <[Saint]> Hum, I'm not sure if it is packed with the binary, or available as an alternative download. 11.08.09 # or should I do a debug build? 11.08.25 # <[Saint]> I guess shipping them is useless, ...not sure what I was thinking there. But it would be nice if the last N builds had their map files archived. 11.08.46 # <[Saint]> foolsh: not unless you want to connect to gdb 11.09.09 # woot, compiler finished! 11.09.45 # <[Saint]> Damn, that took ages. What system is this? 11.10.19 # 32bit linux running in a virtual machine on 64bit windows 7 dual core 2.7ghz without virtualization 11.10.52 # doesn't seem like it'll be very useful, does it? 11.10.55 # hmm 11.10.56 # <[Saint]> (to spped compilation, if you haven't already done so, enable ccache {sudo apt-get install ccache}) 11.11.13 # <[Saint]> compilation will be a lot faster than that, one hopes :) 11.11.49 # <[Saint]> The initial compile is the longest, subsequent builds are significantly shorter. Especially with ccache 11.12.15 # i may have to bite the bullet and risk the other machine real quic 11.12.41 # <[Saint]> what for? 11.13.05 # rockbox compilation is a few minutes even on ancient hardware 11.13.27 # generating dependencie is taking like 5 minutes 11.13.39 # <[Saint]> damn. 11.13.42 # thats io intensive so vm hits you 11.13.55 # on the other machine the entire compile takes like 45 seconds 11.14.07 # but it starts to overheat after 20 minutes or so 11.14.50 # so i think i can build it once, but i can't actually do any dev on it 11.15.04 # hmm, this one is doing okay, now 11.16.05 # hmm, for 3 subsequent build rounds magic errors disappeared 11.16.58 # * foolsh updated FS#12815 with backtrace from data abort 11.16.59 # http://www.rockbox.org/tracker/task/12815 Fuze+ Rockboy data aborts on menu key press, when the srceen is rotated left and image is stretched (bugs, unconfirmed) 11.18.33 # this backtrace doesn't give much insight 11.19.30 Join DmL_ [0] (~acdc5b42@www.haxx.se) 11.19.45 Quit einhirn (Ping timeout: 256 seconds) 11.21.17 # should I put the elf/map anywhere in particular? 11.22.41 # You need matching backtrace and .elf/.map (elf is better) to even try to understand the failure 11.23.00 # so you're not wanting me to upload them soewhere 11.23.07 # I'll try to reproduce on my fuze+ 11.23.18 # i have the elf/map and I can give the address as well now 11.23.58 # DmL: upload .elf somewhere and pastebin abort screen 11.24.09 # hmm 11.24.16 # pamaury: whats mapped at 0x49? iram? 11.24.36 # yeah 11.25.07 # so If I understand abort correctly thats kinda strange 11.25.26 # data abort in memcopy ? 11.25.38 # ah wait it is unaligned access most probably 11.26.01 # would fit: it's in assembly so backtracer probably fails and the error is unaligned access 11.26.56 # i don't have an easy way to upload a screen cap but i can type the text of the error out 11.27.07 # DmL: thats what I mean 11.27.56 # just type it in pastebin.com or whatever to not pollute channel 11.28.03 # ah, ok 11.30.26 # http://pastebin.com/Ty75MjsX 11.30.44 # is that correct? 11.31.52 # yeah 11.32.19 Join ender` [0] (~ender@foo.eternallybored.org) 11.33.21 # if I read correctly that's in lcd_mono_bitmap_part 11.34.38 # on a color game it is exactly the same except the address line reads address: 0x00010037 11.35.11 # pamaury: if I read correctly its in add_to_list_l() 11.36.04 # hmm 11.36.12 # i've yet another address now, weird 11.36.22 # DmL_: impossible, there is no code at this address, isn't it 0x1037 ? 11.36.22 # wodz: can't find any function with that name, did you use the elf ? I had a look at the .map by hand 11.36.24 # 0x0000e6eb 11.36.36 # pamaury: yes 11.37.07 # there is no code between 0x8000 and 0x6000000, those addresses don't make sense 11.37.25 # pamaury, on the color game it has repeated at 0x00010037 11.38.06 # hum, I really need to check on mine 11.38.25 # pamaury: wodz: did you already think of ways to detect 'heap' corruption? (unintentionally overwriting running code) 11.38.44 # we have a stack corruption check on context switch already afaiu 11.39.11 # use virtual memory ? but that can only trap writes to code, not to the stack 11.39.18 # funman: we have but it is not the most reliable thing 11.39.30 # the address seems to move based on which game crashes it 11.39.49 # this pretty much looks like stack corruption 11.40.17 # or else there are 3 or 4 addresses it might come up with 11.40.18 # we could put the stack far away from everything, using virtual memory 11.40.25 # pamaury: i agree proper use of mmu (and making code ro) would be helpful 11.40.50 # I already use the mmu on the imx233 for caching, however I use section of 1MB only 11.40.52 # i just got 0x0000e6eb again on SQRXZ 11.41.51 # funman: you tried something with ro protection on amsv2, am I right? 11.42.03 # DmL_: ok thanks, it looks stack a stack corruption, the address is probably meaningless then :( 11.42.44 # aaand that machine died 11.43.05 # so it looks like stack corruption even though it shows up in only 3 or 4 places repeatedly? 11.43.20 # * [Saint] notes that kugel apparently broke android in the build system 11.43.35 # <[Saint]> "2013-01-29 23:42:32 Error: You specified arch android15 but the output of 'android list target' did not include 'API level: 15'." 11.43.57 # <[Saint]> (not a bug on my side, API15 was depricated) 11.44.17 # alright guys, I gotta get some shut-eye, hope I was able to help a little 11.45.57 # I could try to build a prototype mmu protection: map iram with very small pages, make code ro, map dram with larger pages, make code ro and put stacks in a special section far away from the code in virtual memory (and perhaps in physical memory if possible also) 11.46.17 Quit DmL_ (Quit: CGI:IRC (Ping timeout)) 11.46.25 # wodz: yes but i think i stopped in the middle of it 11.46.52 # pamaury: would be nice 11.47.52 # I think initial idea was to interleave small ro and rw sections so out of bounds write would trigger abort easily 11.48.46 # that would be a huge waste of virtual memory, you would need a second level table for the entire code no ? And how can you interleave them ? 11.50.30 Quit DmL (Quit: CGI:IRC (EOF)) 11.50.31 # manual copy? 11.50.51 # we could do this in a debug mode 11.50.52 # <[Saint]> Oh, derp...all I needed to do was change "android15" to "android16". 11.51.01 # wasting tons of memory is ok if it helps finding bugs 11.52.15 # that would already require a much more clever loader, we would need list of all the ro sections 11.52.53 # <[Saint]> Hum...how do I submit a patch for www.git? 11.54.00 # * [Saint] spots gevaertscommitting there and active here, and pounces 11.54.09 # <[Saint]> *gevaerts committing 11.55.42 # anyway g#239 11.55.43 # Gerrit review #239 at http://gerrit.rockbox.org/r/239 : WIP: read-only memory on sansa AMS using MMU by Rafaël Carré (changes/39/239/2) 11.56.24 # [Saint]: same as everywhere else 11.58.06 Join DmL_ [0] (~acdc5b42@www.haxx.se) 11.58.33 *** Saving seen data "./dancer.seen" 11.58.35 # <[Saint]> gah... 11.58.55 # * [Saint] can't really be buggered checking out www for a one char patch 12.15.29 Quit [Saint] (Remote host closed the connection) 12.17.29 # wodz: thanks, i didn't remember where it was ^_^ 12.17.48 Join [Saint] [0] (~saint@rockbox/user/saint) 12.21.00 Join lorenzo92 [0] (~chatzilla@host100-109-dynamic.249-95-r.retail.telecomitalia.it) 12.21.35 # Guys, to upload data to http://www.rockbox.org/wiki/SansaRuntime shout I know the exact SVN number 12.21.46 # I have used RockBox 3.12 Release 12.22.06 # I want to start looking at WM1808, if I see any similute we can hopefully integrate it cleanly into rockbox reusing WMxxxx code 12.22.12 # It shoould be mentioned "RockBox 3.12 Release" or I should put there exact SVN number? 12.24.25 # lorenzo92: which WM code? There are quite a few WMxxxx drivers in our codebase. 12.24.38 # lorenzo92: for some WMs we don't have DS also 12.24.40 # redhot: yeah please put the exact version 12.24.47 # wodz: yes, I see, I need to find out 12.25.02 # funman: how can I know it? 12.25.30 # Is it possible from device? 12.25.39 # system -> info possibly 12.26.03 # nope, it's just tells me 3.12 12.27.12 # put 3.12 then 12.27.24 # you can't be more exact than that ;) 12.27.40 # lorenzo92: do you have DS for this WM1808? I may have a look - I extended WM8751 driver to support WM8750 once upon a time. 12.27.43 # funman: oh, thanks a lot :)) 12.28.28 # wodz: unfortunately not, but I have a full documented driver for alsa linux (samsung OSS package), I see lots of similarites with wm8758 atm 12.30.30 Quit foolsh (Quit: Leaving) 12.31.12 # wodz: definitely, it's pretty the same ;) 12.32.09 # lorenzo92: pay attention to register map AFAIK there are subtle differences between codecs even in the same family 12.34.51 # heh WM website doesn't mention about wm1808 12.36.14 # funman: ok, thanks it has been uploaded ;) 12.36.36 # FLAC L5 running time 11:50 while MP3 320kbps 10:50 only 12.36.49 # It makes me completely move to FLAC :) 12.43.33 # lorenzo92: Some EV board docs floating around refer to: WM1808, WM8957, WM8983, WM8985, WM8986 12.49.33 # redhot: nice, but it seems to imply your battery is aging? there are reports of 16-17 hrs on the wiki no? 12.50.45 # funman: main question for me was MP3 vs FLAC. and FLAC wins. btw I have used relatively powerful headphones hence battery live is less 12.51.18 # battery is 6 month old 12.51.24 # redhot: ok, might be interessting to compare these results with codec performance 12.51.30 # i.e. MHz 12.51.35 # power hungry* 12.52.34 # the Clip's battery seems to run pretty fast 12.52.40 # I've been spoiled by the iPod Classic 12.52.42 # ]Dreamt 87 points 2 heures de ça 12.52.54 # hein? 12.52.59 Quit advcomp2019_ (Ping timeout: 276 seconds) 12.53.12 # unwanted copy/pasting sorry 12.55.02 # copper: 10-15 hrs is quite enough 12.55.15 # for most people 12.55.18 # depends for whom 12.55.38 # for most of them it is ok ;) 12.58.18 # [citation needed] 13.00.34 # "640K ought to be enough for anybody" :-D 13.10.40 Quit petur (Quit: *plop*) 13.18.48 # :D 13.31.42 Join XavierGr [0] (XavierGr@rockbox/staff/XavierGr) 13.34.11 Quit XavierGr (Disconnected by services) 13.34.12 Join XavierGr [0] (~xavier@rockbox/staff/XavierGr) 13.35.25 Quit the-kyle (Ping timeout: 255 seconds) 13.36.27 Join the-kyle [0] (~kyle@cpe-024-211-185-030.nc.res.rr.com) 13.44.26 Quit the-kyle (Ping timeout: 244 seconds) 13.44.42 Join the-kyle [0] (~kyle@cpe-024-211-185-030.nc.res.rr.com) 13.56.45 # [Saint]: What is the purpose of 'black' color in lamp plugin? That kinda contradicts the purpose, no? 13.58.31 # bye ;) 13.58.36 Part redhot ("Once you know what it is you want to be true, instinct is a very useful device for enabling you to know that it is") 13.58.37 *** Saving seen data "./dancer.seen" 14.04.04 # hum I'm having a error: 'LANG_HW_EQ_GAIN' undeclared here (not in a function) error....any hints? 14.05.21 # okay I found out why, possibly 14.11.16 # hum no I know why but I cannot understand the problem... 14.18.49 Quit mortalis (Quit: Leaving) 14.19.27 # lorenzo92: usually it's because the lang file misses your target in the list of a string 14.19.43 # ahh okay, I'll try :) 14.20.29 # ouch! I need to add my target to all the lang files? 14.20.37 # no 14.20.43 # only the english one 14.20.53 # ^^ now's better :D 14.21.14 # I don't remember how it works but I think english is enough, maybe someone can confirm 14.26.25 # pamaury: it partially worked, now having troubles in settings_list 14.26.37 # which troubles ? 14.27.30 # warning: missing initializer 14.28.45 # perhaps you need some #define hacking 14.29.01 # or you are missing a target define 14.29.17 # it's already there I guess #ifdef HAVE_WM8978 14.30.07 # it's only a warning but should probably have a look to understand it 14.30.38 # but it actually stops gcc, let me re-run it 14.30.48 # try make clean, we never know ^^ 14.30.58 # ahhh 14.31.03 # okay missing string 14.31.05 # :D 14.31.11 # the last one probably 14.34.02 # pamaury: thanks for the hint, mistery solved, later I will study a way to manage codec registers, I guess I'll do something from the linux side i.e. a module 14.34.55 # maybe it's time to have a look at the different WM drivers and refactor them ! What is the codec in the R1 ? 14.35.45 # WM1808, but it is similar (apart 1 registers that have been added to it) to the WM8978 14.35.51 # used in gigabeat-s 14.36.03 # that's why I wanted to try it out on R1 14.36.18 # strange ^^ I was under the impression that all the WM are similar anyway 14.37.24 # not really sure, since for example power register 1 is not located @0x1 for all wm's 14.38.24 # sure there are some differences, but if they are minor, we don't need 10 drivers 14.38.50 # unfortunately samsung did not export to userspace register editing for the wm1808, so I wll need to create an external module (similar to my si4709 module) 14.39.13 # pamaury: yes, you are right, but only where it's indeed similar 14.40.20 # unfortunately we don't have the datasheet for all of them, that's a problem 14.42.16 # ah okay so wm1808 is not the only problematic one... 14.43.43 # no, I think there are few other ones too, maybe we should gather all the datasheets we have and see 14.51.32 Join Gremuchnik [0] (~Gremuchni@fsf/member/gremuchnik) 14.54.47 # Hi, I put a Sandisk 16GB MicroSDHC Memory Card, Class 4, in my SansaClip+. Could I format it in ext4 or ext3 if I only use RockBox? Thanks! 14.54.56 # pamaury: I remember looking at our code for WM and it will not be that easy to unify 14.55.22 # Gremuchnik: no, rockbox supports fat exclusively 14.56.25 # wodz, thanks. Too bad though, fat sucks :-( Where could I log in a "requested feature"? 14.57.55 # forum, but this will have no effect in this case unless you code ext support by yourself and provide patch. This is complex task no-dev have interest in AFAIK 14.58.41 # ok. thanks. you guys rock! cya :-) 14.58.46 Quit Gremuchnik (Quit: Бывайте ребята) 15.03.17 Join amayer_ [0] (~amayer@mail.weberadvertising.com) 15.12.37 Join foolsh [0] (~foolsh@nc-76-0-169-20.dhcp.embarqhsd.net) 15.15.17 # bluebrother: what is the correct Qt way of going from a QString to a char * ? 15.19.22 Join dfkt [0] (dfkt@unaffiliated/dfkt) 15.35.01 Join nateloaf [0] (~nwild@S0106bcaec5c3e90e.wp.shawcable.net) 15.49.55 Join TheSphinX_ [0] (~briehl@p5B3233D2.dip.t-dialin.net) 15.51.23 Quit Zagor (Quit: Clint excited) 15.52.09 Quit TheSphinX^ (Ping timeout: 252 seconds) 15.55.55 Join TheSphinX^ [0] (~briehl@p579CC2D8.dip.t-dialin.net) 15.58.40 *** Saving seen data "./dancer.seen" 15.59.03 Quit TheSphinX_ (Ping timeout: 260 seconds) 16.00.21 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 16.14.09 Quit kevku (Ping timeout: 245 seconds) 16.27.24 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 16.34.50 Join WalkGood [0] (~4@unaffiliated/walkgood) 16.40.23 Quit lorenzo92 (Ping timeout: 264 seconds) 16.43.40 Quit hype (Ping timeout: 240 seconds) 16.47.28 Join hype_ [0] (~hype@82.199.174.16) 16.48.47 Quit Marex (Ping timeout: 264 seconds) 16.49.24 Join Marex [0] (~Marex@2a01:430:d:0:2cc:6ff:fefc:db16) 16.57.51 Join Zagor [0] (~bjst@46.35.227.87.static.tab.siw.siwnet.net) 16.57.52 Quit Zagor (Changing host) 16.57.52 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 17.02.40 Join stoffel [0] (~quassel@pD9E41525.dip.t-dialin.net) 17.07.05 Quit ender` (Quit: I'm a complex person. I have a real and an imaginary part.) 17.07.50 Join ender` [0] (~ender@foo.eternallybored.org) 17.09.15 Quit y4n (Quit: Do you like hurting other people?) 17.10.33 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 17.13.49 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 17.32.54 Quit ender| (Read error: Operation timed out) 17.35.33 # bluebrother: http://gerrit.rockbox.org/r/#/c/391/ 17.35.40 # g#391 17.35.42 # Gerrit review #391 at http://gerrit.rockbox.org/r/391 : Add initial support for the Zen X-Fi3 and the CAB archives. by Amaury Pouly (changes/91/391/1) 17.43.57 Quit stoffel (Remote host closed the connection) 17.46.45 Join ender| [0] (krneki@2a01:260:4094:1:42:42:42:42) 17.51.50 Quit Zagor (Quit: Clint excited) 17.56.05 Quit wodz (Quit: Leaving) 17.58.25 Quit bebna (Quit: Leaving.) 17.58.42 *** Saving seen data "./dancer.seen" 18.04.43 Join Strife89 [0] (~Strife89@adsl-98-80-214-204.mcn.bellsouth.net) 18.29.23 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 18.45.44 Nick TheJacquerie is now known as veryone (radio23@newelite.bshellz.net) 18.50.03 Quit hype_ (Quit: ["Textual IRC Client: www.textualapp.com"]) 18.51.01 Join hype [0] (~hype@82.199.174.16) 18.57.27 Quit pamaury (Quit: this->disconnect()) 19.14.55 Join advcomp2019 [0] (~advcomp20@71-213-217-202.sxcy.qwest.net) 19.14.57 Quit advcomp2019 (Changing host) 19.14.57 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 19.15.31 Quit |akaWolf| (Ping timeout: 255 seconds) 19.36.22 Join lebellium_ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 19.37.24 Join lebellium__ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 19.37.40 Quit lebellium (Ping timeout: 255 seconds) 19.37.48 Nick lebellium__ is now known as lebellium (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 19.38.14 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 19.41.09 Quit lebellium_ (Ping timeout: 256 seconds) 19.55.28 Quit hype (Quit: Computer has gone to sleep.) 19.56.25 Join hype [0] (~hype@82.199.174.16) 19.58.45 *** Saving seen data "./dancer.seen" 19.59.12 Join n1s [0] (~n1s@nl118-168-30.student.uu.se) 19.59.12 Quit n1s (Changing host) 19.59.12 Join n1s [0] (~n1s@rockbox/developer/n1s) 20.00.43 Join lebellium_ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 20.00.59 Quit lebellium (Ping timeout: 256 seconds) 20.01.05 Nick lebellium_ is now known as lebellium (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 20.11.12 Nick veryone is now known as TheJacquerie (radio23@newelite.bshellz.net) 20.16.01 Quit scorche (Disconnected by services) 20.16.04 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 20.23.02 Quit ender` (Quit: The Web is a procrastination apparatus: It can absorb as much time as is required to ensure that you won't get any real work done.) 20.33.00 Join ender` [0] (~ender@foo.eternallybored.org) 20.41.05 Join lebellium_ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 20.43.52 Quit lebellium (Ping timeout: 264 seconds) 20.44.01 Nick lebellium_ is now known as lebellium (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 20.48.06 Quit melmothX (Quit: bau) 21.02.25 Part WalkGood 21.10.00 Quit y4n (Quit: Do you like hurting other people?) 21.14.49 Part LinusN 21.18.06 Join prof_wolfff [0] (~prof_wolf@62.83.50.196.dyn.user.ono.com) 21.22.27 Join SuperBrainAK [0] (~Andy@71-36-165-101.phnx.qwest.net) 21.29.46 Join einhirn [0] (~Miranda@p4FC74DF1.dip0.t-ipconnect.de) 21.33.57 Quit einhirn (Ping timeout: 246 seconds) 21.35.08 Quit foolsh (Ping timeout: 256 seconds) 21.37.09 # pamaury: nice. I've added some comments, might add some more later. 21.38.01 # I don't know rbutil and qt very much so I probably made some bad things ^^ 21.38.08 # I tested it and it worked 21.38.24 # I had to rename mspack's system.h to system-mspack.h because of a name conflict 21.39.43 # I tried to factor ziputil and mspackutil, I don't know if I did it in a very qt way, you tell me 21.40.22 # the changes are #include to #include "bla" 21.40.35 # but okay, I'll try to put as a separate commit 21.41.41 # hmm, changing those includes shouldn't be necessary. 21.42.10 # I didn't understand how you could put the mspack directory in the includes 21.42.15 # might be a good idea to build a libmspack and link that ... 21.42.40 # ok 21.42.43 Join Sanguinius [0] (~kvirc@93-40-96-20.ip38.fastwebnet.it) 21.43.01 # like this: 21.43.02 # INCLUDEPATH += $$RBBASE_DIR/rbutil/ipodpatcher 21.43.07 # in rbutilqt.pro 21.43.29 # building some libmspack.a and linking that would also remove the system.h clash 21.43.33 # do you think it's better to build mspack as a separate library ? 21.44.07 # not sure. 21.44.33 # this might also be a good chance to rename system.cpp to hostsystem.cpp 21.44.34 Quit Strife89 (Ping timeout: 264 seconds) 21.44.44 # a class named System has a somewhat generic name :) 21.45.10 # JdGordon: ping 21.45.55 # the changes to rbutil.ini are nothing that needs discussion IMO -- they could go in pretty much now. That would enable support for the X-Fi3, the only remaining problem for the user would be to perform the cabextract manually :) 21.46.55 # I can try to build Windows development binaries afterwards the next couple of days so people can test. 21.47.14 # would be interesting to see if the new HttpGet class is working without problems as well :) 21.47.29 # ok, the goal was more to put everything together so I can test it, I didn't expect to commit it as one block anyway 21.48.00 # ok 21.48.48 Join foolsh [0] (~foolsh@nc-76-0-169-20.dhcp.embarqhsd.net) 21.49.13 # now I know what to fix ^^ 21.49.26 Join Strife89 [0] (~Strife89@adsl-98-80-214-204.mcn.bellsouth.net) 21.49.57 # is the way of making ZipUtil and MsPackUtil children of some common class ok or you prefer something else ? 21.49.58 # * Strife89 believes he has found a bug to report. 21.51.16 # I'm a bit unsure about it but I think it makes sense doing it that way 21.56.55 Join Strife1989 [0] (~Strife89@adsl-98-80-230-29.mcn.bellsouth.net) 21.58.46 *** Saving seen data "./dancer.seen" 22.00.10 Quit Strife89 (Ping timeout: 240 seconds) 22.13.40 Nick Strife1989 is now known as Strife89 (~Strife89@adsl-98-80-230-29.mcn.bellsouth.net) 22.15.46 Quit SuperBrainAK (Ping timeout: 248 seconds) 22.32.23 Quit n1s (Quit: Ex-Chat) 22.40.22 Quit jhMikeS (Ping timeout: 255 seconds) 22.52.38 Quit Strife89 (Ping timeout: 276 seconds) 23.09.43 Join TheSphinX_ [0] (~briehl@p5B323D69.dip.t-dialin.net) 23.11.58 Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche) 23.12.47 Quit TheSphinX^ (Ping timeout: 248 seconds) 23.13.10 Quit amayer_ (Ping timeout: 256 seconds) 23.21.55 # kugel: ? 23.24.26 # JdGordon: do you remember the reason you implemented STYLE_XY_PIXELS instead of just un-staticing putsxyofs()? 23.24.44 # I'm working on a scroll engine/lcd api overhaul 23.41.40 Quit bertrik (Ping timeout: 240 seconds) 23.51.08 Quit nateloaf (Quit: Leaving.) 23.52.55 Join Wally [0] (~Wizard@powermodell.com) 23.53.04 # IS there a shuffle feautre in rockbox? 23.53.21 # hold on 23.53.24 # I'm looking wrong 23.55.54 # <[Saint]> Yes, and, yes you are. 23.56.08 # * [Saint] suggests reading the manual, or, reading it better. ;) 23.58.14 Join jhMikeS [0] (~jethead71@50.4.240.19) 23.58.14 Quit jhMikeS (Changing host) 23.58.14 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 23.58.48 *** Saving seen data "./dancer.seen"