| deathmist | mal: would you mind taking a look at https://github.com/mer-hybris/qt5-qpa-hwcomposer-plugin/pull/95 (hwcomposer: Fix compile errors and warnings under Qt 5.15) and https://github.com/mer-hybris/qt5-qpa-hwcomposer-plugin/pull/96 (Initial support for Qt6) one day? | 00:06 |
|---|---|---|
| mal | deathmist: I was wondering about in which order to include those, those do partially the same thing | 00:32 |
| deathmist | mal: I know, yet the current order causes a compile error somehow on newer versions of Qt5 from what I can gather, feel free to try building it on any other modern distribution than SFOS :p | 01:04 |
| mal | deathmist: yeah, about merging order, since you are here it might make sense to ask you to rebase after merging the Qt6 PR first | 01:17 |
| mal | I will have a look at those tomorrow (well today really) | 01:18 |
| *** amccarthy is now known as Guest2323 | 06:39 | |
| *** amccarthy_ is now known as amccarthy | 06:39 | |
| T42 | <adampigg> @HengYeDev Keyboard now working on PP and PPP | 09:44 |
| Mister_Magister | why not just make VAAPI driver for android? | 12:55 |
| Mister_Magister | instead of gstdroid | 12:55 |
| Mister_Magister | as far as i understand gstdroid stuff is incompatible with anything | 12:58 |
| *** amccarthy is now known as Guest2355 | 13:42 | |
| *** amccarthy_ is now known as amccarthy | 13:42 | |
| piggz | spiiroin: around? | 16:43 |
| piggz | the following log shows the pinephone waking up, setting the panic led becuase it takes too long to turn the display on, then the display turning on | 17:03 |
| piggz | https://hastebin.com/arogucaxur.yaml | 17:03 |
| piggz | kernel dev says there is nothing wrong with the kernel, from the logs, the drm system doesnt get commanded to turn the screen on until after the led panic is triggered | 17:03 |
| piggz | i echoed to the backlight while it was off, and the wallpaper was shown, so that shows that mce is just keeping the display off too long | 17:04 |
| piggz | im open to suggestions :) | 17:04 |
| T42 | <Mister_Magister> don't use mce problem solved | 17:20 |
| piggz | Mister_Magister: as helpful as ever :D | 17:25 |
| Mister_Magister | to your service :) | 17:26 |
| Mister_Magister | i realyl wanna do vaapi driver for droid lol | 17:26 |
| Thaodan | I think gsteamer is more generic than vaapi. | 17:29 |
| Thaodan | But rewriting gst-droid on top of binder would be useful and more stable. | 17:29 |
| Mister_Magister | Thaodan: problem is if you push anything to get encoded/decoded by gst-droid you can't use it in gstreamer anymore | 17:45 |
| Mister_Magister | otherwise simple gstreamer based players would work | 17:46 |
| Mister_Magister | but they don't | 17:46 |
| Mister_Magister | vaapi is way more generic as you can even ffmpeg it | 17:46 |
| Mister_Magister | and i want output of the hw encoding/decoding to be still usable | 17:46 |
| Mister_Magister | for example to first record and encode and then stream it, or reeoncode stuff | 17:46 |
| Mister_Magister | otherwise we have to do dumb weird stuff with droid decoded stuff instead of just playing it using box standard qtmultimedia | 17:47 |
| Thaodan | Mister_Magister: If you're so smart fix it. | 18:32 |
| Mister_Magister | I might | 18:32 |
| spiiroin | piggz: the control flow should be: mce decides that display should be powered on; mce makes "updatesEnabled(true)" call to compositor; compositor powers up screen; compositor sends method reply to mce; mce continues with brightness ramp up etc | 19:52 |
| spiiroin | the panic is triggered by: it takes too long for that reply to arrive | 19:52 |
| piggz | spiiroin: yes ... so, how do we debug? kernel dev says that because i can manually echo the brightness, and it shows the compositor, then that prooves the kernel and drm are working, and problem is in user space | 19:54 |
| piggz | there is a bunch of stuff happening when resuming like BT devices being detected, and network stuff | 19:55 |
| piggz | but sometimes it can take 10s of seconds to resumt | 19:55 |
| spiiroin | it has been a while, but.. "hw compositor plugin" in lipstick process | 19:55 |
| piggz | whats that? | 19:56 |
| spiiroin | i.e. device specific plugin code gets / should get called | 19:56 |
| spiiroin | I'll take a quick peek if I find the place | 19:56 |
| piggz | i wondered if timers could be an issue, as, the kernel debug times that are printed are in no way related to real time that has passed | 19:56 |
| piggz | thx | 19:56 |
| piggz | spiiroin: pick yourself up a pinephone ;) | 19:56 |
| spiiroin | piggz: https://github.com/sailfishos/lipstick/blob/master/src/compositor/lipstickcompositor.cpp#L783 | 19:59 |
| spiiroin | this is the dbus method call handler | 20:00 |
| spiiroin | there are those platformNativeInterface calls -> where actual power control lies | 20:00 |
| spiiroin | couple of random thoughts: that there was that panic -> lipstick potentially blocked somewhere ^ code? | 20:02 |
| spiiroin | and that manual brightness setting changed something -> there might be some (new) kind of exotic dependency on how brightness should be handled during display wakeup | 20:03 |
| piggz | spiiroin: it always comes on (without manually setting the brightness) .. just takes time, and is related to how long the phone has slept for | 20:03 |
| spiiroin | I wonder.. there was a bug like that. but it was years ago. | 20:05 |
| piggz | and might be to do with how the pinephone sleeps ... it goes into a really deep sleep, much more than an android phone | 20:05 |
| piggz | i think | 20:06 |
| spiiroin | ok, so in theory the panic is just triggered too soon | 20:06 |
| * spiiroin was wondering whether that bug that caused display wakeup to take seconds was fixed in-general / for some backends / could it resurface on new hw ... | 20:07 | |
| spiiroin | then again, there have been devices where display drived bugs in kernel caused similar issues | 20:08 |
| spiiroin | e.g. in one case: display power off took ages, but it was noticeable only when attempt to unblank screen was made right after blanking | 20:09 |
| piggz | afaik, on sailfish suffers from this on the PP hardware, probably becuase its the most mature stack with all this mce/dsme gibberish doing good stuff for us :D | 20:10 |
| piggz | for maybe the first hour, display unblank is fine, but after that it gets increasing worse | 20:11 |
| piggz | one time took about 2 mintues! :D | 20:11 |
| spiiroin | I might be completely wrong, but IIRC that compositor side bug ^ had something to do with frames being buffered despite display being off -> at wakeup time there was memory stress or stte | 20:13 |
| spiiroin | I'll see if I find something about it | 20:13 |
| piggz | thanks | 20:13 |
| spiiroin | mal might actually know this side better | 20:13 |
| piggz | thats handy, he had his pinepone powered on yesterday! | 20:14 |
| spiiroin | piggz: that old bug eludes me, but this should be where that platformNativeInterface call from lipstick lands to: https://github.com/mer-hybris/qt5-qpa-hwcomposer-plugin/blob/master/hwcomposer/qeglfsintegration.cpp#L207 | 21:38 |
| mal | spiiroin: in this case device is not using that | 21:39 |
| spiiroin | ok, so there is a new can of worms somewhere ;-) | 21:40 |
| mal | spiiroin: because this device uses native graphics not droid-graphics | 21:40 |
| mal | spiiroin: so a similar plugin in other Qt packages | 21:40 |
| spiiroin | similar, but in different tree. I wonder if it could still suffer from issues fixed in ^ repo? | 21:42 |
| spiiroin | then again, just adding debug logging to qt side code could already confirm whether that suspiciou amount of time is spent in there vs. elsewhere | 21:46 |
| spiiroin | s/qt side/lipstick side/ | 21:46 |
| mal | yeah | 21:48 |
| deathmist | @slavamon about ofono updates for >=1.30 mind taking a look at https://github.com/sailfishos/ofono/pull/25#pullrequestreview-910111531 (the rats test branch from 2020) again one day? | 21:52 |
| piggz | thanks deathmist :) | 21:55 |
| mal | spiiroin: interesting thing I found, eglfs in qtbase doesn't have DisplayOff or DisplayOn at all in nativeResourceForIntegration | 22:03 |
| mal | I wonder how it turns off/on display | 22:04 |
| T42 | <elros34> maybe only via mce /dev/fb0 control | 22:15 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!