<tmlind>
then i think the reason why weston-simple-dmabuf egl is no longer working with wlroots is probably commit a04cfca4da42 ("Remove support for DMA-BUF flags")
lad_ has joined #maemo-leste
<lad_>
Всем привет, дайте пожалуйста информацию, как установить maemo-leste на N900?
<lad_>
Hello everyone, please give information how to install maemo-leste on N900?
DPA- has quit [Read error: Connection reset by peer]
DPA has joined #maemo-leste
DPA has quit [Ping timeout: 250 seconds]
DPA has joined #maemo-leste
uvos has joined #maemo-leste
<freemangordon>
uvos: something got broken in mce (I suppose) recently:
<freemangordon>
2. press power button (vtklock to be displayed)
<freemangordon>
3. unlock
<freemangordon>
4. press power button again
<freemangordon>
1. lock with vtklock
<freemangordon>
instead of power button menu being shown, device locks again
<freemangordon>
this happens most of the times
<freemangordon>
tmlind: with your TE patch (and my changes) device does not boot at all, like it hangs waiting for something after displaying a couple of 'TE not receined' and 'framedone not received' messages
DPA has quit [Ping timeout: 240 seconds]
<freemangordon>
or, did I get i wrong and my patch shall not be applied?
DPA has joined #maemo-leste
<freemangordon>
hmm, I guess yes
<tmlind>
freemangordon: yes don't apply your patch, this test does not depend on getting te to work, it's just a hacky tear test
<freemangordon>
yeah
<freemangordon>
still tears, lemme check dmesg
<tmlind>
ok
<freemangordon>
nothing there!
<freemangordon>
I mean - none of the prontks
<freemangordon>
*printks
<freemangordon>
that's weird, no?
<freemangordon>
tmlind: what is trace_printk?
<Wizzup>
lad_: typically we install on microsd card for now
<tmlind>
freemangordon: assuming tracing is enabled, just do sudo cat /sys/kernel/debug/tracing/trace_pipe
<freemangordon>
ok
<tmlind>
nice for debugging
<freemangordon>
yeah, I see
<freemangordon>
well tearing is still there, but I don;t really see why it should be fixed.
<tmlind>
yeah
<freemangordon>
I mean - why do you expect DSI_VC_TE bit to be set?
<tmlind>
that means there are still bytes in flight to the lcd
* freemangordon
checks the conditions for this bit to be set
<tmlind>
it's a counter with two start bits, one for the current update mode and one for te
<tmlind>
freemangordon: it gets configured in dsi_update_screen_dispc()
<freemangordon>
tmlind: IIUC, you expect TE_EN to become zero?
<freemangordon>
but, this is never set to 1 in the first place, unless I miss something
System_Error has quit [Ping timeout: 276 seconds]
<freemangordon>
ok, lemme think for a while
<tmlind>
TE_START or TE_EN gets used depending on the mode, it gets set
<freemangordon>
yes, and we use TE_START
<freemangordon>
because TE_ENABLED is false in panel data
<tmlind>
correct
<tmlind>
you can monitor the register change with watch -n0.1 sudo rwmem 0x58004104
<freemangordon>
ok
<freemangordon>
lemme try
<freemangordon>
hmm, no rwmem here :(
<freemangordon>
anyeay, lemme see how is that expected to worl
<tmlind>
try busybox devmem
<freemangordon>
mnm
<freemangordon>
*mhm
<freemangordon>
tmlind: right
<freemangordon>
but, IIUC, we set TE_START at some arbitrary moment, not is sync of panel refresh cycle, no?
<freemangordon>
*not in
<freemangordon>
and because transfer start immediately, we see tearing
<lad_>
[13:23] [Wizzup] ~ lad_: typically we install on microsd card for now // in the future, will it be possible to install on the main memory?
<freemangordon>
it is not that we don;t wait for transfer to finish before we start the next one we see that tearing
<tmlind>
we configure VC_TE when we update the LCD
<freemangordon>
no, we don;t
<freemangordon>
because te_enabled is false in panel data
<tmlind>
we still configure VC_TE, in the current mode soc dsi controller takes care of the transfer instead of the LCD panel controller that does the transfer in TE enabled mode
<freemangordon>
tmlind: see dsi_update_screen_dispc
<freemangordon>
if (dsi->te_enabled) ...
<freemangordon>
if te_enabled is false, we configure TE_START
<freemangordon>
not TE_EN
<tmlind>
right
<tmlind>
TE_EN just makes the LCD panel do the transfer after BTA
<freemangordon>
setting TE_START means "start immediately" if I get this right
<tmlind>
also with TE_EN set dsi_vc_send_bta() makes the LCD panel controller start the transfer
<freemangordon>
I think TE_EN means "start transfer after conditions set in xSYNC registers are set"
<freemangordon>
yes
<freemangordon>
anyway, my point is that we have issues with transfer start
<freemangordon>
because we start it in the middle of panel refresh cycle
<tmlind>
yeah it's possible if the LCD panel controller is supposed to wait something after TE_EN
<freemangordon>
I still don;t understand why TE_EN given that we use TE_START
<freemangordon>
like, if we use TE IRQ, TE_START is set by the HW
<Wizzup>
lad_: yes regarding installing on the emmc / main storage, you can probably do it already, but we don't do it for recovery reasons
<freemangordon>
if we set it manually (which we do) transfer starts immediately
<tmlind>
freemangordon: seems the te gpio case is different from the bus controlled te
<freemangordon>
the only difference I see is who generates the irq
<freemangordon>
PHY vs gpio
<freemangordon>
but maybe I am missing something
<tmlind>
well the phy irq triggers right after the bta, but maybe that's only if the sync regs are not programmed
<freemangordon>
most-probably
<freemangordon>
as for sure vendor kernel does that (programming sync regs)
<freemangordon>
also, it programs 'te scan line'
<tmlind>
yeah but it might be also just left over stuff from the te cmos mode, easy to check though
<tmlind>
i'll see if the te irq triggers later after configuring the scan regs
<freemangordon>
I doubt, as vendor panel driver has some special handling for one of the displays, where cmos mode is used
<tmlind>
ok
<tmlind>
let's hope your theory is correct, then we would get a proper irq after te is done
<freemangordon>
mhm
<tmlind>
not sure what's broken with enabling te as the te interrupt stops happening pretty fast
<freemangordon>
but it happens, right?
<tmlind>
yeah, for up to two mins, often for just few tens of secs
<freemangordon>
well, then we misconfigure something
<freemangordon>
could be something in the panel though
<tmlind>
sometimes there are signaling errors in the complexio regs
<freemangordon>
vendor driver send ~ 15 commends on init
<freemangordon>
*commands on
<tmlind>
yeah
* freemangordon
needs more coffee :)
<tmlind>
seems like we can likely add one byte of add_device_randomness() based on the remaining buffer in framedone if there is something remaining :)
<freemangordon>
tmlind: I still think we don;t have issues with unfinished transfers
<freemangordon>
but with our transfer start being in the middle of the panel internal transfer cycle
<freemangordon>
s/transfer/refresh
<lad_>
[13:42] [Wizzup] ~ lad_: yes regarding installing on the emmc / main storage, you can probably do it already, but we don't do it for recovery reasons // thanks for the answer
<Wizzup>
sure, np
<freemangordon>
Wizzup: were there any hangs? BTW, if the issue is a result from the fence patch, I think I know how to workaround it, until we find a proper fix
<Wizzup>
freemangordon: no, not yet @ ioctl hangs
<freemangordon>
ok
<Wizzup>
freemangordon: btw kernel in repo has a fix for charging, please test when you can
<freemangordon>
ok
<freemangordon>
tmlind: hmm, see https://pastebin.com/4dgz4WuZ . this comment is in dsi_framedone_irq_callback in vendor kernel
<freemangordon>
seems we need BTA on framedone to receive TE
<freemangordon>
which kind of makes sense
Pali has joined #maemo-leste
lad_ has quit [Ping timeout: 256 seconds]
<tmlind>
freemangordon: we already do the "more optimal" part described in the comments, see dsi_send_nop()
<freemangordon>
ok
<tmlind>
did not have any luck making the te interrupt happen later by maxing out the sync regs
<freemangordon>
I will try sending all those commands to panel later on
<freemangordon>
btw, do you know which is the exact pane model we are talking about (in vendor kernel terms)?
<freemangordon>
there are basically 5 different variants it seems
<freemangordon>
one of them being MOT_DISP_MIPI_CM_430_540_960_AMOLED and this one needs special massaging for TE to happen
<freemangordon>
I guess I will have to trace the panel id
<Wizzup>
funny how telepathy-qt has so much stuff for matching all these things but a simple 'look up this nickname on this connection/protocol' is basically non existent
<tmlind>
panel_id=0x90004 in stock dtb, add leading zeros when grepping the stock kernel
<BlagovestPetrov[>
but this happens when I try to execute install.sh
uvos has joined #maemo-leste
<Wizzup>
BlagovestPetrov[: hmmm I recall seeing that before
<Wizzup>
I am going to have to try really hard to remember what I did there
<BlagovestPetrov[>
I may try to do it manually :)
<BlagovestPetrov[>
copying the files, etc
<Wizzup>
so there is definitely a problem with something being read-only when it should be read-write and there is a way to do this with mount but on android everything is slightly messy
<BlagovestPetrov[>
yeah
<Wizzup>
iirc -o remount,rw or something didn't work and I had to try something else
<Wizzup>
trying to search the logs
<Wizzup>
BlagovestPetrov[: I think it needs to be this:
<Wizzup>
20:09 < Wizzup> mount -o remount,rw /dev/block/system /system
<Wizzup>
unless that is already in install.sh
<Wizzup>
yeah nope
<Wizzup>
try putting that there instead of adb shell "su -c 'mount -o remount,rw /system'"
<tmlind>
freemangordon: cool so that fixed your tearing test case?
<BlagovestPetrov[>
sorry, here :)
<BlagovestPetrov[>
thanks
<BlagovestPetrov[>
the same happened and the phone stuck on boot logo. I'll try to do it line by line :)
<tmlind>
freemangordon: yeah i wonder if the sync registers actually generate a real vblank interrupt?
inky_ has quit [Ping timeout: 256 seconds]
inky has joined #maemo-leste
<BlagovestPetrov[>
now Android is permanently stuck on the boot logo. I will need the stock image
<Wizzup>
do you need me to share a link to it?
<BlagovestPetrov[>
Wizzup: the pushes were put before the mounts in the script. It looks like the main issue :)
<BlagovestPetrov[>
sure, if you have it somewhere
<BlagovestPetrov[>
does it work with fastboot on Droid 3?
<BlagovestPetrov[>
some of the older androids were using other tools
<Wizzup>
BlagovestPetrov[: I think you need VRZ_XT862_5.5.1_84_D3G-55_1FF_01.xml.zip right?
<tmlind>
freemangordon: nice, i'm not seeing any timeouts with your te patch :)
<BlagovestPetrov[>
I'm not sure
<BlagovestPetrov[>
yeah, it's mentioned in the readme :)
<Wizzup>
BlagovestPetrov[: ok let me look at scp'ing it, make sure you know how to flash it
<Wizzup>
arg maedevu has so little free space
<BlagovestPetrov[>
for the fastboot to work, the phone should be in bootloader?
<BlagovestPetrov[>
I just don't get why we need the xml
<Wizzup>
it's just called .xml.zip
<Wizzup>
so are there instructions on how to flash it to the droid3 on the wiki or so?
<Wizzup>
doesn't look like there are any
<Wizzup>
ah I have a script
<Wizzup>
10 ins
<Wizzup>
10 mins*
<BlagovestPetrov[>
ok :)
<freemangordon>
tmlind: maybe your vsync patch somehow interacts with this, as if you run gears in window and starts swiping h-d the tearing re-appears
<tmlind>
freemangordon: interesting, i'll test locally instead of my rack setup with wlroots if i get a chance tonight
<tmlind>
no real vblank interrupts triggering
<tmlind>
freemangordon: did the dbm patch work ok for you?
<tmlind>
freemangordon: it seems it should be ok to do the vblank event on framedone, panel is just a few ms behind with the update compared to page flip and i don't think we need to wait on the panel regarding the page flip
<tmlind>
freemangordon: also check if adding cpu load with dd if=/dev/urandom of=/dev/null makes the tearing reappear?
<tmlind>
as that will cause dsi to always have data in flight on framedone probably as cpu does not idle
<freemangordon>
tmlind: ok
pere has quit [Ping timeout: 240 seconds]
<freemangordon>
but, isn;t it doing DMA? why CPU?
<tmlind>
no idea..
<tmlind>
maybe faster response to interrupts with no idle?
<BlagovestPetrov[>
Wizzup: it's my fault. The script is using /sdcard but I already flashed maemo there :)
<freemangordon>
tmlind: BTW, I need that panel driver needs proper quirk handling, like panel specific enable function to be called
<freemangordon>
tmlind: no tearing with 'dd if=/dev/urandom of=/dev/null'
<freemangordon>
but, I see tearing when vkb pops, that's why I think it must be related with drmDirtyFb call somehow
<tmlind>
ok
<freemangordon>
hmm, if I disable drmDirtyFb calls in DDX, there is absolutely no tearing
<tmlind>
ok
<freemangordon>
but, we are missing repaint, ofc
<freemangordon>
lemme revert vblank patch and see how itwill behave without it
* tmlind
reboots d4 without the vblank emulation patch
<freemangordon>
oh, with this TE change hildon swipe fps is limited to 60 :)
<freemangordon>
like on android (as uvos said)
<freemangordon>
tmlind: I don;t think TE can replace vsync - in order to have TE irq you need to queue transfer
<freemangordon>
in order to queue transfer, you need drmDirtyFb
<freemangordon>
tmlind: oh, with vblank patch reverted I no longer see that ugly 'flashing' when rotating landscape<->portrait
<Wizzup>
oooh that'd be nice
<freemangordon>
hmm, actually I still see it
<freemangordon>
somehow it got better
<tmlind>
freemangordon: weird, with your te fix or some other earlier fix things mostly work for me with wlroots without the vblank emulation patch
<tmlind>
freemangordon: looks like stellarium only gets about 6fps with your mesa compared to 12fps with the ti blobs that have the glmark2-es2-wayland hang issue
<freemangordon>
yeah, I think we shall drop vblank patch assuming that userspace is smart enough to know to call drmDirtyFb or somesuch
<tmlind>
ack
<freemangordon>
tmlind: well, it could be that it is not 'my' mesa, but 'upstream' mesa at fault here
<tmlind>
hmm looks like weston-simple-shm has some stripes in it's window, that's about the only issue i now notice
<freemangordon>
as I did nothing more but to RE what was already in pvr_dri.so
<tmlind>
maybe there's some debug or tracing option enabled now?
<freemangordon>
in mesa?
<tmlind>
yeah
<uvos>
freemangordon: android behavior is actually kinda wierd on this
<freemangordon>
none I am aware of
<uvos>
freemangordon: yeah the genneraly ui is limited to 60 fps
<freemangordon>
but?
<uvos>
freemangordon: but some vsynced games run at ~70
<freemangordon>
well, what I see here is that h-d swipes (and refreshes) @ 60
<uvos>
ok
<uvos>
anyhow
<freemangordon>
but gears and glmark render with > 60
<uvos>
regarding power menu on vtklock
<uvos>
i think this might be the fault of the patch that makes vtklock hold a grab
<freemangordon>
are you able to reproduce?
<uvos>
havent tried yet
<uvos>
but
<freemangordon>
ok
<uvos>
the other "context" menu type windows are raised by grab transfer
<uvos>
a grab transfer is impossible if vtklock holds a grab
<freemangordon>
uvos: the actual issue is that device relocks in 2 seconds
<uvos>
oh ok
<freemangordon>
no matter if you press power button or not
<uvos>
i thought you siad that its impossible to open power menu
<uvos>
so how do you tigger this?
<freemangordon>
well, that6's how I initially hit that
<uvos>
let me activate tklock again and reboot
<freemangordon>
the same, just does not press th epower button
<tmlind>
with wlroots i also see es2gears_wayland run at 60 fps
<freemangordon>
uvos: I would recomment you to have a second uSD with vanilla leste on it
<freemangordon>
*recommend
<uvos>
freemangordon: hm so lock the device with tklock?
<uvos>
freemangordon: and then what?
<uvos>
freemangordon: press power?
<freemangordon>
yes
<freemangordon>
and then swipe
<freemangordon>
to unlock
<freemangordon>
most of the times it shows desktop for 1-2 seconds and then display gets dark (device gets locked)
<uvos>
what have you set as what in mce.ini
<uvos>
power key wise
<freemangordon>
no idea, like, whatever is set by you
<freemangordon>
I have changed nothing
<freemangordon>
lemme try to boot leaste, as I was charging in android :p
<uvos>
the charging problem shout be fixed for you
<uvos>
ofc i cant test
<freemangordon>
yeah
<uvos>
since i cant repo
<uvos>
it is?
<freemangordon>
that's the next thing
<uvos>
ok
<freemangordon>
didn;t test yet
<uvos>
o
<uvos>
k
<freemangordon>
will capture a video for you to see what happens
<uvos>
ok so tklock problem dosent show here
<uvos>
but i allways change PowerKeyShortAction=tklock
<uvos>
because i dont like that the power key changes behavior depending on lock state
<bencoh>
I think there used to be a "visible desktop" bug in tklock on fremantle a long time ago
<bencoh>
but I might be misremembering
<tmlind>
freemangordon: i'll do a droid4-pending-pvr-omapdrm-v5.16 branch after you've sent out your te fix
<tmlind>
i wonder if some of the panel configuration commands are same as in the ILI9488-ILITEK.pdf i found online
<tmlind>
it has "5.3.42. Adjust Control 6 (FCh)" for reg 0xfc
<freemangordon>
tmlind: I was not planning to send a patch for that:
<freemangordon>
IMO driver needs to be extended to support panel quirks and I don;t feels capable of doing so cleanly
<freemangordon>
tmlind: however, if you say you're not going to send a patch, I will do it, but I don;t think this is going to happen soon - I already spend too much time on kernel I should have spend on osso-abook :)
<freemangordon>
*this is not going to
<freemangordon>
tmlind: hmm, ILI9488-ILITEK.pdf - how is that related to mapphone panel?
<tmlind>
freemangordon: i don't think that is related, but has at least some documentation on the dsi command mode
<freemangordon>
ah, ok
<tmlind>
freemangordon: your patch, you fix it and send it :p
<freemangordon>
well...
<freemangordon>
what I did was just a quick hack
<freemangordon>
this is not a proper patch
<freemangordon>
so, I will do, but in a month or so
<tmlind>
fine
<tmlind>
how about type up some description for it and i'll do droid4-pending-pvr-omapdrm-v5.16?
<freemangordon>
maybe
<freemangordon>
not now though
<rafael2k>
anyone has a copy of xmonobut?
<tmlind>
freemangordon: i added your patch as a wip patch and pushed out droid4-pending-pvr-omapdrm-v5.16 to github, only build and boot tested so far
<rafael2k>
now just need to play with config (kind of no-brainer to me this... but moving ahead)
inky_ has joined #maemo-leste
<rafael2k>
btw, is this alarm / phone off-on-off workflow you mentioned as the reason for not having a initrd works on pinephone?
<rafael2k>
Wizzup: lemme know how ofono package update is going, in case of any help needed...
inky has quit [Ping timeout: 250 seconds]
<freemangordon>
Wizzup: uvos: upgraded d4 to latest -devel, battery icon gets animated on charger being connected, however, there is no "charging" or "unplug to save energy" messages
<freemangordon>
also, device was started with charger connected, but it was not detected, I had to re-connect the cable
<Wizzup>
rafael2k: make it boot - made it boot?
<freemangordon>
connecting charger does not unlock the device
<Wizzup>
rafael2k: will look at ofono once kernel is ok :)
<freemangordon>
tmlind: btw, with vblank patch reverted, I no longer see "atomic complete timeout (pipe 0)!" messages
<rafael2k>
Wizzup: :(
<rafael2k>
Wizzup: does not makes sense, but anyway...
<rafael2k>
Wizzup: not like the kernel, ofono is ready to go "upstream"
<rafael2k>
Wizzup: I mean, kernel is ready... apart of this specificity of maemo not wanting initrd... thing I'm working right now
<sicelo>
freemangordon: at least the charger connected at boot issue is also there in android. i also have to reconnect there. maybe general cpcap issue?
<Wizzup>
rafael2k: not pushing or anything, just seems to make some sense to wait for it since our current (before your work) did not have modem working
<Wizzup>
rafael2k: will try to get to it real soon
<Wizzup>
rafael2k: been focussing on the telepathy stack
<rafael2k>
Wizzup: -devel kernel was broken, but otherwise kernel 5.10 had telephony enabled and working
<rafael2k>
Wizzup: cool!
<rafael2k>
Wizzup: telepathy seems a monster to work with...
<rafael2k>
I remember to have skype on telepathy in my N900 looong time ago
<rafael2k>
do you plan to integrate SMS in the stack?
<sicelo>
N900 was the reason I still have a Skype account this day :-)
<sicelo>
s/this/to this/
<rafael2k>
: )
<rafael2k>
mamma mia, how much time I lived without using make menuconfig!
<rafael2k>
so many new stuff
<Wizzup>
rafael2k: yes @ sms
<Wizzup>
sicelo: skype still works? heh
<sicelo>
i use it on laptop and android now :-)
<sicelo>
but i think fremantle still logs in, but calls stopped working years ago, and i think there are issues sending text too, although i can't remember too well anymore
<Wizzup>
right, iirc it doesn't
<sicelo>
ah, doesn't even log in now
<Wizzup>
rafael2k: I am starting to understand tp
<rafael2k>
btw, battery icon is now correctly - it shows full battery!
System_Error has joined #maemo-leste
joerg has quit [Read error: Connection reset by peer]
<rafael2k>
Wizzup: almost there with the kernel... make localyesconfig really helped
joerg has joined #maemo-leste
<Wizzup>
rafael2k: ok, let's see how much bigger it gets?
<Wizzup>
rafael2k: great @ battery
<rafael2k>
Wizzup: the difference will be minimal... I focused on just changing the needed parts to have mtd and video in core kernel... some kilobytes at most
<rafael2k>
starting to compile soon
<rafael2k>
on a next round I can try to remove some modules not needed... but it is really not my priority in a world with cheap 64GB SD cards.
<rafael2k>
I want to keep the diff small to mobian pine64-defconfig, so mantainance will be easy
sunshavi has quit [Ping timeout: 250 seconds]
<rafael2k>
ok, kernel compilation starting, all the patches updated in git