TonyStone has quit [Remote host closed the connection]
TonyStone has joined #maemo-leste
uvos has quit [Ping timeout: 256 seconds]
Pali has quit [Ping timeout: 256 seconds]
joerg has quit [Ping timeout: 240 seconds]
joerg has joined #maemo-leste
macros_ has joined #maemo-leste
macros__ has quit [Ping timeout: 250 seconds]
mardy has joined #maemo-leste
<tmlind>
uvos: heh having hard time finding a droid4 los image to dump more gnss MPDTIME examples :) seems it's been years since i last downloaded los
<tmlind>
there should be los 14.1 site with the last set of nightly builds, maybe it was stargo's site on some german server? i think it had some experimental opengapps images as well
<freemangordon>
the condition on 544 can never be true
<freemangordon>
also, what is the point of checking longpress timeout in key release at all?
<freemangordon>
isn't that triggered on timeout? like you press-and-hold and 1.5s later whatever the action connected to that happens?
elastic_1 has joined #maemo-leste
elastic_1 has quit [Client Quit]
<freemangordon>
also, I think the issue with power menu appearing on double-press is that there is a flaw in the logic - shortpress action must not be executed immediately on key release, rather a 200-300 ms timer shall be started and upon its expiration the action shall be executed
elastic_1 has joined #maemo-leste
<freemangordon>
you can never detect double-press correctly otherwise
<freemangordon>
uvos: ^^^
elastic_dog has quit [Ping timeout: 268 seconds]
<freemangordon>
ah, you synthesize an event, thats why the check in release
<freemangordon>
still, double-check is not needed
uvos has joined #maemo-leste
<uvos>
as per the original code sortpress action is executed immiatly on release
<uvos>
also a 200ms timer would not help for correctness
<freemangordon>
I implemented that and am about to test
<uvos>
a timer the lengh of doublepress action is needeed
<freemangordon>
no, why?
<uvos>
to determine if its a double press or not
<freemangordon>
we just need to detect double-press on time
<uvos>
you have to let the time expire
<freemangordon>
ok, lemme test it
<uvos>
otherwise you can get both single and double press executing
<uvos>
the reason for the code that executes longpres on release
<freemangordon>
uvos: you implemented mode change check, no?
<uvos>
is that i first coded that with the intention of moving it to ev->value==2
<freemangordon>
that would prevent both single and double press executed
<uvos>
ie use kernel keyrepeat time as long press
<uvos>
(possible mutliple repeats)
<freemangordon>
alsi, I don;t see any issue with long-press
<uvos>
so that mce stalling can not make a short pres long
<uvos>
however the mapphone cpcap input device dosent support repeat atm
<uvos>
an i wanted to investigate that
<uvos>
and then reativate that bit of code
<uvos>
and remove the timer
<uvos>
(depening on behavior on other devices too ofc0
<freemangordon>
having timer is best, as otherwise you depend on repeat interval
<freemangordon>
anyway, lemme see iof my fix actually work
<uvos>
no the timer is really bad
<uvos>
if you set longpress time pretty short
<uvos>
it will often triger erroniously
<uvos>
and we can just wait n repeats
<uvos>
untill the repeat event time is > longpress time
<uvos>
that will give aproximately the right time
<uvos>
without a race
<uvos>
between the kernel event and mce stalling
<freemangordon>
ok, my fix seems to behave correctly
<uvos>
your fix is not a fix
<uvos>
if you just wait 200ms
<uvos>
that only works if your double press is faster than 200ms
<freemangordon>
sure
<freemangordon>
that's the whole point
<uvos>
also i dont like 200ms latency at all
<freemangordon>
my fix is really a fix as it behaves exactly as I wanted
<freemangordon>
I don;t see you having a better solution
<uvos>
thats a really bad standart of correctness
<freemangordon>
the same as "also i dont like 200ms latency at all" without giving a reason
<freemangordon>
if you wish we can discuss what shall be the corect behaviour
<uvos>
well theres two reasons right there
<freemangordon>
but, how is your mouse double-click detected?
<uvos>
1. adding 200ms latency is bad, i use single click to lock so that dealys my lock by 200ms, you can easly notcie it, making the device slower is bad
<freemangordon>
uvos: again, how is mouse double-click detected?
<uvos>
2. adding 200ms latceny is arbirary as the doubleclick timeout is 1s and if the user doubleclicks >200ms and <1s the double action execution returns
<freemangordon>
sure we can make that a parameter
<freemangordon>
so you can make that to 0 for your use-case
<freemangordon>
agree?
<uvos>
i also dont think its great for opening the power menu
<freemangordon>
for use-case where double-click locks the device, such a timeout is needed, otherwise there is an ugly power-menu blink right before the lock
<freemangordon>
ofc 200 ms is arbitrary and is my first test value
<freemangordon>
I guess 150 might work as well
<uvos>
the only correct value is 1s
<freemangordon>
wait, what?
<uvos>
the only correct value is doublepress time
<uvos>
ie 1s by default
<uvos>
ofc this is way to mutch latenct
<uvos>
witch is why nokia and i dident do this
<freemangordon>
we cannot delay power menu for a second
<freemangordon>
so I don;t see why we discuss that
<freemangordon>
if you double-press for a second, well, you'll have power menu popped
<freemangordon>
but it doesn;t make sense to double-press as quickly as you can and have it blinking
<uvos>
the point is the 200ms timer is only userfull
<uvos>
if you doublepress <200ms
<freemangordon>
sure
<uvos>
if you doublepress <200ms
<freemangordon>
agree
<freemangordon>
but usually you do
<freemangordon>
at least me
<uvos>
then yout can set the the doublepresss timeout to <200ms
<uvos>
but i think thas both to fast (for the user to doublpress reliably)
<freemangordon>
how? by manually aditing config file?
<uvos>
and to slow (for the user to wait extra for single press action)
<uvos>
freemangordon: ? by changeing the default and waiting for double press time to execute single press
<freemangordon>
no, sorry, wating 200 ms fo power-menu to appear is not slow
<uvos>
freemangordon: that would at least be correct however the latency argument still exits just the same
<freemangordon>
uvos: ok, so far I see you only saying my patch is not the correct one, but I don;t understand what is the correct fix. *not* for your usecase, but for mine (and leste default behaviour)
<freemangordon>
and again, I will make that a parameter, so you can tweak your already tweaked system to behave exactly like without the fix
<freemangordon>
and you didn't answer my question how is mouse double-click detected
<uvos>
freemangordon: ensureing that only one action is executed is only possible by wating for the timeout of the doublepress timer to see if the user presses again, due to causality
<uvos>
freemangordon: both android power double press and mouse double-click work by the action of single click being required when doublpress is activated
<freemangordon>
and as I already explained that waiting one second for power menu to appear is terrible UX, so not an option
<uvos>
on android this is: from screen off: singe press opens turns on the display and doublepress opens the camera app
<freemangordon>
so, we don;t have a solution, but a workaround
<uvos>
ofc the single press action is a prerequist of opening the camera app
<uvos>
for mouse doubleclick:
<uvos>
single click hilights the folder doubleclick opens it
<uvos>
the actions both execute in double click and are not interfearing
<uvos>
freemangordon: right the default maemo powerkey actions are fundamentaly broken ux
<uvos>
you have to either wait
<uvos>
or blikc the power menu
<uvos>
both are terrible
<uvos>
i asume they dident care
<uvos>
because they expected people to lock the device with the lock slider
<freemangordon>
or, have a workaround that mitigates it as much as possible
<uvos>
or change the actions to be consitant
<uvos>
single press to lock
<uvos>
double to power off for instance are progressive like android, mouse
<freemangordon>
I don;t see how what I say contradicts to that
<freemangordon>
I want my device to behave not like android. period
<uvos>
your workaround is wating
<freemangordon>
and?
<freemangordon>
I am not in a hurry
<uvos>
thats not like android
<uvos>
its progressive
<uvos>
in the action sense
<freemangordon>
by setting this timeout to zero, you will have your behaviour
<uvos>
delaying 200ms is terrible ux
<freemangordon>
ahrg
<uvos>
it makes it feal slow
<uvos>
you can add this feature
<uvos>
and make the default 0ms
<uvos>
thats all ill accept
<freemangordon>
oh, so displaying half-rendered power menu for a split second is better?
<uvos>
yes it is
<freemangordon>
no
<uvos>
its ugly but at least its fast
<uvos>
ie dosent get in the users way
<freemangordon>
ah, so now you are "accepting" mce patches?
<uvos>
yes i am
<freemangordon>
please have a look in git history
<uvos>
so?
<freemangordon>
of mce that is
<freemangordon>
same
<freemangordon>
uvos: the main issue is not that power-menu is being displayed. the main issue is that power menu gets only half-rendered
<freemangordon>
and that is *UGLY*
<freemangordon>
having couple 100-200-300 ms delay on action is way better
<freemangordon>
ot to say I don't really notice any difference between 0 and 200 ms for power menu to appear
<freemangordon>
you already have a delay because of the dbus
<freemangordon>
also, why is double-press timeout 1000ms?
<freemangordon>
and it it the same as medium delay?
<freemangordon>
thats FUBAR, really
<freemangordon>
ah, medioum is for press-and-hold
<freemangordon>
*medium
<Wizzup>
morning
<freemangordon>
morning
<freemangordon>
Wizzup: do you have any clue why double-press timeout in mce is 1s?
<dsc_>
morn
<freemangordon>
hmm, it seems it comes from Nokia
<freemangordon>
that's the default though
<freemangordon>
and it is used
<Wizzup>
freemangordon: not sure why it is 1s, I think we used mce, but one thing to keep in mind is that we probably don't want to delay single press for too long
<freemangordon>
sure
<Wizzup>
I think we used fremantle default*
<freemangordon>
define 'too long'
<Wizzup>
if people do want to use single press for locking, then delaying it adds latency for them
<freemangordon>
agree
<Wizzup>
but I need to fully read backlog and just woke up :)
<freemangordon>
but having a parameter will fix that for them
<freemangordon>
either way they will have to chage the config from default
<freemangordon>
one more thing tho change should not be a big issue
<freemangordon>
hmm, I wonder if we can have "mce behaviour" packages
<freemangordon>
like "maemo", "android", "whatever"
<Wizzup>
I think that can just be a config file
<freemangordon>
umm, it is already, no? mce.ini
<Wizzup>
there is mce.ini.d
<Wizzup>
where you can place files
<freemangordon>
yeah, this is what I meant
<Wizzup>
ok
<freemangordon>
but, to have a packages that install stuff there to change the behaviour from default
<Wizzup>
in any case, your fix is to delay power key menu showing while doing locking transition, and uvos wants power menu to not block, right? I think having a configurable timer for this not too bad if we can't think of another way to fix it
<Wizzup>
I do agree that if the users want to lock then showing the power key menu before locking is silly and weird ux, but delaying single press to lock is also not ok - but it seems this can be solved with an extra option
<freemangordon>
:nod:
<Wizzup>
uvos: it seems to me if our current default is to have power key menu on single press and tklock on double press, having the value be 0 doesn't make that much sense, right?
<Wizzup>
uvos: I mean I lock my device way more often than that I use the powerkey menu (I really only use it to kill apps typically)
<freemangordon>
same here
<Wizzup>
uvos: and yes that argues for making single press the lock, but that's beside the point :P
danielinux_ has quit [Remote host closed the connection]
<Wizzup>
also I believe this would also allow to have powerkey on doublepress, right?
<Wizzup>
if it doesn't enter lock that quickly (200ms) - if the user wants that
<Wizzup>
(or other configured value)
<freemangordon>
also, I think we shall reduse double-press delay to some sane value
<freemangordon>
1000ms does not make sense
<freemangordon>
unless I am missing something
<Wizzup>
some droid4 buttons are kinda poor
<freemangordon>
*reduce
<freemangordon>
yes, but one second?
<freemangordon>
not critical though
danielinux has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
<freemangordon>
hmm, it seems even 100ms is enough
<uvos>
your just making another race
<uvos>
if you delay single press by 100ms
<uvos>
then lock wins over power menu more often
<uvos>
why dont you: 1 figure out what the minimum resonable doubleclick timer is
<uvos>
wait with the signle press action for the doubleclick timer to expire
<uvos>
if and only if
<uvos>
the set single press action and double press action require it
<uvos>
ie delay be doubleclick timer if single action == power menu and double action == lock
<uvos>
or single action == lock double action == power menu
<uvos>
that way single action == lock double action == power menu also works
<freemangordon>
uvos: I was thinking about similar, but honestly, this is even more ugly hack than a delay
<uvos>
at least its correct
<uvos>
behavior wise
<freemangordon>
also, this does not contradicts with having a short press delay
<uvos>
and if the minumum resoable double press time is low
<freemangordon>
*contradict
<uvos>
its not any worse
<freemangordon>
also, Wizzup said we shall keep double-press high because of HW issues
<freemangordon>
I cannot comment on that as I have only one device around
<uvos>
i dont think he is correct
<uvos>
i think the "HW issue" was mce stalling
<uvos>
the time had to be long beacuse of the salls
<uvos>
but dunno ofc
<freemangordon>
otherwise, as I already said, double-press of 1s is way too excessive to me
<freemangordon>
yeah, I think modem stalling the device was the issue
<uvos>
no
<freemangordon>
well, quirks module
<uvos>
mce is vuernable to more stalls than just from modem
<freemangordon>
but, we'll make most of them async, right?
<uvos>
dosent matter
<freemangordon>
hmm
<uvos>
using a timer to detect longpress for instance is fundamentaly broken
<uvos>
as its a race between userspace geting the release event
<uvos>
and the timer expireing
<uvos>
even is release is just 50ms behind press
<freemangordon>
ok, but we don;t really need us precision there anyways
<uvos>
it might still arvie a long time after
<uvos>
its not us precission we are talking here
<freemangordon>
IIUC you fixed that yesterday, no?
<uvos>
not for longpress
<freemangordon>
by checking the evnt times
<uvos>
as there is no keyrepeat
<freemangordon>
ah
<uvos>
its impssible for longpress on d4
<freemangordon>
well, we have no option then
<uvos>
as the powerkey dosent repeat
<freemangordon>
so lets move on
<uvos>
right but thats a bug
<uvos>
in kernel
<freemangordon>
I am not sure I want power button to repeat
<freemangordon>
maybe this is not a bug
<freemangordon>
but made on purpose
<uvos>
no
<uvos>
the volume key also dosent repeat
<uvos>
for the same reason
<freemangordon>
ok, won;t argue on that
<uvos>
and besides ofc you dont want the pwoer key to repeat
<uvos>
you would just be using the events for timeing
<freemangordon>
anyway, ATM we have an issue with broken UX with default maemo behaviour.
<freemangordon>
my patch mitigates that, albeit not being the proper fix
<uvos>
and i think its terrible
<uvos>
at least make a table
<uvos>
of action combinations
<uvos>
and dont even apply it to combinations that are not broken
<freemangordon>
hmm
<uvos>
ie if doublpress = none
<uvos>
never apply
<uvos>
if doublpress = poweroff and short = lokc
<freemangordon>
this should be in mce.ini, right?
<uvos>
dont apply
<uvos>
etc
<uvos>
?
<uvos>
based on whatever the varibales are set in powerkey.c
<uvos>
yes those are loaded from mce.ini(.d)
<freemangordon>
what about PowerKeyShortDelayApply=lock,poweroff;poweroff,lock
<freemangordon>
just an example
<freemangordon>
lets not hardcode, that's my point
<uvos>
sure
<uvos>
but please also handle the case
<uvos>
of short = lock double=powermenu
<uvos>
ie this needs to wait the full delay
<freemangordon>
that's why config option ;)
<uvos>
thats bad tho
<uvos>
it should just work
<uvos>
whatever actions you set
<uvos>
no need to then figure out why this other delay needs to also be set
<freemangordon>
Wizzup: ^^^ any comment
<freemangordon>
also, I am going to change double-press timeout default to some sane value (like 300ms or so)
<uvos>
if you set it to 300ms
<uvos>
please dont have an anditional 200ms timer at all
<freemangordon>
no, we still need it
<uvos>
thats just buggy for an extra 100ms
<freemangordon>
and breaks the ui
<uvos>
why?
<freemangordon>
UX
<freemangordon>
because you see half-rendered power menu for a split second
<uvos>
no if you have doublepress at 300ms
<uvos>
you can wait the full 300ms if your going to wait 200ms anyhow
<uvos>
at that point its bad either way
<uvos>
at least 300ms is correct
<Wizzup>
sorry work mtg atm, I can read backlog
<freemangordon>
ok
<freemangordon>
uvos: with that being a parameter, we can always set to 0 if needed
<freemangordon>
so, lemme write some actual code
<freemangordon>
lets have a discussion again once I have something to test, ok?
<uvos>
please
<uvos>
then add the parameter
<uvos>
comment it out
<uvos>
in mce.ini
<uvos>
and make the default doublepress time
<freemangordon>
for short delay? ok
<uvos>
yeah
<freemangordon>
sure
<freemangordon>
what default double-press time?
<freemangordon>
500ms?
<uvos>
idk try it out
<freemangordon>
ok, I'll try a bit
<freemangordon>
sure
<uvos>
also pease avoid applying it if its not nesscary
<uvos>
ie at least dont if doublpress is disabled
<uvos>
with action=none
<uvos>
but handling other cases would be good to
<freemangordon>
yeah, we'll have only a couple of combos it is enabled for
<freemangordon>
as a config in mce.ini
<uvos>
sure
<freemangordon>
ok, ttyl, when I am ready
danielinux has quit [Remote host closed the connection]
danielinux has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
<Wizzup>
uvos: if you feel like testing, ofono 1.34 in experimental works ok for me (same bugs as before)
<uvos>
its probubly a bad idea to not restart all services
<uvos>
mce for instance has relied on this in past multiple times
<Wizzup>
yeah I don't think we should prevent everything from restarting
<sicelo>
Wizzup: check how devuan does for ssh. at least on my debian system, it doesn't get auto-restarted (i get a prompt to decide instead). i think devuan has same mechanism
<Wizzup>
but I think it might be possible to work on the policy stuff and not restart some daemons
<uvos>
ssh has the capability to resore sessions on restart no?
<Wizzup>
as in I think policy-rc.d gets a initscript as param
<Wizzup>
uvos: no sshd just forks so the existing ones can just live
<Wizzup>
afaik
<uvos>
ok
<uvos>
not sure how it works exactly but restaring sshd causes it to have a new pid but the sessions dont disconnect
<Wizzup>
right they are forked and independent
<uvos>
ok
<Wizzup>
afaik
<Wizzup>
in any case I think we can amend policy-rc.d with specific files to block restarts of say dsme
<Wizzup>
rafael2k: yes, corruption problems are gone
<Wizzup>
(should be)
<tmlind>
freemangordon: updated my d4 this morning, looks like the tearing with marina theme background scrolling in portrait mode is pretty much gone :)
<Wizzup>
I don't believe we have the tearing fix from fmg in kernel yet fyi
<rafael2k>
Wizzup: reaaaaally! Can I edit my xorg.conf and leave it "empty" again?
<Wizzup>
rafael2k: yes
<Wizzup>
rafael2k: please let me know
<rafael2k>
doing it now!
<tmlind>
freemangordon: fyi, i'm still seeing some tiny black ants here and there but rarely with the marina background scrolling in portrait mode test
<rafael2k>
Wizzup: btw, where is the source of the new ofono?
<rafael2k>
freemangordon: with alsa sound is working all good... trouble starts when pulseaudio is on...
<freemangordon>
I see
<freemangordon>
Wizzup: yeah, seems lock/unlock results in "MMU_Alloc: RA_Alloc of VMArena failed"
<freemangordon>
will have a look tomorrow
<rafael2k>
I'll download mobian and see how stuff is working there... if needed we could upgrade some packages
<uvos>
rafael2k: sphone should be built allready
<uvos>
0.5.0 should contain the fix
<rafael2k>
uvos: strange, when I click in any "recent" number, the number does not go to the text field, and when I click dial, it crashes (but the call goes ahead)
<uvos>
rafael2k: hmm
<uvos>
ok ill check it out
<uvos>
freemangordon: please: 1. add tklock,menu to the list, 2. remove DEFAULT_POWER_SHORT_DELAY and make the dault short delay == DEFAULT_POWER_DOUBLE_DELAY
<rafael2k>
tks!
<uvos>
and i would recomment commenting PowerKeyShortDelay=250 out in mce.ini by default
<rafael2k>
uvos: ii sphone:arm64 0.5.0+2m7 arm64 Maemo Leste phone framework and GUI
<uvos>
so that short delay == PowerKeyDoubleDelay
<uvos>
so that tklock,menu can work
<uvos>
otherwise its broken
<uvos>
actually short delay should be = PowerKeyDoubleDelay unless its also set in mce.ini
<uvos>
ie not set set it to the same thing as doubleDelay
<freemangordon>
uvos: 1. it is already in th elist
<freemangordon>
and 2. better keep that separate, you can always make them equal
<uvos>
im not suggesting combining them
<uvos>
im am suggesting that if not set
<uvos>
ie PowerKeyShortDelay is not in mce.ini
<uvos>
it should be set to doubleDelay
<freemangordon>
ok, how is that going to help?
<freemangordon>
elaborate please, I don;t understand the point
<uvos>
tklock,menu is not in the list
<uvos>
you have menu,tklock
<freemangordon>
ah
<uvos>
tklock,menu needs PowerKeyDoubleDelay to be equal to PowerKeyShortDelay
<freemangordon>
but, tklock is not listed as valid for short press
<uvos>
there is not fakinging it
<uvos>
freemangordon: thats wrong
<uvos>
freemangordon: it works fine
<freemangordon>
ok, but not in the comments in mce.ini
<uvos>
sure we can fix the comments too
<freemangordon>
ok, will do that
<uvos>
seting short to tklock has allways worked fine
<uvos>
anyhow
<uvos>
if you set short to tklock
<uvos>
and double to menu
<uvos>
you cant acess the menu unless short delay == double dela
<uvos>
y
<uvos>
faking it with a shorter timeout than double delay dosent work in this case
<freemangordon>
ok, but does this work now?
<freemangordon>
like - without that patch
<uvos>
it dosent setting tklok to single works
<uvos>
but having double as menu at the same time dose not
<uvos>
you can put power there
<uvos>
but not menu
<uvos>
anyhow thats what this is supposed to fix too
<uvos>
so the thing is with the seperate timeout
<uvos>
thats fine
_inky has quit [Ping timeout: 256 seconds]
<uvos>
but the default of the single timeout should be double delay
<uvos>
so that the whole thing works in any combination of actions
<freemangordon>
ok, I'll add to the list, but will keep PowerKeyShortDelay=250 enabled, with a comment to make it equal to long delay if you want tklock,menu combo
<uvos>
double not long
<freemangordon>
yeah, double
<uvos>
i dont think PowerKeyShortDelay=250 is usefull really
<uvos>
if double is only 100ms more
<freemangordon>
it is
<uvos>
it makes it sill slightly buggy
<freemangordon>
at least on d4
<uvos>
since there is a 100ms window
<freemangordon>
no, makes all the difference
<freemangordon>
ofc those are preliminary values
<Wizzup>
nice to see this get fixed
<freemangordon>
if you test and suggest better ones, I am fine
<uvos>
anyhow the default should be double delay
<uvos>
default as in what happens when its not set in mce.ini
<uvos>
since thats the safe valuie
<uvos>
that allways will work
<freemangordon>
I understand your point, but even that works fine
inky has quit [Ping timeout: 240 seconds]
<freemangordon>
and I don;t wan't to delay single action for too long
<freemangordon>
ok, lets see how it will behave with those values
<freemangordon>
will gather some user feedback
<freemangordon>
and can change/tweak later
<freemangordon>
it is about config, no?
<uvos>
no
<uvos>
you can have PowerKeyShortDelay=250
<uvos>
but PowerKeyShortDelay _is not set at all_
<freemangordon>
hmm?
<freemangordon>
sorry, can't parse
<uvos>
it should default to reading double
<freemangordon>
ok, will do that change
<uvos>
righ
<uvos>
good
<uvos>
that way
<Wizzup>
thanks guys
<uvos>
you can have people just comment it out
<freemangordon>
yeah
<uvos>
if they use an action where they need to be the same
<Wizzup>
[ ok ] Restarting Bluetooth DUN daemon: dundee.
<Wizzup>
invoke-rc.d: policy-rc.d denied execution of restart.
<Wizzup>
rafael2k: we knew what the problem was kinda (egl buffer preserved not supported), enunes gave us a hack to add it to mesa, and we need to fix clutter to use buffer age later on, but meanwhile his hack works
<Wizzup>
rafael2k: we will also file a bug support to get egl buffer preserved added to mesa
<uvos>
but that should be 2 policy files, one for ofono and one for dsme
<uvos>
but you probubly know that
<Wizzup>
uvos: not sure what you mean, but debian only wants this one file, so I'd have to write that in python
<uvos>
hmm ok
<Wizzup>
uvos: we can also have this in leste-config
<uvos>
policy-rc.d trew me off
<Wizzup>
maybe it supports it as a file too, not sure
<Wizzup>
yeah I can double-check how it works
<uvos>
really it should be packaged with the deamon
<uvos>
if at all possible
<uvos>
the deamon package alone should not be broken
<Wizzup>
I think this is something that is just missing in debian
<Wizzup>
judging by how it works I don't think it supports directories
<uvos>
maybe switch to systemd :P
<Wizzup>
see:
<Wizzup>
The /usr/sbin/policy-rc.d file *must* be managed through the alternatives
<Wizzup>
system (/usr/sbin/update-alternatives) by any packages providing it.
<Wizzup>
ok, bbiab
<Wizzup>
but I think we can add this to leste-config ?
<uvos>
hmm thats mesy/hacky then
<Wizzup>
(maybe we can add a few more svcs)
<Wizzup>
we can also have it only disallow 'restart' and accept 'start'
<Wizzup>
etc
<Wizzup>
bbiab :)
_inky has joined #maemo-leste
reinob has joined #maemo-leste
<Wizzup>
uvos: why is it messy, because other pkgs can't register it?
<Wizzup>
can we think of a few more daemons we probably don't want to restart?
<rafael2k>
Wizzup; cool!! tks a lot! PP usage in Maemo I would say it is really possible now! lets ask some donation to pine64 and a PP maemo version! :P
<Wizzup>
icd2 maybe?
<uvos>
yeah idealy any signle package in leste works by itself
<uvos>
Wizzup: depends
<uvos>
Wizzup: how dose icd2 react to restart
<uvos>
Wizzup: i gues it drops connections?
<Wizzup>
uvos: it's quite fine really, but you will lose connection
<Wizzup>
yeah
<uvos>
im not sure its a big deal, but the reason for not restarting ofono was dropping 3g so for consistancy
<uvos>
idealy ofc icd2 would do something smarter on restart
<Wizzup>
I am not sure if I agree wit that per se wrt smarter, but that doesn't really matter
<Wizzup>
rafael2k: yeah would be good to check out keyboard usage
<sunshavi_>
In my opinion getting hw is very difficult also
<sunshavi_>
So what P64 does is awesome
<sunshavi_>
But some efforts could be coordinated. You guys do it a little bit with PMOS
<uvos>
not really anymore
<sunshavi_>
Also there is no other company like AW. I hope PP-pro which is Rockchip based would give also great access to schematichs
<uvos>
since hildon is impossible to pacakge into a general use distrobution
<uvos>
for various reasons
<Wizzup>
uvos: I think you're conflating generally working together and packaging our sw elsewhere
<uvos>
well that would be the best bit of coperation between distrobutions
<Wizzup>
sunshavi_: well, I think we're doing a pretty good job at trying to mainline things, while we also work on our distro, we don't have manpower for much more, and getting something usable on our current targetted devices to me is more important than all using either ofono or modemmanager or something
<uvos>
otherwise we aslo dont really do mutch with pmos do we
<Wizzup>
uvos: they build on our kernel work for some devices :)
<sunshavi_>
Yes. I saw it. The work You are doing guys
<Wizzup>
and I'm pretty confident hildon will get packaged for it again at some point
<sunshavi_>
probably You are benefing also mesa+lima
<Wizzup>
I think they benefit us more, but yeah :P
<Wizzup>
sure, it's about the interaction & fixing stuff
<sunshavi_>
well. Remember my main machine is an SBC with AW SOC which also happens to has lima mali-400
<sicelo>
sunshavi_: i may as well declare that i've taken up maintainership of N900 on pmOS ;-)
<sunshavi_>
that's good sicelo
<sunshavi_>
more or less a month ago I was experimenting with a tablet an AW a721
<sicelo>
what's AW? ah, allwinner
<sunshavi_>
I wanted it to boot from my combo {uSD-card-adapter-to-emmc}. So I was using an emmc
<sunshavi_>
I did not get it to work. If It would have worked. I think those guys on pmOS they are trying to support it also
<sunshavi_>
It just worked from a plain uSD
<sunshavi_>
But I am going to take to retake it in the future when time permits
<sunshavi_>
sicelo: I saw You were trying to calibrate n900 battery. Have You gotten it?
<sicelo>
sunshavi_: one thing i would like to do is (if i had the device[s]) is - make Leste boot on some of the devices in pmOS community, if not all :-)
<sunshavi_>
that's Cool
<sicelo>
sunshavi_: no, it was the d4. n900 you can calibrate battery with eyes closed since hw takes care of it on its own. and no, it's still uncalibrated. i gave up for the time being
<Wizzup>
sicelo: any clue how you plan to do that?
<sicelo>
do what? :-)
<sunshavi_>
I think calibrate d4 battery. or perhaps leste on pmOS-devices?
<sicelo>
if you mean boot pmOS community devices with leste, i'd like to think it's going to be quite straightforward really. only terrible thing will be the power mgmt issues
pere has joined #maemo-leste
<sicelo>
as for calibrating d4, i really don't know. i was thinking to look at estimating capacity using voltage. iirc pavel does something like that in his unicsy_demo
<uvos>
upower dose this allready
<sunshavi_>
pmOs is better at power-management than maemo-leste?
<uvos>
we just dont display it (only the bargraph dose show this estimation)
<Wizzup>
sicelo: - make Leste boot on some of the devices in pmOS community, if not all :-)
<uvos>
wrt callibration
<sicelo>
sunshavi_: no.
<uvos>
i have no problem callibrating
<uvos>
by having the device be empty
<uvos>
booting it
<uvos>
and then charging to full
<Wizzup>
sicelo: I mean, do you plan to package hildon or to use their kernel as base with leste on top?
<sicelo>
Wizzup: ok. the community devices are running mainline. and they all have working 3d... so should be quite easy if one has the device(s)
<uvos>
of you do have a really weak battery
<Wizzup>
sicelo: right, ok
<Wizzup>
sicelo: cool
<uvos>
maybe lower the cutoff voltage for mce, it is quite high. it is so high because you can get into an unbootable situation if the voltage drops to low and the device shuts off before it gets to charge-mode
<uvos>
there is only 100mv room between calibration and mce shuting down
<Wizzup>
makes sense to me
Oksanaa has quit [Ping timeout: 240 seconds]
<sicelo>
uvos: the last time you were saying it won't calibrate because currently droid 4 doesn't do a proper shutdown, but dies. is that still the case?
<uvos>
so there is an oops
<uvos>
yeah
<uvos>
for me it sometimes permanently hangs on shutdown
<uvos>
that would cause callibration to faill to
<uvos>
so yes this is also still a problem
<uvos>
but sometimes this dosent happen
<sicelo>
okay
<uvos>
so yeah various issues
<uvos>
calibration is destined to be very unrelaiable atm
<sicelo>
anyway, i will see if i can run something from unicsy and log some of its output to a file. i know this will increase consumption, but at this point, i want to understand what's the battery status. atm this isn't possible
<uvos>
sicelo: the best way to callibrate manualy
<uvos>
is to charge fullt
<uvos>
*fully
<uvos>
take a note of cat /sys/class/power_supply/battery/charge_counter
<uvos>
and then discharge to almost empty and take another note of cat /sys/class/power_supply/battery/charge_counter
<uvos>
or the other way around
<sicelo>
Yes, that's why i want to log to a file the entire time that the system is running, because shutdown is unreliable due to the oops you refer to. At least this way I'll have some values up to maybe a minute before it dies
<uvos>
sicelo: well just do the reverse then
<uvos>
take a note of the value just after boot when the device boots from empty
<uvos>
and then put it on a charger and forget about it
<uvos>
whenever you come back the difference in values is the capacity
<uvos>
you can then save the value to callibration file in /var
<uvos>
thats it its callibrated
<sicelo>
The reverse is way harder imo, because d4 has its own boot from empty issues. Plus I want to know the discharge characteristics of this replacement battery
<uvos>
no it dosent anymore
<uvos>
mce shuts down early enough that its fine
<uvos>
in all cases
<uvos>
the difference betwee charge and discharge capcaity is goning to be very small
<Wizzup>
so any other services besides ofono and dsme that we can think of?
<uvos>
i dont even really know if i agree with ofono
<uvos>
so no not really :P
<uvos>
sphone has the opsit problem
<uvos>
it desperatly needs to be restarted on upgrade
<uvos>
(and currently is not)
<Wizzup>
right because it doesn't use init scripts (for obvious reasons)
<sicelo>
Why don't you do it in postinst?
<Wizzup>
right dsmetool could do that
<uvos>
dsmetool cant do it to my satisfaction afaik
<uvos>
and postins would not work either since its run as root
<uvos>
i gues i could write something that checks what sphone process is running
<uvos>
and then take a note of its uid/gid
<uvos>
and then kill it and restart it with the same uid/gid
<uvos>
but makeing the env consistant is hard
<uvos>
at least i dont know how of the top of my head
<Wizzup>
uvos: dsmetool can run as user afaik
<Wizzup>
start as rather
<Wizzup>
but yeah all good, just saying that's how it -could- work
<uvos>
it can start user
<uvos>
i think this is broken
<uvos>
it needs to restart all sphone proceies for all uids its running for
<uvos>
with proper dbus user bus and sutch
<uvos>
*start as user user
<Wizzup>
right
<Wizzup>
btw, why does it need to be restarted upon update?
<uvos>
it comunicates with itself via dbus
<uvos>
the interface is not stable atm
<uvos>
and not versioned either
<Wizzup>
right
<sicelo>
i just thought how nice it would be to have a hildonized matrix client
<sicelo>
mmm, i wonder if telepathy has a matrix plugin
<Wizzup>
yes
<Wizzup>
telepathy-tank
<Wizzup>
please give it a try if you can
<Wizzup>
(in empathy or so)
mrgeanie has joined #maemo-leste
<sicelo>
oh, interesting! i'll have a look
<sicelo>
Wizzup: btw thanks for investigating the wifi issue on n900's wl1251. with that fix, iwd runs beautifully
mrgeanie has quit [Remote host closed the connection]
<humpelstilzchen[>
Is Audio not working on pinephone a known issue?
<humpelstilzchen[>
alsa output works when pulseaudio is stopped, so probably pa issue
<Wizzup>
sicelo: good
<Wizzup>
humpelstilzchen[: I think rafael2k is on it
<uvos>
rafael2k: but i noticed that the default config file is wrong i forgot to load ui-calls-manager-gtk so you cant hangup a call (any call not just recents)
<uvos>
rafael2k: ill fix that soon
<uvos>
rafael2k: in the mean time you can just add the module to your sphone config file