--- Log for 02.01.114 Server: adams.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 4 days and 7 hours ago 00.36.20 # <[Saint]> lebellium: sad to say thats probably due to only one touch target having FM, and no one caring about that target in the slightest except for when it stops building. 00.36.27 # <[Saint]> (D2) 00.37.26 # yeah... but now there is the YP-R1 too, it's time to care, I want the theme engine to work for touchtargets too :P 00.37.46 # <[Saint]> It should be trivial to add FM seek/skip tags. 00.38.06 # <[Saint]> But I'm somewhat busy getting drunk today. 00.38.38 # we can talk again tomorrow :) 00.40.41 # lebellium: whatcha wantt? 00.40.47 # ah! 00.40.52 # I have much work for you JdGordon :D 00.43.48 # JdGordon: touchscreen tags, FMS: 00.43.49 # -ffwd and rwd, I had to use prev and next again, with repeat_press. But it seems that there is no auto-tune that way. It stops seeking when I release the finger 00.43.51 # -play: music playback in the FMS -_- and "mute" is different from pausing the FM radio 00.43.52 # -the progressbar (frequencies) can't be moved with the finger 00.44.08 # ffwd and rwd don't work* 00.44.25 # -"menu" opens the context menu instead of going back to the main menu as in WPS 00.44.48 # -"contextmenu" doesn't work 00.45.55 # * JdGordon suggests digging up apps/gui/skin_engine/skin_touchsupport.c 00.46.08 # yes, it isnt setup for the radio at all 00.47.03 # I'm the 1st one to use FM radio on a touchscreen target? Well, nothing should surprise me anymore in Rockbox... 00.48.02 # <[Saint]> No. Youre forgetting we have two input systems. 00.48.09 *** Saving seen data "./dancer.seen" 00.48.16 # <[Saint]> Grid and absolute point. 00.48.20 # you mean the grid? 00.48.22 # yes 00.48.52 # <[Saint]> And the cowon has HW keys anyway iirc. 00.49.02 # grid is just a workaround for lazy guys who don't want to make a real touch theme 00.49.21 # <[Saint]> no. it predates it entirely. 00.49.39 Quit habys (Quit: WeeChat 0.4.1) 00.56.39 # [Saint]: actually, did you have time to look at my cabbiev2 240x400 progress bar fix? That was in september IIRC 01.00.28 Quit ender` (Quit: Religion is excellent stuff for keeping common people quiet. Religion is what keeps the poor from murdering the rich. -- Napoleon Bonaparte) 01.00.46 # <[Saint]> Oh. Errr. I thought I did. But if you're asking i guess that answers that question. Sorry. That's terrible. 01.01.07 # well, unless I missed a patch or commit 01.01.09 # let me check 01.03.09 # nope 01.03.30 # cabbiev2.240x400x16.wps hasn't been updated since 2012 01.08.37 Quit Narod- () 01.09.40 # [Saint]: http://www.rockbox.org/irc/log-20131010 if you need my dropbox link 01.23.09 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 27.0/20131216183647]) 01.46.54 Quit Gallomimia (Read error: Connection reset by peer) 02.04.42 Quit bertrik (Ping timeout: 272 seconds) 02.12.37 Quit onder` (Ping timeout: 245 seconds) 02.13.11 Join onder` [0] (~onder@dyn-dsl-to-76-75-115-88.nexicom.net) 02.48.11 *** Saving seen data "./dancer.seen" 03.47.50 Quit ^7heo (Disconnected by services) 03.48.23 Join ^7heo [0] (~7heo@p5792D818.dip0.t-ipconnect.de) 04.26.27 Quit tertu (Read error: Connection reset by peer) 04.26.52 Quit amiconn (Disconnected by services) 04.26.53 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.26.55 Quit pixelma (Disconnected by services) 04.26.55 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.26.58 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.26.58 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.28.05 Join tertu [0] (~tertu@65-128-138-136.mpls.qwest.net) 04.34.21 Join Strife89 [0] (~Strife89@adsl-98-80-215-52.mcn.bellsouth.net) 04.48.12 *** Saving seen data "./dancer.seen" 04.58.44 Quit Elfish (Ping timeout: 245 seconds) 05.09.17 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) 05.14.00 Quit TheSeven (Disconnected by services) 05.14.06 Quit Elfish (Ping timeout: 246 seconds) 05.14.14 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 05.17.19 Quit saratoga (Ping timeout: 272 seconds) 05.20.18 Join Elfish [0] (amba@84.201.30.174) 05.24.42 Quit Strife89 (Read error: Connection reset by peer) 05.25.22 Quit Elfish (Ping timeout: 252 seconds) 05.25.38 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) 05.26.16 Join Strife89 [0] (~Strife89@adsl-98-80-215-52.mcn.bellsouth.net) 05.30.22 Quit Elfish (Ping timeout: 246 seconds) 05.30.49 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) 06.01.51 Quit Elfish (Ping timeout: 240 seconds) 06.02.26 Quit Unhelpful (Quit: No Ping reply in 180 seconds.) 06.02.45 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 06.08.20 Join Elfish [0] (~amba@84.201.30.174) 06.46.05 Quit Strife89 (Quit: Vamoose.) 06.47.21 Quit cmhobbs (Read error: Operation timed out) 06.48.13 *** Saving seen data "./dancer.seen" 07.19.51 Join flatr0ze_ [0] (~flatr0ze@108-205-242-13.lightspeed.bcvloh.sbcglobal.net) 07.20.28 # Hello. Got a QQ: how come we can't use RSRC firmware for BCM2722 chip off the official Apple firmware for iPod Video with rockbox? If we figure out the API of that firmware, can't we just "pipe" the raw bits of mpeg4 files to that firmware, getting the picture out? 07.30.52 # <[Saint]> I don't believe anyone is stopping you from doing so. 07.34.37 # i would if i could be bothered :P 07.34.55 Nick man_in_s1ack is now known as man_in_sahck (~likeyouca@unaffiliated/man-in-shack/x-4279753) 07.34.57 Nick man_in_sahck is now known as man_in_shack (~likeyouca@unaffiliated/man-in-shack/x-4279753) 07.38.47 Join Gallomimia [0] (~gallomimi@99.199.8.77) 07.38.47 # <[Saint]> If one managed to reverse the firmware, though, there would be absolutely no point in running a shim to drive that firmware to drive the videocore chipset when you coild just poke the HW directly. 07.39.48 # <[Saint]> Its many hundreds of man hours for very little gain though, really. 07.51.03 # i prefer woman hours really 07.54.50 # FiiO X5: https://outpost.fr/Dnt → com.cn: FiiO 07.55.21 # nice mechanical wheel 07.58.54 # [7]: hey, what do we know aout the 5gnano? 08.08.56 # <[Saint]> http://www.freemyipod.org/wiki/Nano_5G 08.09.59 # <[Saint]> or "very little", apparently. 08.12.17 # <[Saint]> in the hw section there you can see the similarity between the nano3g and classic i mentioned in *-community 08.13.18 # <[Saint]> for some odd reason they're kinda expensive when you can find them though. 08.14.58 Join ender` [0] (krneki@foo.eternallybored.org) 08.23.34 # is 1 man hour == 1 woman hour? 08.32.11 # <[Saint]> the man in man hours refers to the kind, not the sex, so - yes. 08.45.31 # if shuffle is on, do repeat modes do anything? 08.48.17 *** No seen item changed, no save performed. 08.54.41 # i.e., if i have repeat = none and shuffle = on, will rockbox stop playing after all songs have played? 08.54.48 # or is the "next track" fully random? 09.13.35 # <[Saint]> repeat mode should win in that instance. 09.14.30 # <[Saint]> and playback is never fully random. 09.14.43 # <[Saint]> even when shuffled, but that's an aside. 09.15.16 # <[Saint]> true random shuffle is often undesirable. 09.16.36 # so if i have repeat = none and shuffle = on, no song will play twice, correct? 09.17.11 # <[Saint]> we have a psuedo-random shuffle. Each track is played exactly once and once only. The user can control the frequency of more desirable tracks/albums by increasing their frequency in the playlist. 09.17.15 # <[Saint]> and no. 09.17.26 # <[Saint]> no track will ever play twice. 09.17.39 # <[Saint]> unless it is in the playlist twice. or more. 09.17.45 # understood :) 09.18.42 # <[Saint]> (or the repeat mode == shuffle, which will play all tracks once in playlist order then reshuffle and restart the playlist) 09.19.16 # yes, i get that, but i was asking about repeat = non :) 09.20.41 # any themebuilders here use linux systems? 09.21.45 # <[Saint]> there's nothing linux-specific i could think of in reference to theme building. 09.21.53 Join Zagor [0] (~bjst@80.239.169.194) 09.22.17 Nick Zagor is now known as Guest71169 (~bjst@80.239.169.194) 09.22.45 # was just wondering what tool they use for making bmps 09.23.18 # because something's funky with my libs or something and the simulator doesn't display 1bit bmps 09.24.00 # also the files don't seem to have the correct headers. "$ file mybmp.bmp" says "data" instead of "Windows Bitmap image" or whatever 09.24.30 # <[Saint]> I use GIMP personally. 09.24.39 Quit Guest71169 (Changing host) 09.24.39 Join Guest71169 [242] (~bjst@rockbox/developer/Zagor) 09.24.56 # [Saint]: 32bit or 64bit? 09.25.02 Nick Guest71169 is now known as Zagor (~bjst@rockbox/developer/Zagor) 09.25.16 # <[Saint]> 64 09.25.36 # [Saint]: can you test to see what comes up when you do "file some-bmp-from-gimp.bmp"? 09.26.58 # <[Saint]> Ah. Not presently. I'm nowhere near anywhere I could do so presently sorry. 09.27.04 # no prob 09.28.12 # gonna try upgrading all the gimp libs i can 09.35.52 Quit Elfish (Ping timeout: 252 seconds) 09.36.10 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) 09.36.51 Quit tertu (Read error: Connection reset by peer) 09.37.17 Join tertu [0] (~tertu@65-128-138-136.mpls.qwest.net) 09.40.38 Quit Elfish (Ping timeout: 240 seconds) 09.40.44 Join Elfish_ [0] (amba@2001:1608:12:1:13:3:3:7) 09.41.10 Nick Elfish_ is now known as Elfish (amba@2001:1608:12:1:13:3:3:7) 09.41.47 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.42.33 # man_in_shack: BMP is a many-sided format, perhaps file fails to parse some variants? 09.45.42 Quit Elfish (Ping timeout: 246 seconds) 09.46.22 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) 09.46.23 # could be 09.47.53 # but it's weird 09.49.00 # just thought, libsdl probably has its own bmp parser 09.49.23 # probably 09.50.45 # my sim isn't displaying the play/pause icon due to this issue 09.51.55 # the built-in one 09.52.38 Quit Elfish (Ping timeout: 240 seconds) 09.58.43 Join Elfish [0] (amba@84.201.30.174) 10.20.10 Quit Elfish (Ping timeout: 252 seconds) 10.24.06 # man_in_shack: we don't use an external bmp parser 10.24.37 # except the player picture that is around the virtual screen in the sim where we just pass that bmp to SDL 10.25.21 Join SovonHalder [0] (~SovonHald@101.215.204.75) 10.25.43 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) 10.25.55 # man_in_shack: is there an error message? 10.34.10 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 10.35.23 # man_in_shack: there was a fix to support recent gimp BMPs recently, try updating to latest git master 10.36.06 Join rela [0] (~x@pdpc/supporter/active/rela) 10.45.31 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 10.46.30 # Hi..guys..happy New Year 10.48.15 # few minutes ago I plugged in my iPod C lassic 6G 160G into my PC..I received an weird message in a white background whice said like the usb is aborted or something 10.48.18 *** Saving seen data "./dancer.seen" 10.48.54 # I had to hold menu+pause button to restart my iPod 10.49.00 # because it went frozen 10.50.12 # then after transferring a few songs when i disconnected the USB properly, i received an error saying something like *panic* 10.50.13 # playlist_rsume() : 00M 10.51.09 # I didn't write down the whole copy of the error that time..but again I plugged in my iPod to check if the ipod faces similar issues 10.51.25 # it didn't get an error while plugging in like it did the previous time 10.51.56 # but when I disconnected the iPod, I kinda got the same error & this time I noted down the whole error which is exactly this.. 10.52.02 # Ship of Theseus 10.52.06 # #TPS key: d00ri5lock3d! 10.52.06 # *panic* 10.52.06 # playlist_rsume() : 00M 10.52.06 DBUG Enqueued KICK SovonHalder 10.52.06 # pc : 08010938 sp : 000096FC 10.52.06 # A : 0803DCF4 10.52.06 *** Alert Mode level 1 10.52.06 # A : 0800B3EC 10.52.06 *** Alert Mode level 2 10.52.06 # A : 0800B5B8 10.52.07 *** Alert Mode level 3 10.52.07 # A : 0800557C 10.52.07 *** Alert Mode level 4 10.52.07 # bt end 10.52.48 # --------- sorry..please ignore Ship of Theseus 10.52.57 # #TPS key: d00ri5lock3d!...the error message was the rest of it..PLEASE help.. 10.55.06 Quit tertu (Ping timeout: 260 seconds) 10.55.41 # SovonHalder: what build are you running? 10.55.57 # you can tell by looking at /.rockbox/rockbox-info.txt 10.57.15 # from system>rockbox info I just loked at it..it's 8566cd7-131224 11.00.28 # please help. I need to know what caused the problem..I have been using RockBox for about a year now.but never saw something like this 11.02.08 *** Alert Mode OFF 11.04.16 Quit Elfish (Ping timeout: 246 seconds) 11.04.32 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) 11.09.08 Quit Elfish (Ping timeout: 245 seconds) 11.09.29 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) 11.14.25 Quit Elfish (Ping timeout: 246 seconds) 11.14.31 # kugel: no error, and compiling gimp is a long way to go ... :P 11.14.54 # man_in_shack: i meant rockbox git master 11.15.10 # ah 11.16.42 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 11.16.58 # please help 11.18.28 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) 11.19.08 # kugel: what's weird is it works if the bmp is saved in greyscale 11.19.19 # but not if it's saved in 1bpp 11.19.28 # SovonHalder: I'l looking at it 11.19.36 # kugel: You knew this probably, but according to my tests with buflib cookie integrity checks buflib doesn't leak memory by itself nor current 'clients' corrupt buflib state. 11.20.06 # nice 11.20.28 # kugel: thank you, Sir. 11.20.49 # gevaerts: is there a possibility that usb_storage_disconnect() is not properly called? 11.21.24 # I've just made a post for this in the rockbox forums: http://forums.rockbox.org/index.php/topic,45688.0.html 11.22.31 # my ISP is very unstable at this time. If I accidentially go offline & remain that way, Please post in the forums if you have something to suggest me. 11.23.07 # the chan is logged. 11.25.27 Quit Elfish (Ping timeout: 246 seconds) 11.25.30 # Oh..that's awesome. but I'm tensed ..that's all 11.25.46 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) 11.26.08 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 11.26.08 # * man_in_shack gives SovonHalder a beer 11.27.38 # :D 11.29.04 # I admit I am a total tech n00b..so i have a question..Can I please know HOW serious is this issue of mine? 11.32.17 # you should first learn how to be patient. kugel told you he's looking at it, that may take more than a few seconds ;) 11.32.55 # kugel: What do you think about integrating buflib state integrity check? The cost is not that high: 1) +1 buflib_data in cookie to store crc 2) crc calc of first 3 buflib_data elements in cookie on alloc and shrink 4) check of crc in block_move() to assure integrity. crc routine is already present in core. 11.33.54 # perhaps in DEBUG builds? 11.34.56 # but yea, cost is pretty minor, seems like a good idea 11.36.17 # low enough to enable it for all builds I'd say 11.36.48 # kugel: I'll clean it up a bit and push it to gerrit 11.42.19 # for DEBUG builds we might want to consider crc check in buflib_get_data() 11.43.34 # kugel: I thought about checking whole buflib state on context switch in DEBUG (just as we check for stack ovl) 11.43.52 # I couldn't get it to work for sdl threads though 11.44.45 # so i'm just installing wine now and i'm going to see if irfanview can do bmps that don't splode 11.45.06 # man_in_shack: have you checked latest rockbox git master? 11.45.21 # told you there was a fix for gimp bmps recently 11.50.04 # yeah, but i want to keep my sansa on stable releases 11.50.49 # Then wait for 3.14, it should come out soon 11.51.10 # define "soon" 11.51.13 # (: 11.52.05 # soon as when we do the release :-) 11.52.13 # that's what i thought 11.52.47 # I don't know if the delay is due to a lack of time or lack of motivation 11.52.58 # but hopefully it gets released in January :) 11.53.25 # maybe it's a lack of lacks 11.54.04 # lebellium: clearly the latter 11.54.37 # oh well, as the project as a whole is concerned, I don't know about the personal situations of the release managers 11.58.06 # lebellium: Did you stress rockbox with your evil themes after backdrop fix? 12.00.43 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.01.30 # kugel: same issue with the built-in play icon in git master 12.03.31 # put the icon somewhere so I can take a look at the header please 12.04.02 Join einhirn [0] (Miranda@bsod.vpn.tu-clausthal.de) 12.05.21 # one sec 12.08.19 # wodz: I did not spend much time on it, but during my few tries USB was working properly on Clip Zip. However I don't really understand what has changed since it still displays my theme backdrop during USB connection 12.08.19 # where would i find the image for the built-in play/pause icons? 12.09.21 # JdGordon: ^ 12.10.23 # lebellium: Is it reproducible in simulator as well? 12.10.35 # hum 12.10.37 # let me check 12.12.14 # is there any particular version of rockbox for iPod Classic daily builds that is recommended & reported by users to be stable & having least bugs ? 12.13.36 # we should really try better than just unloading all skins 12.14.06 # kugel: well, usb connect is rare event 12.14.09 # the only reason we do it currently is because the font engine keeps the files open 12.14.30 # kugel: where do i find the built-in icons in the source? 12.14.48 # wodz: for some it isnt that rare, plus it really looks like something is wrong (even if intended) 12.15.46 # wodz: yes it's reproducible in the sim 12.16.03 # kugel: we should get usb screen skinnable, handle it theme and problem fixed :-) 12.16.26 # the problem that fonts have to be closed remains 12.16.33 # uisimulator/common/player_icons? 12.16.36 # there is no difference with before: the USB screen still loads my SBS (status bar and backdrop). 12.18.16 # * man_in_shack sighs 12.19.07 # lebellium: this is clearly not what the code intends 12.21.16 # wodz: I dont think we need a separate usb skin, it's not at all interactive. perhaps just a way to specify a different usb icon 12.21.48 # in the meantime we should just show the base skin with list replaced by the usb icon (cropeed if necessary) 12.22.44 # kugel: I thought the code fix was to unload the theme during USB connection? 12.23.12 # <[Saint]> oh, yay, lebellium dusted off this old chestnut. 12.23.35 # lebellium: no, it should be doing this for longer. the recent fix was to also really unload the backdrops of the themes 12.23.45 # ok 12.23.52 # (it did unload the backdrop but did not free the buffer for it) 12.23.52 # so actually it does nothing 12.23.56 # nothing works :) 12.24.14 # it loads my full SBS including backdrop 12.25.03 # <[Saint]> I recall he and I discussing that reality didn't match what the code intended and the sbs remained, sometimes somewhat butchered, in the USB screen. 12.25.28 # kugel: with skinned usb screen simple animation would be possible for example 12.26.03 # <[Saint]> I think back then we may have dismissed it as us pushing the skin engine to do weird things. 12.26.26 # wodz: right. anyway it won't fix the root cause :) 12.27.55 # <[Saint]> something handy about that might be properly handling a "safe to eject" mesage. 12.28.13 # <[Saint]> But I'm not how how reliably that can be detected. 12.29.25 # <[Saint]> (or any method to detect this at all, presently? I forget) 12.30.57 # I'd expect it to be some special ums packet to signal the storage that host finished operation and synced buffer 12.31.04 # <[Saint]> I understand a complete lack of "its ok to unplug me now" may be disconcerting to some people. 12.32.02 # but I don't know ums much 12.33.40 # safe eject doesn't exist in UMS 12.33.57 # it's only an OS thing about flushing the caches 12.34.04 # I think there is indeed a SCSI command that is usually used to indicate that the host is done with it 12.34.14 # START/STOP_UNIT if I remember correctly 12.34.54 # I think we already implemented something like this? 12.35.17 # were you could press a button to transition to charging only once you unmounted on the host 12.35.38 # (it didnt work properly on some OSs) 12.35.42 # I don't remember seeing support for it in rockbox, if needed at all 12.36.34 # I'm not sure hosts actually send this command at all, or at a useful time 12.37.29 # one would need a try to be sure 12.37.45 # I think it is sent on "safe removal" on the host 12.38.11 # usb_storage.c handles it but only sets a flag internalyl 12.38.28 # it's actually more complex than just start/stop, the host can specify the power condition: active, idle or handle per logical unit 12.39.40 Join JdGord [0] (~AndChat69@pa49-184-96-97.pa.vic.optusnet.com.au) 12.40.17 # but what do you want to use it for exactly ? 12.41.37 # I think if the device introduce itself as auto-removable then host sends this sequence to inform device it is ready. It is common practice in usb sticks to do so. 12.42.23 # If thats is the case the device disappears after 'safe remove'/eject 12.43.22 # <[Saint]> if at all possible, some visible indication of this state to the user would be nice. 12.43.55 # <[Saint]> non-essential, the last decade says so, bit nice. 12.44.05 # <[Saint]> *but 12.44.18 # http://www.keil.com/forum/19700/ 12.47.57 Quit JdGord (Quit: Bye) 12.48.17 # <[Saint]> wow. some USB stuff I understood. 12.48.18 Join Hanheni [0] (56c06386@gateway/web/freenode/ip.86.192.99.134) 12.48.21 *** Saving seen data "./dancer.seen" 12.48.34 # [Saint]: it's SCSI stuff actually ;) 12.49.07 Nick SuperBrainAK is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) 12.49.10 # Hi' there 12.50.59 Quit Hanheni (Client Quit) 12.52.11 # * [Saint] waves 12.57.21 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 12.58.10 Quit SovonHalder () 13.02.55 Join dfkt [0] (dfkt@unaffiliated/dfkt) 13.05.29 # so i've just about finished wps 13.05.48 # but i'm a little confused about what sbs is 13.06.34 # sbs = menus 13.06.40 # fms = FM radio 13.06.48 # most probably because sbs is a bit confusing :-) 13.06.55 # sbs is not confusing! 13.07.08 # sbs is abbreviation for skinnable status bar 13.07.18 # ah ok 13.07.37 # the twist is that it doesn't have to be status bar per se 13.07.49 # I didn't know that wodz, thanks, and I made more than 10 themes without knowing it. So it's not confusing :P 13.07.56 # fun 13.09.29 # lebellium: Maybe it is confusing for me because I know what it was before. You know, you can do something if you don't know it is impossible :-) 13.09.52 # the docs aren't really clear on how to design sbs 13.10.01 # what is "info viewport" exactly? 13.10.45 # man_in_shack: just look at a theme with SBS, it's easier to understand. Mines have. But there are complex themes^^ 13.10.50 # they* 13.11.37 # info viewport is where the menu lists display 13.12.09 Quit Scall (Quit: Bye bye) 13.12.10 # ok 13.13.36 # <[Saint]> status bar skin, fwiw, iirc. 13.15.12 # <[Saint]> either that, or skinnable base screen. 13.15.24 # <[Saint]> i forget. that was some time ago now. 13.15.51 # <[Saint]> i think the latter. 13.16.14 # soft boobie skin 13.16.26 # <[Saint]> as its more obvious then that a status bar needn't necessarily be involved. 13.17.33 # right 13.20.28 # gevaerts: You volunteered to implement volume limiter - could you review g#697 ? 13.20.29 # 3Gerrit review #697 at http://gerrit.rockbox.org/r/697 : 3 by PurlingNayuki (changes/97/697/8) 13.22.10 # I think I found one of the worst workaround ever in Freescale SDK 13.23.23 # don't be shy - share the finding 13.23.32 # Partition offset in MBR are incremented by 4 except if the underlying media is MMC or if the chip uses ROM revision >TA4 13.23.56 # and only for some partition kinds 13.24.11 # why it is so? 13.25.05 Join Scall [0] (~chat@unaffiliated/scall) 13.25.18 # given the code, I think they introduced a difference between MMC and SD by mistake in some ROM because of code duplication, so then they introduced a software workaround and finally fixed it in some later ROM ? 13.25.36 # pamaury: have you seen g#703 ? 13.25.38 # 3Gerrit review #703 at http://gerrit.rockbox.org/r/703 : 3 by Andrew Ryabinin (changes/03/703/1) 13.26.08 Quit ikeboy (Quit: ikeboy) 13.26.11 # no, thanks, I'll check that 13.28.07 Join lorenzo92 [0] (~chatzilla@host27-157-dynamic.24-79-r.retail.telecomitalia.it) 13.28.17 Quit lorenzo92 (Client Quit) 13.28.37 Join lorenzo92 [0] (~chatzilla@host27-157-dynamic.24-79-r.retail.telecomitalia.it) 13.31.31 # <[Saint]> i guess i should comment on gerrit, but: 13.31.52 # wodz: ok I see, the hifietma8 uses the id 85 but it should have introduced a name in scramble in the first place ! 13.32.17 # <[Saint]> that volume limiter looks like it silently breaks the users expectation of the current volume displayed. 13.32.44 # [Saint]: why? 13.33.37 # <[Saint]> the volume level displayed is going to be normal, when the volume is really capped. 13.34.21 # [Saint]: no, it is not AFAIK. There is other problem however 13.34.26 # <[Saint]> mind you...precut does that now already. 13.35.08 # Build Server message: 3New build round started. Revision 9dbdec1, 243 builds, 32 clients. 13.35.51 # <[Saint]> a quick look from a slightly drunk me and it seems like it will let the user set a volume (and skins display that value) but silently cap it at a set value. 13.36.25 # <[Saint]> if I'm wrong, apologies. 13.36.53 # kugel: ping 13.37.18 # lorenzo92: pong 13.37.18 # [Saint]: Ah, now I see. You are right 13.37.47 # I thought it modifies original passed value as well but it does not 13.37.48 # <[Saint]> Something I dislike very much about precut. 13.37.50 # kugel: did you have a look at my patch? 13.37.53 # Build Server message: 3Build round completed after 165 seconds. 13.38.07 # <[Saint]> Thats on my "get round to it eventually" list too. 13.38.16 # lorenzo92: not yet 13.41.30 # <[Saint]> I believe gevaerts had some idea for a way to implement volume limiting that worked nicely. Or maybe he had the idea that he might have an idea in the future if no one else did. :) 13.41.40 # wodz: I feel stupid now, I pushed the patch but it is wrong: 92 is also used by ihifi760 13.42.11 # that's enough proof to me that the rk27 targets should be placed in the list or don't bother with modelnum conflicts, otherwise a mistake is easily made 13.42.25 # <[Saint]> next up: triple digit build identifiers. :) 13.43.00 # by the way, who actually uses this target id? the bootloader? perhaps rb util? 13.44.45 # ihifi760 has no wiki pages, has it? There is no information about that target and how to install rockbox to it. That's a pity. 13.45.57 # <[Saint]> wodz: I'll make my opinion known on gerrit some time tomorrow. 13.46.24 # <[Saint]> I have had degreasing amounts of time for Rockbox stuff lately. 13.47.13 # lorenzo92: bootloader/rolo for checksum'ing 13.47.16 # <[Saint]> The time I do get is usually spent on the forums these days. I haven't looked over gerrit in a while. 13.47.19 # lebellium: I think pamaury and wodz are a bit lazy with keeping the wiki up to date 13.47.36 # <[Saint]> Which is a shame as theres a lot of good stuff on there. 13.47.46 # there is no problem with pamaury. All Creative and Sony targets have a wiki page 13.48.07 # kugel: that's lebellium's job, isn't it? :P 13.48.17 # I failed to find information about Sony's few weeks ago 13.48.28 # kugel: audiophile daps are not my field of interest :-) 13.48.28 # kugel: like ? 13.48.34 # <[Saint]> I think the problem is zero obligation to update the wiki. 13.48.58 # kugel: It is mortalis work 13.49.02 # I try to keep the wiki up to date but if I missed something I'll be pleased to add it 13.49.05 # Saint: haha I agree. 13.49.50 Quit Scall (Quit: Bye bye) 13.50.00 # pamaury: it looks like i failed 13.50.14 # AFAIK the ihifi760 is the only recent target with absolutely no information about it. I thought it was commonly admited that every target should have a wiki page, even if that pages countains 2 lines or is outdated. What's the point of having a ihifi760 Rockbox build if we don't even know how to install the bootloader... 13.50.52 # <[Saint]> we may not necessarily want it known. 13.51.02 # all my targets have a at least one page: the description page 13.51.04 # <[Saint]> early development, brick risk, etc. 13.51.14 # and if there is code in the repo, then there is a second page for the Port 13.51.29 # <[Saint]> there are times when it may not be prudent to publish all info, i mean. 13.51.30 # yes, your wiki pages are really well documented pamaury, very helpful 13.51.32 # I admit I fail to update TargetStatus and some other pages at time 13.52.36 # [Saint]: sure but is that the reason in the particular ihifi case? I'm not sure. I just think mortalis forgot it/doesn't care/is lazy :) 13.53.27 # <[Saint]> Oh. I have no idea. Just speculating on reasons why we may have execution on a device without any wiki documentation. 13.53.44 # pamaury: sorry then 13.55.23 # no problem :) 13.56.33 # even if we don't publish install instructions immediately (early developement, brick risk etc as you said), there should be a wiki page with basic hardware information at least. Commiting rockbox code for a new target with 0 information about it sounds really strange to me 13.57.07 # absolutely, even if code has to be a source of information 13.58.56 # <[Saint]> well...I guess at some point the "its a wiki" argument has to come up. 13.59.47 # <[Saint]> If you're crap at writing docs, leave it for someone who cares enough for them to be there. Community project and all. 14.00.19 # Maybe it's very similar to another target? 14.01.19 # "it's a wiki, do it yourself if you're not happy" is not a valid argument either in that case. I don't know the Ihifi760 and I'm not a dev. I can update the status summary pages and typos but the guy who writes or commit the rockbox code for a new target should write the wiki page first. Then other people may edit and improve the page if needed 14.01.24 # <[Saint]> Give it to the RSB for something for them to do. "Agenda: New targets to include basic wiki documentation?". 14.01.37 # <[Saint]> They'll be happy for something to do. 14.01.47 # * [Saint] bets not really 14.02.15 # wiki doc is up to the maintainer, at least for a start because he is the one who knows 14.03.06 # <[Saint]> right. but its more an unwritten rule. than a rule rule. 14.03.32 # I expect any usual Rockbox dev to know the unwritten rules 14.04.10 # mortalis is not an unknown newbie. 14.04.56 # <[Saint]> right. but what I'm saying is, known or not, it isn't enforced. at all. 14.17.28 Join 36DAB2461 [0] (srraven@fatfecker.shagged.org) 14.19.43 Nick 36DAB2461 is now known as SrRaven (srraven@fatfecker.shagged.org) 14.20.39 Quit dfkt (Remote host closed the connection) 14.21.52 # lebellium: err... yeah, the USB screen really is fcucked 14.22.04 # it looks like depending on the user font it will actually reenable the sbs 14.22.16 # usb_screen.c line 157 14.22.44 # and no, user fonts arent a blocker for usb skinning 14.23.15 # * JdGordon heads to bed 14.30.11 # are viewports not allowed to overlap at all? 14.36.31 Join cmhobbs [0] (~cmhobbs@ip70-178-52-92.ks.ks.cox.net) 14.36.31 Quit cmhobbs (Changing host) 14.36.31 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 14.39.56 Join liar [0] (~liar@93-82-119-173.adsl.highway.telekom.at) 14.41.22 Nick liar is now known as krnlyng_ (~liar@93-82-119-173.adsl.highway.telekom.at) 14.41.38 # are viewports not allowed to overlap at all? 14.41.41 # oops, sorry 14.43.46 Quit krnlyng (Ping timeout: 260 seconds) 14.48.25 *** Saving seen data "./dancer.seen" 14.48.53 Nick krnlyng_ is now known as krnlyng (~liar@93-82-119-173.adsl.highway.telekom.at) 14.51.07 # <[Saint]> they are. but fun things can happen. 14.52.39 # <[Saint]> it is bad practice to do so, generally speaking. 14.54.43 Join clare [0] (55451d4a@gateway/web/freenode/ip.85.69.29.74) 14.54.54 Quit clare (Client Quit) 14.56.12 # ah, i found the problem 14.56.28 # i had two %xls with the same id 15.00.59 # <[Saint]> there's no concept of layers in skins past backdrop and foreground. you *can* layer viewports, and they are drawn in parsed order, but to guarantee the draw order the content must be static. 15.01.26 # <[Saint]> it cant have any dynamic content without being brought to the "front". 15.01.44 Join Scall [0] (~chat@unaffiliated/scall) 15.01.53 # yup 15.02.00 # <[Saint]> which makes for some hideous artifacts. 15.02.20 # <[Saint]> and/or unexpected behaviour. 15.02.50 Quit cmhobbs (Read error: Operation timed out) 15.03.03 # <[Saint]> which is why its better to swap out conditionally than rely on drawing on top of other elements. 15.03.09 # yes 15.03.14 # all understood now 15.18.49 Quit kugel (Ping timeout: 252 seconds) 15.28.23 # is it possible to position text at different points depending on conditions? 15.47.23 Quit wodz (Read error: Connection reset by peer) 15.48.33 Join tyllmoritz [0] (~robin@p54814CEE.dip0.t-ipconnect.de) 15.58.10 Quit Cultist (Ping timeout: 272 seconds) 16.04.01 Join Narod [0] (~Narod@p5DDDB2AF.dip0.t-ipconnect.de) 16.06.12 Join Mir_ [0] (~Mir@pool-71-109-219-225.lsanca.dsl-w.verizon.net) 16.07.24 Quit Mir (Ping timeout: 252 seconds) 16.08.41 # "Position text"? Not sure exactly what that means... Text is drawn (to my understanding) inside viewports. Its position inside a viewport is limited to things like left/center/right... you can do that conditionally... now, if you mean "position viewports" at different points depending on conditions, I think a given viewport has fixed coordinates, but you can display different viewports conditionally, or conditionally set the fixed coordinates.... wha 16.09.35 Join tertu [0] (~tertu@65-128-138-136.mpls.qwest.net) 16.11.47 Quit rela (Read error: Connection reset by peer) 16.20.29 Quit tyllmoritz (Ping timeout: 265 seconds) 16.23.19 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 16.28.25 Quit SrRaven (Ping timeout: 248 seconds) 16.29.49 Quit flatr0ze_ (Ping timeout: 240 seconds) 16.30.56 Join Cultist [0] (~CultOfThe@2601:d:9280:fc:8634:97ff:fe17:5dc3) 16.31.19 # i've worked out how to do what i want :) 16.32.18 Join SrRaven [0] (srraven@fatfecker.shagged.org) 16.32.38 # <[7]> JdGordon: we don't know much about this thing, as we haven't been able to run any code on it or dump anything from it 16.33.00 # just needed more clever use of viewports is all 16.34.07 # so i've now got battery and volume displaying in both text and graphics depending on setting :) 16.34.17 # because i'm awesome like that :D 16.34.50 # <[7]> JdGordon: there might be some new attack vectors these days (to be cherrypicked from some iphone jailbreaks) 16.35.14 # <[7]> however nobody has bothered to even really look into it, the only really common ipod seems to be the classic these days 16.46.59 # when preparing a theme for upload, is it acceptable to assume that the standard fonts package is installed? 16.48.26 *** Saving seen data "./dancer.seen" 16.51.38 Quit krnlyng (Ping timeout: 260 seconds) 16.58.01 Quit linuxguy3 (Ping timeout: 245 seconds) 17.00.52 Quit ldyblink (Ping timeout: 240 seconds) 17.01.11 Quit Zagor (Quit: Clint excited) 17.01.15 Join ladyblink [0] (bassgeisha@selectah.drop.that.bass.aikyou.bassgeisha.com) 17.06.29 Join krnlyng [0] (~krnlyng@83.175.90.24) 17.07.26 Join linuxguy3 [0] (~timj@24-148-61-208.c3-0.lem-ubr1.chi-lem.il.cable.rcn.com) 17.20.23 # It's more than acceptable to assume the standard fonts - if you try to include one of them with your theme, the upload validation will reject it and complain about that. 17.22.15 # yay 17.22.51 # but it's not acceptable to assume users installed the *extra* font pack 17.23.06 # you have to say what font your theme needs, in the theme description 17.25.58 # or just say that the font pack is needed 17.26.09 # right 17.26.29 # i mean the thing in rockbox utility that says "additional fonts" 17.40.50 # I think those are the ones that are in http://download.rockbox.org/release/3.13/rockbox-fonts-3.13.zip which are the ones that the validation won't let you include with a theme. I agree it is a nice thing to include in your description "requires font pack" or "requires xxx.fnt". But, it isn't possible to actually just bundle one of these with your theme - so, de facto, it is sort of assumed... 17.41.56 # I've discovered that all the fonts I _like_ aren't in there, anyway, so I just bundle them... 17.44.54 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 17.48.38 Quit einhirn (Read error: Connection reset by peer) 17.59.35 Quit ikeboy (Quit: ikeboy) 18.24.02 Quit lorenzo92 (Ping timeout: 260 seconds) 18.27.28 Join pretty_function [0] (~sigBART@123.252.214.140) 18.46.09 Quit Narod (Remote host closed the connection) 18.46.10 Join Narod- [0] (~Narod@p5DDDB2AF.dip0.t-ipconnect.de) 18.48.21 Join lorenzo92 [0] (~chatzilla@host27-157-dynamic.24-79-r.retail.telecomitalia.it) 18.48.28 *** Saving seen data "./dancer.seen" 18.48.54 Quit lorenzo92 (Client Quit) 19.03.53 Nick Mir_ is now known as Mir (~Mir@pool-71-109-219-225.lsanca.dsl-w.verizon.net) 19.30.13 Quit pretty_function (Remote host closed the connection) 19.39.37 Quit tertu (Ping timeout: 265 seconds) 19.39.53 Join ter2 [0] (~tertu@65-128-138-136.mpls.qwest.net) 19.43.57 Quit ter2 (Ping timeout: 240 seconds) 19.58.41 Join krabador [0] (~krabador@unaffiliated/krabador) 19.59.35 Quit DormantBrain (*.net *.split) 19.59.37 Quit APLU (*.net *.split) 20.05.22 Join DormantBrain [0] (~andy@2001:470:8:a61::5f92:59a1) 20.05.22 Join APLU [0] (~mulx@2a01:e34:ee29:12b0::10) 20.13.26 Join saratoga [0] (47e22765@gateway/web/freenode/ip.71.226.39.101) 20.17.51 Join Ezhara [0] (d5bf0841@gateway/web/freenode/ip.213.191.8.65) 20.44.39 Quit Ezhara (Quit: Page closed) 20.48.31 *** Saving seen data "./dancer.seen" 20.48.56 Join kugel [0] (~kugel@91-64-116-250-dynip.superkabel.de) 20.48.56 Quit kugel (Changing host) 20.48.56 Join kugel [0] (~kugel@rockbox/developer/kugel) 20.48.59 Quit y4n (Quit: Assumption is the mother of all fuckups) 20.57.31 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 21.15.05 Join rela [0] (~x@pdpc/supporter/active/rela) 21.32.53 Quit [Saint] (Remote host closed the connection) 21.35.11 Join [Saint] [0] (~saint@rockbox/staff/saint) 21.41.48 Quit ikeboy (Quit: ikeboy) 21.57.14 Quit krabador (Ping timeout: 260 seconds) 21.58.36 Join krabador [0] (~krabador@unaffiliated/krabador) 22.03.49 Quit soap (Ping timeout: 260 seconds) 22.16.21 Join soap [0] (~soap@rockbox/staff/soap) 22.27.02 Quit fs-bluebot (Ping timeout: 272 seconds) 22.28.44 Join fs-bluebot [0] (~fs-bluebo@f053154056.adsl.alicedsl.de) 22.32.13 Quit krabador (Ping timeout: 260 seconds) 22.33.03 Quit fs-bluebot (Ping timeout: 240 seconds) 22.41.04 Join fs-bluebot [0] (~fs-bluebo@f053154056.adsl.alicedsl.de) 22.48.34 *** Saving seen data "./dancer.seen" 22.50.02 Join krabador [0] (~krabador@unaffiliated/krabador) 22.52.13 Quit krabador (Max SendQ exceeded) 22.54.25 Join krabador [0] (~krabador@unaffiliated/krabador) 22.55.50 Quit krabador (Max SendQ exceeded) 22.59.25 Nick DormantBrain is now known as SuperBrainAK (~andy@2001:470:8:a61::5f92:59a1) 23.12.30 # in an ASM block, i know that gcc can stack registers that are already in use automatically 23.12.45 # does this also apply to special registers like the link register or do I have to manually stack those? 23.13.16 # I... don't know, actually. 23.13.25 # Try it and find out. 23.14.01 # (for example gcc does this correctly for %rbx on x86-64, but not %ebx on x86-32) 23.15.44 # saratoga: I could say "look at the doc", but that would be a joke actually ;) 23.15.56 # already testing it 23.18.50 # I mean, I would hope that gcc stacks lr already if it stacks anything at all. 23.19.08 # indeed it does 23.20.00 # interestingly pop(r4,....); bx lr becomes pop {r4,..., pc} 23.20.02 # without hte bx 23.20.15 # but i guess popping the LR to the PC does the same thing 23.20.50 # Right, that is why I was hoping it would always stack lr. 23.20.59 # next question: if list the stack pointer as a clobber, does it store the stack pointer or just trash the stack? 23.21.04 # It gets you a free return from the stack restore. 23.21.06 # gcc of course stacks everything as required by the calling convention 23.21.58 # saratoga: Uh... that sounds like it almost certainly wouldn't do what you want. 23.22.09 # unless you make the function naked as well 23.22.13 # Where can it store the stack pointer? 23.23.09 # derf: couldn't it store the stack pointer as a constant at the end of the asm block? 23.23.22 # As a constant?! 23.23.23 # yea, only option would be a pc-relative location 23.23.39 # we do that in various asm functions 23.23.45 Quit PurlingNayuki (Ping timeout: 272 seconds) 23.24.00 # Well, that may work okay for Rockbox, but it means your code is not re-entrant. 23.24.00 # although the pc relative thing might be a problem 23.24.21 # Which is kind of a problem in lots of other contexts. 23.24.27 # you mean from a context switch? 23.24.29 # Certainly not something I'd expect gcc to do automatically. 23.24.43 # Yes... two threads calling the same function. 23.24.52 # hmm good point 23.25.03 # re-purposing sp is generally a bad idea 23.25.21 # on hosted platforms it can also conflict with signal handling 23.25.27 # so is only having 14 general purpose registers not counting SP 23.25.28 # Yeah. 23.25.35 # and on others with interrupts 23.26.07 # i once fixed rockbox code to not re-use sp to make it work on hosted 23.26.22 # I was assuming by "clobber" you meant you were adding more things to the stack yourself. Changing to be not a stack pointer entirely is a bad idea. 23.26.24 # yeah i know libmad does that 23.26.36 # not anymore i think :) 23.27.00 Join PurlingNayuki [0] (uid20107@gateway/web/irccloud.com/x-oigkhvqpzfubcdkr) 23.27.03 # well knowing i can use the LR is nice, i had always assumed i couldn't 23.27.16 # in an asm() call anyway 23.28.06 # i'll add this to the wiki 23.28.43 # re-using LR can also be problematic in some sitations, but not as problematic as with sp 23.30.17 # anything i should keep in mind? 23.30.45 # imagine a IRQ/signal handler wants to examine the call stack of a normal thread, and it occured during such an asm block 23.31.24 # Nah, this is normal for ARM. 23.31.39 # I think there are some hints you can provide to tell it about stack unwinding. 23.31.55 # But honestly I've never looked into it. 23.31.56 # saratoga: just dont use sp 23.32.05 Join sakax [0] (~sakax@unaffiliated/sakax) 23.32.12 # you'd only ever do that if theres a data abort or prefetch error right? 23.32.12 # ok 23.32.24 # right 23.32.34 # Well, we use this for profiling on B2G, for example. 23.33.09 # (using libunwind) 23.33.20 # but you can also travel the call stack by only looking at the stack iiuc so it's a non-issue probably 23.33.28 # Right. 23.34.37 # might interfere with __builtin_return_address(0) ? 23.38.00 Quit soap (Ping timeout: 264 seconds) 23.38.49 Quit kugel (Ping timeout: 246 seconds)