--- Log for 27.08.113 Server: hitchcock.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 4 days and 22 hours ago 00.01.48 Quit jlbiasini (Quit: jlbiasini) 00.19.55 Nick SuperBrainAK is now known as DormantBrain (~andy@shared02.balt01.cd.2g2u.net) 00.45.40 Quit bertrik (Remote host closed the connection) 00.49.14 Quit thomasjfox_ (Quit: Konversation terminated!) 00.57.46 Quit ender` (Quit: #include | #define Bork for | #define bork fork() | int main() { Bork(bork ;; bork) bork; }) 01.07.04 Quit pamaury (Ping timeout: 245 seconds) 01.22.27 # <[Saint]> lebellium: I admit, that behavior is non-obvious. 01.22.52 # <[Saint]> I guess some RTC will present a bullshit time/date if RTC is non-set. 01.23.08 # <[Saint]> For instance: 01:01:1970 00:00 01.23.19 # <[Saint]> ^ a fairly common one. 01.23.45 # I guess I already got --:-- 01.23.47 # <[Saint]> Apparently when 's RTC is non-set, its simply ":" 01.23.56 # <[Saint]> ...which is kinda annoying. 01.24.24 # <[Saint]> But, anyway, yes...I did forget about the last tuple of that tag. 01.24.52 # yes sure. But then this tag is not what I wanted. I wanted to add a clock for RTC targets (Archos Recorder) and display another thing on my Ondio 01.24.59 # <[Saint]> Its (iirc) :P 01.25.21 # ah? 01.25.39 # oho! 01.25.40 # indeed 01.25.42 # :) 01.25.44 # <[Saint]> errr, sorry, s/set/present/ 01.26.15 # %?cc works 01.26.20 # that's what I wanted 01.26.24 # * [Saint] nods 01.26.40 # <[Saint]> yet more things I need to make clearer in the documentation. 01.26.52 # then I can use "maybe" as "there is no RTC in hardware" 01.27.01 # <[Saint]> There are other tags that use the last tuple similarly. 01.27.08 # <[Saint]> like volume and battery, for example. 01.28.14 # <[Saint]> %?bc 01.28.35 # the last one is not 100%? 01.28.42 # <[Saint]> No. 01.28.45 # max volume* 01.28.58 # heh 01.29.02 # who knows that? :D 01.29.07 # <[Saint]> The very last tuple _should_ be "indeterminable" 01.29.24 # I thought this was only valid for battery and FM strength 01.30.15 # <[Saint]> Not being able to determine the current volume is incredibly unlikely, but iirc, the tag does behave this way. 01.30.22 # hum 01.30.30 # Should I update 10 themes? :S 01.31.15 # <[Saint]> No, its not really an issue, more of a "safety net" I believe. Conditions will usually work happily if one or more tuples are stripped from the end of it. 01.32.01 # <[Saint]> the volume tag usually catches people out compared to how the think it works. 01.32.37 # <[Saint]> 01.32.45 # I thought I used cabbiev2 as example for volume. But my 1st theme was back to 2011, so I don't remember exactly 01.33.33 # <[Saint]> It wouldn't surprise me at all if cabbie didn't include this, as not knowing the current volume is incredibly unlikely. 01.34.20 # <[Saint]> I notice lots of user-built themes forget to include tuples for line level and ranges above line level. 01.34.41 # <[Saint]> so their volume gauges only go as high as -1dB 01.35.18 # that probably means the documentation is not clear enough or they copied a bad theme :D 01.35.47 # <[Saint]> Or both. At least I can do something about the former. 01.35.55 # <[Saint]> The latter is harder to combat. 01.35.57 # <[Saint]> :) 01.46.18 *** Saving seen data "./dancer.seen" 01.47.01 # * [Saint] plays with his new 240GB iPod Video 02.00.14 Join __jae__ [0] (~jae@dedicated.jaerhard.com) 02.02.03 Quit DormantBrain (Ping timeout: 245 seconds) 02.04.00 Join DormantBrain [0] (~andy@74.112.203.135) 02.04.21 Nick DormantBrain is now known as SuperBrainAK (~andy@74.112.203.135) 02.04.31 Quit __jae__ (Ping timeout: 240 seconds) 02.09.45 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130822154523]) 02.33.55 Quit habys (Quit: WeeChat 0.4.1) 02.42.41 Quit crose (Quit: Leaving) 02.43.11 Join habys [0] (~luke@arikui.org) 03.20.21 Nick jmspeex_ is now known as jmspeex (jm@mf4-xiph.osuosl.org) 03.35.40 # hey guys, what is the status of the USB issue for the Ipod Nano 2G? 03.46.19 *** Saving seen data "./dancer.seen" 03.58.51 # vedos: interesting... thanks for sharing the information 03.59.06 # at least apparently you can boot to original FW without reflashing? 04.25.32 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.25.42 Quit amiconn (Disconnected by services) 04.25.49 Quit pixelma (Disconnected by services) 04.25.50 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.25.52 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.28.21 Quit uwe_ (Read error: Operation timed out) 04.30.39 Join uwe_ [0] (~uwe_@dslb-188-105-027-013.pools.arcor-ip.net) 05.12.57 Quit TheSeven (Disconnected by services) 05.13.07 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 05.46.23 *** Saving seen data "./dancer.seen" 05.46.42 Quit [Saint] (Remote host closed the connection) 05.47.51 Join [Saint] [0] (~saint@rockbox/user/saint) 06.21.15 Join advcomp2019__ [0] (~advcomp20@65-131-164-27.sxct.qwest.net) 06.21.15 Quit advcomp2019__ (Changing host) 06.21.15 Join advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019) 06.24.27 Quit advcomp2019_ (Ping timeout: 256 seconds) 07.33.42 Join saratoga [0] (123e1c32@gateway/web/freenode/ip.18.62.28.50) 07.34.08 # who has access to the gerrit config? changing the launch page to "http://gerrit.rockbox.org/r/#/q/status:open+project:rockbox,n,z" would prevent showing the sandbox entries 07.34.16 # http://gerrit.rockbox.org/r/#/q/status:open+project:rockbox,n,z rather 07.38.44 Nick SuperBrainAK is now known as DormantBrain (~andy@74.112.203.135) 07.46.25 *** Saving seen data "./dancer.seen" 08.03.46 Quit soap (Ping timeout: 260 seconds) 08.07.30 # <[Saint]> Holy crap the iPod Video boots fast with nothing but rockbox in the OSOS 08.07.37 # <[Saint]> No dual-boot, but...meh. 08.07.55 # <[Saint]> Its about 4~5 seconds faster than stock Rockbox install. 08.09.45 # * [Saint] is very much liking his new iPod Video 08.09.56 # <[Saint]> ...if only it had a better CPU 08.11.32 # <[Saint]> I was lucky enough to get one of the 64MB RAM models. The pawn show I got it from apparently just looked at the serial number to determine the specification. It was listed as being 80GB, but it has the 240GB aftermarket Toshiba disk in it, and an aftermarket 800mAh battery. 08.11.48 # <[Saint]> All for $70 NZD, quite the score. 08.14.57 # nice 08.15.32 # <[Saint]> I would've been happy if it was stock, as it is in nice condition. 08.15.41 # the HDD in my Classic makes it uncomfortably slower than my Fuze+ though 08.15.49 # <[Saint]> The aftermarket parts were a very welcomed surprise, though. 08.16.23 # <[Saint]> ALso, yes...HDD targets do seem very slow when you're used to flash storage. 08.16.27 # seems like I'm always waiting for the HDD to spin down 08.16.46 # <[Saint]> But, I don't mind the sacrifice in speed for the additional capacity it brings. 08.17.00 # <[Saint]> y'know there's a spin-down setting, right? 08.17.09 # <[Saint]> set it to 3 seconds. 08.17.41 # <[Saint]> (iirc, that's the lowest selection available) 08.18.04 # I meant it's always loading stuff 08.18.08 # no idea what 08.18.38 # <[Saint]> Ah. 08.18.56 # and it feels like I have to handle it like a fragile child with a bone disease or something 08.19.14 # <[Saint]> Mine behave fine. 08.19.19 # * [Saint] shrugs 08.19.44 # <[Saint]> ...now to transfer 240GB at ~6MB/s 08.19.48 # <[Saint]> :-S 08.19.55 # mine goes to 20! 08.20.22 # <[Saint]> My Classic does too, this Video doesn't seem terribly speedy. 08.34.54 # <[Saint]> Booting two iPod Videos next to each other, one with a completely stock install, and the other with Rockbox is OSOS alone makes for quite the dramatic comparison. 08.35.21 # <[Saint]> The OSOS install has booted and spun down the HDD before the stock install finished booting. 08.36.54 # what's OSOS? 08.40.07 # * [Saint] forgets the exact acronym 08.41.03 # <[Saint]> Have a look at http://www.rockbox.org/wiki/IpodPatcher#Advanced_usage 08.42.21 # <[Saint]> The installation method I use is "4) OSOS contains only Rockbox" 08.44.40 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 09.05.44 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 09.09.55 Join ender` [0] (krneki@foo.eternallybored.org) 09.13.46 Quit bertrik (Remote host closed the connection) 09.16.39 Join soap [0] (~soap@cpe-174-102-96-10.woh.res.rr.com) 09.16.39 Quit soap (Changing host) 09.16.39 Join soap [0] (~soap@rockbox/staff/soap) 09.19.07 Join petur [0] (~petur@rockbox/developer/petur) 09.25.53 Join LinusN [0] (linus@giant.haxx.se) 09.34.58 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 09.46.29 *** Saving seen data "./dancer.seen" 10.08.01 Quit saratoga (Quit: Page closed) 10.27.59 Join einhirn [0] (~Miranda@p4FC74B3B.dip0.t-ipconnect.de) 10.32.38 Quit einhirn (Ping timeout: 256 seconds) 10.49.41 Quit pamaury (Ping timeout: 264 seconds) 11.07.06 Join krabador [0] (~krabador_@unaffiliated/krabador) 11.17.55 Quit bluebrother (Disconnected by services) 11.18.02 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 11.19.09 Quit fs-bluebot (Ping timeout: 246 seconds) 11.20.26 Join fs-bluebot [0] (~fs-bluebo@f053155007.adsl.alicedsl.de) 11.21.50 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.26.23 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 11.28.42 Join jlbiasini [0] (~metaphysi@ABordeaux-651-1-197-94.w86-201.abo.wanadoo.fr) 11.30.09 Join __jae__ [0] (~jae@80.82.209.27) 11.30.34 # [7]: ping 11.34.37 Quit __jae__ (Ping timeout: 240 seconds) 11.45.31 # wodz: yes? 11.46.31 *** Saving seen data "./dancer.seen" 11.47.35 # pamaury: we should wait for kugel to have a look to it too, but if you want to have a look yourself, I redid my g#569... 11.47.38 # 3Gerrit review #569 at http://gerrit.rockbox.org/r/569 : 3touchpad: Disable touchpad on softlock. by Jean-Louis Biasini (changes/69/569/30) 11.48.44 # pamaury: which crt0.S you were referring to when talking about rk27xx hwstub port? 11.49.28 # pamaury: And another question, how to define structure in IDA which contains another structure as a member? 11.50.23 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 11.54.09 Join crose [0] (~John@116-66-190-109.dsl.ovh.fr) 12.56.19 Quit rdn (Remote host closed the connection) 12.58.24 # pamaury: could you test g#577 on your device? Also if you know something about the question given as comment that would help... 12.58.26 # 3Gerrit review #577 at http://gerrit.rockbox.org/r/577 : 3touchscreen: softlock touch settings implementation by Jean-Louis Biasini (changes/77/577/5) 13.18.07 # jlbiasini: what about the simulator? 13.18.31 # how would he test touchpad sensitivity in the sim? 13.18.39 # o_O 13.18.51 # er 13.18.56 # I misread that 13.25.17 Join __jae__ [0] (~jae@dedicated.jaerhard.com) 13.30.03 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130822154523]) 13.31.25 # wodz: the crt0.S in hwstub/stub/, there is only one... 13.31.41 # wodz: to create substructures, create a field (with 'd') and then press Alt+Q 13.33.25 # kugel: thanks very much for your comment! The simulator exclusion is beccause the driver part doesn't get compilated in the simulator leading to a compilation error because the _device doesn't get declared/defined pamaury told me to exclude it to solve this but pehraps do you have a better idea? 13.34.37 # pamaury: wait but this crt0.S only setups stack, clear bss and jumps to main so what do you really commented out? 13.35.42 # hum, really ? that must be on my working copy then...but I thought I pushed it to the trunk 13.41.18 # jlbiasini: should be properly simulated 13.46.32 *** Saving seen data "./dancer.seen" 13.47.02 # wodz: the stub relocates itself in HEAD 13.47.57 # jlbiasini, pamaury: fwiw, I would like to discuss why/if there's a need for a setting for this 13.48.21 # pamaury: will look today evening 13.48.28 # kugel: what do you suggest, make it the default behaviour ? 13.48.39 # since it only affects the fuze+, an unstable port, changing existing behavior is acceptable 13.49.21 # yes, the new behavior makes more sense than the because a touchpad is a lot more sensitive than tactile buttons 13.49.49 # s/than// 13.50.00 # kugel: why not but the discussion already occured. But as I'm trying to expand that behaviour to touchscreen target too (see g#577) it would also change behaviour of those target 13.50.03 # 3Gerrit review #577 at http://gerrit.rockbox.org/r/577 : 3touchscreen: softlock touch settings implementation by Jean-Louis Biasini (changes/77/577/5) 13.50.12 # that's fine for me, but what about touchscreen then ? 13.50.52 # do we have touchscreen targets wihtout hardware lock button? 13.51.04 # kugel: yes 13.51.08 # ondav777 13.51.12 # at least 13.51.27 # zen-xfi2 13.51.35 # android/sdl 13.51.37 # the onda's aren't even unstable 13.52.00 # we have no stable touchcreen targets, we're pretty free to experiment I'd say 13.52.12 # great then 13.53.18 # I ws of the idea that a setting was useless in the first place, but the do-not-change-usual-behaviour kind of scare pamaury and me 13.53.36 # obviously we need to make sure there's still a way to unlock 13.54.13 # that's the keymapper's job ;) But yeah I need everyone wants the device to behave this way nowadays, and you're right, there is no really stable touchscreen targert 13.54.15 # *target 13.54.47 # anyway there is also another setting comming soon: the lock only touchdev on softlock 13.55.41 # jlbiasini: why would you want that? 13.55.51 # and I would like to have touchpad sensitiivity enlarge to get used by touchscreen if possible. I think it maks sense to have those general touch setting together 13.55.52 # let me guess: use volume buttons while screen off 13.56.04 # exactly 13.56.39 # that's an old problem, we ideally want a generic solution to that. sansa clips and other targets have this issue as well 13.57.29 # there is a lot of difference betwenn touchpad and hard key. So people often want to have their touchpad lock and still want to use hard button. As it really depend on people/situtation a setting is mandatory on this 13.57.40 # I liked the behavior of CM a few versions ago: when the screen is off the volume buttons still work and a long press on those skips tracks 13.58.02 # CM? 13.58.09 # cyanogenmod 13.59.28 # I think that we should start be the obvious hard and virtual keys have to be seperated 13.59.47 # then we can add a different keympas on hold 14.00.11 # the clip have only hard keys 14.00.41 # the right solution is probably a different keymap on hold, virtual vs hard is not sufficient 14.00.46 # I think this has very little to do with touch or not 14.00.58 # so it's another problem how do you call that, othogonality :p :D 14.01.27 # this could be handle with a special keymaps on hold 14.01.46 # so let's go back to the current patch to implement the lock: what do we need to make that work on the sim and to be as clean as possible and to handle touchpad and touchscreen ? 14.01.47 # I was also thinking about something like that before 14.02.31 # yes because I'm not familliar at all with simulator so i'm a bit lost on this... 14.03.00 # I don't really like the touchpad_filter_enabled of the last commit, I don't get why it is there 14.03.01 # a separate keymap (in particular one that doesnt depend on the current context/screen) when locked seems sensible to me 14.03.21 # s/commit/âtch 14.03.23 # *patch 14.03.57 # pamaury: it an imitation of the touchscreen_to_pixel implementation 14.04.44 # yes and I really dislike this one, this has always make the simulator even more tricky to work with touchscreen 14.05.03 # it filter the driver output based on BUTTON_TOUCHPAD and thus provides a generic way to silent touchpad evenn on touchpad without a knowned power saving function 14.05.57 # very usefull actually but pehraps there would be a better way to implement it 14.06.45 # as I understand it it basically there to filter out BUTTON_TOUCHPAD (a bitmask) buttons and still let tactile keys through 14.06.46 # I don't like it because it puts more logic in the low level driver, which you then have to emulate in the simulator 14.07.13 # after all I'm only rewriting the whole stuff for the second time :D so if there are better idea on the implementation please, tell me... 14.08.51 # I agree that not being able to test the implementation in the simulator is really a pull down 14.09.17 # especially when it's something that would impact about 10 different targets... 14.09.39 Join einhirn [0] (Miranda@bsod.vpn.tu-clausthal.de) 14.10.28 # what about this: in action.c, we call touchpad_enable_device (#ifdef TOUCHPAD) and touchscreen_enable_device(#ifdef TOUCHSCREEN) 14.10.53 # for native targets, we implement touch{pad,touchscreen}_enable_device (with power management for fuze+ and boolean for others) 14.11.09 # for hosted, we add them in firmware/hosted/sdl/button.c 14.11.23 # I have a question about drivers actually: why doesn't android build have a target-button.c? And where am I suppose to declare my touchscreen_enable_device then? 14.11.34 # and for this to work, we need a define of the touchpad buttons to filter them out in the sim 14.11.49 # pamaury: a wrapper in button.c would be ok...that does compile for the sim doesnt it? 14.12.05 # yes I think it does 14.12.30 # I totally agree with that except I don't get it at all... 14.12.38 # in any case, we will need some define to tell the simulator which buttons are the touchpad and which one aren't... 14.12.39 # jlbiasini: it has a button-android.c somewhere 14.12.57 # yes but no button-android.h 14.13.06 # pamaury: right, that's in button-target.h which is seen by the sim 14.13.51 # jlbiasini: it's called button-target.h 14.14.29 # but there are none in the android dir I think, I didn't find any 14.14.36 # ok, so we keep the BUTTON_TOUCHPAD define in button-target.h, drop the filter function and implement touchpad/screen_enable_device in hosted/sdl button driver which in turn uses a boolean and the BUTTON_TOUCHPAD define 14.14.45 # and for android, well I don't know 14.16.01 # jlbiasini: it's in the app subdir 14.16.23 # for android I guess we can filter touchscreen in hosted/android/button.c:button_read_device 14.16.28 # pamaury: I think so 14.16.43 # does the android port has a softlock mechanism ? 14.16.58 # or does it rely on the OS ? 14.17.23 # yes but I thinks this one is more app related and doesn't get include in button_android.c 14.17.26 # not that I'm aware of 14.18.28 # in sdl there is button-sdl.h button-sdl.c apps/button-target.h app/button-application.c 14.18.37 # kugel: jlbiasini: let me have a try at this, I'll post the patch in a 5 minutes 14.18.48 # ok 14.21.24 # kugel: actually button-android.c include buttonmap.h not very consistent but we can put it there 14.22.21 # jlbiasini: button-target.h is always included, implicitely via button.h 14.22.44 # (if not its a bug) 14.22.51 # ok 14.24.58 # pamaury: what I don't get is how you are going to get generic silent touchpad when no power saving is avalaible, but I guess that I would just wait to see your implementation before complaining 14.28.06 # we implement it for every target which has touchpad/touchscreen, ie no generic 14.29.31 # the point of the filter was precisely to have a generic function... If not I can implement it myself it's not really dificult... 14.30.40 # at least we could have a filter in action.c 14.31.00 # I don't really like it, from the point of view of someone not knowing how it works, if you split it in many places it gets hard to understand. I think it's just simpler this way: for a new port just implement touch*_enable_device, that's one boolean for a start so very easy and for touchpad just add an extra define for the simulator 14.31.52 # I was thinking of describing the code in the wiki after having implemented it 14.32.06 # just wait for my code and then comment ;) 14.32.08 # <[7]> wodz: pong 14.32.12 # ok 14.33.38 # [7]: pamaury answered my question already (about structs in ida) 14.33.43 # but I think the generic way is really important else It would basically be a f+ functionnality and there not need to paly around with all kind of ifdef everywhere 14.34.30 Join robin0800 [0] (~Robin0800@cpc1-brig15-2-0-cust755.3-3.cable.virginmedia.com) 14.38.00 Join amayer [0] (~amayer@mail.weberadvertising.com) 14.41.03 # * jlbiasini starts to understand what is pamaury is talking about... 14.47.33 # may I suggest something at the same time ? It requires to answer one question: what is a touchpad ? 14.48.02 # because at the same time we do this, we could also report the touchpad absolute position in button data 14.48.19 # it will be unused for now but if one day someone wants to implement gestures... 14.49.31 # we could even move the button interpretation from the drive to touchpad.c, using touchpad areas just like with touchscreen 14.49.36 # *driver 14.50.26 # pamaury: for the absolute report I was also thinking about something like that 14.51.07 # kugel: any thoughts ? 14.51.54 # for the second part it seems to me difficult because most touchpad device at least till now are at least partly button oriented, even the fuze+ that is probably the more advanced touchpad target we have for now 14.52.51 # ie having generic mapping like on touchscreen doesn't really make sense IMO 14.53.16 # not generic, generic parser 14.53.38 # each target defines regions for buttons and touchpad.c lookup this mapping to find the button 14.53.51 # it is how it works on the simulator btw 14.56.08 Quit kugel (Remote host closed the connection) 14.56.16 Join kugel [0] (~kugel@rockbox/developer/kugel) 14.57.39 # pamaury: yes you are right this definitely makes sense but for what I understand f+ is for now the only real touchpad device. Others are merely a combination of separated touch element 14.58.08 # so I don't know if it's worth to implement such a thing for only one target 14.59.40 Quit robin0800 (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) 14.59.47 # I have some potential targets in mind which have a touchpad: samsung YP-Q2, YP-T10 too 15.02.03 # ok then it would makes sense... 15.02.42 # maybe that should be part of another commit but it's better to think about this ahead 15.02.52 # so you're right, a filter like function it probably better 15.04.35 # I guess that touchpad.c is going to be even closer to touchscreen.c so? 15.05.06 # yes 15.05.57 # which worries me a bit 15.06.24 # usine à gaz spirit :D 15.07.04 # what's the english equivalent of that btw? 15.07.23 # the kitchen sink? 15.07.43 # the thing is that touchscreen.c is mostly screen agnostic except for grid mode 15.08.06 # and I can't think of a device with both touchpad and touchscreen 15.08.39 # what do you mean by "screen agnostic" 15.09.12 # it doesn't care that it is a touchscreen or a touchpad 15.09.39 # it's mostly in apps/ and button.c that the fact that a touchscreen is a touchscreen is used 15.10.42 # as a matter of fact a lot of touch function could be shared between all touch device 15.16.18 # pamaury: I think we should first poost on the mailing list on that and wait because else it's goning to end up with people coming it the last minute to say that it ain't right 15.16.37 # gee! this think is never to end up in the tree... 15.16.41 # *thing 15.17.17 Quit michaelni (Ping timeout: 264 seconds) 15.18.43 Quit jlbiasini (Quit: jlbiasini) 15.23.47 Join maruk [0] (~papier@titanium.v6.sdv.fr) 15.28.58 # jlbiasini: kugel: what about this: https://gist.github.com/pamaury/6353512 15.29.02 # (untested) 15.29.56 Join michaelni [0] (~michael@188-22-99-23.adsl.highway.telekom.at) 15.34.09 # pamaury: ok, it is no surprise that updated crt0.S doesn't work on rk27xx. This core doesn't implement copro interface so you likely end up with data abort or something. 15.34.27 # or undef instr 15.34.37 # ah, ok, I thought this 15.34.50 # so that's just a #ifdef to add then 15.35.01 # maybe I'll have time to look more in depth at the usb problem later today 15.36.11 # I will have some time this evening so maybe we could colaborate 15.36.47 # yes 15.46.35 *** Saving seen data "./dancer.seen" 15.50.44 Quit krabador (Quit: Sto andando via) 16.02.11 Quit Zagor (Quit: Clint excited) 16.31.00 Quit pamaury (Ping timeout: 248 seconds) 16.55.18 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 16.56.39 Quit shamus (Ping timeout: 240 seconds) 16.56.46 Join shamus [0] (~shmaus@ip-206-192-194-158.marylandheights.ip.cablemo.net) 16.57.31 Join n1s [0] (~n1s@nl118-168-30.student.uu.se) 16.57.31 Quit n1s (Changing host) 16.57.31 Join n1s [0] (~n1s@rockbox/developer/n1s) 17.12.49 # <[Saint]> Hmmmm...yah, ...nah. iPod Video definitely needs UI boosting. 17.13.53 # <[Saint]> I guess its the relatively large LCD and relatively small CPU making the difference. 17.15.13 # <[Saint]> I thought maybe it was worth seeing if I could get away with disabling it, but, nope. 17.16.26 # it also gets quite a few irqs from scrollwheel 17.16.39 # <[Saint]> Ah. 17.18.17 # <[Saint]> I got away with disabling it on the Classic, initially - early on in the port - it was basically unusable without boosting on UI interaction, now however - similar to the Fuze + - the CPU almost never needs to boost under normal circumstances. 17.18.49 # <[Saint]> I don't think this adds up to very much power saving, though, as that SoC is quite efficient. 17.19.23 # scrolling lines are kinda slow on my Classic with my themes 17.21.36 Quit Poodlemastah (Quit: ZNC - http://znc.in) 17.22.34 # <[Saint]> well, yay, glad that worked. 17.23.10 # <[Saint]> I now have an ipod bootloader that doesn't care about the Apple OS or IPL anymore. 17.24.27 # <[Saint]> Perfect for OSOS install - since booting the Apple OF isn't actually possible. 17.24.45 # <[Saint]> ...and IPL is dead. 17.28.41 Quit wodz (Quit: Leaving) 17.32.44 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 17.34.26 Quit petur (Quit: Nettalk6 - www.ntalk.de) 17.39.43 Join madcat1990 [0] (~madcat199@216.185.65.74) 17.44.26 Quit Zagor (Quit: Leaving) 17.45.03 # Well, I was gonna report a bug, but apparently it has been fixed in Dev builds 17.45.22 # <[Saint]> Huzzah. 17.46.19 # I don't know what it is that is doing it, but here's how to reproduce it each time in 3.13 stable, and what it shows : http://pastie.org/private/tfy4ssfub9vtlgo3ruvtwg 17.46.32 # Seeing that it is fixed in Dev, I don't know if I should report it or not :X 17.46.36 *** Saving seen data "./dancer.seen" 17.47.20 # <[Saint]> If it is fixed in git head, don't report it, no. 17.53.05 Nick DormantBrain is now known as SuperBrainAK (~andy@74.112.203.135) 17.53.20 # Fair enough, I thought the same. Just wanted to make sure in case you guys needed it documented 17.54.15 # Btw, have I thanked you guys for the awesome work you do, today? 17.54.40 # <[Saint]> Not /today/... :) 17.54.58 # <[Saint]> But I have seen you do so in the past. Its appreciated, I'm sure. 17.56.09 # madcat1990: btw, the debug menu is not intended for users and bugs there should be expected 17.56.28 # <[Saint]> errr... 17.56.38 # <[Saint]> I don't think bugs should ever be expected. 17.56.50 # <[Saint]> Its not intended for users, sure, but it should work. 17.57.00 # [Saint], I agree wholeheartedly. It is my duty, as tester, to report any findings 17.57.28 # Also, I'm waiting on my next paycheck to make another donation 17.57.46 # >.< it has now reached the point where I find other Firmwares ugly, and dysfunctional. 17.58.42 # <[Saint]> One should expect to find bugs in the git head builds, possibly, and that's kinda the point of them...any reported bug is better than one that goes unnoticed, even if the user isn't technically supposed to be poking around there. :) 17.58.57 # <[Saint]> Anyhoo - its fixed, so - yay. :) 17.59.15 # I always poke around there. Especially the buffering thread one. I love to see how my device is buffering 17.59.24 # <[Saint]> Heh. 17.59.56 # And the debug scrollwheel when I had my iMini2G, loved it too, just through that one screen, I found it that the scroll wheel is nothing more than a touchpad 17.59.57 # <[Saint]> I only find it useful myself to check buffer allocations from the skin engine. 18.00.03 # not ugly magic 18.00.19 # Yeah =/ that engine is breaking USB on my device 18.00.25 # well, i'm pretty sure there are known bugs in there that noone has cared to fix but i don't remember any specific one right now 18.00.25 # Default themes work fine in rockbox though 18.00.36 # <[Saint]> you and a lot of other people. 18.00.52 # <[Saint]> and cabbie working, where others don't, makes no sense at all. 18.01.02 # <[Saint]> I *really* wish I knew what was going on there. 18.01.16 # <[Saint]> like, really...really really. 18.01.19 # This might be a stupid suggestion, but would the size of the files make a difference? or what they contain? 18.01.29 # there *HAS* to be something the others use that cabbie doesn't 18.01.38 # or something they use more 18.01.44 # Thusly, breaking the skinning engine 18.01.56 # <[Saint]> It very well may. I don't know. My best guess is bad alignment of memory allocations. 18.02.09 # But that's not done through the WPSes, is it? 18.02.25 # <[Saint]> Why some themes slide though, even when they are vastly larger than cabbie and far more complex code, I do not know. 18.02.35 # <[Saint]> Additionally, simpler, smaller themes also fail. 18.02.39 # <[Saint]> It is baffling. 18.02.48 # Then its not a thing of size 18.02.56 # its a thing of, a parameter being used that breaks it 18.03.23 # <[Saint]> No, even very simple themes that are essentially exact clones of cabbie can break USB. 18.03.35 # <[Saint]> Its not, afaik, any one tag or combination thereof. 18.03.40 # <[Saint]> It is *truly* baffling. 18.03.49 # <[Saint]> I can't find a definite trigger. 18.04.24 # <[Saint]> It has excaped the attempts of about half a dozen people's serious attempts at debugging. 18.05.07 # <[Saint]> lots of bugs have been caught and fixed whilst looking for the cause of this one, though, so that's great. 18.05.09 # Has anyone tried REPLACING cabbie with another theme and attempting to replicate it? 18.05.16 # maybe chunks of them are being loaded into memory, and left there? 18.06.08 # <[Saint]> I don't think so. The way memory allocation works shouldn't allow for this. And I have looked at the bufflib allocations whilst changing themes and there is no indication of leftovers. 18.06.20 # <[Saint]> I honestly have NFI what is happening. 18.06.24 # <[Saint]> Frustrating. 18.06.56 # You know what you guys need? a visual representation of a device's memory 18.07.25 # something along the lines of this : https://www.youtube.com/watch?v=tjcvR5McmSg 18.11.42 Join polemon_ [0] (~polemon@g224097173.adsl.alicedsl.de) 18.12.11 Join rdn [0] (~oop@cpe-69-204-124-212.buffalo.res.rr.com) 18.14.41 Quit polemon__ (Ping timeout: 240 seconds) 18.18.49 Join Strife89 [0] (~Strife89@2602:306:250f:2289:10e6:66d5:5350:6cbc) 18.21.09 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 18.21.32 Join wodz [0] (~wodz@87-207-223-0.dynamic.chello.pl) 18.22.41 # madcat1990: This is awersome. You need full system emulator though. We don't have such thing for any of our targets. Writing one is HUUUUGE task. 18.23.32 # I know. But it'd solve most of our debugging problems. :) 18.24.00 # Not really. 18.24.25 # there are things you cant relibly emulate 18.25.23 # there are? 18.25.32 # Noise? 18.27.08 # ok, 'can't' is unfortunate 'are hard to' is better 18.27.33 # Well, there's *lots* of things we can't emulate because we don't know how they actually work 18.27.49 # writing a full system emulator for a system that you don't ahve docs for requires assuming that your reverse-engineering is correct :) 18.28.08 # true, but it would also help the reverse-engineering! 18.28.34 # Bagder, if anything it'd prove ours wrong. 18.28.53 # obviously there are classes of bugs you can still catch even then, but some of the time you are just begging the question :) 18.30.16 # I really doubt there's an easy way to emulate ALL these devices. 18.30.43 # Best thing to do is replicate Rockbox's behavior on them, but that won't help us much 18.30.55 # Though, if by some chance, we can make a memory dump through USB 18.30.58 # and see what's happening?.. 18.31.16 # madcat1990: basically pamaury is working on this :-) 18.31.51 # So me and one of the devs are in the same wavelength. I'm not a complete idiot! yay 18.32.34 # BUT transfering mem dump through usb means that you cannot live test rockbox usb stack (although you can take a snapshot at particular event) 18.34.27 # Might not live test USB stack, but you can see when the skinning engine is being naughty 18.35.12 Join eyfour [0] (~eyfour@13.90-149-56.nextgentel.com) 18.35.34 # If the bug is reproducible on f+ I think we might ask pamaury to try. 18.36.31 Join Poodlemastah [0] (~Poodlemas@109-124-181-96.customer.t3.se) 18.37.00 # wodz, I can prolly ask a buddy of mine who bought one of those to test it 18.39.23 Quit maruk (Quit: Leaving.) 18.39.55 # <[Saint]> It is. 18.40.07 # <[Saint]> ...reproducible on Fuze +, I mean. 18.40.12 # great 18.45.50 # madcat1990: emulating a device like the fuze+ is really a lot of work, the documentation is very vague on a number of (crucial) points, so that probably wouldn't help much. What will help is live debugging, that we are currently trying to implement 18.47.01 # pamaury, I realise this. Which is why I'm saying, live USB Debugging will allow us to poke at the memory, but not live USB monitoring. But it will at least allow us to check what the skinning engine is doing 18.47.04 # and what's causing it to misbehave 18.49.50 # pamaury: can we try to insert hwstub into rockbox and trigger it on usb connect? That way we will be able to take mem snapshot at arbitrary time 18.50.05 # And dump it to the SD? 18.50.13 # no to PC :-) 18.56.35 Join pretty_function [0] (~sigBART@123.252.213.72) 18.57.46 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 18.57.49 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 19.00.28 # If I have struct foo_t { char a, char b, short c, char d} how it will be padded in array? I mean struct foo_t ble[100]? I guess compiler will try to guarantee halfword alignment of member c in every array item so should I expect trailing padding byte for every item? 19.01.35 # wodz: that's already more or less possible with my hwpatcher tool, although not very practical. But memory dump won't be easy to analyse either 19.03.14 # I don't say it will be easy 19.03.47 # pamaury: btw. what is the status of your amsv2 rom disasm? 19.10.15 Nick SuperBrainAK is now known as DormantBrain (~andy@74.112.203.135) 19.13.37 Quit eyfour (Quit: WeeChat 0.3.7) 19.16.43 Quit shamus (Ping timeout: 240 seconds) 19.22.07 Join shamus [0] (~shmaus@ip-206-192-194-158.marylandheights.ip.cablemo.net) 19.26.21 Quit [Saint] (Remote host closed the connection) 19.26.51 Part LinusN 19.27.47 Join [Saint] [0] (~saint@rockbox/user/saint) 19.37.17 # wodz: haven't work on this for a while, can send you my latest progress 19.39.45 # pamaury: I was just curious 19.46.39 *** Saving seen data "./dancer.seen" 19.48.48 Join polemon__ [0] (~polemon@e179239147.adsl.alicedsl.de) 19.50.56 Quit polemon_ (Ping timeout: 245 seconds) 19.57.47 Quit bertrik (Remote host closed the connection) 20.51.42 Quit thomasjfox (Remote host closed the connection) 20.54.30 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 20.59.18 Quit pretty_function (Remote host closed the connection) 21.09.13 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 21.46.41 *** Saving seen data "./dancer.seen" 21.57.45 Quit madcat1990 (Quit: Leaving) 22.03.18 Quit kevku (Ping timeout: 260 seconds) 22.32.16 Join bertrik [0] (~quassel@2001:610:76a:0:749c:5212:ba7c:37ba) 22.32.16 Quit bertrik (Changing host) 22.32.16 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 22.32.33 Join thomasjfox_ [0] (~thomasjfo@rockbox/developer/thomasjfox) 22.32.44 Join jlbiasini [0] (~metaphysi@ABordeaux-651-1-197-94.w86-201.abo.wanadoo.fr) 22.33.12 # pamaury: ping 22.34.31 Quit thomasjfox (Ping timeout: 276 seconds) 22.34.58 Nick thomasjfox_ is now known as thomasjfox (~thomasjfo@rockbox/developer/thomasjfox) 22.48.44 # pamaury: I just tried your patch it apply cleanly but gave me a lot of bug: http://pastebin.com/HY5VCqmu (this is just the beginning I cuted the following as it was endless... 22.59.44 Join einhirn [0] (Miranda@bsod.vpn.tu-clausthal.de) 23.00.18 Quit Strife89 (Quit: Heading out.) 23.08.43 Nick DormantBrain is now known as SuperBrainAK (~andy@74.112.203.135) 23.16.03 Join dewlap [0] (~dewlap@2001:5c0:1000:a::ad7) 23.17.32 Quit bertrik (Remote host closed the connection) 23.24.30 Quit n1s (Quit: Ex-Chat) 23.26.29 Quit amayer (Quit: Leaving) 23.30.43 # jlbiasini: as I said I didn't try to compile it, you have to learn how to fix this ;) In button.h I wrote #define "touchpad.h" instead of #include 23.31.33 # ok i'll have a look tomorrow then... 23.32.04 # trying to compile now... 23.32.23 # ok that does the work for touchpad, now touchscreen... 23.33.02 # pamaury: If you find time could you check if hwstub gets past setup request at all? 23.33.15 # wodz: last time I tried it didn't 23.34.02 # jlbiasini: I have updated the patch at https://gist.github.com/pamaury/6353512 23.34.31 # pamaury: So at least we have the same behavior 23.35.16 # let me have a try now 23.40.14 # wodz: you should definitely fix the usage() of tools/scramble.c for rockchip 23.40.26 # each time I use I have to lookup the source to realise I need the -modelnum= 23.41.02 # pamaury: sure, will fix it 23.41.08 # thanks 23.42.28 # hum, I get undefined instruction if I try to run it from microsd with scramble 23.43.34 # apparently the relocate code is broken on rk27xx 23.44.20 # pamaury: your patch work on f+ I'm givin a try on the ondav777 simulator to see on a touchscreen target 23.45.21 # some more compilation error, I'll see tomorrow 23.45.25 Quit jlbiasini (Quit: jlbiasini) 23.46.44 *** Saving seen data "./dancer.seen" 23.58.21 Join petur [0] (~petur@rockbox/developer/petur)