| 00:00:00 | BigBambi | Sure |
| 00:00:18 | BigBambi | But for those that do, they don't need to understand programming or anything |
| 00:00:34 | DefineByte | Just how to define fonts. x) |
| 00:00:57 | | Join midkay_ [0] (n=midkay@70-56-92-50.tukw.qwest.net) |
| 00:01:08 | BigBambi | How is that different from bitmaps, or conditionals for the WPS? |
| 00:01:29 | DefineByte | I wasn't suggesting it was. :) |
| 00:05:29 | | Quit bertrik_ ("bye") |
| 00:10:28 | | Join disorganizer [0] (n=5b11dba3@gateway/web/cgi-irc/labb.contactor.se/x-8a218edf1588fffb) |
| 00:11:48 | disorganizer | just a question for the font discussion: why not allow central definition of fonts via theme.cfg (filling the font-cache on config load) and allow a wps to overwrite the fontcache? |
| 00:15:30 | linuxstb | Why complicate things and allow fonts to be specified in two places? Also, how would the overwriting work - i.e. what fonts from the theme .cfg be overwritten? |
| 00:16:39 | | Quit lee-qid (Read error: 110 (Connection timed out)) |
| 00:17:12 | disorganizer | in the theme-cfg, you could define the fonts for the wps like wpsfonts=font.fnt,font2.fnt,font3.fnt |
| 00:17:34 | Llorean | Again, though, that rules out the possibility of shared fonts right there |
| 00:17:43 | disorganizer | the wps could use this "font array" by indexing: %f1 would be font ... etc |
| 00:17:46 | | Quit midkay (Read error: 110 (Connection timed out)) |
| 00:17:48 | Llorean | It makes much more sense, in my opinion, to just have font1, font2, font3, fontX |
| 00:17:58 | Llorean | As global font definitions |
| 00:18:14 | disorganizer | @llorean: we only need to work with the indexes in the font cache. we just need an algorythm to find identical fonts. example: |
| 00:18:44 | disorganizer | font1 is defined in the cfg as wps-font1, wps-font2 and menufont. font2 as listfont. |
| 00:18:51 | Llorean | disorganizer: Yes, but what about the case where someone wants the statusbar and all numbers in the WPS to share the same font? |
| 00:19:32 | linuxstb | disorganizer: I still don't understand what your idea will gain us. |
| 00:19:33 | Llorean | Why should they have to define the font in two places to do this? Why should fonts even be in two places at all? |
| 00:19:51 | * | Llorean doesn't see any actual benefit in having the fonts defined in the WPS. |
| 00:20:11 | disorganizer | slow. i will reexplain what i meant by allowing a wps to overwrite the fonts defined in the theme... |
| 00:20:44 | disorganizer | so lets say, like above, the theme defines wps-fonts as font1 and font2, so they are stored in the fontcache. |
| 00:20:51 | Llorean | Why not explain what is gained by splitting font definitions into two places? |
| 00:20:59 | disorganizer | @llorean: listen first |
| 00:21:04 | Llorean | Since there's no sense in deciding how to do it, if there's no gain in doing it... |
| 00:21:42 | | Quit csc` ("Powering Off") |
| 00:21:51 | disorganizer | now if the wps developer thinks he needs to ensure a special font is used for his wps (even if another theme is chosen for the rest of rockbox), he COULD (not need to) define them in the wps. |
| 00:22:09 | disorganizer | the wps setting would overwrite the wps-fonts in the fontcache on its first load. |
| 00:22:47 | disorganizer | this would please the theme developers delivering themes containing wps's (they could define the fonts in the theme-cfg) but also people only wanting to make a wps without a theme |
| 00:23:26 | disorganizer | :) finished explaining. questions ? |
| 00:25:15 | | Quit XavierGr (Nick collision from services.) |
| 00:25:26 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
| 00:25:34 | Llorean | disorganizer: The problem is that there's going to be more integration between WPS and Rockbox in the future, not less |
| 00:26:11 | disorganizer | integration of which kind? |
| 00:26:12 | Llorean | There's talk of using the WPS rendering code for the status bar. There's other talk of allowing the lists to overlay the WPS. There really isn't the kind of separation of WPS and Theme you're thinking of. It exists now, but the direction things are looking is to decrease it, not increase it. |
| 00:27:46 | disorganizer | well, if its going that way than of course only cfg-settings make sense. but imho they should not be put into the config file, but stay in the themefile and the config should only reference the theme-cfg file |
| 00:28:07 | disorganizer | but thats just a matter of taste :-) |
| 00:28:09 | Llorean | there's no difference between a .cfg file and a theme .cfg file. |
| 00:28:12 | Llorean | I don't know what you're saying there. |
| 00:28:31 | disorganizer | if you load a theme at the moment, the settings are copied from the theme-file to the rockbox-config |
| 00:28:38 | Llorean | No. |
| 00:28:46 | disorganizer | ? |
| 00:28:49 | Llorean | If you load a theme at the moment, any settings in the file are loaded, because it's just a .cfg |
| 00:29:20 | Llorean | There's only one type of .cfg file. Equalizer presets, themes, sound settings, are all just .cfg files of the same sort. |
| 00:30:02 | disorganizer | but afterwards you find the settings in the "default" config your rockbox loads. if the theme-creator decides to use a "special" setting, you need to manually reset it if you load another theme |
| 00:30:24 | Llorean | There's no such thing as a "special" setting. What do you maen? |
| 00:30:26 | Llorean | mean, rather |
| 00:31:02 | disorganizer | for example if one theme sets a backdrop, and another theme does not reset the backdrop. you could think of any setting a theme may set, as its only a config |
| 00:31:09 | | Join qwm [0] (i=qwm@c83-254-194-26.bredband.comhem.se) |
| 00:31:26 | | Join Absinthe [0] (n=cawagons@ool-43561407.dyn.optonline.net) |
| 00:31:37 | | Quit Absinthe (Client Quit) |
| 00:31:39 | Llorean | That's a problem with the theme not being explicit enough then |
| 00:31:57 | Llorean | If the theme wants there to be no backdrop, it should say "no backdrop" rather than what it currently says ("I don't care") |
| 00:32:33 | DefineByte | It's like a webpage that assumes specifying no colour = white. Very annoying. |
| 00:32:35 | Llorean | Why should it be impossible to load a theme without resetting the backdrop? |
| 00:32:55 | disorganizer | lets say i write a theme setting stereo width to 120. no other theme def would care about it ;-) this would happen if we have too many custom settings in the cfg, imho. |
| 00:33:39 | disorganizer | the backdrop was just an example :-) but anyways imho all settings done by a theme should be easily "revertable" by the user. also as said thats just a matter of taste :-) |
| 00:34:01 | Llorean | The solution is properly designed themes... |
| 00:34:40 | disorganizer | so how do you think fonts should be set via a theme? |
| 00:34:57 | | Nick midkay_ is now known as midkay (n=midkay@70-56-92-50.tukw.qwest.net) |
| 00:35:19 | Llorean | Pretty much how the single font is now. Load a series of fonts, and any part of the UI that can be individually fonted can reference it by number. |
| 00:36:03 | disorganizer | ok, so you prefer the font=font1,font2,font3,font4,... method, correct? that would also be the method i prefer :-) |
| 00:37:01 | DefineByte | If lists etc. are to become more customisable would users be able to use the WPS from one theme and the rest from another? |
| 00:39:38 | * | disorganizer noticed the mf patch is broken beyond repair |
| 00:39:52 | Llorean | DefineByte: They'll probably need to make their own .cfg for use with the WPS, at least. |
| 00:40:52 | | Join midkay_ [0] (n=midkay@70-56-92-50.tukw.qwest.net) |
| 00:40:57 | disorganizer | i think it also depends on how the customizability is done. IF the fonts are compatible and IF the customizable parts each have their own definition file, then copying files together would be enough. otherwise manual modification of the theme file or config file will be needed |
| 00:41:16 | | Quit midkay (Nick collision from services.) |
| 00:41:18 | | Nick midkay_ is now known as midkay (n=midkay@70-56-92-50.tukw.qwest.net) |
| 00:42:14 | | Quit ender` (" In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a b") |
| 00:44:24 | | Quit domonok1 (Read error: 104 (Connection reset by peer)) |
| 00:44:46 | disorganizer | @llorean: after thinking about it i believe you are right. the font=.... method is propably more logical as soon as other customizable objects come up. |
| 00:45:45 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 00:46:15 | Llorean | It's really a question of two design paths. Either each thing needs to be handled entirely separately, which means a lot of double and triple checking to make sure you aren't loading fonts more than once, or "whole" themes where different aspects can interact and keep consistency by being defined in terms of global appearance values, such as fonts and UI colors and such. |
| 00:46:32 | disorganizer | also it makes the parsing code easy: set font-array directly from config-file, and then use the indexes when parsing directly. we still need to handle "duplicate fonts" though, as font=font1,font1,font2,font1 should not hold font1 3 times in the cache |
| 00:47:07 | Llorean | It would be rather silly of a user to load three of the same fonts, especially since they're all set on one line so they can see it. |
| 00:48:31 | DefineByte | If a theme is that screwed up let the cache be screwed too. |
| 00:48:57 | Llorean | DefineByte: Well.. |
| 00:49:01 | disorganizer | yes, no doubt. but i propably will happen :-) especially if unexperienced users need to manually "combine" cfg's of different themes to maybe have the file list of one theme with the statusbar of another one and the wps of a third ;-) |
| 00:49:03 | | Quit mf0102 ("Verlassend") |
| 00:49:08 | | Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) |
| 00:49:21 | DefineByte | Is their going to be a limit to the number of definable fonts? |
| 00:49:28 | | Quit advcomp2019 (Nick collision from services.) |
| 00:49:31 | Llorean | It's going to be easier to just change the font line to contain duplicates, rather than go through a whole theme and change which font is referenced, of course. |
| 00:49:35 | | Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) |
| 00:50:15 | disorganizer | @llorean: the exaple would be a user wanting to have only 2 fonts in a wps where the developer used 3 fonts. |
| 00:50:40 | linuxstb | disorganizer: Then the user wouldn't choose that theme, or he/she would modify it. |
| 00:50:49 | Llorean | I think it is best to ask them to modify the theme. |
| 00:51:13 | Llorean | Since it'll affect more screens than just the WPS, in some or many cases, it seems like it should be a decision where they should be asked to actually check where the fonts are used. |
| 00:51:37 | disorganizer | but we could easily allow this: if we create an index of pointers into the real fontcache, we could allow 2 of those pointers to point to the same font without breaking the concept |
| 00:52:29 | | Quit XavierGr (Nick collision from services.) |
| 00:52:40 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
| 00:52:58 | amiconn | The font cache does not necessarily hold the whole font. With fonts covering larger parts of the unicode range, that's in fact rather unlikely |
| 00:54:09 | | Nick gregzx is now known as GregZzZZZzzzzZX (n=chatzill@dss184.neoplus.adsl.tpnet.pl) |
| 00:55:36 | disorganizer | @ amiconn : what part of the font will be cached? and which part not? |
| 00:55:50 | amiconn | The glyphs which are needed are cached |
| 00:55:57 | amiconn | (lru cache) |
| 00:56:09 | linuxstb | disorganizer: That's implemented currently (for a single font) |
| 00:56:18 | | Join shotofadds [0] (i=51016aa7@gateway/web/ajax/mibbit.com/x-8af845f9d49252d4) |
| 00:56:45 | | Quit DefineByte ("Bye all") |
| 00:56:50 | | Quit hd (Client Quit) |
| 00:57:18 | | Quit tvelocity (Remote closed the connection) |
| 00:57:25 | disorganizer | so atm there is a cache for the font which caches the glyphs used? so how will that be expanded to multifont? |
| 00:58:57 | | Quit Jon-Kha (Remote closed the connection) |
| 00:59:19 | * | shotofadds needs some kernel help. I've got interrupts and tick tasks working on the D2, but the menu freezes almost immediately because sleep_core() seems to enter an infinite loop. |
| 00:59:25 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:00:36 | shotofadds | unfortunately i'm kinda new to all this and don't really know where to look for clues. |
| 01:01:11 | linuxstb | disorganizer: That's the hard bit, and why the multi-font patch won't be committed in its current form. |
| 01:02:22 | disorganizer | @ linuxstb : oic. which method does the mf patch use? caching the full fontfile? |
| 01:02:59 | | Quit ompaul (Client Quit) |
| 01:03:58 | linuxstb | disorganizer: IIUC, it just has N separate caches, each caching 1 font. That's very inefficient - they should share the same buffer. |
| 01:06:14 | disorganizer | but if each cache is a glyph-cache, this uses the same memory as having one cache for all of them. correct? |
| 01:07:59 | linuxstb | I mean you should have one cache full of glyphs from all the fonts, rather than many caches, which may not all be full |
| 01:09:00 | amiconn | markun had some ideas how to improve font caching |
| 01:09:06 | linuxstb | shotofadds: Let me ping jhMikeS on your behalf... |
| 01:09:17 | soap | How are only the glyphs needed cached ahead of time? When a track is cached into the buffer are the glyphs pulled at that time for its (the track's) metadata? |
| 01:10:03 | | Nick miepchen^schlaf_ is now known as miepchen^schlaf (n=miepchen@p54BF7261.dip.t-dialin.net) |
| 01:12:33 | amiconn | It's an lru cache, and the glyphs that were cached last are written to a status file, and pre-cached at next boot |
| 01:12:50 | disorganizer | @ linuxstb : it could propably be possible to hold an array of all possible glyphs for each font, and only put pointers for the glyph into this array if it is cached in the combinded cache. whether this makes sense largely depends on how much memory an array of pointers for all possible glyphs would need compared to a cache for the font. |
| 01:13:17 | amiconn | If you suddenly play a track for which some glyphs are not cached yet, the disk has to spin up, that's unavoidable |
| 01:13:59 | amiconn | I don't know whether this was retained when MoB was committed, but the playback engine used to look a the metadata when buffering, and trigger caching of the needed glyphs |
| 01:14:19 | disorganizer | @amiconn: i think soap had the idea of caching the fonts as soon as the metadata is loaded in the buffer |
| 01:14:39 | soap | whoa - no ideas/suggestions here - just curious as to internal workings. ;) |
| 01:14:46 | amiconn | That idea already *was* implemented. I'm just not sure whether it still is |
| 01:15:04 | disorganizer | i was so slow in typing :-) |
| 01:15:28 | amiconn | disorganizer: Do you know how many code positions unicode allows? I.e., forget your array idea... |
| 01:15:54 | disorganizer | no, thats why i ask :-) |
| 01:16:04 | * | shotofadds is going to sleep on it. I'll pick up any hints from the logs tomorrow. |
| 01:16:08 | | Part shotofadds |
| 01:16:21 | amiconn | On targets with smaller screens, the font cache is smaller than just an array of 64K pointers would be. And 65K is just the so-called "base multilingual plane" of unicode |
| 01:16:59 | * | disorganizer thinks dropping unicode support would propably be easier :-) |
| 01:17:28 | * | amiconn would rather not implement multifont than dropping unicode |
| 01:18:17 | amiconn | Multifont is mostly a gimmick (with the exception of dual font for targets with an lcd remote), while unicode support is true functionality |
| 01:18:27 | disorganizer | so i wonder how a combined cache could be implemented. somewhere it must be decided to which font the glyph belongs. and stored, of course. and also the font cache would propably need to be bigger than now, as glyphs will be reused the less the more fonts are used on the same screen |
| 01:18:52 | * | disorganizer thinks he needs to be carefully about what things he makes jokes ;-) |
| 01:20:03 | | Quit piga ("Leaving") |
| 01:20:53 | disorganizer | this makes me think: if 3 fonts are evenly used on a wps with text, wouldnt the resulting combined cache to hold all glyphs on the screen be almost as big as 3 caches holding the used glyphs for each font? i mean, we will anyways need more fontcache-space if we use multiple fonts |
| 01:20:58 | Llorean | disorganizer: I don't know that it needs to be particularly bigger. |
| 01:21:40 | Llorean | The more fonts you use, the less likely those fonts are being used for something dynamic. For example, if you pick a font for numbers, you'll only ever cache 11 glyphs from it, probably. |
| 01:22:29 | Llorean | It could probably be expanded some, but there's going to be a point at which more fonts actually doesn't mean hardly any more cache space needed. |
| 01:22:36 | amiconn | disorganizer: It also depends on the font size |
| 01:23:25 | amiconn | If you e.g. use a big font for titles and a small font for artist and album, and give both of them an equally sized cache, the former might already start swapping glyphs, while the latter isn't even full |
| 01:24:25 | disorganizer | would dynamical handling of the cache help? rockbox could be able to identify a full cache and could dynamically give the full cache more space. |
| 01:27:13 | amiconn | Rockbox has no malloc, and that's for a ton of reasons |
| 01:27:59 | disorganizer | now, how is it handled at the moment if i use the sysfont and another font in my wps? |
| 01:28:20 | disorganizer | (thats font 0 and 1 in the vp definition) |
| 01:29:33 | | Quit amiconn (Nick collision from services.) |
| 01:29:40 | | Join amiconn [50] (n=jens@rockbox/developer/amiconn) |
| 01:30:49 | Llorean | I imagine sysfont isn't cached since it's always in RAM anyway |
| 01:31:38 | linuxstb | Yes, it's compiled-in (by definition) |
| 01:32:27 | disorganizer | so the main problem for mf implementation is indeed the caching.... |
| 01:32:51 | * | linuxstb commits a patch to undo all his RAM wastage and waits for the deltas to come in... |
| 01:33:38 | * | disorganizer hopes linuxstb gets enough ram free so we can waste the gained ram for fontcaching ;-) |
| 01:34:45 | Llorean | disorganizer: You don't free up RAM just to go and waste it. There still needs to be a good solution to the problem. :-P |
| 01:35:11 | jhMikeS | shotofadds: you must enable IRQ in core_sleep. have any pastebin of the code? |
| 01:35:21 | disorganizer | sometimes the solution is more RAM :-) or more bandwidth ;-) |
| 01:36:06 | jhMikeS | hmm...not here :\ |
| 01:36:42 | linuxstb | jhMikeS: As he left, he said he would read the logs... |
| 01:36:59 | | Join gevaerts [0] (n=fg@195-144-092-169.dyn.adsl.xs4all.be) |
| 01:37:09 | jhMikeS | deed |
| 01:37:22 | disorganizer | im still thinking about the dynamic buffersize. wouldnt there be possibilities to implement this without malloc? |
| 01:38:29 | gevaerts | disorganizer: what people are against is not the name "malloc", but the concept |
| 01:38:56 | Mouser_X | Similar question: If you have a plugin that needs 768 KB, as opposed to 512, would you have to stop playback to get the necessary memory? |
| 01:39:07 | Llorean | disorganizer: How would it grow during playback without shrinking the playback buffer? |
| 01:39:09 | disorganizer | a kind of linked list of glyphs, taking their memory from a combined pool (fixed size) |
| 01:39:17 | Llorean | Mouser_X: Yes. |
| 01:39:27 | gevaerts | disorganizer: where is that pool ? |
| 01:39:37 | Llorean | disorganizer: If it's from a fixed size pool, why not just allocate it in advance? |
| 01:39:50 | disorganizer | i explain again: |
| 01:39:54 | Mouser_X | So there's no way to provide that extra bit of memory, other than to stop playback and flush the buffer? Even though it's so little? |
| 01:40:04 | disorganizer | you have a fixed size pool |
| 01:40:17 | Llorean | Mouser_X: The memory can't appear out of thin air. |
| 01:40:18 | disorganizer | lets say an array of glyphs. lets say 20 |
| 01:40:28 | disorganizer | @llorean: we have a font cache now. |
| 01:41:10 | disorganizer | now we define an array of pointers for each loaded fonts, size is 20. |
| 01:41:50 | disorganizer | if a glyph is used for a font, its put into the prereserved array into the next free position. and inside the "font-cache" a ponter is set for this glph to the array position. |
| 01:41:51 | linuxstb | Mouser_X: If there was a plugin that needed 768K, then we could always increase the buffer size (if the plugin was worth it) |
| 01:42:06 | disorganizer | that way we have a per-font cache of pointers and a combined cache of glyphs |
| 01:42:35 | Llorean | There's no dynamically sized buffer in that description. |
| 01:42:55 | Mouser_X | Llorean: Hmmm. I was just asking out of curiosity. |
| 01:43:03 | | Quit Horscht ("User was distributing pornography on server; system seized by FBI") |
| 01:44:02 | disorganizer | @llorean: well, a kind of. we do not use all 20 "pointer" places for some fonts, but the wasted bufferspace would be less. the dynamic buffer was just a dramatically simplified description |
| 01:44:17 | Llorean | Mouser_X: Basically, playback claims all memory not reserved in advance for other things if it's active. And there's no good way to steal memory back from it while it's running. |
| 01:44:30 | linuxstb | Can someone remind me what the bin and RAM sizes include in the delta table, and why the average of those two deltas means anything? |
| 01:44:48 | Llorean | linuxstb: I never got that either. Shouldn't it be the sum? |
| 01:45:14 | disorganizer | and what about linked lists? |
| 01:45:17 | gevaerts | linuxstb: you need to keep score somehow |
| 01:45:22 | amiconn | The sum would effectively include the ram delta twice |
| 01:45:54 | linuxstb | Does the RAM delta include the bin delta? Or is it just the data/bss segments? |
| 01:45:54 | Llorean | amiconn: How so? |
| 01:46:01 | amiconn | ...because the binary is loaded to ram |
| 01:46:08 | amiconn | (except for rombox of course) |
| 01:46:24 | Llorean | So the sum would include the binary delta twice. |
| 01:46:27 | disorganizer | we start off with a list of empty glyph cache places. and a cached-glyph list for each font. |
| 01:46:30 | linuxstb | So then isn't just the RAM delta by itself more interesting? |
| 01:46:59 | amiconn | Both are interesting, for different purposes |
| 01:47:03 | Mouser_X | Build Environment Question: If I setup cygwin on a Windows computer, and have all the stuff put onto a USB flash drive, and then put that flash drive into a Linux PC, would I be able to build Rockbox without any alteration to anything? (If I build from the directory that the build environment exists in) |
| 01:47:14 | Llorean | amiconn: I think the real question is "is there any point where averaging them makes sense"? |
| 01:47:17 | linuxstb | I mean more interesting than the average of bin/ram. I understand they are both interesting. |
| 01:47:21 | amiconn | RAM delta is interesting because it tells how the audio buffer size will change |
| 01:47:54 | amiconn | And binsize delta is interesting because there are certain hard limits we do not want to hit |
| 01:48:10 | gevaerts | Mouser_X: I think you should be able to do something like that |
| 01:48:20 | linuxstb | And the average of the two is interesting because.... ? |
| 01:48:40 | amiconn | (rombox size on archos, and .ajz size limit for the archos loader) |
| 01:49:18 | | Join gregzx [0] (n=chatzill@dse54.neoplus.adsl.tpnet.pl) |
| 01:49:23 | Mouser_X | gevaerts: Thanks. I might have to. The USB hardware on my laptop (where my current build environment is) is screwed up, and can't provide enough power to my USB wireless adapter. |
| 01:49:34 | amiconn | The average in itself is not particularly interesting, but do you have a better idea how to indicate changes in either binsize or ram usage within a single table cell? |
| 01:49:42 | | Part ItalianPianist |
| 01:50:09 | linuxstb | Ah, so it's there in case one of them doesn't change? |
| 01:50:39 | disorganizer | were there thoughts about using linked lists of glphys for caching? |
| 01:50:41 | * | linuxstb thinks about what he just said... |
| 01:51:08 | linuxstb | I think I would just want the ramsize change in the box |
| 01:51:15 | amiconn | And as long as the ram usage only changes due to binsize change, the average is equal to that |
| 01:51:59 | gevaerts | disorganizer: linked lists won't change much |
| 01:52:39 | amiconn | The lru cache does use linked lists afaik |
| 01:52:41 | * | gevaerts thinks that linked lists would mainly increase RAM usage by four bytes per glyph |
| 01:53:24 | * | amiconn recommends disorganizer to take a look at lru.c, font_cache.c and font.c |
| 01:53:25 | disorganizer | well, linked lists could allow a dynmic cache without malloc-like behaviour |
| 01:53:45 | * | disorganizer is no programmer and doesnt understand c, so that wont help |
| 01:53:49 | gevaerts | Not really. They just provide a different way to do the indexing |
| 01:54:29 | disorganizer | but as i understood we do not have any indexing at the moment. and the problem is that a cache for each font would waste memory. so lists could help |
| 01:56:49 | disorganizer | we start off with a linked list of glyphs to reserve memory for the cache. each fonts gets its own list, which we start of empty, representing the glyphcache for each font. if a font uses a glph its storage space is taken from the list of empty cache spaces, and linked in the font-glyphcache |
| 01:56:59 | | Join aliask [0] (n=aliask@rockbox/developer/aliask) |
| 01:57:16 | disorganizer | if we have no more free glyphspaces, we need to apply magic |
| 01:58:10 | disorganizer | :-) so what we do is from all cached glyphs we search for the oldes and reuse it. that way the font needing the most space will get more cache spaces, and the one using less glyphs gets less spaces |
| 02:00 |
| 02:02:28 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
| 02:04:33 | | Join kushal_12_27_200 [0] (n=kushal@12.169.180.134) |
| 02:04:33 | | Quit jhMikeS (Read error: 104 (Connection reset by peer)) |
| 02:04:59 | | Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) |
| 02:07:30 | | Quit GregZzZZZzzzzZX (Connection timed out) |
| 02:08:55 | | Join flax^ [0] (n=knas@217-210-192-39-no51.tbcn.telia.com) |
| 02:10:08 | | Join bwananna [0] (n=bwana@67.220.1.138) |
| 02:10:19 | bwananna | hmm |
| 02:11:03 | bwananna | ok so question on replacement batteries for iPod mini, who sells quality batteries |
| 02:11:06 | bwananna | ? |
| 02:11:39 | aliask | You can find them resonably commonly on ebay, but I don't know about "quality" |
| 02:11:40 | flax^ | Any ETA on rockbox for 6g iPod's? |
| 02:12:11 | aliask | flax^: No. Nobody is working on it (that we know of). There are a number of serious hurdles to overcome before a port is even feasible too. |
| 02:13:03 | flax^ | Ok |
| 02:13:11 | flax^ | Sucks to be me then :< |
| 02:13:22 | bwananna | yea the last one i got on ebay was garbage, it was put togeather improperly so as it wouldn't fit into the ipod |
| 02:14:43 | aliask | Are you sure you got the right battery then? I've bought replacement ipod batteries off ebay and never had a problem |
| 02:15:21 | | Quit kushal_12_27_200 ("Leaving") |
| 02:17:11 | bwananna | yup |
| 02:17:17 | bwananna | according to them it was correct |
| 02:17:19 | | Part flax^ |
| 02:17:30 | bwananna | but in fact the daughter board on the battery was installed improperly |
| 02:17:41 | bwananna | thus making the physical dimensions just a little too big |
| 02:18:18 | bwananna | literally it was installed backwards!!!! |
| 02:18:21 | bwananna | gah |
| 02:18:29 | aliask | Damn, that's annoying. Couldn't you send it back? |
| 02:19:21 | bwananna | well |
| 02:19:23 | bwananna | I could |
| 02:19:36 | bwananna | but i decided instead of sending it back |
| 02:19:45 | bwananna | I could resolder the component on properly |
| 02:19:56 | bwananna | but accidently caused it to catch fire |
| 02:19:58 | bwananna | heh |
| 02:20:21 | aliask | Heh, I can imagine the look on your face... :) |
| 02:20:26 | bwananna | yea |
| 02:20:50 | aliask | Which country are you in? I know that in Australia a chain called jaycar often stock ipod replacement batteries. |
| 02:20:53 | bwananna | those people are right about the lion batteries catching fire for sure |
| 02:20:55 | bwananna | US |
| 02:21:00 | bwananna | we have a chain |
| 02:21:14 | bwananna | but they cost 30 bucks |
| 02:21:17 | bwananna | too expensive |
| 02:21:25 | bwananna | for a 560mAh battery |
| 02:21:45 | bwananna | i want at least a 700 for that price, but don't want to be ripped off again |
| 02:22:31 | | Quit tessarakt ("Client exiting") |
| 02:24:05 | bwananna | say, does rockbox util come with loader 1 or 2 currently? |
| 02:24:07 | bwananna | know offhand? |
| 02:24:27 | aliask | Isn't loader the ipod linux bootloader? |
| 02:24:46 | Llorean | bwananna: It comes with the official ROCKBOX bootloader, not the iPodLinux loader |
| 02:26:10 | bwananna | oh |
| 02:26:55 | bwananna | well anyway, rockbox is great software, thanks for all your work |
| 02:27:00 | bwananna | and thanks for the help |
| 02:27:29 | | Quit gevaerts ("really going to sleep now") |
| 02:31:08 | * | disorganizer is going to be now |
| 02:31:13 | disorganizer | nite@all |
| 02:31:24 | disorganizer | be=bed :-) |
| 02:31:37 | | Quit disorganizer ("CGI:IRC") |
| 02:39:42 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 02:45:09 | bwananna | strange |
| 02:45:44 | bwananna | the rockbox bootloader gives me an ATA: -80 error, but loader 2 loads rockbox seemingly fine |
| 02:53:30 | Llorean | How is your iPod partitioned and formatted? |
| 02:56:00 | | Quit FOAD (Read error: 110 (Connection timed out)) |
| 02:56:00 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 02:56:54 | | Join elite23q [0] (n=dc65344a@gateway/web/cgi-irc/labb.contactor.se/x-6f9d0dbd1f2297c9) |
| 02:57:13 | elite23q | hey dudes, im just wondering.. What does 'Rockbox' actually od? |
| 02:59:29 | *** | Saving seen data "./dancer.seen" |
| 02:59:37 | bwananna | Llorean : it is formatted however apple set it up |
| 02:59:48 | bwananna | then installed with the rbutil |
| 02:59:53 | Mouser_X | Od? It doesn't od anything... If you want to know what it can do, check here: http://www.rockbox.org/twiki/bin/view/Main/WhyRockbox |
| 03:00 |
| 03:00:14 | Llorean | bwananna: FAT32 or HFS+? |
| 03:00:22 | bwananna | i had itunes restore it before I installed rockbox |
| 03:00:23 | bwananna | fat32 |
| 03:00:31 | Llorean | Original hard disk? |
| 03:00:33 | bwananna | granted it is a compact flash |
| 03:01:00 | Llorean | That would be the problem. You should try compiling and using the SVN bootloader, rather than the currently distributed one. |
| 03:01:13 | bwananna | SVN should work huh |
| 03:01:22 | Mouser_X | elite23q: Rockbox is meant as a replacement for the Original Firmware. It can do all sorts of things. That link I gave (above) is much better than me retyping everything. |
| 03:01:49 | bwananna | well loader2 works fine |
| 03:01:50 | | Quit elite23q (Client Quit) |
| 03:02:08 | bwananna | i'll just wait until a newer version of the rockbox loader is distributed |
| 03:03:07 | bwananna | does the current rockbox loader allow you to choose from a menu what you want to boot, IE. rockbox, disk mode, or apple firmware? |
| 03:04:30 | krazykit | no, but you can hold a direction on the wheel to choose. |
| 03:04:54 | krazykit | not sure about how disk mode works, as i don't have an ipod, but the manual should be clear on the mapping |
| 03:05:40 | Llorean | bwananna: Be aware that the iPodLinux loader has been known to cause strange and obscure problems in the past. |
| 03:06:55 | bwananna | man |
| 03:15:30 | | Join saratoga [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-384a76dbf9180342) |
| 03:37:30 | | Join piga [0] (n=leonardo@189.5.228.43) |
| 03:40:12 | piga | saratoga: I talked to people of ArchC, and they told me that the ARM processor is not stable at version 2.0 of ArchC :( |
| 03:40:44 | piga | saratoga: But they told me that this Simit-ARM (http://simit-arm.sourceforge.net/) is a good one |
| 03:41:57 | piga | it is GNU license and is coded in C++ |
| 03:44:08 | | Quit fasmaie (Read error: 113 (No route to host)) |
| 03:46:27 | | Join kugel [0] (n=kugel@unaffiliated/kugel) |
| 03:48:29 | kugel | linuxstb: I've taken a quick look into parse_list now. For the font, it either sets vp->font to 0 or 1. But where is actually decided that 0 is SYSFONT and 1 is FONT_UI? |
| 03:48:45 | kugel | I admit, I'm trying to sync multifont |
| 03:49:35 | | Quit XavierGr (Read error: 113 (No route to host)) |
| 03:49:53 | | Quit bwananna ("thanks people") |
| 03:51:38 | aliask | kugel: In firmware/export/font.h - "enum { FONT_SYSFIXED, FONT_UI, MAXFONTS };" |
| 03:52:54 | kugel | aliask: Thanks |
| 03:54:34 | kugel | great, looks like I can ignore the hunk |
| 03:56:06 | | Join slackcub [0] (n=dsfranks@c-98-206-41-48.hsd1.il.comcast.net) |
| 03:58:16 | slackcub | how would I go about installing patches? |
| 03:58:49 | aliask | slackcub: Take a read of this: http://www.rockbox.org/twiki/bin/view/Main/WorkingWithPatches |
| 03:59:07 | slackcub | thanks! I knew I was missing something... |
| 03:59:11 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-294c6f8c48d3663c) |
| 04:00 |
| 04:00:56 | | Quit perrikwp (Client Quit) |
| 04:01:34 | | Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-da07a187e8929cf6) |
| 04:07:32 | slackcub | ok.. I guess I should have asked.. where can I get the source to apply patches to? |
| 04:07:55 | | Quit piga ("Leaving") |
| 04:08:15 | Mouser_X | It tells you in that link. |
| 04:08:27 | slackcub | it does.. guess i need to look closer |
| 04:08:53 | Mouser_X | I was thinking of a different one. |
| 04:09:01 | Mouser_X | SimpleGuideToCompiling |
| 04:09:34 | Mouser_X | slackcub: http://www.rockbox.org/twiki/bin/view/Main/SimpleGuideToCompiling |
| 04:09:55 | slackcub | thanks |
| 04:10:57 | | Join miepchen^schlaf_ [0] (n=miepchen@p54BF7E46.dip.t-dialin.net) |
| 04:19:45 | kugel | I build rockbox in 61s, is that good? |
| 04:20:07 | | Join argumentD [0] (n=argument@cpe-76-173-115-95.socal.res.rr.com) |
| 04:25:24 | | Join csc` [0] (n=csc@archlinux/user/csc) |
| 04:27:22 | | Quit miepchen^schlaf (Read error: 110 (Connection timed out)) |
| 04:27:50 | kugel | Ok, I'm trying to compile the sim, but I get this error:"cc1: error: unrecognized command line option "-fvisibility=hidden"" |
| 04:27:57 | aliask | A clean build of the main binary, plugins, codecs, langs, etc takes 3m41s on my box. |
| 04:28:22 | kugel | I formatted my disc recently, before that it worked |
| 04:28:38 | kugel | aliask: I guess 61s is good then :) |
| 04:29:07 | aliask | Did you install the build system from rockboxdev.sh? |
| 04:29:14 | kugel | yea |
| 04:29:25 | kugel | that doesn't install the sim build system anyway |
| 04:29:47 | kugel | But I went trough http://www.rockbox.org/twiki/bin/view/Main/UiSimulator#Building_Windows_sim_in_Linux |
| 04:29:57 | kugel | through* |
| 04:29:58 | aliask | It sounds like you have a wrong version of gcc or something |
| 04:30:17 | kugel | It says "Using i586-mingw32msvc-gcc 3.4.5 (304)" |
| 04:30:37 | kugel | I'm pretty sure that it said "Using gcc 4.3" or something before formatting |
| 04:30:52 | aliask | Is that the output from `gcc -v` |
| 04:31:07 | kugel | 4.1.3 |
| 04:31:28 | kugel | "gcc-Version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)" to be exact |
| 04:31:37 | | Join countrymonkey [0] (n=4b05639a@gateway/web/cgi-irc/labb.contactor.se/x-2f1a76f9bdc56db6) |
| 04:32:02 | aliask | Mmm. That should be fine - I'm running 4.1.2, but I doubt that'll be it. |
| 04:32:25 | countrymonkey | Is 8737 in a state of commitability? |
| 04:32:45 | kugel | aliask: What does it say when you run configure for sim? |
| 04:33:08 | aliask | kugel: I'm updating my svn atm, one that's done I'll check |
| 04:33:40 | kugel | you can run another terminal window :/ you just need a source on your hd |
| 04:34:18 | aliask | It says it's using gcc 4.1.2 - so that's your issue |
| 04:34:33 | aliask | Also - mingw32 will create win32 binaries (are you trying to do that?) |
| 04:36:01 | kugel | no |
| 04:36:10 | kugel | I hit 50 and s for e200 simulator |
| 04:37:20 |
icon identifies that the person is a core developer (has commit access).