| 00:00:08 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 00:02:18 | gevaerts | Quintasan: it should be GPLv2 or later |
| 00:02:26 | * | hillshum notices that rbutil's main.cpp header does not specify a version of GPL, nor is the COPYING file referenced present |
| 00:03:59 | Quintasan | hmm lack of COPYING file will be propably a problem |
| 00:04:05 | Quintasan | who should I poke to add it? |
| 00:04:40 | gevaerts | rockbox as a whole has the full license text. Do we distribute rbutil sources separately? |
| 00:05:34 | Quintasan | gevaerts: looks like -> http://download.rockbox.org/rbutil/source/rbutil-1.2.2.tar.bz2 |
| 00:05:41 | saratoga | if I want to have the codeclib able to do transforms of different sizes, how should I handle allocating buffer space for different transform sizes used for different codecs |
| 00:06:14 | saratoga | I'm thinking of having the init function return a struct, and then have the individual codecs add pointers to whatever buffers they want to use (IRAM, DRAM) |
| 00:06:28 | saratoga | but maybe theres a more elegant way? |
| 00:06:29 | Quintasan | gevaerts: nvm, it was inside the source tree, I hope that's acceptable |
| 00:07:07 | saratoga | the problem is that some codecs like WMA will need a lot of transform sizes (5) while others like ATRAC only use 1 size, so a lot of IRAM would be wasted if I allocated all 5 buffers in the lib |
| 00:08:07 | gevaerts | Quintasan: in general bluebrother and domonoky are the people to talk to about rbutil |
| 00:08:10 | saratoga | Quintasan: does packaging for ubuntu make sense? we tend to update rbutil from time to time, so if your copy isn't updated with it, yours won't be able to work with newer rockbox targets |
| 00:08:53 | hillshum | Depends on how often it's updated |
| 00:09:02 | Quintasan | saratoga: no problem if I make a watch file |
| 00:09:17 | Quintasan | it's not a problem even if I don't make it :P |
| 00:09:39 | Quintasan | urgh, now I have to find email of authors :/ |
| 00:09:56 | gevaerts | As far as I know rbutil is still considered to be in a state where it can be changed without backward compatibility (things like URLs on the website). Can you handle that? |
| 00:10:42 | * | hillshum thinks there should be an official Ubuntu PPA |
| 00:10:57 | gevaerts | Quintasan: ubuntu requires people to have an email address in order to allow their software in? |
| 00:11:36 | Quintasan | gevaerts: I need to give proper credit in copyright file, it mentions including emails, I dunno if it's required |
| 00:12:40 | Quintasan | I can just put their names but I bet archive admins will complain |
| 00:14:01 | gevaerts | isn't just a general contact address enough? |
| 00:15:13 | Quintasan | should suffice |
| 00:16:06 | gevaerts | Anyway, I think you should talk to domonoky or bluebrother first. I'm really not convinced that packaging, and therefore having old versions around, is such a good idea at this stage |
| 00:17:07 | Quintasan | gevaerts: what do you mean by old versions? I'm packaging current version and adding watch file to speed up updating Ubuntu package to new source |
| 00:18:00 | gevaerts | Quintasan: and they keep getting updated if people use e.g. LTS installs? |
| 00:19:09 | Quintasan | gevaerts: nope, I guess we can make a PPA if you need to upgrades to be supplied asap |
| 00:19:23 | gevaerts | PPA? |
| 00:19:32 | Quintasan | I found that request laying in Launchpad and I though I could try doing it |
| 00:19:38 | Quintasan | Personal Package Archive |
| 00:19:42 | Torne | we're just saying that sometimes we will change stuff that makes old rbutil builds entirely stop working |
| 00:19:48 | Torne | URLs on the rockbox servers, etc |
| 00:19:58 | Torne | because we generally assume that people use an rbutil they just downloaded . |
| 00:20:07 | Torne | not a bianry package someone may have made some time ago |
| 00:20:27 | Quintasan | uhm ok, so PPA would be better, but now that you mention it I don't really think I should package it |
| 00:21:14 | Torne | the rbutil builds we do are statically linked so generally they Just Work if people download them |
| 00:29:57 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
| 00:36:29 | * | domonoky1 mentions that the newest rbutil has a feature to nag the user, if a new version is online :-) |
| 00:37:34 | domonoky1 | also with the current static one-binary rbutil, a ubuntu package is not really needed. |
| 00:37:39 | | Quit kugel (Read error: 110 (Connection timed out)) |
| 00:38:28 | | Quit mcuelenaere () |
| 00:39:38 | | Join AEnima1577 [0] (n=clbarnob@c-98-249-3-190.hsd1.va.comcast.net) |
| 00:41:59 | | Quit Crunchie (Read error: 110 (Connection timed out)) |
| 00:43:52 | | Quit Ypsy ("Oh noes! My ZNC obviously just shut down :(") |
| 00:50:53 | | Quit Quintasan ("Konversation terminated!") |
| 00:52:44 | TheSeven | what's the easiest way to debug thread lockups? |
| 00:52:45 | | Join YPSY [0] (n=ypsy@geekpadawan.de) |
| 00:53:00 | TheSeven | is there any ready-make solution for dumping which thread is running? |
| 00:56:20 | | Join Omlet [0] (i=omlet05@38.145-241-81.adsl-dyn.isp.belgacom.be) |
| 00:57:52 | | Quit domonoky1 (Read error: 131 (Connection reset by peer)) |
| 00:59:04 | gevaerts | saratoga: I'm pretty sure that most tools will work from vmware |
| 00:59:35 | saratoga | i don't think I ever got MSC mode even working on vmware, but maybe that was just my machine |
| 01:00 |
| 01:02:21 | | Join bertrik_ [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 01:02:57 | | Quit bertrik_ (Client Quit) |
| 01:03:00 | | Nick YPSY is now known as Ypsy (n=ypsy@geekpadawan.de) |
| 01:03:31 | Unhelpful | TheSeven: you could probably do that under gdb if you can reproduce on sim. on target is more complicated, there's usb-serial logging on some targets but i don't know how well it will work if a thread isn't yielding |
| 01:04:04 | TheSeven | Unhelpful: it's happening somewhere around the usb driver :-/ |
| 01:04:15 | TheSeven | so on-screen is the only way i can think of |
| 01:04:57 | TheSeven | the only way i can think of right now is using a watchdog (either hardware or just emulated via the timer int) |
| 01:05:01 | Unhelpful | you could draw text to the screen, that's the only thing i can think of, but it would need to be done from the thread, and if you know which thread... |
| 01:05:28 | TheSeven | writing to the screen from a timer int could actually work |
| 01:05:34 | saratoga | i keep getting "error: expected specifier-qualifier-list" mean in gcc? |
| 01:05:47 | saratoga | err what does getting "error: expected specifier-qualifier-list" mean in gcc |
| 01:06:09 | TheSeven | saratoga: on what source code? |
| 01:06:28 | saratoga | TheSeven: http://pastebin.com/m28d3bfb |
| 01:06:36 | saratoga | line 15 |
| 01:07:20 | TheSeven | FFTContext vs. FFTComplex? |
| 01:08:14 | saratoga | yeah |
| 01:08:15 | saratoga | opps |
| 01:09:13 | saratoga | i'm getting cross eyed merging these headers |
| 01:09:53 | TheSeven | they fooled me, too, until i had a closer look |
| 01:11:22 | | Quit flydutch ("/* empty */") |
| 01:12:09 | | Quit amiconn (Nick collision from services.) |
| 01:12:11 | | Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) |
| 01:12:30 | | Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) |
| 01:13:49 | | Quit Omlet ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 01:14:38 | | Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) |
| 01:14:38 | | Quit pixelma (Nick collision from services.) |
| 01:14:57 | | Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) |
| 01:15:05 | *** | Saving seen data "./dancer.seen" |
| 01:15:56 | saratoga | i just decoded a WMA file with the new MDCT, though its garbled |
| 01:17:55 | | Quit toffe82_ ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]") |
| 01:22:14 | TheSeven | you mean it isn't crashing? |
| 01:22:18 | TheSeven | is it fast at least? |
| 01:26:21 | markun | saratoga: is the new MDCT already faster? |
| 01:26:56 | saratoga | it won't be faster just yet |
| 01:27:08 | saratoga | the old one is pretty well optimized and the new one isn't even working correctly yet |
| 01:27:12 | saratoga | but eventually i think it will be |
| 01:27:35 | saratoga | i just want to get a working patch so mt and i can chip away at optimizing it in rockbox |
| 01:27:52 | | Quit bertrik ("De groeten") |
| 01:28:12 | saratoga | but eventually i think it will be a couple MHz faster on ARM and probably a lot faster on Coldfire |
| 01:28:47 | saratoga | i'm hoping to do 300% realtime WMA decoding on PP with this |
| 01:31:23 | | Join Omlet [0] (i=omlet05@38.145-241-81.adsl-dyn.isp.belgacom.be) |
| 01:35:11 | | Quit ender` (" I went to a general store. They wouldn't let me buy anything specifically.") |
| 01:38:53 | | Quit DerPapst ("Leaving.") |
| 01:45:46 | | Quit Omlet ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 01:58:08 | | Quit beta2k (Read error: 110 (Connection timed out)) |
| 01:59:16 | | Join saratoga_ [0] (i=9803c6dd@gateway/web/freenode/x-dxnzxjxvhibdzgpt) |
| 02:00 |
| 02:00:38 | | Quit saratoga (Ping timeout: 180 seconds) |
| 02:04:48 | | Quit Xerion (Connection timed out) |
| 02:07:23 | | Quit panni_ (Read error: 131 (Connection reset by peer)) |
| 02:11:27 | | Quit n1s ("Lämnar") |
| 02:12:51 | | Nick Ypsy is now known as YPSY (n=ypsy@geekpadawan.de) |
| 02:12:53 | Unhelpful | saratoga_: what's new about it? |
| 02:13:18 | saratoga_ | Unhelpful: its the mdct we originally discussed this spring, one based on an FFT |
| 02:13:44 | | Join panni_ [0] (i=hannes@ip-95-222-21-143.unitymediagroup.de) |
| 02:13:48 | saratoga_ | it turns out we already had an FFT based on based on a fast split radix algorithm in liba52 |
| 02:14:17 | saratoga_ | and the ffmpeg people implemented the same algorithm for their new FFT |
| 02:22:42 | Unhelpful | i remember the discussion... i don't really *understand* fft in any great depth, though. |
| 02:28:12 | | Quit hillshum (Read error: 110 (Connection timed out)) |
| 02:28:40 | preglow | split radix is pretty much the way to go |
| 02:28:52 | | Join hillshum [0] (n=hillshum@75-165-234-34.slkc.qwest.net) |
| 02:29:14 | preglow | why would it be very much faster than what we have on coldfire, tho? |
| 02:35:36 | | Join CaptainKewl [0] (i=lkjl@207-237-172-77.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 02:37:44 | | Quit CaptainKewl (Client Quit) |
| 02:43:50 | saratoga_ | preglow: long time no see |
| 02:44:03 | preglow | quite :> |
| 02:44:05 | preglow | i do lurk though |
| 02:44:19 | saratoga_ | mostly because it would probably be easier to run on the emac |
| 02:44:29 | preglow | yeah, that is a good argument |
| 02:44:36 | saratoga_ | this ffmpeg fft is quite amazing |
| 02:44:45 | saratoga_ | they wrote it recursively out of preprocessor defines |
| 02:45:04 | saratoga_ | so we'd only have to asm the building blocks |
| 02:45:51 | preglow | it'll probably be pretty skippy on the memory access tho, so no movem :/ |
| 02:46:08 | saratoga_ | does that matter if we're in IRAM? |
| 02:46:15 | saratoga_ | i don't know much about how coldfire works |
| 02:46:30 | preglow | not as much as it would in ordinary ram no |
| 02:46:47 | preglow | but i don't really know the low level details on how split radix algos work |
| 02:46:52 | saratoga_ | what does movem do exactly? |
| 02:47:04 | preglow | just fetch consecutive values form memory in one go |
| 02:47:08 | Unhelpful | saratoga_: load a run of values from memory, i believe |
| 02:47:12 | saratoga_ | ah so its arms ldm |
| 02:47:20 | preglow | yeap |
| 02:47:28 | saratoga_ | i doubt thats a huge issue, theres still plenty of work done at each level |
| 02:47:42 | saratoga_ | split radix does a 2 and 4x decomposition at the same time |
| 02:47:55 | saratoga_ | so the Nth fft is composed of an N/2 and 2 N/4 FFTs |
| 02:47:59 | preglow | isn't split radix pretty much about decomposing a block into tons of small 2 and 4 size butterflies? |
| 02:48:41 | Unhelpful | saratoga_: i don't suppose they have an jpeg idct that's at all emac-friendly? |
| 02:48:58 | saratoga_ | i have no idea |
| 02:48:59 | preglow | i don't think you'd gain too much from using emac on jpeg idcts |
| 02:49:13 | preglow | you don't need too much precision |
| 02:49:19 | saratoga_ | but given the small size of the jpeg transform, you're probably better off looking up the known best algorithm |
| 02:49:53 | saratoga_ | thats what libmad does for its 36 point transform |
| 02:50:12 | saratoga_ | then unroll it and ASM it |
| 02:50:18 | preglow | for fixed size transforms, you're just better off bruteforcing the algo |
| 02:50:26 | saratoga_ | preglow: did you work on libmad? |
| 02:50:40 | preglow | algebraic simplifications and just code it |
| 02:50:44 | preglow | yeah, i did |
| 02:50:55 | Unhelpful | preglow: you don't need high precision, but you benefit from being able to roll multiplies together with adds. i did *pretty* well working from the ijg idct algorithms, but i suspect there may be better mac-optimized idct algos... |
| 02:51:05 | saratoga_ | do you know how libmad was chosen when SWCODEC was created? |
| 02:51:24 | preglow | it was chosen due to working pretty well out of the box |
| 02:51:35 | preglow | i did port another one made specially for 68ks |
| 02:51:42 | saratoga_ | what was it called? |
| 02:51:48 | preglow | but with no great luck, and tons of work needed to tailor it to emac |
| 02:51:51 | preglow | eh, i don't remember |
| 02:51:54 | preglow | but gimme a sec |
| 02:51:59 | saratoga_ | i wonder about libmad's performance |
| 02:52:20 | saratoga_ | it seems quite poor compared to other decoder's numbers, and thats after half of it was rewritten in ASM |
| 02:52:40 | saratoga_ | i suspect that some of its algorithmic choices are simply poor |
| 02:53:06 | preglow | http://www.pvv.org/~thomj/rockbox/cf-mpegdec_rockbox.tar.gz |
| 02:53:10 | preglow | that's how far i took it |
| 02:53:22 | preglow | well |
| 02:53:26 | preglow | it might be structured badly |
| 02:53:34 | preglow | but i don't think the algorithms are poor, specifically |
| 02:53:46 | saratoga_ | i've verified that the mdct is known optimal |
| 02:53:52 | | Quit GeekShadow (Read error: 104 (Connection reset by peer)) |
| 02:53:59 | saratoga_ | the ffmpeg and helix decoders are interesting |
| 02:54:02 | saratoga_ | helix in particualr |
| 02:54:09 | preglow | i'd love to use the helix stuff |
| 02:54:15 | preglow | what i've seen of it looks very good |
| 02:54:19 | saratoga_ | we can't use it but they have extremely interesting comments, and they benchmarked on arm7tdmi |
| 02:54:23 | preglow | indeed |
| 02:54:29 | preglow | their aac decoders also look great |
| 02:54:39 | preglow | nice memory use, good performance benchmarks |
| 02:54:42 | saratoga_ | yes some of the ideas i've had for ours are already used in it |
| 02:54:42 | Unhelpful | armv6 has some very nice simd instructions i can use if i can come up with an *efficient* way to reorder coefficients. easiest would probably be just to use a separate de-zigzag table for each ordering :/ |
| 02:55:10 | preglow | Unhelpful: for what target? |
| 02:55:21 | preglow | i can't even remember what the d2 has, i think it's armv5 |
| 02:55:37 | saratoga_ | the next time i'm trapped in an airport i want to go line by line and compute their multiply counts and compare to libmad |
| 02:55:48 | saratoga_ | I think v6 is just the beast right now |
| 02:55:57 | saratoga_ | and the upcoming nano4g port |
| 02:56:09 | preglow | so 4g has v6, does it |
| 02:56:12 | preglow | that's cute |
| 02:56:30 | Unhelpful | preglow: beast is the only armv6 target, i think. with 0-1-2-3 ordering the 4-point idct is faster to just do two columns in parallel than to try to use special ops to speed up the algorithm |
| 02:56:32 | preglow | the newer arms have some pretty specialized simd shit |
| 02:57:01 | saratoga_ | IIRC the 4G is basically just the iphone in a different package |
| 02:57:09 | preglow | i can live with that |
| 02:57:10 | saratoga_ | so it has absurdly overspeced hardware |
| 02:57:20 | Unhelpful | if i can get 0213 ordering for it then i can use more of the special ops |
| 02:57:35 | saratoga_ | yes its quite appealing, particularly given that the 16Gb option is pretty inexpensive |
| 02:58:00 | preglow | any way to actually flash it yet, tho? running rockbox from app hacks doesn't sit very well with me |
| 02:58:12 | saratoga_ | ask TheSeven |
| 02:59:24 | saratoga_ | he had some absurd runtime numbers for the 2G |
| 02:59:39 | saratoga_ | if they work out for the 4G it'll be a popular target |
| 03:00 |
| 03:00:15 | | Join Tomis2 [0] (n=Tomis@70.134.92.143) |
| 03:00:25 | | Quit Tomis (Read error: 104 (Connection reset by peer)) |
| 03:00:32 | | Nick Tomis2 is now known as Tomis (n=Tomis@70.134.92.143) |
| 03:01:06 | preglow | you had a look at porting the ffmpeg mp3 codec, btw? |
| 03:01:08 | TheSeven | saratoga_: ipod touch 2g to be correct |
| 03:01:19 | TheSeven | and they changed some things, e.g. reduced dram size to 32MB and removed the nor flash |
| 03:01:24 | saratoga_ | preglow: thats the other codec I've been looking at |
| 03:01:41 | saratoga_ | mp3 is next on my todo list once i have this imdct working well |
| 03:01:41 | TheSeven | and i'm not sure if they removed the arm7 core, it doesn't respond as expected at least |
| 03:01:41 | preglow | brb, teeth brushie |
| 03:02:37 | TheSeven | and the lcd is driven through spi instead of clcd |
| 03:02:58 | TheSeven | but i would guess they still have an hw h.264 decoder |
| 03:04:35 | saratoga_ | given the CPU speed would they actually need it? |
| 03:05:10 | TheSeven | i have no idea what they are clocking this thing at |
| 03:05:28 | TheSeven | they may actually using the bad chips for the nano and the good ones for the touch if they were clever |
| 03:05:55 | TheSeven | just blitting a memory buffer to the lcd is at ~20fps with caches disabled |
| 03:06:14 | TheSeven | remember that this tiny thing has a 240x320 lcd |
| 03:06:19 | preglow | probably hardware h264 |
| 03:06:34 | preglow | it can be done insanely more power efficient that way |
| 03:06:58 | saratoga_ | how does hardware H.264 work? |
| 03:07:13 | preglow | never actually read the specs on such a chip |
| 03:07:16 | saratoga_ | is it just a DSP core or do they actually have multipliers and such run in sequence |
| 03:07:36 | preglow | custom dsp core i guess |
| 03:07:37 | preglow | with a rom |
| 03:07:57 | preglow | with the decoder chip being interfaced directly to the lcd |
| 03:08:02 | saratoga_ | would that be much more power efficient then an arm core with NEON? |
| 03:08:22 | preglow | almost certainly |
| 03:08:44 | preglow | h264 coding isn't pure dsp data crunching |
| 03:09:15 | preglow | but like i said, i've never read the specs for a hardware solution |
| 03:09:52 | saratoga_ | i suppose having instructions for things like packed fixed point saturating multiplies and such would be a lot faster then arm |
| 03:10:02 | preglow | indeed |
| 03:10:11 | saratoga_ | have you looked at the ffmpeg mp3 decoder? |
| 03:10:16 | preglow | and the entropy coding part isn't cheap these days either |
| 03:10:24 | preglow | i've looked at it, but remember nothing of details |
| 03:10:48 | saratoga_ | i suppose the first step would be to just start picking pieces and swapping them into libmad and see if it gets faster |
| 03:11:30 | saratoga_ | well first i guess i should figure out all the stupid crap mp3 does |
| 03:11:50 | preglow | well, like i said, i don't believe the algorithmic choices in libmad are straight out bad |
| 03:12:03 | preglow | but yeah, you would probably see pretty easily if something is radically different and worth trying to swap out |
| 03:13:09 | saratoga_ | its funny how mp3 ended up being so much slower then everything else |
| 03:13:15 | preglow | one of the most cpu sucking parts is subband decoding, but i think libmad does that in an accepted fashion |
| 03:13:16 | saratoga_ | at least on ARM |
| 03:13:32 | saratoga_ | yeah synth_full is 50% of the total runtime |
| 03:13:34 | preglow | doesn't really surprise me |
| 03:13:45 | saratoga_ | its what i put on the coprocessor for PP |
| 03:13:47 | preglow | mp3 has so much shit in it for what it does |
| 03:13:51 | preglow | i mean, both subband coding and mdct? wtf? |
| 03:14:01 | saratoga_ | atrac3 does that too |
| 03:14:20 | saratoga_ | but it took buschel and mt like a week to get it working reasonably well |
| 03:14:39 | preglow | yeah, but i believe atrac uses coarses subbands |
| 03:14:49 | preglow | mp3 uses exactly the same filter bank as layer2 |
| 03:14:52 | saratoga_ | yeah just 3 |
| 03:15:03 | saratoga_ | or maybe 4 |
| 03:15:06 | *** | Saving seen data "./dancer.seen" |
| 03:15:08 | preglow | 4 i believe |
| 03:15:11 | saratoga_ | i mighht be mixing up atrac1 and 3 |
| 03:15:16 | preglow | sits better with algorithms |
| 03:15:35 | preglow | hmm, nah, forget that |
| 03:15:53 | preglow | as long as the bandwidths are the same for all bands, the downsampling is easy |
| 03:16:24 | saratoga_ | 1 is 3 bands, 3 is 4 bands |
| 03:16:39 | saratoga_ | 3+ uses 16 bands |
| 03:16:56 | saratoga_ | leave it to sony to rediscover stupid mpeg crap 15 years later |
| 03:17:33 | preglow | yeah |
| 03:17:40 | preglow | emphasis stupid |
| 03:17:50 | preglow | no pooint in keeping all that silly subband coding shit that i can see |
| 03:18:22 | saratoga_ | my theory is that they were interested in keeping the memory usage as absolutely low as possible |
| 03:18:24 | preglow | it just makes things more complicated and makes exact reconstruction impossible |
| 03:18:35 | preglow | my theory is they wanted to use as many patents as possible :P |
| 03:18:46 | saratoga_ | and somehow this evolved into a design philosophy that persisted long after memory became cheap |
| 03:19:01 | saratoga_ | this is mpeg or sony? |
| 03:19:06 | preglow | both |
| 03:19:43 | saratoga_ | that would explain the seperate tonal and spectral component coding |
| 03:27:25 | preglow | indeed |
| 03:27:30 | preglow | anywho, i gotta sleep |
| 03:27:36 | preglow | seeya |
| 03:35:58 | | Quit AEnima1577 ("Leaving.") |
| 03:37:13 | saratoga_ | see you |
| 03:42:38 | | Quit midgey () |
| 03:43:00 | Unhelpful | is low memory use still helpful for dedicated hardware implementations? |
| 03:52:43 | saratoga_ | Unhelpful: depends what you mean by low memory |
| 03:56:28 | | Join Topy [0] (n=Topy44@f049044018.adsl.alicedsl.de) |
| 04:00 |
| 04:00:33 | | Join AEnima1577 [0] (n=clbarnob@c-98-249-3-190.hsd1.va.comcast.net) |
| 04:00:50 | | Quit AEnima1577 (Client Quit) |
| 04:05:22 | | Join midgey [0] (n=tjross@c-71-238-148-140.hsd1.mi.comcast.net) |
| 04:05:33 | | Join panni__ [0] (n=hannes@ip-77-25-136-166.web.vodafone.de) |
| 04:07:57 | | Quit Rondom (Nick collision from services.) |
| 04:08:07 | | Join Rondom [0] (n=Rondom@dslb-084-057-184-209.pools.arcor-ip.net) |
| 04:12:24 | | Join CaptainKwel [0] (i=lkjl@207-237-172-77.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 04:14:49 | | Quit T44 (Read error: 110 (Connection timed out)) |
| 04:14:51 | | Quit panni_ (Read error: 104 (Connection reset by peer)) |
| 04:16:24 | | Join derekja [0] (n=derek@cpe-69-204-247-87.nyc.res.rr.com) |
| 04:16:30 | | Part derekja |
| 04:20:06 | | Quit TheSeven (Nick collision from services.) |
| 04:20:26 | | Join The_Seven [0] (n=theseven@rockbox/developer/TheSeven) |
| 04:20:38 | | Nick The_Seven is now known as TheSeven (n=theseven@rockbox/developer/TheSeven) |
| 04:22:31 | | Join AEnima1577 [0] (n=clbarnob@c-98-249-3-190.hsd1.va.comcast.net) |
| 04:22:38 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
| 04:23:19 | | Join panni_ [0] (i=hannes@ip-95-222-21-143.unitymediagroup.de) |
| 04:30:58 | | Quit panni__ (Read error: 110 (Connection timed out)) |
| 04:35:59 | | Quit AEnima1577 ("Leaving.") |
| 04:41:53 | | Quit HellDragon (Read error: 104 (Connection reset by peer)) |
| 04:42:00 | | Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) |
| 04:56:20 | saratoga_ | wow I think i am losing my mind over this fft bug |
| 05:00 |
| 05:15:07 | *** | Saving seen data "./dancer.seen" |
| 05:33:44 | | Join AndyI [0] (n=pasha_in@212.14.205.32) |
| 05:45:28 | | Quit AndyIL (Read error: 110 (Connection timed out)) |
| 05:46:48 | | Quit ps-auxw (Read error: 110 (Connection timed out)) |
| 05:57:42 | CIA-5 | New commit by blue_dude (r23628): pcmbuf: consolidate some similar code |
| 05:58:58 | | Quit BlakeJohnson861 ("Leaving.") |
| 06:00 |
| 06:06:39 | | Join BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 06:06:40 | | Quit JdGordon ("Leaving.") |
| 06:11:46 | saratoga_ | blue_dude: ping |
| 06:12:50 | | Join JdGordon [0] (n=Miranda@c-24-22-210-83.hsd1.wa.comcast.net) |
| 06:17:39 | | Join Blue_Dude [0] (n=chatzill@rockbox/developer/Blue-Dude) |
| 06:17:46 | Blue_Dude | Hi. I've only got a few minutes, though... |
| 06:18:49 | | Quit hillshum (Read error: 110 (Connection timed out)) |
| 06:18:55 | Blue_Dude | I saw your comment about running DSP on its own core, but DSP is already running on the codec thread, which is the problem to begin with. I'm not sure how to make DSP multithreaded with bad sync problems. |
| 06:19:02 | | Join hillshum [0] (n=hillshum@75.165.228.82) |
| 06:19:39 | Blue_Dude | saratoga_: oh yeah, pong... |
| 06:27:35 | Blue_Dude | I don't see any technical reason why DSP can't run its own thread on the other COP core. But the timing issues are confusing. If the pcmbuf begins to starve, which thread to boost? The DSP? And when it starves, it boosts the codec? What other threads would be competing for time on the COP and would they be badly affected by a CPU boost? etc. |
| 06:28:52 | Blue_Dude | Would it make more sense to move the codec thread in its entirety (w/ DSP) to the other core and flog it for all its worth if it begins to bog? |
| 06:29:14 | Blue_Dude | Just thinking aloud. Time for bed though... |
| 06:29:17 | | Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.5.5/20091102152451]") |
| 06:34:10 | | Join AaronM [0] (n=Aaron@adsl-155-218-45.mem.bellsouth.net) |
| 06:34:26 | saratoga_ | Blue_Dude: (for the logs) theres very little using the other core besides the MP3 decoder, which would use about 20MHz worth of its time |
| 06:34:43 | saratoga_ | if pcm begins to starve it always boosts both cores since they're synchronous |
| 06:35:09 | saratoga_ | I don't think it matters if the DSP starves because it can't get enough main CPU time, or enough COP time, either way it'll boost until it recovers |
| 06:35:23 | | Join shai [0] (n=Shai@l192-117-110-233.cable.actcom.net.il) |
| 06:35:35 | saratoga_ | mostly i think the problem would be seperating the DSP functions between the main and COP threads |
| 06:37:29 | | Quit goffa (Read error: 60 (Operation timed out)) |
| 06:37:34 | | Quit CaptainKwel ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 06:41:30 | | Join goffa [0] (n=goffa@70.33.8.114) |
| 06:41:33 | saratoga_ | Blue_Dude: the other interesting possibility I've thought about was to allow the entire pcmbuffer past the codec to run on the COP, basically make pcmbuf_insert pass data to the COP |
| 06:41:59 | saratoga_ | this would allow for some interesting codec optimizations such as running mdct on COP without having to pass data back to the main CPU |
| 06:42:13 | saratoga_ | but i have no idea how difficult that would be to do |
| 06:42:36 | saratoga_ | i suppose just moving EQ to the COP would be easier since EQ is relatively self contained |
| 06:50:30 | JdGordon | would that work with codecs themselves running on the COP also? |
| 06:50:55 | | Quit rphillips (Remote closed the connection) |
| 06:53:45 | | Join rphillips [0] (n=rphillip@66-90-184-91.dyn.grandenetworks.net) |
| 06:54:35 | | Join CaptainKewl [0] (i=lkjl@207-237-172-77.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 06:58:59 | | Quit CaptainKewl (Client Quit) |
| 06:59:02 | | Quit Tomis () |
| 07:00 |
| 07:08:25 | | Quit fyrestorm (Read error: 104 (Connection reset by peer)) |
| 07:08:45 | | Join fyrestorm [0] (n=nnscript@cpe-69-203-150-85.si.res.rr.com) |
| 07:09:06 | | Join CaptainKewl [0] (i=jds@207-237-172-77.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 07:14:37 | saratoga_ | JdGordon: you mean the whole codec? |
| 07:15:11 | *** | Saving seen data "./dancer.seen" |
| 07:25:26 | | Quit CaptainKewl ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 07:25:54 | CIA-5 | New commit by kkurbjun (r23629): Doom: test to see if it still needs Os on arm - that was set when the plugin buffer was smaller on all of the targets. |
| 07:38:36 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
| 07:39:59 | saratoga_ | does performance actually matter for doom? |
| 07:41:17 | | Quit panni_ ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
| 07:42:35 | kkurbjun | saratoga_: on the mr500 it's only getting 8 fps currently so I am just making it easier |
| 07:42:48 | saratoga_ | wow |
| 07:42:48 | kkurbjun | besides, if the space is there why not use it |
| 07:43:12 | saratoga_ | on the fuze doom crashes when it runs out of malloc space, but i guess Os isn't going to make much difference |
| 07:43:32 | kkurbjun | no, I don't think that Os would have any size on the dynamic memory |
| 07:43:51 | kkurbjun | any size impact that is |
| 07:46:08 | | Quit Horschti (Read error: 60 (Operation timed out)) |
| 07:57:11 | | Join Horschti [0] (n=Horscht2@xbmc/user/horscht) |
| 08:00 |
| 08:02:40 | | Join Rob2223 [0] (n=Miranda@p4FDCC351.dip.t-dialin.net) |
| 08:04:24 | | Quit JdGordon (Read error: 104 (Connection reset by peer)) |
| 08:04:31 | | Quit Horscht (Read error: 60 (Operation timed out)) |
| 08:05:21 | | Quit jfc (Read error: 145 (Connection timed out)) |
| 08:05:31 | | Join jfc [0] (n=john@dpc6682208002.direcpc.com) |
| 08:20:46 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
| 08:23:07 | | Quit saratoga_ ("Page closed") |
| 08:25:49 | | Join robin0800 [0] (n=quassel@general-ld-216.t-mobile.co.uk) |
| 08:26:30 | | Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
| 08:31:20 | | Nick nawks is now known as nawkzZzz (n=matt@va-67-233-123-218.dhcp.embarqhsd.net) |
| 08:35:31 | | Join stoffel [0] (n=quassel@p57B4EF10.dip.t-dialin.net) |
| 08:43:18 | | Quit shai ("Leaving") |
| 08:52:44 | | Quit phanboy4 ("Leaving") |
| 09:00 |
| 09:05:40 | | Quit BHSPitLappy (Read error: 104 (Connection reset by peer)) |
| 09:09:38 | | Join shai [0] (n=Shai@l192-117-110-233.cable.actcom.net.il) |
| 09:09:45 | | Quit midgey () |
| 09:12:04 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 09:15:15 | *** | Saving seen data "./dancer.seen" |
| 09:15:25 | | Quit elcan (Remote closed the connection) |
| 09:15:28 | | Join elcan [0] (i=user36@pr0.us) |
| 09:21:44 | | Nick Horschti is now known as Horscht (n=Horscht2@xbmc/user/horscht) |
| 09:25:55 | | Join flydutch [0] (n=flydutch@host119-166-dynamic.8-87-r.retail.telecomitalia.it) |
| 09:29:30 | | Quit elcan (Read error: 54 (Connection reset by peer)) |
| 09:29:35 | | Join elcan [0] (i=user36@pr0.us) |
| 09:40:13 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 09:50:13 | | Quit Horscht ("Verlassend") |
| 09:54:51 | | Join DerPapst [0] (n=DerPapst@p4FE8F94E.dip.t-dialin.net) |
| 09:58:04 | | Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) |
| 10:00 |
| 10:05:28 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
| 10:08:50 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 10:15:10 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 10:20:43 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 10:38:01 | | Join Mysterytrain [0] (n=George@66.216.229.82) |
| 10:38:16 | | Part Mysterytrain |
| 10:46:44 | | Quit maffe ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 10:54:52 | | Quit stoffel (Read error: 60 (Operation timed out)) |
| 10:55:00 | | Join stoffel [0] (n=quassel@p57B4E5EF.dip.t-dialin.net) |
| 11:00 |
| 11:00:38 | | Quit fyrestorm (Read error: 104 (Connection reset by peer)) |
| 11:00:50 | | Join stoffel_ [0] (n=quassel@p57B4E5EF.dip.t-dialin.net) |
| 11:01:52 | | Join fyrestorm [0] (n=nnscript@cpe-69-203-150-85.si.res.rr.com) |
| 11:14:15 | | Quit stoffel (Read error: 110 (Connection timed out)) |
| 11:15:19 | *** | Saving seen data "./dancer.seen" |
| 11:16:19 | | Quit BHSPitLappy ("Ex-Chat") |
| 11:16:35 | | Join pamaury [0] (n=pamaury@91-168-84-62.rev.libertysurf.net) |
| 11:17:50 | | Quit stoffel_ (Read error: 60 (Operation timed out)) |
| 11:22:11 | | Join Horschti [0] (n=Horscht2@xbmc/user/horscht) |
| 11:23:46 | pamaury | hello, is there any git "expert" around ? |
| 11:25:00 | | Join stoffel [0] (n=quassel@87.180.201.246) |
| 11:32:52 | | Join Omlet [0] (i=omlet05@38.145-241-81.adsl-dyn.isp.belgacom.be) |
| 11:36:08 | | Quit bertrik (Read error: 60 (Operation timed out)) |
| 11:36:41 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 11:42:46 | | Quit Horscht (Read error: 110 (Connection timed out)) |
| 11:46:30 | | Join teru [0] (n=teru@222.13.174.123) |
| 11:56:42 | | Join stoffel_ [0] (n=quassel@p57B4C9F6.dip.t-dialin.net) |
| 11:56:45 | | Quit bertrik (Success) |
| 12:00 |
| 12:00:15 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 12:01:43 | | Join Jaykay [0] (n=chatzill@p5DDC6BFD.dip.t-dialin.net) |
| 12:03:04 | | Quit stoffel (Read error: 145 (Connection timed out)) |
| 12:04:56 | | Join stoffel [0] (n=quassel@p57B4F20A.dip.t-dialin.net) |
| 12:13:25 | | Nick Zambezi is now known as Multiman (i=Zulu@80.67.9.2) |
| 12:13:36 | | Nick Multiman is now known as Zambezi (i=Zulu@80.67.9.2) |
| 12:18:43 | | Join stoffel__ [0] (n=quassel@p57B4F20A.dip.t-dialin.net) |
| 12:18:53 | | Quit stoffel__ (Remote closed the connection) |
| 12:19:34 | | Quit stoffel ("No Ping reply in 90 seconds.") |
| 12:20:00 | CIA-5 | New commit by teru (r23630): sudoku: fix improper checking if loaded puzzle is valid. blocks also need to be checked. |
| 12:20:59 | | Quit stoffel_ (Read error: 110 (Connection timed out)) |
| 12:47:44 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 13:00 |
| 13:06:30 | | Quit antil33t (Read error: 104 (Connection reset by peer)) |
| 13:06:36 | | Join antil33t [0] (n=Mudkips@203-184-54-232.callplus.net.nz) |
| 13:12:55 | | Join ps-auxw [0] (n=arneb@dyn37.ps-auxw.de) |
| 13:15:22 | *** | Saving seen data "./dancer.seen" |
| 13:19:43 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 13:22:15 | | Join Bagder_ [0] (n=daniel@1-1-5-26a.hud.sth.bostream.se) |
| 13:24:25 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 14:00 |
| 14:03:00 | | Join Zorda [0] (n=hi@c-71-62-228-21.hsd1.va.comcast.net) |
| 14:06:34 | | Quit Zorda_ (Read error: 110 (Connection timed out)) |
| 14:11:08 | | Join einhirn [0] (n=Miranda@p5DCC0D53.dip0.t-ipconnect.de) |
| 14:12:06 | | Quit chrism (Read error: 104 (Connection reset by peer)) |
| 14:23:14 | | Join Xerion [0] (i=xerion@82.170.197.160) |
| 14:32:22 | | Join Lss [0] (n=Lss@cm46.delta91.maxonline.com.sg) |
| 14:34:13 | | Quit n1s (Read error: 110 (Connection timed out)) |
| 14:38:04 | | Quit FOAD ("I'll be back") |
| 14:41:29 | | Join FOAD [0] (n=dok@dinah.blub.net) |
| 14:51:23 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 14:51:26 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 14:57:29 | | Quit Grahack ("Leaving.") |
| 15:00 |
| 15:00:16 | | Join blablabla [0] (n=qohaswys@215.80-241-81.adsl-dyn.isp.belgacom.be) |
| 15:01:47 | blablabla | Nobody here? |
| 15:02:02 | Bagder_ | just you and 136 bots |
| 15:02:27 | | Quit Zambezi (Read error: 110 (Connection timed out)) |
| 15:03:59 | CIA-5 | New commit by teru (r23631): jpeg/png: unify code to display image to draw_image(_rect). |
| 15:14:37 | | Quit DerPapst ("Leaving.") |
| 15:15:23 | | Quit blablabla (Remote closed the connection) |
| 15:15:24 | *** | Saving seen data "./dancer.seen" |
| 15:15:40 | | Join blablabla [0] (n=sdsepwyb@215.80-241-81.adsl-dyn.isp.belgacom.be) |
| 15:17:12 | | Quit blablabla (Remote closed the connection) |
| 15:17:20 | | Join blablabla [0] (n=ifjcoacb@215.80-241-81.adsl-dyn.isp.belgacom.be) |
| 15:17:44 | | Quit n1s (Read error: 110 (Connection timed out)) |
| 15:21:23 | | Quit blablabla (Client Quit) |
| 15:21:25 | | Join blablabla [0] (n=dwizocxs@215.80-241-81.adsl-dyn.isp.belgacom.be) |
| 15:24:08 | | Quit funman ("free(random());") |
| 15:24:31 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 15:27:52 | | Join efyx_ [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 15:36:15 | | Quit FlynDice (Remote closed the connection) |
| 15:38:49 | | Quit Bagder_ (Read error: 60 (Operation timed out)) |
| 15:39:00 | blablabla | What are you doing? |
| 15:39:32 | funman | things |
| 15:39:50 | | Join nex_1 [0] (n=niemandc@dslb-088-065-066-181.pools.arcor-ip.net) |
| 15:40:02 | blablabla | What are you doing?? |
| 15:40:06 | blablabla | What are you doing? |
| 15:40:10 | funman | blablabla: read the topic |
| 15:40:14 | Mode | "#rockbox +o funman " by ChanServ (ChanServ@services.) |
| 15:40:47 | nex_1 | hi, how can i try rockbox on my desktop? a long time ago i was able to run rockbox virtual out of the desktop. too long ago.. how can i do this again? |
| 15:41:08 | funman | nex_1: you can run the rockbox simulator |
| 15:41:26 | nex_1 | rockbox simulator, ok. where can i download itß |
| 15:41:41 | funman | rockbox.org |
| 15:41:45 | | Quit blablabla (Remote closed the connection) |
| 15:42:00 | | Join blablabla [0] (n=jiqbosax@215.80-241-81.adsl-dyn.isp.belgacom.be) |
| 15:42:32 | nex_1 | oh reallaly? |
| 15:42:52 | pixelma | or prebuilt simulators from rasher's page (maybe not completely up-to-date) |
| 15:43:41 | nex_1 | okay thank you. i try to build it manually |
| 15:44:14 | | Quit Jaykay (Read error: 110 (Connection timed out)) |
| 15:44:58 | | Quit antil33t () |
| 15:50:46 | kugel | Unhelpful: I fail to compile gcc from svbn :( |
| 15:52:02 | kugel | I mean, it in fact compiled, but multilib seems to be messed up (unknown option -mcpu=arm7tdmi) |
| 15:52:44 | nex_1 | how many uarts does an ipod nano 1g have? |
| 15:53:34 | kugel | hm, it seems gnu-as seems to complain, not gcc |
| 15:53:48 | | Quit blablabla (Read error: 54 (Connection reset by peer)) |
| 15:54:01 | | Join blablabla [0] (n=fvkobmrt@215.80-241-81.adsl-dyn.isp.belgacom.be) |
| 15:55:35 | Mode | "#rockbox -o funman " by funman (n=fun@rockbox/developer/funman) |
| 15:56:15 | | Quit blablabla (Read error: 104 (Connection reset by peer)) |
| 15:56:26 | | Join blablabla [0] (n=gljzgltz@215.80-241-81.adsl-dyn.isp.belgacom.be) |
| 15:57:10 | | Quit blablabla (Read error: 104 (Connection reset by peer)) |
| 15:57:22 | | Join blablabla [0] (n=uokonboc@215.80-241-81.adsl-dyn.isp.belgacom.be) |
| 15:58:07 | | Quit blablabla (Read error: 104 (Connection reset by peer)) |
| 15:58:19 | | Join blablabla [0] (n=ksdwrjpn@215.80-241-81.adsl-dyn.isp.belgacom.be) |
| 15:58:42 | kugel | interesting, having gnu-as and gcc in different bin/ dirs breaks things |
| 15:59:24 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 15:59:34 | nex_1 | hm.. would be able to put an ipod nano in an ipod mini box? http://img.tomshardware.com/de/2005/09/13/apple_ipod_nano_kleinster_mp3_player_mit_farbdisplay/ipod_nano4.jpg |
| 15:59:56 | nex_1 | i have no measured data, but it looks like it would be able, or? |
| 16:00 |
| 16:00:07 | | Quit blablabla (Read error: 104 (Connection reset by peer)) |
| 16:00:57 | | Join blablabla [0] (n=fayhbcvu@215.80-241-81.adsl-dyn.isp.belgacom.be) |
| 16:01:28 | nex_1 | ok, i think the display makes no problems, but the clickwheel is to little, and i dont think the ipod mini clickwheel is compatible |
| 16:03:36 | | Quit blablabla (Read error: 54 (Connection reset by peer)) |
| 16:03:47 | | Quit liar (Read error: 60 (Operation timed out)) |
| 16:04:43 | | Join Zambezi [0] (i=Zulu@80.67.9.2) |
| 16:05:00 | funman | nex_1: if it's not related to rockbox it's better to discuss it in #rockbox-community |
| 16:05:15 | nex_1 | ok |
| 16:05:16 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
| 16:06:42 | | Join Llorean [0] (n=DarkkOne@adsl-76-204-246-139.dsl.hstntx.sbcglobal.net) |
| 16:09:30 | | Join antil33t [0] (n=Mudkips@203-184-54-232.callplus.net.nz) |
| 16:09:42 | | Quit Zorda (Read error: 110 (Connection timed out)) |
| 16:09:49 | | Quit einhirn (Read error: 104 (Connection reset by peer)) |
| 16:10:51 | kugel | aaargh, stupid fuze |
| 16:11:10 | kugel | funman: compiling with eabi breaks the ams sd driver |
| 16:12:01 | | Quit Horschti (Read error: 60 (Operation timed out)) |
| 16:15:15 | | Quit gevaerts (Nick collision from services.) |
| 16:15:26 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 16:16:57 | | Join stoffel [0] (n=quassel@p57B4E126.dip.t-dialin.net) |
| 16:26:00 | | Join liar [0] (n=liar@83.175.83.185) |
| 16:26:39 | | Quit n1s (Read error: 110 (Connection timed out)) |
| 16:29:46 | funman | it breaks a lot of things it seems |
| 16:31:48 | kugel | getting MCI_DATA_CRC_FAIL it seems |
| 16:32:13 | funman | i don't see asm() in the file |
| 16:32:28 | funman | are you compiling with -O somethign? |
| 16:34:33 | kugel | whatever rockbox is compiled with |
| 16:34:54 | kugel | -O it seems |
| 16:35:13 | funman | try with -O0 perhaps to see if optimization removes/reorder something needed |
| 16:35:53 | kugel | -O0 doesn't even compile |
| 16:36:09 | funman | how come? |
| 16:36:23 | | Join blablabla [0] (n=gdpwfbwn@215.80-241-81.adsl-dyn.isp.belgacom.be) |
| 16:36:24 | | Quit blablabla (Read error: 104 (Connection reset by peer)) |
| 16:36:36 | | Join blablabla [0] (n=ptjjaxtf@215.80-241-81.adsl-dyn.isp.belgacom.be) |
| 16:37:09 | kugel | firmware/target/arm/system-arm.h:253: error: impossible constraint in ‘asm’ |
| 16:37:11 | | Quit blablabla (Read error: 104 (Connection reset by peer)) |
| 16:37:20 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 16:39:03 | kugel | I'm not too familiar with inline asm syntax, do you see something fishy? |
| 16:39:29 | funman | i don't know better than you :/ |
| 16:40:28 | | Join blablabla [0] (n=zysjytnx@215.80-241-81.adsl-dyn.isp.belgacom.be) |
| 16:40:33 | funman | perhaps there's something in info gcc C\ Extensions Constraints |
| 16:43:10 | | Quit Lss (Read error: 54 (Connection reset by peer)) |
| 16:43:33 | | Join Lss [0] (n=Lss@cm46.delta91.maxonline.com.sg) |
| 16:43:53 | | Join MethoS- [0] (n=clemens@134.102.106.250) |
| 16:45:09 | | Quit nex_1 ("cu") |
| 16:46:12 | | Quit flydutch ("/* empty */") |
| 16:48:57 | kugel | funman: "i" must be "r" it seems |
| 16:49:26 | | Quit robin0800 (Read error: 60 (Operation timed out)) |
| 16:50:01 | kugel | debug_menu.c doesn't compile to |
| 16:50:02 | kugel | too |
| 16:50:05 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 16:50:09 | kugel | strange things happen there |
| 16:52:27 | kugel | funman: -O0 indeed works! |
| 16:52:38 | | Join robin0800 [0] (n=quassel@149.254.200.216) |
| 16:52:55 | kugel | that means I need to dig into the disassembly to see what's being optimized away :S |
| 16:53:19 | funman | or try -O{s,1,2,3} :P |
| 16:53:36 | kugel | -O2 doesn't work as well |
| 16:53:55 | kugel | -O0 is a *huge* binsize hit, btw |
| 16:54:58 | | Quit blablabla (Read error: 104 (Connection reset by peer)) |
| 16:57:22 | kugel | as a side note: the clip playback crash happens on -O0 too |
| 16:57:44 | | Nick nawkzZzz is now known as nawkz (n=matt@va-67-233-123-218.dhcp.embarqhsd.net) |
| 17:00 |
| 17:01:46 | kugel | funman: are you interested in looking at the disassemblies as well? |
| 17:02:07 | | Join stoffel_ [0] (n=quassel@87.180.234.180) |
| 17:02:12 | | Join blablabla [0] (n=jhqpeqnt@215.80-241-81.adsl-dyn.isp.belgacom.be) |
| 17:02:39 | kugel | I'm curious why this is exposed with eabi |
| 17:03:04 | funman | sorry no |
| 17:03:12 | | Quit blablabla (Read error: 104 (Connection reset by peer)) |
| 17:03:33 | kugel | there's no mci_delay() in -O1 :/ |
| 17:04:00 | funman | hum it has no side effects |
| 17:04:06 | | Join Zorda [0] (n=hi@c-71-62-228-21.hsd1.va.comcast.net) |
| 17:04:09 | funman | what if you mark i as volatile ? |
| 17:04:19 | | Join darkham [0] (n=darkham@host8-155-dynamic.6-87-r.retail.telecomitalia.it) |
| 17:04:38 | | Join MaadMan [0] (n=MaadMan@188-192-221-19-dynip.superkabel.de) |
| 17:07:13 | n1s | kugel: did you look at my patch in fs#10616? |
| 17:07:23 | kugel | funman: that fixes problems indeed |
| 17:07:47 | kugel | n1s: yes |
| 17:08:24 | kugel | the plugin.c hunk shouldn't be needed. clear_display() also does stop_scroll() |
| 17:09:04 | kugel | for the radio.c hunk, as I said, I would be happier if scroll_stop() could be used. although I vaguely remember to have radio.c fixed already |
| 17:09:17 | kugel | maybe only for exiting |
| 17:09:53 | n1s | kugel: yeah this happens when calling the context menu in the radio screen, exit is fine, i |
| 17:09:59 | n1s | 'll try that out |
| 17:10:26 | kugel | n1s: scroll_stop() is called at the end, maybe you can do it in the same way |
| 17:10:40 | pixelma | n1s: did you also look at the USB screen? |
| 17:11:21 | kugel | funman: maybe I should commit my semi-but-better-than-nothing udelay() to get around those busy waits |
| 17:12:11 | | Join ipod2g [0] (n=7a35c352@giant.haxx.se) |
| 17:12:21 | funman | how is it different from busy loops? |
| 17:12:41 | n1s | pixelma: no, will loom once i've this down |
| 17:12:41 | n1s | look, even |
| 17:13:15 | | Quit stoffel (Read error: 110 (Connection timed out)) |
| 17:13:40 | n1s | kugel: in plugin.c clear_display() is called before starting the plugin, my change was to prevent scrolling lines that appeard after exiting the plugin, so should clear_display() be called after exiting plugins too? |
| 17:13:59 | kugel | funman: should the delay halved when I insert asm volatile ("nop\n") into the while loop? |
| 17:14:26 | funman | ? |
| 17:14:32 | | Quit robin0800 (Read error: 131 (Connection reset by peer)) |
| 17:14:47 | CIA-5 | New commit by teru (r23632): jpeg/png: change file list handling a bit. ... |
| 17:14:59 | kugel | it does int i = 0xfff; while(i−−) now |
| 17:15:06 | ipod2g | hey #rockbox, i've just updated to the daily build of the nano2g which is r23630-091115 and i get frequent channel-swapping. my last build i used was r23367-091027 and i havent got a single issue about the channel-swapping. what gives? |
| 17:15:28 | *** | Saving seen data "./dancer.seen" |
| 17:16:05 | funman | what's channel swapping ? |
| 17:16:19 | | Join kugel_ [0] (n=kugel@e178092110.adsl.alicedsl.de) |
| 17:16:34 | | Quit kugel (Nick collision from services.) |
| 17:16:37 | kugel_ | doesn't an additional nop mean the effective delay is (approx) doubled? |
| 17:16:39 | | Nick kugel_ is now known as kugel (n=kugel@e178092110.adsl.alicedsl.de) |
| 17:17:04 | funman | not really, you need to read the assemblty |
| 17:17:12 | ipod2g | funman: left channel goes to the right and vice versa |
| 17:18:43 | kugel | mci_delay() is very strange on -O0 |
| 17:20:17 | n1s | ipod2g: a bug that has been intruduced since your last build then probably |
| 17:21:36 | ipod2g | yeah i've been encountering those on recent builds but not as frequently as this one thou |
| 17:21:37 | pixelma | I thought that channel-swapping existed for the 2ng gen Nano already |
| 17:22:41 | pixelma | (i.e. hasn't been fixed yet and I'm just wondering why you said that it didn't happen with an older build), but I don't have a Nano |
| 17:23:34 | ipod2g | not as frequently as the older builds |
| 17:23:34 | n1s | pixelma: iirc it was fixed at one point and appears to have reappeared |
| 17:24:17 | n1s | that is a bug that has affected for several targets, btw |
| 17:24:51 | pixelma | I know the first gen Nanos had the same problem ages ago |
| 17:25:34 | | Join robin0800 [0] (n=quassel@general-ld-216.t-mobile.co.uk) |
| 17:27:12 | n1s | kugel: is it better to do lcd_clear_display() after exiting plugins than explicit lcd_stop_scroll() ? |
| 17:28:08 | kugel | not really, but it wouldn't hurt |
| 17:28:29 | n1s | ok, i'll do that instead then |
| 17:28:41 | kugel | I just thought it was done already (but it is only via send_event(GUI_EVENT_REFRESH, NULL) which only does something when sbs or custom ui vp are active) |
| 17:29:42 | ipod2g | so it is really a bug in almost all targets? |
| 17:31:23 | kugel | +300k due to -O0 on the fuze :P |
| 17:31:42 | | Join Tomis [0] (n=Tomis@70.134.71.157) |
| 17:32:44 | | Join Jaykay [0] (n=chatzill@p5DDC6BFD.dip.t-dialin.net) |
| 17:33:00 | Bob_C | kugel: sounds like a step in the wrong direction :) |
| 17:33:43 | kugel | Bob_C: -O0 at least produces something working :S |
| 17:34:47 | Bob_C | what's a quick way to look at the asm output? |
| 17:34:50 | | Quit Llorean ("Leaving.") |
| 17:35:13 | funman | gcc -S |
| 17:35:51 | | Quit teru ("Quit") |
| 17:36:04 | n1s | ipod2g: no, it is a bug that has affected several targets, the fix is usually specific to that target or codec driver though |
| 17:36:16 | kugel | \o/ |
| 17:36:20 | kugel | the fuze works now |
| 17:36:27 | kugel | I should probably commit the fixes |
| 17:36:35 | kugel | (no matter of eabi I mean) |
| 17:37:00 | n1s | kugel: scroll_stop works fine for the radio screen |
| 17:37:44 | kugel | nice |
| 17:38:01 | * | n1s has no idea about the wps -> usb problem though, iiuc wps should stop scrolling before usb already |
| 17:38:24 | | Quit pamaury (Read error: 113 (No route to host)) |
| 17:39:22 | n1s | ugh, wps.c is handling events in two places |
| 17:39:30 | n1s | and one of them seems weird |
| 17:39:31 | pixelma | in the USB screen you also get scrolling lines when you enter it from the menu or file browser and there were some scrolling lines |
| 17:40:38 | n1s | hmm, seems like we should set some standard for this, should a screen stop scrollign on exit or on entry? |
| 17:41:03 | kugel | well, I told tomers to use scroll_stop() if possible, but that doesn't work to cleanup list scrolling from within the usb screen |
| 17:41:21 | kugel | n1s: on exit rather |
| 17:41:43 | n1s | kugel: i agree with that, so the lists should stop scrolling on exit |
| 17:42:13 | | Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) |
| 17:42:17 | | Quit ipod2g ("CGI:IRC (EOF)") |
| 17:42:50 | pixelma | kugel: meant to ask you when the WPS is actually parsed - on load (that would mean during boot if you don't chose another theme/WPS) or when entering? |
| 17:43:21 | n1s | I may look at that later, not now though |
| 17:43:38 | kugel | pixelma: the former |
| 17:44:21 | pixelma | during work on a WPS in a simulator it looked like the latter (because only when starting playback I got error messages when parsing failed) |
| 17:45:27 | CIA-5 | New commit by nls (r23633): Fix scrolling lines that keep scrolling after exiting plugins and scrolling lines from the fm screen that keep scrolling in the radio context menu, ... |
| 17:47:52 | pixelma | kugel: and should I report the album art on screens with different pixel format issue - I think someone else could explain the reasons better though... |
| 17:49:43 | | Join dfkt_ [0] (n=dfkt@unaffiliated/dfkt) |
| 17:50:09 | | Join stoffel [0] (n=quassel@p57B4DD15.dip.t-dialin.net) |
| 17:51:33 | | Join robin0800_ [0] (n=quassel@general-ld-216.t-mobile.co.uk) |
| 17:52:31 | | Quit dfkt (Nick collision from services.) |
| 17:52:31 | kugel | pixelma: you can report it, but I don't think we ever officially supported that. I just hoped it would work, maybe it should be deactivated again |
| 17:52:34 | | Nick dfkt_ is now known as dfkt (n=dfkt@unaffiliated/dfkt) |
| 17:53:33 | | Quit stoffel_ (Read error: 145 (Connection timed out)) |
| 17:55:17 | | Quit robin0800 (Read error: 60 (Operation timed out)) |
| 18:00 |
| 18:00:45 | | Join bluebrother [0] (n=dom@f053153190.adsl.alicedsl.de) |
| 18:02:42 | | Quit bluebroth3r (Read error: 60 (Operation timed out)) |
| 18:04:08 | | Quit funman ("free(random());") |
| 18:07:58 | | Join panni_ [0] (i=hannes@ip-95-222-21-143.unitymediagroup.de) |
| 18:13:19 | kkurbjun | hmm, jpeg zooming does not seem to work anymore |
| 18:13:23 | | Join liar_ [0] (n=liar@83.175.83.185) |
| 18:13:24 | | Join mabeco49 [0] (n=mabeco49@189.106.103.10) |
| 18:13:51 | | Quit darkham (Read error: 110 (Connection timed out)) |
| 18:17:13 | kkurbjun | kugel: I'm getting a segfault on the H300 simulator just starting with a fresh cfg and then going into the statusbar menu and selecting custom for the statusbar |
| 18:17:24 | kkurbjun | fresh being an empty cfg |
| 18:18:36 | kugel | I think that's because loaded_ok isn't being checked anymore |
| 18:20:57 | kkurbjun | it may have to do with the multiscreen stuff, it doesn't happen on the gigabeat f |
| 18:22:21 | kkurbjun | that's another thing I wanted to ask about: right now it doesn't look like there is an option for the custom statusbar on remote screens, but the built-in statusbar is being factored out, what is the plan for remotes |
| 18:23:05 | kkurbjun | well |
| 18:23:20 | kkurbjun | actaully, I guess there is a menu item, but how does it work is it an rsbs? |
| 18:23:28 | CIA-5 | New commit by kugel (r23634): Fix a few possible problems discovered in -O0 / eabi experiments. ... |
| 18:24:27 | | Quit feisar- (Remote closed the connection) |
| 18:24:39 | kugel | kkurbjun: yea, .rsbs |
| 18:25:04 | kugel | Unhelpful: sansa ams work now with eabi :> |
| 18:25:08 | kkurbjun | hmm, I'll have to try that - I can set the ui viewport to font 0 or 1 right? |
| 18:25:18 | kugel | yea |
| 18:25:24 | kugel | you don't need an sbs for that though :) |
| 18:25:33 | kugel | the ui viewport also has the font param |
| 18:25:55 | kkurbjun | well, I want the remote to use font 0 and the main screen to use the user selected font |
| 18:26:03 | kkurbjun | oh yeah |
| 18:27:01 | | Join feisar- [0] (n=jljhook@irkki.fi) |
| 18:27:45 | kkurbjun | as a heads up it looks like the H300 sim is failing in skin_display on line 505 when I set the statusbar to custom |
| 18:27:58 | kkurbjun | I'm not sure what should be going on in there though |
| 18:29:10 | kkurbjun | are you going to commit that display fix for the graphical glitches when going into the wps? |
| 18:29:13 | mabeco49 | hi, everybory. i'm a student and am making a job for the class of operating system, in which we must choose a os and give a little information about it. |
| 18:29:37 | kkurbjun | I found another problem when setting the ui viewport - it seems to cause all kinds of glitches when leaving plugins |
| 18:29:45 | | Quit liar (Connection timed out) |
| 18:29:59 | | Quit nawkz (Remote closed the connection) |
| 18:30:26 | kkurbjun | well, the first menu you go into is not using the ui viewport and then when you go into another it starts using the ui viewport, but it leaves a bunch of artifacts |
| 18:30:46 | mabeco49 | i need to kwow what are the scheduler, memory manager, i/o manager and files manager. already downloaded the source but couldn't find qhat i needed. could anyone help me? |
| 18:31:03 | | Join fdinel [0] (n=Miranda@modemcable235.127-131-66.mc.videotron.ca) |
| 18:31:54 | kugel | wth, what is that binsize hit ? |
| 18:32:19 | kugel | kkurbjun: blame JdGordon for that |
| 18:32:24 | kugel | I told him he introduced bugs |
| 18:32:45 | domonoky | mabeco49: you will find the sheduler in firmware/kernel.c, there is probably no memory manager in rockbox (no mmu on most targets).. |
| 18:32:57 | kugel | r23606 |
| 18:33:24 | mabeco49 | domonoky, thanks. |
| 18:34:25 | mabeco49 | domonoky: about the ui, do i find information on the sources either? |
| 18:34:47 | | Join pamaury [0] (n=pamaury@91-168-84-62.rev.libertysurf.net) |
| 18:35:06 | domonoky | mabeco49: sure, everything is in the source :-) But if you have specific questions about it, feel free to ask here .. |
| 18:36:27 | kkurbjun | kugel, the remote custom statusbar is doing something strange |
| 18:36:46 | kkurbjun | I load an rsbs that just has this line: "%Vi|0|0|79|16|0|-|-|" |
| 18:36:49 | * | kugel wonders when all those bugs came in, it all worked fine on the initial commit |
| 18:37:05 | gevaerts | mabeco49: http://www.rockbox.org/wiki/RockboxArchitecture might be helpful. Parts of it are probably outdated though |
| 18:37:19 | kugel | kkurbjun: isn't it a mono remote? mono doesn't have the color parameters |
| 18:37:26 | kkurbjun | and it starts showing the menu for a bit, but when I get to the top-level menu the remote stops showing the menu |
| 18:37:29 | mabeco49 | domonoky: oh, thanks man. i'll go check now! |
| 18:37:41 | kkurbjun | yeah, mono, I'll remove those |
| 18:37:45 | pixelma | kugel: did you really test all those things before? Nothing is bug free... |
| 18:38:02 | kugel | I did test rsbs |
| 18:38:06 | kkurbjun | kugel: I removed that and the behavior is the same |
| 18:38:32 | kkurbjun | it shows the menu with scrolling lines and all till I hit the top level and then it goes blank |
| 18:38:59 | | Quit Jaykay (Read error: 60 (Operation timed out)) |
| 18:39:20 | kkurbjun | if I go back into a sub-level menu it still does not show anything |
| 18:39:21 | | Quit pamaury (Read error: 113 (No route to host)) |
| 18:39:37 | mabeco49 | gevaerts: thanks, man! |
| 18:39:43 | | Join pamaury_ [0] (n=pamaury@91-168-84-62.rev.libertysurf.net) |
| 18:41:13 | kkurbjun | This is the line I am testing with now: "%Vi|0|0|-|-|0|" |
| 18:41:28 | | Nick liar_ is now known as liar (n=liar@83.175.83.185) |
| 18:41:50 | | Quit feisar- (Remote closed the connection) |
| 18:42:25 | mc2739 | kugel: is there a reason you used static volatile int lcd_busy instead of static volatile bool lcd_busy ? |
| 18:43:52 | kkurbjun | kugel: so I was testing that with the MR500 sim, if I take that same rsbs into the H300 sim and loads it it segfaults |
| 18:44:03 | | Quit robin0800_ (Remote closed the connection) |
| 18:44:15 | CIA-5 | New commit by kugel (r23635): Fix crash when selecting statusbar: custom in the menus without having a valid sbs loaded. |
| 18:44:35 | kugel | mc2739: not really, I seem to have forgotten to change it back |
| 18:44:46 | pamaury_ | gevaerts: ping |
| 18:44:47 | kugel | it really doesn't matter though, the resulting code is the same |
| 18:45:15 | gevaerts | pamaury_: gnip |
| 18:45:37 | pixelma | mc2739: thanks for looking over my manual patch (the pictureflow one). About the playback comment for low mem targets - it is possible to start playback from within the plugin but you change into the WPS then and leave the plugin automatically because both doesn't work). Is it possible to express this somehow? |
| 18:45:47 | * | pamaury_ doesn't understand why xchat switched to pamaury_ ! |
| 18:45:59 | pamaury_ | gevaerts: have you ever heard of Microsoft Os Descriptors ? |
| 18:48:50 | | Quit bzed (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | NSplit | lindbohm.freenode.net irc.freenode.net |
| 18:48:50 | | Quit fdinel (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit Lss (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit Zambezi (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit bertrik (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit fyrestorm (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit shai (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit goffa (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit AaronM (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit BlakeJohnson86 (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit linuxguy3 (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit Bob_C (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit yosafbridge (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit togetic (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit freqmod_qu (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit tmzt (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit shodanX (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit ej0rge (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit kkurbjun (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit blithe (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit Tristan (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit jordan`` (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit MethoS- (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit AndyI (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit ThomasAH (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit rjg (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit fxb (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit fish_ (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit markun (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit Overand (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit hatseflats (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit knittl (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit Grahack (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit FOAD (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit Rob2223 (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit HellDragon (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit pixelma (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit alexbobp (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit tha (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit panni_ (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit antil33t (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit Omlet (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit thegeek (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit mc2739 (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit GodEater (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit krazykit (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit droidcore (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit Tuplanolla (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit HBK (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit advcomp2019 (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit ender` (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit Sajber^ (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit rvvs89 (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit dfkt (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit Tomis (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit n1s (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit dmb (lindbohm.freenode.net irc.freenode.net) |
| 18:48:50 | | Quit gtkspert_ (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit grndslm (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit crwl (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit B4gder (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit kadoban_ (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit evilnick (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit Unhelpful (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit jvd (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit lyngaas (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit Kopfgeldjaeger (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit n17ikh (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit pamaury_ (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit liar (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit bmbl (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit elcan (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit JdGordon (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit jfc (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit TheSeven (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit amiconn (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit Kohlrabi (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit scorche (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit sinthetek (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit ps-auxw (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit Zorda (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit domonoky (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit YPSY (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit Zarggg_ (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit seani (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit Res1 (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit Dhraakellian (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit SUSaiyan (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit tchan (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit scorche|sh (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit MaadMan (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit gevaerts (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit Horscht (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit rphillips (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit AlexP (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit at0m (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit niekie (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit kugel (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit efyx_ (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit Rondom (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit Topy (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit linuxstb (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit killan (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit Galois (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit J-23 (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit jasio (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit rasher (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit aevin (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit CIA-5 (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit Hadaka (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit mabeco49 (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit bluebrother (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit stoffel (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit Xerion (lindbohm.freenode.net irc.freenode.net) |
| 18:48:53 | | Quit hillshum (lindbohm.freenode.net irc.freenode.net) |
| 18:48:54 | | Quit topik (lindbohm.freenode.net irc.freenode.net) |
| 18:48:54 | | Quit crashd (lindbohm.freenode.net irc.freenode.net) |
| 18:48:54 | | Quit dionoea (lindbohm.freenode.net irc.freenode.net) |
| 18:48:54 | | Quit chaos (lindbohm.freenode.net irc.freenode.net) |
| 18:48:54 | | Quit jon-kha (lindbohm.freenode.net irc.freenode.net) |
| 18:48:54 | | Quit Torne (lindbohm.freenode.net irc.freenode.net) |
| 18:48:54 | | Quit Slasheri (lindbohm.freenode.net irc.freenode.net) |
| 18:48:54 | | Quit preglow (lindbohm.freenode.net irc.freenode.net) |
| 18:48:54 | | Quit maraz (lindbohm.freenode.net irc.freenode.net) |
| 18:48:54 | | Quit zu (lindbohm.freenode.net irc.freenode.net) |
| 18:48:54 | | Quit ChanServ (lindbohm.freenode.net irc.freenode.net) |
| 18:59:38 | NHeal | lindbohm.freenode.net irc.freenode.net |
| 18:59:38 | NJoin | CIA-5 [0] (n=CIA@208.69.182.149) |
| 18:59:38 | NJoin | Hadaka [0] (n=naked@naked.iki.fi) |
| 18:59:54 | NJoin | rasher [50] (n=rasher@rockbox/developer/rasher) |
| 18:59:54 | NJoin | aevin [0] (i=eivindsy@decibel.pvv.ntnu.no) |
| 19:00 |
| 19:02:18 | | Quit CIA-5 (Killed by sagan.freenode.net (Nick collision)) |
| 19:02:18 | | Join AlexP [0] (n=alex@58.198.66-86.rev.gaoland.net) |
| 19:02:18 | | Join Horscht [0] (n=Horscht2@79.212.250.200) |
| 19:02:18 | NJoin | mabeco49 [0] (n=mabeco49@189.106.103.10) |
| 19:02:18 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
| 19:02:18 | NJoin | stoffel [0] (n=quassel@p57B4DD15.dip.t-dialin.net) |
| 19:02:18 | NJoin | Xerion [0] (i=xerion@82.170.197.160) |
| 19:02:18 | NJoin | hillshum [0] (n=hillshum@75.165.228.82) |
| 19:02:18 | NJoin | topik [0] (i=awesome@213.203.214.114) |
| 19:02:18 | NJoin | crashd [0] (i=foobar@195.62.28.70) |
| 19:02:18 | | Join dionoea [0] (n=dionoea@videolan/developer/dionoea) |
| 19:02:18 | NJoin | chaos [0] (n=chaos@gentoo/user/ch4os) |
| 19:02:18 | NJoin | jon-kha [0] (i=jon-kha@kahvi.eu.org) |
| 19:02:18 | | Join Torne [0] (i=torne@rockbox/developer/Torne) |
| 19:02:18 | NJoin | preglow [0] (i=thomj@129.241.210.199) |
| 19:02:18 | NJoin | zu [0] (n=zu@88.191.93.109) |
| 19:02:18 | NJoin | maraz [0] (i=maraz@xob.kapsi.fi) |
| 19:02:18 | NJoin | Slasheri [0] (i=miipekk@rockbox/developer/Slasheri) |
| 19:02:40 | NJoin | ChanServ [0] (ChanServ@services.) |
| 19:02:40 | NJoin | rjg [0] (i=rgordon@odie.tomelliott.net) |
| 19:02:40 | NJoin | knittl [0] (n=knittl@unaffiliated/knittl) |
| 19:02:40 | NJoin | fxb [0] (n=felixbru@h1252615.stratoserver.net) |
| 19:02:40 | NJoin | fish_ [0] (n=fish@freigeist.org) |
| 19:02:40 | NJoin | Overand [0] (i=overand@crappy.domain.name) |
| 19:02:40 | NJoin | markun [50] (n=markun@rockbox/developer/markun) |
| 19:02:40 | NJoin | kkurbjun [0] (n=kkurbjun@c-98-245-170-51.hsd1.co.comcast.net) |
| 19:02:40 | NJoin | blithe [0] (n=blithe@blakesmith.me) |
| 19:02:40 | NJoin | jordan`` [0] (n=jordan@78.235.252.137) |
| 19:02:40 | NJoin | Tristan [0] (i=tristan@i.dont.want.to.die.virgin.net.in) |
| 19:02:40 | NJoin | ej0rge [0] (n=alhaz@alhaz.fttp.xmission.com) |
| 19:02:40 | NJoin | Sajber^ [0] (n=Sajber@h-65-31.A213.priv.bahnhof.se) |
| 19:02:40 | NJoin | krazykit [0] (n=kkit@76.251.250.122) |
| 19:02:40 | NJoin | evilnick [0] (n=evilnick@ool-4571af51.dyn.optonline.net) |
| 19:02:40 | NJoin | Tuplanolla [0] (n=jani@unaffiliated/tuplanolla) |
| 19:02:40 | NJoin | droidcore [0] (n=mark@69-196-151-127.dsl.teksavvy.com) |
| 19:02:40 | | Join Unhelpful [0] (n=quassel@rockbox/developer/Unhelpful) |
| 19:02:40 | NJoin | HBK [0] (n=hbk@rrcs-97-77-51-170.sw.biz.rr.com) |
| 19:02:40 | NJoin | scorche [50] (n=scorche@rockbox/administrator/scorche) |
| 19:02:40 | | Join jvd [0] (n=syscrash@poipu/developer/syscrash) |
| 19:02:40 | NJoin | lyngaas [0] (n=staale@19.81-167-149.customer.lyse.net) |
| 19:02:40 | NJoin | Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) |
| 19:02:40 | | Join rvvs89 [0] (n=ivo@pdpc/supporter/base/rvvs89) |
| 19:02:40 | NJoin | n17ikh [0] (n=n17ikh@host-69-59-126-212.nctv.com) |
| 19:02:40 | NJoin | sinthetek [0] (n=sinthete@cpe-071-076-249-163.triad.res.rr.com) |
| 19:02:40 | NJoin | advcomp2019 [0] (n=advcomp2@unaffiliated/advcomp2019) |
| 19:02:40 | | Join tchan [0] (n=tchan@lunar-linux/developer/tchan) |
| 19:02:40 | NJoin | SUSaiyan [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) |
| 19:02:40 | NJoin | scorche|sh [50] (n=scorche@rockbox/administrator/scorche) |
| 19:02:40 | NJoin | bzed [0] (n=bzed@devel.recluse.de) |
| 19:02:40 | NJoin | Kohlrabi [0] (n=Kohlrabi@frustrum.nosebud.de) |
| 19:02:40 | NJoin | ThomasAH [0] (n=thomas@aktaia.intevation.org) |
| 19:02:40 | NJoin | tha [0] (i=1038@ccc2.rbg.informatik.tu-darmstadt.de) |
| 19:02:40 | NJoin | shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) |
| 19:02:40 | NJoin | kadoban_ [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) |
| 19:02:40 | NJoin | Dhraakellian [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com) |
| 19:02:40 | NJoin | Res1 [0] (n=Res@user-0c6s6gs.cable.mindspring.com) |
| 19:02:40 | | Join GodEater [0] (n=bibble@rockbox/staff/GodEater) |
| 19:02:40 | | Join B4gder [241] (n=daniel@rockbox/developer/bagder) |
| 19:02:40 | NJoin | tmzt [0] (n=tmzt@adsl-69-208-8-42.dsl.akrnoh.ameritech.net) |
| 19:02:40 | NJoin | freqmod_qu [0] (n=quassel@dhcp208-240.ed.ntnu.no) |
| 19:02:40 | NJoin | alexbobp [0] (n=alex@66.112.249.238) |
| 19:02:40 | NJoin | seani [0] (n=seani@78.33.109.70) |
| 19:02:40 | NJoin | crwl [0] (n=crwlll@a91-156-100-168.elisa-laajakaista.fi) |
| 19:02:40 | NJoin | hatseflats [0] (n=hatsefla@193.200.132.183) |
| 19:02:40 | NJoin | grndslm [0] (n=grndslm@174-126-14-4.cpe.cableone.net) |
| 19:02:40 | NJoin | togetic [0] (n=togetic@unaffiliated/ibuffy) |
| 19:02:40 | Mode | "#rockbox +o ChanServ " by irc.freenode.net |
| 19:02:40 | NJoin | mc2739 [0] (n=mc2739@rockbox/developer/mc2739) |
| 19:02:40 | NJoin | gtkspert_ [0] (n=gtkspert@124-169-252-223.dyn.iinet.net.au) |
| 19:02:40 | NJoin | Zarggg_ [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
| 19:02:40 | NJoin | yosafbridge [0] (n=yosafbri@li14-39.members.linode.com) |
| 19:02:40 | NJoin | Bob_C [0] (n=chatzill@host86-142-212-198.range86-142.btcentralplus.com) |
| 19:02:40 | NJoin | linuxguy3 [0] (n=timj@adsl-75-57-190-229.dsl.emhril.sbcglobal.net) |
| 19:02:40 | NJoin | thegeek [0] (n=nnscript@s168c.studby.ntnu.no) |
| 19:02:40 | NJoin | YPSY [0] (n=ypsy@geekpadawan.de) |
| 19:02:40 | NJoin | amiconn [0] (i=quassel@rockbox/developer/amiconn) |
| 19:02:40 | NJoin | pixelma [0] (i=quassel@rockbox/staff/pixelma) |
| 19:02:40 | NJoin | TheSeven [0] (n=theseven@rockbox/developer/TheSeven) |
| 19:02:40 | NJoin | dmb [0] (n=Dmb@unaffiliated/dmb) |
| 19:02:40 | | Join HellDragon [0] (i=jd@Wikipedia/HellDragon) |
| 19:02:40 | NJoin | AndyI [0] (n=pasha_in@212.14.205.32) |
| 19:02:40 | NJoin | BlakeJohnson86 [0] (n=bjohnson@c-24-118-162-123.hsd1.mn.comcast.net) |
| 19:02:40 | NJoin | AaronM [0] (n=Aaron@adsl-155-218-45.mem.bellsouth.net) |
| 19:02:40 | NJoin | goffa [0] (n=goffa@70.33.8.114) |
| 19:02:40 | NJoin | Rob2223 [0] (n=Miranda@p4FDCC351.dip.t-dialin.net) |
| 19:02:40 | NJoin | JdGordon [0] (n=jonno@rockbox/developer/JdGordon) |
| 19:02:40 | NJoin | shai [0] (n=Shai@l192-117-110-233.cable.actcom.net.il) |
| 19:02:40 | NJoin | elcan [0] (i=user36@pr0.us) |
| 19:02:40 | NJoin | bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 19:02:40 | NJoin | ender` [0] (i=krneki@foo.eternallybored.org) |
| 19:02:40 | NJoin | fyrestorm [0] (n=nnscript@cpe-69-203-150-85.si.res.rr.com) |
| 19:02:40 | NJoin | Omlet [0] (i=omlet05@38.145-241-81.adsl-dyn.isp.belgacom.be) |
| 19:02:40 | NJoin | bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 19:02:40 | NJoin | domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 19:02:40 | NJoin | ps-auxw [0] (n=arneb@dyn37.ps-auxw.de) |
| 19:02:40 | NJoin | FOAD [0] (n=dok@dinah.blub.net) |
| 19:02:40 | NJoin | Zambezi [0] (i=Zulu@80.67.9.2) |
| 19:02:40 | NJoin | antil33t [0] (n=Mudkips@203-184-54-232.callplus.net.nz) |
| 19:02:40 | NJoin | n1s [0] (n=n1s@rockbox/developer/n1s) |
| 19:02:40 | NJoin | Lss [0] (n=Lss@cm46.delta91.maxonline.com.sg) |
| 19:02:40 | NJoin | MethoS- [0] (n=clemens@134.102.106.250) |
| 19:02:40 | NJoin | Zorda [0] (n=hi@c-71-62-228-21.hsd1.va.comcast.net) |
| 19:02:40 | NJoin | Tomis [0] (n=Tomis@70.134.71.157) |
| 19:02:40 | NJoin | Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) |
| 19:02:40 | NJoin | dfkt [0] (n=dfkt@unaffiliated/dfkt) |
| 19:02:40 | NJoin | panni_ [0] (i=hannes@ip-95-222-21-143.unitymediagroup.de) |
| 19:02:40 | NJoin | liar [0] (n=liar@83.175.83.185) |
| 19:02:40 | NJoin | fdinel [0] (n=Miranda@modemcable235.127-131-66.mc.videotron.ca) |
| 19:02:40 | | Join pamaury [0] (n=pamaury@91-168-84-62.rev.libertysurf.net) |
| 19:02:40 | | Join Maad_Man [0] (n=MaadMan@188-192-221-19-dynip.superkabel.de) |
| 19:02:40 | | Join Guest78705 [0] (n=fg@rockbox/developer/gevaerts) |
| 19:02:40 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 19:02:40 | NJoin | rphillips [0] (n=rphillip@66-90-184-91.dyn.grandenetworks.net) |
| 19:02:40 | | Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) |
| 19:02:41 | | Quit Hadaka (Connection reset by peer) |
| 19:02:49 | | Nick Guest78705 is now known as gevaerts (n=fg@rockbox/developer/gevaerts) |
| 19:02:49 | | Join CIA-80 [0] (n=CIA@208.69.182.149) |
| 19:02:51 | gevaerts | and no, I don't really like fallbacks to drivers, but if that's the best way to do it, I don't see many other options |
| 19:03:11 | | Nick AlexP is now known as Guest54595 (n=alex@58.198.66-86.rev.gaoland.net) |
| 19:03:15 | | Join Hadaka [0] (n=naked@naked.iki.fi) |
| 19:03:15 | NJoin | at0m [0] (n=at0m@94-225-90-23.access.telenet.be) |
| 19:03:15 | NJoin | efyx_ [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 19:03:15 | NJoin | Rondom [0] (n=Rondom@dslb-084-057-184-209.pools.arcor-ip.net) |
| 19:03:15 | NJoin | Topy [0] (n=Topy44@f049044018.adsl.alicedsl.de) |
| 19:03:15 | NJoin | linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 19:03:15 | NJoin | killan [0] (n=nnscript@c-94fc70d5.06-397-67626721.cust.bredbandsbolaget.se) |
| 19:03:15 | NJoin | Galois [0] (i=djao@efnet.math.uwaterloo.ca) |
| 19:03:15 | NJoin | J-23 [0] (n=zelazko@unix.net.pl) |
| 19:03:15 | NJoin | jasio [0] (n=yann@cpc2-rdng20-2-0-cust902.15-3.cable.virginmedia.com) |
| 19:03:18 | pamaury | There is a request call GET_MS_DESCRIPTOR, request_type=0xC0 |
| 19:03:23 | * | pamaury checking usb doc... |
| 19:05:20 | CIA-80 | New commit by kugel (r23636): Consolidate some #ifdef code. |
| 19:05:25 | pixelma | and seeing a mixture of lists and WPS like this http://imagebin.org/71143 is just bah (getting worse with parts of pictureflow underneath) |
| 19:05:25 | pamaury | It's a vendor-specific, device request |
| 19:05:46 | pamaury | Which means the request is forwared to the driver if I'm correct. |
| 19:06:27 | gevaerts | if it's device, usb_core normally handles it |
| 19:06:34 | kugel | pixelma: is that a wps with peakmeter? |
| 19:06:43 | pixelma | no |
| 19:06:48 | pamaury | Doesn't usb_core forwards to driver if the request is vendor-specific ? |
| 19:07:08 | kugel | drawing the wps is superfast on my fuze |
| 19:07:26 | gevaerts | it forwards if the request is for an interface or an endpoint |
| 19:07:44 | pamaury | Yes you're right, I just checked |
| 19:07:59 | pamaury | This behaviour can be changed |
| 19:08:01 | pamaury | no ? |
| 19:08:13 | kugel | pixelma: does this patch make it any better ? http://pastie.org/699847 |
| 19:08:14 | gevaerts | anything can be changed |
| 19:08:15 | gevaerts | Nor |
| 19:08:24 | pamaury | Is there any reason not to do it for device request ? |
| 19:08:33 | gevaerts | which driver should get it? |
| 19:08:58 | pixelma | mc2739: ok, I was wrong. I thought you could actually select the track it should play but that doesn't seem to work (or maybe it is broken in the mean time), you can only go to the WPS. And then you are right with the playlist position |
| 19:09:08 | gevaerts | Device requests are normally things like SET_ADDRESS or GET_DESCRIPTOR, i.e. not function dependent at all |
| 19:09:14 | * | gevaerts has to go for a bit |
| 19:09:17 | pamaury | ah.... that's a clever remark |
| 19:09:28 | pixelma | kugel: I'll try |
| 19:09:28 | kugel | pixelma: that was never supposed to work, only in random_folder_advance |
| 19:10:02 | * | pamaury hates Microsoft descriptors just two hours after discovering them |
| 19:10:30 | | Quit Guest54595 (Client Quit) |
| 19:10:50 | NJoin | AlexP [0] (n=alex@rockbox/staff/AlexP) |
| 19:11:23 | pamaury | gevaerts: wait, in their stupidity, they had a clever idea: it's a device request but the wValue contains the interface number ! |
| 19:12:24 | pixelma | mc2739: ok, I think that can all be addressed in a later patch |
| 19:15:30 | *** | Saving seen data "./dancer.seen" |
| 19:17:35 | NJoin | jfc [0] (n=john@dpc6682208002.direcpc.com) |
| 19:19:24 | kkurbjun | kugel: the theme is here: http://themes.rockbox.org/index.php?target=mrobe500 |
| 19:26:35 | kkurbjun | kugel, strange - I am not able to reproduce the remote screen display disappearing now after re-loading the theme |
| 19:27:12 | kkurbjun | If it comes up again I'll save my cfg file |
| 19:27:43 | kkurbjun | It is really cool that you can use a different ui font between the main and remote screen |
| 19:29:26 | mc2739 | pixelma: if you commit FS #10712, I noticed a typo after uploading my latest patch - on line 9, "-play" should be just "play" |
| 19:30:17 | | Quit Rob2223 () |
| 19:31:09 | kugel | kkurbjun: yea, but only if you don't need chars that are not in iso8859-1 |
| 19:33:36 | | Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) |
| 19:37:23 | | Join Rob2222 [0] (n=Miranda@p4FDCC351.dip.t-dialin.net) |
| 19:46:31 | pixelma | kugel: worse with that patch (although I would still have to try without the patch and the same revision), Rockbox freezes in this half loaded state and if I interrupt that, I get the error message: I09: CPUAdrEr at 09010F14 - enabled "Catch mem accesses" in the debug menu gives me a slightly different error message: I0C: UserBrk at 09019016 |
| 19:46:34 | gevaerts | pamaury: ok, so we can look for 0xc0 in core, and then dispatch to the right driver? |
| 19:47:14 | pamaury | Yes but there is a problem |
| 19:48:06 | pamaury | (first, 0xC0 is only the request type, the request code can be set to any value which is report in the string descriptor, ugly !) |
| 19:48:38 | pamaury | First of all, the GET_MS_DESCRIPTOR can an interface value but it's not mandatory |
| 19:48:43 | pamaury | *can take |
| 19:50:50 | pamaury | But there is something good: the get extended compat ids (one of the two sub request to implement) returns a list of ids which can be associated to interfaces. So if I'm correct, we could implement some logic in usb_core which would then dispatch to drivers and gather aggregate everything. |
| 19:51:14 | kugel | pixelma: sounds very strange |
| 19:51:16 | gevaerts | ok |
| 19:51:41 | kugel | what revisison are you testing on? |
| 19:51:42 | pamaury | Then there is a get extended properties which is normaly purely interface related and can be routed to a driver |
| 19:51:45 | Ctcp | Version from freenode-connect!freenode@freenode/bot/connect |
| 19:52:17 | pamaury | BUT I checked libmtp code and this is not really implemented properly. On the other hand, the code is robust enough to work with only the first part |
| 19:52:24 | pixelma | kugel: 23636 |
| 19:52:51 | pixelma | backlight mod build (but that shouldn't have an influence) |
| 19:53:06 | gevaerts | How likely is it that we'll ever want other drivers that need this GET_MS_DESCRIPTOR? If it's not likely at all, just add a field to struct usb_class_driver, leave it NULL for all drivers except MTP, and just dispatch the control handling to the first driver that implements it |
| 19:53:25 | * | kugel doesn't see how this patch causes such problems |
| 19:54:54 | kugel | what the heck, I can't close tasks anymore? |
| 19:54:54 | pamaury | Yes I agree. Furthermore, Microsoft OS Descriptors define only a few kinds of descriptors: MTP, PTP, RNDIS,XUSB20 and BLUTUTH |
| 19:55:05 | pamaury | So forwarding is probably simpler |
| 19:55:41 | kugel | blututh? |
| 19:55:50 | pamaury | (http://www.microsoft.com/whdc/connect/usb/os_desc.mspx) |
| 19:56:08 | | Quit stoffel (Read error: 145 (Connection timed out)) |
| 19:56:24 | pixelma | kugel: seems to happen without that patch and the same revision too :\ so something had been broken between r 23598 and 23636 |
| 19:56:27 | pamaury | And this would avoid many problems if those descriptors are not implemented on the OS side (most will probably expect only one interface) |
| 19:58:14 | * | gevaerts doesn't understand all details yet |
| 19:58:20 | pamaury | gevaerts: perhaps you could have a look at it (http://www.microsoft.com/whdc/connect/usb/os_desc.mspx), read this spec and check that I'm not saying incorrect things. |
| 19:59:04 | pamaury | I don't have a full understanding of it yet but those descriptors really seem overkill to me |
| 20:00 |
| 20:02:15 | pamaury | And there really are necessary because Windows XP need them to correctly detect a MTP device. Windows Vista and Windows Seven (theorically) can only detect them based on the USB PTP class but I don't want to test that. I don't know how MacOS works but the only time I tested it, my device was reported as a PTP device so those descriptors are also probably needed |
| 20:03:09 | | Join Tomis2 [0] (n=Tomis@70.134.101.204) |
| 20:03:48 | * | pamaury has to go otherwise he will die of starvation |
| 20:03:57 | gevaerts | I'll try to have a more detailed look later, but if they are needed to make things work, there's not much else to do |
| 20:04:01 | * | gevaerts has to go too |
| 20:07:52 | | Join stoffel [0] (n=quassel@p57B4EF5D.dip.t-dialin.net) |
| 20:11:10 | | Quit stoffel (Read error: 131 (Connection reset by peer)) |
| 20:11:56 | Dhraakellian | just out of curiosity, does Rockbox support Ogg FLAC in addition to the standard FLAC in its own container? |
| 20:12:28 | pixelma | kugel: your peakmeter commit broke it |
| 20:13:41 | Torne | Dhraakellian: yes |
| 20:13:57 | pixelma | r23624 works, 23625 doesn't (the UserBrk address was in wps.c and so I suspected that) |
| 20:14:06 | pixelma | Torne: really? |
| 20:14:24 | kugel | o.O |
| 20:14:59 | gevaerts | Torne, Dhraakellian: not as far as I understand |
| 20:15:04 | Torne | doesn't it? |
| 20:15:07 | Torne | ogg.c looks like it |
| 20:15:15 | * | gevaerts might be wrong |
| 20:15:23 | kugel | ondio, I assume? |
| 20:15:29 | AlexP | I didn't think it did |
| 20:15:41 | Torne | maybe not then :) |
| 20:15:52 | Torne | surely we should though |
| 20:15:58 | AlexP | Would be a nice surprise for us all if it did :) |
| 20:16:06 | | Quit Tomis (Read error: 104 (Connection reset by peer)) |
| 20:16:06 | | Nick Tomis2 is now known as Tomis (n=Tomis@70.134.101.204) |
| 20:16:18 | n1s | Torne: no, we don't support ogg flac |
| 20:16:35 | Torne | oh |
| 20:16:41 | * | kugel is surprised how such a relatively undangerous change can cause such problems |
| 20:16:44 | Torne | sorry then, Dhraakellian |
| 20:16:47 | Torne | :) |
| 20:17:12 | Dhraakellian | Torne: no skin off my back. I'm just asking so I know how to answer a reply to a blog comment I made somewhere |
| 20:17:16 | Dhraakellian | oslt |
| 20:17:36 | n1s | we've even had bug reports about "ogg files" that don't work that were in fact ogg flac |
| 20:17:59 | n1s | and btw, Ogg FLAC is stupid :) |
| 20:17:59 | Torne | surely it wouldn't be that difficult |
| 20:18:02 | kugel | pixelma: can I have your config.cfg? it seems to work on the sim |
| 20:18:05 | Dhraakellian | n1s: so I've heard |
| 20:18:15 | pamaury | It's a strange thing to have flac embedded in ogg |
| 20:18:45 | pixelma | kugel: I somehow doubt that the sim will be telling much |
| 20:19:02 | | Join mtc [0] (n=mtc@fsf/member/mtc) |
| 20:19:14 | kugel | rockbox.elf + mapfile maybe? |
| 20:21:46 | Dhraakellian | does Rockbox do speex in Qgg, or does it have its own container too? |
| 20:22:01 | kugel | Unhelpful: gcc 4.4.3 compiles flawlessly, maybe it's worth digging svn log to find what fixed the compilation problems on 4.4.2? |
| 20:22:18 | kugel | or we wait ~2 month for .3 being released |
| 20:23:17 | | Join domonoky1 [0] (n=Domonoky@g229147134.adsl.alicedsl.de) |
| 20:26:29 | | Quit mabeco49 ("Saindo") |
| 20:27:46 | | Quit domonoky (Read error: 60 (Operation timed out)) |
| 20:28:37 | kugel | pixelma: ? |
| 20:29:19 | | Join Omlet05 [0] (i=omlet05@91.181.236.15) |
| 20:32:18 | n1s | Dhraakellian: yeah we do ogg speex afaik |
| 20:34:23 | pixelma | kugel: yes? |
| 20:34:29 | kugel | pixelma: can you give me the rockbox.elf and .map? |
| 20:34:57 | pixelma | yes, how can I send those files to you? |
| 20:36:13 | | Join dfkt_ [0] (i=dfkt@unaffiliated/dfkt) |
| 20:36:37 | kugel | email would work |
| 20:39:25 | pixelma | ok |
| 20:39:51 | pixelma | kugel: same address as in the ml? |
| 20:39:52 | kugel | yep |
| 20:42:10 | kugel | pixelma: showing the wps is fast on the ondio sim too. was that screenshot made on the target? |
| 20:42:12 | mtc | so rockbox supports speex encoding... does it support speex-in-ogg or flac-in-ogg formats? |
| 20:42:36 | pixelma | kugel: yes, and sure it's a sim not an emulator and your computer's CPU is way different from the SH one, and disk access works different too etc. etc ... |
| 20:42:49 | kugel | I know that |
| 20:45:52 | | Quit Omlet (Success) |
| 20:46:17 | * | kugel remembers that displaying the wps used to take way longer some month ago |
| 20:48:21 | pixelma | my impression is different |
| 20:48:35 | kugel | let's see if I can read sh assembly :p |
| 20:49:42 | pixelma | it became slower at some point during some UI work and stayed that way (it feels worse but I don't have numbers) |
| 20:50:27 | Unhelpful | kugel: it might be worth checking. or maybe worth waiting. if we switch i expect we'll be stuck with that version for a few years, so we'd best be sure ;) |
| 20:51:21 | kugel | getting & compiling gcc from svn is a considerable pain, btw |
| 20:51:41 | kugel | pixelma: same addresses as you mentioned above? |
| 20:52:09 | Unhelpful | kugel: there are no snapshot tarballs? |
| 20:52:35 | kugel | I didn't look |
| 20:52:47 | kugel | maybe from trunk, but I wanted the 4.4 branch |
| 20:53:07 | n1s | trunk has snapshots made every friday iirc |
| 20:53:40 | Unhelpful | also we might want to wait for a 2.20 binutils release, or try going back to 2.19 - as near as i can tell they update the snapshot tarball without (always) changing the filename. |
| 20:53:49 | kugel | 2.20 is released |
| 20:53:58 | kugel | 4 weeks ago |
| 20:54:38 | kugel | 2.19 (.1 even IIRC) didn't work at all |
| 20:54:44 | n1s | seems active branshes have snapshots too, see ftp://ftp.gwdg.de/pub/misc/gcc/snapshots/ for example |
| 20:55:04 | Unhelpful | it didn't? i remember 2.19 snapshot working except for the section offset issue |
| 20:55:29 | kugel | it didn't compile without changes, and half of the codecs didn't work IIRC |
| 20:55:33 | pixelma | kugel: no, I forgot. There's a slight difference: the CPUAdrEr is at 09010F08 and the UserBrk at 0901901A (with "catch mem accesses" > "Zero area (all)" enabled) |
| 20:55:49 | kugel | anyway, we don't need to worry since 2.20 is out since a while |
| 20:56:57 | kugel | pixelma: the first one seems to be in browse_cuesheet. are you using a cuesheet? |
| 20:57:40 | kugel | wps.c is far later |
| 20:58:20 | kugel | n1s: meh, I didn't know that |
| 20:58:30 | | Quit dfkt (Read error: 110 (Connection timed out)) |
| 20:59:41 | kugel | Unhelpful: any idea how that changes in r23634 cause the binsize hit on all arm targets? |
| 20:59:54 | JdGordon | n1s: you pinged yesterday? |
| 21:00 |
| 21:00:00 | kugel | did the syntax correction make optimizing impossible somehow? |
| 21:01:42 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 21:01:42 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 21:01:42 | kugel | pixelma: the latter address isn't 4 byte aligned. that might cause a problem, but I really can't see how my change could cause that |
| 21:01:42 | | Join mikroflops [0] (n=yogurt@90-224-27-247-no112.tbcn.telia.com) |
| 21:01:56 | pixelma | kugel: no, cuesheet support is even turned off - and the early USB crash (that was fixed then) was interestingly in cuesheet something too |
| 21:02:43 | JdGordon | there is a cuesheet check whihc sort of happens even if cueshet is disabled |
| 21:02:57 | JdGordon | the actual problem there is probaly a null pointer reference |
| 21:03:41 | n1s | JdGordon: it was about my patch for fs#10616 but kugel answered the question, more similar bugs remain though |
| 21:03:43 | kugel | I assume 09010F08 is the instruction that tries to access 0901901A, then things go wild |
| 21:04:08 | | Join FlynDice [0] (n=FlynDice@206.82.218.140) |
| 21:04:34 | pixelma | I think that's what the "Catch mem accesses" does - catching null pointers. Unfortunately I don't remember the details :/ |
| 21:05:01 | JdGordon | early usb is still borken? |
| 21:06:07 | pixelma | no, going to the WPS |
| 21:06:32 | pixelma | is broken now since r23625 |
| 21:06:37 | | Quit GeekShadow ("The cake is a lie !") |
| 21:06:41 | | Join CaptainKewl [0] (i=jds@207-237-172-77.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) |
| 21:06:55 | pixelma | on the Ondio at least |
| 21:07:05 | kugel | the crash is in cue_find_current_track which indeed derefences a pointer without checking for NULL |
| 21:07:33 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
| 21:08:13 | JdGordon | it shouldnt be getting there |
| 21:08:27 | JdGordon | cuesheet_subtrack_changed is NULL-ref protected |
| 21:08:32 | | Quit phanboy4 (Read error: 104 (Connection reset by peer)) |
| 21:08:43 | kugel | ah, there we have browse_cuesheet |
| 21:08:53 | | Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) |
| 21:09:10 | JdGordon | which isnt called by the wps |
| 21:09:19 | | Quit dfkt_ (Nick collision from services.) |
| 21:11:10 | | Quit FlynDice (Remote closed the connection) |
| 21:13:48 | kugel | pixelma: can I have your config.cfg too? |
| 21:15:13 | kugel | i don't think it's NULL pointer derefence |
| 21:15:27 | kugel | the fault address seems to be 0901901A |
| 21:15:33 | *** | Saving seen data "./dancer.seen" |
| 21:15:35 | | Join FlynDice [0] (n=FlynDice@206.82.218.140) |
| 21:17:10 | kugel | which is code in play_hop() |
| 21:17:51 | kugel | maybe it's a race condition between playback and main thread |
| 21:18:09 | kugel | since my yesterdays change, the audio thread doesn't run between entering and displaying the wps |
| 21:20:38 | kugel | (which may take a while on a slow sh target) |
| 21:23:17 | JdGordon | TIMEOUT_NOBLOCK is causing the audio thread to not start? |
| 21:24:00 | kugel | pixelma: I assume this works around http://pastie.org/700026 |
| 21:24:59 | kugel | TIMEOUT_NOBLOCK causes action.c to call button_get(false) instead of button_get_w_tmo() |
| 21:25:08 | pixelma | kugel: sure, just tried if it happens with any WPS and it does. What's "funny" is that it's not completely frozen - I can still adjust volume, and it only crashes when I press "Right" (skip), "Left" does nothing and going back to the menu works and then entering the WPS again works correctly then... |
| 21:26:08 | pixelma | seems to freeze (ID3 data isn't loaded and playback doesn't start) on entering that WPS a first time |
| 21:26:53 | pixelma | I'll try that patch though |
| 21:29:45 | pixelma | and the "classic" WPS is a bit broken because it uses pure %pb and the progressbar doesn't show... |
| 21:30:03 | kugel | didn't JdGordon fix that? |
| 21:30:05 | | Join obo [0] (n=obo@77-99-230-49.cable.ubr04.trow.blueyonder.co.uk) |
| 21:30:17 | | Part obo ("Bye") |
| 21:30:19 | | Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) |
| 21:31:32 | kugel | pixelma: can you try starting playback without going to the wps immediately (e.g. by use insert in the context menu of a music file)? if you then enter the wps it should show fine |
| 21:32:30 | kugel | I changed to TIMEOUT_NOBLOCK because the peeakmeter code does that also, so I didn't worry about it |
| 21:33:04 | JdGordon | does anyone want to comment on the classic_statusbar.sbs in svn? I really want to commit the old bar removal today |
| 21:33:04 | pixelma | yes, that works |
| 21:33:25 | JdGordon | pixelma: yeah, I thought I fixed %pb? |
| 21:33:54 | kugel | JdGordon: btw, I easily spot the problems r23606 caused |
| 21:34:15 | kugel | pixelma: what works? the patch or starting playback without wps ? |
| 21:34:25 | pixelma | which revision (am at 23625 since testing )? |
| 21:34:36 | JdGordon | good.. so fix it properly by passing the viewport arround |
| 21:34:41 | pixelma | kugel: starting playback without WPS |
| 21:34:53 | pixelma | testing your patch now |
| 21:34:56 | JdGordon | tomers: hi, did you se my comment for the rtl tag patch? |
| 21:35:00 | kugel | that proves my assumption |
| 21:35:21 | kugel | the real problem is why that causes badness, but I don't feel like investigating that |
| 21:35:36 | JdGordon | thats a really silly thing to say |
| 21:35:43 | JdGordon | and leads to shit code |
| 21:36:52 | pixelma | that patch helps |
| 21:37:27 | pixelma | I still find changing to the WPS takes too long and looks bah ;) |
| 21:38:00 | pixelma | I almost thought the patch didn't fix the freeze... |
| 21:39:09 | JdGordon | its probably because the first full redraw is all the way at the end of the main loop... so it takes a noticable amount of time to get there |
| 21:40:12 | pixelma | kugel: can I test your first patch on top of this one now (which was the more important of course) |
| 21:40:13 | JdGordon | on the first loop it even does a partial redraw followed bu a full redraw |
| 21:40:30 | kugel | pixelma: yep, I was about to ask you that anyway :) |
| 21:40:59 | kugel | JdGordon: there's only the (huge) switch in between. |
| 21:41:30 | kugel | that shouldn't be entered actually, and even if, the individual cases are relatively small |
| 21:41:43 | kugel | but the skin engine is quite a bummer for sh it seems |
| 21:42:01 | JdGordon | ? |
| 21:42:27 | JdGordon | sh doesnt like linked lists or something? |
| 21:43:27 | pixelma | entering the WPS seemed slow for some time already, it's just now that you see everything non ID3 info drawn over the list that it looks very weird |
| 21:43:46 | | Quit funman ("free(random());") |
| 21:45:52 | CIA-80 | New commit by kugel (r23637): Partly revert r23625 (the TIMEOUT_NOBLOCK change), and add a comment explaining why (or trying to, at least). |
| 21:45:53 | * | JdGordon has the crazy idea that the displayer should go through the skin backwards for rtl skins :D |
| 21:46:29 | Unhelpful | kugel: that's not just a syntax change, i and r constraints are fundamentally different. replacing an i constraint with an r constraint means an extra instruction to load the value into a register. and since it's code that's inlined... |
| 21:47:22 | kugel | Unhelpful: -O0 exposed errors in that 3 functions |
| 21:47:49 | Unhelpful | errors of what sort? did you look at the asm? |
| 21:48:21 | kugel | it's inline assembly, why should I look at the generated code? |
| 21:48:59 | kugel | constraint exceeded or so, I don't remember |
| 21:49:03 | | Quit tomers (Connection reset by peer) |
| 21:49:34 | | Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) |
| 21:50:16 | Unhelpful | do you know where the call was that tripped it? |
| 21:50:36 | kugel | kernel.c |
| 21:50:55 | Unhelpful | one thing you could do is test for the constancy of mask, and branch to two different asm versions |
| 21:51:32 | kugel | what is the difference between i and r? |
| 21:51:54 | pixelma | kugel: the first patch doesn't seem to do much (maybe a tiny tiny bit) but hard to measure (both take between 6 and 7 seconds from pressing "resume" to actual playback. Everything non-ID3 of my WPS shows up quite quickly but drawn over the list, lines which should display ID3 info are filled with the fallback things from the WPS. Actual playback start (I hear something) and info from the tags displaying seems to happen at the same time. |
| 21:52:16 | kugel | 6 - 7 seconds ??? |
| 21:52:19 | tomers | Hi there. I've just posted update to "FS #10783 - WPS translation". It was reviewed by others and been fixed accordingly. Do you think I should wait until tomorrow, or can I post it tonight? |
| 21:52:42 | Unhelpful | i is an immediate value. it must be compile-time constant, because it's encoded into the instruction, and it must not (on arm) have set bits that cover a span of more than 8 bits. immediates on arm must be a rotated byte. |
| 21:54:01 | pixelma | has something changed with regards to loading ID3 info and maybe the first buffering (and playback starting during that). kugel: yes :( (measured with the stopwatch plugin on my c200, manually though) and now you can imagine how stupid looking at that mixed up screen looks |
| 21:54:12 | pixelma | s/looks/is |
| 21:54:52 | | Quit AlexP ("Please insert girder") |
| 21:54:55 | Unhelpful | given that -O0 broke it, i would bet that -O0 made the mask value non-constant |
| 21:55:03 | kugel | that patch should at least make the list go away rather quickly |
| 21:55:04 | | Join AlexP [0] (n=alex@rockbox/staff/AlexP) |
| 21:55:38 | pixelma | it doesn't |
| 21:55:43 | kugel | Unhelpful: O0 also broke something which is a constant in debug_menu.c |
| 21:56:57 | kugel | 6-7s is so slow, I suspect that the storage transfers delay it |
| 21:57:13 | pixelma | kugel: ok, it does but you still see that mashup for very long |
| 21:57:35 | kugel | Unhelpful: line 1621 and following |
| 21:57:54 | | Quit phanboy4 (Read error: 54 (Connection reset by peer)) |
| 21:58:15 | | Join phanboy4 [0] (n=benji@c-24-98-43-198.hsd1.ga.comcast.net) |
| 21:58:25 | * | domonoky1 still doesnt understand why we want to compile rockbox with eabi, if it causes such problems.. |
| 21:58:49 | Torne | eabi has linkage features that don't work in oabi |
| 21:58:53 | kugel | pixelma: you could insert a splash after "send_event(GUI_EVENT_REFRESH, gwps_enter_wps);" in wps.c to see how long the initial update really takes |
| 21:58:55 | Torne | because it's actually sensibly designed :) |
| 21:59:33 | kugel | domonoky1: -60k binsize on non-mmu targets, mostly :) |
| 22:00 |
| 22:00:27 | domonoky1 | kugel: oki, thats a argument i can understand :-) |
| 22:00:59 | Unhelpful | kugel: doesn't -O0 also disable inlining? if that function is *ever* left standalone instead of inlined it *will* fail to compile, as obviously mask can't be constant as a true parameter. |
| 22:01:27 | Unhelpful | try making it always_inline instead of changing the constraint, maybe |
| 22:01:37 | kugel | it did in mci_delay() case |
| 22:02:24 | * | domonoky1 suspects that there are many more places which use delays like this, and fears hidden bugs everywhere. |
| 22:03:33 | * | kugel thinks that expecting compile time constants as parameters for a function (even if it's inline) is questionable |
| 22:03:55 | | Join stoffel [0] (n=quassel@p57B4EF5D.dip.t-dialin.net) |
| 22:05:21 | Unhelpful | kugel: then make it a macro. or use a test for constancy and branch between versions with i and r constraints, but that could fail too if the dead branch isn't eliminated. |
| 22:05:31 | pixelma | kugel: didn't you change something about tag info loading in preparation of custom statusbar that could have an influence on the loading times there? |
| 22:06:31 | TheSeven | gevaerts: ping |
| 22:07:09 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 22:07:26 | | Quit stripwax (Client Quit) |
| 22:07:40 | Unhelpful | but for what it does, expecting a constant parameter is perfectly reasonable. if you were writing this in asm at each callsite you'd be using an immediate. :P |
| 22:09:17 | kugel | btw, what's the point of that temp register? |
| 22:09:22 | kugel | why not just use r12? |
| 22:10:11 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 22:10:32 | kugel | "error: impossible constraint in ‘asm’" is the error, btw |
| 22:11:20 | kugel | __attribute__((always_inline)); doesn't seem to help |
| 22:12:33 | gevaerts | TheSeven: gnip |
| 22:12:55 | kugel | rockbox doesn't know __gnu_inline__ ? |
| 22:13:08 | TheSeven | gevaerts: as you may have heard, liar has some usb trouble on his nano2g |
| 22:13:44 | gevaerts | vaguely, yes |
| 22:13:48 | | Join niekie [0] (i=quasselc@dreamworld.bergnetworks.com) |
| 22:13:53 | TheSeven | he just found out that commenting the send and receive call in the standard USB_REQ_GET_STATUS handler seems to fix it |
| 22:14:06 | TheSeven | any idea what could be going on there? |
| 22:14:18 | | Part mtc |
| 22:14:45 | kugel | TheSeven: did you see his nand fix? |
| 22:15:01 | liar | kugel: that may be not the correct solution |
| 22:15:05 | TheSeven | kugel: I think this turned out to be a semi-fix again? |
| 22:15:25 | kugel | waiting for the fifo? that seems proper to me |
| 22:15:27 | TheSeven | gevaerts: if the send or receive (or both) are not commented, the whole device seems to lock up in a weird state where not even the timer int is running any more, but it doesn't seem to be inside an int handler either |
| 22:15:48 | TheSeven | any idea what could be special about that get status request (which doesn't seem to hurt if we just ignore it) |
| 22:16:18 | liar | kugel: but its locking up sometimes too(but only after unclean shutdowns) |
| 22:16:30 | TheSeven | aha? interesting fact. |
| 22:16:47 | liar | yep |
| 22:17:28 | gevaerts | which USB_REQ_GET_STATUS is it? device, interface, or endpoint? |
| 22:17:56 | liar | gevaerts: the one in request_handler_interface_standard |
| 22:18:13 | gevaerts | ok, so interface |
| 22:18:32 | gevaerts | weird |
| 22:18:45 | * | gevaerts wonders why a host would even call that |
| 22:19:19 | | Join Strife89 [0] (n=Strife89@adsl-81-160-3.mcn.bellsouth.net) |
| 22:19:31 | gevaerts | for interface, *all* bits in the response are reserved and zero, so this is a zero-information request |
| 22:20:48 | * | TheSeven isn't even sure that it is called at all |
| 22:21:00 | TheSeven | something running away would explain that behavior far better |
| 22:21:25 | | Quit AaronM ("Emo Time In My Corner... //_-") |
| 22:22:02 | TheSeven | either someone's accidentally jumping there, or someone's trashing some variables |
| 22:22:32 | TheSeven | but how could such a kind of bug only appear on certain devices? (all devices liar has touched :-P ) |
| 22:22:41 | liar | lol |
| 22:22:52 | gevaerts | liar: what OS are you running? |
| 22:23:13 | liar | ubuntu 9.10, but it also happens on 9.04 and windows xp |
| 22:23:39 | liar | TheSeven: it doesnt work on __grants ipod too and i have never touched it :-P |
| 22:24:49 | * | TheSeven thinks of doing some post-mortem debug on a core dump of that |
| 22:25:16 | TheSeven | now that we know where it's running along, we may be able to fire up an ibugger stub from that place |
| 22:25:36 | gevaerts | the fact that commenting out the usb transfers has no ill effects seems to confirm that there's no real GET_STATUS request. I'd expect a bus reset if the host actually did send one |
| 22:26:14 | TheSeven | it would probably reset the bus and continue to do other things, recognizing that that request doesn't work |
| 22:26:20 | TheSeven | we probably wouldn't notice that |
| 22:26:27 | Unhelpful | kugel: then it's being inlined in a case where the value is non-constant, or is not constructable as an immediate. you need to look at the callsite and see. |
| 22:26:33 | gevaerts | you'd notice the bus reset in dmesg |
| 22:26:39 | | Quit Grahack ("Leaving.") |
| 22:26:49 | gevaerts | GET_STATUS is not something optional |
| 22:27:16 | TheSeven | gevaerts: you know how these drivers are written |
| 22:27:25 | TheSeven | "don't trust anyone or we may fail somewhere" |
| 22:27:37 | TheSeven | there's shitloads of broken usb devices on the market |
| 22:27:37 | kugel | Unhelpful: it seems to be not inlined, the error appears as soon as the header included |
| 22:28:18 | kugel | the question is why always_inline doesn't work |
| 22:28:32 | TheSeven | but if we are indeed dealing with a runaway here, why does this manage to recover somewhat gracefully if we comment that? |
| 22:28:54 | Unhelpful | it will break if not inlined. make sure it's always inlined, replace it with a macro, or try using if(__builtin_constant_p(mask)) and branching the asm with the i or r constraint |
| 22:29:20 | TheSeven | liar: did you try inserting a panicf on line 707? is this reached? |
| 22:29:30 | Unhelpful | or don't build with -O0. the error you're getting is not an error if optimization is enabled. |
| 22:29:51 | liar | TheSeven: i had a splashf in there(it is called) |
| 22:29:58 | * | kugel thinks code that depends on O levels is bad code |
| 22:30:11 | | Join Creposucre [0] (n=53c3a620@giant.haxx.se) |
| 22:30:19 | TheSeven | gevaerts: GET_STATUS is request 0? |
| 22:30:29 | kugel | Unhelpful: how to make sure if always_inline doesn't work? |
| 22:30:34 | Unhelpful | kugel: then use a macro to guarantee the code is inlined. code that depends on inlining and specialization is *not* inherently bad code. |
| 22:30:52 | gevaerts | TheSeven: apparently, yes |
| 22:30:53 | Unhelpful | well, if it's trying to generate a non-inline version, clearly it's not working? |
| 22:30:58 | Creposucre | JdGordon: ping |
| 22:31:07 | TheSeven | liar: try an "if (req->bRequest==USB_REQ_GET_STATUS) panicf("whatever");" at line 689 |
| 22:31:26 | kugel | maybe it's inlining but also generating the definition |
| 22:31:28 | Creposucre | JdGordon: just to let you know that I've updated FS 10494 |
| 22:31:32 | gevaerts | TheSeven: the linux kernel (at least 2.6.30) only ever calls USB_REQ_GET_STATUS for USB_RECIP_DEVICE, so *never* interface |
| 22:31:42 | TheSeven | or maybe even better "if (req == 0) panicf("ouch");" |
| 22:32:01 | Unhelpful | it shouldn't on account of static |
| 22:32:47 | TheSeven | a null pointer getting passed in there may well explain that |
| 22:33:57 | | Join tomers_ [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) |
| 22:34:51 | pixelma | mc2739: thanks for the head-up about the typo (and sorry for not paing much attention then but the crash was more important to me first), will have a look and then commit now |
| 22:35:15 | gevaerts | TheSeven: so the driver calling usb_signal_transfer_completion() with wrong data? |
| 22:36:23 | TheSeven | gevaerts: i suspect the chip just claims to have received something but for some reason the request data is all-zero or something |
| 22:36:43 | TheSeven | either a spurious int, or maybe a cache coherency problem once again? |
| 22:37:17 | liar | TheSeven: *PANIC* whatever |
| 22:37:17 | liar | but the second one doesnt panic |
| 22:37:33 | TheSeven | hm, so we're indeed receiving crap from the chip :-/ |
| 22:37:41 | * | gevaerts sees something fishy in the code |
| 22:37:52 | TheSeven | which code? |
| 22:38:09 | pixelma | the |
| 22:38:16 | * | pixelma hides |
| 22:38:27 | gevaerts | TheSeven: usb_core.c, usb_core_transfer_complete() |
| 22:39:03 | mc2739 | pixelma: no problem, crashes are always a higher priority than documentation |
| 22:39:15 | gevaerts | TheSeven: it picks a completion_event struct depending on endpoint number. I suspect it should also take direction into account, to avoid overlapping completions |
| 22:39:41 | CIA-80 | New commit by tomers (r23638): FS #10783 - WPS translation ... |
| 22:39:43 | gevaerts | This could also be responsible for some weird logf output I've been seeing from usb_storage on PP |
| 22:39:51 | * | gevaerts grabs a device |
| 22:39:57 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
| 22:41:11 | gevaerts | TheSeven: if you get two completion events for EP0 for IN and OUT close to each other (faster than the threads can switch), you could get strange things here |
| 22:44:53 | | Quit tomers_ ("ChatZilla 0.9.85 [Firefox 3.5.5/20091109125225]") |
| 22:46:04 | gevaerts | liar: could you try http://pastie.org/700165.txt ? |
| 22:46:24 | * | gevaerts tries it on his e200 |
| 22:48:06 | | Quit Maad_Man ("Leaving") |
| 22:48:09 | | Join Maad_Man [0] (n=MaadMan@188-192-221-19-dynip.superkabel.de) |
| 22:48:11 | pamaury | I have a question about git: on github, pcc1 once created an experimental branch (mtp-experimental) but now I would like to delete this branch. How can I delete the branch both locally and on the remote (github) ? (I don't think I should leave this branch forever) |
| 22:48:12 | | Quit tomers (Read error: 113 (No route to host)) |
| 22:51:17 | | Quit stoffel (Remote closed the connection) |
| 22:53:23 | kugel | Unhelpful: is there some define for the O levels? |
| 22:53:50 | liar | gevaerts: that locks up too |
| 22:54:18 | * | kugel fails to get it work as #define |
| 22:54:59 | gevaerts | :( |
| 22:56:35 | gevaerts | that does mean it's probably the driver then |
| 22:57:21 | gevaerts | I still think it's a bug though, so I'll commit anyway |
| 22:57:33 | | Quit Creposucre ("CGI:IRC") |
| 22:58:28 | CIA-80 | New commit by gevaerts (r23639): Don't use the same completion_event for both directions. This could cause problems on USB controllers that have IN and OUT endpoints with the same ... |
| 22:59:15 | * | kugel hands gevaerts an enum to make code readable :) |
| 22:59:37 | * | gevaerts waits for kugel's patch :) |
| 22:59:57 | pixelma | gevaerts: could these fixes help with the MacOS 10.4 problems too? |
| 23:00 |
| 23:00:24 | gevaerts | pixelma: no |
| 23:00:51 | kugel | gevaerts: you just want to maintain our usb code busfactor :) |
| 23:01:04 | gevaerts | kugel: where do you want an enum? |
| 23:01:17 | | Join petur [0] (n=peter@d54C6F9B2.access.telenet.be) |
| 23:02:08 | kugel | IN and OUT when accessing the array instead of "bogus" 0 and 1 (the boolean seems even worse, even if it's correct) |
| 23:02:23 | gevaerts | kugel: I do have IN and OUT. Their value is 0x80 and 0x00 |
| 23:02:48 | kugel | then something else |
| 23:02:58 | gevaerts | those are the values that get passed in |
| 23:03:13 | kugel | DIRECTION_IN and _OUT for example |
| 23:03:35 | gevaerts | used where exactly? |
| 23:04:04 | kugel | what? |
| 23:04:33 | kugel | your commit uses 0, 1 and a boolean for the direction, doesn't it? |
| 23:04:44 | * | pamaury wonders someone has an answer to his Git question |
| 23:05:14 | kugel | git brach -d <branch> |
| 23:05:22 | kugel | then git push |
| 23:05:46 | gevaerts | it uses 0 and 1 as array indices (no boolean! There is no such thing in C!), that are derived from a direction int, which is 0x00 or ox80 |
| 23:05:48 | kugel | (the git push command may be more complicated) |
| 23:06:20 | kugel | "dir!=0" is a boolean expression to me |
| 23:06:31 | gevaerts | yes, but not to the compiler :) |
| 23:06:34 | gevaerts | it returns an int |
| 23:06:56 | kugel | who cares about the compiler, I'm arguing for readable code |
| 23:07:14 | gevaerts | ok, please propose a patch |
| 23:07:54 | kugel | &ep_data[EP_CONTROL].completion_event[DIRECTION_OUT] seems better readable to me |
| 23:08:10 | gevaerts | and where does DIRECTION_OUT come from? |
| 23:08:21 | gevaerts | in one case it's easy, but the other? |
| 23:08:27 | kugel | that has to be defined of course |
| 23:08:38 | gevaerts | that's not what I mean |
| 23:08:56 | kugel | enum { DIRECTION_IN, DIRECTION_OUT, (maybe also NUM_DIRECTIONS ]; |
| 23:08:58 | gevaerts | don't tell me enums and macros have to be defined. I'm not an idiot |
| 23:09:10 | kugel | I don't understand your question then |
| 23:09:34 | gevaerts | How do you handle the completion_event[dir!=0] bit? |
| 23:09:38 | * | kugel knows that gevaerts isn't an idiot |
| 23:09:56 | * | gevaerts wonders why kugel thought he didn't know how to declare an enum then |
| 23:10:07 | kugel | dir == DIRECTION_IN ? DIRECTION_IN : DIRECTION_OUT for example |
| 23:10:39 | TheSeven | gevaerts: &ep_data[EP_CONTROL].completion_event[dir>>7] :-P |
| 23:11:13 | kugel | or just dir ? ... |
| 23:11:45 | gevaerts | kugel: why? I prefer to access actually existing array indices |
| 23:11:50 | TheSeven | if anything: &ep_data[EP_CONTROL].completion_event[dir == IN ? DIRECTION_IN : DIRECTION_OUT] |
| 23:12:05 | TheSeven | but this doesn't really look better to me |
| 23:12:48 | kugel | gevaerts: how do you mean that? |
| 23:13:20 | kugel | TheSeven: that looks much better IMO |
| 23:13:20 | gevaerts | kugel: accessing an array with two elements at index 0x80 is not going to work well. "dir" can be 0x00 or 0x80 |
| 23:13:34 | | Quit Strife89 ("Leaving") |
| 23:13:54 | kugel | at index 0x80? |
| 23:14:01 | gevaerts | yes |
| 23:14:16 | kugel | where does "[dir == IN ? DIRECTION_IN : DIRECTION_OUT]" give index 0x80? |
| 23:14:33 | TheSeven | kugel: I think he is referring to [23:09]<kugel>or just dir ? ... |
| 23:14:39 | gevaerts | it doesn't. You said "or just dir" |
| 23:15:03 | kugel | I meant "dir ? DIRECTION_IN : DIRECTION_OUT" |
| 23:15:12 | gevaerts | Also, I don't think having USB_DIR_IN being 0x80 and another DIRECTION_IN being 1 is going to make things clear |
| 23:15:16 | kugel | (the "..." was lazyness) |
| 23:15:37 | *** | Saving seen data "./dancer.seen" |
| 23:16:13 | gevaerts | wait |
| 23:16:14 | * | kugel disagrees, but whatever |
| 23:17:47 | CIA-80 | New commit by gevaerts (r23640): use the EP_DIR() macro to go from USB_DIR_* to a 0 or 1 value |
| 23:18:01 | gevaerts | better? |
| 23:18:25 | kugel | yea :> |
| 23:18:35 | * | TheSeven just wanted to come up with another idea |
| 23:18:59 | TheSeven | what about a struct that consists of 2 of these things, named in and out? ;-) |
| 23:19:06 | * | gevaerts had forgotten that tomers had added some of those helpers |
| 23:19:26 | pixelma | hmm, there already was a pure voice string for "of" |
| 23:19:40 | * | kugel wonders why he added those ;) |
| 23:19:45 | gevaerts | TheSeven: that would require lots of code elsewhere |
| 23:20:10 | TheSeven | gevaerts: you should be able to use that like an array |
| 23:20:21 | gevaerts | kugel: quick quiz: which direction is USB_DIR_IN? :) |
| 23:20:25 | kugel | oh, DIR_IN and DIR_OUT already exist too :) |
| 23:20:52 | * | TheSeven likes usb direction naming :-P |
| 23:20:53 | | Quit mikroflops (""Maailmanpyoramuualta"") |
| 23:21:01 | kugel | 0x80? |
| 23:21:01 | gevaerts | TheSeven: sure? Without relying on gcc doing the right thing with something the spec says is undefined? |
| 23:21:09 | Unhelpful | EP_DIR_ARRAY_INDEX_VALUE() would be clearer! ;) |
| 23:21:10 | gevaerts | kugel: direction, not value |
| 23:21:25 | kugel | in ? |
| 23:21:38 | gevaerts | device to host or host to device? |
| 23:21:45 | * | TheSeven can't see the problem |
| 23:22:07 | kugel | host to device |
| 23:22:08 | TheSeven | just use a struct that consists of 2 of these things, one named in and one named out |
| 23:22:26 | gevaerts | kugel: wrong :) IN is device to host :) |
| 23:22:33 | TheSeven | and then pass &ep_data[EP_CONTROL].completion_event.in or &ep_data[EP_CONTROL].completion_event.out |
| 23:22:49 | kugel | arg, I was thinking about OUT when doing the last guess |
| 23:22:54 | | Quit n1s ("Lämnar") |
| 23:23:07 | kugel | to make you believe me that I unfortunately need to admit that I looked it up :P |
| 23:23:11 | TheSeven | kugel: everyone would have said that :-P |
| 23:23:27 | Unhelpful | kugel: perhaps you were thinking that "in" == "device-to-host" made too much sense to belong in the USB spec? |
| 23:23:29 | JdGordon | aaaaaaaarrrrrrrrrr... wtf do i do about the rec bar? |
| 23:24:02 | kugel | it's like I said :p |
| 23:24:10 | TheSeven | gevaerts: yes, you would of course need an if there, but it looks nice and clean to me, and the compiler will probably eliminate it anyways |
| 23:24:23 | kugel | I looked at /* The USB core is a device, and OUT is RX from that P.O.V */ and had OUT in my mind since then |
| 23:24:24 | gevaerts | TheSeven: that may work well for this particular case, but most places that do something like this get a number, so you get lots of extra lines |
| 23:25:00 | gevaerts | TheSeven: if the current way is found to be unclear, I prefer Unhelpful's suggestion, even if he seems to have proposed it as a joke :) |
| 23:28:57 | gevaerts | hm, maybe DIR_IN and DIR_OUT, and USB_DIR_IN and USB_DIR_OUT should indeed be enums, so we could use that as a type instead of int, so it would be a lot clearer which one is needed for functions. Not sure if that wouldn't cause other issues though |
| 23:29:24 | CIA-80 | New commit by kugel (r23641): Change "r" back to "i" (i is for immediate, so no syntax error) and reclaim a bit binsize. Live with that those function don't build with -O0 since ... |
| 23:29:31 | | Quit bmbl ("Bye!") |
| 23:30:26 | kugel | gevaerts: we better wait for the eabi change with that one :) |
| 23:31:30 | gevaerts | kugel: probably :) the thing is that they really need to be interchangeable with int. I don't want three lines of extra code every time I get 0x80 from the hardware and need USB_DIR_IN |
| 23:32:11 | kugel | that will work with eabi, unless you access them via a int pointer |
| 23:33:09 | JdGordon | kugel: shouldnt this just work in WPSLIST...? "SBS.112x64: classic_statusbar.sbs |
| 23:33:09 | JdGordon | SBS: classic_statusbar.sbs" |
| 23:33:22 | gevaerts | maybe it's better to leave that one as plain int, and only use an enum for the other variety (the 0/1 one) |
| 23:33:28 | kugel | JdGordon: I think so, yes |
| 23:33:44 | JdGordon | :( no dice |
| 23:33:52 | gevaerts | that one is never passed to hardware, shouldn't be used in bitwise logic, and so on |
| 23:34:01 | kugel | maybe without the extension, I'm not sure |
| 23:34:23 | kugel | you can uncomment some debug messages in wpsbuild.pl |
| 23:34:57 | JdGordon | the rockbox_default theme doesnt seem to get made? |
| 23:35:28 | kugel | that's not really a file |
| 23:35:56 | kugel | it only contains a target independant comment, the filename is hardcoded in wps.c to use the builtin |
| 23:36:55 | JdGordon | yeah I know.. I'd still expect the file to be created thoguh |
| 23:36:58 | JdGordon | or moved |
| 23:37:25 | kugel | maybe it's created in buildzip.pl? |
| 23:37:40 | JdGordon | is the sbs stuff linked up properly? I added the line to boxes which does get created, and its added the the generated cfg, but the sbs is copied across |
| 23:37:55 | JdGordon | neither is the bmps |
| 23:38:48 | | Quit pamaury ("exit(*(int *)0 / 0);") |
| 23:38:52 | CIA-80 | New commit by pixelma (r23642): Manual: Pictureflow chapter - foremost fixing the M3 manual but clean up the button table completely to make it more readable and be more accurate ... |
| 23:39:21 | kugel | my first sbs patch has this line "+SB.176x220x16: cabbiev2.sb" |
| 23:40:32 | JdGordon | it needs the depth? |
| 23:41:02 | kugel | yes, but x16 targets will also get x1 stuff |
| 23:42:00 | pixelma | mc2739: sorry, now I forgot to fix the typo |
| 23:43:56 | pixelma | and I see another unnecessary thing |
| 23:44:24 | JdGordon | ah, if its named correctly it does get created... the bmp's arnt copied though |
| 23:44:49 | mc2739 | pixelma: that's OK, I can get it |
| 23:45:15 | Unhelpful | gevaerts: they're only incompatible when pointed to, or if you're converting between signed and unsigned types |
| 23:45:39 | pixelma | mc2739: line 53 doesn't need the {} after the last of the two mentioned buttons |
| 23:46:05 | liar | gevaerts: another usb bug i found out is: rockbox locks up if i the usb cable is connected while booting or if i connect it before the disk activity led on the top right shuts off the first time |
| 23:46:10 | Unhelpful | casting small enums to signed will almost never mean what you expect it to, unless the enum contains a negative value |
| 23:46:59 | kugel | did you try that? |
| 23:47:04 | | Join mikroflops [0] (n=yogurt@90-224-27-247-no112.tbcn.telia.com) |
| 23:47:15 | | Quit petur (Remote closed the connection) |
| 23:48:15 | CIA-80 | New commit by mc2739 (r23643): Fix typo and remove umnecessary {} |
| 23:48:21 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 23:49:31 | kugel | Unhelpful: why does that not work? |
| 23:50:33 | gevaerts | liar: that doesn't happen on other targets, so I suspect a driver bug, in which case TheSeven is the one to poke :) |
| 23:51:51 | JdGordon | kugel: did that cabbie sbs use any bmp's whicht he .wps didnt? |
| 23:52:03 | kugel | I don't think so |
| 23:52:24 | kugel | but I think I had some other sbs to test with later, I'm not so sure though |
| 23:53:01 | JdGordon | I think it doesnt parse the sbs for files.. or copy them properly |
| 23:53:08 | JdGordon | but my eyes are bleeding from the perl :( |
| 23:54:13 | | Quit Maad_Man ("Leaving") |
| 23:54:28 | Unhelpful | kugel: an enum with only small positive values is equivalent to unsigned char. since you are casting it to a *larger* type in casting to signed, the full range of the small type can and will be preserved. so, (signed)(tiny_enum =0xff) != -1 |
| 23:54:54 | | Join ender [0] (i=krneki@foo.eternallybored.org) |
| 23:56:04 | kugel | I assume the compiler handles that properly like it does for all other types? |
| 23:56:10 | Unhelpful | doom and mpegplayer both have enum values where -1 is not part of the enum but is used as a flag value in code. for an equality test, you can compare enum_var to (enum_type)-1, for greater-than this also fails |
| 23:56:47 | Unhelpful | in that it warns that the comparison is always going to be true or false depending on its sense, yes, gcc handles it "properly" |
| 23:57:16 | kugel | but (signed)(tiny_enum =0xff) != -1 is what I expect if the enum doesn't have negative values |
| 23:57:17 | gevaerts | kugel: the problem is that the "compatible type" for an enum can be char, signed int, or unsigned int. The compiler can decide for each enum independently |
| 23:57:40 | kugel | yea, it depends on the enum |
| 23:58:06 | gevaerts | From my understanding that means that on a target where char is signed, the compiler can decide things differently than for a target where char is unsigned |
| 23:58:07 | Unhelpful | to fix these, either define the -1 flag value in the enum, making it a signed type, or cast the -1 instead of the enum variable. |
| 23:58:09 | kugel | Unhelpful: ah you investigated those lot of warnings already? I was to lazy :) |
| 23:58:28 | JdGordon | yep.. buildwps.pl is broken |
icon identifies that the person is a core developer (has commit access).