System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
xmn has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
xmn has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
xmn has joined #maemo-leste
joerg has quit [Ping timeout: 265 seconds]
joerg has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
mardy has joined #maemo-leste
joerg has quit [Excess Flood]
joerg has joined #maemo-leste
Twig has joined #maemo-leste
pere has quit [Ping timeout: 250 seconds]
<Wizzup>
calebtheythem[m]: weird, did you do something?
Twig has quit [Ping timeout: 264 seconds]
pere has joined #maemo-leste
Pali has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
Wizzup: dident gitorious.org partner with archive.org too keep itself avaible after it shutdown? is there a mirror somewhere that still works? www.gitorious.org dosent.
<uvos>
Wizzup: i want to grab some slightly leste related stuff, namely mbm source
<Wizzup>
got some specific links?
<Wizzup>
I can ask a colleage and yeah the files are somewhere but it's not up
<Wizzup>
it's kind of in limbo and I've been asking them many times
<Wizzup>
I'll ask again, see if someone can bring it up
<Wizzup>
emu
<Wizzup>
sry
elastic_dog has quit [Ping timeout: 250 seconds]
elastic_dog has joined #maemo-leste
<uvos>
is there a way to get what process provides a dbus interface?
<uvos>
ie i want to know what process provides org.freedesktop.ColorManager for instance
<Wizzup>
that's probably some lcms thing, but I am not sure, maybe one of those dbus inspetors can tell you
<bencoh>
I think mdbus2 can help
<bencoh>
but I don't know how much
<bencoh>
and iirc this depends on whether the target process implements dbus introspection(?)
<uvos>
bencoh: so mdbus has the option --show-pids
<uvos>
bencoh: but i cant make it work on any interface
<uvos>
bencoh: pobubly user error
<bencoh>
I vaguely remember jo.erg saying that most of nokia stuffed missed proper introspect implem
<bencoh>
stuff*
<uvos>
well im poking around in xdg stuff
<uvos>
so i suspect that kde/lxqts implementations offer proper introspection
<uvos>
all the other introsepction features wrok
<parazyd>
Wizzup: d4 kernel is ready, managed to build last night
<parazyd>
Wizzup: lmk about pvr mesa and anything I can do
<Wizzup>
parazyd: great, freemangordon might have some new patches later
<Wizzup>
parazyd: regarding mesa, there's just the two patches I shared that are not cleaned up
<Wizzup>
I recall you asked a question about it but I think I forgot to answer
<parazyd>
I think I just asked if you committed it
<Wizzup>
ah, ok, I did not
<Wizzup>
I think there's two things
<Wizzup>
The first thing is the patch to the source itself to make freedreno build
<Wizzup>
and the other stuff is debian/rules + meson "fixes"
<uvos>
freemangordon / Wizzup: you cant create multiple HDStatusMenuItem from one plugin right?
<Wizzup>
The freedreno build fix is not upstream atm, so I suggest we just tack it in our repo for now, and the debian/rules and meson we want anyway
<Wizzup>
uvos: I don't know, I also don't know about the window stack thing you mentioned
<Wizzup>
uvos: I assume not though
<uvos>
:(
<Wizzup>
why?
<uvos>
looks like i cant create a thing that creates a HDStatusMenuItem for eatch xdg StatusNotifierItem
<uvos>
other than directly changing hildons-status-menu
<Wizzup>
wouldn't that potentially be a lot of icons?
<uvos>
Wizzup: not really
<uvos>
its the system tray
<uvos>
not notifications
<uvos>
like the icon networkmanager creates
<uvos>
not like the stuff libnotify creates
<Wizzup>
aha
<uvos>
i think this makes plenty of sense to translate to HDStatusMenuItem
pere has quit [Ping timeout: 256 seconds]
pere has joined #maemo-leste
<uvos>
i cant debug a silly mameo-launcher application
<uvos>
so i run gdb maemo-summoner
<uvos>
run /usr/bin/hildon-status-menu.launch
<uvos>
and it ends in "maemo-summoner" received signal SIGILL, Illegal instruction.
<uvos>
bt is just ??
<uvos>
i have debug symbols for summoner
<uvos>
the application itself works fine without gdb
<Wizzup>
uvos: sigill is openssl
<Wizzup>
just continue
<Wizzup>
this is not summoner related
<uvos>
it segfaults immidatly after
<Wizzup>
also see the wiki debugging page
<uvos>
altho it works fine without gdb
<uvos>
(this is repo hildons-status-menu)
pere has quit [Ping timeout: 250 seconds]
Wikiwide has quit [Ping timeout: 250 seconds]
<uvos>
so now hildon-status-menu aborts with a g_assert but it dosent print the message
<uvos>
i can see g_assertion_message in the call stack
<uvos>
but something maemo-summoner or status-menu eats the messages
<uvos>
honestly writing a plugin for status-menu is extreamly frustrating
pere has joined #maemo-leste
devrtz[m] has quit [K-Lined]
scops has quit [K-Lined]
mighty17[m] has quit [K-Lined]
calebtheythem[m] has quit [K-Lined]
ungeskriptet[m] has quit [K-Lined]
asriel_dreemurr has quit [K-Lined]
tvall has quit [K-Lined]
argon has quit [K-Lined]
MartijnBraam[m] has quit [K-Lined]
M1peter10[m] has quit [K-Lined]
tvall has joined #maemo-leste
panzeroceania has quit [Ping timeout: 264 seconds]
Treebeard has joined #maemo-leste
scops has joined #maemo-leste
Treebeard has quit [Changing host]
mighty17[m] has joined #maemo-leste
Treebeard has joined #maemo-leste
BenLand100 has quit [Ping timeout: 260 seconds]
M1peter10[m] has joined #maemo-leste
argon has joined #maemo-leste
devrtz[m] has joined #maemo-leste
ungeskriptet[m] has joined #maemo-leste
MartijnBraam[m] has joined #maemo-leste
calebtheythem[m] has joined #maemo-leste
asriel_dreemurr has joined #maemo-leste
Treebeard is now known as BenLand100
nohit has quit [Ping timeout: 265 seconds]
panzeroceania has joined #maemo-leste
nohit has joined #maemo-leste
<freemangordon>
zmatt: either I am stupid, or kernel TILER code is more buggy that is seems. May I ask you: are tiles rectangular or each tile can have different w/h as long as w*h*bpp = 4096?
<freemangordon>
third day in a row I am unable to come up with a sane algo that backs padding to dummy page :)
<freemangordon>
*with a dummy page
<bencoh>
is that so that it can be page-aligned?
<freemangordon>
rephrase please
tvall has quit [Quit: Client limit exceeded: 20000]
scops has quit [Quit: Client limit exceeded: 20000]
<bencoh>
freemangordon: are tiles supposed to meet the w*h*bpp = 4096 so that tiles are page aligned?
tvall has joined #maemo-leste
<freemangordon>
tiles themselves are not page aligned
scops has joined #maemo-leste
<freemangordon>
the backing mmory is
<freemangordon>
*memory
<freemangordon>
but I can't understand from the docs what dimensions can a tile have
<freemangordon>
if it is rectangular, then current driver code does very bad things :)
Twig has joined #maemo-leste
<zmatt>
freemangordon: by "tile" you mean an area backed by a physical page?
<uvos>
freemangordon: any idea how to make hildon-status-menu show any output? g_critical(), assert, printf - anything
<uvos>
its DEBUG_OUTPUT=1
vectis has quit [Ping timeout: 268 seconds]
<bencoh>
uvos: I think it logs to logger/syslog but I might be wrong
vectis has joined #maemo-leste
<Wizzup>
uvos: maybe add that (DEBUG_OUTPUT=1) to wiki page
<freemangordon>
zmatt: well, thats one of the things I am trying to understand - what is tile. Like - is 1024x1x4 area backed by a single page? If yes, then obviously it is a tile.
<zmatt>
no
<zmatt>
a single PAT page is 64x64 pixels * 1 byte/pixel or 64x32 pixels * 2 bytes/pixel or 32x32 pixels * 4 bytes/pixel
<freemangordon>
so, to 'describe' 1024x1x4 area we need several 32x32x4 'slots', correct?
<zmatt>
(the 15-bit PAT page number consists of the top 7 bits of the y-coordinate and the top 8 bits of the x-coordinate)
<zmatt>
yes, it'll round up to 1024x32x4
<freemangordon>
zmatt: which translates to what in practice? that we need 32 32x32x4 'blocks' to describe 1024x1x4
<freemangordon>
ok, then we have a biger issue
<freemangordon>
*bigger
<zmatt>
TILER virtual memory is reserved in units I just mentioned
<freemangordon>
because the number of pages calculated by kernel for such 1024x1x4 framebuffer is exactly one ;)
<zmatt>
you sure about that?
<freemangordon>
I think so, lemme show you the code
<freemangordon>
ok, thanks for the conversation, at the end of the day I am relaxed that everything is ok, it is just that simply I am stupid :)
<dreamer>
:D
<dreamer>
at least you're relaxed about it
<freemangordon>
sure I am
<freemangordon>
it would have been much worse if there is a bug in kernel ;)
<freemangordon>
because stupidity is unfixable, si I have to do nothing about it :D
<freemangordon>
*so
<zmatt>
ah you found it
<freemangordon>
yeah
<freemangordon>
somehow I've missed that when I was looking for where size is calculated
<freemangordon>
now I will be able to finally implement that page aligned buffer padding algo
<zmatt>
freemangordon: had I sent you this link yet? https://pastebin.com/raw/pWWtEiXc it shows how the TILER addressing actually works
<freemangordon>
yes, but what wasn't making sens to me was the buffersize I was calculating (I made a userspace test program that emulates TILER BOs allocation to test my algo)
Twig has joined #maemo-leste
<freemangordon>
so my understanding of a 'tile' (128x128 bytes in 4bpp mode) was not matching the input data
<zmatt>
128x128*4 would be 64KB
<zmatt>
every tile is 4KB since it's backed by a page
<freemangordon>
but now everything will fit tight, expect patch v3 most-probably tomorrow
<freemangordon>
yeah, it is 32x32
<freemangordon>
typo
<freemangordon>
anyway, thanks for the conversation, obviously I had to talk about that with someone. Usually that helps a lot to find your own mistakes.
<zmatt>
np
<dreamer>
you have reduced zmatt to a rubber ducky
<freemangordon>
dreamer: come on
<zmatt>
well, I'm still a *bit* more interactive than a rubber ducky... they're great listeners but they don't really provide much feedback ;)