| Wizzup | uvos: parazyd: shall we set /proc/sys/vm/stat_interval to 600 in droid4-pm and n900-pm ? | 00:05 |
|---|---|---|
| tmlind | so the reason es2gears_wayland stopped working with wlroots is described in this pending mesa demos pull request: https://gitlab.freedesktop.org/mesa/demos/-/merge_requests/32 | 08:26 |
| tmlind | the branch to use for es2gears_wayland is: https://gitlab.freedesktop.org/kevinoid/demos xdg-shell | 08:26 |
| 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") | 08:28 |
| lad_ | Всем привет, дайте пожалуйста информацию, как установить maemo-leste на N900? | 08:56 |
| lad_ | Hello everyone, please give information how to install maemo-leste on N900? | 09:01 |
| dsc_ | hi lad_ there is some documentation here: https://leste.maemo.org/Nokia_N900 | 09:04 |
| lad_ | Thanks bro | 09:05 |
| dsc_ | пожалуйста | 09:07 |
| lad_ | У вас большая сеть IRC | 09:07 |
| dsc_ | да некоторые пользователи | 09:08 |
| dsc_ | усердно работать) | 09:08 |
| lad_ | Как эта прошивка? Стабильно работает?) | 09:08 |
| dsc_ | да, это стабильно | 09:09 |
| dsc_ | но все равно некоторых программ не хватает | 09:09 |
| lad_ | Установка на флешку? | 09:09 |
| lad_ | Или на основную память? | 09:09 |
| dsc_ | попробуй | 09:09 |
| lad_ | Понятно | 09:09 |
| dsc_ | :D | 09:10 |
| freemangordon | uvos: something got broken in mce (I suppose) recently: | 10:53 |
| freemangordon | 1. lock with vtklock | 10:54 |
| freemangordon | 2. press power button (vtklock to be displayed) | 10:54 |
| freemangordon | 3. unlock | 10:54 |
| freemangordon | 4. press power button again | 10:54 |
| freemangordon | instead of power button menu being shown, device locks again | 10:54 |
| freemangordon | this happens most of the times | 10:55 |
| 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 | 11:06 |
| freemangordon | or, did I get i wrong and my patch shall not be applied? | 11:07 |
| freemangordon | hmm, I guess yes | 11:11 |
| 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 | 11:17 |
| freemangordon | yeah | 11:18 |
| freemangordon | still tears, lemme check dmesg | 11:18 |
| tmlind | ok | 11:18 |
| freemangordon | nothing there! | 11:19 |
| freemangordon | I mean - none of the prontks | 11:19 |
| freemangordon | *printks | 11:19 |
| freemangordon | that's weird, no? | 11:20 |
| freemangordon | tmlind: what is trace_printk? | 11:20 |
| Wizzup | lad_: typically we install on microsd card for now | 11:23 |
| tmlind | freemangordon: assuming tracing is enabled, just do sudo cat /sys/kernel/debug/tracing/trace_pipe | 11:24 |
| freemangordon | ok | 11:25 |
| tmlind | nice for debugging | 11:25 |
| freemangordon | yeah, I see | 11:25 |
| freemangordon | well tearing is still there, but I don;t really see why it should be fixed. | 11:26 |
| tmlind | yeah | 11:26 |
| freemangordon | I mean - why do you expect DSI_VC_TE bit to be set? | 11:27 |
| tmlind | that means there are still bytes in flight to the lcd | 11:27 |
| * freemangordon checks the conditions for this bit to be set | 11:28 | |
| tmlind | it's a counter with two start bits, one for the current update mode and one for te | 11:28 |
| tmlind | freemangordon: it gets configured in dsi_update_screen_dispc() | 11:29 |
| freemangordon | tmlind: IIUC, you expect TE_EN to become zero? | 11:29 |
| freemangordon | but, this is never set to 1 in the first place, unless I miss something | 11:30 |
| freemangordon | ok, lemme think for a while | 11:30 |
| tmlind | TE_START or TE_EN gets used depending on the mode, it gets set | 11:30 |
| freemangordon | yes, and we use TE_START | 11:31 |
| freemangordon | because TE_ENABLED is false in panel data | 11:31 |
| tmlind | correct | 11:31 |
| tmlind | you can monitor the register change with watch -n0.1 sudo rwmem 0x58004104 | 11:31 |
| freemangordon | ok | 11:32 |
| freemangordon | lemme try | 11:32 |
| freemangordon | hmm, no rwmem here :( | 11:32 |
| freemangordon | anyeay, lemme see how is that expected to worl | 11:32 |
| tmlind | try busybox devmem | 11:32 |
| freemangordon | mnm | 11:32 |
| freemangordon | *mhm | 11:32 |
| freemangordon | tmlind: right | 11:34 |
| freemangordon | but, IIUC, we set TE_START at some arbitrary moment, not is sync of panel refresh cycle, no? | 11:34 |
| freemangordon | *not in | 11:34 |
| freemangordon | and because transfer start immediately, we see tearing | 11:35 |
| 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? | 11:35 |
| freemangordon | it is not that we don;t wait for transfer to finish before we start the next one we see that tearing | 11:35 |
| tmlind | we configure VC_TE when we update the LCD | 11:35 |
| freemangordon | no, we don;t | 11:35 |
| freemangordon | because te_enabled is false in panel data | 11:36 |
| 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 | 11:37 |
| freemangordon | tmlind: see dsi_update_screen_dispc | 11:37 |
| freemangordon | if (dsi->te_enabled) ... | 11:37 |
| freemangordon | if te_enabled is false, we configure TE_START | 11:37 |
| freemangordon | not TE_EN | 11:38 |
| tmlind | right | 11:38 |
| tmlind | TE_EN just makes the LCD panel do the transfer after BTA | 11:38 |
| freemangordon | setting TE_START means "start immediately" if I get this right | 11:38 |
| tmlind | also with TE_EN set dsi_vc_send_bta() makes the LCD panel controller start the transfer | 11:39 |
| freemangordon | I think TE_EN means "start transfer after conditions set in xSYNC registers are set" | 11:39 |
| freemangordon | yes | 11:39 |
| freemangordon | anyway, my point is that we have issues with transfer start | 11:40 |
| freemangordon | because we start it in the middle of panel refresh cycle | 11:40 |
| tmlind | yeah it's possible if the LCD panel controller is supposed to wait something after TE_EN | 11:41 |
| freemangordon | I still don;t understand why TE_EN given that we use TE_START | 11:41 |
| freemangordon | like, if we use TE IRQ, TE_START is set by the HW | 11: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 | 11:42 |
| freemangordon | if we set it manually (which we do) transfer starts immediately | 11:42 |
| tmlind | freemangordon: seems the te gpio case is different from the bus controlled te | 11:43 |
| freemangordon | the only difference I see is who generates the irq | 11:44 |
| freemangordon | PHY vs gpio | 11:44 |
| freemangordon | but maybe I am missing something | 11:45 |
| tmlind | well the phy irq triggers right after the bta, but maybe that's only if the sync regs are not programmed | 11:45 |
| freemangordon | most-probably | 11:45 |
| freemangordon | as for sure vendor kernel does that (programming sync regs) | 11:45 |
| freemangordon | also, it programs 'te scan line' | 11:46 |
| tmlind | yeah but it might be also just left over stuff from the te cmos mode, easy to check though | 11:46 |
| tmlind | i'll see if the te irq triggers later after configuring the scan regs | 11:47 |
| freemangordon | I doubt, as vendor panel driver has some special handling for one of the displays, where cmos mode is used | 11:47 |
| tmlind | ok | 11:47 |
| tmlind | let's hope your theory is correct, then we would get a proper irq after te is done | 11:48 |
| freemangordon | mhm | 11:48 |
| tmlind | not sure what's broken with enabling te as the te interrupt stops happening pretty fast | 11:48 |
| freemangordon | but it happens, right? | 11:49 |
| tmlind | yeah, for up to two mins, often for just few tens of secs | 11:49 |
| freemangordon | well, then we misconfigure something | 11:49 |
| freemangordon | could be something in the panel though | 11:49 |
| tmlind | sometimes there are signaling errors in the complexio regs | 11:49 |
| freemangordon | vendor driver send ~ 15 commends on init | 11:49 |
| freemangordon | *commands on | 11:50 |
| tmlind | yeah | 11:50 |
| * freemangordon needs more coffee :) | 11:50 | |
| 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 :) | 11:51 |
| freemangordon | tmlind: I still think we don;t have issues with unfinished transfers | 11:56 |
| freemangordon | but with our transfer start being in the middle of the panel internal transfer cycle | 11:56 |
| freemangordon | s/transfer/refresh | 11:56 |
| 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 | 11:59 |
| Wizzup | sure, np | 12:05 |
| 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 | 13:06 |
| Wizzup | freemangordon: no, not yet @ ioctl hangs | 13:13 |
| freemangordon | ok | 13:13 |
| Wizzup | freemangordon: btw kernel in repo has a fix for charging, please test when you can | 13:13 |
| freemangordon | ok | 13:14 |
| freemangordon | tmlind: hmm, see https://pastebin.com/4dgz4WuZ . this comment is in dsi_framedone_irq_callback in vendor kernel | 13:15 |
| freemangordon | seems we need BTA on framedone to receive TE | 13:16 |
| freemangordon | which kind of makes sense | 13:16 |
| tmlind | freemangordon: we already do the "more optimal" part described in the comments, see dsi_send_nop() | 13:38 |
| freemangordon | ok | 13:38 |
| tmlind | did not have any luck making the te interrupt happen later by maxing out the sync regs | 13:39 |
| freemangordon | I will try sending all those commands to panel later on | 13:39 |
| freemangordon | btw, do you know which is the exact pane model we are talking about (in vendor kernel terms)? | 13:40 |
| freemangordon | there are basically 5 different variants it seems | 13:41 |
| freemangordon | one of them being MOT_DISP_MIPI_CM_430_540_960_AMOLED and this one needs special massaging for TE to happen | 13:42 |
| freemangordon | I guess I will have to trace the panel id | 13:43 |
| 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 | 13:43 |
| tmlind | panel_id=0x90004 in stock dtb, add leading zeros when grepping the stock kernel | 13:48 |
| freemangordon | thanks | 13:48 |
| tmlind | freemangordon: MOT_DISP_MIPI_CM_400_540_960 | 13:49 |
| freemangordon | thanks | 13:49 |
| Guest23 | good luck guys you are producing extraordinary work | 14:03 |
| freemangordon | tmlind: should be dsi_mipi_cm_400_540_960_m2_v1_panel_enable | 14:08 |
| Wizzup | Guest23: thanks :) | 14:08 |
| freemangordon | and we have a comment saying /* MIPI TE Drop out fix */ | 14:08 |
| freemangordon | tmlind: :D | 14:48 |
| freemangordon | no tearing!!! | 14:48 |
| freemangordon | with panel init commands from vendor kernel it works | 14:50 |
| freemangordon | tmlind: https://pastebin.com/0v32GPpu | 14:59 |
| freemangordon | not sure both parts of vendor init are needed | 14:59 |
| Wizzup | mvp :p | 15:01 |
| freemangordon | hmm? | 15:01 |
| Wizzup | most valued person, it was a joke :) | 15:02 |
| freemangordon | ah | 15:02 |
| freemangordon | :) | 15:02 |
| freemangordon | tmlind: with that working maybe your vsync patch is not needed anymore? | 15:08 |
| BlagovestPetrov[ | Hey, guys | 15:31 |
| BlagovestPetrov[ | i'm trying to install the boot loader to Droid 3 | 15:31 |
| BlagovestPetrov[ | https://www.toptal.com/developers/hastebin/izeweyotat.yaml | 15:31 |
| BlagovestPetrov[ | it roots successfully | 15:32 |
| BlagovestPetrov[ | but this happens when I try to execute install.sh | 15:32 |
| Wizzup | BlagovestPetrov[: hmmm I recall seeing that before | 15:35 |
| Wizzup | I am going to have to try really hard to remember what I did there | 15:35 |
| BlagovestPetrov[ | I may try to do it manually :) | 15:35 |
| BlagovestPetrov[ | copying the files, etc | 15:35 |
| 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 | 15:36 |
| BlagovestPetrov[ | yeah | 15:36 |
| Wizzup | iirc -o remount,rw or something didn't work and I had to try something else | 15:37 |
| Wizzup | trying to search the logs | 15:38 |
| Wizzup | BlagovestPetrov[: I think it needs to be this: | 15:39 |
| Wizzup | 20:09 < Wizzup> mount -o remount,rw /dev/block/system /system | 15:39 |
| Wizzup | unless that is already in install.sh | 15:39 |
| Wizzup | yeah nope | 15:39 |
| Wizzup | try putting that there instead of adb shell "su -c 'mount -o remount,rw /system'" | 15:39 |
| Wizzup | so: | 15:40 |
| Wizzup | adb shell "su -c 'mount -o remount,rw /dev/block/system /system'" | 15:40 |
| tmlind | freemangordon: cool so that fixed your tearing test case? | 16:03 |
| BlagovestPetrov[ | sorry, here :) | 16:06 |
| BlagovestPetrov[ | thanks | 16:07 |
| BlagovestPetrov[ | the same happened and the phone stuck on boot logo. I'll try to do it line by line :) | 16:11 |
| tmlind | freemangordon: yeah i wonder if the sync registers actually generate a real vblank interrupt? | 16:13 |
| BlagovestPetrov[ | now Android is permanently stuck on the boot logo. I will need the stock image | 16:28 |
| Wizzup | do you need me to share a link to it? | 16:29 |
| BlagovestPetrov[ | Wizzup: the pushes were put before the mounts in the script. It looks like the main issue :) | 16:29 |
| BlagovestPetrov[ | sure, if you have it somewhere | 16:29 |
| BlagovestPetrov[ | does it work with fastboot on Droid 3? | 16:30 |
| BlagovestPetrov[ | some of the older androids were using other tools | 16:30 |
| Wizzup | BlagovestPetrov[: I think you need VRZ_XT862_5.5.1_84_D3G-55_1FF_01.xml.zip right? | 16:31 |
| tmlind | freemangordon: nice, i'm not seeing any timeouts with your te patch :) | 16:33 |
| BlagovestPetrov[ | I'm not sure | 16:33 |
| BlagovestPetrov[ | yeah, it's mentioned in the readme :) | 16:34 |
| Wizzup | BlagovestPetrov[: ok let me look at scp'ing it, make sure you know how to flash it | 16:36 |
| Wizzup | arg maedevu has so little free space | 16:37 |
| BlagovestPetrov[ | for the fastboot to work, the phone should be in bootloader? | 16:37 |
| BlagovestPetrov[ | I just don't get why we need the xml | 16:37 |
| Wizzup | it's just called .xml.zip | 16:38 |
| Wizzup | so are there instructions on how to flash it to the droid3 on the wiki or so? | 16:38 |
| Wizzup | doesn't look like there are any | 16:38 |
| Wizzup | ah I have a script | 16:39 |
| Wizzup | 10 ins | 16:40 |
| Wizzup | 10 mins* | 16:40 |
| BlagovestPetrov[ | ok :) | 16:42 |
| 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 | 16:56 |
| freemangordon | or could be another issue | 16:56 |
| Wizzup | BlagovestPetrov[: https://maedevu.maemo.org/images-devel/droid3/ - see sh script and zip | 17:01 |
| Wizzup | droid3 instructions are likely similar to the droid4 ones here https://leste.maemo.org/Motorola_Droid_4#Updating_Android but I will need to test it out to verify for sure | 17:01 |
| BlagovestPetrov[ | thanks :) | 17:02 |
| tmlind | freemangordon: interesting, i'll test locally instead of my rack setup with wlroots if i get a chance tonight | 17:24 |
| tmlind | no real vblank interrupts triggering | 17:25 |
| tmlind | freemangordon: did the dbm patch work ok for you? | 17:26 |
| 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 | 17:29 |
| tmlind | freemangordon: also check if adding cpu load with dd if=/dev/urandom of=/dev/null makes the tearing reappear? | 17:30 |
| tmlind | as that will cause dsi to always have data in flight on framedone probably as cpu does not idle | 17:31 |
| freemangordon | tmlind: ok | 17:35 |
| freemangordon | but, isn;t it doing DMA? why CPU? | 17:35 |
| tmlind | no idea.. | 17:36 |
| tmlind | maybe faster response to interrupts with no idle? | 17:36 |
| BlagovestPetrov[ | Wizzup: it's my fault. The script is using /sdcard but I already flashed maemo there :) | 17:37 |
| freemangordon | tmlind: BTW, I need that panel driver needs proper quirk handling, like panel specific enable function to be called | 17:38 |
| Wizzup | BlagovestPetrov[: ah, yeah, try withotu sdcard inserted | 17:40 |
| BlagovestPetrov[ | sure :) | 17:40 |
| freemangordon | tmlind: no tearing with 'dd if=/dev/urandom of=/dev/null' | 17:43 |
| freemangordon | but, I see tearing when vkb pops, that's why I think it must be related with drmDirtyFb call somehow | 17:45 |
| tmlind | ok | 17:45 |
| freemangordon | hmm, if I disable drmDirtyFb calls in DDX, there is absolutely no tearing | 17:47 |
| tmlind | ok | 17:48 |
| freemangordon | but, we are missing repaint, ofc | 17:48 |
| freemangordon | lemme revert vblank patch and see how itwill behave without it | 17:48 |
| * tmlind reboots d4 without the vblank emulation patch | 17:48 | |
| freemangordon | oh, with this TE change hildon swipe fps is limited to 60 :) | 18:01 |
| freemangordon | like on android (as uvos said) | 18:01 |
| freemangordon | tmlind: I don;t think TE can replace vsync - in order to have TE irq you need to queue transfer | 18:04 |
| freemangordon | in order to queue transfer, you need drmDirtyFb | 18:04 |
| freemangordon | tmlind: oh, with vblank patch reverted I no longer see that ugly 'flashing' when rotating landscape<->portrait | 18:08 |
| Wizzup | oooh that'd be nice | 18:09 |
| freemangordon | hmm, actually I still see it | 18:09 |
| freemangordon | somehow it got better | 18:10 |
| tmlind | freemangordon: weird, with your te fix or some other earlier fix things mostly work for me with wlroots without the vblank emulation patch | 18:33 |
| 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 | 18:34 |
| freemangordon | yeah, I think we shall drop vblank patch assuming that userspace is smart enough to know to call drmDirtyFb or somesuch | 18:35 |
| tmlind | ack | 18:35 |
| freemangordon | tmlind: well, it could be that it is not 'my' mesa, but 'upstream' mesa at fault here | 18:35 |
| tmlind | hmm looks like weston-simple-shm has some stripes in it's window, that's about the only issue i now notice | 18:35 |
| freemangordon | as I did nothing more but to RE what was already in pvr_dri.so | 18:36 |
| tmlind | maybe there's some debug or tracing option enabled now? | 18:36 |
| freemangordon | in mesa? | 18:36 |
| tmlind | yeah | 18:37 |
| uvos | freemangordon: android behavior is actually kinda wierd on this | 18:37 |
| freemangordon | none I am aware of | 18:37 |
| uvos | freemangordon: yeah the genneraly ui is limited to 60 fps | 18:37 |
| freemangordon | but? | 18:37 |
| uvos | freemangordon: but some vsynced games run at ~70 | 18:37 |
| freemangordon | well, what I see here is that h-d swipes (and refreshes) @ 60 | 18:37 |
| uvos | ok | 18:37 |
| uvos | anyhow | 18:38 |
| freemangordon | but gears and glmark render with > 60 | 18:38 |
| uvos | regarding power menu on vtklock | 18:38 |
| uvos | i think this might be the fault of the patch that makes vtklock hold a grab | 18:38 |
| freemangordon | are you able to reproduce? | 18:38 |
| uvos | havent tried yet | 18:38 |
| uvos | but | 18:38 |
| freemangordon | ok | 18:38 |
| uvos | the other "context" menu type windows are raised by grab transfer | 18:38 |
| uvos | a grab transfer is impossible if vtklock holds a grab | 18:39 |
| freemangordon | uvos: the actual issue is that device relocks in 2 seconds | 18:39 |
| uvos | oh ok | 18:39 |
| freemangordon | no matter if you press power button or not | 18:39 |
| uvos | i thought you siad that its impossible to open power menu | 18:39 |
| uvos | so how do you tigger this? | 18:39 |
| freemangordon | well, that6's how I initially hit that | 18:39 |
| uvos | let me activate tklock again and reboot | 18:39 |
| freemangordon | the same, just does not press th epower button | 18:40 |
| tmlind | with wlroots i also see es2gears_wayland run at 60 fps | 18:40 |
| freemangordon | uvos: I would recomment you to have a second uSD with vanilla leste on it | 18:40 |
| freemangordon | *recommend | 18:40 |
| uvos | freemangordon: hm so lock the device with tklock? | 18:40 |
| uvos | freemangordon: and then what? | 18:40 |
| uvos | freemangordon: press power? | 18:40 |
| freemangordon | yes | 18:40 |
| freemangordon | and then swipe | 18:40 |
| freemangordon | to unlock | 18:40 |
| freemangordon | most of the times it shows desktop for 1-2 seconds and then display gets dark (device gets locked) | 18:41 |
| uvos | what have you set as what in mce.ini | 18:41 |
| uvos | power key wise | 18:42 |
| freemangordon | no idea, like, whatever is set by you | 18:42 |
| freemangordon | I have changed nothing | 18:42 |
| freemangordon | lemme try to boot leaste, as I was charging in android :p | 18:42 |
| uvos | the charging problem shout be fixed for you | 18:42 |
| uvos | ofc i cant test | 18:43 |
| freemangordon | yeah | 18:43 |
| uvos | since i cant repo | 18:43 |
| uvos | it is? | 18:43 |
| freemangordon | that's the next thing | 18:43 |
| uvos | ok | 18:43 |
| freemangordon | didn;t test yet | 18:43 |
| uvos | o | 18:43 |
| uvos | k | 18:43 |
| freemangordon | will capture a video for you to see what happens | 18:43 |
| uvos | ok so tklock problem dosent show here | 18:45 |
| uvos | but i allways change PowerKeyShortAction=tklock | 18:45 |
| uvos | because i dont like that the power key changes behavior depending on lock state | 18:45 |
| uvos | let me undo that and restart mce... | 18:46 |
| freemangordon | https://pastebin.com/WcbGmjWv | 18:46 |
| freemangordon | mce.ini | 18:46 |
| uvos | hmm | 18:47 |
| uvos | so i reset mce back to defaults | 18:47 |
| uvos | i open power menu and lock the device there | 18:47 |
| uvos | then i press power once | 18:47 |
| uvos | then vtklock opens | 18:47 |
| uvos | then i press power again | 18:47 |
| uvos | nothing happens | 18:47 |
| uvos | then i unlock via slider | 18:47 |
| uvos | and nothing ususal happend | 18:48 |
| uvos | dispaly is still on | 18:48 |
| uvos | was that the right sequence? | 18:48 |
| freemangordon | doesn;t happen every time | 18:48 |
| freemangordon | lemme capture a video for you | 18:48 |
| uvos | can you repo it | 18:49 |
| freemangordon | yes | 18:49 |
| uvos | while running mce with --verbose --verbose | 18:49 |
| uvos | ie sudo su - | 18:49 |
| freemangordon | just captured a video | 18:49 |
| uvos | /etc/init.d/mce stop | 18:49 |
| freemangordon | lemme give you the video first | 18:49 |
| uvos | mce --verbose --verbose | 18:49 |
| uvos | that way we know what state mce is in | 18:49 |
| uvos | (It prints its global state) | 18:49 |
| tmlind | freemangordon: glmark2-es-wayland score 143 fyi | 18:49 |
| uvos | so your repoing this on a mapphone, right? | 18:50 |
| uvos | since it might be timing related | 18:50 |
| freemangordon | d4 | 18:50 |
| uvos | ok | 18:50 |
| freemangordon | tmlind: no way | 18:50 |
| freemangordon | tmlind: what is the fps on jellyfish, for example? | 18:51 |
| tmlind | freemangordon: glmark-es2-wayland --size 960x540 --benchmark jellyfish score is 54 - 56, fullscreen | 18:52 |
| freemangordon | uvos: http://46.249.74.23/leste/d4/20220116_001.mp4 | 18:57 |
| freemangordon | @ 1:10 | 18:57 |
| freemangordon | tmlind: I don't see how wayland can do 2x drm | 18:57 |
| freemangordon | this is simply not possible IMO | 18:57 |
| freemangordon | unless sgx freq on your device is 2x compared to mine :) | 18:58 |
| tmlind | well glmark2 terrain score is still 2 so unlikely :) | 18:58 |
| freemangordon | 2? | 18:58 |
| freemangordon | it is 1 here | 18:59 |
| tmlind | hehe | 18:59 |
| tmlind | do you have some test script that slows down the sgx rate still? | 18:59 |
| freemangordon | so, I would say something is broken in fps calculation in -wayland | 18:59 |
| tmlind | heh maybe | 18:59 |
| freemangordon | uvos: again, I really think you shall have second uSD to boot vanilla leste | 19:00 |
| uvos | freemangordon: so at 1:10 you lock the device and unlock it via slider then you (double?) press the power button, and it locks again | 19:00 |
| freemangordon | no | 19:01 |
| freemangordon | I press nothing | 19:01 |
| freemangordon | but it locks again | 19:01 |
| uvos | you clearly press the powerbutton again in the video | 19:01 |
| freemangordon | do you see how the screen somehow 'flashes' after I unlock | 19:01 |
| freemangordon | no, it is my finger there, but I actually do not press | 19:02 |
| freemangordon | also, somethimes single-clock gets ignore | 19:02 |
| freemangordon | oh, sorry, I have mce stopped ATM | 19:02 |
| uvos | fine let me flash sd | 19:03 |
| uvos | what is this on | 19:03 |
| uvos | devel or stable? | 19:03 |
| freemangordon | -devel | 19:03 |
| freemangordon | tmlind: glmark2 Score: 86, this is with Xorg (so blit) | 19:03 |
| tmlind | ok | 19:03 |
| freemangordon | -drm is vsynced @ 58 :D | 19:04 |
| freemangordon | dinner, ttyl | 19:04 |
| tmlind | later | 19:05 |
| uvos | freemangordon: ok so i see an issue | 19:06 |
| uvos | but its a different one | 19:06 |
| uvos | i gues | 19:07 |
| uvos | so if i have vtklock open | 19:07 |
| uvos | and click power once just after closing tklock | 19:07 |
| uvos | via slider | 19:07 |
| uvos | the device display is turned off again and it locks | 19:07 |
| uvos | instead of showing the power menu | 19:07 |
| uvos | this is an obvious race | 19:07 |
| uvos | if you close tklock and press the power button before mce gets the dbus message, it thinks its in tklock mode | 19:08 |
| uvos | so it shuts off the display on single press | 19:08 |
| uvos | let me repoduce this on fremantle | 19:08 |
| uvos | should have the same issue (maybe different timeing) | 19:08 |
| uvos | actually the difference is probubly xinput | 19:10 |
| uvos | xinput state stuff takes pretty long | 19:10 |
| uvos | so mce lags behind more | 19:10 |
| uvos | yeah that happens on fremantle too | 19:13 |
| uvos | except you have to press power way faster after closing tklock | 19:13 |
| uvos | as expected | 19:13 |
| uvos | so probubly what happens here is: | 19:14 |
| uvos | the tklock mce state isents tightly syncronized at all | 19:14 |
| uvos | so we are in tklock | 19:14 |
| uvos | you dissmiss tklock via slider | 19:15 |
| uvos | then by chance the tklock relock timer expires in mce | 19:15 |
| uvos | before mce manages to update its state from the dbus message | 19:15 |
| uvos | and the device relocks | 19:15 |
| uvos | this happens on fremantle to | 19:16 |
| uvos | but our mce is mutch slower beacuse it dose way more, and waits on xorg to respond on xinput calls | 19:16 |
| uvos | so it happens way more often | 19:16 |
| uvos | yeah you can see the mce state change in the log | 19:18 |
| uvos | it laggs behind some | 19:18 |
| uvos | maybe half a second or so | 19:18 |
| uvos | if the timer expires in this time or you press power button what you describe happens | 19:18 |
| freemangordon | uvos: ok, but this has to be fixed, as it is really annoying | 19:22 |
| uvos | sure | 19:23 |
| freemangordon | and actually makes the device useless, as you are unable to unlock sometimes even after 10 or so tries | 19:23 |
| uvos | wierd i cant even make it happen via the timer | 19:23 |
| uvos | at all | 19:23 |
| uvos | anyhow | 19:23 |
| uvos | this is racy for sure | 19:23 |
| uvos | so the fix requires systemui to not close tklock | 19:23 |
| freemangordon | uvos: lemme get mce logs, maybe this is another issue I see here | 19:24 |
| uvos | untill mce signals that its ready | 19:24 |
| uvos | or really we should rethink this entire thing | 19:24 |
| uvos | becasue its a mess thats just asking to be racy | 19:24 |
| uvos | with the required tight sync between mce and tklock/systemui | 19:24 |
| freemangordon | well, it already has callbacks and such, maybe there is a bug in vtklock | 19:25 |
| uvos | or mce, its possible a wait should be there i havent looked at the code again for this bug | 19:25 |
| freemangordon | but lets see if mce performs correctly | 19:25 |
| uvos | and wont tonight | 19:25 |
| uvos | any ttyl | 19:25 |
| freemangordon | later | 19:25 |
| uvos | *anyhow | 19:25 |
| uvos | actually if there is a wait allready | 19:27 |
| uvos | its broken in fremantle too | 19:27 |
| uvos | since you can cause the out of sync issue there too | 19:27 |
| uvos | now really ttyl | 19:27 |
| freemangordon | never seen on fremantle | 19:27 |
| uvos | you can make it happen | 19:27 |
| uvos | unlock via slider | 19:27 |
| uvos | and then click power immidatly | 19:28 |
| freemangordon | and I am using vtklock for the last >10 years | 19:28 |
| freemangordon | lemme try | 19:28 |
| uvos | you breifly see the desktop | 19:28 |
| freemangordon | and then power menu | 19:28 |
| uvos | and then the device locks instead of power menu | 19:28 |
| freemangordon | just tried, lemme try harder | 19:28 |
| uvos | so same issue exists | 19:28 |
| uvos | mce is just faser | 19:28 |
| uvos | (known issue on mce now being a bit slow) | 19:28 |
| freemangordon | ok, we have to make it faster, it doesn;t make sens mco on d4 to be slower than mce on n900 | 19:29 |
| freemangordon | *mce | 19:29 |
| uvos | sure we should make it faster | 19:29 |
| freemangordon | leste vs fremantle that is | 19:29 |
| uvos | but thats not the real issue | 19:29 |
| uvos | we should also fix the race | 19:29 |
| freemangordon | mhm | 19:30 |
| freemangordon | uvos: https://pastebin.com/ywFJiQbH mce logs | 19:32 |
| bencoh | I think there used to be a "visible desktop" bug in tklock on fremantle a long time ago | 19:44 |
| bencoh | but I might be misremembering | 19:44 |
| tmlind | freemangordon: i'll do a droid4-pending-pvr-omapdrm-v5.16 branch after you've sent out your te fix | 19:54 |
| tmlind | i wonder if some of the panel configuration commands are same as in the ILI9488-ILITEK.pdf i found online | 19:56 |
| tmlind | it has "5.3.42. Adjust Control 6 (FCh)" for reg 0xfc | 19:58 |
| freemangordon | tmlind: I was not planning to send a patch for that: | 20:01 |
| freemangordon | IMO driver needs to be extended to support panel quirks and I don;t feels capable of doing so cleanly | 20:02 |
| 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 :) | 20:04 |
| freemangordon | *this is not going to | 20:04 |
| freemangordon | tmlind: hmm, ILI9488-ILITEK.pdf - how is that related to mapphone panel? | 20:05 |
| tmlind | freemangordon: i don't think that is related, but has at least some documentation on the dsi command mode | 20:10 |
| freemangordon | ah, ok | 20:10 |
| tmlind | freemangordon: your patch, you fix it and send it :p | 20:11 |
| freemangordon | well... | 20:11 |
| freemangordon | what I did was just a quick hack | 20:11 |
| freemangordon | this is not a proper patch | 20:11 |
| freemangordon | so, I will do, but in a month or so | 20:12 |
| tmlind | fine | 20:12 |
| tmlind | how about type up some description for it and i'll do droid4-pending-pvr-omapdrm-v5.16? | 20:13 |
| freemangordon | maybe | 20:14 |
| freemangordon | not now though | 20:15 |
| rafael2k | anyone has a copy of xmonobut? | 20:18 |
| 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 | 20:36 |
| tmlind | freemangordon: here's the branch, maybe check i did not forget anything: https://github.com/tmlind/linux_openpvrsgx/commits/droid4-pending-pvr-omapdrm-v5.16 | 20:37 |
| freemangordon | tmlind: ok, will do tomorrow | 20:44 |
| rafael2k | found! and it still works! https://github.com/rafael2k/xmonobut | 20:45 |
| tmlind | freemangordon: ok thanks | 20:45 |
| Wizzup | rafael2k: how did it go with the kernel? | 21:02 |
| lel | IMbackK closed an issue: https://github.com/maemo-leste/bugtracker/issues/577 (N900 touchscreen is broken with latest -devel hildon-desktop) | 21:12 |
| tmlind | looks like the modem stuff has some issue merged into v5.16, need to continue looking at it tomorrow night.. ttyl | 21:25 |
| rafael2k | Wizzup: working on it right now | 21:27 |
| rafael2k | Wizzup: using it indeed... just need to play a bit with menuconfig... fininshing the rebase to 5.15.13 | 21:27 |
| rafael2k | Wizzup: make it boot without initramdisk and voila | 21:28 |
| rafael2k | btw, did ofono made its way? | 21:30 |
| rafael2k | I did not see it upgraded yet | 21:36 |
| rafael2k | already rebased: https://github.com/rafael2k/pine64-kernel/tree/maemo/beowulf-devel | 21:44 |
| rafael2k | now just need to play with config (kind of no-brainer to me this... but moving ahead) | 21:44 |
| rafael2k | btw, is this alarm / phone off-on-off workflow you mentioned as the reason for not having a initrd works on pinephone? | 21:47 |
| rafael2k | Wizzup: lemme know how ofono package update is going, in case of any help needed... | 21:48 |
| 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 | 21:55 |
| freemangordon | also, device was started with charger connected, but it was not detected, I had to re-connect the cable | 21:55 |
| Wizzup | rafael2k: make it boot - made it boot? | 21:55 |
| freemangordon | connecting charger does not unlock the device | 21:56 |
| Wizzup | rafael2k: will look at ofono once kernel is ok :) | 21:56 |
| freemangordon | tmlind: btw, with vblank patch reverted, I no longer see "atomic complete timeout (pipe 0)!" messages | 21:59 |
| rafael2k | Wizzup: :( | 22:00 |
| rafael2k | Wizzup: does not makes sense, but anyway... | 22:01 |
| rafael2k | Wizzup: not like the kernel, ofono is ready to go "upstream" | 22:03 |
| rafael2k | Wizzup: I mean, kernel is ready... apart of this specificity of maemo not wanting initrd... thing I'm working right now | 22:06 |
| 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? | 22:07 |
| 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 | 22:22 |
| Wizzup | rafael2k: will try to get to it real soon | 22:22 |
| Wizzup | rafael2k: been focussing on the telepathy stack | 22:22 |
| rafael2k | Wizzup: -devel kernel was broken, but otherwise kernel 5.10 had telephony enabled and working | 22:29 |
| rafael2k | Wizzup: cool! | 22:30 |
| rafael2k | Wizzup: telepathy seems a monster to work with... | 22:30 |
| rafael2k | I remember to have skype on telepathy in my N900 looong time ago | 22:37 |
| rafael2k | do you plan to integrate SMS in the stack? | 22:38 |
| sicelo | N900 was the reason I still have a Skype account this day :-) | 22:38 |
| sicelo | s/this/to this/ | 22:39 |
| rafael2k | : ) | 22:39 |
| rafael2k | mamma mia, how much time I lived without using make menuconfig! | 22:39 |
| rafael2k | so many new stuff | 22:39 |
| Wizzup | rafael2k: yes @ sms | 22:40 |
| Wizzup | sicelo: skype still works? heh | 22:40 |
| sicelo | i use it on laptop and android now :-) | 22:40 |
| 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 | 22:41 |
| Wizzup | right, iirc it doesn't | 22:41 |
| sicelo | ah, doesn't even log in now | 22:42 |
| Wizzup | rafael2k: I am starting to understand tp | 22:45 |
| rafael2k | btw, battery icon is now correctly - it shows full battery! | 22:49 |
| rafael2k | Wizzup: almost there with the kernel... make localyesconfig really helped | 23:16 |
| Wizzup | rafael2k: ok, let's see how much bigger it gets? | 23:26 |
| Wizzup | rafael2k: great @ battery | 23:26 |
| 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 | 23:28 |
| rafael2k | starting to compile soon | 23:28 |
| 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. | 23:30 |
| rafael2k | I want to keep the diff small to mobian pine64-defconfig, so mantainance will be easy | 23:31 |
| rafael2k | ok, kernel compilation starting, all the patches updated in git | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!