SuperMarioSF has quit [Read error: Connection reset by peer]
SuperMarioSF has joined #maemo-leste
nmdv has joined #maemo-leste
mp107 has quit [Ping timeout: 255 seconds]
nmdv has quit [Remote host closed the connection]
nmdv has joined #maemo-leste
joerg has quit [Ping timeout: 245 seconds]
joerg has joined #maemo-leste
fab_ has joined #maemo-leste
nmdv has quit [Ping timeout: 255 seconds]
Juest has quit [Quit: Client closed]
mp107 has joined #maemo-leste
fab_ has quit [Quit: fab_]
<freemangordon> Wizzup: uvos: actually I don;t think we can use either gconf or gsettings for fmtx
<freemangordon> we don;t want to do that ^^^
<freemangordon> so, I am thinking of configfs maybe?
<freemangordon> umm... not configfs
<freemangordon> what was the name?
maxwelld has quit [Ping timeout: 255 seconds]
antranigv has quit [Ping timeout: 255 seconds]
<freemangordon> ok, seems I got it wrong and there is no kernel fs that can be used as persistent parameters storage
antranigv has joined #maemo-leste
maxwelld has joined #maemo-leste
Juest has joined #maemo-leste
noidea__ has quit [Read error: Connection reset by peer]
noidea__ has joined #maemo-leste
SuperMarioSF has quit [Read error: Connection reset by peer]
SuperMarioSF has joined #maemo-leste
pere has quit [Ping timeout: 240 seconds]
fab_ has joined #maemo-leste
vahag has joined #maemo-leste
vahag has left #maemo-leste [#maemo-leste]
akossh has joined #maemo-leste
<sicelo> besides frequency (and maybe region?), what else needs persistent storage?
xmn has quit [Ping timeout: 248 seconds]
uvos__ has joined #maemo-leste
<uvos__> freemangordon: not sure why this should prevent gsettings, you can check the key like that with dconf too
<uvos__> besides, this seams not so great, would it not be better if the deamon just checked the key on startup and exited sucessfully if its not set?
<uvos__> am i missing something?
pere has joined #maemo-leste
<freemangordon> uvos__: maybe you are right, I will dig further into it
maxwelld has left #maemo-leste [Error from remote client]
uvos__ has quit [Ping timeout: 246 seconds]
uvos__ has joined #maemo-leste
maxwelld has joined #maemo-leste
uvos__ has quit [Read error: Connection reset by peer]
arno11 has joined #maemo-leste
uvos__ has joined #maemo-leste
<arno11> Wizzup: sicelo: new UCM files sent
<Wizzup> ty, will deploy momentarily
<arno11> ok thx
<Wizzup> (I'm excited for this atm)
<Wizzup> s/atm/btw/
<Wizzup> also want to try the IR a bit later this week :)
<arno11> ok cool
uvos has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
arno11_ has joined #maemo-leste
fab_ has quit [Quit: fab_]
Guest2 has joined #maemo-leste
Guest2 has left #maemo-leste [Leaving]
<Wizzup> arno11_: building for -devel
<arno11_> cool
<Wizzup> it's probably already built
<arno11_> ok thx
<arno11_> yes i see it
vahag has joined #maemo-leste
vahag has left #maemo-leste [#maemo-leste]
<sicelo> cool, thanks. quick question though ... why create relationship between fmtx and headphone jack?
<sicelo> or that was to get autoswitching, since pulse already triggers the ucm verb/device according to jack events?
<arno11_> fmtx only works if jack function is set on 'headphone' iirc
<sicelo> yes, that's true (the fm transmitter chip inputs connected to the headphone lines).
<sicelo> but my question is - you mention that one should connect the headphone jack. it should work without inserting it normally
<arno11_> yes of course, just in case you insert something, fmtx must be started after
<arno11_> otherwise ucm switch to headphone sequence
<arno11_> and stop fmtx
neimsaci has quit [Quit: WeeChat 4.0.1]
fab_ has joined #maemo-leste
<arno11_> *switches *stops
<arno11_> brb
<sicelo> i see. i guess that's why something like fmtxd is needed ... so the fmtx session is 'protected' from that kind of thing
pere has quit [Ping timeout: 250 seconds]
pere has joined #maemo-leste
arno11_ has left #maemo-leste [#maemo-leste]
<Wizzup> uvos: the thumb2 support, is that for building kernel to make it use thumb2?
<uvos> yes
<Wizzup> cool
<sicelo> link to the branch? i don't see it for now
<Wizzup> maemo/chimaera-devel
<Wizzup> bbl
<sicelo> yes, but i mean the actual kernel config changes ... maemo/chimaera-devel only contains packaging
<Wizzup> ah, ok, I just looked at the changelog
<sicelo> otherwise thanks uvos for thumb2, and i see charge-mode changes related to the booting at <10%. thanks
<uvos> sicelo: also the charging not being detected on boot on d4 might be fixed, at least i cant repo it right now anymore
The_Niz has quit [Ping timeout: 246 seconds]
xmn has joined #maemo-leste
<uvos> Wizzup: do we have bash installed on leste for sure?
<uvos> why is /bin/sh dash?
<sicelo> isn't that the debian/devuan default?
<bencoh> it is
<uvos> anyhow Wizzup please merge and tag this out: https://github.com/maemo-leste/osso-af-startup/pull/2
<uvos> also the use of runuser here is ugh
<sicelo> mmm, i'm not sure 'source' is a bashism. at least it's there in pmos and used extensively. they don't use bash, but busybox. can check what their /bin/sh is aliased to
<uvos> source istent part of the posix shell
<uvos> and i think it was first introduced by bash
<uvos> but thats not really important
<uvos> point is its not in in sh and not in dash
<sicelo> their /bin/sh is symlink to /bin/busybox
The_Niz has joined #maemo-leste
fab_ has quit [Quit: fab_]
gnarface has quit [Quit: Leaving]
neimsaci has joined #maemo-leste
gnarface has joined #maemo-leste
fab_ has joined #maemo-leste
xes has quit [Read error: Connection reset by peer]
arno11 has joined #maemo-leste
uvos__ has quit [Ping timeout: 250 seconds]
uvos__ has joined #maemo-leste
SuperMarioSF has quit [Read error: Connection reset by peer]
SuperMarioSF has joined #maemo-leste
fab_ has quit [Read error: Connection reset by peer]
fab_ has joined #maemo-leste
<arno11> i know that's an old issue guys but any hope to solve the weird bug with hildon composition? disabling it on the fly speeds up apps a lot (even on pinephone iirc)
<uvos> what wierd bug with composition?
<bencoh> slower rendering, I'd say
<arno11> yes
<uvos> composition is expensive - sure maybe it can be optimized but its not a bug
<bencoh> (although I don't think it's specific to hildon)
<uvos> but composition is just expensive
<arno11> ok that's really too much for N900
<bencoh> I wonder if you could easily try another compositor / compositing wm for comparison
<uvos> kwin should work
<uvos> it has gles support
<uvos> its reaaaaaaly slow on d4
<uvos> so yeah
<bencoh> slower than hildon?
<uvos> much
<uvos> the only fix here would be to make hildon not rely on composition, as its not nessecary for what hildon dose really
<uvos> but this would require major reachitecting
<uvos> so not going to happen
<freemangordon> bencoh: *everything* is slower than hildon
<uvos> well no plain x isent :P
<uvos> or openbox
<bencoh> freemangordon: :D
<uvos> or i3
<bencoh> yeah, wmii is just super fast on d4 ;)
<uvos> sway is also faster than hildon
<uvos> at composition
<uvos> even
<freemangordon> uvos: sorry, I missed the context - why is bash needed in the above PR?
<uvos> freemangordon: so runuser runs as the users shell by default
<uvos> we have a user who uses xonsh (essentally python) as thair shell, so the scripts dont work with that
<freemangordon> omg
<uvos> runuser sources the profile with source
<uvos> wich is not in posix and not implemented by dash (default debain shell)
<uvos> which is not in posix and not implemented by dash (default debain shell)
<uvos> so we need to use bash explicitly
<freemangordon> I see
<freemangordon> ok, lemme merge that
<freemangordon> uvos: shall I release it for -devel?
<uvos> yes, please
<freemangordon> ok
<uvos> also merge master
<uvos> its behind devel
<freemangordon> sure
ahmed_sam has joined #maemo-leste
<freemangordon> done
RedW has quit [Ping timeout: 245 seconds]
xes has joined #maemo-leste
ahmed_sam has quit [Read error: Connection reset by peer]
RedW has joined #maemo-leste
<arno11> freemangordon: any idea why ir_rx51 is causing kernel crashes ?
<arno11> *when we try to send pulse
SuperMarioSF has quit [Read error: Connection reset by peer]
SuperMarioSF has joined #maemo-leste
Daanct12 has quit [Remote host closed the connection]
Danct12 has joined #maemo-leste
maemish_ has joined #maemo-leste
<maxwelld> i am getting floating point exception when running osso-xterm
<maxwelld> i think it happened before as well.
<maxwelld> don't remember how i solved it.
<uvos> backtrace?
<freemangordon> arno11: where is oops?
<arno11> oops happens immediately after sending a pulse, no way to log
parazyd has quit [Ping timeout: 246 seconds]
<freemangordon> why?
<freemangordon> wtym "no way to log"?
<freemangordon> mtdoops?
<arno11> ok i'll try
<arno11> thx
maemish_ has quit [Quit: Connection closed for inactivity]
<Wizzup> arno11: if you tell me how to reproduce I can hook up my serial too late rtonight
<arno11> ok cool and thx. For example you can just run 'ir-ctl -S rc5:0x1e01' to produce the oops
<arno11> (it happens using lirc and pierogi as well)
<arno11> with any command
<Wizzup> lirc I can install with apt?
<Wizzup> and I guess I need to load bt, or?
<sicelo> no, bt isn't needed
<Wizzup> ok
<sicelo> and for the test, ir-ctl is enough. no lirc needed
<Wizzup> as in it will take 1-2 hours before I can do it, so just asking any questions I might otherwise have when you guys are asleep :D
<sicelo> you most likely will already have ir-ctl on the device. it's provided by v4l-utils
<arno11> and the ir driver is already loaded on boot
fab_ has quit [Quit: fab_]
nmdv has joined #maemo-leste
akossh has quit [Quit: Leaving.]
nmdv has quit [Ping timeout: 246 seconds]
parazyd has joined #maemo-leste
elastic_dog has quit [Ping timeout: 260 seconds]
elastic_dog has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
SuperMarioSF_ has joined #maemo-leste
SuperMarioSF has quit [Ping timeout: 246 seconds]
maxwelld has quit [Ping timeout: 244 seconds]
maxwelld has joined #maemo-leste
maxwelld has left #maemo-leste [#maemo-leste]
neimsaci has quit [Quit: WeeChat 4.0.1]