xmn has quit [Read error: Connection reset by peer]
xmn has joined #maemo-leste
xmn has quit [Ping timeout: 250 seconds]
_inky has quit [*.net *.split]
sunshavi has quit [*.net *.split]
The_Niz has quit [*.net *.split]
asriel has quit [*.net *.split]
Wikiwide has quit [*.net *.split]
asriel has joined #maemo-leste
sunshavi has joined #maemo-leste
The_Niz has joined #maemo-leste
_inky has joined #maemo-leste
Wikiwide has joined #maemo-leste
mardy has joined #maemo-leste
joerg has quit [Ping timeout: 256 seconds]
joerg has joined #maemo-leste
pere has quit [Ping timeout: 240 seconds]
pere has joined #maemo-leste
Twig has joined #maemo-leste
Twig has quit [Ping timeout: 250 seconds]
Pali has joined #maemo-leste
Pali has quit [Ping timeout: 250 seconds]
dsc_ has quit [Ping timeout: 245 seconds]
dsc_ has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
i think we should think about defaults a bit more
<uvos>
like ppl i hand the bionic (which runs defaults) get confused with how the power button works
<uvos>
or how we all install simple-brigtness-applet because going into the settings to change the brigtness is pretty lame
<Wizzup>
mhm
<freemangordon>
uvos: what's wrong with how power button works?
System_Error has quit [Remote host closed the connection]
<sicelo>
doesn't follow android standards
<freemangordon>
ah, I see
<sicelo>
short press = lock/unlock. long press = system/boot options
<uvos>
having to double click to turn the dsiplay off but click once to turn the dsiplay back on
<uvos>
messes with peoples muscel memory form android and ios yeah
<uvos>
theres nothing wrong with it per say
<dsc_>
how does the automatic brightness works?
<uvos>
dsc_: wdym
<sicelo>
dsc_: ALS sensor, as always :-)
<dsc_>
gotcha
<Wizzup>
uvos: I think eventually we will want to rework some of how the status applet works from UX pov, because eventually it just "fills up" with applets
<Wizzup>
but that is a 2022 or 2023 thing :P
<sicelo>
do they begin scrolling when you have many of them? i've never had a lot of them, so i never really noticed
<Wizzup>
even if they scroll it doesn't work
<Wizzup>
as in it's just not ok
<Wizzup>
I mean from usability pov
<Wizzup>
if you install wireguard and tor status applet you already get two more
<Wizzup>
it fills up
<RedW>
7
<sicelo>
8
<sicelo>
:)
<RedW>
oops, wrong window :)
<dsc_>
how do I CTRL^D with a droid 4 :D
<uvos>
Wizzup: the status applet runs the applets in a hildon-pannable-area
<uvos>
Wizzup: so id be suprised if it dosent start scrolling
<uvos>
aka its a bug if it dosent
<uvos>
wireguard and tor status applet should ony appear if they are configured really
<uvos>
btw
xmn has joined #maemo-leste
<freemangordon>
:nod:
<Wizzup>
uvos: no, because you can activate them in system mode at any time
<Wizzup>
I am talking about the status area button
<freemangordon>
not only configured, but active, no?
<Wizzup>
and the way to activate them is through that button
<Wizzup>
freemangordon: the icon in the status area, yes
<uvos>
no sure how having the status area button makes sense
<uvos>
if thereis no vpn configured
<Wizzup>
right so I was talking about that window with the buttons
<freemangordon>
ok, but I don;t think scrolling is that bad there
<Wizzup>
freemangordon: ok, I never tried
* uvos
confused
<freemangordon>
Wizzup: the point is that buttons should not be there unless those are active
<uvos>
what window with buttons? not hildon-status-menu?
<Wizzup>
uvos: I think we're on the same page, I do mean hildon-status-menu
<uvos>
right thos buttons shold only be there if activating the vpn is a possiblity
<uvos>
ie its configured
<Wizzup>
freemangordon: that is not true for internet connection, or profiles, clock, bluetooth
<freemangordon>
Wizzup: what is the functionlaity of those buttons?
<Wizzup>
freemangordon: to enable tor/wireguard system wide for an active connection
<freemangordon>
ah
<Wizzup>
there's also the openvpn one btw
<freemangordon>
well, yeah, ok
<Wizzup>
it might make sense to 'group' them eventually
<freemangordon>
I wonder if status menu supports groups
<Wizzup>
but that's a whole different thing
<Wizzup>
in any case 2022/2023 :P
<freemangordon>
I wouldn't be surprosed if groups are already supported
<freemangordon>
bu yeah, 2023
<freemangordon>
:)
<uvos>
Wizzup: "uvos: no, because you can activate them in system mode at any time" yeah but what happens if i activate a vpn but there is no account configured?
<uvos>
ie just haveing the applet installed i have it in hildon-status-menu
<uvos>
ie the workflow that makes sense to me is: open settings -> configure a network -> now the button pops up in status-menu for me to enable or disable it. anyhow ttyl
_inky has quit [Ping timeout: 244 seconds]
_inky has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
<Wizzup>
uvos: I guess for tor you don't need an account
<Wizzup>
but yes for wg or openvpn this is true
* sicelo
also doesn't see ux problem with scrolling in status area - android scrolls it too, ios too. it's unavoidable. and yes, best way to manage it is just to avoid having too many things there, especially inactive ones
<bencoh>
well, to be fair on android you usually need to scroll for notifications
<bencoh>
not for always-displayed plugins
<sicelo>
at least on my android 8, when pulling down the notification drawer (which contains what is roughly hildon's status menu), i can only select among 5 items. then, as i continue pulling it down, more of them appear. in my case, 9 more appear
<sicelo>
so i guess if we take android as a benchmark for status menu, hildon problem is that our items individually take a lot of space, and thus two per column, so it fills up fast as a result
<bencoh>
yeah, a compact layout/mode would probably help here
<freemangordon>
hmm, one cannot allocate TILER BOs through dma_buf API
* bencoh
headscratches
<bencoh>
how are you supposed to allocate it then?
<freemangordon>
bencoh: omap_bo_new
<freemangordon>
which is omap specific
<bencoh>
uh
<bencoh>
sad
<freemangordon>
yeah
<freemangordon>
IIUC you can;t use gbm_bo_create and get a TILER BO
<freemangordon>
which leaves us with the only option to use xf86-video-omap if we and sane performance with rotated display
<freemangordon>
s/we and/we want
<bencoh>
or add full dmabuf support to the omap/tiler/whatever drivers galaxy
<bencoh>
(at least to the point where one can allocate tiler buffers)
<freemangordon>
I don't think I am the one to do that
<freemangordon>
not without some hints from the maintainers
<freemangordon>
I wrote a mail, still no answer
<bencoh>
I wonder if there is any reason notto default to tiler buffers on omap4/omap5
<freemangordon>
no idea
<freemangordon>
but dma_buf defaults to CMA
<bencoh>
hmm
<bencoh>
don't you just mmap() on some fd to get buffers?
<freemangordon>
it is not that simple
<bencoh>
well, and/or use some ioctl before/after
<bencoh>
anyway, it should still be bound to some device
<freemangordon>
the point is that SGX(for example) should see the same memory correctly
<freemangordon>
but, there is a note that TILER memory is shmem memory
<freemangordon>
I don;t understand what is that supposed to mean
<bencoh>
yeah, I get that part, I'm just wondering what actually happens when you allocate a dmabuf-able buffer
<freemangordon>
I don;t
<freemangordon>
so please explain what "shmem" is
<bencoh>
shmem, as in /dev/shm, or as in "memory shared between cpu and sgx, and mapped at the same address"?
<bencoh>
(ah, I wrote that "I get that part" before you mentioned shmem btw)
<freemangordon>
but how it can be mapped at the same address, given that SGX has its own mmu?
<freemangordon>
the only way to use the tiler is to pass flags through userspace API
<freemangordon>
omap_bo_new()
<freemangordon>
but, your question is absolutely valid - why all BOs are not allocated through the tiler?
<bencoh>
I guess it wouldn't make any sense on non-tiler platforms
<bencoh>
but still
<freemangordon>
this is omapdrm which supports TILER rotation only
<freemangordon>
lets forget about omap3 for a while
<bencoh>
ah :)
<freemangordon>
tmlind: any clue? ^^^
<bencoh>
then yeah, I don't see why
<freemangordon>
for VRFB it is another story
<freemangordon>
because we have limited contexts (12 on omap3) so it makes sense to assign VRFB context to BO only when really needed
<bencoh>
unless ... if TILER has a limited number of "buffers"
<freemangordon>
yeah
<freemangordon>
but I was unable to find the TRM to see how this works
<bencoh>
hmm, I think I downloaded the TRM at some point, lemme check
<bencoh>
iirc TI removed some manuals from their website right?
<freemangordon>
and because my knowledge on DMA API and MMUs ends here (or rather has ended 200 meters before here) I don;t know if it is possible to somehow "migrate" non-tiler (or non-vrfb) BO to TILER one
<buZz>
zmatt used to be the TILER expert
<bencoh>
meh, I have the omap3530 one here, no omap4
<buZz>
back in #dragonbox-pyra
<sicelo>
omap 4 trm? i have it
<freemangordon>
buZz: it is not about the TILER, but about how the rest of the system sees such a buffer
<bencoh>
right, zmatt had it work by kludging part of the driver(s), I don't think it ever got merged. and that was on omap5
<bencoh>
oh, found it on the desktop I'm connected from, silly :)
<bencoh>
(uploading it ...(
<freemangordon>
like - we allocate a non-TILER BO that is send to SGX
<freemangordon>
SGX sets it MMU to access that BO
<sicelo>
ah, you'll be faster (bencoh). was sending it to dropbox just now
<bencoh>
sicelo: yeah I figured :)
<freemangordon>
now, if we want to transform this BO to a TILER one, how SGX knows this change has happened to re-program its MMU?
<freemangordon>
but, IIUC, TILER is just a kind of iommu
<freemangordon>
like, it remaps memory accesses, no?
<freemangordon>
so, implementation details are not important
<freemangordon>
also, even if TILER has unlimited 'buffers', VRFB does not, so we are in the same situation
<bencoh>
looks like TILER is actually a rotation engine as well
<freemangordon>
like VRFB
<freemangordon>
and yes, R in tileR is for rotation :)
<bencoh>
but yeah, it's basically all about address transformation
<bencoh>
meaning that it doesn't really "perform" the rotation, it "just" translate addresses to effectively return the pixels that should be addressed after rotation
<bencoh>
or so I understand it
<freemangordon>
my understanding is the same
<bencoh>
which is kinda funny, because it means that any access to a "rotated" buffer will go through it
<bencoh>
I wonder how expensive (energy-wise) that thing is
<bencoh>
maybe that's the reason it's not enabled by default btw
<bencoh>
either that, or erratums that make it buggy
<bencoh>
errata*
<freemangordon>
as simple address translation should not be that expensive
<bencoh>
dunno, maybe you're right
<buZz>
freemangordon: ah well, just saying it might not hurt to ask him for things that lack in understanding
<buZz>
guy works with TI stuff a -lot-
<bencoh>
another thing is ... what happens when it tries to access memory ....
<freemangordon>
we have a page fault
<freemangordon>
:)
<bencoh>
no I mean ... let's say you access a "rotated" buffer
<bencoh>
so it goes and fetches the right pixels(bytes) for you
<bencoh>
but instead of fetching a full line from RAM, it needs to fetch a "column", ie a pixel from every actual line
<bencoh>
doesn't sound super efficient to me, unless it actually fetches the full lines and caches it
<freemangordon>
I doubt it can cache 540x960x4 even for non-rotated scenario
<bencoh>
maybe it only caches macroblocks then
<bencoh>
otherwise it really sounds like a pain
<freemangordon>
but, I don't know how this stuff works, so...
<freemangordon>
they say TILER works on pages only
<bencoh>
yeah, me neither ... I never brought myself to actually read the whole TILER chapter
<freemangordon>
also, there was some note of 'no caching for TILER' somewhere
<freemangordon>
lemme try to find it
<bencoh>
noncached access on ARM really doesn't sound like something we would want
<Wizzup>
last time I asked someone to donate one I got permabanned from ebay
<buZz>
:D :D
<buZz>
yeah 'plz donate your unobtainium to meeeee'
<buZz>
Wizzup: might have more success asking ppl in #maemo :)
<Wizzup>
I don't really need one
<tmlind>
droid4 has obsoleted n950 :)
<tmlind>
well at least for me
* tmlind
used n950 for years until it started breaking for the lcd, then got busy with droid4
<freemangordon>
I have a working one, but I need PVR driver for it :)
<tmlind>
heh ok :) i'm pretty sure it was the 2016 elce in berlin when sre, pavel and i chatted about getting droid4 working as a n900 replacement hardware
<tmlind>
freemangordon: did your rubber pads melt away on n950 into sticky mess?
<freemangordon>
yes
<tmlind>
probably possible to replace with some fuzzy pieces of felt
<freemangordon>
yeah
<freemangordon>
but doesn;t make sence without having SW for it :)
<tmlind>
yeah maybe in few years
<freemangordon>
yeah
argon has quit [Killed (NickServ (GHOST command used by argonn_!~nuclear@31.135.167.133))]
argon has joined #maemo-leste
yanu_ has joined #maemo-leste
avoidr_ has joined #maemo-leste
dsc__ has joined #maemo-leste
<freemangordon>
[ 31318.703] (II) OMAP(0): Successfully initialized the "omap_pvr" sub-module
<freemangordon>
:)
dsc_ has quit [*.net *.split]
yanu has quit [*.net *.split]
avoidr has quit [*.net *.split]
<Wizzup>
neat :-)
<freemangordon>
hmm, how to test solid fill?
<freemangordon>
ah −rect500
<freemangordon>
hmm, seems omap_pvr_drv I found has solid acceleration removed :(
<freemangordon>
I'll haev to implement that
mardy has quit [Quit: WeeChat 2.8]
avoidr_ is now known as avoidr
pere has quit [Ping timeout: 250 seconds]
xmn has joined #maemo-leste
Twig has quit [Ping timeout: 240 seconds]
Wikiwide_ has joined #maemo-leste
Wikiwide_ has quit [Remote host closed the connection]
Wikiwide_ has joined #maemo-leste
pere has joined #maemo-leste
Wikiwide_ is now known as Wikiwide
_inky has quit [Quit: Leaving.]
_inky has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
historicly lots of exa implementations where slower than cpu only
<uvos>
maybe the removed this because its perf was bad
<uvos>
just wildly guesing here
uvos has quit [Read error: Connection reset by peer]