<freemangordon>
uvos: hmm, seems display state pipe is called twice per lock
uvos has joined #maemo-leste
<tmlind>
Wizzup: ok i ended up using the older image last night, upgrade to devel is a pain currently :)
<uvos>
freemangordon: well it should if its on->dim->off (it might allways do that to make sure the state is consistant i dont recall)
<uvos>
it its runing it twice with off as the argument
<uvos>
theres a bug somewhere, but it dosent matter mutch because every callback has to check if the callback isent run twice with the same argument anyhow
<Wizzup>
tmlind: hmm how is it a pain, we should fix that
<uvos>
as that can happen in various circumstances
<tmlind>
Wizzup: mce and hildon-desktop refuse to upgrade, xorg won't restart, apt dist-upgrade needs to be finished in the emergency shell etc
<uvos>
tmlind: i dont have any logs sorry
<uvos>
tmlind: i can try and captue some tomorrow
<tmlind>
uvos: ok no problem, can't get the stock android to install, can't find a sim right now
<tmlind>
uvos: no luck with the corner taps, setting up a new micro-sd card for d4
<tmlind>
uvos: yeah lineageos works fine for capture too, i think you need to set the ts27010 debug level though
meldrian is now known as Frittenfett
_inky has quit [Ping timeout: 240 seconds]
inky has quit [Ping timeout: 240 seconds]
inky has joined #maemo-leste
<tmlind>
uvos: now the corner trap trick worked :) it may need to be done on right away on the first language selection screen, and the top taps may need to be about 2cm lower than the top and multiple rounds
inky_ has joined #maemo-leste
inky has quit [Ping timeout: 240 seconds]
<Wizzup>
tmlind: hmmmm ok, because it reboots somehow during upgrade
rafael2k has quit [Ping timeout: 268 seconds]
inky has joined #maemo-leste
<Wizzup>
freemangordon: looks like the mesa build finished, now we'll still have to set the behaviour in clutter, I'll get my pp online in a bit
inky_ has quit [Ping timeout: 240 seconds]
inky has quit [Remote host closed the connection]
inky_ has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
_inky has joined #maemo-leste
marabej has quit [Ping timeout: 256 seconds]
_inky has quit [Ping timeout: 256 seconds]
<uvos>
Wizzup: lets just disable lifegurad for now, please
inky_ has quit [Ping timeout: 256 seconds]
_inky has joined #maemo-leste
<Wizzup>
freemangordon: what do you think, disable lg until we have fremantle-style system upgrades where it forces a reboot?
<Wizzup>
as in, it prevents you from doing anything but doing the upgade
pere has joined #maemo-leste
<tmlind>
uvos: seems like the stock distro has buggy ts27010 debug, or los has enabled more features, not seeing the at commands with logcat after echo 0x7fffffff > /sys/module/ts27010mux/parameters/debug_level
<uvos>
"fremantle-style system upgrades where it forces a reboot" <- i honestly hate this
<uvos>
and there is no scenario where lg reboot helps anything anyhow
<freemangordon>
Wizzup: this is fine for -devel, but not for -stable IMO
<freemangordon>
uvos: this was already discussed
<uvos>
not really
<uvos>
you just dissmiss it with no argument
<freemangordon>
uvos: I am not going to argue on simple common sense
<Wizzup>
well there should be a sensible way for end users to do system upgrades
<Wizzup>
simple dist-upgrade doesn't seem likely to cut it
<uvos>
freemangordon: bullshit commen sense
<uvos>
Wizzup: you can have lifeguard and apt
<uvos>
Wizzup: just disable it before and reenable it after
<uvos>
no need to reboot or do anything else
<freemangordon>
uvos: so, Xorg crashes, how you;re going to restart if it happens to notice?
<uvos>
if dsme dident exist and hildon was a xdg shell you could just restart it
<uvos>
like any deamon
<uvos>
anyhow
<Wizzup>
keep in mind that what we do now doesn't have to be what we do ~3 months from now
<Wizzup>
if it's a real problem to upgrade for many people that's something of concern and more pressing than what we do later imho
<uvos>
so lifeguard's usefullness:
<uvos>
ok lets pick a random deamon
<freemangordon>
Wizzup: what about having no lg revoots for -devel only?
<uvos>
freemangordon: it breaks all the time on stable too
<freemangordon>
do we know why?
<uvos>
yes random deamon fails (different one eatch time)
<uvos>
so please listen for a second
<freemangordon>
how's that?
<uvos>
bugs in deamons
<freemangordon>
and we push those to -stable?
<uvos>
they fail in untested configurations
<uvos>
so yes
<uvos>
we cant test everything
<freemangordon>
mhm
<uvos>
so lifeguard's usefullness:
<freemangordon>
well, lets disable WDs then, why not
<freemangordon>
we can;t test kernel as well
<uvos>
its different
<uvos>
please just listen for a while
<freemangordon>
sorry, I am out of this conversation
<uvos>
see
<freemangordon>
I don't find it useful
<uvos>
this is how we "discuss" this
<Wizzup>
freemangordon: I think enunes patch fixes the problem if we also request the bit on clutter
<freemangordon>
saying "because we cannot code our daemons to be stable enough to not crash on restart, lets remove lg once and for all" is not something I am going to discuss
<uvos>
freemangordon: thats not what im saying
<uvos>
at all
<Wizzup>
freemangordon: wrt daemons it's a matter of prioritising
<uvos>
the problem is that lifeguard dosent help
<uvos>
it hurts
<Wizzup>
we can turn on lg later again, currently it's more of a problem than that it helps
<freemangordon>
sure, if we hit reboot loop
<uvos>
there is no scenario where it helps at all
<uvos>
ever
<freemangordon>
which means it is useless
<freemangordon>
which means it shall be removed
<uvos>
its worse thatn useless as it hurts
<uvos>
except where there are defficancys that make it impossible to restart deamons without restart
<uvos>
liek x
<uvos>
but this is just because of architecture problems
<uvos>
and we should fix unrestartable deamons
<uvos>
to be restartable
<freemangordon>
there are only several daemons that lead to system restart
<uvos>
quite a few do really
<freemangordon>
less than 10
<uvos>
thats quite a few
<uvos>
and again it dosent help anything for these 10
<uvos>
so lets go though an example
<freemangordon>
so, what do you do if something in /tmp gets messy? DBUS address, for example
<freemangordon>
no daemon restart will fix it
<freemangordon>
you need to reboot the whole device
<uvos>
deamon restart absoluly should clear the dbus addresses
<freemangordon>
not really, becouse half of the system will use the old address
<freemangordon>
or, you want all the daemos to crahs and restart instead of doing a clean reboot?
<Wizzup>
I think we're disregarding the more practical problem(s)
<uvos>
yes ofc
<freemangordon>
uvos: this might mae sense on server
<freemangordon>
*make
<freemangordon>
not on mobile
<uvos>
freemangordon: please let me explain for a second
<freemangordon>
ok
<uvos>
so lets say we have a deamon with a bug
<uvos>
maybe mis (dosent matter what deamon)
<uvos>
it derefrences a nullpointer when you use it
<humpelstilzchen[>
I wonder what your current target audience is - enduser or developer
<uvos>
so it chrashes
<uvos>
and dsme restarts it
<freemangordon>
humpelstilzchen[: thats the issue,actually ;)
<Wizzup>
freemangordon: btw, did you see my msg? pinephone problem seems fixed
<freemangordon>
Wizzup: yes, but lets finish with lg first
<uvos>
this is "fine" as lg will never reboot as the crashes are slow but we should give the user some indication on the problem as rn it will look like everything wokrs and this is imo worse than informing the user that something is wrong by the deamons features being missing
<uvos>
but ok
<uvos>
no lg reboot needed
<uvos>
now we have another bug, here it crashes right at startup if config option xyz is set
<uvos>
we dont set xyz so we dident notice
<uvos>
our user now has a deamon that allways crashes on startup
<uvos>
what happens? device reboots deamon crashes again device reboot deamon crahses again
<uvos>
the user cant use the device (even thoug the deamon might not be _absolutly_ critcal (maybe for emergency call at least))
<uvos>
and even worse
<uvos>
the user cant give us the logs
<freemangordon>
uvos: it is as simple as:"we shall not push system critical daemons in -stable that are prone to such breakages"
<uvos>
without pluging in the sdcard (which is only possible if leste is on an sdcard)
<freemangordon>
also, lg is an option
<uvos>
turning off lg in a boot loop is impossible
<freemangordon>
not every daemon under dsme is set todo it
<uvos>
to point is that if a deamon is cosntantly crashing and restarting
<uvos>
a reboot is very unlikley to fix it
<freemangordon>
see, it is mce, Xorg, h-d and few others that lead to l-g reboot
<Wizzup>
ke-recv as well
<freemangordon>
yeah
<Wizzup>
and a few more iirc
<uvos>
and a boot loop makes it impossibe to debug or give us info
<Wizzup>
status applets, hildon-home
<Wizzup>
icd2 too
<uvos>
mce is not vital
<uvos>
you can use the phone without mce
<freemangordon>
ok, if we think those daemons shall not cause lg reboot, lets assess them one by one
<uvos>
and call emergancy
<Wizzup>
uvos: I disagree with you there but I do think we should not reset now if mce crashes many times
<uvos>
mce causing a reboot is detrimental
<Wizzup>
but in practice it probably means you cannot unlock your phone :)
<freemangordon>
mhm
<Wizzup>
freemangordon: the debian upgrade process also messes with these states and daemons
<uvos>
the problem is that the likely hood of a reboot solveing anything is mutch mutch lower than a bootloop
<uvos>
what lg could do
<uvos>
is reboot _once_
<uvos>
and then never again untill the deamon in question starts correctly
<uvos>
that would be fine
<uvos>
and hildon needs to become an xdg session
<freemangordon>
again, if we think some daemons shall not cause lg reboot, lets just remove that freom their startup
<uvos>
so x can bre restarted
<uvos>
thats just a travisty atm
<freemangordon>
uvos: we don;t really need such thing on mobile
<uvos>
yes you do
<uvos>
for recovery
<uvos>
x crahing need to cause a reboot and causing a reboot makes it hard to debug
<uvos>
so dont do it
<uvos>
and xdg session has many other advantages too
<freemangordon>
ok, how hard is to go through the daemons and remove 'lg reboot' option from dsme startup line?
<uvos>
x crahing need not
<uvos>
freemangordon: not very
<uvos>
but thats hardly the point
<uvos>
its enabled by default atm
<freemangordon>
wrong
<uvos>
and if you mean during a boot loop
<uvos>
then its very hard
<freemangordon>
it is explicitly enabled by dsme command line for a particular daemon
<uvos>
that is default
<uvos>
for the user
<freemangordon>
also, I am using fremantle for the last 11 years - never hit a reboot look because mce is buggy or Xorg crashed or whatever
<freemangordon>
*loop
<uvos>
because nokia threw the thing over the wall
<uvos>
and it only runs on one device
<uvos>
it has mutch less variables
<freemangordon>
how that matters?
<freemangordon>
ah
<uvos>
and ofc we cant possibley do as mutch qc as nokia
<uvos>
for eeatch device
<uvos>
as they did for n900
<freemangordon>
anyway, I am agains removing lg reboot
<uvos>
its just not realistic
<freemangordon>
*agains
<freemangordon>
t
<freemangordon>
so, we can temporarily put no_lg_reboots until we think we have stable enough system
<freemangordon>
Wizzup: ^^^
<Wizzup>
I agree with that
<freemangordon>
to answer your question
<uvos>
i would not renable lg untill it only reboots once
<uvos>
period
<Wizzup>
so do we install that file from an update, or change the default in dsme? fine with either
<freemangordon>
hmm, image-builder?
<uvos>
i would move the very obscure file you have to touch
<uvos>
into a proper config file
<uvos>
and make it not default
<freemangordon>
this is developer, not end-user option anyways
<uvos>
a config .ini file
<uvos>
is not realy user facing
<uvos>
in a meaningfull way
<freemangordon>
why?
<uvos>
touch /etc/no_lg_reboots
<uvos>
is just bad
<uvos>
even for developers
<freemangordon>
oh, come on
<freemangordon>
if it is documented
<uvos>
it should not have to be documented
<freemangordon>
BTW, right now TS on d4 does not react
<uvos>
an /etc/dsme.ini with lifeGuardReboot=false ad a # explantaion what this is is self documenting
<freemangordon>
this is after I restarted mce a couple of times
<freemangordon>
while playing with quircs module
<freemangordon>
*quirks
<uvos>
if mce crashes while the display is off
<uvos>
that is the result
<freemangordon>
why is that?
<uvos>
becuase it disables the xinput devices
<uvos>
and it cant enable them on startup
<uvos>
because there are other disabled xinput devices it cant enable
<freemangordon>
but it reenables them on startup, no?
<uvos>
so it dosent know what to enable
<Wizzup>
we can move the file to /etc/dsme ?
<freemangordon>
sure, but how is that different?
<Wizzup>
more sensible to ship in dsme package
<freemangordon>
I mean - lets focus on important things, not where a particular, developer-only use file is located
<Wizzup>
I am just thinking about how to now make this no reset the default for now
<freemangordon>
I think image-builder shall create the file
<Wizzup>
so current users won't get it?
<freemangordon>
or, you want current users to have that too?
<Wizzup>
I think so
<freemangordon>
well, hildon-meta then
<Wizzup>
or leste-config
<freemangordon>
mhm
<Wizzup>
ok, I'll try to make it work
<uvos>
not meta
<freemangordon>
ok, -config
<uvos>
but i thing shiping it in dsme makes more sense
<Wizzup>
I agree with uvos but I also don't care enough to discuss it that much, either dsme package or leste-config
<Wizzup>
either is fine
<Wizzup>
so - can we talk pinephone :)
<freemangordon>
no, because changing that would require dsme upgrade
<Wizzup>
sure, ok
<freemangordon>
and this is one of the daemons you can't upgrade without rebooting the device
<freemangordon>
IIRC
<Wizzup>
fair enough
<Wizzup>
so pinephone ... it looks like the rendering problems are gone
<Wizzup>
but there definitely seems to be a (serious) performance penatly
<uvos>
we dont restart dsme on upgrade
<uvos>
thats it
<uvos>
otherwise you can upgrade it fine
<Wizzup>
as in, portrait mode is less smooth for sure than it was before
<Wizzup>
but I don't see rendering problems in firefox or the qt web browser or the osso-xterm thing I used to reproduce the bug
<freemangordon>
sec, phone call
<Wizzup>
ok, brb
<Wizzup>
yeah so the mesa patch + clutter change to request preserved buffers works
uvos has quit [Ping timeout: 256 seconds]
<freemangordon>
Wizzup: maybe we shall take that patch temporarily until we implement buffer_age
<freemangordon>
I think it makes sense to test that mesa+clutter on d4/n900
<Wizzup>
ok
<Wizzup>
I can build the clutter patch for -experimental
<Wizzup>
we would not expect perf change there right
<freemangordon>
mhm
<Wizzup>
how do we think buffer age will help perf btw
<freemangordon>
honestly I wonder how/why it works on SGX
<freemangordon>
Wizzup: it will prevent uploads
<Wizzup>
mhm
* freemangordon
is back to mce d4 quirks module
<freemangordon>
uvos: nothing shall be done on MCE_DISPLAY_DIM in that module, right?
_inky has quit [Ping timeout: 256 seconds]
<Wizzup>
freemangordon: oh wait I still had use_fallback = TRUE
<freemangordon>
:)
<Wizzup>
that explains poor perf
<freemangordon>
yeah
<freemangordon>
yeah, that's how I like it babe :). Double=press on d4 now losk immediately :)
<freemangordon>
uvos: there is at least one more regression - if you slide-open the keyboard, device unlocks, it should re-lock if you close the kbd without touching anything else
<Wizzup>
+1 that'd be nice to have
<freemangordon>
ugh, I was about to look at that h-s-m PR
<freemangordon>
hmm, lets have -things moved to stable first
<Wizzup>
freemangordon: what is the ugh about?
<uvos>
hmm
<uvos>
that worked untill very recently
<uvos>
ill look into it
<uvos>
ah i allready know what caused this problem
<uvos>
hmm
<uvos>
its not solvable
<uvos>
easly
<freemangordon>
great
<uvos>
so the problem is:
<freemangordon>
Wizzup: it was about that I just remember about it
<uvos>
on mce ignores events from devices it conisders "switch" devices
<uvos>
for this feature
<uvos>
and a couple of other things
<uvos>
in this case this means the slider switch itself dosent count as an aciton
<freemangordon>
uvos: there is a bug in PR, will push a fix in minute
<uvos>
problem ist
<uvos>
that the slider switch isent nesscarly on a different input device as everything else
<uvos>
this is true on n900
<uvos>
and sorta on d4 but not really
<uvos>
particualy the volume buttons are on the same device
<uvos>
so since i added the handlers for the volume buttons this broke as i had to make mce accept this input device
<uvos>
we need to replace the per input device behavor changes
<uvos>
with something that filters on keycodes
<freemangordon>
hmm, I think we already have that
<uvos>
sadly no
<uvos>
we dont
<uvos>
it filters event devices as a whole
<uvos>
based on the keys they advertise
<uvos>
this only works if the devices fit into its catigorys
<freemangordon>
yes, but you can have multiple listeners per device, no?
<uvos>
and there are even several devices to handle differently
<uvos>
no
<uvos>
and the listerners dont filter gennerally
<freemangordon>
hmm, I remember I implemented that correctly back than, but lemme check
<uvos>
they often just do something whenever any key gets pressed on some device category
<uvos>
sutch as cancle the autorelock
<uvos>
but theres lots of sutch handlers
<freemangordon>
uvos: you can call mce_match_event_file_by_caps() as much as you want
<uvos>
right
<uvos>
but that dosent help
<uvos>
since it expects there to be different event files
<uvos>
for different caps
<uvos>
this is a bad solution
<freemangordon>
not really
<uvos>
yes really
<uvos>
you cant make it work
<freemangordon>
you may have more than one file with same caps
<freemangordon>
same/matching
<uvos>
the amount of files is detiermined by the kernel
<uvos>
and matching a device to multiple caps
<uvos>
is no use
<uvos>
as the handlers expect a cap list to contain only buttons they expect and no others
<uvos>
the solution is to just have a single event que with all event devices bound to
<uvos>
and then have something that filters eatch event centraly
<uvos>
like xcb works
<uvos>
also libinput
<uvos>
we could use libinput acctually
<uvos>
that would be best
<freemangordon>
but you can attach different handler for every fd returned
<uvos>
but that dosent help
<uvos>
so there are categorys
<uvos>
like switches
<freemangordon>
and filter in the handler itself
<uvos>
those get ignored for timeout
<uvos>
and for autoreloc etc
<freemangordon>
hmm
<uvos>
all of them
<uvos>
so if a device matches that cagiory it gets ginored
<freemangordon>
I see
<freemangordon>
anyway, we'll have to fix that
<uvos>
that makes sense if its an input device with just the slider switch or something
<uvos>
but if its an input device with the silder switch and a keyboard
<uvos>
it breaks
<uvos>
there is nothing you can do about that
<uvos>
except replace how this works entriely
<tmlind>
for the issues with reboots, maybe all those watchdog features could be enabled by a package that can also be uninstalled if desired
<freemangordon>
uvos: ok, will have a look eventually
<freemangordon>
"nothing you can do" is a bit of an exaggregation :)
<freemangordon>
lemme fix the current PR first
<uvos>
well you have to rewirte how the filtering works
<Wizzup>
tmlind: I've rebased the ofono code we have on ofono 1.34, and will also add the pinephone patches now (assuming it all works well)
<Wizzup>
uvos: ^
<uvos>
Wizzup: great
<uvos>
figureing out whats wrong with the motorola modem ofono driver would be pretty great also
<uvos>
with sgx mostly out of the way this at least is what furstrates me the most when using the device
<Wizzup>
I don't have time do to that atm, but yes
<Wizzup>
I agree 100%
_inky has quit [Ping timeout: 240 seconds]
inky_ has quit [Ping timeout: 256 seconds]
_inky has joined #maemo-leste
inky_ has joined #maemo-leste
<Wizzup>
uvos: hmmm looks like it might even solve some problems
<Wizzup>
although it maybe uses some of pavels work
huckg has joined #maemo-leste
<Wizzup>
(modem is called droid_0)
<tmlind>
Wizzup: sounds good, if anybody has cycles to work on ofono we should use ell api directly to manage the mdm6600 ports as it's packet based after
<sicelo>
who/what decides modem name in ofono? i get n900_2 on n900, which looks odd sometimes. doesn't matter too much, but i do wonder
<Wizzup>
sicelo: I think in this case other driver is being used tbh
<Wizzup>
will investigate a bit later
<uvos>
if its using palis hacked at driver for the d4 we really dont want that
<uvos>
as it uses the at interface
<Wizzup>
pavel not pali
<Wizzup>
and yes I'll investigate in a bit
<uvos>
right
<humpelstilzchen[>
modrana seems to be broken
<Wizzup>
what do you see? any this is om the pinephone?
<humpelstilzchen[>
yes, on pine. It does not download any map.