| *** NIN101 has quit IRC | 00:00 | |
| *** Martix has joined #maemo-ssu | 00:06 | |
| *** Martix_ has joined #maemo-ssu | 00:08 | |
| *** Martix has quit IRC | 00:08 | |
| *** Vlad_on_the_road has quit IRC | 00:15 | |
| *** jonwil has quit IRC | 00:21 | |
| DocScrutinizer05 | freemangordon: there's a clear threshold of ALS above which indLED is dimmed down (by either current_led or brightnes [=PWM]) to near invisible brightness | 00:30 |
|---|---|---|
| DocScrutinizer05 | doesn't exactly look like "calculated" to me - rather I think some fool decided to dim *all* LED when actually only kbd LEDs were meant to get shut down completely | 00:31 |
| DocScrutinizer05 | but street gossip has it that some product manager chairfart gashead specified dimming of indLED above a certain brightness as a product requirement, and so devels implemented it in the least-effort way they could think of | 00:33 |
| *** dafox has quit IRC | 00:33 | |
| DocScrutinizer05 | btw NB that led_current is NOT in units of mA | 00:34 |
| DocScrutinizer05 | *sigh*, again looking up my own statements in wiki | 00:35 |
| DocScrutinizer05 | http://wiki.maemo.org/N900_Hardware_LED | 00:36 |
| DocScrutinizer05 | >> | 00:37 |
| DocScrutinizer05 | Despite the line | 00:37 |
| DocScrutinizer05 | #define LP5523_DEFAULT_CURRENT 50 /* microAmps */ | 00:37 |
| DocScrutinizer05 | suggesting different, the units in there are 0.1 mA (100 µA per step is correct). So the driver init default "50" for all LEDs is 5 mA, and mce seems to set current to 0.2 mA (value 2 in the led_current sysnode) for B and G, and either to 0.2 mA or 0.8 mA for R. | 00:37 |
| DocScrutinizer05 | << | 00:37 |
| DocScrutinizer05 | the comment in ( ) is by Nokia_Employee responsible for LP5523 | 00:38 |
| DocScrutinizer05 | >>Probably settings as high as 100 for 10 mA are safe for the RGB LED, higher values might destroy the LED. (yes, correct, the RGB could be damaged from heat if set to more than 10 mA on all 3 LEDs) | 00:39 |
| DocScrutinizer05 | quite funny that by guesswork been correct to the mA even for the max current allowed :-) | 00:40 |
| DocScrutinizer05 | s/ by/ my/ | 00:40 |
| infobot | DocScrutinizer05 meant: quite funny that my guesswork been correct to the mA even for the max current allowed :-) | 00:40 |
| *** Martix_ has quit IRC | 00:41 | |
| *** Martix_ has joined #maemo-ssu | 00:41 | |
| DocScrutinizer05 | freemangordon: actually mce is insane to mess with led_current at all | 00:42 |
| DocScrutinizer05 | led_current should get (probably hard-)set to the max allowavle current for the LED, and all the rest be done by brightness sysnode | 00:43 |
| DocScrutinizer05 | messing with led_current is strongly deprecated and not really justified by any eationale I'd know of, but meh, that's what we got, obviously | 00:43 |
| *** int_ua has joined #maemo-ssu | 00:44 | |
| *** Martix_ has quit IRC | 00:45 | |
| *** Martix_ has joined #maemo-ssu | 00:45 | |
| DocScrutinizer05 | actually you should set led_current of all 3 LEDs of the 3color indLED so that a) each single LED doesn't see overcurrent b) all three LEDs together shouldn't see exceeding the max continuous *power* consumption allowed for the thermal design, and c) in a ratio to each other so that the indLED shines white on brightness[r,g,b]==255 | 00:46 |
| DocScrutinizer05 | otherwise the lp5523 logarithmic mode for brightness will cause hue deviations for "white" < 255 | 00:48 |
| *** Martix_ has quit IRC | 00:48 | |
| *** Martix_ has joined #maemo-ssu | 00:49 | |
| *** Martix_ has quit IRC | 00:52 | |
| *** _nicolai_ has quit IRC | 01:52 | |
| *** BCMM has quit IRC | 02:37 | |
| *** nox- has quit IRC | 02:47 | |
| *** amizraa has joined #maemo-ssu | 03:13 | |
| *** drathir_ has joined #maemo-ssu | 03:19 | |
| *** sixwheeledbeast has quit IRC | 03:23 | |
| *** jon_y has quit IRC | 03:23 | |
| *** nedko has quit IRC | 03:23 | |
| *** raccoon_ has quit IRC | 03:23 | |
| *** merlin1991 has quit IRC | 03:23 | |
| *** drathir has quit IRC | 03:23 | |
| *** dos1 has quit IRC | 03:50 | |
| *** LauRoman has quit IRC | 04:20 | |
| *** M4rtinK has quit IRC | 04:40 | |
| *** sixwheeledbeast has joined #maemo-ssu | 05:17 | |
| *** jon_y has joined #maemo-ssu | 05:17 | |
| *** nedko has joined #maemo-ssu | 05:17 | |
| *** raccoon_ has joined #maemo-ssu | 05:17 | |
| *** merlin1991 has joined #maemo-ssu | 05:17 | |
| *** nedko has left #maemo-ssu | 05:23 | |
| *** amiconn has quit IRC | 05:51 | |
| *** amiconn_ has joined #maemo-ssu | 05:51 | |
| *** amiconn_ is now known as amiconn | 05:52 | |
| *** jonwil has joined #maemo-ssu | 07:25 | |
| *** DrCode has joined #maemo-ssu | 07:26 | |
| *** luf has joined #maemo-ssu | 07:30 | |
| *** dafox has joined #maemo-ssu | 07:35 | |
| *** dafox has quit IRC | 08:07 | |
| *** Vlad_on_the_road has joined #maemo-ssu | 08:30 | |
| *** Vlad_on_the_road has quit IRC | 09:21 | |
| *** LauRoman has joined #maemo-ssu | 09:31 | |
| *** int_ua has quit IRC | 09:31 | |
| *** LaoLang_cool has joined #maemo-ssu | 10:04 | |
| *** LaoLang_cool has quit IRC | 10:11 | |
| *** Martix_ has joined #maemo-ssu | 10:12 | |
| *** Pali has joined #maemo-ssu | 10:13 | |
| *** sunny_s has joined #maemo-ssu | 10:31 | |
| *** arcean has joined #maemo-ssu | 10:32 | |
| *** BCMM has joined #maemo-ssu | 11:01 | |
| *** BCMM has quit IRC | 11:01 | |
| freemangordon | Pali: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg95403.html | 11:05 |
| freemangordon | I knew there is something wrong in the clock fw :) | 11:05 |
| *** Martix_ has quit IRC | 11:13 | |
| *** arcean has quit IRC | 12:10 | |
| *** dos1 has joined #maemo-ssu | 13:48 | |
| DocScrutinizer05 | it's a terrible feeling to see what botch is done sometimes in kernel land | 14:01 |
| *** M4rtinK has joined #maemo-ssu | 14:06 | |
| *** arcean has joined #maemo-ssu | 14:09 | |
| DocScrutinizer05 | anyway nice find, hope you get cam working now | 14:10 |
| *** sailus_ has joined #maemo-ssu | 14:14 | |
| *** sailus_ has quit IRC | 14:16 | |
| *** sailus_ has joined #maemo-ssu | 14:18 | |
| *** DrCode has quit IRC | 14:29 | |
| *** M4rtinK has quit IRC | 14:33 | |
| *** DrCode has joined #maemo-ssu | 14:38 | |
| *** lizardo has joined #maemo-ssu | 14:51 | |
| DocScrutinizer05 | God gracious, I think I got an angie-hangover - and that might last for the next 4 years | 15:00 |
| Pali | DocScrutinizer05: what is max value for lp5523 "led_current" sysfs entries? | 15:07 |
| DocScrutinizer05 | Pali: I honestly don't know, logically it's a u8 I guess | 15:12 |
| DocScrutinizer05 | the chip supports something as high as maybe 50mA, and anyway the value range is deep into the red regarding what the LEDs on N900 can do | 15:13 |
| DocScrutinizer05 | Pali: lp5523 datasheet: >> 9 programmable outputs with 25.5 mA full-scale current, << | 15:15 |
| DocScrutinizer05 | unit for led_current is 0.1mA | 15:16 |
| DocScrutinizer05 | that's a max 255 for this sysnode | 15:16 |
| DocScrutinizer05 | which conveniently will fry the indicator 3color LED anyway | 15:17 |
| DocScrutinizer05 | according to Nokia guy who designed the LED stuff, the max is 3*10mA for the indLED, aka 3* 100 for sysnode | 15:18 |
| DocScrutinizer05 | ...or LED will literally fry | 15:18 |
| DocScrutinizer05 | for the kbd LEDs I guess they can cope with 20mA each, but that's a guess of mine and nothing you should quote me on | 15:19 |
| *** DrCode_ has joined #maemo-ssu | 15:20 | |
| *** DrCode has quit IRC | 15:20 | |
| *** DrCode_ is now known as DrCode | 15:20 | |
| DocScrutinizer05 | Pali: so, what exactly is your question? | 15:22 |
| Pali | DocScrutinizer05: in upstream kernel there is property max_current which needs to be initliazed from board data. and driver allow to change led_current only if new led_current < max_current | 15:24 |
| Pali | by default max_current is 0, so you can think what happen :-) | 15:24 |
| DocScrutinizer05 | in original lp5523.ko of Nokia there are sane presets for the LED current iirc, and maybe or rather probably MCE also does some presets, but in the end nobody incl mce should mess with those values after initial setup | 15:24 |
| Pali | max_current current is only limit for led_current | 15:24 |
| DocScrutinizer05 | Pali: LOL | 15:24 |
| DocScrutinizer05 | well, sane concept | 15:25 |
| Pali | I set max_current to 255 (because led_current is uint8_t) | 15:25 |
| Pali | because original maemo 2.6.28 kernel has u8 led_current and no upper limit | 15:25 |
| DocScrutinizer05 | ok, I gonna takle responsibility for this and define: max_current for all 9 diodes on N900:: 100 aka 10mA | 15:25 |
| DocScrutinizer05 | take even, as well as tackle :-D | 15:26 |
| DocScrutinizer05 | when we already got sth as nice and useful as max_current, we shall use it to enforce sane maximum that keeps LEDs alive | 15:27 |
| DocScrutinizer05 | so: 10mA, set max_current to 100 | 15:27 |
| DocScrutinizer05 | I gather that value comes from board data? | 15:27 |
| DocScrutinizer05 | Pali: ^^^ | 15:29 |
| Pali | DocScrutinizer05: yes max_current is set in rx51 board data | 15:30 |
| Pali | so change it to 100 (it is 10mA?) | 15:30 |
| DocScrutinizer05 | yes | 15:30 |
| DocScrutinizer05 | please | 15:31 |
| Pali | DocScrutinizer05: initial value for all (kb1..kb6,b,r,g) is 50 | 15:32 |
| DocScrutinizer05 | I know | 15:32 |
| Pali | this is OK? | 15:32 |
| DocScrutinizer05 | yes | 15:32 |
| Pali | it is also in board data | 15:32 |
| DocScrutinizer05 | http://wiki.maemo.org/N900_Hardware_LED | 15:34 |
| *** luf has quit IRC | 15:37 | |
| *** drathir_ is now known as drathir | 15:39 | |
| DocScrutinizer05 | Pali: all the info in there is correct | 15:40 |
| Pali | DocScrutinizer05: I sent new version of patch and CCed you | 15:50 |
| DocScrutinizer05 | thanks | 15:50 |
| Pali | DocScrutinizer05: maybe you can review patch too and sign it | 15:51 |
| Pali | or comment other parts | 15:51 |
| DocScrutinizer05 | not for fame but for later flames you might want to add in patch that the values been defined by me | 15:51 |
| DocScrutinizer05 | sure | 15:51 |
| *** DrCode has quit IRC | 15:51 | |
| DocScrutinizer05 | aah, you did | 15:53 |
| DocScrutinizer05 | looks good, what shall I do? | 15:55 |
| DocScrutinizer05 | consider the patch "signed by me" | 15:56 |
| Pali | DocScrutinizer05: if patch is ok, just write something that is correct and you can sign patch by keyword "Signed-off-by:" | 16:02 |
| *** arcean has quit IRC | 16:03 | |
| DocScrutinizer05 | done | 16:07 |
| *** DrCode has joined #maemo-ssu | 16:09 | |
| *** arcean has joined #maemo-ssu | 16:22 | |
| *** arcean has quit IRC | 16:57 | |
| *** robotanarchy has joined #maemo-ssu | 17:21 | |
| *** sailus_ has quit IRC | 17:22 | |
| *** sailus has quit IRC | 17:23 | |
| *** sailus has joined #maemo-ssu | 17:23 | |
| *** sailus_ has joined #maemo-ssu | 17:23 | |
| *** lrtz has quit IRC | 17:42 | |
| *** lrtz has joined #maemo-ssu | 17:48 | |
| freemangordon | Pali: found a bug in the led driver or it is just fix to the board data? | 17:57 |
| Pali | freemangordon: where? | 17:58 |
| freemangordon | Pali: re your discussion with DocScrutinizer05 | 17:59 |
| freemangordon | ^^^ | 17:59 |
| freemangordon | about max current, etc | 17:59 |
| Pali | freemangordon: I did not pushed that new patch to gitorious yet | 17:59 |
| freemangordon | Pali: ok, but is there a bug? | 17:59 |
| DocScrutinizer05 | freemangordon: the latter | 17:59 |
| Pali | which changing 255 to 100 | 17:59 |
| freemangordon | ok | 17:59 |
| freemangordon | Pali: did you see the link I posted ^^^ | 18:00 |
| DocScrutinizer05 | it could be considered "bug in board data" | 18:00 |
| freemangordon | :nod: | 18:00 |
| freemangordon | can't we limit that to 50 instead of 100? | 18:00 |
| freemangordon | mce set it to 47 aiui | 18:00 |
| DocScrutinizer05 | I gather max_current is write-once, just like FMTX max power | 18:01 |
| DocScrutinizer05 | if it's n ot, then THAT would actually be a bug | 18:01 |
| DocScrutinizer05 | in driver | 18:01 |
| freemangordon | will check the permissions when I boot the kernel | 18:01 |
| DocScrutinizer05 | freemangordon: nope, the limits are checked and correct | 18:02 |
| Pali | DocScrutinizer05: it is const compile time variable | 18:02 |
| DocScrutinizer05 | ooh, even better | 18:02 |
| freemangordon | if it is anything but 0444 I guess we can fix it | 18:02 |
| Pali | for chaning it you need to recompile zImage | 18:02 |
| freemangordon | Pali: what are the permissions of sysfs entry? | 18:02 |
| DocScrutinizer05 | of which entry? | 18:04 |
| DocScrutinizer05 | max_current? this shall be r/o | 18:04 |
| freemangordon | sure, buit what are the actual permissions :) | 18:04 |
| Pali | freemangordon: this is not about permission, but it is variable in board data file in some structure | 18:04 |
| freemangordon | Pali: this is exposed in sysfs | 18:04 |
| Pali | permission is of course 0444 | 18:04 |
| DocScrutinizer05 | :-) | 18:05 |
| Pali | but you should not change it | 18:05 |
| Pali | and you also cannot | 18:05 |
| DocScrutinizer05 | 444 correct | 18:05 |
| freemangordon | Pali: it is fine then :) | 18:05 |
| Pali | ok :-) | 18:05 |
| Pali | going to push that patch into gitorious | 18:05 |
| Pali | pushed | 18:06 |
| freemangordon | Pali: see http://www.mail-archive.com/linux-omap@vger.kernel.org/msg95403.html | 18:06 |
| Pali | what is with that? | 18:07 |
| freemangordon | wrong dpll/frequency calculation | 18:07 |
| freemangordon | on 3430 | 18:07 |
| freemangordon | I'll try that patrch now | 18:07 |
| DocScrutinizer05 | and try if it actually kicks in | 18:08 |
| freemangordon | but it seems half of the clocks are wrong :) | 18:08 |
| DocScrutinizer05 | I'm musing about all that insane clock generation auto-guess code | 18:08 |
| freemangordon | DocScrutinizer05: for sure it kicks in, remember my discussion with sailus about strange frequencies? the same strange frequency I have with ssi clocks | 18:09 |
| DocScrutinizer05 | seems like an odd way to handle clocks | 18:09 |
| freemangordon | DocScrutinizer05: actually I like that "clock framework" | 18:09 |
| *** arcean has joined #maemo-ssu | 18:09 | |
| freemangordon | and maybe I will like this DT shit too, it seems after all those are not 3d objects :) | 18:09 |
| DocScrutinizer05 | setting up clock dividers and muxes and whatnot is a *very* complex thing to do the right way, even for humans using their brain and all the datasheets. It sounds weird to try and write an algo that does all this in a generic way | 18:10 |
| freemangordon | DocScrutinizer05: no algo, stuff is hardcoded | 18:11 |
| DocScrutinizer05 | mhm | 18:11 |
| DocScrutinizer05 | ok then | 18:11 |
| DocScrutinizer05 | that's actually what I'd do | 18:11 |
| freemangordon | there is a clock tree | 18:11 |
| *** NIN101 has joined #maemo-ssu | 18:11 | |
| DocScrutinizer05 | yep, it's a tree | 18:11 |
| DocScrutinizer05 | the clock dependencies | 18:12 |
| freemangordon | :nod: | 18:12 |
| freemangordon | the same goes for the power supplies iiuc | 18:12 |
| DocScrutinizer05 | so when they use a static data structure to represent that tree with all the solutions for various tuples of clocks, that's OK I guess | 18:12 |
| DocScrutinizer05 | rather a forest | 18:13 |
| freemangordon | so all that is up to you is to define which clocks and power supplies your device uses | 18:13 |
| DocScrutinizer05 | :nod: | 18:13 |
| freemangordon | framework finds the dependencies and enables the appropriate plls/dividers, etc | 18:14 |
| freemangordon | and power supplies | 18:14 |
| freemangordon | so it looks fine | 18:14 |
| DocScrutinizer05 | basically it's a sparse multidimensional array | 18:14 |
| DocScrutinizer05 | ideally augmented by allowing wildcards | 18:14 |
| freemangordon | ok, booting with ^^^ patch, lets see :) | 18:15 |
| DocScrutinizer05 | :-) | 18:15 |
| DocScrutinizer05 | good luck! | 18:15 |
| freemangordon | well, at least it still boots :D | 18:16 |
| freemangordon | Pali: btw I reverted your et8ek8 FW patch and the oops is gone | 18:16 |
| Pali | ok, will look at it later | 18:17 |
| Pali | at least we know what caused it | 18:17 |
| freemangordon | Pali: looking through the code, I wondered what "offset" is supposed to mean | 18:17 |
| freemangordon | could it be an offset into the file? not a pointer | 18:17 |
| freemangordon | ok | 18:17 |
| Pali | * The pointers in the list are actually offsets from the beginning of the blob. | 18:20 |
| Pali | freemangordon: so there is problem | 18:20 |
| Pali | you are right | 18:20 |
| freemangordon | :) | 18:21 |
| DocScrutinizer05 | hah | 18:23 |
| DocScrutinizer05 | bbl | 18:23 |
| Pali | this is retarded nonsense usage of pointers | 18:24 |
| Pali | specifing relative offset of of current stucture to another... | 18:24 |
| Pali | how can I write this C code? struct A a = { .val = 1 }; struct B b = { .val = &a - &b; }; | 18:27 |
| DocScrutinizer05 | err, that's frequently used in ~80% of file formats | 18:27 |
| Pali | C does not allow to do (&a - &b) in initlializer | 18:27 |
| Pali | and structure B b needs value which will be offset between struct A a and struct B b | 18:28 |
| freemangordon | Pali: hmm, those are different types I guess | 18:28 |
| Pali | it is even possible | 18:28 |
| freemangordon | try to cast to uintptr_t | 18:28 |
| Pali | freemangordon: casting to (uintptr_t) is possible | 18:28 |
| Pali | but problem is with operation minus | 18:28 |
| Pali | C does not allow that operation at compile time in initliaizer | 18:28 |
| Pali | error: initializer element is not constant | 18:29 |
| Pali | gcc output ^^^^ | 18:29 |
| DocScrutinizer05 | meh | 18:29 |
| freemangordon | Pali: declare structs as const | 18:29 |
| freemangordon | static const even | 18:29 |
| Pali | static are already | 18:29 |
| Pali | will try const | 18:29 |
| Pali | const does not helped, same problem | 18:30 |
| Pali | this is first time I saw someting ugly as this | 18:31 |
| freemangordon | Pali: try to cast the pointers to (const uintptr_t*) | 18:32 |
| Pali | only one solution I see to remove const, initliaze that values to 0L and then use init function for that | 18:32 |
| Pali | (const uintptr_t) | 18:32 |
| Pali | without * | 18:32 |
| freemangordon | :nod: | 18:32 |
| Pali | still not working | 18:32 |
| freemangordon | Pali: the correct way to handle that is to not use offsets :) | 18:32 |
| freemangordon | but to rewrite smiaregs to usee pointers | 18:33 |
| Pali | ok, will try to change smia code | 18:33 |
| Pali | freemangordon: try this patch: http://pastebin.com/M6WdEcYJ | 18:45 |
| FatPhil | Pali: you can't sensibly do "struct A a = { .val = 1 }; struct B b = { .val = &a - &b; };" - it's illegal C | 19:01 |
| FatPhil | You cannot subtract pointers of things which don't point to (parts of) the same object. | 19:01 |
| FatPhil | so I agree with freemangordon - these aren't offsets to C, so don't try and pretend they are. | 19:03 |
| Pali | FatPhil: I already changed code, so that offset (-&b) is not needed and using directly pointer | 19:07 |
| FatPhil | patch on pastebin looks like an improvement, certainly | 19:07 |
| FatPhil | The question that it raises is why the earlier horrors existed - it just looks wrong! | 19:08 |
| freemangordon | Pali: ok | 19:08 |
| FatPhil | Anything which removes casts is generally an improvement to code. | 19:09 |
| Pali | FatPhil: now i think why: that data structures comes from userspace via request_firmware and was created by gcc and objcopy | 19:09 |
| Pali | and in that userspace blob was every structure calucated against some "main" | 19:10 |
| FatPhil | I've not looked into the file as a whole, so take your word on that | 19:10 |
| Pali | and these hacks were needed for converting structures from that userspace blob which comes from request_firmware to native kernel structures | 19:11 |
| Pali | very ugly solution... | 19:11 |
| FatPhil | But the addresses that the compiler gives you (unless you're using linker hacks) tell you nothing about the location of data in firmware. | 19:12 |
| DocScrutinizer05 | yep | 19:12 |
| FatPhil | the compiler's permitted to allocate those structures in alphabetical order, or in reverse | 19:12 |
| FatPhil | The correct solution is to struct all of the structs together | 19:12 |
| DocScrutinizer05 | unless it's one large structure | 19:12 |
| Pali | do not look at that linker hacks... | 19:12 |
| Pali | it using lot of perl code | 19:12 |
| FatPhil | Perl to generate linker hacks? | 19:13 |
| FatPhil | NACK! | 19:13 |
| DocScrutinizer05 | wtf, nmap the firmware file, set readpointer to offset of data structure and read it in from file to local variable struct | 19:14 |
| FatPhil | well, request firmware is the standard way of getting the data in, there's no problem with that. | 19:16 |
| FatPhil | kernel shouldn't filp_open, for example | 19:17 |
| FatPhil | I can't really suggest anything - I don't have any et8ek8 here, I presume that's on my home machine. | 19:18 |
| * FatPhil goes home | 19:18 | |
| FatPhil | (after he's finished his pot of tea) | 19:19 |
| *** arcean has quit IRC | 19:23 | |
| *** bsdmaniak has joined #maemo-ssu | 19:29 | |
| freemangordon | Pali: arch/arm/mach-omap2/board-rx51-peripherals.c:1272:34: warning: 'rx51_t2scripts_data' defined but not used [-Wunused-variable] | 19:31 |
| freemangordon | I guess this is a result from so-called "fix power off/restart problem" or whatever that patch was called | 19:31 |
| Pali | freemangordon: yes, ask more Skry | 19:32 |
| Pali | you can ignore that warning | 19:32 |
| *** dhbiker has joined #maemo-ssu | 20:10 | |
| freemangordon | Pali: hmm, but, but... this struct is the power management scripts, ain;t? | 20:12 |
| *** LauRoman has quit IRC | 20:12 | |
| Pali | freemangordon: yes, but it causing poweroff problems | 20:12 |
| Pali | this needs to be fixed | 20:13 |
| freemangordon | ok | 20:13 |
| DocScrutinizer05 | FatPhil: you had a chance to check the part number on N9 PoP? | 20:19 |
| FatPhil | DocScrutinizer05: didn't know I was going to do that! | 20:36 |
| FatPhil | Isn't that identified in the boot log (although perhaps somewhat cryptically) | 20:36 |
| FatPhil | Can't check - don't have n9 jig | 20:37 |
| DocScrutinizer05 | don't worry, I'll disassemble my N9 then | 20:40 |
| DocScrutinizer05 | thanks nevertheless | 20:40 |
| DocScrutinizer05 | ooops, actually I mixed up things (rather persons), sorry | 20:44 |
| DocScrutinizer05 | and actually not only persons but also channels | 20:46 |
| *** Pali has quit IRC | 20:50 | |
| *** Vlad_on_the_road has joined #maemo-ssu | 20:57 | |
| *** arcean has joined #maemo-ssu | 21:08 | |
| *** Pali has joined #maemo-ssu | 21:12 | |
| *** arcean has quit IRC | 21:16 | |
| *** _nicolai_ has joined #maemo-ssu | 21:27 | |
| *** nox- has joined #maemo-ssu | 21:29 | |
| DocScrutinizer05 | I just noticed a bug in cameraui2: starting it via "Kamera" icon from applauncher opened the gui but didn't show the "Open Lens Door!" display. Opening lens door switched the display to something without any widgets, only viewfinder (and maybe one or two widgets remaining, like focus frame and close button). | 21:52 |
| DocScrutinizer05 | can't reproduce that effect, possibly only "works" after reboot | 21:52 |
| DocScrutinizer05 | comparing to a stock (non-CSSU) system didn't show same effect there | 21:53 |
| *** M4rtinK has joined #maemo-ssu | 22:19 | |
| *** luf has joined #maemo-ssu | 22:30 | |
| *** bsdmaniak has quit IRC | 22:52 | |
| *** sailus_ has quit IRC | 23:01 | |
| *** sailus_ has joined #maemo-ssu | 23:03 | |
| *** NIN101 has quit IRC | 23:06 | |
| *** arcean has joined #maemo-ssu | 23:13 | |
| *** arcean has quit IRC | 23:20 | |
| *** sailus_ has quit IRC | 23:21 | |
| *** sailus has quit IRC | 23:22 | |
| *** sailus has joined #maemo-ssu | 23:22 | |
| *** sailus_ has joined #maemo-ssu | 23:22 | |
| *** Pali has quit IRC | 23:28 | |
| *** DrCode has quit IRC | 23:33 | |
| *** DrCode has joined #maemo-ssu | 23:33 | |
| *** xes has joined #maemo-ssu | 23:39 | |
| *** BCMM has joined #maemo-ssu | 23:50 | |
| *** Vlad_on_the_road has quit IRC | 23:50 | |
| *** lizardo has quit IRC | 23:51 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!