**** BEGIN LOGGING AT Sun Jul 05 02:59:58 2009
Jul 05 04:08:05 <CIA-45> SHR: 03frazier.cameron 07shr-settings * r6aae692e147f 10/shr_settings_modules/shr_currentprofile.py: [CurrentProfile] Small tweak to sort out an interface annoyance.
Jul 05 04:08:17 <CIA-45> SHR: 03frazier.cameron 07shr-settings * r30a9ca4d8c1c 10/shr_settings_modules/shr_about.py: [About] Cosmetic fix, found as dos fixed what I was doing wrong. Thanks dos\!
Jul 05 04:08:18 <CIA-45> SHR: 03frazier.cameron 07shr-settings * r894d14df096b 10/playground/shr-settings-toolbar: [Launcher-Toolbar] Fixed finger sizing
Jul 05 06:38:21 <khiraly1> is there doc available how to querry gps from frameworkd ?
Jul 05 06:38:54 <tmzt> freesmartphone.org
Jul 05 06:38:57 <tmzt> api docs
Jul 05 06:40:07 <khiraly1> http://lists.openmoko.org/nabble.html#nabble-td2443946 <-- Im also wondering if monto published his python program
Jul 05 06:41:16 <khiraly1> tmzt: is the org.freedesktop.Gypsy.Accuracy is the correct one to use?
Jul 05 06:41:43 <tmzt> don't know
Jul 05 06:44:13 <khiraly1> btw, how fast generates the chip the gps positions ? /1s /100ms /10ms ?
Jul 05 06:45:01 <tmzt> on fr? I don't work with it
Jul 05 07:09:18 <PaulFertser> khiraly1: the default is 1 Hz
Jul 05 07:09:32 <khiraly1> PaulFertser: and what is the max?
Jul 05 07:10:01 <PaulFertser> khiraly1: i don't know, at least 4 but frameworkd doesn't support any other rates except 1 anyway. 
Jul 05 07:10:12 <khiraly1> aham
Jul 05 07:10:14 <khiraly1> ;)
Jul 05 07:10:22 <khiraly1> so iit is useless for rocket purpose
Jul 05 07:10:23 <khiraly1> ;)
Jul 05 07:10:39 <PaulFertser> khiraly1: you can use u-blox protocol directly to get what you need
Jul 05 07:11:03 <khiraly1> I only want the basics for now. Just curious
Jul 05 07:11:34 <PaulFertser> khiraly1: the basics you can get easily with FSO, even simple mdbus calls will do.
Jul 05 07:12:02 <PaulFertser> khiraly1: altenatively, you can run fso-gpsd and use regular gpsd protocol.
Jul 05 07:12:15 <khiraly1> gypsy is the preferred way?
Jul 05 07:14:13 <khiraly1> (preferred way == no need to worry about power consumption, and suspend)
Jul 05 07:14:47 <PaulFertser> khiraly1: fso-gpsd requests resource only when any client is connected. So if you disconnect from socket, it will release it automatically.
Jul 05 07:15:20 <khiraly1> this fso-gpsd is org.freedesktop.Gypsy.Accuracy ?
Jul 05 07:15:58 <PaulFertser> khiraly1: what? fso-gpsd is a daemon that provides regular gpsd-compatible (to a limited extent) protocol.
Jul 05 07:16:33 <khiraly1> I can querry directly frameworkd
Jul 05 07:16:46 <khiraly1> http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freedesktop.Gypsy.Accuracy.html;hb=HEAD
Jul 05 07:17:41 <PaulFertser> khiraly1: sure
Jul 05 07:18:07 <khiraly1> it is a bit cloudy how many gps deamons are running ...
Jul 05 07:18:16 <PaulFertser> khiraly1: btw, the api docs are incomplete, e.g. there's no mention of interface to request per-sattelite information.
Jul 05 07:19:13 <khiraly1> I was toying an idea of implementing image viewer/browser in paroli. And what else would be better then having a yet another gps viewer application
Jul 05 07:19:14 <khiraly1> ;)
Jul 05 07:19:59 <khiraly1> PaulFertser: btw, my kiss fileformat reference implementation is almost done. There are some polishing left (like specifiyng the default filename, etc)
Jul 05 07:57:55 <PaulFertser> Guys, anyone wants to discuss battery percentage reporting for gta01? The trick is: old .24 reported charge percentage but it's linear and completely bogus. Should we do that as a bandaid in recent kernels or not? DocScrutinizer ? rtp ? 
Jul 05 07:58:56 <PaulFertser> The proper semantics from Documentation/bla-bla is to report only something we directly measure/read, all guessing, estimation and stuff should be done in a userspace library (that is yet to be written, according to docs).
Jul 05 07:59:36 <PaulFertser> raster: What's your opinion about handling _very_ (only current and voltage available) dumb battery management hardware?
Jul 05 08:13:32 <raster> PaulFertser: hmmm
Jul 05 08:14:00 <raster> well batteries as they lose charge drop voltage - using some kind of curve
Jul 05 08:14:26 <raster> you can measure that curve on a new battery withthe system on continually with the same power drain (ie doing nothing but polling from the cpu every now and again)
Jul 05 08:14:42 <raster> you can map that curve - store it and of course ed up doing a reverse lookup
Jul 05 08:14:52 <raster> adjusted for the start or end points
Jul 05 08:15:10 <raster> (based on the level it last reached when charging finished - ie voltage failed to go up anymore)
Jul 05 08:16:34 <PaulFertser> raster: sure, it's possible and it's basically what should be done. But it's not something that belongs to the kernel-space, is it?
Jul 05 08:16:47 <raster> hmmm
Jul 05 08:16:55 <raster> that is a good point
Jul 05 08:17:10 <raster> i am not sure
Jul 05 08:17:26 <raster> there is no precedent for userspace having to handle this
Jul 05 08:17:42 <raster> as userspace shouldnt imho need to know what kind of curve the batery voltage drop uses
Jul 05 08:30:39 <PaulFertser> raster: let me cite Documentation/power/power_supply_class.txt: "Inferring not available properties using some heuristics or mathematical model is not subject of work for a battery driver. Such functionality should be factored out ... full-fledged battery model is likely not subject for kernel at all, as it would require floating point calculation to deal with things like differential equations and Kalman filters. This is better be handled by
Jul 05 08:30:45 <PaulFertser> ... batteryd/libbattery, yet to be written."
Jul 05 08:31:34 <raster> "yet to be written"
Jul 05 08:31:41 <raster> it doesnt exist
Jul 05 08:32:48 <raster> no battery yet handled on any linux system i know of is unable to report thngs like actual level (as opposed to the dumb cheap batteries you see at least in older phones)
Jul 05 08:33:44 <PaulFertser> raster: so what do you propose for gta01? Now the battery gadget has zero idea about capacity because only voltage and current is availble.
Jul 05 08:35:06 <raster> i propose that gta01 is pretty close to a dead device
Jul 05 08:35:10 <raster> no more will be mde
Jul 05 08:35:18 <raster> there are maybe at most 1000 in existence
Jul 05 08:35:25 <raster> and over time will vanish
Jul 05 08:35:48 <raster> unless you want to=write libbat.so
Jul 05 08:35:55 <raster> it makes sense
Jul 05 08:36:18 <raster> there should be more libs that abstract the kernel /proc and /sys api's
Jul 05 08:36:38 <raster> but unless they exist - things have to go straight to kernel
Jul 05 08:37:43 <PaulFertser> raster: if only i could get a gta01... I have no idea where to get that discharge curve.
Jul 05 08:38:00 <raster> bingo
Jul 05 08:38:03 <raster> thats the problem
Jul 05 08:38:07 <raster> there are so few
Jul 05 08:38:10 <raster> u cannto get them anymore
Jul 05 08:38:15 <raster> and they will slowly disappear
Jul 05 08:38:23 <raster> i used to have one - and somewhere it got lost
Jul 05 08:38:27 <raster> no idea where it is
Jul 05 08:39:32 <PaulFertser> I found information about 2 devices near Moscow but failed to contact the owners.
Jul 05 08:39:46 <raster> hehehe
Jul 05 08:40:19 <raster> really - i would wait until a real new product surfaces that has a primitive battery
Jul 05 08:40:32 <raster> and a new producyt
Jul 05 08:40:34 <raster> product
Jul 05 08:47:18 <PaulFertser> raster: you demotivate me ;)
Jul 05 08:47:27 <raster> hehehehe
Jul 05 08:47:31 <raster> well it's being practical
Jul 05 08:47:35 <raster> you will hunt down a phone
Jul 05 08:47:37 <raster> get lots of data
Jul 05 08:47:39 <raster> do code
Jul 05 08:48:32 <raster> for a platform that very soon may really cease to exist - and that i'd argue already has ceased as i know how many were made - and there are maybe 400 more or less in the "wild" in use
Jul 05 08:48:36 <raster> possibly een fewer
Jul 05 08:48:53 <raster> and in 1 year - it will be half that or less i suspect
Jul 05 08:49:05 <raster> wait for a bigger one to appear
Jul 05 08:53:09 <PaulFertser> I'm a humble guy. I usually spend lots of time doing nothing at all. If i can do something that will make even 10 devices work a little bit better, it'd still be more fun than doing nothing staring on failblog.org in despair.
Jul 05 09:21:40 <raster> PaulFertser: i guess i always look at it through my eyes - and my list of things to do and that i am doing is so log - i try and get things OFF it, not onto it, so nothing goes onto it without a very very very good justification  - it has to be more useful/important than my current stuff
Jul 05 09:42:37 <Q-Master> mrmoku|a`: I've tried to upgrade now but: ollected errors:
Jul 05 09:42:37 <Q-Master>  * ERROR: Cannot satisfy the following dependencies for frameworkd-config-shr-dev:
Jul 05 09:42:37 <Q-Master>          *  frameworkd-config-shr (= 0.8.5.1+gitr1473+130fb4c50f81b803d42b32c69f20e0713930f741-82+060495f1ddcf6db79c1cd9d12e51b47adac8e2ed-r6) *
Jul 05 09:57:51 <farhaven> should opkg segfault if i install a large number of packages?
Jul 05 09:58:13 <farhaven> i just did an opkg upgrade on a fresh unstable image and it segfaulted after a while
Jul 05 09:58:40 <farhaven> and it looks like it didn't update the installed packages database, because when I rerun it, it starts all over again
Jul 05 10:00:02 <Q-Master> crap
Jul 05 10:00:03 <Q-Master>        ERROR    SIM-Messages-FSO: Could not install signal handlers!
Jul 05 10:00:03 <Q-Master> 2009.07.05 13:58:19.695 dbus.connection      ERROR    Exception in handler for D-Bus signal:
Jul 05 10:00:03 <Q-Master> Traceback (most recent call last):
Jul 05 10:00:03 <Q-Master>   File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 214, in maybe_handle_message
Jul 05 10:00:03 <Q-Master>     self._handler(*args, **kwargs)
Jul 05 10:00:04 <Q-Master>   File "/usr/lib/python2.6/site-packages/framework/subsystems/opimd/pimb_sim_messages_fso.py", line 317, in handle_auth_status
Jul 05 10:00:07 <Q-Master>     self.gsm_device_iface.SetSimBuffersSms(self.am_i_default(), reply_handler=self.dbus_ok, error_handler=self.dbus_err)
Jul 05 10:00:10 <Q-Master> AttributeError: 'SIMMessageBackendFSO' object has no attribute 'gsm_device_iface'
Jul 05 10:17:47 <mrmoku> raster, what would be your estimate how far away a stable e17 is now?
Jul 05 10:17:59 <mrmoku> shr users hate me every time I update EFL_SRCREV ;)
Jul 05 10:18:44 <raster> if there was a stable
Jul 05 10:18:53 <raster> u'd complain because itws missing features the new svn stuff has
Jul 05 10:18:56 <raster> and then update anyway
Jul 05 10:18:57 <raster> :)
Jul 05 10:19:00 <Q-Master> mrmoku: have you seen what I've written a bit upper?
Jul 05 10:19:09 <mrmoku> Q-Master, yep
Jul 05 10:19:36 <mrmoku> the frameworkd-config-shr issue I've seen on ML too
Jul 05 10:19:36 <Q-Master> kill dos1 for me. 8)
Jul 05 10:20:14 <mrmoku> the other one is more an issue ;)
Jul 05 10:20:35 <mrmoku> raster, yeah
Jul 05 10:20:50 <mrmoku> but someday you will do a stable release, no?
Jul 05 10:21:07 <mrmoku> just wanted to know if it is more like in three months or in three years :P
Jul 05 10:21:43 <raster> yes
Jul 05 10:21:50 <raster> but stable is just a label
Jul 05 10:21:52 <raster> nothing more
Jul 05 10:22:04 <raster> andf dont klnow
Jul 05 10:22:07 <raster> we dont give timeframes
Jul 05 10:22:11 <mrmoku> well... no, because after that label you will keep sonames ;)
Jul 05 10:22:14 <raster> because all timeframes are crap
Jul 05 10:22:18 <raster> they will not be kept
Jul 05 10:22:24 <raster> i may as wel say next month
Jul 05 10:22:28 <raster> it wont happen
Jul 05 10:22:47 <raster> sonames are no problem
Jul 05 10:23:00 <mrmoku> but you might have an idea about what is still missing and how long it *might* take to acomplish
Jul 05 10:23:09 <raster> it just forces an upgrade of apps and libs using the updated libs
Jul 05 10:23:12 <raster> thats all
Jul 05 10:23:25 <raster> sam as any masoe so version change
Jul 05 10:23:50 <raster> dont have any idea as its mostly e17 (the wm) missing stuff - not libs
Jul 05 10:23:55 <raster> and very few are working on it
Jul 05 10:24:08 <mrmoku> this is fine for stuff we have in our feed
Jul 05 10:24:09 <raster> not to mention i am about to have a new lump of efl additions added to my plte
Jul 05 10:24:11 <mrmoku> we can rebuild them
Jul 05 10:24:11 <raster> plte
Jul 05 10:24:22 <raster> it looks like it'll kep me busy for 9 months
Jul 05 10:24:29 <mrmoku> :)
Jul 05 10:24:38 <raster> the point of the soname changes is stability
Jul 05 10:24:46 <raster> so you compile AGAINST the same lib version
Jul 05 10:24:52 <raster> not having it means less stability
Jul 05 10:24:58 <raster> yes - it means rebuils for apps
Jul 05 10:25:08 <raster> but not doing it means randomly crashing aps that arent rebuilt
Jul 05 10:25:23 <raster> what ois better? random unexplainable crashes or simply not running and making u rebuild?
Jul 05 10:25:25 <mrmoku> I know and understand that
Jul 05 10:25:42 <mrmoku> I'm just having a hard time to explain that to our users
Jul 05 10:26:09 <mrmoku> they use packages from here and there and then complain they break whenever we update EFL
Jul 05 10:26:17 <raster> thats the problem - users dont understand
Jul 05 10:26:27 <raster> you can simply not update efl
Jul 05 10:26:31 <raster> that will have stability then
Jul 05 10:26:33 <raster> :)
Jul 05 10:26:37 <mrmoku> :P
Jul 05 10:26:56 <raster> that is exactly what distros do
Jul 05 10:27:14 <raster> they use the same version of x or kernel or whatever release after release
Jul 05 10:27:14 <raster> etc.
Jul 05 10:27:19 <raster> update after update
Jul 05 10:27:28 <raster> they change major things every 6-12 months
Jul 05 10:27:53 <mrmoku> yep, our problem is we do not yet have a release :)
Jul 05 10:28:09 <mrmoku> and people use shr-unstable, because it is mostly the best working shr
Jul 05 10:28:33 <mrmoku> guess we have to work harder to get a first release out then
Jul 05 10:28:41 <raster> you use a specific svn rev
Jul 05 10:28:49 <raster> i hope you are using the one we announce in our snapshots
Jul 05 10:28:53 <mrmoku> yep :)
Jul 05 10:28:53 <raster> ie the tarballs we make
Jul 05 10:29:02 <raster> that is technically a release
Jul 05 10:29:04 <raster> like any other
Jul 05 10:29:07 <mrmoku> from svn though, but the rev you announced on e list
Jul 05 10:29:08 <raster> it is no different
Jul 05 10:29:23 <raster> its probably substantially higher quality than most software releases
Jul 05 10:29:37 <raster> using that particular svn rev - or the tarballs, is no different
Jul 05 10:29:43 <raster> its the exact same identical code
Jul 05 10:58:26 <SHR-WugBranler`> tracfeed: Ticket #318 (GetPowerStatus doesn't work on gta01) updated <http://trac.shr-project.org/trac/ticket/318#comment:7>
Jul 05 11:28:10 <Q-Master> dos1!
Jul 05 11:29:10 <Q-Master> dos1: have you seen this: AttributeError: 'SIMMessageBackendFSO' object has no attribute 'gsm_device_iface'?
Jul 05 11:42:59 <morphis> heyho
Jul 05 11:45:52 <morphis> DocScrutinizer: do you have some time to look at this: http://lists.gnufiish.org/pipermail/gnufiish-devel/2009-July/000158.html
Jul 05 11:46:20 <morphis> someone told me another way how it could be possible to repair my broken testpad
Jul 05 11:48:49 * Q-Master uploaded a new fbreader to opkg.org
Jul 05 11:52:39 <dos1> Q-Master: where  you get that error?
Jul 05 11:53:23 <Q-Master> dos1:  2009.07.05 13:58:19.684 opimd                ERROR    SIM-Messages-FSO: Could not install signal handlers!
Jul 05 11:53:23 <Q-Master> 2009.07.05 13:58:19.695 dbus.connection      ERROR    Exception in handler for D-Bus signal:
Jul 05 11:53:23 <Q-Master> Traceback (most recent call last):
Jul 05 11:53:23 <Q-Master>   File "/usr/lib/python2.6/site-packages/dbus/connection.py", line 214, in maybe_handle_message
Jul 05 11:53:23 <Q-Master>     self._handler(*args, **kwargs)
Jul 05 11:53:26 <Q-Master>   File "/usr/lib/python2.6/site-packages/framework/subsystems/opimd/pimb_sim_messages_fso.py", line 317, in handle_auth_status
Jul 05 11:53:28 <Q-Master>     self.gsm_device_iface.SetSimBuffersSms(self.am_i_default(), reply_handler=self.dbus_ok, error_handler=self.dbus_err)
Jul 05 11:53:31 <Q-Master> AttributeError: 'SIMMessageBackendFSO' object has no attribute 'gsm_device_iface'
Jul 05 12:23:32 <larsc> Weiss: I think I found the reason for the WSOD during Xorg restarting and sd card access.
Jul 05 12:25:16 <Weiss> larsc: :D go on..
Jul 05 12:26:01 <dos1> Q-Master: do you have latest frameworkd?
Jul 05 12:26:41 <Q-Master> dos1: just updated. but with error about frameworkd-config-shr unable to update
Jul 05 12:31:18 <Weiss> larsc: anything to do with locking in glamo-core.c?
Jul 05 12:31:36 <larsc> Weiss: The part which disables the cmdq engine disables also the divider used for all memory clocks. see http://git.openmoko.org/?p=xf86-video-glamo.git;a=commitdiff;h=69ccc9307c6b6a1aeb1f51ea732af20d52a66685
Jul 05 12:32:09 <larsc> and thus mmc memory clock gets disabled aswell
Jul 05 12:35:03 <PaulFertser> morphis: is that a via to the left of the place where TP was?
Jul 05 12:35:23 <Weiss> larsc: aha.. that seems definitely plausible..
Jul 05 12:36:19 <larsc> Weiss: my freerunner survived half an hour of reading from the sd card and constantly restarting the xserver
Jul 05 12:36:47 <PaulFertser> morphis: and i think the only way you damaged the TP (unless you pulled hard the wire after soldering) is overheating the TP.
Jul 05 12:38:38 <larsc> Weiss: another thing which could cause problems is how the clock dividers for engines are enabled/disabled.
Jul 05 12:39:40 <larsc> GLAMO_REG_CLOCK_GEN5_1 is read then the appropriate bit is set and its written back
Jul 05 12:39:52 <Weiss> interesting... i was just looking at the kernel version of the same function, and it doesn't do that disablement
Jul 05 12:40:22 <larsc> if two process do this at the same time we could lose one update
Jul 05 12:40:23 <Weiss> ..yet i was able to reproduce something similar to "lindi-'s crash"
Jul 05 12:40:52 <cunner1> hi all! i'm using the literki keyboard in shr unstable and i'd like to add a key for the degree symbol (for geocaching) in the configfile. for some reason this does not seam to work. has anybody tried something similar?
Jul 05 12:40:59 <Weiss> yes.. that's just an example of "nasty locking (or lack of) between userspace and kernel space"... KMS gets rid of all that :) (i'm happy to be able to report KMS is vaguely working over here)
Jul 05 12:41:12 <larsc> so I implemented ioctls to enable/disable engines, so the xorg driver only touches only 2d and cmdq registers
Jul 05 12:42:31 <larsc> well and i cleaned up the mmc driver, so i doesn't touch general registers without holding the cores lock
Jul 05 12:44:23 <Weiss> sounds good! i think KMS is overall a better (perhaps longer-term) way to get rid of these kinds of nastiness, though
Jul 05 12:48:48 <Weiss> larsc: with very little extra code, i think we can have a situation where a non-KMS-aware DDX works with a KMS kernel, and a KMS DDX also works with a non-KMS DDX
Jul 05 12:49:39 <larsc> Weiss: tell me
Jul 05 12:50:41 <Weiss> as part of the bootup, KMS sets up /dev/fb0. X is free to use that if it wants. the only restriction would concern switching from a low to a higher resolution screen, but since we start up in the highest allowed resolution anyway, that's not a problem
Jul 05 12:50:53 <SHR-WugBranler`> tracfeed: Ticket #463 (retrieve prefix codes automatically from SIM) updated <http://trac.shr-project.org/trac/ticket/463#comment:11>
Jul 05 12:51:03 <Weiss> a KMS-aware DDX works by creating a screen in a GEM object then submitting that to the kernel via an ioctl for display
Jul 05 12:52:43 <Weiss> the only issue is that /dev/fb0 should expose the minimum amount of memory - only enough for 480x640x16bit, so the DDX, if working in fbdevhw mode, wouldn't have access to RAM for offscreen pixmaps
Jul 05 12:53:24 <Weiss> i propose to deal with this by exposing more memory via /dev/fb0, and having a kernel configuration option (or perhaps even a boot cmdline option) to "optimise for KMS"
Jul 05 12:54:40 <Weiss> an alternative would be to have non-KMS DDX + KMS kernel resulting in slow graphics
Jul 05 12:55:03 <Weiss> in all of this, the original situation can be arrived at always by configuring the kernel with glamo-fb and without glamo-drm
Jul 05 12:55:13 <Weiss> (the two options are mutually exclusive)
Jul 05 12:56:07 <Weiss> make sense?
Jul 05 12:58:11 <larsc> hm, yes
Jul 05 12:58:57 <morphis> DocScrutinizer & DocScrutinizer2: ping
Jul 05 13:00:33 <[Rui]> mirko: hi
Jul 05 13:00:49 <mirko> [Rui]: hi
Jul 05 13:00:55 <[Rui]> mirko: in the sms list, when one slides horizontally new buttons popup
Jul 05 13:01:02 <[Rui]> mirko: what elementary widget is that?
Jul 05 13:01:17 <[Rui]> mirko: would be nice to have that in elmdentica :)
Jul 05 13:01:31 <mirko> [Rui]: seems you're expecting talking to paroli-mirko who i'm not :)
Jul 05 13:01:41 <[Rui]> mirko: ow :( no fair :)
Jul 05 13:01:50 <[Rui]> anyone else knows?
Jul 05 13:03:04 <larsc> Weiss: another thing that would be good to have is clock managment, so we can automaticaly turn of clocks and dividers which are not in use.
Jul 05 13:06:57 <mirko> larsc: preparation for your talk about TCP which will start in < 24h finished? :P
Jul 05 13:14:56 <PaulFertser> morphis: is that a via to the left of the place where TP was?
Jul 05 13:16:33 <PaulFertser> GTA01 users! I need your feedback! What are you currently using to estimate battery charge level? Were you satisfied with bogus linear scale from .24 times? Do you have better ideas?
Jul 05 13:19:41 <Q-Master> PaulFertser: have you got a GTA01?
Jul 05 13:19:47 <PaulFertser> Q-Master: no :(
Jul 05 13:19:52 <PaulFertser> Q-Master: nobody answered :(
Jul 05 13:19:57 <Q-Master> crap
Jul 05 13:40:27 <larsc> PaulFertser: you have commit access to the om kernel, right?
Jul 05 13:42:22 <PaulFertser> larsc: right
Jul 05 13:43:09 <larsc> PaulFertser: want to commit http://lists.openmoko.org/pipermail/openmoko-kernel/2009-July/010310.html ?
Jul 05 13:44:19 <PaulFertser> larsc: hm, i need to compare with the patches that got committed to alsa-devel kernel tree first.
Jul 05 13:45:13 <larsc> they are the same
Jul 05 13:49:22 <CIA-45> SHR: 03seba.dos1 07shr * r415da8038201 10/libframeworkd-phonegui-efl/data/contacts.edc: libframeworkd-phonegui-efl: change order of buttons (ok/accept/yes/green - left, no/close/cancel/red - right) [part 3]
Jul 05 13:50:12 <PaulFertser> larsc: except for the sizeof(wm8753_reg) -> sizeof(wm8753->reg_cache) change 
Jul 05 13:51:40 <PaulFertser> larsc: are you ok if i commit http://git.kernel.org/?p=linux/kernel/git/broonie/sound-2.6.git;a=commitdiff;h=1df892cba45f9856d369a6a317ad2d1e44bca423 and http://git.kernel.org/?p=linux/kernel/git/broonie/sound-2.6.git;a=commitdiff;h=637a935aaba2f05e2178c9d1b714d7a2c36c8b44 "as is"?
Jul 05 13:54:12 <larsc> PaulFertser: sure
Jul 05 14:09:49 <PaulFertser> larsc: pushed, mail sent, thanks a lot :)
Jul 05 14:57:03 <TAsn> damn, I'm blind ;(
Jul 05 14:57:05 <TAsn> http://scap.linuxtogo.org/files/b17befba6c88cab96ee7f00e0fcdd107.png
Jul 05 14:57:31 <TAsn> I mean, those pictures blinded me (only for a couple of minutes), though I'm ok now, I'm regaining my vision :)
Jul 05 15:18:42 <PaulFertser> TAsn: somebody should do a black&green only theme to emulate old CRTs. 
Jul 05 15:21:10 <TAsn> I never really used a crt this old :)
Jul 05 15:21:27 <TAsn> though I have seen ones (from a distance)
Jul 05 15:24:00 <PaulFertser> TAsn: same for me (though probably i saw them really near)
Jul 05 15:24:33 <TAsn> I also saw ones really near, though haven't actually used one
Jul 05 15:24:43 <TAsn> (that's what I meant by "from a distance")
Jul 05 15:31:18 <|Marco|> what's heppend to dbus in latest shr? whet's the new "method" of usage ?
Jul 05 15:32:07 <|Marco|> *happened*
Jul 05 15:39:49 <|Marco|> noone.. okay
Jul 05 15:59:33 <|Marco|> I'm getting "Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged" when doing just about anything with dbus, what's going on ?
Jul 05 16:01:28 <Gorbusch|away> @|Marco| you can / should ignore this for the moment
Jul 05 16:01:49 <|Marco|> Gorbusch|away: yeah, but it's killing my gprs gui
Jul 05 16:02:23 <Gorbusch|away> are you sure about this, i get those messages and never got any problems with my dbus apps
Jul 05 16:03:00 <Gorbusch> which gps app did you use?
Jul 05 16:03:06 <|Marco|> gprs
Jul 05 16:03:22 <|Marco|> and it worked anyway, but still, what's the deal ?
Jul 05 16:04:25 <Gorbusch> the problem is as far as i know in the used libs, they should be switched to the new way of using return calls
Jul 05 16:05:25 <|Marco|> aha
Jul 05 16:06:01 <|Marco|> thanks, the error message didn't give me much clues to that.. I'm not that in depth with dbus and all the libs :/
Jul 05 16:26:02 <agg1n> should i use fso trac to reaport a bug/problem related to libeflvala?
Jul 05 16:48:09 <PaulFertser> alphaone: ping
Jul 05 16:48:21 <alphaone> pong
Jul 05 16:48:58 <PaulFertser> alphaone: the guy on ML claims that his tests showed he could get true FF in ~40s. Is it possible at all?
Jul 05 16:49:07 <alphaone> yes
Jul 05 16:49:11 <alphaone> definitely
Jul 05 16:49:46 <PaulFertser> alphaone: i've read that to download almanacs one needs to receive 25 frames, each frame requires 30s.
Jul 05 16:50:19 <alphaone> You only need ephimeris for navigation
Jul 05 16:50:50 <PaulFertser> What is almanac good for then?
Jul 05 16:51:11 <alphaone> almanac is valid for a longer time
Jul 05 16:51:20 <PaulFertser> But how is it used at all?
Jul 05 16:51:45 <alphaone> To know  which satellites to look for initially
Jul 05 16:52:03 <PaulFertser> Doesn't it receive the data from all sats simultaneously?
Jul 05 16:52:52 <alphaone> with modern chipsets it hardly makes a difference because they have many correlators
Jul 05 16:53:16 <alphaone> to look for the different satellites in parallel
Jul 05 16:54:31 <PaulFertser> Is our antaris modern enough? Does it mean it doesn't need almanac data at all?
Jul 05 16:56:41 <SHR-WugBranler`> tracfeed: Ticket #533 (erminig unusable) updated <http://trac.shr-project.org/trac/ticket/533#comment:3>
Jul 05 16:59:04 <alphaone> PaulFertser: http://u-blox.com/en/download-center.html?task=summary&cid=83&catid=97
Jul 05 16:59:41 <alphaone> page 89
Jul 05 16:59:48 <Wonka> antaris4 does need almanach
Jul 05 16:59:51 <PaulFertser> alphaone: heh, does it mean you don't know the answer off-hand or that you want to teach me to get information myself? :D Ok, thanks.
Jul 05 17:00:22 <Wonka> alphaone: almanach is less info than ephemeris...
Jul 05 17:00:37 <alphaone> PaulFertser: it will begin navigating even if it only has ephemeris
Jul 05 17:00:58 <alphaone> Wonka: yes, but almanac is sent from all for all SVs
Jul 05 17:01:45 <Wonka> almanach is coarse nav info. ephemeris is fine nav info. for a fix, you need ephemeris && locked signal of at least four sats.
Jul 05 17:01:54 <Wonka> for a 3d fix
Jul 05 17:03:47 <Wonka> if i've got internet somehow, and a coarse idea of where i am, i can download almanach and ephemeris info for "about my position", put it to antaris4, anf get a fix in less than 30s after that.
Jul 05 17:03:54 <PaulFertser> alphaone: this file seem to be damaged, only 3.2M is download instead of 6.4
Jul 05 17:03:55 <Wonka> btdt, several times
Jul 05 17:04:44 <Wonka> PaulFertser: almanach is good for having an idea what satellites to expect about where in the sky.
Jul 05 17:05:21 <Wonka> hm. dinner. bbl.
Jul 05 17:05:35 <PaulFertser> Wonka: i know
Jul 05 17:05:52 <alphaone> PaulFertser: There is an option to enable navigation trough almanac on the antaris, but it's not very accurate
Jul 05 17:06:12 <alphaone> PaulFertser: Cold start can take down to ~47seconds
Jul 05 17:07:24 <PaulFertser> alphaone: thanks a lot for clarifications
Jul 05 17:08:47 <alphaone> I'll have to look at ICD-GPS-200c to find out why 40seconds is enough to receive the ephemeris when the transmission itself only repeats every 12.5minutes
Jul 05 17:09:27 <PaulFertser> alphaone: ephemeris are transmitted every 30 seconds
Jul 05 17:13:38 <[Rui]> |Marco|: hey
Jul 05 17:13:48 <[Rui]> |Marco|: solved that problem already?
Jul 05 17:14:18 <[Rui]> the messages you see are are a not serious problem, but maybe you're crashing because you're not doing g_type_init();
Jul 05 17:30:40 <agg1n> holy crap... in "compose sms"-screen i clicked accidentally on "close" but canceled closing with clicking on "no"... that resulted in having the text field in the "compose sms"-screen uneditable and half of the text was removed too... -_-
Jul 05 17:53:10 <|Marco|> [Rui]: might be it.. it looks like the app works.. but because of the messages, the app don't work exactly as it's supposed to
Jul 05 17:53:44 <[Rui]> |Marco|: you'll see that if you use gconftool-2 it'll display the same messages and work as expected!
Jul 05 17:54:45 <|Marco|> okiday
Jul 05 18:29:52 <troy> I have what should be a simple problem, but I can't for the life of me seem to figure out how to solve this. Alsa is looking for the sound device in /dev/snd/ folder but all of the device files are located in /dev (/dev/dsp /dev/pcmC0D0p ...etc). How do I get them to appear in /dev/snd?
Jul 05 18:30:50 <troy> It is a bootstrapped lenny running off the microSD card BTW
Jul 05 18:32:42 <PaulFertser> troy: check your /etc/udev/rules.d/50-udev.rules
Jul 05 18:33:28 <PaulFertser> troy: i have KERNEL=="controlC[0-9]*", NAME="snd/%k"; KERNEL=="pcmC[D0-9cp]*",  NAME="snd/%k" and the like there
Jul 05 18:33:56 <PaulFertser> troy: and of course you need to have udevd running
Jul 05 18:34:34 <troy> aha.. that explains it.. I removed that file. I'll try restoring the backup I made of it
Jul 05 18:35:42 <PaulFertser> troy: :D
Jul 05 18:35:46 <PaulFertser> troy: why did you do that?
Jul 05 18:36:53 <troy> I did it when I was trying to get the touchscreen working. I looked at an old working udev and this file was not present. silly me.
Jul 05 18:46:04 <troy> PaulFertser: that worked.. thank you.
Jul 05 18:46:31 <PaulFertser> troy: welcome
Jul 05 18:48:11 <mrmoku> PaulFertser, did you see the report about glin not working on ML?
Jul 05 18:48:19 <PaulFertser> mrmoku: shr ML?
Jul 05 18:48:21 <mrmoku> looks like gta01 kernel is wrong again :(
Jul 05 18:48:25 <mrmoku> PaulFertser, moment
Jul 05 18:49:33 <mrmoku> PaulFertser, shr-user yeah
Jul 05 18:51:59 <PaulFertser> mrmoku: he didn't provide zgrep OABI /proc/config.gz output :-/
Jul 05 18:57:25 <PaulFertser> mrmoku: neither that, nor unstable build date.
Jul 05 19:00:20 <DocScrutinizer> PaulFertser: pomg
Jul 05 19:00:38 <PaulFertser> DocScrutinizer: heh :)
Jul 05 19:00:40 <DocScrutinizer> errr what's up?
Jul 05 19:00:53 * DocScrutinizer out of order
Jul 05 19:01:12 <PaulFertser> DocScrutinizer: was trying to gather opinions about what kernel should do with very dumb battery management like that on gta01.
Jul 05 19:02:36 <DocScrutinizer> my opinion: keep the gta01 stile for bat w/o CC in GTA02. Assuming the sysfs nodes stay compatible
Jul 05 19:03:48 <PaulFertser> DocScrutinizer: to do any capacity estimation in kernel space is contrary to the power_supply specs. But otoh raster said he's never seen such a dumb device that can't provide capacity and the library to do that based on voltage and current readings doesn't exists etc. So it seems that for gta01 we can do a simple several-segments approximation in kernel space. 
Jul 05 19:04:03 <PaulFertser> DocScrutinizer: SpeedEvil gave me a link to a good enough discharge graphs.
Jul 05 19:04:31 <lindi-> me usb battery does not provide capacity
Jul 05 19:04:47 <PaulFertser> lindi-: what does it provide?
Jul 05 19:05:06 <lindi-> PaulFertser: 5V
Jul 05 19:05:16 <lindi-> PaulFertser: 2200mAh
Jul 05 19:05:53 <lindi-> so theoretically 22 hours of gps tracking (100 mA consumption)
Jul 05 19:06:28 <PaulFertser> lindi-: no, i mean do you have _any_ way of estimating its remaining charge?
Jul 05 19:07:06 <DocScrutinizer> PaulFertser: ack. our sysfs node also delivers % charge where it should be absolute uAh.
Jul 05 19:07:57 <PaulFertser> lindi-: the problem i'm looking at is that now gta01 users have zero idea about how much charge they have. It was almost the case for the whole gta01 life because for percentages it used a completely bogus linear scale. Seems like nobody cared. But now it doesn't provide percentage estimation at all for the reasons i outlined before.
Jul 05 19:08:10 <DocScrutinizer> PaulFertser: otoh power management is rather nonstandard and is kinda borked even on my siemens-laptop for kde-power-applet
Jul 05 19:08:22 <PaulFertser> DocScrutinizer: no, on gta02 we provide both uAh (though from a slightly wrong register, sorry for that) and percentage.
Jul 05 19:08:31 <DocScrutinizer> s/nonstandard/device specific/
Jul 05 19:08:31 <bzzbot> DocScrutinizer meant: PaulFertser: otoh power management is rather device specific and is kinda borked even on my siemens-laptop for kde-power-applet
Jul 05 19:09:02 <PaulFertser> DocScrutinizer: for gta01 i've just sent a patch that brings units (mV -> uV and mA -> uA) for voltage and current in accordance with specs.
Jul 05 19:09:24 <DocScrutinizer> ok, sounds good
Jul 05 19:09:33 <lindi-> PaulFertser: i can charge it fully and then use current_now to estimate it :)
Jul 05 19:10:04 <DocScrutinizer> but sorry, I'm really handicapped today
Jul 05 19:11:13 <DocScrutinizer> we had street riots in my quarter last night, and I got headache today
Jul 05 19:11:15 <PaulFertser> lindi-: but you don't expect any WM gadget to show you that ;)
Jul 05 19:11:28 <PaulFertser> DocScrutinizer: street riots? :-O why?
Jul 05 19:13:06 <DocScrutinizer> radical anti-imp/anti-fa/anti-brain punksters going mad on a pubs' special event
Jul 05 19:15:51 <PaulFertser> Probably it'd be good if we had more anti-fa here. Too many fascists around, so many it's dangerous to live here, especially if you don't look like "russian".
Jul 05 19:16:53 <DocScrutinizer> hmm, applies for eastern germany as well. Not though for our quarter especially
Jul 05 19:17:51 <DocScrutinizer> so those drunken jung angry men basically destryed their own backyard :-S
Jul 05 19:20:03 <lindi-> PaulFertser: nope :)
Jul 05 19:21:00 <PaulFertser> lindi-: but gta01 users want to have at least some idea of percentage left
Jul 05 19:21:37 <PaulFertser> DocScrutinizer: any radicalism seem to be bad :(
Jul 05 19:21:49 <DocScrutinizer> ack
Jul 05 19:23:36 <DocScrutinizer> except radical punishment for redicalism that's missing the mandatory amount of intelect
Jul 05 19:32:52 <Th30z> Hi, How can I read PSN (product serial number) from app?
Jul 05 19:34:02 <PaulFertser> Th30z: mount -o ro /dev/mtdblock5 /mnt/; cat /mnt/sn; umount /mnt
Jul 05 19:34:35 <Th30z> PaulFertser: thanks!
Jul 05 19:57:10 <DocScrutinizer> th30z seems one of the drive-by-shooters of IRC. Fire question and log out. Otherwise I had suggested he considers to use IMEI instead of S/N which might better meets his needs, depending on usecase
Jul 05 19:59:36 <PaulFertser> :-/
Jul 05 20:07:17 <fredrin> How do i get the Literki keyboard transparent? 
Jul 05 20:07:31 <fredrin> it's a sweet keyboard
Jul 05 20:12:13 <fredrin> never mind, it was a button on the keyboard :) 
Jul 05 20:14:15 <tmzt> what format is mtdblock5?
Jul 05 20:14:19 <tmzt> fs
Jul 05 20:15:18 <PaulFertser> tmzt: ext2
Jul 05 20:15:33 <tmzt> ok
Jul 05 20:15:38 <tmzt> interesting
Jul 05 20:15:40 <tmzt> why?
Jul 05 20:16:10 <PaulFertser> tmzt: small factory partition, why not?
Jul 05 20:16:58 <tmzt> I guess since it's doesn't matter
Jul 05 20:17:06 <tmzt> for wearleveling
Jul 05 20:17:11 <PaulFertser> Yes
Jul 05 20:17:15 <PaulFertser> And it's simple 
Jul 05 20:17:22 <tmzt> it's ro
Jul 05 20:17:25 <tmzt> I meant
Jul 05 20:17:36 <tmzt> ok
Jul 05 21:46:33 <CIA-45> freesmartphone.org: 03mickey 07cornucopia * recbadf2618de 10/fsodeviced/src/ (bin/main.vala plugins/alsa_audio/plugin.vala): fsodeviced: don't fail, if no scenarios are available
Jul 05 23:29:55 <CIA-45> freesmartphone.org: 03mickey 07cornucopia * rd7cd1110c67f 10/misc-vapi/tests/ (4 files): misc-vapi: tests: prepare for testalsapcm
Jul 05 23:29:56 <CIA-45> freesmartphone.org: 03mickey 07cornucopia * r9db8a912e70f 10/fsodeviced/src/plugins/alsa_audio/plugin.vala: fsodeviced: alsa_audio: use quarks to transfer from/to strings
Jul 06 00:01:40 <CIA-45> freesmartphone.org: 03mickey 07cornucopia * rfabe53eed2aa 10/fsodeviced/src/plugins/alsa_audio/plugin.vala: fsodeviced: fix concurrent playing of multiple sounds
**** ENDING LOGGING AT Mon Jul 06 02:59:56 2009