| Wizzup | sicelo: uvos: when you mean gpu hang, do you mean device reset, or? | 00:06 |
|---|---|---|
| uvos | Wizzup: no its the never returing ioctl thing - or at least the symptoms are the same | 00:35 |
| uvos | the device fails to render any new frames, the last frame is displayed forever but the kernel is alive enough to never trigger a wdr | 00:36 |
| Wizzup | uvos: I see | 02:19 |
| Wizzup | to be honest I'm quite happy with how this is working out wrt tp | 02:55 |
| Wizzup | I think if we can implement some history fetching for some of the more important protocols, we're quite far then | 02:56 |
| freemangordon | Wizzup: yes, your messages from web client (or another leste device) are reported as scrollback messages to tp | 07:50 |
| freemangordon | what is the issue with password field? | 07:51 |
| freemangordon | if it is either password or api token, just enter it there | 07:51 |
| freemangordon | arno11: did you manage to fix you fb plugin issues? | 09:27 |
| freemangordon | Wizzup: hmm, sometimes sent messages got lost | 09:43 |
| freemangordon | like, I type something on the kbd, press send and nothing happens, besides that message field is cleared | 09:45 |
| freemangordon | if I kill conversations, it starts to work | 09:47 |
| Wizzup | freemangordon: it's not either api_token or password, they are seperate things for the plugin | 11:06 |
| Wizzup | freemangordon: I have never gotten a message that I have sent myself delivered, not as scrollback or otherwise, but I don't do fb | 11:06 |
| arno11 | freemangordon: no, i still have issues with FB plugin: purple-FB is perfectly working through pidgin but not through tp-haze/conversations (from a fresh install, i tried twice, with devel upgrade and FB plugin from extras testing) | 11:06 |
| arno11 | maybe that's something due to my account, i don't know, otherwise everything is fine (even with overclock :P, btw my n900 is stable @1GHz with Fremantle and works @1.1GHz) | 11:09 |
| Wizzup | does it not log into the account, or do messages not get reported? | 11:10 |
| arno11 | it refuses to log in fact | 11:10 |
| arno11 | and when i start presence-ui from command line it show 'network error') | 11:11 |
| arno11 | what i don't understand is why it works in pidgin with exactly the same settings and same network | 11:16 |
| freemangordon | arno11: hmm, weird | 11:21 |
| freemangordon | will ping you later on to check what haze is doing | 11:21 |
| arno11 | ok | 11:21 |
| freemangordon | Wizzup: maybe I didn't explain it properly - it is not about messages from other channels, but IM message (person-to-person) | 12:09 |
| Wizzup | I understand | 12:10 |
| Wizzup | so on xmpp with gabble you won't get these currently | 12:10 |
| Wizzup | we'd need the xep 0313 MAM support for this I believe | 12:10 |
| freemangordon | again, it is not about any history | 12:12 |
| freemangordon | I just type a message, press 'Send" and nothinbg :) | 12:12 |
| Wizzup | what if you're offline on the phone at that moment? | 12:12 |
| freemangordon | I am not | 12:12 |
| Wizzup | so there are two things | 12:13 |
| Wizzup | if a protocol supports real time sending your sent messages, handle them well | 12:13 |
| freemangordon | but even if I am, I should be given at least error message or something | 12:13 |
| Wizzup | and then there is the more general case | 12:13 |
| Wizzup | yeah, we don't handle the offline / not in a room case yet | 12:13 |
| Wizzup | we will | 12:13 |
| Wizzup | but the more general case is that various protocols can send you message history from channels, like slack, xmpp, etc | 12:13 |
| freemangordon | ok, I think I am just hitting some bug | 12:13 |
| freemangordon | right | 12:14 |
| Wizzup | so that your phone can have the 'full/correct' log | 12:14 |
| freemangordon | right | 12:14 |
| freemangordon | got it | 12:14 |
| freemangordon | but all this has nothing to do with what I reported ^^^ :) | 12:15 |
| Wizzup | if tp-haze reports your message sent from another device and conversations doesn't log it, that's a bug | 12:15 |
| Wizzup | conversations currently ignores messages marked as delivery reports | 12:15 |
| Wizzup | but it doesn't look at the scrollback status | 12:15 |
| freemangordon | I know | 12:15 |
| freemangordon | it is not about scrollback or delivery report | 12:15 |
| freemangordon | again: | 12:15 |
| freemangordon | I press on a IM action in addressbook, conversations open IM channel, I type something, press send, message field gets cleared and that's all | 12:16 |
| Wizzup | I see, and if you re-open the window in conversations, is the message there? | 12:16 |
| freemangordon | the message is neither received on the other side, nor does it appear in the history | 12:17 |
| freemangordon | no, it is not | 12:17 |
| Wizzup | ok, so the sending just goes awry | 12:17 |
| freemangordon | yes | 12:17 |
| freemangordon | that's what I am trying to say all the time :) | 12:17 |
| freemangordon | unfortunately no idea how to repro | 12:17 |
| freemangordon | maybe if account re-connects ? | 12:17 |
| Wizzup | I think the first thing to do is the handle the status of a sent message | 12:18 |
| Wizzup | we don't track that currently | 12:18 |
| Wizzup | we just fire and forget | 12:18 |
| freemangordon | ok, but when do you add it to history and to scrollback? | 12:18 |
| Wizzup | when it is sent successfully | 12:18 |
| freemangordon | how do you know that? | 12:18 |
| Wizzup | tp lets us know though the channel onMessageSent signal | 12:19 |
| freemangordon | ok | 12:19 |
| Wizzup | but if we want to get specific errors for a msg, we will need to follow it | 12:19 |
| freemangordon | BTW, I suspect once you open a channel and account re-connects, the handle is no longer valid | 12:19 |
| Wizzup | and then we would log messages to the db, set flags that they aren't sent yet, and then update those flags instead of logging a new message in onmessagesent | 12:19 |
| Wizzup | that is correct, at least for rooms | 12:19 |
| Wizzup | I am not sure if this is the same for direct 1:1 messages too | 12:20 |
| freemangordon | it should be the same for IM channels as well | 12:20 |
| Wizzup | oh, wait, I see, yes. | 12:20 |
| freemangordon | ;) | 12:20 |
| Wizzup | yes, this is probably it | 12:20 |
| Wizzup | we'll have to handle the channel invalidation then | 12:20 |
| freemangordon | so you should handle acount status | 12:20 |
| Wizzup | because we have a channel 'cache', so we don't make double channels | 12:21 |
| freemangordon | yes | 12:21 |
| freemangordon | I don;t think that's needed | 12:21 |
| Wizzup | I think we just handle channel invalidation, not check onOnline or something | 12:21 |
| freemangordon | at least haze does that for you | 12:21 |
| Wizzup | no, this can definitely happen | 12:21 |
| freemangordon | for group chats that is | 12:21 |
| Wizzup | even if it is the same channel, we would connect() the qt signal twice | 12:21 |
| Wizzup | resulting in double messages :) | 12:21 |
| freemangordon | ah | 12:21 |
| freemangordon | anyway, have to run, ttyl | 12:21 |
| Wizzup | ttyl | 12:24 |
| rafael2k | Happy 2024 everybody! | 13:20 |
| rafael2k | The maemo is running on the PPP here for 2 week without reboot. At least the kernel from Mobian is very stable. | 13:20 |
| Wizzup | right, but the display/hildon-desktop still needs to be figured out, right? | 13:21 |
| Wizzup | also, happy new year | 13:21 |
| rafael2k | yeap | 13:24 |
| Wizzup | we're making lots of progress I think :) | 13:24 |
| rafael2k | anyone with time, lemme know, I too a look in the code, but I feel I'll spend much more time than any of you | 13:24 |
| Wizzup | I think fmg is the best candidate to take a look | 13:25 |
| Wizzup | I don't know too much about h-d | 13:25 |
| rafael2k | I have a feeling there could be some issue at panfrost too. I hope not | 13:26 |
| Wizzup | could be, but let's exclude that for now | 13:26 |
| Wizzup | rotation is likely not 3d related | 13:26 |
| rafael2k | right | 13:42 |
| rafael2k | and the lock screen is perfectly working, no lags, correct aspect and so on | 13:43 |
| freemangordon | rafael2k: how can I copnnect? | 14:53 |
| freemangordon | *connect | 14:54 |
| arno11 | freemangordon: i got logs fron tp-haze and issue seems related to recent changes with my ISP ! | 14:56 |
| freemangordon | ugh | 14:56 |
| freemangordon | but why it affects haze only? | 14:56 |
| arno11 | because it seems to be related to tricky stuff with ipv6 | 14:57 |
| freemangordon | so, can we do anything to fix that? | 14:58 |
| arno11 | and pidgin seems to have patch for that issue | 14:58 |
| freemangordon | ahaaa | 14:58 |
| arno11 | not at the moment | 14:58 |
| arno11 | and this issue seems to affect FB and google mainly | 14:58 |
| arno11 | so anyway | 14:59 |
| freemangordon | wtym 'pidgin has a patch", isn't it the same plugin? | 14:59 |
| arno11 | same plugin yes, but i mean pidgin itself | 14:59 |
| freemangordon | ok, but pidgin is just an UI, it is the plugin that does all the job | 14:59 |
| arno11 | apparently not all the job iiuc | 15:00 |
| freemangordon | ah, maybe the fix is in libpurple | 15:00 |
| arno11 | ah yes probably | 15:00 |
| freemangordon | but... they use the same libpurple | 15:00 |
| arno11 | i'll have a 'deeper' look and let you know | 15:00 |
| freemangordon | ok, LMK if you find some details | 15:01 |
| freemangordon | ok | 15:01 |
| freemangordon | I wonder shall we do PR for our changes to upstream | 15:01 |
| rafael2k | hey | 16:20 |
| rafael2k | I'll write to you in pvt | 16:20 |
| freemangordon | rafael2k: so, does that run some kind of zaphod head or? | 17:27 |
| freemangordon | why do we have 2 crtcs connected to the output? | 17:28 |
| freemangordon | Wizzup: so the issue with ppp is that we h-d cannot identify the primary crtc | 17:28 |
| rafael2k | no, just one output | 17:28 |
| rafael2k | I mean, not that I know, but it is just the stock phone connected to the pp keyboard | 17:29 |
| freemangordon | ok, but xrandr reports 2 crtcs connected, 63 and 64 | 17:29 |
| rafael2k | DP-1 disconnected primary (normal left inverted right x axis y axis) | 17:29 |
| rafael2k | this one right ^ | 17:30 |
| freemangordon | yes | 17:30 |
| freemangordon | and root window is reported to be on that output :D | 17:30 |
| freemangordon | that's a mess | 17:30 |
| rafael2k | I have a feeling this is for connecting an external monitor | 17:30 |
| rafael2k | uff | 17:30 |
| freemangordon | rafael2k: this https://github.com/maemo-leste/hildon-desktop/blob/master/src/util/hd-util.c#L278C7-L278C15 | 17:31 |
| freemangordon | receives DP-1 as output | 17:31 |
| freemangordon | lemme check xorg.log | 17:32 |
| rafael2k | lets try to XRRSetOutputPrimary to force the correct one? | 17:34 |
| rafael2k | lemme test | 17:34 |
| freemangordon | wait a second | 17:34 |
| rafael2k | ok | 17:35 |
| freemangordon | the fuck? where is xorg log file? | 17:35 |
| dsc_ | /home/user/.local/share/xorg/Xorg.0.log | 17:37 |
| freemangordon | ok, I can't find Xorg log file | 17:38 |
| freemangordon | thanks | 17:38 |
| dsc_ | maybe, idk | 17:38 |
| freemangordon | ah | 17:38 |
| rafael2k | /var/log/Xorg.0.log | 17:40 |
| freemangordon | no, dsc_ is right | 17:40 |
| rafael2k | good to know | 17:40 |
| freemangordon | keep in mind we run xorg as user | 17:40 |
| rafael2k | : ) | 17:40 |
| rafael2k | hummm, that was myself then | 17:40 |
| freemangordon | yeah, that's new to me as well :) | 17:40 |
| dsc_ | (found via lsof :P) | 17:40 |
| freemangordon | does nto matter | 17:41 |
| rafael2k | interesting | 17:41 |
| rafael2k | freemangordon: https://gist.github.com/oranenj/3658446 | 17:41 |
| rafael2k | does this make sense to have ^ | 17:41 |
| rafael2k | check if display is connected, then set it as primary | 17:42 |
| rafael2k | (the first connected, I mean) | 17:42 |
| freemangordon | no, because we might want to have multiple connected tisplays | 17:42 |
| freemangordon | the issue here is that someone reports that xorg root window is on disconncted output | 17:42 |
| freemangordon | what image is that? PP? | 17:43 |
| rafael2k | yes | 17:43 |
| rafael2k | PP one | 17:43 |
| freemangordon | hmm, I was thinking there is xorg.conf file for it | 17:43 |
| freemangordon | obviously not | 17:43 |
| freemangordon | to me this is a bug in modesetting | 17:46 |
| freemangordon | I wonder if we can fix that with .conf wile | 17:46 |
| freemangordon | rafael2k: no idea what to do | 17:50 |
| freemangordon | like, to me this is a bug in modesetting (perhaps) | 17:50 |
| freemangordon | also, kernel driver lacks connector type property | 17:50 |
| freemangordon | without knowing which screen to rotate... | 17:51 |
| freemangordon | h-d simply assumes it is in landscape | 17:52 |
| freemangordon | and it is not that simple to just hardcode something | 17:52 |
| freemangordon | because that affects touchscreen as well | 17:53 |
| freemangordon | ugh | 17:58 |
| freemangordon | dp-1 is primary | 17:58 |
| freemangordon | so, how could root window be on the disconnected output is beyond my understanding | 18:00 |
| freemangordon | uvos: ^^^ any cluie | 18:00 |
| freemangordon | *clue | 18:00 |
| freemangordon | rafael2k: does it look better now? | 18:03 |
| freemangordon | rafael2k: ok, I am disconnecting, I think as a workaround you may want to put: | 18:13 |
| rafael2k | lemme check | 18:13 |
| freemangordon | xrandr --output DSI-1 --primary | 18:13 |
| freemangordon | in .xinitrc or some other script | 18:13 |
| freemangordon | until the issue is fixed | 18:13 |
| rafael2k | yay | 18:14 |
| rafael2k | perfect now | 18:14 |
| rafael2k | : ) | 18:14 |
| freemangordon | yeah, but will be broken on reboot | 18:14 |
| freemangordon | I am not sure how to fix that | 18:14 |
| rafael2k | at least you found the root cause! | 18:14 |
| freemangordon | yeah | 18:14 |
| rafael2k | that is already big advancement | 18:14 |
| freemangordon | we shall find someone that knows xrandr better than me to see if this is normal behaviour | 18:16 |
| freemangordon | (primary output to be disconnected) | 18:16 |
| freemangordon | and root to be reported to live there | 18:16 |
| rafael2k | yeap, but at least we can workaround this issue until properly fixed | 18:19 |
| rafael2k | touch and screen works pretty nice and fast, no artifacts or anything I can see! | 18:20 |
| freemangordon | :) | 18:23 |
| rafael2k | much fast than PP 1! | 18:28 |
| freemangordon | well, pp1 is ok in portrait | 18:32 |
| rafael2k | no problem with PP1 indeed | 18:34 |
| rafael2k | comparing PPP with maemo now, and plasma or mobian... maemo is so much faster and "snapier¨ | 18:35 |
| rafael2k | : ) | 18:35 |
| freemangordon | which makes sense, given how light it is | 18:35 |
| freemangordon | and optimized for low-end devices | 18:35 |
| rafael2k | btw, and if one has indeed an external DP connected | 19:16 |
| rafael2k | shouldn't we default the root display to the device one anyway? | 19:17 |
| Wizzup | are both displays 'connected' | 19:55 |
| Wizzup | even the external one? | 19:56 |
| Wizzup | freemangordon: dsc_: looks like my local_uid calc was wrong, I've just commit a fix to master | 20:22 |
| Wizzup | in conversations | 20:22 |
| Wizzup | so we'll probably want to clean the db | 20:23 |
| Wizzup | recreate* | 20:23 |
| Wizzup | (it's only in -devel so no harm done) | 20:23 |
| rafael2k | no, just the DSI display device shows as connected | 20:59 |
| Wizzup | then h-d shouldn't pick it, weird that it would be primary though | 21:59 |
| Wizzup | freemangordon: rtcom-accounts-ui won't expand my jabber account when clicked on from status menu -> accounts | 22:50 |
| freemangordon | Wizzup: the issue is that display type is not reported | 23:32 |
| freemangordon | and we look for "Panel" do determine which is the built-in one | 23:32 |
| freemangordon | Wizzup: is that account enabled? | 23:33 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!