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