LjL has quit [Read error: Connection reset by peer]
LjL has joined #maemo-leste
jrayhawk has quit [Quit: Lost terminal]
jrayhawk has joined #maemo-leste
joerg has quit [Ping timeout: 252 seconds]
joerg has joined #maemo-leste
macros_ has quit [Ping timeout: 246 seconds]
macros_ has joined #maemo-leste
<freemangordon>
uvos__:
<freemangordon>
export OFONO_AT_DEBUG=1
<freemangordon>
export OFONO_QMI_DEBUG=1
<freemangordon>
and pass -d to ofonod
<freemangordon>
via /etc/default/ofono, for example
<freemangordon>
I am adding those env vars to the init script usualluy
mardy has joined #maemo-leste
<freemangordon>
uvos__: mce on fremantle also does not control kbd brightness besides on/off, goingt o check what android does
<freemangordon>
yeah, android keeps it on 255
<freemangordon>
so, I think we shall put some defaults, like, unless on sunlight, keep it on. maybe start from 128 for complete darkness and switch to 255 for anything between 50 and 250(made up values). maybe calculate based on als readings, dunno
<freemangordon>
power savings are not really something we shall consider (on n900 led current is 5 mA per led, IIUC)
rafael2k has joined #maemo-leste
<uvos__>
i think thats way to bright
<uvos__>
i changed android to reduce the brighness there too
xmn has quit [Quit: ZZZzzz…]
<freemangordon>
uvos__: the point is that defaults should allow everybody to use their devices. being too bright might be inconvenient, but does not stop you from using the device. being too dim stops you.
<freemangordon>
as I said, a RL example - my device seems to be used a lot, so kbd buttons got glossy because of the usage
<freemangordon>
on indirect light they are unreadable
<freemangordon>
without bright backloght that is
<freemangordon>
*backlight
<uvos__>
fine
<uvos__>
its not worth arguing about
<uvos__>
change mce.ini to whatever you like in the repo
<uvos__>
and ill change it back locally
<freemangordon>
I will do some measurements/tests and will do a PR
xmn has joined #maemo-leste
<freemangordon>
uvos__: what about if I add one more slider in display cpl applet for kbd brightness?
<freemangordon>
so noone to be forced to edit ini files to chagne the broghtness?
dev has left #maemo-leste [Disconnected: closed]
dev has joined #maemo-leste
xmn has quit [Ping timeout: 250 seconds]
<uvos__>
sure
<uvos__>
but the problem is that the tables themselves need to be in mce.ini
<freemangordon>
ok, will do
<uvos__>
becasue they are a device dependant thing
<uvos__>
so maybe add low med high profiles
<freemangordon>
yes, I'll control a multiplier
<uvos__>
that the user can coose from
<uvos__>
or so
<freemangordon>
from .5 to 1.0
<freemangordon>
so if initial (for darkness) is 160 and you select the lowest setting, you'll get your 80
<freemangordon>
the same for 255, it will become 127/8
<freemangordon>
5 steps
<uvos__>
ok
<uvos__>
watch out for the 1 bit brightness tho
<uvos__>
that cant become 0
<freemangordon>
you mean touch buttons?
<uvos__>
yeah
<freemangordon>
why it can't?
<uvos__>
setting the multiplier to 0.5 would make those allays be off
<uvos__>
becasue 1*0.5 = 0.5 floored is 0
<freemangordon>
I am not going to recalculate
<freemangordon>
or rather - if kbd is not zero, then ts is 1
<freemangordon>
or will not touch at all
<uvos__>
i dont follow
<freemangordon>
ts buttons brightness can be 0 or 1
<uvos__>
yes
<uvos__>
and seting the multiplier to 0,9 should not make it 0 all the time
<uvos__>
thats all
<uvos__>
how you do that i dont care
<freemangordon>
if keyboard brightness is zero, then ts brightness must be 1
<freemangordon>
otherwise it is 0
<freemangordon>
so we tie kbd with ts
<uvos__>
f keyboard brightness is zero, then ts brightness must be 1 ??
<freemangordon>
unless I am missing some usecase where ts shall be one but kbd 0
<uvos__>
well slider closed
<freemangordon>
oh, sorry:
<freemangordon>
if keyboard brightness is zero, then ts brightness must be 0
<freemangordon>
yeah, I'll consider slider
<freemangordon>
I think it is already considered
<uvos__>
the problem is sutch logic is hard to do consistantly
<uvos__>
because button backlight can have any nummber of lights configured
<uvos__>
and other devices also have on lights etc
<freemangordon>
hmm, right
<freemangordon>
ok, I'll keep the tables and will just apply multiplier
<freemangordon>
to the kbd backlight
<freemangordon>
ok?
<uvos__>
sure
<freemangordon>
ok
<uvos__>
also yes slider is ofc considerd
<uvos__>
see mce.ini.d/70-droid.ini
<uvos__>
for what button-backlght can consider
<freemangordon>
mhm
<uvos__>
btw the is keyboard proparty is only used to implment the legacy dbus interfce
<uvos__>
that allows mce clients to query mce if the button backlight is lit
<freemangordon>
ok
<uvos__>
in freemantle there is only one, when i redid this to be configurabel and support multiple lights i had to assign some light to check
<uvos__>
try and not use this for anything else
<freemangordon>
I will only apply multiplier to kbd backlight values
<freemangordon>
unless I see anything else that needs to be changed, but for now I don;t
sunshavi_ has quit [Remote host closed the connection]
sunshavi_ has joined #maemo-leste
<freemangordon>
uvos__: how to convert in_illuminance_input to mlux? multiply by 2000?
ceene has joined #maemo-leste
<uvos__>
in_illuminance_input schal be mlux according to kernel documentation
<uvos__>
however
<uvos__>
it isent on any device we use :(
<freemangordon>
great :(
<uvos__>
so there is a proparty in the device depedant mce.ini file that tells us a conversion factor
<uvos__>
that i mesured for all the devices we have
<freemangordon>
ah, thanks
<freemangordon>
and what is in_illuminance_scale?
<uvos__>
right so scale*intput should be mlux i think
<uvos__>
maybe read kernel documentation again
<freemangordon>
ok
<uvos__>
but iio-sensor-proxy uses scale for us
<uvos__>
look at iio-als.c
<freemangordon>
ok
<freemangordon>
have to run now, will do later
<freemangordon>
bbl
<rafael2k>
webrtc in chromium works, with jitsi... it takes some time to enter the room, but at least for voice - it work!
<freemangordon>
will end up in cellulard where it will be translated to ofofno
<freemangordon>
*ofono
<freemangordon>
everything else uses stuff like connui_cell_sim_status_register()
<freemangordon>
so it does not care how it works
<freemangordon>
we agreed that modem control will be in cellulard, so I think it makes sense cellulard to provide the information on the current status
<freemangordon>
as it anyway registers
Pali has joined #maemo-leste
<freemangordon>
we may extend or rename nokia dbus interfaces ofc
<Wizzup>
I understand, but why would we want to reimplement the interface just for this lib
<Wizzup>
that's what I meant mostly
<Wizzup>
is there a benefit outside of this one package?
<freemangordon>
this lib is used all over the place
<freemangordon>
everybody uses it - pin query, cpl applet, etc
<Wizzup>
sure, but are you saying there is no way to make the lib work with another (ofono) iface?
<Wizzup>
I know, I did most of the buggy ofono porting :)
<freemangordon>
sure it can, but I think it will be way harder
<freemangordon>
also, you know that libgofono is asyn c
Guest224 has quit [Quit: Client closed]
<Wizzup>
so cellulard's job would be to block on the dbus call and return when it's ready where it will wait for ofono?
<freemangordon>
exactly
<Wizzup>
yes, but we don't have to use libgofon
<freemangordon>
but, cellulard will wait for ofono
<Wizzup>
we could just issue async call and block on the reply
<Wizzup>
with normal ofono dbus
<Wizzup>
block -waiting- for the reply
<freemangordon>
but wahy, given that we already do lots of stuff in cellulard?
<freemangordon>
*why
<Wizzup>
to me it just seems a bit awkward to support an old iface nothing else will use, we won't share with others, to get connui-cellular to work sensibly
<Wizzup>
I mean we do own all the code, we can even rewrite the usage of the lib if we really want to
<Wizzup>
not saying we should, but just saying that -maybe- there's paths that don't require this custom iface
<Wizzup>
I don't have a particularly strong opinion either way
<freemangordon>
I think this lib is not the only user of those interfaces
<Wizzup>
but you might find you have to implement a lot of the ofono iface
<Wizzup>
well, we haven't found many others, and if we did, we planned to port them to ofono
<freemangordon>
yes, but that way we tie to ofono
<Wizzup>
instead of tieing to some nih? :D
<freemangordon>
and if we decide to move to mm, then we'll have to rewrite them all
<freemangordon>
mo, MM
<freemangordon>
*no
<freemangordon>
if we stay with nokia interfaces we'll have to rewrite only cellulard
<Wizzup>
what about icd2?
<freemangordon>
what about it?
<Wizzup>
for MM
<freemangordon>
it will have libicd-mm
<freemangordon>
just another plugin
<Wizzup>
ok, fine, I guess it makes some sense since some UI parts depend on it
<Wizzup>
it just seems like potentially a lot of work
<Wizzup>
i.e. you have to expose a lot of the ofono interface
<Wizzup>
which feels redundant
<freemangordon>
no, why expose ofono? you meant expose nokia interfaces?
<Wizzup>
I mean you have to port over most of the ofono interface
<Wizzup>
like will you port com.nokia.csd.Call ?
<Wizzup>
and com.nokia.phone.SSC ?
<freemangordon>
yes
<Wizzup>
com.nokia.phone.SIM
<freemangordon>
yes
<Wizzup>
and they're also underdocumented, whereas ofono is
<Wizzup>
also wrt introspection
<freemangordon>
hmm...
<Wizzup>
so then we have multiple interfaces to calls?
<Wizzup>
I mean again, it's doable
<Wizzup>
it just means a big shift imho
<freemangordon>
oh. ok :)
<Wizzup>
it won't be an easy task to expose an iface the size of ofono
<Wizzup>
and we were very actively avoiding for a long time
<Wizzup>
at least I was
<freemangordon>
but still, if I am to do the settings thingie, to me it seems I will have to start from scratch
<freemangordon>
ok, agree
<Wizzup>
I think a lot of the research I did on what parts to map to what is sorted already
<freemangordon>
sure
<Wizzup>
but yes the slinging around of data is a problem
<Wizzup>
but I spend more time understanding the lib and figuring out what ifaces to implement where
<freemangordon>
but you leave lots of fixmes and todos so I think it will be faster if I just start from scratch lookiong at your code for reference
<Wizzup>
one of the main problems for me was libgofono and how it works, and how it relied on the glib main loop to return at some point, which can muck with the flow of other programs
<Wizzup>
sure, if you plan to not go the cellulard way
<freemangordon>
yes, that's what I will have to avoid
<freemangordon>
so, you say it is better to not use libgofono and call dbus directly?
<Wizzup>
I think it will give more flexibility
<freemangordon>
ok
<Wizzup>
even though it's probably not fun to write
<freemangordon>
well, I have no issues with dbus
<Wizzup>
I'd like to leave it to you to decide if you want to go the cellulard route or this route
<freemangordon>
I think I already agreed to not go cellulard route
<Wizzup>
the current state wiht libgofono does work for status, home, cpa and pin
<Wizzup>
but the cpa has issues still
<Wizzup>
ok
<Wizzup>
when I wrote it there were also a lot more ofono issues, that I might have tried to work around
<Wizzup>
but I agree libgofono probably is not the way here
<freemangordon>
mhm
<freemangordon>
we need blocking calls
<freemangordon>
at least initially
<freemangordon>
we may reconsider at some point
<Wizzup>
right
<freemangordon>
though, I will check again if we can use libgofono now I have way better understanding of ofono etc
<Wizzup>
ok
Langoor has quit [Ping timeout: 268 seconds]
<rafael2k>
Guest224: and that was a quick-and-dirty conversion from YUYV422 to jpeg... could be better!
<rafael2k>
Wizzup: when you have a couple of minutes, could you please take a look in the ringtones package?
<uvos__>
i tried to use libofono for sphone
<rafael2k>
maemo-ringtones-mr0 has /usr/share/sounds/NokiaTune.aac but not /usr/share/sounds/Nokia_tune.aac, as expected
<uvos__>
it was more trouble than it was worth and very limiting
<uvos__>
vs just using the dbus interface by hand
<uvos__>
the dbus interface is pretty good imo
<rafael2k>
afaics, libgofono has no USSD too
<rafael2k>
lemme know if anyone can take a look in the ringtone package, otherwise I could just edit the package by hand... as I did before (and not it is broken again)
<rafael2k>
Maemo is with broken ringtone for now
Langoor has joined #maemo-leste
<sicelo>
guess you just need to make appropriate adjustment in rules file and make an MR
<rafael2k>
do you know where is the source of this package?
alex1216 has quit [Ping timeout: 244 seconds]
<Wizzup>
there is no source we just import it as is from nokia
<Wizzup>
that way we also don't have the tunes on our gh
<rafael2k>
ok, so I dunno what to do, but something is wrong
<rafael2k>
sphone looks for /usr/share/sounds/Nokia_tune.aac
<rafael2k>
but the package has /usr/share/sounds/NokiaTune.aac
<rafael2k>
I can explode the package and change the path, no problem, but lets decide how to fix...
<rafael2k>
who is right?
<Wizzup>
sphone is probably wrong
<Wizzup>
but I can't look deep atm, sry
<Wizzup>
I have to meet someone
<Wizzup>
either that or the thing that selects ringtones
<rafael2k>
so
<rafael2k>
nothing to do with sphone
<rafael2k>
/etc/profiled/99.custom.ini and /etc/profiled/90.nokia.ini have confliting information
<Wizzup>
not sure,bbl
<Wizzup>
ah
<rafael2k>
this package ringtones added this /etc/profiled/99.custom.ini
<rafael2k>
which does not follow the /etc/profiled/90.nokia.ini conventions
<rafael2k>
my ringtone package did not had this .ini, and followed the already in place convention
<rafael2k>
you know better about Maemo intrinsics... please advice
ceene has quit [Ping timeout: 265 seconds]
<rafael2k>
or profile-data or maemo-ringtones-mr0 needs to be fixed
<rafael2k>
IMHO, this 99.custom.ini should be removed, as it points to files that it not even carry (in the package), as im.alert.tone = /usr/share/sounds/chat-msg_in_bg.wav
alex1216 has joined #maemo-leste
<rafael2k>
and profile-data have the paths fixed to match the paths in maemo-ringtones-mr0
<rafael2k>
or just concentrate the fixes in maemo-ringtones-mr0
<rafael2k>
the /etc/ringtones does not seem right too
<rafael2k>
(in maemo-ringtones-mr0)
<rafael2k>
unless you could copy all the correct files from a N900, which would be cool indeed, and we could make a proper package
<rafael2k>
: )
<rafael2k>
cp /usr/share/sounds and /home/user/MyDocs/.sounds/Ringtones
<rafael2k>
I can do the package
uvos__ has quit [Ping timeout: 248 seconds]
ceene has joined #maemo-leste
xmn has joined #maemo-leste
norayr has quit [Quit: Gateway shutdown]
dev has quit [Quit: Gateway shutdown]
norayr has joined #maemo-leste
norayr has quit [Client Quit]
pere has quit [Ping timeout: 268 seconds]
pere has joined #maemo-leste
uvos__ has joined #maemo-leste
ceene has quit [Ping timeout: 248 seconds]
xmn has quit [Ping timeout: 244 seconds]
xmn has joined #maemo-leste
<freemangordon>
Wizzup: we do not want to support simlock, right?
<uvos__>
as in phone dosent work without sim?
<uvos__>
(unlocked)
pere has quit [Ping timeout: 265 seconds]
<freemangordon>
no, as this phone is locked to a provider and cannot work with other SIM cards
<freemangordon>
I don't see ofono supporting that anyways
xmn has quit [Ping timeout: 265 seconds]
dev has joined #maemo-leste
dev has quit [Client Quit]
norayr has joined #maemo-leste
norayr has left #maemo-leste [#maemo-leste]
norayr has joined #maemo-leste
uvos__ has quit [Remote host closed the connection]
Danct12 has quit [Remote host closed the connection]
dev has joined #maemo-leste
rafael2k has quit [Ping timeout: 265 seconds]
xmn has joined #maemo-leste
pere has joined #maemo-leste
alex1216 has quit [Quit: WeeChat 2.3]
branon has quit [Remote host closed the connection]
branon has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
pere has quit [Ping timeout: 246 seconds]
branon has quit [Read error: Connection reset by peer]
<norayr>
rafael2k, i know the issue with your pp kbd
uvos has joined #maemo-leste
<uvos>
what is there even to support?
<uvos>
the modem will just refuse to use the sim
<buZz>
freemangordon: i think thats usually locked in the baseband? so ofono shouldnt even need support
<buZz>
^ indeed
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
branon has joined #maemo-leste
pere has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
Danct12 has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]
dev has joined #maemo-leste
akossh has joined #maemo-leste
dev has left #maemo-leste [Disconnected: Replaced by new connection]