<freemangordon>
tmlind: though, better wait before including those, I plan to sent patches to Tomi and most-probably will reword commit descriptions
<freemangordon>
*send
L29Ah has quit [Ping timeout: 240 seconds]
<tmlind>
freemangordon: ok i'll add those tonight so then we should have a complete dev branch
pere has quit [Ping timeout: 240 seconds]
<tmlind>
bbl tonight
<rafael2k>
[137029.457550] udevd[19047]: failed to execute '/usr/sbin/iw' '/usr/sbin/iw wlan0 set power_save on': No such file or directory
<rafael2k>
sicelo: it does not matter, it will be loaded in memory anyway, but it could be a module, yes
<rafael2k>
just finish kernel compilation now, if it works, we could just flip ov5640 to M for the repo package
<rafael2k>
iw is in /sbin/iw, but udevd looks for it in /usr/sbin
* dsc_
shoots at dbus
<rafael2k>
unified usr seems a good option to solve this
<rafael2k>
I can just delete from the patch both cameras as built-in (GC2145 is also built-in) - will do it after I make sure kernel works
<rafael2k>
yay, package created
<rafael2k>
: )
<rafael2k>
can anyone point me where to get boot.txt currently used for maemo pinephone images, so I can make sure kernel works with default configuration?
rafael2k has quit [Quit: BitchX: now in non-drowsy formula too!]
rafael2k has joined #maemo-leste
System_Error has quit [Ping timeout: 276 seconds]
<freemangordon>
tmlind: could you have a look at https://pastebin.com/PYnDYxPv ? Please advice if you think something shall be added/removed/etc to the commit message. This is the commit that most-probably Tomi will NACK, so I want to format the commit message in the best possible way.
<rafael2k>
Wizzup: about debian/patches/mobian/0213-builddeb-don-t-build-linux-libc-dev-package.patch, yes, you did that, and I think it was on purpose, as we have the maemo-quirks stuff on top of the Makefile, but if you want that, it would be easy to rebase
<rafael2k>
seems all good... I hope I did the job right in git mobian-5.15.
<Wizzup>
we'll see :)
<rafael2k>
fingers crossed
<Wizzup>
freemangordon: shall I cherry pick the tearing patch into our 5.15
<Wizzup>
we could also try to go to 5.16 soon, but I am a bit inclined to get 5.15 to stable first
<freemangordon>
Wizzup: lets freeze for a while
<Wizzup>
ok
<freemangordon>
:nod:
<Wizzup>
but do we pick the tearing patch?
<freemangordon>
no
<Wizzup>
ok
<freemangordon>
it is not critical
<Wizzup>
I also want to work on a news post some, I think today
<Wizzup>
going to be a lot
<freemangordon>
also, I think we shall focus on fixing the pile of issues we currently gave in -devel, push to -stable and then start working on new stuff
<Wizzup>
as opposed to?
<freemangordon>
pushing new things to -devel
<Wizzup>
I mean I agree, just not sure to what issues it translates for you exactly
<freemangordon>
charging on d4, vtklock
<freemangordon>
both are terribly broken in -devel
<freemangordon>
also, issues we see on n900
<Wizzup>
I don't know if they are working on stable, I had bad experiences on stable and it is ok for me now on -devel
<Wizzup>
maybe we need a list
<freemangordon>
well, not sure about stable, but both were working pretty much ok for me and got broken ~2 weks ago
<freemangordon>
*weeks
<Wizzup>
so the recent patch didn't help?
<freemangordon>
helped a little bit
<freemangordon>
like, device charges
<freemangordon>
but there are no notifications
<Wizzup>
imho my main non-telepathy prio is figuring out why the pinephone vkb is broken because I am hoping we can get enunez' help still
<Wizzup>
hmm I see @ notifications
<freemangordon>
this is kernel issue for sure
<freemangordon>
(PP)
<Wizzup>
the vkb stuff?
<freemangordon>
because it works ok on -stable
<freemangordon>
yes
<Wizzup>
oh, ok, let's get new kernel first then
<freemangordon>
mhm
<freemangordon>
so, I think the plan shall be - fix those issues, push to stable, start implementing new things
<freemangordon>
yeah, d4 with charger connected on boot does not charge
<freemangordon>
this was working for sure
<uvos>
works fine here
<uvos>
wierd
<freemangordon>
uvos: did you have a look at mce log I pasted ^^^
<uvos>
i did but its useless without knowing when the states changed relative to tklock states
<uvos>
so a tklock log with times would be required
<uvos>
but im pretty sure i know what the issue is anyhow
<uvos>
just cant repoduce this problem eihter
<uvos>
(without pressing power to cause race on purpose)
<freemangordon>
uvos: but why I see 2 power buttin presses in that log?
<uvos>
also no way it worked a couple of weeks ago
<freemangordon>
*button
<uvos>
mce has had no changes in a long time really
<freemangordon>
I pressed it only once
<uvos>
oh ok
<uvos>
hmm
<freemangordon>
and yes, I can assure you that was working fine
<uvos>
well a change in mce dident cause this then
<freemangordon>
uvos: that is double-press timeout?
<freemangordon>
*what is
<uvos>
dunno what is default
<uvos>
PowerKeyDoubleDelay=1000
<freemangordon>
yeah, this is the bug
<uvos>
explain?
<freemangordon>
lock the screen, press power button, while vtklock is displayed, press power button again
<freemangordon>
swipe to unlock
<uvos>
ok
<uvos>
dident see anything
<uvos>
do i have to do this fast?
<freemangordon>
or actually double-press to show vtklock
<freemangordon>
yes
<freemangordon>
seems second press got queued somewhere
<uvos>
ah yeah
<uvos>
you can douple press
<uvos>
and then mce thinks its double press to lock
<uvos>
sometimes
<freemangordon>
but this should get reset on vtklock being shown
<uvos>
i gues your device might have a bouncy/dirty power button
<uvos>
makeing this happen more often
<freemangordon>
yeah, could be
<uvos>
ok
<freemangordon>
but still, a bug in mce to me
<uvos>
ok
<uvos>
i gues
<uvos>
at least this can be imporved
<uvos>
ill do it
<freemangordon>
thanks
<freemangordon>
also, sometimes single-press does not get registered
<freemangordon>
but evtest shows it
<uvos>
dose mce ragister anything wiht the power button
<uvos>
in the log
<freemangordon>
also, double-press wait for a second or so to lock the device
<uvos>
in this case
<freemangordon>
lemme check
<uvos>
do think it wait
<uvos>
s
<uvos>
really
<uvos>
its just xinput and dpms calls to x take pretty long
<freemangordon>
a second?
<uvos>
and mce executes these sync
<uvos>
yeah dpms takes forever
<uvos>
and only returns after the display is off
<freemangordon>
hmm, we shall fix that somehow
<freemangordon>
I mean - a second to turn display off :(
<uvos>
its also tklock too
<uvos>
so mce waits on xinput first, then tklock, then dpms
<uvos>
(depedns on what order you load the modules)
<freemangordon>
tklock should be fast
<uvos>
vtklock is slow
<uvos>
no idea how fast tklock is
<freemangordon>
but yeah, I guess we shall measure the times
<freemangordon>
and try to optimize
<freemangordon>
not high prio though, lets make it work corectly first :)
<uvos>
vtklock is quite slow tho
<uvos>
if you load lock-generic instead of tklokc
<uvos>
mce is mutch faster
<uvos>
anyhow yeah
<freemangordon>
yeah, I plan to improve vtklock someday
<freemangordon>
as it also has those nasty rendering artefacts too
<uvos>
hmm what artifacts?
<uvos>
i dont see any
<uvos>
other than it breaking in portrait
<uvos>
(not really a artifact as sutch)
<freemangordon>
slider is displayed incorrectly for a split second
<Wizzup>
yeah (displayed incorrectly) and portrait would be good to have
<freemangordon>
uvos: can't repro missed single-press now
<freemangordon>
I restarted mce, so...
<freemangordon>
uvos: also, I think mce verbose log must display time
<freemangordon>
it is with limited usefulness otherwise
<uvos>
well it logs to syslog
<uvos>
so that adds time
<freemangordon>
does it?
<uvos>
but sure
<uvos>
theres an option for it yeah
<freemangordon>
ah, yeah
<freemangordon>
ok, but when it logs to the console, there are no times
<freemangordon>
but yeah, not a biggie
<rafael2k>
reading your messages - is vkb in pp broken? did not know that. I'm kind of using it sometimes...
<uvos>
renders wrong
<rafael2k>
how it renders wrong?
<rafael2k>
I renders fine.
<rafael2k>
*It
<rafael2k>
what renders wrong is the lock screen in portrait mode.
akossh has joined #maemo-leste
<rafael2k>
What needs imho in pp is: kernel update, add some missing firmware (camera / bluetooth), rework the alsa/ucm/pulseaudio config to match new kernel, new ofono, fix graphics rendering issues (noaccell is working fine thou)
<rafael2k>
and voila, I would call it stable. of course the only hard issue is the fix for the rendering issues...
<Wizzup>
rafael2k: yeah so I can do the ofono stuff
<Wizzup>
rafael2k: and the kernel stuff is happening now
<Wizzup>
missing firmware (cam) - if you make a pr I can look at it, for ucm, I suppose we can get a ucm from mobian?
<Wizzup>
wrt graphics rendering, someone was helping us with it, but he ran into a vkb problem
<Wizzup>
which seemed to be kernel problem per fmg, so hopefully your kernel helps
<rafael2k>
Wizzup: I'll look the audio setup in mobian, yes
<Wizzup>
great work :)
<Wizzup>
let's see how the kernel goes when it's done
<rafael2k>
concerning the missing firmware, that is easy thing, until next weekend I can sort this out
<Wizzup>
we might have a package for the firmware already, not sure, maybe parazyd knows?
<Wizzup>
rafael2k: oh btw, did you get the keyboard already?
<Wizzup>
rafael2k: iirc we needed to pull in some extra commits for the keyboard to work
<rafael2k>
I just see some messages in dmesg about missing firmware for one of the cameras and bluetooth
<rafael2k>
Wizzup: keyboard support is enabled in the new kernel
<rafael2k>
Wizzup: Also PPP support is in place
<rafael2k>
Wizzup: as soon as the PP keyboard arrives, we'll have support
<Wizzup>
rafael2k: great, someone who was here the other day already had one but said our (stable) kernel didn't work yet
<Wizzup>
rafael2k: through kernel yeah, not userspace?
<rafael2k>
Wizzup: we did not copy the new PPP dtb... lets leave this for the next kernel build
<Wizzup>
yeah
<rafael2k>
I think we also need a updated u-boot, then it should boot fine.
<Wizzup>
for ppp you mean
<rafael2k>
most of the peripherals are the same in ppp, apart of the SoC itself, so support should be pretty simple
<rafael2k>
yes, for ppp
<Wizzup>
wonder if its power management will be any better
<rafael2k>
I would not hold my breath...
<rafael2k>
the SoC sucks even more power...
<rafael2k>
pp keyboard is a must-have to use it a whole day without a power bank or a socket...
<Wizzup>
ow
* Wizzup
is happy his droid4 lasts 2-3 days
<rafael2k>
at least is keeps my pocket warm
<Wizzup>
lol
<rafael2k>
:P
L29Ah has joined #maemo-leste
<uvos>
freemangordon: yeah so experiamenting with mce a bit it looks like the problem is how double press is registered too
<uvos>
freemangordon: so mce times from when it reads the event
<uvos>
freemangordon: instead of the kernels reporting time of the event
<uvos>
freemangordon: so thats pretty terrible
<uvos>
since if mce gets stalled for any reason
<uvos>
any 2 presses of the power button will be a double press
<uvos>
since mce will read them at the same time when it unstalles
<freemangordon>
well, I don;t quite agree, as when you single-press, mce reacts to that and shows tklock
<freemangordon>
if there was a second press after that, it should not be treated as a double-press
<freemangordon>
becasue single-press was already registered and acted upon
<uvos>
freemangordon: right except the double press timeout was allready registerd
<uvos>
freemangordon: then mce stalls
<freemangordon>
I guess you mean some implementation detail
<uvos>
the implementation is just terrible
<freemangordon>
so, you can;t cancel that timeout?
<uvos>
no beacuse mce is stalled
<uvos>
by the time its unstalled the timeout is over
<freemangordon>
or, you callback function you can't check what is the current state?
<freemangordon>
s/you/in
<freemangordon>
that should be doable, no?
<uvos>
thats not the real solution
<uvos>
theres lots of issues here
<uvos>
the real problem is that powerkey assumes it processes events in real time, so it assumes that the delay between 2 presses and between press and release is the time between when it processes these events
<uvos>
and also that mce state when the keys where pressed is the state _now_ when it processes them
<uvos>
the solution is to rewirte it to instead look only at the time value in the event struct
<uvos>
to make sutch descissions
<freemangordon>
sorry, have to attend work mtg, ttyl
xes_ has joined #maemo-leste
xes has quit [Ping timeout: 256 seconds]
xes_ has quit [Ping timeout: 240 seconds]
inky_ has quit [Ping timeout: 256 seconds]
_inky has quit [Ping timeout: 256 seconds]
xes_ has joined #maemo-leste
inky_ has joined #maemo-leste
_inky has joined #maemo-leste
xmn has joined #maemo-leste
Blikje has quit [Remote host closed the connection]
Blikje_ has joined #maemo-leste
R0b0t1`` has quit [Ping timeout: 240 seconds]
<Wizzup>
rafael2k: kernel build completed
joerg has quit [Excess Flood]
joerg has joined #maemo-leste
pere has quit [Ping timeout: 240 seconds]
xmn has quit [Ping timeout: 240 seconds]
joerg is now known as Guest8395
joerg has joined #maemo-leste
Guest8395 has quit [Ping timeout: 256 seconds]
xmn has joined #maemo-leste
Blikje_ is now known as Blikje
System_Error has quit [Remote host closed the connection]
<tmlind>
freemangordon: ok around now here and there
<rafael2k>
Wizzup: yay!
<inky>
rafael2k, Wizzup, what changed?
<tmlind>
freemangordon: so omap_gem_pin() is hard to follow.. and that makes your patch even harder to follow :)
<tmlind>
freemangordon: maybe prepare things a bit first by returning early for the omap_gem_is_contiguous() related checks?
<tmlind>
freemangordon: or split the function into some helpers depending on the mapping type?
<uvos>
Wizzup: why would that be extream? x has at least one fd open per client
pere has joined #maemo-leste
<freemangordon>
tmlind: the patch as such is ok, I mean - if Tomi requires changes I will do them. The point/question is - do you think I shall add anything to the commit message
<freemangordon>
like, is it clear why the patch?
<freemangordon>
Wizzup: hmm
<freemangordon>
never seen that. did you check if you have free memory?
<freemangordon>
maybe there is some memory leak, I will have to check allocations
<tmlind>
freemangordon: i doubt tomi will apply such a patch, too complicated to follow.. and he probably wants it broken into smaller chunks to review it
<tmlind>
just guessing of course :)
<tmlind>
freemangordon: i guess you can always send it to the lists and let's see what tomi says
<tmlind>
freemangordon: hard to say if the description is ok as i can't really follow the patch :)
<rafael2k>
inky: basically the support for pp is complete, all drivers are there, including modem, also the kernel has most of the modules enabled, allowing for example, all luks ciphers, packet filtering, NAT and so on
<rafael2k>
inky: also pp keyboard support should be there (not tested yet, keyboards are on the way)
<freemangordon>
tmlind: oh, ok, will try to rework it a bit to simplify it
<tmlind>
freemangordon: sounds good to me :) maybe separate helper functions to avoid the complicated if else stuff?
<tmlind>
freemangordon: i suspect your patch makes sense, it's just the current function gets interlaced into the patch badly making it hard to follow
<rafael2k>
inky: even some modules for android compability available in the kernel are enabled as modules, in case anyone crazy enough wants to run anbox...
<freemangordon>
tmlind: yeah
<tmlind>
uhh need to try to understand recent n_gsm.c for v5.16 branch.. need to continue tomorrow night
inky has quit [Ping timeout: 256 seconds]
inky has joined #maemo-leste
<_inky>
rafael2k: thank you!
<rafael2k>
: )
<Wizzup>
uvos: combined with no windows open and out of memory...
<Wizzup>
uvos: seems fishy to me
sunshavi has quit [Remote host closed the connection]
Blikje has quit [Remote host closed the connection]