Wednesday, 2022-11-23

deathmistmal: would you mind taking a look at (hwcomposer: Fix compile errors and warnings under Qt 5.15) and (Initial support for Qt6) one day?00:06
maldeathmist: I was wondering about in which order to include those, those do partially the same thing00:32
deathmistmal: 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 :p01:04
maldeathmist: yeah, about merging order, since you are here it might make sense to ask you to rebase after merging the Qt6 PR first01:17
malI will have a look at those tomorrow (well today really)01:18
*** amccarthy is now known as Guest232306:39
*** amccarthy_ is now known as amccarthy06:39
T42<adampigg> @HengYeDev Keyboard now working on PP and PPP09:44
Mister_Magisterwhy not just make VAAPI driver for android?12:55
Mister_Magisterinstead of gstdroid12:55
Mister_Magisteras far as i understand gstdroid stuff is incompatible with anything12:58
*** amccarthy is now known as Guest235513:42
*** amccarthy_ is now known as amccarthy13:42
piggzspiiroin: around?16:43
piggzthe 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 on17:03
piggzkernel 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 triggered17:03
piggzi 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 long17:04
piggzim open to suggestions :)17:04
T42<Mister_Magister> don't use mce problem solved17:20
piggzMister_Magister: as helpful as ever :D17:25
Mister_Magisterto your service :)17:26
Mister_Magisteri realyl wanna do vaapi driver for droid lol17:26
ThaodanI think gsteamer is more generic than vaapi.17:29
ThaodanBut rewriting gst-droid on top of binder would be useful and more stable.17:29
Mister_MagisterThaodan: problem is if you push anything to get encoded/decoded by gst-droid you can't use it in gstreamer anymore17:45
Mister_Magisterotherwise simple gstreamer based players would work17:46
Mister_Magisterbut they don't17:46
Mister_Magistervaapi is way more generic as you can even ffmpeg it17:46
Mister_Magisterand i want output of the hw encoding/decoding to be still usable17:46
Mister_Magisterfor example to first record and encode and then stream it, or reeoncode stuff17:46
Mister_Magisterotherwise we have to do dumb weird stuff with droid decoded stuff instead of just playing it using box standard qtmultimedia17:47
ThaodanMister_Magister:  If you're so smart fix it.18:32
Mister_MagisterI might18:32
spiiroinpiggz: 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 etc19:52
spiirointhe panic is triggered by: it takes too long for that reply to arrive19:52
piggzspiiroin: 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 space19:54
piggzthere is a bunch of stuff happening when resuming like BT devices being detected, and network stuff19:55
piggzbut sometimes it can take 10s of seconds to resumt19:55
spiiroinit has been a while, but.. "hw compositor plugin" in lipstick process19:55
piggzwhats that?19:56
spiiroini.e. device specific plugin code gets / should get called19:56
spiiroinI'll take a quick peek if I find the place19:56
piggzi 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 passed19:56
piggzspiiroin: pick yourself up a pinephone ;)19:56
spiirointhis is the dbus method call handler20:00
spiirointhere are those platformNativeInterface calls -> where actual power control lies20:00
spiiroincouple of random thoughts: that there was that panic -> lipstick potentially blocked somewhere ^ code?20:02
spiiroinand that manual brightness setting changed something -> there might be some (new) kind of exotic dependency on how brightness should be handled during display wakeup20:03
piggzspiiroin: it always comes on (without manually setting the brightness) .. just takes time, and is related to how long the phone has slept for20:03
spiiroinI wonder.. there was a bug like that. but it was years ago.20:05
piggzand might be to do with how the pinephone sleeps ... it goes into a really deep sleep, much more than an android phone20:05
piggzi think20:06
spiiroinok, so in theory the panic is just triggered too soon20: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
spiirointhen again, there have been devices where display drived bugs in kernel caused similar issues20:08
spiiroine.g. in one case: display power off took ages, but it was noticeable only when attempt to unblank screen was made right after blanking20:09
piggzafaik, 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 :D20:10
piggzfor maybe the first hour, display unblank is fine, but after that it gets increasing worse20:11
piggzone time took about 2 mintues! :D20:11
spiiroinI 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 stte20:13
spiiroinI'll see if I find something about it20:13
spiiroinmal might actually know this side better20:13
piggzthats handy, he had his pinepone powered on yesterday!20:14
spiiroinpiggz: that old bug eludes me, but this should be where that platformNativeInterface call from lipstick lands to:
malspiiroin: in this case device is not using that21:39
spiiroinok, so there is a new can of worms somewhere ;-)21:40
malspiiroin: because this device uses native graphics not droid-graphics21:40
malspiiroin: so a similar plugin in other Qt packages21:40
spiiroinsimilar, but in different tree. I wonder if it could still suffer from issues fixed in ^ repo?21:42
spiirointhen again, just adding debug logging to qt side code could already confirm whether that suspiciou amount of time is spent in there vs. elsewhere21:46
spiiroins/qt side/lipstick side/21:46
deathmist@slavamon about ofono updates for >=1.30 mind taking a look at (the rats test branch from 2020) again one day?21:52
piggzthanks deathmist :)21:55
malspiiroin: interesting thing I found, eglfs in qtbase doesn't have DisplayOff or DisplayOn at all in nativeResourceForIntegration22:03
malI wonder how it turns off/on display22:04
T42<elros34> maybe only via mce /dev/fb0 control22:15

Generated by 2.17.1 by Marius Gedminas - find it at!