| merlin1991 | the string is going to be in the binary :D | 00:00 |
|---|---|---|
| merlin1991 | though you can leave it out of git ;) | 00:00 |
| freemangordon | forget about .deb, I am sleepy | 00:00 |
| freemangordon | :D | 00:00 |
| freemangordon | yeah | 00:00 |
| merlin1991 | you can simply call the build like this "dpkg-buildpackage -rfakeroot -us -uc -Ifbkey.h" | 00:00 |
| freemangordon | yep | 00:01 |
| merlin1991 | also adding -I.git speeds up all our compiles / uploads :D | 00:01 |
| freemangordon | and won't add it to git | 00:01 |
| freemangordon | ok, I need 2 repos then | 00:01 |
| merlin1991 | hm? | 00:01 |
| freemangordon | feedservice2-dev | 00:01 |
| freemangordon | and feedservice-plugin-fb-common | 00:02 |
| merlin1991 | ah yeah true :D | 00:02 |
| merlin1991 | why does it have a -dev package? | 00:02 |
| merlin1991 | o.O? | 00:02 |
| freemangordon | that is a -dev package for another closed-source library | 00:02 |
| merlin1991 | ah | 00:02 |
| merlin1991 | what does that one do? :D | 00:02 |
| freemangordon | same as libconnui-dev for cbs-widget | 00:03 |
| freemangordon | uses libcurl to connect to FB | 00:03 |
| freemangordon | adn sqllite and some other things | 00:03 |
| *** lizardo has quit IRC | 00:05 | |
| *** NIN101 has quit IRC | 00:06 | |
| merlin1991 | any particular names/ descriptions? | 00:07 |
| freemangordon | feedservice-plugin-fb-common | 00:07 |
| freemangordon | and feedservice2-dev | 00:07 |
| merlin1991 | https://gitorious.org/community-ssu/feedservice2-dev | 00:08 |
| freemangordon | http://maemo.org/packages/view/feedservice-plugin-fb-common/ | 00:08 |
| merlin1991 | https://gitorious.org/community-ssu/feedservice-plugin-fb-common | 00:08 |
| freemangordon | for the description | 00:08 |
| merlin1991 | makes me rofl :D | 00:09 |
| freemangordon | merlin1991: you kan check on your n900 for the descriptions | 00:10 |
| freemangordon | *can | 00:10 |
| freemangordon | as those on maemo.org are older versions | 00:10 |
| merlin1991 | I'm about to headdesk due to sleep deprivation, I don't think so :D | 00:11 |
| freemangordon | yeah, same here | 00:11 |
| freemangordon | lets continue tomorrow | 00:11 |
| *** Estel_ has quit IRC | 00:43 | |
| *** Estel_ has joined #maemo-ssu | 00:43 | |
| MohammadAG | why not include the key | 00:47 |
| *** Estel_ has quit IRC | 00:47 | |
| *** Estel^ has joined #maemo-ssu | 00:47 | |
| MohammadAG | it's not a matter to worry about | 00:47 |
| freemangordon | MohammadAG: osso-gnome-vfs2 is missing int the last *-pr | 00:47 |
| Pali | freemangordon, I do not have fb (and I do not know how is working...) but what is that key? | 00:50 |
| Pali | and what is problem with fb? | 00:50 |
| freemangordon | hmm my bad, it is in -pr, but not in the changelog | 00:50 |
| freemangordon | Pali: FB widget does not work | 00:50 |
| freemangordon | FB pphoto uploader too | 00:50 |
| Pali | because fb changed api? | 00:51 |
| freemangordon | no, there is some bug in curl | 00:51 |
| Pali | freemangordon, bug in curl? bug which depends on current date/time? | 00:52 |
| freemangordon | Pali: for some reason curl tries to use IPv6 adress when connecting to FB | 00:52 |
| Pali | I know that FB added AAAA record last week (or earlier) | 00:53 |
| freemangordon | yep | 00:53 |
| freemangordon | and that triggers the bug | 00:53 |
| Pali | ah, stupid bug | 00:53 |
| Pali | but then it is not only problem with fb? | 00:54 |
| freemangordon | Pali, so far that is the only reported bug | 00:54 |
| Pali | and solution is to update curl to new version? | 00:55 |
| freemangordon | yep | 00:55 |
| Pali | ok | 00:55 |
| Pali | but what is that key for fb? | 00:55 |
| freemangordon | in the meanwhile I REed a part of the FB infra responsible for login | 00:56 |
| freemangordon | when an application tries to use FB API it must provide 2 keys | 00:56 |
| freemangordon | application ID and a secret key | 00:56 |
| freemangordon | google for FB API key | 00:57 |
| *** Estel^ has quit IRC | 00:57 | |
| freemangordon | Pali, have to take some sleep | 00:57 |
| freemangordon | bb for now :) | 00:57 |
| Pali | and you cannot use key from that nokia binary? | 00:58 |
| Pali | ok, bye | 00:58 |
| freemangordon | I can, the problem is if I publish it on gitorious | 00:58 |
| freemangordon | bye | 00:58 |
| DocScrutinizer05 | I don't see how that's a problem, esp when you obfuscate it a little | 01:03 |
| merlin1991 | it only is a problem if fb dev tos says something against it | 01:04 |
| DocScrutinizer05 | even ship it as binary | 01:04 |
| DocScrutinizer05 | you "publish" that key anyway, in each binary package some user downloads | 01:05 |
| merlin1991 | You must not give your secret key to another party, unless that party is an agent acting on your behalf as an operator of your application. You are responsible for all activities that occur under your account identifiers. | 01:05 |
| DocScrutinizer05 | errr, jaggedijagg | 01:06 |
| merlin1991 | in other words, app yes, source no | 01:07 |
| DocScrutinizer05 | shipping with the app either *is* or *is not* "giving key to other party" | 01:07 |
| merlin1991 | and then there is We can take enforcement action against you and any or all of your applications if we determine in our sole judgment that you or your application violates Facebook Platform Terms and Policies. Enforcement action is both automated and manual, and can include disabling your application, restricting you and your application's access to Platform functionality, terminating our agreements with you, or any other action as we | 01:07 |
| merlin1991 | in our sole discretion deem appropriate. | 01:07 |
| merlin1991 | in other words we *might* ruin fb for all n900 users of the stock plugin if we publish the nokia keys | 01:08 |
| DocScrutinizer05 | so what? do as I suggested: extract the key from original nokia binary you ship partially to gitorious, by a nifty combination of dd, od, and sed, create a temporary file with some hex values which you can #include | 01:11 |
| DocScrutinizer05 | though I'd do that with my own key, sure | 01:11 |
| DocScrutinizer05 | not really the Nokia one | 01:11 |
| DocScrutinizer05 | you could do that on device | 01:11 |
| merlin1991 | and why do all the nifty stuff? | 01:12 |
| DocScrutinizer05 | in pre-install | 01:12 |
| merlin1991 | why not simply "not" put the key on in the source package and gitorious and have it just in the binary? | 01:12 |
| merlin1991 | could be argued to be "configuration" and not part of the "software" | 01:12 |
| Pali | but this violate GPL | 01:13 |
| Pali | first choose other license | 01:13 |
| merlin1991 | freemangordon: wrote it, he chooses the license :) | 01:13 |
| DocScrutinizer05 | look, we're just patching original nokia lib ;-D every single byte of it except the key | 01:14 |
| merlin1991 | rofll | 01:14 |
| Pali | :D | 01:14 |
| merlin1991 | well if anything freemangordon can slap any license on it, there is no (c) nokia on his code | 01:14 |
| merlin1991 | and since it is very maemo specific I wouldn't worry about people stealing the source, so I guess anything bsd/mit like would be perfect | 01:15 |
| merlin1991 | though as I wrote earlier it's up to freemangordon | 01:15 |
| Pali | I do not see any differences between distributing binary with key and source code with key in hexdump | 01:16 |
| Pali | both are same | 01:17 |
| DocScrutinizer05 | honestly, the lib has same name, runs on same device, for same main() with same API | 01:17 |
| DocScrutinizer05 | I only half was joking | 01:17 |
| DocScrutinizer05 | we're indeed patching a lib, not stealing a key | 01:18 |
| merlin1991 | yeah :D | 01:18 |
| merlin1991 | btw I think we would be GPL compliant if we load the key from a file at runtime and not distribute that file :) | 01:18 |
| merlin1991 | (in source) | 01:18 |
| DocScrutinizer05 | about the non-disclosure, this can get handled by actually using whatever key is in original lib as found during install of our patch | 01:18 |
| merlin1991 | tricky | 01:19 |
| merlin1991 | we replace, thus apt removes the old lib before we place the new lib | 01:19 |
| DocScrutinizer05 | ouch | 01:19 |
| merlin1991 | before *any* inst hook of our package gets called | 01:19 |
| DocScrutinizer05 | even before pre-install? | 01:19 |
| DocScrutinizer05 | dang | 01:19 |
| Pali | why to create some stupid hack because of license? | 01:20 |
| DocScrutinizer05 | just for the fun | 01:20 |
| Pali | :D | 01:20 |
| merlin1991 | Pali: I'd simply not license it gpl and be happy :D | 01:20 |
| Pali | I think key should be included in source code in some hexdump way | 01:21 |
| Pali | It is really same as key included in elf binary | 01:21 |
| DocScrutinizer51 | indeed | 01:22 |
| merlin1991 | yeah, but the fb tos explecitely forbid to publish the key outside of an application | 01:23 |
| Pali | source code is application part | 01:23 |
| DocScrutinizer51 | but then you can't download the original Nokia lib anywhere | 01:23 |
| DocScrutinizer51 | without 'auth' | 01:23 |
| merlin1991 | Pali: the wording is: You must not give your secret key to another party, unless that party is an agent acting on your behalf as an operator of your application. You are responsible for all activities that occur under your account identifiers. | 01:23 |
| *** BCMM has quit IRC | 01:24 | |
| Pali | Security through obscurity? | 01:24 |
| merlin1991 | apparently :/ | 01:25 |
| Pali | there always exists way how to obtain key from app | 01:25 |
| merlin1991 | though I loved the security through insanity article on tdwft :D | 01:25 |
| Pali | from any app | 01:25 |
| DocScrutinizer51 | merlin1991: thisx doesn't say which encoding your app has | 01:25 |
| merlin1991 | yeah but operator != guy reading your code | 01:25 |
| Pali | so you cannot write application in bash/python? | 01:25 |
| DocScrutinizer51 | exactly | 01:26 |
| Pali | then operator != guy which hexdump/objdump your code | 01:26 |
| DocScrutinizer51 | that's not what the TOS says | 01:26 |
| DocScrutinizer51 | incluse the key in hex, 'decode' it rot13 | 01:27 |
| DocScrutinizer51 | enough to "not share" | 01:27 |
| Pali | it is also encoded in nokia binary? | 01:28 |
| merlin1991 | DocScrutinizer51: but my rot26 is so much more secure ;) | 01:28 |
| DocScrutinizer51 | who can read c source and understand it does rot13 can as well hexdump the binary | 01:28 |
| Pali | I think char key[] = { 0x00, 0x01, ... }; is enought | 01:28 |
| DocScrutinizer51 | probably | 01:29 |
| Pali | no encoding but binary format | 01:29 |
| Pali | same as in elf binary | 01:29 |
| DocScrutinizer51 | yup | 01:29 |
| DocScrutinizer51 | we should ask quim | 01:30 |
| merlin1991 | dunno how quim can help us here | 01:30 |
| DocScrutinizer51 | he's the one to worry about Nokia's key, not we | 01:30 |
| DocScrutinizer51 | or lemme put it that way, when Nokia allows us to use the key, we are an 'agent(?)' | 01:31 |
| Pali | so why then ask? :D We do not worry about Nokia :) same as Nokia does not worry about us :) | 01:31 |
| merlin1991 | I only wory about $random people on the stock plugin suddenly not being able to use it anymore | 01:32 |
| merlin1991 | (because of our actions) | 01:32 |
| Pali | freemangordon wrote that stock plugin does not working due to AAAA record | 01:32 |
| Pali | problem with curl | 01:33 |
| merlin1991 | yeah, but a different libcurl fixes that again | 01:33 |
| DocScrutinizer51 | merlin1991: when Nokia allows us resp declares cssu replacement official, there's no reason anybody feels pissed | 01:33 |
| merlin1991 | which even is in extras-devel (even though it shouldn't be there) | 01:33 |
| DocScrutinizer51 | the point is we patch a lib but the app and platform stays the same | 01:35 |
| DocScrutinizer51 | the key is for the app | 01:35 |
| merlin1991 | I'm only jumping those hoops here to prevent the unlikely occasion of fb revoking the official nokia key | 01:35 |
| DocScrutinizer51 | they CANT when Nokia says thats all OK | 01:36 |
| DocScrutinizer51 | well they can, but why should they? | 01:36 |
| merlin1991 | also I'm not worried about the .deb at all, I'm thinking about the tar.gz and gitorious | 01:37 |
| DocScrutinizer51 | in the end for fb nuttin changed | 01:37 |
| merlin1991 | except that the key now is easily avaiable to anybody interested | 01:37 |
| DocScrutinizer51 | I see this different | 01:37 |
| merlin1991 | btw Pali technically we can't make the lib gpl anyway | 01:38 |
| DocScrutinizer51 | not any easier than with any non-encrypted binary | 01:38 |
| merlin1991 | it's links against the closed feedservice2 lib from nokia | 01:38 |
| *** Atarii has quit IRC | 01:38 | |
| Pali | and LGPL? | 01:38 |
| merlin1991 | and as per gpl we would have to provide source for that aswell | 01:38 |
| merlin1991 | Pali: does not help us | 01:39 |
| DocScrutinizer51 | the closed feed is a point | 01:39 |
| DocScrutinizer51 | the hex in source, not | 01:39 |
| merlin1991 | "our" product inclueds parts that we can't provide source to | 01:39 |
| Pali | LGPL allow linking with closed libary | 01:39 |
| merlin1991 | yeah but only if the lib is lgpl | 01:39 |
| merlin1991 | no the other way around | 01:39 |
| merlin1991 | or rather it allows you to link gpled library, but not to link against non gpl stuff and make yours lpgl | 01:40 |
| merlin1991 | the fun of closed components :/ | 01:40 |
| DocScrutinizer51 | merlin1991: take some sleep ;) | 01:40 |
| merlin1991 | DocScrutinizer51: 3 contradicting statements? not tired enough ;) | 01:41 |
| Pali | https://www.gnu.org/licenses/gpl-faq.html#FSWithNFLibs | 01:45 |
| Pali | https://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF | 01:46 |
| DocScrutinizer51 | I'd extract the key from original lib. If we got no pre-install hook to do that, so heck this will be the first 'app' (except cssu?) that needs two packages to install completely - a chain-install | 01:46 |
| Pali | merlin1991, you can write program under GPL license and write exception to link closed source libary xyz into your program | 01:46 |
| *** nox- has joined #maemo-ssu | 01:48 | |
| DocScrutinizer51 | and my TV just asks "is FB still in or alreafy out?" | 01:50 |
| DocScrutinizer51 | or wait, can't 'our' lib download the original one? | 01:54 |
| DocScrutinizer51 | during install | 01:54 |
| merlin1991 | please no | 01:54 |
| DocScrutinizer51 | please no? :-P | 01:55 |
| merlin1991 | we'd have to put proper headers in order to get the nokia ssu server to behave and then work with the fun packaging of an debian package (tar.gz inside ar) and still don't mess aynthing up | 01:55 |
| DocScrutinizer51 | eeeew | 01:55 |
| merlin1991 | especially the first part is not fun | 01:55 |
| merlin1991 | unpacking the deb actually goes quite good (ofc only if we have ar avaiable on device, I dunno that) | 01:56 |
| DocScrutinizer51 | can't we just use apt-get? | 01:56 |
| merlin1991 | since we're in install dpkg is locked thus apt-get will error out before running | 01:56 |
| DocScrutinizer51 | hahaha rrrright | 01:56 |
| merlin1991 | but we ofc could patch apt-get to allow download with locked dpkg database | 01:57 |
| merlin1991 | but that is just tooooooooooooo fucking much for a single api key | 01:57 |
| DocScrutinizer51 | yep | 01:57 |
| DocScrutinizer51 | btw I wonder why cssu and this 'app' don't use alarmd or a simple subshell with sleep to start that 2nd phase of install | 02:00 |
| * DocScrutinizer51 also ponders there's obviously some hook for doing backup prior to PR upgrade | 02:05 | |
| DocScrutinizer51 | might be feasible to exploit that to get a copy of original lib | 02:06 |
| Pali | so this is reason why we should include cron into maemo and cssu :D | 02:07 |
| merlin1991 | nah alarmd would do fine | 02:08 |
| merlin1991 | but would still be a stinkin dirty hack | 02:08 |
| DocScrutinizer51 | or we simply install under alternative name, and do a rename in postinstall | 02:08 |
| merlin1991 | thou shall never touch the content of other packages with yours | 02:08 |
| Pali | I'm suggesting to include key into source code in hex | 02:08 |
| DocScrutinizer51 | haha | 02:08 |
| merlin1991 | part of the debian bible ;) | 02:09 |
| *** Sc0rpius has joined #maemo-ssu | 02:09 | |
| DocScrutinizer51 | well, we're not allowed to redistribute Nokia (C), neither complete binaries nor excerpts | 02:11 |
| DocScrutinizer51 | are we? | 02:11 |
| merlin1991 | that key? | 02:11 |
| merlin1991 | we got it listening on the traffic ofc | 02:11 |
| DocScrutinizer51 | I think that's irrelevant | 02:15 |
| merlin1991 | yep, jokes usually are | 02:15 |
| DocScrutinizer51 | as irrelevant as encoding of our app, machinecode or c test | 02:15 |
| DocScrutinizer51 | honestly, make the key a user config option. ship a tool to extract key from original lib and mv original to backup plus mv patched into place | 02:31 |
| *** arcean has quit IRC | 02:46 | |
| *** M4rtinK has quit IRC | 02:49 | |
| *** M4rtinK has joined #maemo-ssu | 03:06 | |
| *** M4rtinK has quit IRC | 03:11 | |
| *** Estel_ has joined #maemo-ssu | 03:26 | |
| *** Estel^ has joined #maemo-ssu | 03:51 | |
| *** Estel_ has quit IRC | 03:51 | |
| *** Pali has quit IRC | 04:21 | |
| *** trbs has quit IRC | 04:30 | |
| *** amiconn_ has joined #maemo-ssu | 05:17 | |
| *** amiconn has quit IRC | 05:17 | |
| *** amiconn_ is now known as amiconn | 05:17 | |
| *** Estel^ has quit IRC | 05:19 | |
| *** Estel_ has joined #maemo-ssu | 05:20 | |
| *** int_ua has quit IRC | 05:53 | |
| *** amiconn_ has joined #maemo-ssu | 06:03 | |
| *** amiconn has quit IRC | 06:03 | |
| *** amiconn_ is now known as amiconn | 06:04 | |
| *** M4rtinK has joined #maemo-ssu | 06:04 | |
| *** Estel_ has quit IRC | 06:10 | |
| *** Estel_ has joined #maemo-ssu | 06:10 | |
| *** M4rtinK has quit IRC | 06:17 | |
| *** Estel_ has quit IRC | 06:18 | |
| *** Estel_ has joined #maemo-ssu | 06:18 | |
| *** M4rtinK has joined #maemo-ssu | 06:18 | |
| *** Estel_ has quit IRC | 06:43 | |
| *** Estel_ has joined #maemo-ssu | 06:44 | |
| *** cbeau has left #maemo-ssu | 06:45 | |
| *** Estel_ has quit IRC | 06:46 | |
| *** Estel_ has joined #maemo-ssu | 06:48 | |
| *** nox- has quit IRC | 07:07 | |
| *** Estel_ has quit IRC | 07:36 | |
| *** Estel_ has joined #maemo-ssu | 07:38 | |
| freemangordon | DocScrutinizer51, Pali, merlin1991: the situation is in a no way different to cbs-widget: FOSS library linked to closed source | 08:38 |
| freemangordon | and I think putting the keys (and only the keys) in a different header file, which won't be on gitorious and won't get included in tar.gz solves our problem pretty easy | 08:40 |
| *** M4rtinK has quit IRC | 08:57 | |
| freemangordon | merlin1991: here http://gcc.gnu.org/releases.html is the ling for gcc 4.6.2 source code, just follow "GCC 4.6.2" link and choose the best mirror for you | 09:08 |
| freemangordon | *link | 09:08 |
| *** amiconn has quit IRC | 09:37 | |
| *** amiconn has joined #maemo-ssu | 09:40 | |
| *** M4rtinK has joined #maemo-ssu | 10:01 | |
| Estel_ | freemangordon, may I buggy You with interesting request? | 10:22 |
| freemangordon | sure | 10:23 |
| Estel_ | do you remember idea about using Rpi as hdmi out for N900... During conversation with SpeedEvil and Hurrian, the latter come up with extra interesting idea | 10:24 |
| Estel_ | http://mg.pov.lt/maemo-irclog/%23maemo.2012-06-06.log.html#t2012-06-06T05:06:40 | 10:24 |
| Estel_ | from this line to end of related discussion | 10:24 |
| Estel_ | IMO, it's our best chance to achieve it without - practically - any overhead on N900's side (CPU, RAM), and ability mto transfer everything, using Rpi as processing machine | 10:25 |
| freemangordon | Estel_, cloning is done on a HW level | 10:25 |
| Estel_ | and, as my limited knowledge goes implementing it *shouldn't* be very hard, given fact, that TV-Out kernel module is open and we need only small change + implement it to userland as additional option | 10:25 |
| Estel_ | he? | 10:25 |
| freemangordon | driver os FOSS (DSS2 driver) | 10:26 |
| Estel_ | SpeedEvil suggested, that hardware element read framebuffer | 10:26 |
| Estel_ | yea | 10:26 |
| Estel_ | and it compress etc | 10:26 |
| Estel_ | read on, I proposed other way later | 10:26 |
| Estel_ | SpeedEvil was in soubt, if it's doable using USb speeds, but it was confirmed later | 10:26 |
| freemangordon | and it supports VFI (virtual framebuffer), not sure is it enabled in .config | 10:27 |
| Estel_ | basically, something that would allow Rpi to read our framebufer - in raw mode - and process it on Pi | 10:27 |
| Estel_ | hm, itneresting | 10:27 |
| Estel_ | it would be 800x480*3*FPS bits - for 10 fps, it's only ~11Mb/s, would run flawlessly even over wifi | 10:27 |
| Estel_ | on good connection wifi, it should work even for 20 and 30 FPS | 10:27 |
| Estel_ | for USB, it would be possible to use higher resolutions | 10:28 |
| Estel_ | Pi would need to, basically, display captured framebuffer, without or with additional processing | 10:29 |
| Estel_ | this way, everything would work, even video, and - except dropping to framebuffer like in Tv-out - everything would be processed using Pi resources | 10:29 |
| Estel_ | I knwo You're (both) overprojected, but it would be KILLER feature - better than anythinbg made for any mobile device without hdmi out, including apples and paid software | 10:30 |
| Estel_ | of course You know my limited (barely existent) skills re coding, but as far as I can tell, the bets thing is that it *shouldn't* require cosmic ammounts of effort | 10:30 |
| * Estel_ teases | 10:30 | |
| Estel_ | ~tease | 10:31 |
| Estel_ | ~striptease | 10:31 |
| infobot | Hoogah Hoogah wah wah *takes of the box* *dances around showing of the cpu and memory* Ah yeah you likey my little HD no? | 10:31 |
| freemangordon | Estel_, scratch that, what is supported is RFBI, not VFI | 10:36 |
| *** dafox has joined #maemo-ssu | 10:36 | |
| freemangordon | Estel_, I am not sure I get the idea. You want to use VENC (that is TV out) module to do what exactly? | 10:45 |
| Estel_ | to cannibalsie way it's reading screen data *before* processing via hardware parts... | 10:46 |
| Estel_ | and to change tv-out applet to generl purpose external view applet (or better name) that have tv-out as one of, lets say 3 functions. or two | 10:46 |
| Estel_ | then, on Raspberry Pi side, capture screen data (in form it is presented before processed by N900 hardware tv-out) and display it via HDMI | 10:47 |
| freemangordon | Estel_, there is no dedicated TV out memory, fremebuffer is read line by line and scaled in real-time | 10:47 |
| *** M4rtinK has quit IRC | 10:47 | |
| Estel_ | = HDMI output | 10:47 |
| Estel_ | OK | 10:47 |
| Estel_ | so couldn't it by read line by line over USB networking by Pi? | 10:47 |
| Estel_ | is there a way to allow Pi to access N900's framebuffer? | 10:47 |
| Estel_ | so scratch tv-out module | 10:47 |
| Estel_ | if it's not needed, then, even better | 10:47 |
| Estel_ | we don't need scalling | 10:48 |
| Estel_ | only exporting data to framebuffer, in native resolutions, for beginning | 10:48 |
| freemangordon | to access as in? it is /dev/fbN (n=0,1,2) | 10:48 |
| Estel_ | any sensible way to read it from another linuxbox? | 10:48 |
| Estel_ | Ok, do we have any implementations in linux world, where something read framebuffer and display it? | 10:48 |
| freemangordon | ya, do a netcat :P | 10:48 |
| Estel_ | as per my calculations, bits per second are | 10:49 |
| Estel_ | 800*480*3*FPS | 10:49 |
| freemangordon | wrong | 10:49 |
| Estel_ | ? | 10:49 |
| freemangordon | we are not using rgb, | 10:49 |
| Estel_ | ops | 10:49 |
| freemangordon | FB is 16 bpp | 10:49 |
| Estel_ | don't tell me that it's 16 bits :p | 10:49 |
| Estel_ | eh | 10:49 |
| freemangordon | 565 or something | 10:50 |
| Estel_ | and we have this pout into framebuffer, without any drawback for performance, when using tv-out? | 10:50 |
| Estel_ | I don't talk about scaling | 10:50 |
| Estel_ | oh god | 10:50 |
| freemangordon | please rephrase | 10:50 |
| Estel_ | any way to process it in sensible way before sending? | 10:50 |
| freemangordon | process as in? | 10:50 |
| Estel_ | I jsut wonder how Tv-out is processing so much raw data, even if we drop scaling to Pal/NTSC | 10:51 |
| freemangordon | comress? scale? | 10:51 |
| Estel_ | IDK, change to RGB, whatever | 10:51 |
| freemangordon | Estel_, you annot drop the scaler | 10:51 |
| freemangordon | *cannot | 10:51 |
| freemangordon | it is a part of VENC module | 10:51 |
| Estel_ | understood. | 10:51 |
| freemangordon | Estel_, look at DSS subsystem in TRM and you will get the picture | 10:51 |
| Estel_ | so after reading from framebuffer, it's either PAL/NTSc or nothing? | 10:51 |
| Estel_ | i mean tv-out of course | 10:52 |
| freemangordon | it is 565 | 10:52 |
| freemangordon | which is passed to VENC module in chunks of (iirc) 2048 bytes | 10:52 |
| Estel_ | it doesso 800*480*565*FPs, which make it unsuitable for sending | 10:52 |
| freemangordon | Estel_, that is the FB content, not the result of downscaling | 10:53 |
| Estel_ | now, I wonder if we can process it a little - in any way - to make it "smaller" in terms of byte,s without using too much resources on N900 side, and, actually, leave considerable ammount for other functions | 10:53 |
| Estel_ | yea | 10:53 |
| Estel_ | but we *don't* want to downscale for HDMI out | 10:53 |
| *** dafox has quit IRC | 10:53 | |
| Estel_ | for that we have Tv-out | 10:53 |
| freemangordon | MJPEG? | 10:53 |
| freemangordon | or some other fast algo | 10:53 |
| Estel_ | sounds ncie. Basically, main limit is *realistic* thoroghput of USB networking | 10:54 |
| Estel_ | ...and mjpeg would allow us to do 20 fps without killing N900? | 10:54 |
| freemangordon | BTW I still wonder what is wrong with X forwarding | 10:54 |
| Estel_ | freemangordon, remember thread in TMO? AFAIK, You were able to forward EasyDebian to external machine... | 10:55 |
| Estel_ | but not Maemo as per se | 10:55 |
| freemangordon | never tried hard | 10:55 |
| Estel_ | lack of xephyr or something | 10:55 |
| freemangordon | it was just a POC | 10:55 |
| Estel_ | You know, if You would try hard, and it would succeed, it would be same *killer* feature with even less hassle ;) | 10:55 |
| Estel_ | for sure less than RE fb plugin :P | 10:55 |
| * Estel_ teases again | 10:55 | |
| freemangordon | why you would want maemo through HDMI? | 10:55 |
| freemangordon | it won't fit | 10:56 |
| freemangordon | most of the UI is optimized (read hardcoded) fro 800x480 | 10:56 |
| freemangordon | *for | 10:56 |
| Estel_ | because I would like to sue higher resolutions for 3rd party FOSS programs (i.e. not hildon-desktop itself) | 10:56 |
| Estel_ | because Tv output is downscaled and small fonts are hard to read | 10:56 |
| freemangordon | example? ED? | 10:57 |
| freemangordon | ED works like charm with X forwarding | 10:57 |
| Estel_ | because I love to work on trips with N900, but hate fact that quality of everything I see on big screen is worse than holding small screen close to eyes :P | 10:57 |
| Estel_ | no no,m lets leave debian alone | 10:57 |
| freemangordon | but what application then, gimme an example | 10:58 |
| Estel_ | basically, any FOSS program in repos that could run it higher ress but is hardcoded now to 800x480 could be updated to work using other resolutions | 10:58 |
| Estel_ | leafpad :P | 10:58 |
| Estel_ | no, seriously | 10:58 |
| Estel_ | I'm afraid to tell "games", bnecause I will hear "then do it Yourself and don't bug me" | 10:58 |
| Estel_ | but, other than games: | 10:59 |
| freemangordon | Estel_, have in mind that even if there is a way to forward FB to Pi, what you would yse as an inout device? | 10:59 |
| freemangordon | n900 itself? | 10:59 |
| freemangordon | *input | 11:00 |
| * freemangordon is afk | 11:00 | |
| Estel_ | sorry, got dced | 11:00 |
| Estel_ | freemangordon, other than some educational tools, videos and images Document viewers? | 11:01 |
| Estel_ | Ed doesn't have DSP acceleration for video, at least not the easy way | 11:01 |
| Estel_ | BTW, AFAIK, in your testing Ed was exported to external screen via LXDE, yep? | 11:01 |
| Estel_ | some programs are veryt resource hungry, and run better when started from within Maemo, without LXDE and all middle-mans (GIMP) | 11:02 |
| Estel_ | (Chromium, even old Libre Office) | 11:02 |
| Estel_ | s/old/good old/ | 11:02 |
| infobot | Estel_ meant: (Chromium, even good old Libre Office) | 11:02 |
| Estel_ | but generally, You're right | 11:02 |
| Estel_ | most programs we need in better resolution are in ED | 11:02 |
| Estel_ | if we can't run hildon-desktop and so goes on in higher resolutions, it may be quite unnecessary, for sure | 11:03 |
| Estel_ | honestly, i'm a little pissed off by PAL/NTSC downscaling | 11:03 |
| Estel_ | it's just quite annoying, that on big big BIG screen, You have lower resolution/quality of image than on native 800x480 screen,, but maybe it's only psychological/purist point of view | 11:04 |
| Estel_ | but, another *important* thing - other systems, like Ubuntu 12.04. should it work just like with Easy Debian? | 11:04 |
| Estel_ | Your's and other's experiences show, that running programs from such antively booted systems is much faster than chroot (why, BTW?) | 11:04 |
| Estel_ | I think that they should be exportable via xephyr etc, but You know better, probably | 11:05 |
| Estel_ | (i.e. confirm/deny? tried that? interested to try?) | 11:05 |
| freemangordon | Estel_, forget about streaming media from n900 to Pi, OMAP has one GFX and 2 video overlays which are scaled/mixed in HW to produce the image you have on LCD | 11:11 |
| Estel_ | ah | 11:12 |
| Estel_ | so, I msut summarize, that You're right - most like as for Maemo, we need only Ed and such things via HDMI-out | 11:12 |
| Estel_ | downscaling to PAL (little better) or NTSC (little worse) is irritating, but we can live with it | 11:12 |
| Estel_ | and question about other systems booted independently of Maemo? | 11:12 |
| Estel_ | I suspect it should be no problem to send them? | 11:13 |
| freemangordon | and that is done with export DISPLAY=a.d.c.d:0.0 startlxde | 11:13 |
| freemangordon | Estel_, NFC, but it should be the same | 11:13 |
| Estel_ | I think You agree that it's very interesting thing for, lets say, Lubuntu 12.04 | 11:14 |
| Estel_ | especially, considering how fast things like Chromium or LibreOffice works there | 11:14 |
| freemangordon | no, that was for ED chroot | 11:14 |
| Estel_ | BTw, any clue why it works much slowe rin chroot under Maemo? chroot should be like native speed? | 11:14 |
| freemangordon | slower? no, it is the same here, but my ED is on uSD | 11:15 |
| freemangordon | and not in a loopback device | 11:15 |
| Estel_ | same here, no loopback | 11:15 |
| Estel_ | but in eMMC. i use swap; on uSD... | 11:15 |
| freemangordon | me too | 11:16 |
| Estel_ | hey, I'm sure i remember You saying, on ubuntu 12.04 thread, that things work faster than in ED | 11:16 |
| freemangordon | hmm, can't remember saying such thing | 11:16 |
| Estel_ | hm, shouldn't we avoiud I/O conflicts with swap, just like with Maemo on eMMC? ED during operation, also generates quite ammount of I/O, doesn't it conflict with swap I/O? | 11:16 |
| freemangordon | seems like no | 11:16 |
| Estel_ | ok, will search and ask later, maybe ti was just me missunderstanding it | 11:17 |
| Estel_ | sorry for bugging You then, and thanks for clarification | 11:17 |
| Estel_ | You're right, it seems, that we have everything we need possible already | 11:17 |
| *** dafox has joined #maemo-ssu | 11:28 | |
| *** Estel_ is now known as maemobot | 11:41 | |
| *** maemobot is now known as Estel_ | 11:45 | |
| freemangordon | MohammadAG: hiding FB secret key is enough, ain't? API key is useless without it, correct? | 11:45 |
| *** Estel_ is now known as safsdgdfhg | 11:45 | |
| *** safsdgdfhg is now known as Estel_ | 11:45 | |
| *** arcean has joined #maemo-ssu | 11:52 | |
| MohammadAG | No | 11:55 |
| MohammadAG | FB secret key is used for more advanced changes | 11:55 |
| MohammadAG | Or calls | 11:55 |
| MohammadAG | Anyway, why hide it when it's clear in the public? | 11:55 |
| *** Pali has joined #maemo-ssu | 12:22 | |
| freemangordon | MohammadAG: so I should remove API key from the sources too? | 12:24 |
| freemangordon | it does not make sense, sekret key is used fro signature generation | 12:24 |
| freemangordon | *secret | 12:24 |
| MohammadAG | Dude? Just keep it | 12:25 |
| MohammadAG | Just keep both keys | 12:25 |
| MohammadAG | The same way everyone keeps them | 12:25 |
| freemangordon | MohammadAG: where it is clear? in binary? | 12:25 |
| MohammadAG | Yes | 12:26 |
| MohammadAG | You can't do anything harmful with them | 12:26 |
| freemangordon | MohammadAG: what one can do with API key only? | 12:26 |
| MohammadAG | Nothing | 12:27 |
| freemangordon | ok, that was my question :) | 12:27 |
| MohammadAG | So just keep the API key and the secret key in the source | 12:27 |
| DocScrutinizer51 | those keys are just so FB stays in control in case somebody comes up with a rogue app | 12:27 |
| freemangordon | so, now we have API key(only) on gitorious, secret key is not there | 12:27 |
| MohammadAG | Exactly, they can just delete/blacklist the key | 12:27 |
| MohammadAG | WHY?! | 12:27 |
| freemangordon | just in case | 12:28 |
| freemangordon | to keep merlin1991 happy :D | 12:28 |
| DocScrutinizer51 | weird rationale | 12:28 |
| freemangordon | ? | 12:28 |
| freemangordon | one needs both keys to be able to send a request to FB servers | 12:29 |
| MohammadAG | In case what | 12:29 |
| MohammadAG | Very weird | 12:29 |
| MohammadAG | Nokia made no effort to hide | 12:29 |
| MohammadAG | Neither should they make any effort | 12:29 |
| MohammadAG | A request to do what | 12:29 |
| MohammadAG | Just put both keys on gitorious | 12:29 |
| MohammadAG | They won't cause a nuclear strike | 12:29 |
| MohammadAG | If you're not putting it on gitorous I am | 12:30 |
| freemangordon | ok, application id (API key) is visible from your FB profile | 12:31 |
| MohammadAG | Again any argument you make won't make sense | 12:31 |
| MohammadAG | Both keys can be obtained by stringing the lib | 12:31 |
| MohammadAG | Both keys aren't tied in any way to a certain device's imei | 12:32 |
| freemangordon | MohammadAG: but it is not that easy to have the lib | 12:32 |
| MohammadAG | Both keys are in plaintext | 12:32 |
| DocScrutinizer51 | that's what Pali ans I say whole morning | 12:32 |
| freemangordon | and the concern is that FB could blacklist n900 if we put the keys on gitorious | 12:32 |
| MohammadAG | FB don't give a fuck | 12:32 |
| DocScrutinizer51 | the ONLY issue / concern being it's part of Nokia (C) IP | 12:33 |
| MohammadAG | That's false, I can bet on it | 12:33 |
| freemangordon | TBH I am ok either ways | 12:33 |
| DocScrutinizer51 | unless we use our own key, which kinda defeats purpose of 100% compatibility | 12:33 |
| freemangordon | MohammadAG: just make and agreement with merlin1991 and i will put secret key on gitorious too | 12:34 |
| freemangordon | ok? | 12:34 |
| Pali | freemangordon, my idea was to include key in hex form like: char key[] = { 0x11, 0x12, ... }; | 12:34 |
| DocScrutinizer51 | again. please ask Quim! | 12:35 |
| freemangordon | Pali, it is in such form | 12:35 |
| Pali | it is same as hexfump of elf binary | 12:35 |
| freemangordon | https://gitorious.org/community-ssu/feedservice-plugin-fb-common/blobs/master/include/facebook/common.h#line29 | 12:35 |
| DocScrutinizer51 | If Quim gives OK, we *are* OK and basically Nokia's agent | 12:35 |
| DocScrutinizer51 | in that regard | 12:36 |
| freemangordon | hmm, or not :) | 12:36 |
| MohammadAG | iOS keys are also plaintext | 12:43 |
| freemangordon | MohammadAG: where? | 12:44 |
| freemangordon | you have the source code? | 12:44 |
| MohammadAG | No, strings | 12:46 |
| MohammadAG | No one hides these | 12:46 |
| MohammadAG | You can get the N9 keys in the sane way | 12:47 |
| freemangordon | MohammadAG: lets end that discussion, I told you, make an agreement with merlin1991 and I will but the second key on gitorious too, ok? | 12:54 |
| freemangordon | *put | 12:55 |
| freemangordon | MohammadAG: on the other hand - were you able to find X-Fade? | 13:02 |
| freemangordon | merlin1991 told me there is some problem with -testing repo | 13:02 |
| *** xmlich02 has joined #maemo-ssu | 13:03 | |
| MohammadAG | merlin1991's pestering him afaik | 13:03 |
| *** int_ua has joined #maemo-ssu | 13:14 | |
| *** xnt14 has quit IRC | 13:17 | |
| *** MohammadAG has quit IRC | 13:19 | |
| *** MohammadAG has joined #maemo-ssu | 13:20 | |
| *** xnt14 has joined #maemo-ssu | 13:21 | |
| *** lizardo has joined #maemo-ssu | 13:30 | |
| *** MohammadAG has quit IRC | 13:32 | |
| *** MohammadAG has joined #maemo-ssu | 13:32 | |
| Estel_ | freemangordon, MohammadAG, if some contact with X-Fade is needed, You can always ask me | 14:16 |
| Estel_ | i'm in almsot constant contact with him (no joke :D ) | 14:16 |
| Estel_ | ...so I can easily forward Your problems. Generally, anyone from council is good to ping regarding infra | 14:17 |
| *** arcean has quit IRC | 15:05 | |
| Pali | Estel_, promoting package kernel-power-settings to extras: http://maemo.org/packages/view/kernel-power-settings/ | 15:05 |
| Estel_ | yea, told X-Fade about that one | 15:06 |
| Estel_ | he is working on it | 15:06 |
| Estel_ | You remind me old problem, or something new failed? | 15:06 |
| *** DocScrutinizer06 has joined #maemo-ssu | 15:06 | |
| *** DocScrutinizer has quit IRC | 15:06 | |
| *** DocScrutinizer has joined #maemo-ssu | 15:06 | |
| Estel_ | Pali^^^ | 15:08 |
| Pali | old problem | 15:08 |
| *** DocScrutinizer05 has quit IRC | 15:10 | |
| *** Estel_ has quit IRC | 15:19 | |
| *** maemobot has joined #maemo-ssu | 15:20 | |
| *** lizardo_ has joined #maemo-ssu | 15:22 | |
| *** arcean has joined #maemo-ssu | 15:24 | |
| *** lizardo_ has quit IRC | 15:55 | |
| *** M4rtinK has joined #maemo-ssu | 17:38 | |
| *** maemobot is now known as Estel_ | 18:40 | |
| *** M4rtinK has quit IRC | 18:53 | |
| *** int_ua has quit IRC | 19:01 | |
| *** NIN101 has joined #maemo-ssu | 19:18 | |
| *** mirandir has joined #maemo-ssu | 19:23 | |
| DocScrutinizer51 | hmm | 19:42 |
| *** dafox has quit IRC | 19:42 | |
| DocScrutinizer51 | that might explain a lot :-P | 19:42 |
| DocScrutinizer51 | alas if it's really a bot, it will blow each turing test outa the water | 19:43 |
| DocScrutinizer51 | by simply redefining the test parameters radically | 19:44 |
| *** Atarii has joined #maemo-ssu | 20:14 | |
| *** Atarii has joined #maemo-ssu | 20:14 | |
| *** krayon has joined #maemo-ssu | 20:18 | |
| *** krayon has quit IRC | 20:18 | |
| *** krayon has joined #maemo-ssu | 20:18 | |
| *** arcean_ has joined #maemo-ssu | 20:27 | |
| *** arcean has quit IRC | 20:30 | |
| DocScrutinizer51 | turing redefined: if tester headbangs before 15min are over, obviously bot wins | 20:31 |
| DocScrutinizer51 | other forms of giving up count as well: going insane, shoot yourself... | 20:32 |
| DocScrutinizer51 | shoot the bot/non-bot... | 20:35 |
| DocScrutinizer51 | well, in thois latter case it's arguable if the bot won | 20:35 |
| * merlin1991 headdesks | 20:36 | |
| merlin1991 | which sane person timestamps deltas with the beginning of the delta? | 20:36 |
| freemangordon | merlin1991, hi | 20:37 |
| freemangordon | read the log? | 20:37 |
| merlin1991 | just did, sry I actually wanted to pester x-fade today but didn#t manage | 20:37 |
| freemangordon | ok, as I was under the impression that you told meyesterday it is mag who is pestering X-Fade | 20:38 |
| DocScrutinizer51 | merlin1991: lol | 20:38 |
| merlin1991 | nah I wanted todo that myself | 20:38 |
| freemangordon | the second think - I uploaded FB crap on gitorious with only one of the two keys :) | 20:38 |
| DocScrutinizer51 | sure thing, keep the fun for yourself ;-zp | 20:38 |
| freemangordon | a kind of compromise :D | 20:39 |
| freemangordon | but mag wants them both. please, do some agreement with him and tell me what to do | 20:39 |
| freemangordon | merlin1991 ^^^ | 20:39 |
| merlin1991 | jsut load the 2nd one | 20:39 |
| freemangordon | upload the second one on gitorious? | 20:40 |
| freemangordon | ok | 20:40 |
| merlin1991 | I'm the minority in here saying no so I guess I'm overruled | 20:40 |
| DocScrutinizer51 | could any of you guys please ask quim?! | 20:40 |
| freemangordon | DocScrutinizer51: I can bet qgil has NFC about FB API and keys | 20:40 |
| DocScrutinizer51 | I'd rather trust in his decision on it | 20:40 |
| freemangordon | But qhat kind of decisiion one can make if he is not informed on the matter at all? | 20:41 |
| DocScrutinizer51 | he for sure has an idea of API access keys in general | 20:42 |
| freemangordon | DocScrutinizer51, I have move than idea for security, keys and such (that is a part of my job). But it does not mean I know a shit about FB | 20:42 |
| *** int_ua has joined #maemo-ssu | 20:43 | |
| DocScrutinizer51 | it's not FB which is the problem here, it's a key handed out to NOKIA by FB | 20:43 |
| freemangordon | It is MohammadAG that is the most knowledgeable, so maybe we should trust him | 20:43 |
| freemangordon | and that key flls under the TC of FB, not Nokia | 20:44 |
| freemangordon | *falls | 20:44 |
| freemangordon | as it is FB who is the key issuer and SP | 20:44 |
| DocScrutinizer51 | I'd trust him if we hadn't that debate and 'minority report' | 20:44 |
| freemangordon | we have the debate because we lack knowledge | 20:45 |
| freemangordon | and it is the same for qgil | 20:45 |
| DocScrutinizer51 | and it is NOKIA wo owns the key | 20:45 |
| freemangordon | no, it is FB who owns the key | 20:45 |
| DocScrutinizer51 | not at all | 20:45 |
| *** mase76 has joined #maemo-ssu | 20:45 | |
| freemangordon | want a bet? | 20:45 |
| DocScrutinizer51 | evidence: it's in a nokia blob | 20:45 |
| freemangordon | but it is authourized by FB, not Nokia | 20:46 |
| DocScrutinizer51 | that's nothing to do with ownership | 20:46 |
| freemangordon | DocScrutinizer51, it has all to to with the ownership, it is the same if you say that you are owner of the public key in an RSA pair | 20:47 |
| freemangordon | the owner is the issuer | 20:47 |
| DocScrutinizer51 | itMs NOKIA who's responsible to obey the EULA for that ke | 20:47 |
| freemangordon | not the user | 20:47 |
| DocScrutinizer51 | key | 20:47 |
| DocScrutinizer51 | rabulism | 20:48 |
| freemangordon | but it is the user who will be declined access to FB with that key (if FB decides) not Nokia | 20:48 |
| freemangordon | and that is the poit | 20:48 |
| DocScrutinizer51 | ask quim, instead of speculating | 20:48 |
| freemangordon | *point | 20:48 |
| DocScrutinizer51 | handwaving | 20:49 |
| freemangordon | [20:38] <freemangordon> DocScrutinizer51: I can bet qgil has NFC about FB API and keys | 20:49 |
| DocScrutinizer51 | so what | 20:49 |
| DocScrutinizer51 | search somebody to hol.d the bet or what? | 20:49 |
| DocScrutinizer51 | I'm not interested | 20:50 |
| DocScrutinizer51 | I know quim some time | 20:50 |
| DocScrutinizer51 | and it's irrelevant what he got a clue of or not | 20:50 |
| DocScrutinizer51 | asking him is the only PC thing | 20:50 |
| freemangordon | well, I would like to know what merlin1991 and mag will decide | 20:51 |
| DocScrutinizer51 | they already did | 20:51 |
| freemangordon | qgil is not a CSSU maintainer last time I chacked | 20:51 |
| freemangordon | *checked | 20:51 |
| freemangordon | so, I will upload the second key | 20:51 |
| freemangordon | gtg | 20:52 |
| freemangordon | bye for now | 20:52 |
| mase76 | hi! does anybody know, if openmediaplayer reads the gain tagged with mp3gain? | 20:53 |
| *** mase76 has quit IRC | 21:05 | |
| merlin1991 | bah | 21:06 |
| merlin1991 | was just about to answer | 21:06 |
| merlin1991 | (close to om uses mafw thus NO!) | 21:06 |
| Sc0rpius | man | 21:11 |
| Sc0rpius | do you know if there's a way to make the middle top button (the one that unlocks the screen) behave EXACTLY like the one at the side ? | 21:11 |
| Sc0rpius | because my side button (the one that slides) is so worn that it's hard for me to slide it anymore | 21:12 |
| Sc0rpius | and the button that unlocks (but then swipe) is totally useless!!! I would love to make it unlock/lock the screen without sliding shit | 21:12 |
| Sc0rpius | I guess there's a way since there are people that have made custom screensavers or something. | 21:13 |
| DocScrutinizer06 | in former times my advice would've been "delegate it to the council, they'll feature it out" - nowadays it seems in sovjet russia out of features councils your delegation | 21:18 |
| DocScrutinizer06 | anyway fact is we're redistributing non-foss stuff owned by Nokia, even if we change that key. This means we ought talk to them prior to doing so | 21:19 |
| DocScrutinizer06 | change the notation of that key (to ocatl for example) | 21:20 |
| DocScrutinizer06 | octal | 21:20 |
| DocScrutinizer06 | yet another point nobody mentioned yet: only Nokia (and FB, but they won't) can tell if that key FB granted usage to Nokia actually runs under same TOS like the ones somebody (merlin?) quoted here | 21:22 |
| DocScrutinizer06 | their "contract" might differ vastly from what you find on FB's webpage for end users and other ants | 21:23 |
| DocScrutinizer06 | Sc0rpius: straight brute force approach: redefine GPIO numbers in kernel | 21:26 |
| DocScrutinizer06 | but that might fail, as... I mean it's the *power* button, not some arbitrary switch like camdoor or kbd-slider | 21:28 |
| DocScrutinizer06 | it's probably as nasty as redefining ctrl-alt-del for ISA | 21:28 |
| Sc0rpius | hmm | 21:28 |
| Sc0rpius | well I would want to unlock/lock the screen with single push | 21:29 |
| Sc0rpius | and a long push to be the power button just like it is now but without showing menu or annoying swipe screen | 21:29 |
| DocScrutinizer06 | how about fixing the slider ? | 21:29 |
| Sc0rpius | I would need another button, I've slided too much and the little bar is flat so the whole button is flat | 21:30 |
| DocScrutinizer06 | a long push to power button does (TZZZDUM) power off | 21:30 |
| Sc0rpius | yeah that's fine. | 21:30 |
| Sc0rpius | but I would like to redefine the short push | 21:30 |
| Sc0rpius | to lock/unlock without annoyances | 21:30 |
| DocScrutinizer06 | the short push also does power off, though with an option for software to intercept | 21:31 |
| DocScrutinizer06 | it's a quite special kind of button | 21:31 |
| Sc0rpius | well I saw an application in tmo these days | 21:32 |
| Sc0rpius | I forgot the name | 21:32 |
| DocScrutinizer06 | I'd get a spare part for the slider button | 21:33 |
| Sc0rpius | QtLockScreen | 21:33 |
| Sc0rpius | I guess the guy that wrote it somehow intercepted the button | 21:33 |
| Sc0rpius | and the whole thing actually | 21:33 |
| Sc0rpius | he made a video | 21:33 |
| Sc0rpius | http://www.youtube.com/watch?v=hUK7OvJZGdo | 21:33 |
| Sc0rpius | I should test his application first since it doesn't have a slide (but it has a button) | 21:34 |
| Sc0rpius | and then read his source code | 21:34 |
| DocScrutinizer06 | no, it's probably low level maemo (even kernel) that intercepts it | 21:34 |
| DocScrutinizer06 | the higher level stuff prolly will use dbus to learn about power button pressed | 21:34 |
| Sc0rpius | well but he definitely made it | 21:35 |
| DocScrutinizer06 | well sure, you can replace what's there and already doing it by some own stuff | 21:35 |
| DocScrutinizer06 | but I guess it's easy to make it behave exactly like the lockslider | 21:36 |
| DocScrutinizer06 | it's NOT easy | 21:36 |
| DocScrutinizer06 | honestly, why don't you fix the friggin plastic lever | 21:36 |
| Sc0rpius | and where I can find a new one | 21:36 |
| DocScrutinizer06 | or get a spare | 21:36 |
| Sc0rpius | the N900 has been discontinued for so long | 21:37 |
| Sc0rpius | it's very hard to find replacements for it | 21:37 |
| DocScrutinizer06 | I could dremel one for you, from solid gold ;-D | 21:37 |
| Sc0rpius | hehehehe | 21:37 |
| DocScrutinizer06 | or just glue a layer of solid gold handle on top of the worn plastic | 21:38 |
| * DocScrutinizer06 wonders what users do to lockslider, as Sc0rpiusisn't the only one with exactly this problem | 21:39 | |
| Sc0rpius | that's the ONLY hardware button I use | 21:43 |
| Sc0rpius | everytime I check my phone I slide it | 21:44 |
| Sc0rpius | that's like 129035468912346589127364981273465 times a day | 21:44 |
| *** xnt14 has quit IRC | 21:46 | |
| *** MohammadAG has quit IRC | 21:46 | |
| *** xnt14 has joined #maemo-ssu | 21:48 | |
| *** MohammadAG has joined #maemo-ssu | 21:48 | |
| DocScrutinizer06 | sure thing, nevertheless this plastic lever has to be a defective part as well | 21:49 |
| DocScrutinizer06 | otherwise I can't see how anybody except Krueger would ruin it by operating it | 21:49 |
| DocScrutinizer06 | except of course when dust and fine sand blocks the slide | 22:03 |
| DocScrutinizer06 | anyway, looking at it I think you even can drill a 1mm hole into it ans screw a knob on top | 22:05 |
| DocScrutinizer06 | and* | 22:05 |
| *** MohammadAG has quit IRC | 22:05 | |
| *** MohammadAG has joined #maemo-ssu | 22:05 | |
| DocScrutinizer06 | or glue a 0.8mm steel bolt into the 1mm hole, with a nice round end that just protrudes 1.5mm over the flat surface of the bump sliding in the hole | 22:06 |
| *** trbs has joined #maemo-ssu | 22:07 | |
| DocScrutinizer06 | s/in the hole/in the case apperture/ | 22:07 |
| infobot | DocScrutinizer06 meant: or glue a 0.8mm steel bolt into the 1mm hole, with a nice round end that just protrudes 1.5mm over the flat surface of the bump sliding in the case apperture | 22:07 |
| MohammadAG | <freemangordon> It is MohammadAG that is the most knowledgeable, so maybe we should trust him | 22:10 |
| MohammadAG | hmm? | 22:10 |
| *** int_ua has quit IRC | 22:24 | |
| *** int_ua has joined #maemo-ssu | 22:39 | |
| *** int_ua has quit IRC | 22:45 | |
| *** int_ua has joined #maemo-ssu | 22:55 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!