--- Log for 14.01.114 Server: adams.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 16 days and 7 hours ago 00.14.05 Quit funman (Changing host) 00.14.05 Join funman [0] (~fun@rockbox/developer/funman) 00.39.46 Quit Rower (Quit: Hmmm...) 00.46.58 Quit ender` (Quit: Little expense had been spared to create the impression that no expense had been spared.) 00.51.34 Join Strife1989 [0] (~Strife89@adsl-98-80-207-168.mcn.bellsouth.net) 00.51.48 Nick Strife1989 is now known as Strife89 (~Strife89@adsl-98-80-207-168.mcn.bellsouth.net) 00.53.53 *** Saving seen data "./dancer.seen" 00.54.15 Quit pamaury (Ping timeout: 246 seconds) 00.59.14 # Build Server message: 3New build round started. Revision a43cce2, 249 builds, 32 clients. 01.03.40 # Build Server message: 3Build round completed after 266 seconds. 01.04.12 Part b0hoon ("GTG. Bye.") 01.14.33 Quit chrisjj (Quit: Page closed) 01.17.05 Join chrisjj [0] (561bb732@gateway/web/freenode/ip.86.27.183.50) 01.20.56 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 27.0/20140109165205]) 01.24.06 # kugel: at http://www.rockbox.org/tracker/task/12930 you wrote "however the manual is still wrong indeed." Could you clarify? 01.48.35 # %pv returns "-73" 1 step up from the bottom, but the bottom returns "?-74" where "?" is non-printing but affects the substring offset... (clip zip)... huh? 01.49.15 # so, %ss(1,2,%pv) returns "73" for -73, but one down from that returns "-7". 01.49.18 # huh? 01.49.34 # what is the non-printing character at the beginning when it is all the way down? 01.50.15 # I know there is some kind of 'muted' conditional -but what is going on with the leading character? 01.51.42 # NEVER MIND - I see what I did here... 02.07.48 Quit Topy44 (Ping timeout: 252 seconds) 02.11.40 Join Topy44 [0] (~Topy44@93.190.93.215) 02.12.17 Nick DormantBrain is now known as SuperBrainAK (~andy@2001:470:8:a61::5f92:59a1) 02.34.06 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) 02.53.57 *** Saving seen data "./dancer.seen" 03.21.10 Join amayer [0] (~amayer@72.25.60.215) 03.29.40 Quit gevaerts (Ping timeout: 245 seconds) 03.30.05 Quit evilnick (Ping timeout: 245 seconds) 03.59.21 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 04.00.59 Join pedro_angelo [0] (~pedro_ang@187-15-190-138.user.veloxzone.com.br) 04.02.45 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 04.03.59 Join Rask [0] (~rask@97-124-250-130.hlrn.qwest.net) 04.09.05 # Hi all. I'm wondering - can Rockbox on a Sansa Fuze be set to pretend to be an iPod over USB? That is, for purposes of connecting to a system that has iPod integration over USB. 04.09.56 # Rask: no feature like that has been implemented yet 04.10.15 # Hmm.. 04.11.09 # Does such a feature even exist, to your knowledge? My car has a USB port, but its method of dealing with a straight-up USB mass storage device is a bit braindead, and I've heard it's better if you use an iPod... but it has a USB port, not a dock connector, so I'm wondering if the iPod enumerates as a different type of device over USB that might account for different behavior. 04.12.34 # Rask: im sure it could be done if your willing to put in the wrench time 04.13.13 # i know we support some versions of IAP (ipod accessory protocal) 04.13.28 # i dont know if any of the more recent versions are supported 04.14.47 # Hmm, it looks like IAP goes over a standard RS232-like connection rather than USB. 04.15.05 # *shrugs* over my head 04.16.21 # Mmm. 04.16.23 # Ok, thanks anyhoo. 04.16.27 Part Rask 04.16.46 Quit amayer (Quit: Leaving) 04.33.52 Quit [Saint] (Remote host closed the connection) 04.35.08 Join [Saint] [0] (~saint@rockbox/staff/saint) 04.47.24 Quit pedro_angelo (Remote host closed the connection) 04.48.26 Join pedro_angelo [0] (~pedro_ang@187-15-190-138.user.veloxzone.com.br) 04.49.54 Quit pedro_angelo (Read error: Connection reset by peer) 04.54.01 *** Saving seen data "./dancer.seen" 04.55.44 Quit pixelma (Disconnected by services) 04.55.45 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.55.47 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.55.47 Quit amiconn (Disconnected by services) 04.55.47 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.55.50 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 05.00.59 # The palm pre did that - pretended over USB to be an apple product - and apple changed things to make it harder - so it might not be that simple. 05.01.42 # not entirely correct 05.01.59 # how so? 05.02.20 # oh, err, not really answering you :) more frhter up 05.02.26 # ah 05.02.54 # with a bit of tweaking you should be able to run the iap code on any other device (getting it to compile is the hard part). you'd probably need to change the usb id's also 05.03.20 # iirc rasher got a sansa pretending to be a ipod so itunes woiuld set the clock from a PC 05.11.06 Quit __jae__ (Remote host closed the connection) 05.11.12 Join __jae__ [0] (~jae@dedicated.jaerhard.com) 05.57.13 Quit TheSeven (Disconnected by services) 05.57.18 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 06.06.56 Join saratoga [0] (123e11e0@gateway/web/freenode/ip.18.62.17.224) 06.08.02 Quit Strife89 (Ping timeout: 272 seconds) 06.09.04 # i should really retest the clip+ battery life to see if its changed much recently 06.09.44 Nick SuperBrainAK is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) 06.41.46 Quit mt (Ping timeout: 265 seconds) 06.54.04 *** Saving seen data "./dancer.seen" 07.01.33 Join Rower [0] (husvagn@90-230-142-55-no41.tbcn.telia.com) 07.51.30 Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) 07.54.12 Join kugel [0] (~kugel@rockbox/developer/kugel) 07.55.42 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 07.56.21 Quit kugel (Read error: Connection reset by peer) 08.05.43 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 08.23.38 Join ender` [0] (krneki@foo.eternallybored.org) 08.30.05 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 08.32.54 Quit kugel_ (Ping timeout: 245 seconds) 08.37.11 Quit zoktar (Ping timeout: 245 seconds) 08.42.03 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 08.46.39 Join zoktar [0] (~zoktar@unaffiliated/zoktar) 08.48.35 Join petur [0] (5bb7304d@rockbox/developer/petur) 08.54.07 *** Saving seen data "./dancer.seen" 08.56.32 Join Zagor [0] (~bjst@2a01:2b0:3041:3018:2677:3ff:fea3:3ef4) 08.56.33 Quit Zagor (Changing host) 08.56.33 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 09.00.17 Join maruk1 [0] (~papier@titanium.v6.sdv.fr) 09.14.20 Quit bertrik (Ping timeout: 272 seconds) 09.21.47 Quit [Saint] (Read error: Connection reset by peer) 09.23.56 Join [Saint] [0] (~saint@rockbox/staff/saint) 09.25.22 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 09.40.36 Quit Provel (Read error: Connection reset by peer) 09.45.07 Join Provel [0] (~Provel@97-88-171-31.dhcp.stls.mo.charter.com) 10.20.49 # Let sansa learn to pretend to be an iPod? 10.20.53 # That sounds good. 10.46.42 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.52.19 # pamaury: no time to copy the data from intermediate buffer is mood point if there are drivers running in polled mode. Moreover interrupts are serialized so I can't still see the problem. You setup all dst addresses for ep dma engines to the intermediate buffer and in interrupt you copy the data to the actual location. 10.53.16 # hmm, no you are right that will not work 10.53.24 # damn 10.53.40 Quit pamaury (Read error: Connection reset by peer) 10.54.08 *** Saving seen data "./dancer.seen" 10.56.09 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.58.11 Join dfkt [0] (dfkt@unaffiliated/dfkt) 10.59.55 Quit Topy44 (Ping timeout: 252 seconds) 11.00.26 Join Topy44 [0] (~Topy44@93.190.93.215) 11.05.09 # Who owns G#384? 11.05.13 # 3Gerrit review #384 at http://gerrit.rockbox.org/r/384 : 3Touchscreen: Show a line separator in lists. by Thomas Martitz (changes/84/384/3) 11.06.34 # what do you mean by 'owns'? 11.06.42 Part Bagder ("*plopp*") 11.09.52 Quit Provel (Ping timeout: 272 seconds) 11.10.01 Join Provel [0] (~Provel@97-88-171-31.dhcp.stls.mo.charter.com) 11.10.07 Quit mc2739 (Ping timeout: 252 seconds) 11.11.49 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 11.28.49 # Owner 11.31.11 Quit pamaury (Quit: No Ping reply in 180 seconds.) 11.31.20 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.35.47 # by Thomas Martitz should give you a hint 11.44.20 Quit pamaury (Ping timeout: 272 seconds) 11.58.36 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.01.37 Quit petur (Quit: Page closed) 12.24.24 # It's kugel... 12.54.10 *** Saving seen data "./dancer.seen" 12.57.55 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 13.01.47 Join mt [0] (~mt@cpe-24-165-191-253.neo.res.rr.com) 13.16.49 Quit ikeboy (Quit: ikeboy) 13.19.53 Join felipeluna [0] (c81ba7f4@gateway/web/freenode/ip.200.27.167.244) 13.20.11 Quit wodz (Read error: No route to host) 13.25.45 # anyone knows how to control loops when using libgme decoder? 13.38.18 Join greenDaron [0] (~greenDaro@rtr.ds.pk.edu.pl) 13.44.54 Part greenDaron 14.24.08 Quit kiwicam (Ping timeout: 245 seconds) 14.41.43 Join krabador [0] (~krabador@unaffiliated/krabador) 14.43.51 Join wodz [0] (~wodz@87-207-223-0.dynamic.chello.pl) 14.45.26 Join amayer [0] (~amayer@mail.weberadvertising.com) 14.54.14 *** Saving seen data "./dancer.seen" 14.58.54 Quit cmhobbs (Ping timeout: 260 seconds) 15.27.12 Join ac_ [0] (~ac@AMarseille-151-1-88-8.w92-150.abo.wanadoo.fr) 15.28.23 Nick DormantBrain is now known as SuperBrainAK (~andy@2001:470:8:a61::5f92:59a1) 15.45.32 Quit krabador (Quit: Sto andando via) 15.45.43 Quit mt (Ping timeout: 272 seconds) 15.54.10 Quit linuxguy4 (Ping timeout: 252 seconds) 15.54.36 # rasher: do you read this? 15.55.36 # toehser1: I did it *before* the news about the palm pre :) 15.56.11 Join petur [0] (5bb7304d@rockbox/developer/petur) 16.03.34 Join linuxguy3 [0] (~timj@24-148-61-208.c3-0.lem-ubr1.chi-lem.il.cable.rcn.com) 16.14.58 # Seeing pamaury's http://www.rockbox.org/mail/archive/rockbox-dev-archive-2013-12/0006.shtml got much less reponse (zero) that IHMO it deserves (more than zero), I'm linking here in case anyone overlooked it. 16.16.30 # "one cannot enable the plugins without fixing all of them" is really poor, so Option 1) looks excellent to me. But "only plugins which can be run/have a keymap" needs defining with care, I think. 16.17.10 Join Strife89 [0] (~Strife89@adsl-98-80-207-168.mcn.bellsouth.net) 16.21.22 # ok thanks, unfortunately that doesn't solve the issue: someone has to do the work ^^ I began something back then but it's unfinished. For the moment I'm mostly trying to fix the lcd ZEN issue. I'm trying to get the STMP3700 errata because I know nearly for sure that it is a hardware bug. 16.26.24 # "doesn't solve the issue: someone has to do the work ^^ " Solving the issue of lack of response might leads to solving the issue of lack of work :) 16.27.10 # "hardware bug" meaning discrepancy between hardware behaviour and documentation? 16.27.59 # hey, well you could define it this way. In this case, it means part of hardware locks up and cannot be used anymore until you reboot. 16.28.54 # which is one very annoying way of not following the documentation ;) 16.35.51 # Well, often that can be due to a bug in code but rarely is considered a bug in the hardware. Undefined behaviour is a fact of CPU life :) You could consider it a badly designed panic alert :) 16.39.16 # In this case, this is definitely a hardware bug, I managed to reproduce and get a live system over USB and clearly the hardware is not behaving as expected: the LCD DMA channel does is blocked and even reset won't work whereas it should. 16.40.23 # When a peripheral reset has no effect, this is usually a good sign that's it's a hardware bug. 16.41.33 # The key think is: "whereas it should". If the docs say it should, then I agree there's a bug. 16.42.06 # If the docs don't, then one may have to reevaluate ""not behaving as expected" :) 16.43.34 # Perhaps consider that resetting a peripheral such as DMA channel may succeed in resetting the peripheral, but not the component on the receiving end of the channel. 16.44.49 # chrisjj: do you know how many devices pamaury has reverse engineered and written drivers for? Maybe the possibility that he knows what he's talking about isn't *that* far fetched 16.45.09 # You should never read a hardware datasheet then, because you will find that most hardware is ill-documented ;) 16.45.33 Quit Strife89 (Ping timeout: 246 seconds) 16.47.21 # despite being one of the best documented SoC I know, the stmp3700 is also a very complicated beast, and plenty of things are not properly documented. The behaviour of DMA channel reset isn't for example, but I think it's not ridiculous to admit that resetting a DMA channel should at least stop it and put it back to idle state 16.48.20 # Anyway, I have requested the STMP3700 errata to see if this a known problem 16.48.35 Join clip88231 [0] (4dff6fcf@gateway/web/freenode/ip.77.255.111.207) 16.49.49 Join saratoga_ [0] (4160ac54@gateway/web/freenode/ip.65.96.172.84) 16.53.14 Quit wodz (Ping timeout: 260 seconds) 16.54.19 *** Saving seen data "./dancer.seen" 17.00.08 Quit fragilematter (Quit: Leaving.) 17.01.04 Quit Zagor (Quit: Clint excited) 17.01.44 # I don't any see anyone not admitting that. I think resetting should put the controller to a defined state. But my point was that it does not put the component on the receiving end of the channel to a ready state, so if that component has got stuck, we're still stuck. 17.03.05 # I've read (and written) hardware data sheets and yes I agree some are not great. But that would not suggests never to read one :) 17.04.10 # "I have requested the STMP3700 errata to see if this a known problem" ISTR you also have the proven OF code disassembled? 17.07.49 # the bug is in the DMA channel here: the receiving side is fine. 17.08.13 # Have you managed to monitor the receiving side? 17.09.25 # resetting the DMA channel does not reset the peripheral, it only ends the transfer. In this case, the peripheral is still working but the DMA channel is blocked and cannot be used anymore. 17.09.39 # the OF code doesn't help here unfortunately 17.12.20 # OK. 17.13.19 # I am still unsure about how exactly this happen though 17.13.52 # I think it occurs in LCDIF DOTCLK mode if the the peripheral is reset while the fifo is not empty 17.17.06 # "The peripheral" being the DMA controller?? 17.18.27 # no, the LCDIF 17.18.30 Quit [Saint] (Remote host closed the connection) 17.18.47 # the DMA controller is completely separated from the LCDIF on STMP3700 17.19.01 # (on imx233 the LCDIF embeds a DMA controller so it's simpler) 17.19.32 # (though you can still drive the LCDIF with external DMA on imx233) 17.20.51 # "if the the peripheral is reset while the fifo is not empty" Sounds highly credible. 17.21.38 # Can you first do a reset to empty the FIFO? 17.24.16 # not yet, what is weird is that OF bootloader usually stops the LCDIF before handing over to the firmware but it appears it justs gates a few clock and freeze the DMA instead of resetting so I'm not sure what is the correct way to handle the situation. That will be trial and error. 17.24.27 Join [Saint] [0] (~saint@rockbox/staff/saint) 17.24.47 # Understood - not ideal and not safe, but perhaps it would narrow the search. 17.24.53 Quit saratoga_ (Ping timeout: 272 seconds) 17.26.57 # Good luck! 17.27.01 # BTW, re "Actually I was not aware that we had a typedef rule", I'd guess it is this: Line26_Write_normal_C_code__No_new_types 17.27.20 Join rela [0] (~x@pdpc/supporter/active/rela) 17.27.39 # I mean http://bit.ly/Line26_Write_normal_C_code__No_new_types 17.28.21 Quit petur (Quit: Page closed) 17.32.01 Quit [Saint] (Remote host closed the connection) 17.40.42 # hello people _o/ satisfied rockbox user here, I have a Sansa Fuze v2 17.41.26 # I just have a question : is it possible to get rid of the non-free firmware completely ? 17.44.09 # not using our tools, although I suppose theres no reason someone couldn't write software to do so 17.44.20 Join [Saint] [0] (~saint@rockbox/staff/saint) 17.47.49 # Here is the problem : when plugged, rockbox boots on the original firmware, and when unplugged, it refreshes the library, and this takes a ridiculously long time, and of course I can't shut it down while it's plugged 17.48.17 # we actually don't boot the OF on USB insertion, or at least haven't for a few years now 17.49.08 # saratoga: usually I boot it on rockbox before plugging it, but when the battery is empty I have no choice 17.49.27 # my guess is you are running some very old bootloader 17.50.17 # saratoga: you could be right, I've updated rockbox, but haven't thought updating the bootloader 17.51.27 Join wodz [0] (~wodz@87-207-223-0.dynamic.chello.pl) 17.51.39 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 17.52.58 # I also have a bug that happened few times : the device completely freezes at boot (booting rockbox), giving a blank screen, and there's no way to shut it down (it' a shame you can't remove the battery :/ ). I have to wait for the battery to empty and then charge it again. But my device is getting old, maybe it's hardware-related. 17.59.47 # ac_:I've found when that when RB crashes like that here, a device reset is sufficient to recover. Did you try device reset? On Sansa Fuze, hld Power for 20secs. 17.59.55 Quit gelraen_ (Quit: Quit) 18.01.46 # chrisjj: I didn't know about device reset, but IIRC I have tried holding the power button for 1 min and nothing happened 18.02.05 # bug reports for the circa 2011 bootloader are not very interesting 18.02.31 # Odd. Perhaps try that when the device is not crashed - to verify. 18.03.15 # its probably just crashed with the clocks screwed up badly enough that the hardware that monitors the buttons isn't running 18.03.26 Quit ikeboy (Remote host closed the connection) 18.07.41 # chrisjj: what does device reset do ? does it remove rockbox ? 18.07.50 # cuts power to the device 18.09.20 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 18.09.36 # ac_: It simply reboots the software, like e.g. Windows, Restart. It does not remove Rockbox or affect the any audio files. 18.10.21 # saratoga, chrisjj : ok, it's a "soft reset" then :P 18.11.29 # I don't remember how I installed the bootloader, is it via the rockbox utility ? 18.12.32 # yeah just intall a new one through that 18.12.40 # You might want to first ensure you have a copy of the current bootloader on PC, should you need to go back to it. 18.12.52 # saratoga: how do I know the version of my bootloader ? 18.13.06 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 18.13.34 # I believe it says the version briefly during startup 18.14.21 # well it's very brief :/ 18.14.30 # 3.0 I think 18.25.51 # looks like the new bootloader is still 3.0 18.26.01 Join bp0 [0] (~bp@228.222.2.96.wimax.dynamic.datatruck.com) 18.26.01 Quit bp0 (Changing host) 18.26.01 Join bp0 [0] (~bp@unaffiliated/bp0) 18.26.08 # and boots the original firmware when plugged 18.26.55 # oh no 4.0 18.27.09 # you have to reboot on the OF first, ok 18.27.13 Join pretty_function [0] (~sigBART@123.252.214.84) 18.27.38 # yeah, it works, cool \o/ 18.27.53 # erf 18.27.57 # blank screen 18.28.22 # "Undefined instruction at 0000003C" 18.29.09 # but soft reset works 18.31.48 # ok now my device freezes when plugged 18.32.14 # and unfreezes when unplugged, strange 18.33.24 # "Undefined instruction at 0000003C" and then "Undefined instruction at 300BF4F8" when I press power 18.33.37 # I pres power again and it reboots 18.35.22 # "Data abort at 3002E298 FSR0x8 (domain 0, fault 8) address 0x746B635C pc:3002E298 sp:300A0878" 18.36.47 Quit maruk1 (Quit: Leaving.) 18.43.08 # "but soft reset works" Progress! :) 18.44.03 # Is it possible that a bad usb connexion could make rockbox crash ? I'm not confident with this crappy proprietary physical usb connexion 18.44.24 # there seem to be a little slack 18.46.16 Quit clip88231 (Quit: Page closed) 18.52.42 # ac_: a bad USB connexion often crashes RB here, but I am using unstable ports. I don't know about the stable Sansa port. 18.54.20 *** Saving seen data "./dancer.seen" 19.07.50 Quit Raptors (Read error: Connection reset by peer) 19.08.05 Join Raptors [0] (~whoneedsa@198-200-68-213.cpe.distributel.net) 19.28.19 Join Strife89 [0] (~Strife89@2602:306:250d:18b9:e42e:ed47:3ab3:c4bf) 19.43.38 Quit bp0 (Quit: Leaving) 19.46.33 Quit wodz (Ping timeout: 252 seconds) 19.54.10 Quit Rower (Quit: Hmmm...) 19.56.22 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 19.58.48 Join keypin [0] (~user@p4FD4B0FC.dip0.t-ipconnect.de) 20.01.26 Quit pretty_function (Remote host closed the connection) 20.06.15 Join Horscht [0] (~Horscht@xbmc/user/horscht) 20.19.01 Quit Horscht (Quit: quit) 20.30.04 Join wodz [0] (~wodz@87-207-223-0.dynamic.chello.pl) 20.51.11 Join Rower [0] (husvagn@90-230-142-55-no41.tbcn.telia.com) 20.54.22 *** Saving seen data "./dancer.seen" 20.58.36 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 21.07.41 Quit felipeluna (Quit: Page closed) 21.09.24 Quit rela (Read error: Connection reset by peer) 21.27.35 Quit yosafbridge (Ping timeout: 245 seconds) 21.32.42 Join lebellium_ [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 21.33.01 Quit y4n (Quit: PÆNTS ØLF!) 21.35.52 Quit lebellium (Ping timeout: 272 seconds) 21.36.06 Nick lebellium_ is now known as lebellium (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 21.48.59 Quit Raptors (Read error: Connection reset by peer) 21.49.16 Join Raptors [0] (~whoneedsa@198-200-68-213.cpe.distributel.net) 21.53.17 Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) 21.56.45 Quit Rower (Quit: Hmmm...) 22.03.57 Part LinusN 22.07.37 Quit keypin (Ping timeout: 272 seconds) 22.10.04 Join keypin [0] (~user@p4FD4B0FC.dip0.t-ipconnect.de) 22.24.20 Quit ikeboy (Quit: ikeboy) 22.29.45 Quit bluebrother (Disconnected by services) 22.29.50 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 22.31.20 Quit fs-bluebot (Ping timeout: 272 seconds) 22.32.51 Join fs-bluebot [0] (~fs-bluebo@g224236153.adsl.alicedsl.de) 22.43.31 Join kugel [0] (~kugel@91-64-116-250-dynip.superkabel.de) 22.43.31 Quit kugel (Changing host) 22.43.31 Join kugel [0] (~kugel@rockbox/developer/kugel) 22.45.10 # Build Server message: 3New build round started. Revision d0d9f86, 249 builds, 33 clients. 22.47.19 Join mt [0] (~mt@cpe-24-165-191-253.neo.res.rr.com) 22.48.25 # Build Server message: 3Build round completed after 194 seconds. 22.54.23 *** Saving seen data "./dancer.seen" 22.57.53 Quit Strife89 (Ping timeout: 245 seconds) 23.06.10 Quit amayer (Quit: Leaving) 23.08.50 Quit wodz (Ping timeout: 245 seconds) 23.16.12 # copper: fixed 23.17.13 Part keypin 23.23.09 # kugel: excellent :D 23.26.03 # hmmm 23.26.14 # makes me want to get back to theming 23.26.21 # I have a couple ideas 23.27.49 # I have a new idea how to handle the themes at usb screen 23.28.11 # JdGordon, gevaerts, [Saint]: ^ 23.28.28 # AFAIK the main problem with themes there is that fonts are unavailable 23.29.06 # go on? 23.29.24 # so my idea is that we allow skins as normal, but just block drawing text 23.29.46 # what fonts are unavailable? 23.29.53 # Technically fonts aren't entirely unavailable 23.29.58 # ah 23.30.01 # copper: all except sysfont 23.30.10 # It's just that you can't get any glyphs that aren't in RAM 23.30.10 # you mean in that mode 23.30.40 # And you can't really know which glyphs are in RAM at any given time 23.30.47 # kugel: blocking text updates would block showing battery charging progress 23.31.23 # gevaerts: the cache is there yes, and I think it would be even better to assume the required glyphs are available; however handlign the case (which should be very unlikely) where this assumption doesn't hold isn't trivial 23.31.56 # * gevaerts tries to think 23.32.34 # I considered returning a sysfont glyph or returning blank if the cache lookup fails, both are non-trivial to implement 23.32.54 # copper: yes, it would also block printing the current time 23.33.07 # for battery a bar tag could function as a workaround 23.33.27 # For numbers, you can do fonts in bmp, but that's a bit of a hack 23.33.49 # however, in any event, showing frozen text seems better than disabling the entire theme (leading to black screen with only the usb logo) 23.34.13 # I'm trying to think how variable text will actually be on the USB screen. 23.34.27 # gevaerts: can be arbitrary with SBSs 23.35.00 # we could preload glyphs for it 23.35.10 # I don't understand 23.35.12 # so it owuld just need a tag to say what to load 23.35.19 # the font used to switch to sysfont anyway 23.35.20 # I'm all for more sophisticated solutions 23.35.31 # kugel: it can be, yes, but there's no playback active, so how variable is it *really* for text that's not in thje theme itself (or numbers)? 23.35.38 # however, playing around with my idea gives a reasonable result with little code changes 23.35.58 # gevaerts: fm radio can be active, no? 23.36.19 # hmmm 23.36.20 # right 23.36.52 # http://pastie.org/8633893 implements my idea 23.37.48 # We do potentially have a lot more RAM available for font caching, now that UMS allocation isn't silly any more 23.37.58 # the skin content can be arbitrary (and unicode) so I wouldnt go the route of trying to predict what text will be shown 23.39.28 # blocking all text isnt very nice either 23.39.36 # I'd allow sysfont at least 23.40.11 # JdGordon: it's better than completely blank screen isnt it? 23.41.03 # As a first step, I wouldn't go for a fallback to sysfont, so if the theme specifies another font, tough luck. If the theme asks for sysfont however, why not draw the text? 23.41.47 # falling back to for all text doesn't work anyway 23.41.55 # * JdGordon heads to work 23.42.19 # a) it has little character coverage and b) it has different geometrics which potentially messes up the skin layout 23.42.26 # * gevaerts nods 23.43.39 # IMO the best would be either to cache the whole font (what you seemed to propose above) or return a placeholder glyph for the very very very unlikely case of a cache miss 23.44.08 # not all targets can cache the whole font (and not all of them) I think 23.44.16 # Definitely not 23.44.31 # unifont is at least twice as big as the enire RAM on a clipv1 :) 23.45.29 # There might be another caveat though 23.46.31 # In the early days of usb on pp502x, I tried some sort of speed indicator on the USB screen, wich managed to destabilise USB by just wanting a bit of CPU on my e200 23.47.16 # I suspect things would be better now (there were lots of bugs in the driver back then), but I'm not entirely sure if all of our USB drivers will handle e.g. scrolling stuff or fancy animations 23.47.36 # the update rate of the sbs is limited (even with peakmeter on) so it shouldnt hog the CPU much 23.47.50 # We'll have to see 23.48.21 # "scrolling stuff" as in drawing text? 23.48.28 # Yes :) 23.49.46 # so what to do with my idea? 23.50.34 # I haven't seen an attempt in years to handle this problem properly so I'm willing to accept such a short-term solution 23.52.18 # * gevaerts looks at some code 23.54.43 # I'd still allow text if the theme specifies font 0, but I can't find right away how to do that 23.54.51 # Apart from that detail, I'm all for it