| Wizzup | uvos: well let's stay in touch wrt rtcom since we can probably share some code eventually | 00:18 |
|---|---|---|
| Wizzup | I have quite some notes on how rtcom works and how to log for sms | 00:18 |
| Wizzup | and I'll make a el-v1.db for testing | 00:19 |
| kona | got tired of not having a kb on my main phone | 04:53 |
| kona | https://rootaction.net/owncloud/index.php/s/vlX4GsBlskKQsta | 04:53 |
| kona | might do similar for my pinephone if i can't get one of the official kbs | 04:54 |
| Wizzup | bluetooth/ | 08:36 |
| Wizzup | ? | 08:36 |
| Wizzup | that upside seems unreal :p | 08:37 |
| Wizzup | uptime* | 08:37 |
| uvos | rtcom-eventlogger is pretty terrible | 11:12 |
| uvos | like the field event_type needs a string literal like "RTCOM_EL_EVENTTYPE_SMS_MESSAGE" thats how the hell am i supposed to gues that? its not defined anywhere | 11:13 |
| uvos | same with all of the other event elements | 11:13 |
| Wizzup | I didn't have that much trouble with it tbh | 11:15 |
| Wizzup | but yeah we're basically doing double work now anyway | 11:15 |
| uvos | its terrible api | 11:15 |
| Wizzup | k | 11:16 |
| uvos | well can you tell me what all the RTCOM_EL_EVENTTYPE_ strings are? | 11:21 |
| Wizzup | they are defined in the plugins | 11:22 |
| Wizzup | https://github.com/maemo-leste/rtcom-eventlogger-plugins/blob/master/src/sms-plugin.c | 11:23 |
| Wizzup | https://github.com/maemo-leste/rtcom-eventlogger-plugins/blob/master/src/sms-plugin.c#L76 | 11:23 |
| uvos | great api :P | 11:23 |
| uvos | "go grep some other repo to maybe find where the string is used somewhere" | 11:24 |
| Wizzup | so the plugins have some headers | 11:24 |
| Wizzup | but they don't export the useful stuff | 11:24 |
| Wizzup | we should add them here https://github.com/maemo-leste/rtcom-eventlogger-plugins/blob/master/rtcom-eventlogger-plugins/sms.h | 11:24 |
| Wizzup | that's my understanding at least | 11:24 |
| Wizzup | https://github.com/maemo-leste/rtcom-eventlogger-plugins/blob/master/rtcom-eventlogger-plugins/call.h | 11:24 |
| Wizzup | which already does the call logging | 11:25 |
| Wizzup | and the call types here: https://github.com/maemo-leste/rtcom-eventlogger-plugins/blob/master/src/call-plugin.c#L195 | 11:25 |
| Wizzup | I think the idea is to use the plugins, just the sms one is rather incomplete | 11:26 |
| Wizzup | for example call has this kind of stuff https://github.com/maemo-leste/rtcom-eventlogger-plugins/blob/master/src/rtcom-el-plugin-call.c#L222 | 11:26 |
| uvos | id | 11:27 |
| uvos | idk | 11:27 |
| uvos | that function is really useless | 11:27 |
| Wizzup | which means you don't need the strings externally for that | 11:27 |
| uvos | you still need it if you want to find the events etc | 11:27 |
| Wizzup | so I just filtered by events from the sms service id | 11:28 |
| Wizzup | e.g. | 11:28 |
| Wizzup | if(!rtcom_el_query_prepare(query, | 11:28 |
| Wizzup | "remote-uid", argv[1], RTCOM_EL_OP_EQUAL, | 11:28 |
| Wizzup | "service-id", service_id, RTCOM_EL_OP_EQUAL, | 11:28 |
| Wizzup | NULL)) { | 11:28 |
| uvos | im also not sure what the point to those plugins is in the first place | 11:31 |
| uvos | they dont seam terrbly usefull | 11:31 |
| uvos | Wizzup: https://github.com/maemo-leste/sphone/blob/master/src/modules/store-rtcom.c | 12:47 |
| uvos | so sphone stores its events now | 12:47 |
| uvos | (if you load that module, not default) | 12:47 |
| uvos | into rtcom | 12:47 |
| uvos | still working on the api in the other direction (sphone will abstract it). | 12:47 |
| Wizzup | uvos: did you test this with rtcom uis and such? I don't see a header with uuid for the message id anywhere | 13:35 |
| Wizzup | and does it repor the different sms flags? | 13:36 |
| Wizzup | pending, delivered, etc | 13:36 |
| Wizzup | it should probably also set the is read property | 13:38 |
| uvos | sphone dosent know that | 13:38 |
| uvos | atm | 13:38 |
| uvos | also the state | 13:38 |
| uvos | dosent know that either | 13:38 |
| Wizzup | meanwhile I'm looking at https://gitlab.freedesktop.org/telepathy/telepathy-glib/-/blob/master/examples/client/text-handler.c | 13:41 |
| Wizzup | seems pretty easy / generic for the various (text) protocols | 13:41 |
| uvos | not sure what uuid you speak of | 13:42 |
| uvos | i just did what https://github.com/maemo-leste/rtcom-eventlogger/blob/master/tests/check_el.c dose | 13:42 |
| Wizzup | yeah but check-el doesn't do what needs to be in the database | 13:43 |
| Wizzup | it's pretty evident on the fremantle database | 13:43 |
| uvos | see its terrible api :P | 13:43 |
| Wizzup | well I spend ~2-3 hours understanding it yesterday | 13:43 |
| uvos | if you have to look at the old database to know what fields exist | 13:43 |
| Wizzup | ==== Headers ==== | 13:44 |
| Wizzup | The database has headers, one for each event, it looks like. It for example | 13:44 |
| Wizzup | contains UUIDs for each event (at least for sms), but it can also contain vcard | 13:44 |
| Wizzup | fields it looks like. My table only contains name=message-token though. | 13:44 |
| Wizzup | I don't know how you can write code compatible with what fremantle does without looking at it | 13:51 |
| Wizzup | the local_uid also probably needs to be telepathy-ring for any compat | 13:51 |
| Wizzup | well not that literal string, but a telepathy-ring one | 13:51 |
| uvos | thats bust | 13:52 |
| Wizzup | on fremantle the local_uid for all sms/call events is ring/tel/ring | 13:52 |
| Wizzup | there are others too, e.g. | 13:52 |
| Wizzup | sofiasip/sip/sip_2exs4all_2enl0 | 13:52 |
| Wizzup | idle/irc/fremantle0 | 13:52 |
| Wizzup | which map to the remotes table | 13:53 |
| Wizzup | amongst other things | 13:53 |
| uvos | i not going coperate on that, if the logging backend requires you to give ids provided by certain ids its over | 13:53 |
| uvos | im not useing it | 13:53 |
| uvos | certain libs | 13:54 |
| Wizzup | that's fine, you can evaluate my code when it's done | 13:54 |
| Wizzup | and then make up your mind | 13:54 |
| Wizzup | until I fully understand how it works I'm not going to diverge from what nokia did | 13:54 |
| Wizzup | I don't see the point of using their apis in a way that doesn't actually make it work the way then intedeed do | 13:55 |
| Wizzup | intended* | 13:55 |
| Wizzup | then it's easier to just roll your own | 13:55 |
| Wizzup | for the record I am not saying that you cannot write sphone plus something in local_uid | 13:56 |
| Wizzup | but it's not going to work the way you expect with some of the other components | 13:57 |
| Wizzup | is my guess | 13:57 |
| uvos | so can you provide an example for what is key and value in a header | 13:59 |
| uvos | for message/sms/call | 13:59 |
| Wizzup | it's going to take me time to figure out if call or chat message also have it | 14:01 |
| Wizzup | most of headers is just this | 14:01 |
| Wizzup | 20290|34235|message-token|9bac9a4c-5fe3-49f3-b5ee-c213c96bf760 | 14:01 |
| Wizzup | I'd have to write a join and other stuff to see if that's only sms | 14:01 |
| Wizzup | of course the libtelepathy-glib0 examples don't build normally :D | 14:03 |
| Wizzup | I don't know how these message-tokens are used in the conversations ui, yet | 14:04 |
| uvos | https://github.com/maemo-leste/rtcom-eventlogger/blob/d635dd7a9520090b523405ca8531524746451f1a/src/eventlogger.c#L1092 | 14:05 |
| dsc_ | i received a droid4 in the mail (thanks santa) | 14:06 |
| dsc_ | it runs an old android version | 14:06 |
| dsc_ | how2maemoleste | 14:06 |
| dsc_ | https://leste.maemo.org/Getting_Started | 14:06 |
| dsc_ | > After updating device firmware with included script (eg. flash-droid-4-fw.sh) | 14:06 |
| Wizzup | https://leste.maemo.org/Motorola_Droid_4#Installation | 14:06 |
| dsc_ | oh. | 14:07 |
| dsc_ | thx | 14:07 |
| Wizzup | also note | 14:07 |
| Wizzup | Check what kernel version your Android OS runs. For this go to Settings -> About phone. Slide to the bottom, where you can see "Kernel version". If you have at least 3.0.8, you may skip "Updating Android" step below. | 14:07 |
| uvos | probubly just remove the https://leste.maemo.org/Getting_Started installation to SD Card thing | 14:08 |
| uvos | its just confusing as thats device dependant | 14:08 |
| Wizzup | feel free :p | 14:08 |
| uvos | drop a hint to look at the device pages instead | 14:08 |
| dsc_ | Wizzup: seems to be 3.0.8 yep | 14:08 |
| uvos | dsc_: also think about if you want android 7 on it too | 14:08 |
| uvos | its alot easier to install los first and then leste | 14:09 |
| uvos | dosent matter if you dont intend to use android also | 14:09 |
| bencoh | yeah, I'd recommand installing lineageOS on it as well | 14:09 |
| Wizzup | I sent it to dsc for development purposes | 14:09 |
| uvos | Wizzup: well compearing with los is usefull :P | 14:09 |
| uvos | for kernel development | 14:09 |
| dsc_ | I seem to be stuck in fastboot mode, it says the device is LOCKED - maybe that has something to do with it | 14:45 |
| dsc_ | > Start the device in fastboot mode. For this press power button and bottom volume key simultaneously and release them after a second. | 14:46 |
| dsc_ | or can I just proceed with `sudo fastboot flash mbm ...` now? | 14:48 |
| parazyd | 14:49 | |
| dsc_ | https://i.imgur.com/PdRcRRG.jpg | 14:57 |
| uvos | yes | 14:59 |
| dsc_ | ok :) | 15:01 |
| uvos | please note that at least fastboot v30.0 is needed | 15:03 |
| uvos | this version is quite recent | 15:03 |
| uvos | the wiki dosent tell you.. | 15:03 |
| Wizzup | really? I used fastboot from android-tools 8.1.0 and it worked fine | 15:04 |
| uvos | that should be v30 no? | 15:06 |
| uvos | anyhow in the 29 series there is a bug that prevents it from working without flash raw | 15:07 |
| uvos | and maybe below 29 too | 15:07 |
| uvos | (but not very old versions before 29, not sure where the bug was introduced) | 15:08 |
| uvos | i think it was intrduced in 27 | 15:08 |
| uvos | iirc | 15:08 |
| uvos | so 2017 | 15:08 |
| dsc_ | ok, up and running :) | 15:14 |
| Wizzup | deb https://maedevu.maemo.org/leste beowulf-devel main contrib non-free | 15:16 |
| Wizzup | add that one to sources.list or sources.list.d | 15:16 |
| Wizzup | and apt update && apt dist-upgrade | 15:16 |
| dsc_ | can I get access via SSH through micro-USB somehow or does it need to be on wifi | 15:18 |
| uvos | sure there is usbnet | 15:18 |
| uvos | also there is serial on the usb port if you conect a ttl->usb there | 15:19 |
| Wizzup | https://leste.maemo.org/Status/USB_Peripheral | 15:20 |
| Wizzup | however, usbnet gets flaky when the device thinks it is fully charged | 15:20 |
| bencoh | much reminds me I still need to understand why usbnet doesn't behave here | 15:43 |
| bencoh | (it used to work on my own custom kernel from 2~3y ago) | 15:43 |
| bencoh | s/much/which/ | 15:43 |
| bencoh | Wizzup: by flaky, do you mean it connects and immediatly disconnects? | 15:43 |
| bencoh | (ie the usb device is shown as connected then disconnected on host) | 15:45 |
| Wizzup | bencoh: yes | 15:45 |
| bencoh | oh | 15:45 |
| bencoh | here I think it happens even when not fully charged (I'm pretty certain) | 15:46 |
| Wizzup | might depend on the table | 15:46 |
| Wizzup | cable* | 15:46 |
| bencoh | well, I tried with various cables, but ... | 15:46 |
| bencoh | (and it definitely used to work before I moved to leste) | 15:46 |
| bencoh | (and fastboot seems to work) | 15:46 |
| bencoh | but if others are experiencing something similar, then ... interesting | 15:47 |
| bencoh | tbh I think it's related to how vbus events are handled | 15:47 |
| Wizzup | freemangordon: wg | 17:12 |
| Wizzup | wb* | 17:12 |
| freemangordon | hi! | 17:13 |
| freemangordon | No fish in Chalchidiki sea so I decided to get back home one day earlier :) | 17:15 |
| Wizzup | aw :( | 17:17 |
| freemangordon | well, not that bad, I caught enough fish this year | 17:18 |
| Wizzup | there is slowly some rtcom/conversations ui movement as well | 17:19 |
| freemangordon | nice | 17:20 |
| freemangordon | I was thinking about vrfb rotation | 17:20 |
| freemangordon | I will send a mail to tomi/laurent, to get some pointers on the omplementation | 17:20 |
| Wizzup | makes sense | 17:22 |
| freemangordon | *implementation | 17:22 |
| kona | wizzup: bluetooth yes | 18:08 |
| kona | i didnt grok the uptime comment | 18:10 |
| Wizzup | it's like 27000 days | 18:11 |
| Wizzup | if I read correctly | 18:11 |
| uvos | the screenshot shows 10k days uptime | 18:12 |
| uvos | 18937 days to be exact | 18:12 |
| uvos | or 51 years | 18:12 |
| uvos | that happens to be the time since 1970 :) | 18:13 |
| Wizzup | yeah | 18:13 |
| Wizzup | usually 'uptime' does not get it wrong though | 18:13 |
| Wizzup | so that was surprising | 18:13 |
| kona | oh wow. thanks neofetch. | 18:13 |
| kona | kali nethunter runs in some container so maybe thats causing it to get bad results? | 18:15 |
| uvos | freemangordon: | 18:42 |
| uvos | i think i know how xorg rotates | 18:43 |
| uvos | in general | 18:43 |
| uvos | so xf86Rotate sets a pixmap transform on the xorg drawable | 18:43 |
| freemangordon | how? | 18:43 |
| uvos | and then glamor rotates in gl | 18:43 |
| uvos | or other backends rotate | 18:43 |
| uvos | like exa dose to | 18:43 |
| uvos | in hw | 18:43 |
| uvos | using the same code as rotating any other xorg pixmap/drawable | 18:44 |
| freemangordon | hmm | 18:45 |
| freemangordon | but this is not really HW rotation in case of omap3/4 | 18:45 |
| uvos | well its rotating on sgx | 18:45 |
| uvos | this works fine perf wise on wayland | 18:45 |
| freemangordon | not really | 18:45 |
| freemangordon | this halves the FPS | 18:46 |
| freemangordon | IIUC | 18:46 |
| uvos | thats not what i see in sway/gears | 18:46 |
| freemangordon | with 100% cpu oad | 18:46 |
| freemangordon | run glmark | 18:46 |
| uvos | well i cant because i have to upgrade mesa first | 18:46 |
| freemangordon | esgears is too small (300x300) | 18:46 |
| uvos | its full screen here | 18:46 |
| uvos | sway makes everything fullscreen ;) | 18:46 |
| bencoh | isn't there some dmabuf-powered / mem2mem infra for DMR allowing basic transformations (ie rotation)? | 18:47 |
| freemangordon | no | 18:47 |
| uvos | there are kms planes instead | 18:47 |
| freemangordon | also, rotation is not really 'basic' transformation :) | 18:47 |
| uvos | anyhow | 18:47 |
| uvos | thats how it rotates | 18:48 |
| uvos | make of it what you will | 18:48 |
| freemangordon | ok | 18:48 |
| freemangordon | uvos: rotating through GL is suboptimal. No matter what you do, you don;t have zero-copy | 18:51 |
| uvos | sure its not optimal, im just saying this is how it works and it should work fine on omap* using this path. | 18:52 |
| uvos | we know first hand that this path has a perf hit | 18:53 |
| freemangordon | i.e. - you have some pixmap already rendered. you need to upload that to a texture and then send that texture through a shader | 18:53 |
| uvos | its slower on wayland by about 1/3 here | 18:53 |
| freemangordon | on d4, right? | 18:53 |
| uvos | and its slower on pp with glamor too from what others have stated | 18:53 |
| uvos | yeah | 18:53 |
| freemangordon | imagine on n900/n9/50 | 18:53 |
| uvos | regarding the uploading | 18:54 |
| freemangordon | no, the way to have the rotation is through tiler | 18:54 |
| uvos | that should not happen | 18:54 |
| uvos | idealy | 18:54 |
| uvos | since on wayland for instances everyting is on sgx | 18:54 |
| freemangordon | well, yeah | 18:54 |
| uvos | qt renders its buffer with gl, passes it to the wayland wm, and then the wm rotates with gl and outputs | 18:54 |
| uvos | thats how its supposed to work | 18:55 |
| uvos | and ofc this is ideal anywhere where your gpu as its own ram | 18:55 |
| bencoh | well, there is a reason why qt5/wayland nemomobile was slower, and was never ported to n900 :) | 18:56 |
| freemangordon | anyway, on omaps we have a HW that can rotate with no perf hit | 18:57 |
| uvos | i think ram plays a big part to | 18:57 |
| uvos | but yeah | 18:57 |
| freemangordon | so I see no reason not to use it | 18:57 |
| uvos | im not advocating for this path at all | 18:57 |
| freemangordon | yeah, sure | 18:57 |
| uvos | im just saying where it is and why it works like this | 18:57 |
| freemangordon | thanks for the explanation though | 18:57 |
| bencoh | freemangordon: looks like this landed in mainline: drivers/gpu/drm/drm_blend.c | 18:58 |
| freemangordon | what is this? | 18:58 |
| bencoh | (to be honest I thought it remained a samsung-only fantasy) | 18:58 |
| bencoh | freemangordon: pretty much what I mentioned, or so I think | 18:58 |
| uvos | seams to implement the kms planes (just read the comment at the top first i hear of this) | 18:59 |
| bencoh | although I'm not certain it's actually used anywhere / really implemented by any driver | 18:59 |
| uvos | bencoh: seams to be implmenting this: https://www.kernel.org/doc/html/v4.15/gpu/drm-kms.html#plane-functions-reference | 19:00 |
| freemangordon | hmm, I think omapdrm implements at least the rotation property | 19:00 |
| uvos | no we havend found anyone useing that interface either | 19:00 |
| bencoh | I wonder if samsung uses it at least | 19:01 |
| bencoh | I guess I could check | 19:01 |
| uvos | android might generally | 19:01 |
| bencoh | freemangordon: you were right about the property: 14 171 drivers/gpu/drm/omapdrm/omap_plane.c <<omap_plane_install_properties>> | 19:02 |
| bencoh | drm_plane_create_rotation_property(plane, | 19:02 |
| freemangordon | omapdrm seems to implement this | 19:02 |
| freemangordon | but no userspace is using it it seems | 19:02 |
| bencoh | what's supposed to perform the actual rotation? | 19:03 |
| freemangordon | TILER on omap4 | 19:03 |
| uvos | tiler in omapdrms case | 19:04 |
| bencoh | is that implemented kernel-side? | 19:04 |
| freemangordon | yes | 19:04 |
| bencoh | ah right, OMAP_DSS_ROT_TILER | 19:04 |
| bencoh | well, it might actually be the way then | 19:04 |
| freemangordon | see omap_gem_init | 19:04 |
| uvos | there is even a modesetting patch to use this fmg found | 19:04 |
| freemangordon | yes, but for omap3 we need VRFB rotation | 19:04 |
| bencoh | ah | 19:04 |
| uvos | but implementing it for omap3 would be hardish | 19:05 |
| freemangordon | not really, VRFB seems way simpler than TILER | 19:05 |
| uvos | freemangordon: looks like android has drm_hwcomposer | 19:05 |
| uvos | that uses this too | 19:05 |
| freemangordon | ttyl, dinner | 19:05 |
| bencoh | enjoy! :) | 19:05 |
| Wizzup | uvos: did you move the screen vibration checkmark from display to profiles, or was it just always there | 22:58 |
| Wizzup | I vaguely recall it being in settings -> display | 22:58 |
| uvos | i moved it | 23:25 |
| uvos | its profile dependant too now, just like the touchscreen sound | 23:26 |
| Wizzup | it's much harder to find though I think | 23:26 |
| Wizzup | maybe I am just used to it | 23:26 |
| uvos | sure | 23:27 |
| uvos | but not realy realtive to touchscreen sounds | 23:27 |
| uvos | the profile ui could telegraph more what its for for sure | 23:27 |
| uvos | its also off by default now | 23:29 |
| uvos | btw | 23:29 |
| uvos | but we can change that back if you like | 23:29 |
| uvos | since imo the feedback makes sense only on restive ts where you dont know if you pressed hard enough to register the touch, while on capacative ts if you can feel the ts touching your finger its registering a touch. | 23:31 |
| Wizzup | I don't care much about the default, I just implemented the maemo functionality while learning REing | 23:35 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
