<dsc_>
Wizzup: Do you know of a file extension that *does* have a mime handler?
<dsc_>
for example I have Dorian installed, but clicking on `.pdf` files does not yield dorian
<dsc_>
just making sure it is not hamsterfiler's fault
vipthx has quit [Quit: Leaving]
<Wizzup>
dsc_: pdf
<Wizzup>
should launch the pdf viewer
<Wizzup>
but I have not done much with mime
<Wizzup>
maybe ask freemangordon or uvos
<uvos>
Wizzup: cant look right now
<uvos>
Wizzup: dsc_: any and all maemo applications have broken mimes
<uvos>
install some desktop application
<uvos>
those work
<uvos>
so iirc on freemantle hildon-mime had a global mime database that it held iself and was only extensable via its own custom apis
<uvos>
while the xdg-mime system just uses the mime entries in .desktop files to generate a database
<uvos>
as hildon-mime is non functional anything that uses it is broken atm
<dsc_>
ok
<uvos>
also we probubly want to rid ourselves of this so that desktop applications can launch maemo ones and vice versa
<uvos>
hildon mime shal then be just a compatibily wrapper that uses the xdg stuff behind the scenes
<dsc_>
right
<uvos>
but yes this is totaly broken atm
<dsc_>
so hamsterfiler uses this hildon-mime thing with dbus
<dsc_>
like you said
<dsc_>
I can port that to xdg
<uvos>
maybe just port to xdg
<uvos>
yeah
<Wizzup>
let's check with fmg
<dsc_>
but uhh
<Wizzup>
not just remove it
<dsc_>
for example where is `xdg-open` ? :P
<dsc_>
or `xdg-mime`
<uvos>
freemangordon is usualy against changing anything api related - but please do add xdg support at least as an ifdef
<uvos>
that way hamsterfiler could be used on phosh etc too
<dsc_>
nvm, I think I can just use Qt5's QMimeDatabase
<uvos>
right that also wraps xdg
<dsc_>
ok :)
<uvos>
btw since we where launching the pdf viewer above
<uvos>
this is even more broken
<uvos>
since the pdf viewer dosent allow one to open a pdf via its commandline at all
<uvos>
you have to use the pdf viewers persistant dbus interface
<uvos>
meaning the pdf viewer is impossible to use in a proper mime
<uvos>
you can only use the pdf viewer to open a file by implenting its own custom interface
<Wizzup>
or it will just handle mime properly later on
<uvos>
hildon-mime dose this (and for lots of other applications too)
<Wizzup>
when it's ported to newer xpdf
<Wizzup>
I don't see the point of porting a hildon capable file manager and then stripping out the hildon parts :P
<Wizzup>
but maybe the mime stuff is super trivial, idk
<dsc_>
uvos: previously ive solved this by having applications opening an unix socket and when a 2nd instance is spawned it can detect it is already running (and communicate a "file open" to the 1st instance)
<dsc_>
dbus probably the better way to do that yeah
<dsc_>
albeit dbus not available on windows, so using unix sockets in Qt5 is nice, because on Windows it uses named pipes
<dsc_>
which keeps the application crossplatform
<Wizzup>
hildon has some of this solved already
<Wizzup>
probably that's why it has this mime stuff
<Wizzup>
we just need to make that work
<dsc_>
ill hold on porting to xdg for now
<Wizzup>
yeah, better to make sure the hildon mime stuff works as well
<dsc_>
unsure why hildon had to reinvent that wheel though
<uvos>
they reinvented most wheels
<Wizzup>
they invented them before it became a standard* ;-)
<uvos>
not in this case
<uvos>
anyhow
<uvos>
i just rememberd something
<uvos>
so hildon mime has these categorys xdg dosent have
<uvos>
and i seam to remember fmg implementing a heuristic to pars xdg mimes into the database
<uvos>
so acutally the hildon-mime xdg interop might be there allready
<uvos>
maybe try installin the thing
<mighty17[m]>
uvos: btw omapconf doesnt compile on android
<uvos>
or rather xdg has other categories
<uvos>
it has the same kind of categories but they are semanticly different
<uvos>
mighty17[m]: yes it dose :P
<uvos>
also not sure why you would want it on android
<uvos>
it works
<uvos>
but is mostly non functional because of missing defconfig flags
<uvos>
unless you go and compile your own debuging android kernel ofc
<mighty17[m]>
uvos: comparing registers
<uvos>
use rwmem
<mighty17[m]>
ah right
<uvos>
omapconf is way overkill
<mighty17[m]>
even rwmem does not
<uvos>
both of these compile fine for me
<mighty17[m]>
lemme try a clean build
<mighty17[m]>
my bad, uvos, it builds now, thanks!
<uvos>
speculating here, motorola dosent appear to use the counter at all - they use a mutch more complex setup where they have discarge curves for eatch battery
<uvos>
maybe this is because on early cpcap revisions the counter was broken
<bencoh>
many fuelgauge don't rely on the coulomb counter only - some don't use it at all, even in modern implementations
<uvos>
ok
<uvos>
maybe they just dident feal like using it what do i know
<bencoh>
(in my opinion it's kinda broken, but for some of their parts, Samsung insists on saying they rely on voltage only)
<bencoh>
-s
sunshavi has quit [Read error: Connection reset by peer]
sunshavi has joined #maemo-leste
mardy has quit [Quit: WeeChat 2.8]
akossh has joined #maemo-leste
ruleh has joined #maemo-leste
<Wizzup>
so 5.8 does still hit off but it hangs very quickly when panel is probed
ruleh has quit [Quit: Client closed]
<Wizzup>
same for 5.8.y (stable), it's not particularly useful for debugging where the off mode regression happened between 5.7 and 5.9
<Wizzup>
ok, with a specific method I can still hit ~42mW (same as 5.7)
<sicelo>
this is without any modules load? (42mW)
<Wizzup>
yes
<Wizzup>
so whatever caused off mode to never be hit was introduced between 5.8 and 5.9 I think
<sicelo>
you couldn't hit OFF with anything >5.9 ?
<Wizzup>
right, not without changing parts of the kernel
<Wizzup>
I am going to try 5.9.y again just to verify
<Wizzup>
probably best to start at bottom and read up
<Wizzup>
I could really use some help if you have spare cycles btw
<sicelo>
not yet :-(
<sicelo>
in a week or two i might finally begin to have some time
<Wizzup>
in any case the off mode idling is not stable in 5.8 (seems serial related)
<Wizzup>
but that is a separate problem
<Wizzup>
tmlind: right so I can confirm the OFF mode no longer being hit is introduced between 5.8 and 5.9
<uvos>
since off mode not being hit on 5.9+ is simply because sched is to buisy to find the time, maybe whatever is increasing the events also caused the slight power increase d4 has seen since about 5.8 too
<Wizzup>
could be, let's see if I can find it
<Wizzup>
there's a bunch of clock rework in git log v5.8..v5.9
<Wizzup>
or rather I looked at git log v5.8..v5.9 arch/arm/mach-omap*
<uvos>
that might not be wide enough something could have very well changed in the scheduler
<Wizzup>
I will do a bisect, so that won't matter
<uvos>
oh i thought you ment you only want to biscect arch/arm/match-omap
<Wizzup>
nah just looking at the log
<uvos>
thats an option
<uvos>
ok
<Wizzup>
unfortunately on plain v5.9 my idle script doesn't work