| Wizzup | ok so voiceCallsChanged is called and it's clear the call ends if the remote party hangs up before we even pick up | 00:28 |
|---|---|---|
| Wizzup | but statusChanged is never called for the MaemoCallHandler | 00:28 |
| Wizzup | this is a oneliner I think | 00:31 |
| Wizzup | +++ b/src/modules/voicecallmanager/comm-voicecallmanager-maemomanager.cpp | 02:09 |
| Wizzup | @@ -73,11 +73,15 @@ void MaemoManager::voiceCallsChanged(void) | 02:09 |
| Wizzup | sphone_module_log(LL_DEBUG, "handlerid: %s", handlerid.toStdString().c_str()); | 02:09 |
| Wizzup | 02:09 | |
| Wizzup | if (!voicecallmodel->instance(handlerid)) { | 02:09 |
| Wizzup | this solves the repeated vibration | 02:09 |
| Wizzup | + mh->hangup(); // If not already | 02:09 |
| Wizzup | I'll see if I can figure out the audio problem next and push that here: https://github.com/maemo-leste/sphone/tree/vcm-fixes | 02:23 |
| unic0rn | devel seems to repeat already sent sms after reboot | 02:23 |
| unic0rn | sent one test message from conversations earlier in the day, just got it again after reboot | 02:23 |
| Wizzup | this is not specific to devel but rather a modem kernel or userspace issue that happens sometimes | 02:26 |
| Wizzup | I don't get it very often at all but sometimes it does happen | 02:26 |
| unic0rn | now this is interesting | 02:36 |
| unic0rn | noticed that when I connect d4 to my chromebook to charge it, on d4's side usb0 shows up as a network interface | 02:37 |
| unic0rn | figured "why bother with wifi when this will be faster" | 02:37 |
| unic0rn | and indeed it works, I have both wifi connection to the internet and local usb ethernet to phone | 02:38 |
| Wizzup | yes, this works fine, but when the droid4 is fully charged it will start dropping the usb0 connection every 30 seconds or so, jfyi | 02:39 |
| Wizzup | bedtime for me, almost 3am | 02:39 |
| Wizzup | tomorrow I hope to fix the audio issue, and maybe look at either volume status applet for call volume or perhaps improve the notifications some depending on fmg's progress | 02:40 |
| unic0rn | yeah, 2:40am here as well | 02:40 |
| unic0rn | question, is there a fine-tuned cpufreq configuration for d4 in leste, or is it just using default ondemand? | 06:19 |
| unic0rn | I'm trying https://pastebin.com/Va8adZXM - it's a bunch of settings I've defined by trial and error on my old amd A8-7600 desktop | 06:19 |
| unic0rn | from my experience on that cpu at least, by default ondemand ramps up way too fast, which is supposed to be nice for performance, but the cost is in the loss of power efficiency | 06:20 |
| unic0rn | same is likely true for other cpus. back then I was checking it with software video decode, because the goal was to avoid having an audible fan noise while watching movies | 06:21 |
| unic0rn | ondemand caused cpu frequency to spike all over the place, it was constantly up and down | 06:22 |
| unic0rn | my conservative settings settle down on lower frequency - it's going up a bit slower to avoid overshooting the required by load frequency, but then it goes down slower as well. | 06:23 |
| unic0rn | the result was more or less constant cpu frequency during video playback, lower than the average generated by ondemand | 06:24 |
| unic0rn | those settings were defined few years ago, but I assume nothing has changed in that governor's settings | 06:25 |
| freemangordon | unic0rn: I don;t think we use any custom cpufreq config | 09:41 |
| freemangordon | maybe use your tuned config and report if there is a change in battery life compared to stock ondemand | 09:41 |
| unic0rn | I am using it, but my usage is irregular and battery is weak, so it's hard to tell, other than perhaps checking how long it'll survive on idle - but I don't really let it idle for too long | 09:42 |
| freemangordon | idle is not really an issue on leste | 09:43 |
| freemangordon | while usage is | 09:43 |
| gnarface | hmmm... you know, i recently observed on some of my other ARM hardware that default ondemand behavior is all over the board even at idle, which is distinctly different from the behavior i've observed on amd64 hardware | 09:43 |
| unic0rn | then it should help, depending how heavy the usage is | 09:43 |
| gnarface | what i'm saying, unic0rn, it it may not be an issue specific to just your d4 | 09:44 |
| unic0rn | default ondemand according to kernel docs, just goes up to max freq as soon as there's load | 09:44 |
| unic0rn | which is, in case of a phone, not exactly optimal | 09:44 |
| gnarface | oh, to be clear, i never caught it doing that correctly either, without heavy tuning, even on amd64 | 09:44 |
| freemangordon | well, I think we'll appreciate custom cpufreq tunnings :) | 09:44 |
| gnarface | what actually does that right, is powernowd (using the userspace governor) | 09:44 |
| gnarface | but that's what i actually want out of it | 09:45 |
| unic0rn | the way I tested the settings above was simple, video playback with sudden bitrate spikes | 09:45 |
| gnarface | what i've observed it doing on ARM hardware though, is fluttering around amongst multiple speeds at apparently sub-second frequency | 09:45 |
| gnarface | ...which isn't useful | 09:45 |
| freemangordon | ugh | 09:45 |
| unic0rn | default conservative wasn't keeping up with the load, leading to dropped frames, so I've tuned it so that there was no performance loss vs ondemand, but the clocks were more stable and lower | 09:46 |
| unic0rn | gnarface: oh yes, those changes are VERY fast | 09:47 |
| gnarface | i don't think it's specific to the d4, or even to maemo-leste, i think it's something suspect in the upstream kernel ondemand implementation, and where i tested it at least, schedutil was doing it too, but i haven't tested kernels older than 6.1 to see if it was always this way | 09:47 |
| unic0rn | ondemand just has adhd | 09:47 |
| unic0rn | it was that way on 5.x kernels in manjaro iirc | 09:47 |
| gnarface | what i'm wondering is if it's different for ARM hardware, since i haven't tested it on the x86 ones either | 09:47 |
| gnarface | ...not since before 6.1 anyway | 09:48 |
| unic0rn | it was that way on a8-7600 for me, desktop apu from amd | 09:48 |
| gnarface | hmmm | 09:48 |
| unic0rn | so yeah, it's just the way ondemand is | 09:48 |
| gnarface | or maybe newer hardware in general? the other thing is, most my hardware is pretty old.... | 09:48 |
| unic0rn | it's jumping all over the place | 09:48 |
| unic0rn | a8-7600 is old | 09:48 |
| unic0rn | that's kaveri, waaaaay before ryzen | 09:49 |
| gnarface | not doing it on my FX or phenom chips | 09:49 |
| gnarface | though they have a different issue where they kinda individually drift a few mhz off the target speed setting... | 09:50 |
| gnarface | the actual state changes don't "flutter" | 09:50 |
| unic0rn | older amds were a mess | 09:50 |
| gnarface | i think that's actually an artifact of some power saving thing i've got enabled in the bios... | 09:51 |
| unic0rn | cool'n'quiet? | 09:51 |
| unic0rn | as in, "we're just frying those eggs, no need to burn them in 5 seconds" | 09:51 |
| gnarface | no, unrelated to the fans | 09:51 |
| gnarface | "C1e" or "c1E" or something? | 09:52 |
| gnarface | the capitalization might matter | 09:52 |
| unic0rn | could be, no idea why it would affect frequencies | 09:52 |
| unic0rn | but then, if the hardware is old, I would check voltages | 09:52 |
| unic0rn | if they're not stable... well. things may happen | 09:53 |
| gnarface | anyway, on the ARM hardware though, (pine64+ A64 SoC boards but you can probably reproduce this on a pinephone) i was seeing the current frequency feathering around among i think the bottom 3 speeds even while at basically 0% load, which seems... wrong | 09:55 |
| unic0rn | with ondemand? | 09:56 |
| gnarface | yea, default settings. not sure if that's related to what you're seeing | 09:56 |
| unic0rn | I'm surprised it didn't go to max | 09:56 |
| gnarface | i'm not using systemd | 09:57 |
| unic0rn | lol | 09:57 |
| gnarface | :D | 09:57 |
| unic0rn | also, perhaps I wasn't clear. I wasn't really checking the frequency spikes on my d4, although when issuing random frequency info or anything, current clock was usually higher than minimum at idle | 09:58 |
| unic0rn | I was just copying some stuff to d4, including various scripts, and I found those custom settings | 09:58 |
| unic0rn | checked what leste is using, added the script to rc.local and that's it. figured it won't hurt and should actually help | 09:59 |
| unic0rn | since ondemand is usually going bonkers with the clocks | 09:59 |
| unic0rn | on any platform | 09:59 |
| unic0rn | but as I've said, from my experience on that cpu - meaning a8-7600 | 10:00 |
| unic0rn | I would be surprised if omap behaves any better though | 10:01 |
| freemangordon | Wizzup: ok, gabble looks for jabber:x:delay, which is superseeded by xep 203 | 10:01 |
| Wizzup | freemangordon: check | 10:46 |
| Wizzup | freemangordon: I think with message markers we might not even need xep 203 , do we? | 10:47 |
| Wizzup | https://docs.modernxmpp.org/client/protocol/ | 10:48 |
| Wizzup | freemangordon: ^^ | 10:48 |
| Wizzup | does anyone else find the droid4 vibration too strong in sound? | 10:56 |
| Wizzup | funnily enough the hw a vibrates very different from the hw b it seems | 10:56 |
| Wizzup | lowering the speed from 180 to 80 made it a bit better for me IMO | 10:58 |
| freemangordon | Wizzup: inxep 203 it is urn:xmpp:delay | 10:58 |
| freemangordon | Wizzup: so, we are becoming upstream for tp-gabble? | 10:59 |
| Wizzup | freemangordon: I think we should make contact with the mailing list | 11:07 |
| Wizzup | nlnet also said they'd appreciate it if we are a bit more public about or telepathy fixing efforts | 11:08 |
| Wizzup | it might also help with other distros keeping it around | 11:08 |
| Wizzup | I think gentoo was trying to remove certain telepathy related packages due to lack of maintenance | 11:08 |
| Wizzup | freemangordon: so the modernxmpp website, I think this is really worth checking | 11:10 |
| Wizzup | as it says there's over 500 XEPs and many are no longer in use | 11:11 |
| Wizzup | it would be sensible to look at some modern clients (prosody, dino, conversations on android etc) and see which ones they implement | 11:11 |
| Wizzup | there's probably also a lot of code already out there, for example for pidgin there are many plugins which do say omemo or mam and they're actually suprisingly few lines of code | 11:12 |
| Wizzup | https://github.com/qxmpp-project/qxmpp | 11:14 |
| Wizzup | this is what Kaidan uses | 11:14 |
| Wizzup | https://doc.qxmpp.org/qxmpp-1/xep.html | 11:14 |
| Wizzup | we might consider switching to this from the old lib that gabble uses | 11:15 |
| Wizzup | https://doc.qxmpp.org/qxmpp-1/ | 11:15 |
| freemangordon | Wizzup: all this does not answer my question :) | 11:16 |
| freemangordon | I made a pr for tp-haze few months ago | 11:16 |
| freemangordon | no sign of life, so i wonder if there is anybody on FDO that's still interested in TP | 11:16 |
| Wizzup | so I think we should mail the mailing list, ask if there are any maintainers, and otherwise suggest we could maintain some packages | 11:16 |
| Wizzup | was this on gitlab or on the mailing list | 11:17 |
| freemangordon | could you do that? | 11:17 |
| freemangordon | on gitlab | 11:17 |
| Wizzup | I seem to vaguely remember mailing the tp mailing list a year or two ago, but I am not sure | 11:17 |
| Wizzup | yeah ok I can look | 11:17 |
| freemangordon | please do, you know PR is not my cup of tee :p | 11:17 |
| freemangordon | in the meanwhile I'll start fixing our gabble | 11:17 |
| Wizzup | I don't think I'm particularly good at PR yet | 11:18 |
| Wizzup | could you look at qxmpp? | 11:18 |
| freemangordon | what for? | 11:18 |
| Wizzup | it's a library | 11:18 |
| freemangordon | I don't want qt in tp service | 11:19 |
| Wizzup | there are connection managers that use qt (matrix for example) | 11:19 |
| freemangordon | ok, but that does not make it less memory hungry | 11:19 |
| Wizzup | the point mostly being that implementing 10 years of XEPs that gabble missed out on could take a long time | 11:19 |
| Wizzup | maybe see if there's any other library then | 11:19 |
| freemangordon | I don;t think it will be that complicated | 11:19 |
| Wizzup | I write prosody earlier but I meant profanity | 11:20 |
| freemangordon | we use wocky, lemme check if it has bee updated | 11:20 |
| Wizzup | no wocky is very outdated | 11:20 |
| freemangordon | right | 11:20 |
| Wizzup | https://github.com/profanity-im/profanity this is a console based client | 11:20 |
| Wizzup | (I also use this) | 11:20 |
| freemangordon | well, last commit is 3 years ago | 11:20 |
| Wizzup | I don't know if they have a library | 11:20 |
| freemangordon | https://github.com/TelepathyIM/wocky/commits/master/ | 11:21 |
| Wizzup | no, looks like it's just plain C code without a library | 11:21 |
| freemangordon | mhm | 11:21 |
| Wizzup | (profanity-im) | 11:21 |
| freemangordon | ah | 11:21 |
| freemangordon | :) | 11:21 |
| Wizzup | I mean all these wocky changes are kind of just keeping it alive | 11:22 |
| Wizzup | not really adding anything | 11:22 |
| Wizzup | I mean it's up to you but I would straight up consider abandoning wocky and building upon work others have done | 11:22 |
| Wizzup | there's a -lot- | 11:22 |
| Wizzup | brb 15 mins or so | 11:23 |
| freemangordon | Wizzup: https://github.com/TelepathyIM/wocky/commit/564551d495cde108d8ec05ddf8cbb96fb0ef1ddc | 11:23 |
| freemangordon | this is already fixed upstream | 11:23 |
| freemangordon | Wizzup: does not look *that* inactive | 11:26 |
| freemangordon | https://github.com/TelepathyIM/telepathy-gabble/commits/master/ | 11:26 |
| Wizzup | 3 years ago is very inactive | 11:27 |
| Wizzup | I would suggest to look at how much has changed and estimate just how long it will take to reimplement all of it, and for what :) | 11:27 |
| freemangordon | how to know what has changed for 3 years? | 11:28 |
| Wizzup | not three years | 11:28 |
| Wizzup | It was already super lagging behind in 2014 | 11:28 |
| Wizzup | now it's 2024 | 11:28 |
| freemangordon | hmm | 11:28 |
| Wizzup | it's not about when there was last a commit, but no features were adding, no new XEPs, since forever | 11:28 |
| freemangordon | so, the plan should be to drop wocky? | 11:28 |
| freemangordon | or to drop gabble, or? | 11:29 |
| Wizzup | or bring it up to date with all modern xmpp xep's, per the website I linked earlier and by looking at what the various clients/lbis implement (qxmpp, kaidan, dino, profanity-im) | 11:29 |
| freemangordon | ok, do we want *everything* implemented? | 11:29 |
| Wizzup | well there's (1) upgrade wocky (2) switch gabble to different lib than wocky and bring it up to date otherwise (3) make a new cm like tp gabble with a new lib | 11:29 |
| freemangordon | (3) would be a nightmare | 11:29 |
| Wizzup | well we don't need everything implement now, but I think that multi device, message archives and omemo are all pretty standard now | 11:30 |
| freemangordon | so I would try with 1 | 11:30 |
| Wizzup | I think we just need to take stock of how much work each option would be before deciding | 11:30 |
| freemangordon | implementing couple of missing functionalities should be easier than starting from scratch | 11:31 |
| Wizzup | just keep in mind that many of these modern xmpp libraries get funding for years and continue to work on it, so it's not a small undertaking | 11:31 |
| freemangordon | hmm, ok | 11:31 |
| Wizzup | I think I disagree but I don't think either of us have done the necessary homework :P | 11:31 |
| freemangordon | right | 11:31 |
| freemangordon | so, do we have library to use instead of wocky? | 11:31 |
| freemangordon | not qt based, please | 11:31 |
| Wizzup | well this is what I was trying to research above | 11:31 |
| freemangordon | right | 11:32 |
| freemangordon | hmm, actually, if it does not link to QApplication/GUI, it should not ba that bad | 11:32 |
| Wizzup | yes, it is not bad | 11:32 |
| Wizzup | it looks like dino is vala, so not C | 11:32 |
| * freemangordon reconsiders | 11:32 | |
| Wizzup | prosody-im is C but they don't have a library, their xmpp implementation is in-line | 11:33 |
| freemangordon | I meant this https://github.com/qxmpp-project/qxmpp | 11:33 |
| Wizzup | yes I understand :) | 11:33 |
| freemangordon | where is prosody-im? | 11:33 |
| Wizzup | I think there is telepathy-tank in our repos (which is the matrix cm that uses telepathyqt to be a cm) | 11:33 |
| Wizzup | sorry I keep writing prosody but I mean profanity | 11:33 |
| Wizzup | https://github.com/profanity-im/profanity | 11:33 |
| Wizzup | prosody is the C/lua server for xmpp | 11:34 |
| freemangordon | oh, ok | 11:35 |
| freemangordon | looks promising https://github.com/profanity-im/profanity/blob/master/src/xmpp/xmpp.h | 11:35 |
| Wizzup | my current preference would be looking at qxmpp since it seems to have nice looking docs and enough abstractions that it could match tp nicely | 11:35 |
| Wizzup | yes that is a good option too | 11:35 |
| Wizzup | but then you'd have to figure out how to link against it I guess | 11:36 |
| Wizzup | profanity will probably lack all things for audio and video calls, since it's a ncurses client | 11:36 |
| freemangordon | what would be the issue? | 11:36 |
| freemangordon | (linking) | 11:36 |
| Wizzup | I mean you could copy-paste the code but then how to do keep up to date | 11:36 |
| freemangordon | ah | 11:36 |
| Wizzup | or git submodule it somehow link against the objects | 11:36 |
| freemangordon | no, that should be submodule | 11:36 |
| Wizzup | but there's no 'libprofanity' as far as I can see | 11:36 |
| freemangordon | so, you think qxmpp? | 11:37 |
| Wizzup | I think so, but I don't know if that would be (2) or (3), I guess probably (3), which is, eh, but maybe better | 11:37 |
| freemangordon | no, better 2 | 11:37 |
| freemangordon | well, depends who implements it | 11:38 |
| Wizzup | so would you mix C and C++ and glib and qt them in the CM? | 11:38 |
| freemangordon | if it is me, I would go for 2 | 11:38 |
| Wizzup | ok | 11:38 |
| freemangordon | what is the issue? | 11:38 |
| freemangordon | (mixing) | 11:38 |
| freemangordon | qt uses glib | 11:38 |
| Wizzup | not a lot I suppose, just convoluted code wise | 11:38 |
| Wizzup | O' | 11:39 |
| Wizzup | I'm fine either way, but qxmpp seems to support all modern stuff, likely will be maintain going forward, and the APIs/abstractions seem nice | 11:39 |
| Wizzup | whether we use telepathyqt connection manager or glib connection manager I don't really care about so much | 11:39 |
| Wizzup | I just saw that gabble is 75k lines of code | 11:39 |
| freemangordon | hmm, maybe creating tp-qxmpp is really a better option | 11:39 |
| freemangordon | Wizzup: but that includes wocky | 11:40 |
| Wizzup | oh it does? ok, I just did wc -l src/*.c | 11:40 |
| freemangordon | in lib | 11:41 |
| Wizzup | ah I see, wocky is just copied into it | 11:41 |
| freemangordon | mhm | 11:41 |
| Wizzup | well, anyway, so I do think (3) is easier, but maybe we need to do a bit of exploration to find out | 11:41 |
| Wizzup | I need to water the plants :) | 11:42 |
| freemangordon | :) | 11:42 |
| Wizzup | one thing, in regards to a main to send to tp, what shall I say | 11:42 |
| Wizzup | like, hi, ewe're here, we're using tp and fixing things, can we get acess to maintain things? or? | 11:43 |
| freemangordon | something like | 11:43 |
| freemangordon | or, is there maintainer, we want to colaborate, dunno | 11:43 |
| Wizzup | ok | 11:44 |
| freemangordon | we already did some things, (insert link here) ... | 11:44 |
| freemangordon | this https://github.com/maemo-leste-upstream-forks/telepathy-haze/commits/maemo/chimaera-devel for example | 11:45 |
| freemangordon | Wizzup: but, until we do something better, I think to fix our gabble for at least simple things | 11:54 |
| freemangordon | like backscroll etc | 11:54 |
| Wizzup | ok | 12:05 |
| Wizzup | freemangordon: anyone I should CC? | 12:42 |
| Wizzup | for TP | 12:42 |
| Wizzup | I sent you a draft | 12:42 |
| freemangordon | ... | 12:42 |
| freemangordon | no idea | 12:43 |
| Wizzup | ok | 12:43 |
| freemangordon | maybe pavel? | 12:43 |
| Wizzup | I could add random contributors | 12:43 |
| Wizzup | from TP I mean | 12:43 |
| freemangordon | yeah, mail looks fine to me | 12:44 |
| Wizzup | maybe just check the draft and if it's ok I will send it | 12:44 |
| Wizzup | ok | 12:44 |
| Wizzup | then I'll just mail more people if nobod responds | 12:44 |
| Wizzup | (later) | 12:44 |
| freemangordon | I think cc-in Palvel is good idea | 12:44 |
| freemangordon | *cc-ing | 12:45 |
| Wizzup | too late :) | 12:45 |
| Wizzup | but I can send him a copy | 12:45 |
| sicelo | i don't think pavel is interested in TP | 12:49 |
| Wizzup | probably not, but I emailed him anyway, he might be interested in our recent maemo developments | 12:49 |
| sicelo | however, i wonder if you could also have included debian's tp team | 12:49 |
| Wizzup | I think they should be on that list, but if there's no reply in a few days I will reply to the mail, assuming it goes through the ML, and include them in a reply | 12:50 |
| sicelo | sure. i was looking at debian's ofono package recently, and it's 'housed' by the tp team. | 12:50 |
| Wizzup | right | 12:56 |
| Wizzup | arno11: sorry I forgot about pcsx yesterday, let's take a look today | 13:16 |
| arno11 | Wizzup: vibration is really too strong on N900 too. | 14:29 |
| arno11 | for pcsx, no rush | 14:29 |
| arno11 | but once pcsx is ok i can work on pierogi (easy stuff) and Drnoksnes (more complicated) | 14:31 |
| Wizzup | yeah I think we just reduce the power in mce.ini | 14:35 |
| arno11 | ok | 14:39 |
| dsc_ | arno11: re: yt-dlp, do you output in a certain resolution (ffmpeg pass?) | 15:17 |
| dsc_ | can imagine you dont want 4k on the n900 | 15:17 |
| arno11 | yeah ofc i use 360p max | 15:19 |
| Wizzup | already got one reply on my TP mail :) | 15:22 |
| sicelo | guess they replied to you directly? i don't see it in ML (even though i received your initial mail) | 15:24 |
| Wizzup | yes | 15:25 |
| Wizzup | btw, it might be worth trying wpa_supplicant from bullseye-backports to see if the host mode works again | 15:27 |
| sicelo | so what are they saying? TP alive? :-) | 15:52 |
| Wizzup | just copying the messages to some other folks | 15:54 |
| freemangordon | Wizzup: I guess I'll have to implement more smart own account matching | 18:08 |
| freemangordon | but for now should be ok | 18:08 |
| Wizzup | ok | 18:11 |
| arno11 | dsc_: btw for 360p stream, i usually run 'python3 yt-dlp --get-url -f 18 https//www.youtube.com/watch?v=blablabla' and then copy the link provided directly in smplayer (and disable compo + fullscreen) | 20:20 |
| dsc_ | ah cool | 20:20 |
| arno11 | a direct pipe works but a way slower | 20:20 |
| arno11 | available resolution can be checked with -F command | 20:22 |
| arno11 | this python tool is a bit slow to start but really powerful | 20:22 |
| dsc_ | i know yt-dlp pretty well, was just wondering how you were using it | 20:27 |
| arno11 | ok :P | 20:32 |
| unic0rn | in case I'm testing video playback, what can I do - other than reboot - when after mpv's exit I'm left with the last played frame on screen? | 22:32 |
| unic0rn | ideally with some soft gpu reboot | 22:32 |
| unic0rn | to be clear, by default it works fine, other than occassional frame drops | 22:34 |
| unic0rn | but I'm kinda stress testing it, with 10bit h264 video and different video output options | 22:35 |
| unic0rn | to which the driver doesn't always respond kindly | 22:35 |
| Wizzup | freemangordon: I don't know if this is recent but on some incoming SMS conversations not aborts with stack smashing detected | 23:43 |
| Wizzup | It might happen in conv_abook_lookup_tel, so I am not sure yet | 23:43 |
| uvos | unic0rn: not a whole lot, driver dosent support gpu recovery | 23:48 |
| uvos | unic0rn: and most of it is closed source | 23:48 |
| uvos | restarting xorg only might help | 23:48 |
| Wizzup | freemangordon: does osso-abook not have dbgsym pkg? | 23:48 |
| uvos | but thats hard to do on leste due to defficanies in its init system | 23:49 |
| unic0rn | figured | 23:49 |
| unic0rn | uvos: [vo/drm] Cannot set CRTC: Permission denied - any idea why? | 23:49 |
| unic0rn | that's as root | 23:49 |
| uvos | Wizzup: btw sphone giveing you a freed call proparties on the pipe is impossible on hangup | 23:50 |
| unic0rn | I have a feeling it might work after killing xorg, but that's not really a solution | 23:50 |
| uvos | unic0rn: no idea in what context that pops up | 23:50 |
| uvos | it could be that you are trying to set the crtc on the gpu drm node | 23:50 |
| uvos | which dosent work since the gpu has no outputs | 23:51 |
| Wizzup | uvos: I solved the hang problem already in vcm code | 23:51 |
| uvos | Wizzup: ok | 23:51 |
| unic0rn | uvos: mpv --vo=drm --drm-connector=1.DSI-1 | 23:51 |
| Wizzup | I just have to see why sphone logs 2-3 times now | 23:51 |
| Wizzup | otherwise it seems good | 23:51 |
| Wizzup | I also trimmed the backend name a bunch | 23:51 |
| uvos | unic0rn: mpv might be trying to change the crtc mode | 23:51 |
| uvos | thats not supported at all | 23:51 |
| unic0rn | could be related to screen rotation? | 23:52 |
| unic0rn | that is, verbose log reports 540x960 | 23:52 |
| uvos | that is correct that is the resolution of the pannel | 23:52 |
| uvos | its native portait | 23:52 |
| Wizzup | freemangordon: | 23:55 |
| Wizzup | (gdb) frame 10 | 23:55 |
| Wizzup | #10 0x0043d61e in TelepathyAccount::log_event (this=this@entry=0xa881b0, epoch=epoch@entry=1717105656, text=..., outgoing=outgoing@entry=false, channel=..., remote_uid=..., remote_alias=...) at ./src/lib/tp.cpp:368 | 23:55 |
| Wizzup | 368 in ./src/lib/tp.cpp | 23:55 |
| Wizzup | (gdb) printqs5static remote_uid | 23:55 |
| Wizzup | then it crashes here: | 23:56 |
| Wizzup | (Qt5 QString)0xbeffe610 length=5: "Apple" | 23:56 |
| Wizzup | #6 0xb5698a3e in __stack_chk_fail () at stack_chk_fail.c:24 | 23:56 |
| Wizzup | #7 0xb6abc1ca in osso_abook_query_phone_number () at /usr/lib/arm-linux-gnueabihf/libosso-abook-1.0.so.0 | 23:56 |
| Wizzup | #8 0xb6ac9a14 in osso_abook_aggregator_find_contacts_for_phone_number () at /usr/lib/arm-linux-gnueabihf/libosso-abook-1.0.so.0 | 23:56 |
| Wizzup | #9 0x0042b840 in conv_abook_lookup_tel(char const*) (telno=<optimized out>) at ./src/lib/abook.cpp:37 | 23:56 |
| Wizzup | sorry I should have probably pasted this somewhre else | 23:56 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!