| *** aap has quit IRC | 00:05 | |
| unclouded | didn't know about "--differences=cumulative". nice | 00:20 |
|---|---|---|
| *** Vlad_on_the_road has quit IRC | 00:32 | |
| *** aap has joined #maemo-ssu | 00:33 | |
| *** aap has quit IRC | 00:41 | |
| *** Vlad_on_the_road has joined #maemo-ssu | 00:43 | |
| *** oldtopman has joined #maemo-ssu | 00:49 | |
| *** Vlad_on_the_road has quit IRC | 00:52 | |
| *** aap has joined #maemo-ssu | 01:09 | |
| *** aap has quit IRC | 01:15 | |
| *** Pali has quit IRC | 01:30 | |
| *** NIN101 has quit IRC | 01:48 | |
| *** Martix_ has joined #maemo-ssu | 02:09 | |
| *** Martix has quit IRC | 02:12 | |
| *** aap has joined #maemo-ssu | 02:15 | |
| *** LauRoman has quit IRC | 02:25 | |
| *** Martix_ has quit IRC | 03:08 | |
| *** sunny_s has quit IRC | 03:10 | |
| *** Martix_ has joined #maemo-ssu | 03:13 | |
| *** Martix_ has quit IRC | 03:31 | |
| *** nox- has quit IRC | 03:55 | |
| *** dos1 has quit IRC | 04:25 | |
| *** jonwil has joined #maemo-ssu | 04:30 | |
| *** amiconn_ has joined #maemo-ssu | 05:03 | |
| *** amiconn has quit IRC | 05:03 | |
| *** amiconn_ is now known as amiconn | 05:03 | |
| *** amiconn has quit IRC | 08:47 | |
| *** amiconn has joined #maemo-ssu | 08:47 | |
| *** oldtopman has quit IRC | 09:13 | |
| *** LauRoman has joined #maemo-ssu | 09:28 | |
| *** scoobertron has quit IRC | 09:39 | |
| *** scoobertron has joined #maemo-ssu | 10:18 | |
| *** Pali has joined #maemo-ssu | 10:18 | |
| *** sunny_s has joined #maemo-ssu | 10:22 | |
| *** Pali has quit IRC | 10:51 | |
| *** Pali has joined #maemo-ssu | 10:54 | |
| *** sunny_s has quit IRC | 10:57 | |
| *** LauRoman has quit IRC | 11:05 | |
| *** Vlad_on_the_road has joined #maemo-ssu | 11:18 | |
| freemangordon | Pali: any idea who loads hsi/ssi drivers? | 11:23 |
| *** oooaaaooo has joined #maemo-ssu | 11:32 | |
| *** DrCode has quit IRC | 11:35 | |
| *** DrCode has joined #maemo-ssu | 11:39 | |
| oooaaaooo | hi guys what is the difference between stable & testing? | 11:39 |
| *** dhbiker has quit IRC | 12:15 | |
| *** dhbiker has joined #maemo-ssu | 12:17 | |
| *** NIN101 has joined #maemo-ssu | 12:20 | |
| *** NIN101 has quit IRC | 12:24 | |
| *** NIN102 has joined #maemo-ssu | 12:25 | |
| *** NIN102 is now known as NIN101 | 12:30 | |
| *** Martix_ has joined #maemo-ssu | 12:49 | |
| DocScrutinizer05 | see /topic | 14:28 |
| DocScrutinizer05 | see http://wiki.maemo.org/Community_SSU | 14:28 |
| *** dos1 has joined #maemo-ssu | 14:40 | |
| Pali | freemangordon: no | 14:57 |
| freemangordon | Pali: hmm, no matter what I do, there is no responce from cmt :( | 15:05 |
| freemangordon | it looks like cmt is not powered | 15:06 |
| freemangordon | Pali: did you ever got cmt drivers working with 3.x kernels? | 15:07 |
| freemangordon | *get | 15:07 |
| Pali | I think not, they not worked with 3.5 too | 15:07 |
| freemangordon | weird, Skry had them working | 15:08 |
| freemangordon | seems like the patches you've applied are not the correct ones | 15:08 |
| freemangordon | Pali: do you have a link to nemomobile kernel adaptation git tree? | 15:09 |
| freemangordon | for n900 that is | 15:09 |
| freemangordon | I cant find it | 15:09 |
| Pali | git://github.com/nemomobile/kernel-adaptation-n950-n9.git | 15:09 |
| Pali | git://gitorious.org/meego-device-adaptation/n900_kernel.git | 15:09 |
| Pali | git://github.com/skry/linux.git | 15:09 |
| Pali | git://github.com/skry/linux-n900.git | 15:09 |
| freemangordon | git://gitorious.org/meego-device-adaptation/n900_kernel.git gives 404 | 15:10 |
| Pali | I have these repos ^^^ | 15:10 |
| freemangordon | oh, this is git :D | 15:10 |
| *** bsdmaniak has joined #maemo-ssu | 15:13 | |
| *** bsdmaniak has quit IRC | 15:42 | |
| *** bsdmaniak has joined #maemo-ssu | 15:43 | |
| *** T_X has quit IRC | 16:02 | |
| *** T_X has joined #maemo-ssu | 16:02 | |
| *** Vlad_on_the_road has quit IRC | 16:09 | |
| *** arcean has joined #maemo-ssu | 16:18 | |
| *** Vlad_on_the_road has joined #maemo-ssu | 16:18 | |
| *** arcean_ has joined #maemo-ssu | 16:25 | |
| *** arcean has quit IRC | 16:27 | |
| freemangordon | Pali: why "CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE is not set"? | 16:31 |
| freemangordon | I bet we work without L2 cache | 16:31 |
| Pali | do not know | 16:32 |
| freemangordon | :) | 16:32 |
| Pali | I tried to merge rx51_defconfig from maemo 2.6.28 kernel with omap2plus from 3.5 | 16:32 |
| freemangordon | ok | 16:32 |
| Pali | and result is rx51_defconfig in 3.10 | 16:32 |
| Pali | if there is something missing, enable it | 16:32 |
| freemangordon | ok | 16:32 |
| Pali | also I looked in menuconfig and tried to enable what is needed | 16:33 |
| Pali | but make menuconfig is really really really big | 16:33 |
| freemangordon | Pali: in ssi driver there is something missing, but I don;t know how to readd it using hwmod/clock framework | 16:33 |
| Pali | freemangordon: try to ask sre | 16:33 |
| Pali | he upstreaming now ssi driver | 16:33 |
| Pali | and do not know which version using... | 16:34 |
| freemangordon | it is a function disabling autoidle on dpll3 | 16:34 |
| freemangordon | O bet what he tries to upstream does not work | 16:34 |
| freemangordon | *I | 16:34 |
| Pali | https://lkml.org/lkml/2013/8/11/67 | 16:35 |
| Pali | he could be on #debian | 16:35 |
| freemangordon | Pali: seems there is some HW bug, see ssi_disable_dpll3_autoidle in meego tree | 16:36 |
| freemangordon | sre == Skry ? | 16:36 |
| Pali | no | 16:36 |
| freemangordon | oh | 16:36 |
| Pali | Sebastian Reichel | 16:37 |
| Pali | he porting debian to n900 | 16:37 |
| freemangordon | ok, will look at what he does | 16:37 |
| freemangordon | hmm seems different | 16:40 |
| Pali | freemangordon: maybe we should look at meego n900 kernel tree if there are not some needed patches | 16:42 |
| freemangordon | seems his driver is ported to hwmod | 16:42 |
| *** Vlad_on_the_road has quit IRC | 16:42 | |
| freemangordon | Pali: BTW CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE is the same as my ppa api | 16:45 |
| freemangordon | I mean, it calls smc to save/restore AUX reg | 16:45 |
| freemangordon | without that AUX context get lost on sleep | 16:45 |
| freemangordon | afaik | 16:46 |
| *** arcean_ has quit IRC | 16:56 | |
| Pali | freemangordon: look at commit 1a7e01f01a4af807206de0d26f059c3459f3a1fb in meego n900 git tree | 16:57 |
| Pali | it adding some regulator for camera operation | 16:57 |
| freemangordon | ok | 16:58 |
| Pali | and there is another commit cae12d3ebf22039cc7216f317bebac2f797d2a31 which reduce battery consumption | 16:59 |
| freemangordon | Pali: want to test sri's ssi driver first | 17:00 |
| Pali | there are maybe more interesting patches... | 17:00 |
| Pali | ok | 17:00 |
| freemangordon | :nod: | 17:00 |
| * DocScrutinizer05 honestly wonders what you guys are targeting at | 17:14 | |
| freemangordon | 3.x working with maemo? | 17:15 |
| DocScrutinizer05 | looks like, yeah | 17:15 |
| DocScrutinizer05 | "working" and *working* are two different things though | 17:15 |
| freemangordon | if we can't make it on n900, we aon;t be able to do it on neo900 as well | 17:16 |
| freemangordon | *can't | 17:16 |
| DocScrutinizer05 | maybe that whole effort turn out to be futile in the end - see my recent rant why you frequently regularly want to or even have to "fork" and run your own kernel flavor for embedded | 17:17 |
| freemangordon | DocScrutinizer05: yep, but lets see what we can do with upstream first | 17:17 |
| DocScrutinizer05 | sure | 17:17 |
| DocScrutinizer05 | :-) | 17:17 |
| freemangordon | before doing forks :) | 17:17 |
| DocScrutinizer05 | after all you *should* be able to forward-port _all_ the nice powermanagement patches that we find in maemo kernel | 17:18 |
| freemangordon | :nod: | 17:18 |
| freemangordon | BTW I think part of them are already upstreamed | 17:18 |
| freemangordon | but don;t ask me which prts :D | 17:18 |
| *** FlameReaper has joined #maemo-ssu | 17:18 | |
| DocScrutinizer05 | if the result will go upstream ever that's another question | 17:18 |
| freemangordon | sure | 17:18 |
| DocScrutinizer05 | but we should be able to get a recent kernel with powersaving as good as maemo 1.6.28 | 17:19 |
| DocScrutinizer05 | 2.6.... | 17:19 |
| DocScrutinizer05 | typo | 17:19 |
| DocScrutinizer05 | then also revert all the damage done to sysfs etc by kernel devels ;-) Done | 17:20 |
| freemangordon | Pali: re camera - we already have that regulator, but board code is missing the ".supply = "vaux2" part | 17:21 |
| freemangordon | NFC if that matters | 17:21 |
| DocScrutinizer05 | in the end it doesn't matter if you backport 80 patches into KP57 or forward port 150 Nokia patches and rollbacks to linus kernel 3.11 | 17:21 |
| DocScrutinizer05 | the result in the end should be identical | 17:21 |
| freemangordon | sure | 17:22 |
| freemangordon | the easy way is to use KP :) | 17:22 |
| *** sixwheeledbeast has joined #maemo-ssu | 17:22 | |
| freemangordon | but we rather keep that as a fallback | 17:23 |
| DocScrutinizer05 | I strongly support any such project you're doing. It helps us acquire better knowledge about our kernel | 17:23 |
| DocScrutinizer05 | and in the end both approaches will result in same final "product" | 17:23 |
| DocScrutinizer05 | when done correctly and comprehensive | 17:24 |
| freemangordon | sure, but having upstream kernel working is preferable imo | 17:24 |
| freemangordon | we can use it for other distros as well | 17:24 |
| DocScrutinizer05 | as already explained. The 100% finalized result is identical for both approaches. It's the different flaws you get for 99% finalized versions that makes the difference | 17:25 |
| DocScrutinizer05 | for the KP approach you will miss functions or see broken functions that are new to 3.11. For the linus branch aproach you will see flawed power management | 17:26 |
| DocScrutinizer05 | after fixing those flaws, both end results are 100% identical | 17:27 |
| DocScrutinizer05 | you definitely can use stock maemo kernel for other distros as well. See easydeb | 17:30 |
| DocScrutinizer05 | the question is what's the effort to port any such kernel to other hw platforms | 17:30 |
| DocScrutinizer05 | and keep it up to date | 17:30 |
| DocScrutinizer05 | for both the linusbranch approach has clear advantages | 17:31 |
| DocScrutinizer05 | for maemo stability at large, the KP approach is clearly the better one | 17:31 |
| DocScrutinizer05 | I'm just a tiny bit worried that users might think this project is closely related to CSSU which clearly it isn't and shouldn't | 17:33 |
| DocScrutinizer05 | we maybe need to mint a new term, like e.g. CSSU-Factory | 17:34 |
| DocScrutinizer05 | or CSSU-Lab | 17:34 |
| DocScrutinizer05 | would make a nice home for FPTF as well | 17:35 |
| DocScrutinizer05 | in the end Neo900 maemo will be a "new distro" no matter how binary compatible it might be for apps | 17:36 |
| DocScrutinizer05 | CSSU-S/T clearly is NO new distro | 17:36 |
| DocScrutinizer05 | a common misconception | 17:37 |
| DocScrutinizer05 | introducing a new noticeably different (on API/revision level) kernel pretty much qualifies for "new distro" | 17:38 |
| *** DrCode has quit IRC | 17:40 | |
| *** hatake_kakashi has joined #maemo-ssu | 17:40 | |
| freemangordon | Pali: hmm, sri's driver makes no difference :( | 17:46 |
| DocScrutinizer05 | maybe you want to check e.g SHR, it has working BB5 modem on N900 | 17:47 |
| DocScrutinizer05 | ask dos1 | 17:47 |
| freemangordon | any link to kernel tree? | 17:47 |
| freemangordon | ok | 17:47 |
| Sicelo | who's sri? | 17:47 |
| DocScrutinizer05 | sre | 17:48 |
| Sicelo | ok. | 17:48 |
| Pali | sre = Sebastian Reichel | 17:48 |
| Pali | working with debian on n900 | 17:48 |
| *** DrCode has joined #maemo-ssu | 17:48 | |
| freemangordon | hmm, he is not on #debian | 17:48 |
| Sicelo | he's not done with the modem driver yet. | 17:48 |
| Sicelo | quickest way to get him is Jabber | 17:49 |
| DocScrutinizer05 | ~shr | 17:49 |
| infobot | i heard shr is The Stable Hybrid Release (SHR), intended to be a community driven distribution composed of the FSO and some basic applications, that can be configured to use several different graphical toolkits, for example GTK or EFL. SHR is based on the FSO build. At first, SHR was introduced in order to use the Openmoko2007.2 GTK software in combination with the new FSO, but things have changed. | 17:49 |
| Sicelo | dunno why, but he's been mia on IRC for a while now | 17:49 |
| Pali | freemangordon: sre has wireshark plugin for isi: http://sre.ring0.de/ | 17:49 |
| Pali | maybe it can be used for debugging | 17:50 |
| freemangordon | Pali: we are far from this ste, the modem seems to be either powered off or with no clk | 17:50 |
| freemangordon | *step | 17:50 |
| Sicelo | that's why he needed a serial adapter :P | 17:51 |
| DocScrutinizer05 | http://shr-project.org/trac | 17:51 |
| freemangordon | Jan 1 06:22:38 Nokia-N900 kernel: [ 21.256744] SSI protocol aka McSAAB added | 17:51 |
| freemangordon | Jan 1 06:22:38 Nokia-N900 kernel: [ 21.291198] cmt_speech cmt_speech: hsi_client_probe | 17:51 |
| freemangordon | Jan 1 06:22:38 Nokia-N900 kernel: [ 21.331665] ssi_protocol ssi_protocol: Configuring SSI port | 17:51 |
| Pali | freemangordon: look at sre kernel tree: http://sre.ring0.de/linux/ | 17:51 |
| freemangordon | Jan 1 06:22:38 Nokia-N900 kernel: [ 21.331787] ssi_protocol ssi_protocol: Issuing BOOT INFO REQ command | 17:51 |
| freemangordon | Jan 1 06:22:38 Nokia-N900 kernel: [ 21.331817] hsi_async 346 | 17:51 |
| freemangordon | Jan 1 06:22:38 Nokia-N900 kernel: [ 21.337951] ssi_protocol ssi_protocol: Issuing RX command | 17:51 |
| freemangordon | Jan 1 06:22:38 Nokia-N900 kernel: [ 21.337982] hsi_async 346 | 17:51 |
| DocScrutinizer05 | Pali: II have ISI plugin for wireshark ;-) | 17:51 |
| freemangordon | Pali: and ^^^ is all I have, modem does not respond to "BOOT INFO REQ" | 17:52 |
| DocScrutinizer05 | http://talk.maemo.org/showthread.php?p=1022444#post1022444 | 17:53 |
| DocScrutinizer05 | ;-D | 17:53 |
| DocScrutinizer05 | freemangordon: NB the cmt_speech is a upper layer that uses a virtual channel in the low level ISI interface to BB5 | 17:56 |
| DocScrutinizer05 | before even bothering about cmt_speech, you should get basic communication to BB5 working | 17:56 |
| freemangordon | :nod: | 17:56 |
| DocScrutinizer05 | ISI is a bitch | 17:57 |
| Pali | freemangordon: https://elektranox.org/n900/contact.html | 17:57 |
| DocScrutinizer05 | iirc you need a quite complicated strictly defined sequence of actions to crank it up | 17:58 |
| DocScrutinizer05 | worse than e.g. USB | 17:58 |
| freemangordon | DocScrutinizer05: yep, by using gpio pins | 17:59 |
| DocScrutinizer05 | not only, that's actually not even ISI | 17:59 |
| DocScrutinizer05 | ISI is a "network protocol" | 17:59 |
| dos1 | SHR on N900 is using 2.6.37 | 17:59 |
| DocScrutinizer05 | similar to TCP/IP | 17:59 |
| freemangordon | to power the modem up that is | 17:59 |
| dos1 | recipe is named "linux-nokia900-meego" | 17:59 |
| freemangordon | dos1: oh, pretty old I'd say :) | 17:59 |
| dos1 | yup | 18:00 |
| freemangordon | modem was working there | 18:00 |
| dos1 | development pretty much stalled after some initial work | 18:00 |
| dos1 | so it probably won't be useful | 18:00 |
| Pali | freemangordon: he is probably under irc name elektranox | 18:01 |
| DocScrutinizer05 | it's at least nit like "power up cmt, send AT, receive OK" | 18:01 |
| DocScrutinizer05 | not* | 18:01 |
| DocScrutinizer05 | you need to *establish* the connection | 18:01 |
| freemangordon | Pali: hmm, lemme try to reach him | 18:01 |
| Sicelo | his nick was just 'sre' when he was still available. xmpp is the quickest way as mentioned above | 18:02 |
| DocScrutinizer05 | >SSI protocol aka McSAAB added< and immediately then >cmt_speech cmt_speech: hsi_client_probe< looks completely odd and fishy anyway | 18:02 |
| DocScrutinizer05 | cmt_speech CANNOT work immediately after adding the low level PHY driver | 18:03 |
| freemangordon | yep, seems like function calls were wrong | 18:03 |
| freemangordon | DocScrutinizer05: though that should not prevent from communication with the modem | 18:04 |
| Pali | look at /msg NickServ info elektranox | 18:07 |
| Sicelo | ah, freenode.. :) | 18:08 |
| freemangordon | /msg NickServ info elektranox | 18:08 |
| Sicelo | i used to find him on OFTC | 18:09 |
| Pali | really above is his irc freenode nick | 18:09 |
| freemangordon | :nod: | 18:09 |
| Pali | use xmpp or email | 18:09 |
| Pali | now he is offline | 18:09 |
| Sicelo | on xmpp he's right now online, but marked DND. around UTC 1800, he's usually online | 18:10 |
| DocScrutinizer05 | freemangordon: cmt_speech is similar to a USB soundcard driver. HSI is similar to PCI where a NIC is plugged in. ISI is similar to the TCP stack, and your "soundcard" you want to talk to via cmt_speech would be attached via USB-over-TCP/IP | 18:11 |
| freemangordon | DocScrutinizer05: I understand that :) | 18:11 |
| DocScrutinizer05 | :-) | 18:14 |
| freemangordon | Pali: http://sre.ring0.de/linux/log/?h=ssi-cleaned-dt | 18:14 |
| freemangordon | I guess we shall wait for that to go upstream :) | 18:14 |
| DocScrutinizer05 | fsck DT | 18:15 |
| freemangordon | yeah :( | 18:15 |
| DocScrutinizer05 | another kernel devs' brainfart, eh? | 18:15 |
| Sicelo | but the linux-arm ML is clearly biased towards DT now.. looks like they just dismiss anything not DT | 18:16 |
| DocScrutinizer05 | feels like kernel devels invented a general way to describe arbitrarly shaped areas that are hw paltforms, but in RL hw platforms are not areas but 3D objects like irregular toroids etc | 18:17 |
| DocScrutinizer05 | some might even be higher-dimensional | 18:18 |
| DocScrutinizer05 | good luck for describing this via polygons | 18:19 |
| Sicelo | they'll tell you that gfx cards do that :p | 18:19 |
| DocScrutinizer05 | they will suffer a terrible mistake then, sinc graca only produce 2D projections of the real worls | 18:21 |
| DocScrutinizer05 | world even | 18:21 |
| DocScrutinizer05 | a pixmap is elementarily incapable to describe 3D objects comprehensively, and likewise it seems to me DT is incapable of describing real hw platforms in a sufficiently flexible manner | 18:23 |
| Sicelo | anyway, /me doesn't know sh*t about kernel development lol, just that i have had a chance to talk to people like sre before | 18:24 |
| jonwil | bah, my N900 work is getting me nowhere. Need to find something useful to do... | 18:25 |
| DocScrutinizer05 | well, I've seen kernel concepts come and go. And I guess DT is not one of the concepts here to stay | 18:32 |
| jonwil | what exactly is DT? | 18:35 |
| DocScrutinizer05 | just like maemo got rid of initrd, since initrd is nonsense for a highly specialized kernel meant to run on one well defined and immutable platform only | 18:35 |
| DocScrutinizer05 | jonwil: Device Tree. a description of *all* the hardware you find on the platform, incl all its properties | 18:36 |
| DocScrutinizer05 | drivers know sh*t about how to handle that particular platform, they look into DT to decide what to do. Basically | 18:37 |
| DocScrutinizer05 | bbl | 18:37 |
| *** Vlad_on_the_road has joined #maemo-ssu | 18:37 | |
| DocScrutinizer05 | "which powersupply to ramp up to power that WLAN module?" -> "look into DT" | 18:39 |
| DocScrutinizer05 | "which interface to use to talk to the power supply to tell it to ramp-up?" -> "look into DT" | 18:40 |
| DocScrutinizer05 | aiui | 18:40 |
| jonwil | I can see now why its not so good for all platforms | 18:40 |
| *** DrCode has quit IRC | 18:40 | |
| jonwil | where its incapable of describing all the things you need to describe | 18:41 |
| DocScrutinizer05 | it's an idiotic idea in some cases | 18:41 |
| *** FlameReaper has quit IRC | 18:41 | |
| DocScrutinizer05 | yes, exactly | 18:41 |
| jonwil | if its idiotic, why do kernel devs want to persist with it? | 18:41 |
| DocScrutinizer05 | because it's so... computer-scientific | 18:42 |
| DocScrutinizer05 | BBLFRN | 18:42 |
| DocScrutinizer05 | o/ | 18:42 |
| *** FlameReaper has joined #maemo-ssu | 18:43 | |
| jonwil | If I had a dollar for every time I heard of a programmer continuing to persist with stupid code and continuing to not accept better ways of doing things, I would probably have enough money that I wouldn't need to write code for a living and could just retire... :P | 18:44 |
| *** DrCode has joined #maemo-ssu | 18:44 | |
| Pali | DocScrutinizer05: DT is bettern then ACPI DSDT | 18:44 |
| jonwil | GOOD programmers will listen when someone says "I have a better way to do xyz" | 18:44 |
| *** FlameReaper has quit IRC | 18:45 | |
| Pali | ACPI is undebugable and unparsable | 18:45 |
| Pali | and human unreadable | 18:45 |
| Pali | and even worse machine not executable... | 18:45 |
| Pali | and needs own VM | 18:45 |
| Pali | and acpica in kernel! | 18:46 |
| Pali | and thanks to MS who created proprietary extension WMI which is now used for evryething | 18:46 |
| jonwil | Good luck getting ACPI working unless you reverse engineer Windows and do EXACTLY what Windows does (since that's all most motherboard vendors test against) | 18:46 |
| ShadowJK | A lot of the bugs come from the code assuming the OS will do X, and not checking if OS did X | 18:46 |
| Pali | thank you, rather DT | 18:47 |
| ShadowJK | yeah what jonwil said :) | 18:47 |
| ShadowJK | acpi is otherwise a cool idea, replacing BIOS roms running real mode code with a portable bytecode | 18:47 |
| Pali | portable bytecode? really? it is bytecode designed for x86 | 18:48 |
| Pali | I'm not able to decompile my DSDT because it has invalid sequences... | 18:49 |
| Pali | and ability to patch it is not possible | 18:49 |
| ShadowJK | Kernel patches it all the time :-) | 18:50 |
| jonwil | is there a better way to do the kind of stuff embedded ARM needs than DT? | 18:50 |
| *** jonwil has quit IRC | 18:53 | |
| DocScrutinizer51 | FFS, queue at the voting booths :-( | 19:05 |
| DocScrutinizer51 | ~xyawn | 19:06 |
| infobot | good coffee | 19:06 |
| DocScrutinizer51 | where? | 19:06 |
| DocScrutinizer05 | well, ACPI never *really* worked for me and my linux boxen | 19:22 |
| DocScrutinizer05 | since ACPI is not one of the selling points you check when picking a MoBo | 19:23 |
| DocScrutinizer05 | thus vendors do whatever shite, as long as it works with windows (like jonwil said) | 19:24 |
| DocScrutinizer05 | industry level PCs are a tad fifferent I guess | 19:24 |
| DocScrutinizer05 | different even | 19:24 |
| *** Vlad_on_the_road has quit IRC | 19:38 | |
| DocScrutinizer05 | in the end DT and ACPI are a good thing for general purpose one-kernel-fits-all approach that is used for x86 PC. For a highly tailored-to-fit "custom" kernel designed to perform as good as possible on one particular embeeded device like N900, you better forget about any such concept all together | 19:41 |
| DocScrutinizer05 | s/eede/edde/ | 19:41 |
| infobot | DocScrutinizer05 meant: in the end DT and ACPI are a good thing for general purpose one-kernel-fits-all approach that is used for x86 PC. For a highly tailored-to-fit "custom" kernel designed to perform as good as possible on one particular embedded device like N900, you better ... | 19:41 |
| DocScrutinizer05 | really, shoehorning a concept like ACPI (or DT?) onto a device that doesn't even have any BIOS to support the idea's founding requirements - that feels more than silly to me | 19:45 |
| DocScrutinizer05 | "first let's ponder how to hardcode a ACPI emulator into the kernel to compensate for missing BIOS with real DSDT/ACPI tables. Then we try to figure how we can read out that crap and nevertheless *despite* of it do the right thing for our particular platform, for which we need custom patches to 50% of device drivers anyway and those patches will never make it upstream" - outright ridiculous | 19:50 |
| DocScrutinizer05 | that's the moment when you want to "fork" | 19:52 |
| DocScrutinizer05 | which so far every single embedded project I know of eventually did | 19:53 |
| *** Vlad_on_the_road has joined #maemo-ssu | 19:53 | |
| DocScrutinizer05 | maybe they don't call it "fork" | 19:54 |
| DocScrutinizer05 | but in the end it is. Just a highly customized kernel (and userland) that has no chances to go upstream | 19:54 |
| DocScrutinizer05 | upstream is PC centric, and it gets more and more PC centric every day dudes like Poettering rush over it | 19:55 |
| DocScrutinizer05 | systemd My ASS. Definitely the ideal concept for embedded | 19:58 |
| * ShadowJK just setup a board with 64M ram and systemd :) | 20:00 | |
| DocScrutinizer05 | and android madness bleeding into linux recently doesn't help either | 20:00 |
| DocScrutinizer05 | newsflash time | 20:00 |
| DocScrutinizer05 | o/ | 20:01 |
| dos1 | what makes systemd so unsuited for embedded? | 20:01 |
| DocScrutinizer05 | the overhead | 20:03 |
| DocScrutinizer05 | or let me put it this way: the philosophy behind it | 20:03 |
| DocScrutinizer05 | systemd makes /usr mandatory during *early* boot | 20:04 |
| DocScrutinizer05 | actually it abolishes /usr | 20:04 |
| DocScrutinizer05 | it also abolishes udev | 20:04 |
| DocScrutinizer05 | but not to replace it by sth more lightweight | 20:05 |
| DocScrutinizer05 | HECK, systemd *needs* d-bus last I tried to check | 20:06 |
| nedko | systemd works in pair with udev | 20:07 |
| DocScrutinizer05 | and don't get me started on d-bus | 20:07 |
| dos1 | hehe | 20:07 |
| nedko | :) | 20:07 |
| wmarone_ | AF_DBUS | 20:07 |
| nedko | wmarone_: it is in mainline? | 20:07 |
| wmarone_ | Haven't looked into it in a while | 20:08 |
| nedko | DocScrutinizer05: in fact systemd and udev are quite coupled. what they abolish is hal | 20:09 |
| DocScrutinizer05 | last I checked systemd simply scooped up and abolished udev | 20:10 |
| DocScrutinizer05 | but I know of embedded systems that opted out from udev in favour for sth more lightweight | 20:11 |
| DocScrutinizer05 | I don't see how that goes along with systemd | 20:11 |
| DocScrutinizer05 | I also know of embedded systems (actually a friggin lot) that don't need nor want nor have the grunt to run d-bus | 20:12 |
| DocScrutinizer05 | and it's only a matter of time until systemd eats PA and makes that mandatory as well, as otherwise no "beep beep I'm up! Greetings, Poettering" audio on loading the kernel | 20:13 |
| nedko | DocScrutinizer05: what is more lightweight but has the same functionality than udev and d-bus? | 20:13 |
| DocScrutinizer05 | no d-bus | 20:14 |
| DocScrutinizer05 | no udev | 20:14 |
| nedko | no d-bus no udev -> no features they provide | 20:14 |
| DocScrutinizer05 | fsck the "functionality" | 20:14 |
| DocScrutinizer05 | so WHAT? | 20:14 |
| dos1 | but you don't always need features they provide | 20:14 |
| DocScrutinizer05 | exactly | 20:14 |
| dos1 | I know that SHR was using devtmpfs instead of udev for some time | 20:15 |
| DocScrutinizer05 | yep | 20:15 |
| DocScrutinizer05 | for example | 20:15 |
| DocScrutinizer05 | you can even run a system on statically configured devices | 20:15 |
| DocScrutinizer05 | and *d-bus*??? PFFF! | 20:16 |
| nedko | DocScrutinizer05: no IPC? or some other IPC mechanism? | 20:16 |
| DocScrutinizer05 | google IPC! | 20:16 |
| DocScrutinizer05 | it's not like d-bus invented that | 20:17 |
| dos1 | just checked, it's still using devtmpfs | 20:17 |
| DocScrutinizer05 | nor did Poettering | 20:17 |
| nedko | of course, dbus is just what is the best IPC we have on linux | 20:17 |
| dos1 | but well, together with systemd | 20:17 |
| nedko | maybe not for low resource systems though | 20:17 |
| DocScrutinizer05 | nedko: says WHO? | 20:17 |
| nedko | DocScrutinizer05: i say it | 20:17 |
| dos1 | but dunno if it would be still possible with upgraded systemd | 20:17 |
| DocScrutinizer05 | I'm proud to differ | 20:17 |
| nedko | DocScrutinizer05: this is why i asked you what you think is better | 20:18 |
| dos1 | dbus is the most popular IPC system | 20:18 |
| DocScrutinizer05 | I think I wouldn't be as silly as saying "XY is *best*" - since there never is ONE _best_ thing | 20:18 |
| dos1 | but that doesn't make it the best automatically | 20:18 |
| DocScrutinizer05 | exactly | 20:18 |
| kerio | dbus is a piece of crap, but it's the less shitty of the generic IPC systems | 20:19 |
| kerio | *least | 20:19 |
| nedko | of course, there are use cases when you don't event want linux | 20:19 |
| kerio | but, especially on an embedded system, why do you need a generic ipc system? | 20:20 |
| DocScrutinizer05 | and there are situations where I don't want to continue such discussions | 20:20 |
| nedko | i think the level of functionality/features maemo5 provides demands the features provided by dbus | 20:20 |
| DocScrutinizer05 | who said "maemo"? | 20:21 |
| nedko | maybe this is not embedded enough | 20:21 |
| DocScrutinizer05 | do we have systemd on maemo? NO WE DONT and I'm pretty happy about that | 20:21 |
| nedko | maemo is always implicit in this channel, no? :) | 20:21 |
| kerio | actually, even a lot less embedded | 20:21 |
| kerio | on a fucking server | 20:21 |
| kerio | why would i want dbus? | 20:21 |
| DocScrutinizer05 | indeed | 20:21 |
| kerio | or pulseaudio | 20:22 |
| DocScrutinizer05 | because damn Poettering thinks you mustn't have login without accessability and I18n support | 20:22 |
| DocScrutinizer05 | you MUST NOT | 20:23 |
| DocScrutinizer05 | or you're free to use... _not_ linux | 20:23 |
| dos1 | well, i'm using systemd on my pc; but each time when i remind myself that the same person who's responsible for it did pulseaudio, I think I might want to reconsider it ;] | 20:23 |
| nedko | i dont want to troll you but you sound like a datenwolf... :] | 20:23 |
| nedko | i dislike pulseaudio but i like systemd | 20:24 |
| DocScrutinizer05 | excuse me for not even googling the term, couldn't care less. please refrain from explaining it to me | 20:24 |
| nedko | it is a good thing for a dynamic system | 20:24 |
| DocScrutinizer05 | maybe the concept is a good one, the implementation is abysmal and unbearable | 20:25 |
| DocScrutinizer05 | so is the attitude driving it onto us | 20:26 |
| nedko | it is open source... | 20:26 |
| DocScrutinizer05 | go away with your "it's FOSS" | 20:26 |
| nedko | we are free to implement it better or improve it | 20:26 |
| dos1 | we are free to not use it | 20:27 |
| DocScrutinizer05 | which is the only alternative | 20:27 |
| nedko | dos1: this too :) | 20:27 |
| DocScrutinizer05 | you WLL NOTimprove the fucked up API | 20:28 |
| DocScrutinizer05 | you WILL NOT remove the d-bus dependencies | 20:28 |
| DocScrutinizer05 | it's like claiming "the plans for the hoover dam are public, you're free to improve them" | 20:29 |
| nedko | o.0 | 20:29 |
| DocScrutinizer05 | improving systemd means abolishing it and replacing it by something now (or old) | 20:30 |
| nedko | do you mean we don't have the resource to change the direction coprorate open source is pushing to? | 20:30 |
| DocScrutinizer05 | just like Poettering did with ALSA, though ALSA was easy to improve and add the allegedly missing capabilities PA was meant to deliver but failed *epically* | 20:31 |
| nedko | PA actually relies on ALSA | 20:31 |
| DocScrutinizer05 | s/sth now/sth new/ | 20:31 |
| nedko | in some aspect, PA extends ALSA | 20:32 |
| nedko | it doesnt abolish ALSA | 20:32 |
| DocScrutinizer05 | nedko: believe me *I* know that | 20:32 |
| DocScrutinizer05 | and no, it only depends on ALSA soundcard implementations | 20:32 |
| DocScrutinizer05 | since Poettering boggled from that part | 20:33 |
| nedko | not really but i'm not going to argue on this | 20:33 |
| nedko | at least not here | 20:33 |
| DocScrutinizer05 | anyway, I'm out. This discussion is futile | 20:33 |
| * thedead1440 wonders if poettering ever made it into any of the #maemo* chans; he would certainly be delighted :p | 20:50 | |
| nedko | thedead1440: this [pa/systemd/udev thing] is hardly news | 20:54 |
| nedko | i was hit by it more than 5 years ago | 20:54 |
| nedko | lennart probably earlier | 20:54 |
| *** LauRoman has joined #maemo-ssu | 20:56 | |
| *** nox- has joined #maemo-ssu | 20:57 | |
| *** Milhouse has joined #maemo-ssu | 21:03 | |
| *** sailus has quit IRC | 21:42 | |
| *** bsdmaniak has quit IRC | 21:49 | |
| Pali | PA using kernel ALSA | 22:10 |
| Pali | because kernel ALSA is maybe only interface for kernel audio drivers (OSS in linux kernel is dead?) | 22:10 |
| nedko | app -> alsa (API) -> PA -> alsa (API) -> kernel | 22:29 |
| nedko | that said, alsa is overengeneered too :) | 22:29 |
| *** arcean_ has joined #maemo-ssu | 22:32 | |
| DocScrutinizer05 | "alsa (API)" is a pretty crappy compatibility layer | 22:38 |
| DocScrutinizer05 | the left one | 22:38 |
| DocScrutinizer05 | the right one is basically not existing, just "hw:0.0" soundcard ALSA kernel driver | 22:39 |
| kerio | kernel -> audio card is probably a lot more interesting | 23:01 |
| kerio | and we're lucky that it's too low level for lennart | 23:01 |
| kerio | or he would've fucked that up too | 23:01 |
| *** arcean_ has quit IRC | 23:06 | |
| DocScrutinizer05 | ack | 23:27 |
| *** Vlad_on_the_road has quit IRC | 23:33 | |
| *** freemangordon_ has joined #maemo-ssu | 23:55 | |
| *** freemangordon has quit IRC | 23:55 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!