| 00:39.57 | *** part/#maemo-ssu obironbo (~chatzilla@tn-76-7-165-130.sta.embarqhsd.net) |
| 01:13.41 | *** join/#maemo-ssu wmarone (~wmarone@c-67-174-151-253.hsd1.ca.comcast.net) |
| 02:09.27 | *** join/#maemo-ssu amiconn_ (quassel@rockbox/developer/amiconn) |
| 02:17.17 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 07:46.45 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
| 08:02.27 | *** join/#maemo-ssu NIN101 (~NIN@p5DD281E3.dip0.t-ipconnect.de) |
| 08:19.59 | *** join/#maemo-ssu Free-MG (~test@p4FFE7B49.dip.t-dialin.net) |
| 09:27.33 | *** join/#maemo-ssu _rd (~rd@p57B48177.dip0.t-ipconnect.de) |
| 10:03.41 | *** join/#maemo-ssu arcean (~Arcean@aacy105.neoplus.adsl.tpnet.pl) |
| 10:13.02 | *** join/#maemo-ssu _rd (~rd@p57B48177.dip0.t-ipconnect.de) |
| 10:21.14 | *** join/#maemo-ssu smoku (~spectrum@xkh0g2.infr.xiaoka.com) |
| 10:31.44 | *** join/#maemo-ssu mase76 (~mase76@p5DD3AFC1.dip.t-dialin.net) |
| 10:50.04 | *** join/#maemo-ssu jonwil (~jonwil@27-33-137-199.static.tpgi.com.au) |
| 10:54.41 | *** join/#maemo-ssu arcean_ (~Arcean@aacx104.neoplus.adsl.tpnet.pl) |
| 11:26.16 | *** join/#maemo-ssu _rd (~rd@p57B48177.dip0.t-ipconnect.de) |
| 11:34.17 | *** join/#maemo-ssu DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 14:08.55 | *** part/#maemo-ssu smoku (~spectrum@xkh0g2.infr.xiaoka.com) |
| 14:09.03 | *** join/#maemo-ssu smoku (~spectrum@xkh0g2.infr.xiaoka.com) |
| 14:10.09 | smoku | configure: error: Package requirements (hildon-libs >= 0.12.0) were not met |
| 14:10.15 | smoku | what is hildon-libs? |
| 14:11.22 | smoku | is it some closed package? as I can find hildon-libs-l10n-public only in repository |
| 14:27.54 | merlin1991 | smoku: which package are you trying to build? |
| 14:28.26 | smoku | merlin1991: osso-xterm |
| 14:29.16 | smoku | I already found out - it's an old name of libhildon, which it falls back to when hildon-1.pc is not present |
| 14:35.54 | DocScrutinizer | o/ merlin1991 |
| 14:36.50 | merlin1991 | o/ DocScrutinizer |
| 14:47.26 | DocScrutinizer | just idly wondered if chemist and other tmo mods have a permanent appointment with their psychologist, to not lose their mind about tmo shit |
| 14:53.58 | MohammadAG | I'm assuming the meeting is still up for tomorrow? |
| 14:54.14 | DocScrutinizer | sure thing |
| 14:54.47 | DocScrutinizer | any comments in advance, to think about til tomorow? |
| 14:55.18 | MohammadAG | Since the speed of light was recently broken, what other physics statements are BS? :P |
| 14:55.35 | DocScrutinizer | ???? |
| 14:55.45 | *** join/#maemo-ssu Sc0rpius (~naikel@190.78.151.78) |
| 14:55.56 | DocScrutinizer | speed of light been "broken" since ages |
| 14:56.12 | MohammadAG | http://gizmodo.com/5908206/did-scientists-really-just-break-the-speed-of-light |
| 14:56.16 | MohammadAG | rebroken then |
| 14:56.44 | DocScrutinizer | there's just no way info propagates fatser than light in vacuum, to a place that's not already entangled with your location |
| 14:58.31 | DocScrutinizer | IOW e.g. tunneling happens with trans-SOL, but obviously for tunneling both ends of the tunnel previously got entangled by any sub-SOL process like installing a physical tube or whatever |
| 15:01.14 | DocScrutinizer | most spectacular such super-SOL information transfer been demonstrated via entangled photons, over distances like width of a river - when one riverside you do sth to the one photon, on the other riverside the info was instantly available on entangled "sibling"-photon |
| 15:01.47 | DocScrutinizer | quite obviously prior to that the one photon had to cross the river at light speed |
| 15:02.17 | DocScrutinizer | as you can entangle them only when they share same location in space-time |
| 15:03.49 | DocScrutinizer | so you as well could consider this like info is traveling back in time to the moment both photons shared same location, then madatorily takes opposite direction in time moving forward to same moment but on other photon |
| 15:04.24 | DocScrutinizer | quite intriguing a topic |
| 15:04.45 | MohammadAG | see? I'm good at brainstormers :p |
| 15:04.46 | DocScrutinizer | but never really broke the fundamental meaning of SOL being the speed limit |
| 15:06.11 | DocScrutinizer | there's even cherenkov-radiation happening per definition when particles move at trans-SOL. Obviously it only can happen in any medium but not in vacuum, as SOL in vacuum is speed limit |
| 15:08.07 | DocScrutinizer | blue glowing of water moderated atomic reactors commonly atrributed to cherenkov radiation (though I seem to recall that's actually incorrect) |
| 15:13.57 | DocScrutinizer | sigh, I could've read that URL'd page prior to elaborating on my physics knowledge. They absically explained it already |
| 15:22.14 | *** join/#maemo-ssu Pali (~pali@unaffiliated/pali) |
| 15:26.50 | DocScrutinizer | just had a great idea to follow a MrTesla-alike concept and start propagating a field of entangled photons unidirectional, so in 10 years everybody could communicate with any point in a 10 lightyears diameter from earth with zero delay |
| 15:27.50 | DocScrutinizer | an obviously useless idea, but anyway, I think I might find sponsors |
| 15:28.00 | DocScrutinizer | :-D |
| 15:38.28 | DocScrutinizer | another funny question: maybe *all* barionic matter is entangled since big bang? |
| 15:39.12 | DocScrutinizer | anyway, not exactly on topic for tomorrow's meeting |
| 15:39.24 | merlin1991 | hhr |
| 15:39.38 | DocScrutinizer | MohammadAG: what's your take on the optional packages for CSSU? |
| 15:39.48 | merlin1991 | I'm still trying to find a proper way todo it |
| 15:40.02 | merlin1991 | 2 packages + transistional package is bad (rootfs space) |
| 15:40.30 | merlin1991 | 1 package is impossible since ham would put it under updates |
| 15:40.48 | merlin1991 | 2 packages with conflict to first is something it'd have to check if ham does it properly |
| 15:41.06 | DocScrutinizer | after we wanna hear some semi-feasible reasonable suggestions how to proceed and implement that needed functionality, tomorrow |
| 15:41.44 | merlin1991 | yeah I'll have to play a bit with ham tonight :D |
| 15:41.48 | DocScrutinizer | maybe a true new repo was most straight way to go? |
| 15:42.09 | MohammadAG | easy fix |
| 15:42.16 | merlin1991 | that would only allow us an all or nothing apprach for the 1 package solution |
| 15:42.16 | MohammadAG | may not be clean, but HAM is far from that |
| 15:42.31 | MohammadAG | since CSSU-extras depends on HAM, patch HAM to not show packages from it |
| 15:42.51 | MohammadAG | or add XB-Maemo-Flags: not-a-freaking-update |
| 15:42.52 | merlin1991 | and HOW do you install them then? |
| 15:42.59 | DocScrutinizer | merlin1991: I fail to get your "one pkg" stanza |
| 15:43.07 | MohammadAG | well, that flag would make them show under install |
| 15:43.18 | MohammadAG | or download, or whatever the middle button's text is |
| 15:43.19 | merlin1991 | MohammadAG: and what is for updates then? |
| 15:43.24 | merlin1991 | ie you have installed re version X |
| 15:43.34 | merlin1991 | and version Y comes out but is a real update now? |
| 15:43.50 | MohammadAG | if (not-an-update && currentmaintainer: Nokia) show under install |
| 15:44.01 | MohammadAG | if (not-an-update && currentmaintainer: else) update |
| 15:44.03 | DocScrutinizer | we dn't need updates, do we? if yes then for what? |
| 15:44.03 | merlin1991 | also this way we#d break apt |
| 15:44.07 | MohammadAG | no |
| 15:44.16 | merlin1991 | DocScrutinizer: fix bugs? :D |
| 15:44.21 | MohammadAG | apt-get update is advanced, and would upgrade from Nokia to new |
| 15:44.30 | merlin1991 | would you like to install nikocam and stay with its current state? :D |
| 15:45.16 | DocScrutinizer | no, I would like to pick nikocam from cssu-extras as a simple optional package, like I do with bash from extras |
| 15:45.32 | merlin1991 | yeah but when youve installed it already then you want updates |
| 15:45.40 | merlin1991 | and ofc you want them in your updates window |
| 15:45.41 | DocScrutinizer | sure thing |
| 15:45.51 | merlin1991 | so a flag "this is no freaggin update" only works for the first time |
| 15:45.58 | merlin1991 | so the 1 package way is m00t anyway |
| 15:46.08 | DocScrutinizer | where's the problem with shipping an update in cssu-exrtas repo |
| 15:46.22 | MohammadAG | DocScrutinizer, the way HAM/apt work is that if we have nicocam in cssu-extras it'll show in updates |
| 15:46.36 | merlin1991 | if we keep the package name same as nokia name |
| 15:46.43 | DocScrutinizer | not until it's installed? |
| 15:46.52 | DocScrutinizer | aaah |
| 15:46.58 | DocScrutinizer | then that's the problem |
| 15:47.13 | DocScrutinizer | package names conflict, hmhmhmhm |
| 15:47.24 | DocScrutinizer | I see |
| 15:47.49 | DocScrutinizer | dang |
| 15:48.41 | DocScrutinizer | jaffa had some idea how to do all that, no? |
| 15:49.30 | merlin1991 | his idea was 2 distinct packages |
| 15:49.34 | DocScrutinizer | re-reads jaffa's mail |
| 15:49.47 | merlin1991 | and one to swap .desktop .dbus .whatever files |
| 15:49.52 | merlin1991 | but that's not feasible either |
| 15:50.46 | merlin1991 | since we have to keep our rootfs footnote as small as possible, and installing each closed blob side by side with the re package is just going to eat up space quite fast |
| 15:51.36 | DocScrutinizer | could we implement a "replace" menu checkbox in HAM, and all pkgs from cssu-extras have some "#ifdef cssu-replace" in their postinstall script? |
| 15:52.15 | DocScrutinizer | nah, off the point |
| 15:52.20 | merlin1991 | DocScrutinizer: we should at least be apt compatible |
| 15:52.47 | merlin1991 | my best shot at it so far is: |
| 15:52.55 | DocScrutinizer | the icon / .desktop itself has to manage conflicts when we install nikocam in parallel to stock |
| 15:54.08 | merlin1991 | have the nokia package from the nokia repo, a cssu package ie camera-ui2 that conflicts with the nokia and the 3rd packages, and have the 3rd package that depends on the nokia package and conflicts with the cssu one (needed when user uninstalls cssu pak and wants nokia back) |
| 15:54.26 | merlin1991 | s/3rd packages/3rd package/ |
| 15:55.03 | DocScrutinizer | hmm, something like that, yeah |
| 15:55.06 | merlin1991 | that way we'd leave the user the choice and take care that there is no side by side rootfs madness |
| 15:56.45 | DocScrutinizer | and build two pkgs for each project, one always tagged/named "${APPNAME}-cssu" and thus the concurrently usable pkg |
| 15:57.02 | merlin1991 | you lost me there |
| 15:57.26 | merlin1991 | so essentially you want a 4th package aswell that can be install concurrently? |
| 15:57.36 | DocScrutinizer | and ${APPNAME} and ${APPNAME}-cssu obviously conflict |
| 15:57.45 | DocScrutinizer | yes |
| 15:58.09 | merlin1991 | why would it conflict then? |
| 15:59.28 | merlin1991 | my suggestion was: 1st ${APPNAME} (original nokia), 2nd ${APPNAME}-cssu (the rewrite) and 3rd ${APPNAME}-nokia the helper to install nokia package back |
| 15:59.38 | DocScrutinizer | because ${APPNAME} from extras-cssu is replacing original nokia pkg, while ${APPNAME}-cssu installs same binary in a way it can coexist with original nokia pkg. evidently they should conflict with each other |
| 15:59.44 | merlin1991 | and then have 1,3 conflict 1 |
| 16:00.12 | merlin1991 | err 1,3 conflict 2 |
| 16:00.26 | DocScrutinizer | :nod: |
| 16:00.36 | DocScrutinizer | my suggestion just augments this |
| 16:01.12 | merlin1991 | your augmention brings no real value, besides calc |
| 16:01.27 | DocScrutinizer | ok, naming conflicts still a problem |
| 16:01.31 | merlin1991 | all other rewrites are either original or rewrite by design |
| 16:01.59 | merlin1991 | unless you love to have doubled control panel entries, and whatnot :D |
| 16:02.19 | merlin1991 | sure for anything that is a REAL application I can see the point to run them side by side |
| 16:02.30 | merlin1991 | (in this case Calc is the only one so far) |
| 16:02.35 | DocScrutinizer | user has three possible options: a) keep Nokia binary, b) replace Nokia binary by cssu rewrite, c) install cssu-rewrite side by side with original Nokia binary |
| 16:03.24 | merlin1991 | though rewrites currently in place: 3 control panel things, not excatly feasible side by side, camera-ui impossible side by side, and calc calc makes sense to have the c option |
| 16:03.43 | merlin1991 | I'd apply c only where it makes sense |
| 16:03.45 | merlin1991 | but not in general |
| 16:03.59 | DocScrutinizer | when one or another option is not available for a particular project, we simply omit that pkg |
| 16:04.17 | merlin1991 | with that added I'm fine with your suggestion :D |
| 16:05.28 | DocScrutinizer | e.g for orientation-lock applet we only got [b)|c)] option. it's an optional pkg that neither can replace any stock Nokia stuff nor live side by side with any |
| 16:06.20 | DocScrutinizer | so only cssu-orientationlock-applet-cssu pkg should be available |
| 16:06.45 | DocScrutinizer | I'm unhappy with my own naming sheme though :-D |
| 16:08.16 | DocScrutinizer | let's define: $PKG == Nokia stock, ${PKG}-cssuR == replacing, ${PKG}-cssu == optional aka side-by-side (if applicable) |
| 16:09.15 | DocScrutinizer | quite obviously a ${PKG}-cssuR would install .desktop etc that are same name as ${PKG} |
| 16:09.25 | DocScrutinizer | to completely replace stuff |
| 16:10.04 | DocScrutinizer | while a ${PKG}-cssu would install .desktop with new name that's not conflicting with original Nokia stuff |
| 16:13.06 | DocScrutinizer | and yes, in HAM with cssu-extras repo enabled there should also show up ${PKG}-nokia, which allows user to install original binary - basically it's a synonym for uninstalling ${PKG}-cssuR |
| 16:13.11 | merlin1991 | which essentially would give us only 1 ${PKG}-cssu from our current packages |
| 16:13.19 | merlin1991 | yep |
| 16:13.48 | merlin1991 | also since the user can install the -cssuR packages from ham (they are visible after all) they need a way to install the nokia package again (which is invisible ofc) |
| 16:14.23 | DocScrutinizer | yep |
| 16:16.08 | DocScrutinizer | nota bene for PKGs not existing in stock (like orientation-lock applet), the "-cssu" extension is somewhat optional, since there are no ambiguities |
| 16:17.09 | merlin1991 | exactly :D |
| 16:30.33 | DocScrutinizer | oh, one thing I'd like to get defined in our HowTo about all that: it's generally mandatory for a R-pkg to deliver a non-R aka -cssu pkg as well, unless this obviously doesn't make any sense (you can't have a -cssu pkg for HD, you however *can* have a -cssu pkg for camera) |
| 16:31.17 | DocScrutinizer | excuse my poor wording |
| 16:31.35 | merlin1991 | err? |
| 16:31.44 | DocScrutinizer | oh, one thing I'd like to get defined in our HowTo about all that: it's generally mandatory for a project delivering a R-pkg to provide a non-R aka -cssu pkg as well, unless this obviously doesn't make any sense (you can't have a -cssu pkg for HD, you however *can* have a -cssu pkg for camera) |
| 16:31.49 | merlin1991 | you can only have a -cssu pkg for camera with quite some work |
| 16:32.02 | merlin1991 | it has to be the only one by design |
| 16:32.36 | DocScrutinizer | oh? how so? |
| 16:32.46 | merlin1991 | becaus it's coded like that? |
| 16:33.06 | merlin1991 | also hd is a bad example, since anything open-source isn't part of this great scheme |
| 16:33.11 | DocScrutinizer | I always thought fcam and blessN900 were quite able to delive "-cssu" type pkgs |
| 16:33.38 | merlin1991 | they are not the stock camera ;) |
| 16:34.10 | DocScrutinizer | right, and that's exactly the rationale behind this |
| 16:34.38 | merlin1991 | well still the nikocam needs some adjustments to work as a -cssu pkg |
| 16:34.56 | merlin1991 | so unless nicolai does them there isn't going to be a side by side package for the camera-ui |
| 16:35.12 | merlin1991 | imo having a side by side option is just icing on the cake |
| 16:35.25 | merlin1991 | first thing the user needs is to have a choice at all |
| 16:35.25 | DocScrutinizer | I don't like users of stock maemo left behind just because app devels are too lazy to consaider make their stuff work on non-cssu systems as an alternative concurrent app |
| 16:35.59 | merlin1991 | stock maemo users are left behind per definiton |
| 16:36.03 | merlin1991 | since this is all cssu specific |
| 16:37.14 | DocScrutinizer | yes, but we're not hostile against stock, we actively want to encourrage devels to build their apps for all maemo users |
| 16:37.38 | DocScrutinizer | and we want to keep freedo of choice where ever possible |
| 16:37.50 | merlin1991 | yeah but cssu is never going to host "apps" |
| 16:37.57 | DocScrutinizer | choice to install -cssu pkg rather than -cssuR |
| 16:38.04 | merlin1991 | this is only about hosting rewrites of stuck stuff within cssu |
| 16:38.18 | merlin1991 | s/stuck/stock/ |
| 16:38.32 | DocScrutinizer | merlin1991: it's exactly not |
| 16:38.40 | merlin1991 | the meeting is |
| 16:38.46 | DocScrutinizer | it's also about stuff like orientation-lock applet |
| 16:38.49 | merlin1991 | the whole idea why I started this is |
| 16:39.39 | merlin1991 | and PER DEFINTION OF CSSU WE ARE NOT GOING TO ADD ANYTHING THAT CAN LIVE WITHIN EXTRAS THUS THERE IS NO NEED TO CONSIDER cssuR PACKAGES FOR YOUR AVERAGE APP |
| 16:39.40 | merlin1991 | ffs |
| 16:39.50 | merlin1991 | sry :D |
| 16:39.55 | DocScrutinizer | yes, all on same page here |
| 16:41.41 | DocScrutinizer | just for app rewrites like OMP and camera, I think we owe cssu users to require devels to also provide a -cssu pkg, so users can compare side by side |
| 16:42.33 | DocScrutinizer | if it can't be done for a particular project, then ok, so it's like that |
| 16:43.02 | DocScrutinizer | but if it can get done easily, we shouldn't let devels get away with laziness |
| 16:43.19 | merlin1991 | yeah sure, but most devels already have such things in place anyway |
| 16:43.22 | merlin1991 | (see omp in extras) |
| 16:43.45 | merlin1991 | since essentially anything -cssu could live in extras unless it depends on somehting cssu specific |
| 16:43.51 | DocScrutinizer | the more easily we can define this as a usually mandatory best practice |
| 16:44.52 | DocScrutinizer | of course when there's an extras pkg already, we don't need a -cssu pkg |
| 16:45.48 | DocScrutinizer | at least if the pkg from extras doesn't fail on CSSU ;-D |
| 16:46.30 | DocScrutinizer | and only if the pkg from extras is actually not replacing stock app in stock fremantle |
| 16:47.24 | DocScrutinizer | as otherwise it's a non-cssu version of the R-pkg |
| 16:48.23 | merlin1991 | omp is the perfect exmaple |
| 16:48.27 | merlin1991 | in extras and does not replace |
| 16:50.07 | DocScrutinizer | yes |
| 16:50.12 | DocScrutinizer | all fine with that |
| 16:50.57 | DocScrutinizer | doesn't need an explicit -cssu pkg, as there's the extras pkg doing exactly what otherwise we'd require at _least_ for -cssu pkg |
| 16:52.31 | DocScrutinizer | I'd like to see similar situation for nikocam |
| 16:53.02 | DocScrutinizer | (actually I don't know if it's maybe already like that) |
| 16:57.15 | DocScrutinizer | anyway... o/ |
| 16:57.21 | DocScrutinizer | afk |
| 16:58.53 | *** join/#maemo-ssu mase_76 (~mase76@p5DD3A8FC.dip.t-dialin.net) |
| 17:11.49 | *** join/#maemo-ssu mase76 (~mase76@p5DD3A8FC.dip.t-dialin.net) |
| 17:21.20 | Jaffa | sees his name and goes to read scrollback |
| 17:22.38 | Jaffa | merlin1991: DocScrutinizer: The "bridge" package could uninstall the original package since CSSU doesn't do the whole complete meta-provides thing |
| 17:23.38 | DocScrutinizer | Jaffa: yup, that's how I understood merlin1991's concept |
| 17:31.38 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 17:51.51 | *** join/#maemo-ssu mase76 (~mase76@p5DD3A8FC.dip.t-dialin.net) |
| 17:59.18 | *** join/#maemo-ssu mase76 (~mase76@p5DD3A8FC.dip.t-dialin.net) |
| 18:15.43 | *** join/#maemo-ssu arcean (~arcean@aacx104.neoplus.adsl.tpnet.pl) |
| 18:23.47 | *** join/#maemo-ssu BCMM (~ben@unaffiliated/bcmm) |
| 18:28.59 | *** join/#maemo-ssu _rd (~rd@p57B48177.dip0.t-ipconnect.de) |
| 18:50.42 | *** join/#maemo-ssu _rd (~rd@p57B48177.dip0.t-ipconnect.de) |
| 18:56.31 | *** join/#maemo-ssu fw190 (1fae102c@gateway/web/freenode/ip.31.174.16.44) |
| 18:56.56 | fw190 | helo |
| 18:59.27 | fw190 | in one of the conversations someone wrote that APMD sucks |
| 18:59.50 | fw190 | but what to do if one has a Chinese battery |
| 19:00.08 | fw190 | and stock indicator sucks like hell |
| 19:00.19 | fw190 | after hlaf battery i goes to 0 |
| 19:00.41 | fw190 | and in AMPD the nokia BME alternative shows more accurate |
| 19:01.19 | fw190 | does AMPD mess the system or something like that? |
| 19:02.53 | Sicelo | bq27200 ftw |
| 19:04.12 | fw190 | I do not understand the ftw thin. IRC shortcuts arent easy for me :) |
| 19:04.49 | Sicelo | ~ftw |
| 19:04.49 | infobot | For The Win! |
| 19:05.44 | Sicelo | http://enivax.net/jk/n900/bq27200.sh |
| 19:07.06 | StyXman | Sicelo: any plans to make a widget out of it? |
| 19:08.31 | Sicelo | i tried in DCE .. but for my purposes, just running it in a terminal is good enough |
| 19:09.48 | StyXman | well, it's a .sh script, it should be doable in any other language :) |
| 19:12.54 | Sicelo | i mostly use it while calibrating battery |
| 19:27.00 | *** join/#maemo-ssu _rd (~rd@p57B48177.dip0.t-ipconnect.de) |
| 19:32.24 | *** join/#maemo-ssu mase76 (~mase76@p5DD3A8FC.dip.t-dialin.net) |
| 19:36.14 | DocScrutinizer | I think pali and freemangordon (iirc) were about to implement a complete set of replacements for bme, that APM shite thing (I.E. a better bq27200.ko with sys/*/* nodes), hald-addon-bme, and battery applet |
| 19:36.58 | DocScrutinizer | fw190 gone, meh |
| 19:38.40 | DocScrutinizer | anyway, for now the approach is so utterly obvious: replace each read() from /sys/*/*/bq27200/* by a system("i2cget bla blub") call, in this APMD shite |
| 19:41.07 | DocScrutinizer | or even implement a lib-fake-bq27k.so that you LD_PRELOAD for AMPD and similar apps using /sys/*/*/bq27200/* nodes, and this lib transforms each read to any of those nodes to an equivalent direct I2C read |
| 19:41.53 | DocScrutinizer | AIUI there's a lib doing the exact opposite, for bme in mer/meego-ce |
| 19:45.57 | DocScrutinizer | there's even a way to patch 27200.ko in a way it wouldn't lock the I2C bus chip addr permanently, but rather basically would do all the init stuff now done when modprobing the module whenever somebody does a read() on any of the sysnodes, then reads out the value from chip via I2C, and immediately releases I2C again, this not permanently blocking bme and i2ctools like in bq27200.sh |
| 19:46.46 | DocScrutinizer | nobody tackled that, as it would need serious rewrite of the bq27200.ko module. Obviously something nobody is eager to do |
| 20:14.21 | *** join/#maemo-ssu mase76 (~mase76@p5DD3A8FC.dip.t-dialin.net) |
| 20:36.56 | *** join/#maemo-ssu Kaptenen_ (~Kaptenen@81.216.60.47) |
| 20:49.16 | *** join/#maemo-ssu _rd (~rd@p57B48177.dip0.t-ipconnect.de) |
| 20:52.06 | *** join/#maemo-ssu Kaptenen_ (~Kaptenen@81.216.60.47) |
| 21:44.23 | *** join/#maemo-ssu smoku (~spectrum@xkh0g2.infr.xiaoka.com) |