| calebtheythem[m] | my photon Q display has died :/ https://p.calebs.dev/vexibuduza.cs | 00:16 |
|---|---|---|
| uvos | uff | 00:41 |
| uvos | maybe this happend to mine too, it lights up but nothing happens (not even mbm shows) | 00:42 |
| Wizzup | calebtheythem[m]: weird, did you do something? | 09:02 |
| 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. | 11:14 |
| uvos | Wizzup: i want to grab some slightly leste related stuff, namely mbm source | 11:15 |
| Wizzup | got some specific links? | 11:17 |
| Wizzup | I can ask a colleage and yeah the files are somewhere but it's not up | 11:17 |
| Wizzup | it's kind of in limbo and I've been asking them many times | 11:17 |
| uvos | Wizzup: everything here: http://web.archive.org/web/20130816141615/http://gitorious.org/droid this contains reverse engeneered a85x mbm + hacked qemu that emulates a a855 enough to boot mbm and some other stuff | 11:20 |
| uvos | i wanted to save it for future referance | 11:20 |
| Wizzup | I'll ask again, see if someone can bring it up | 11:25 |
| Wizzup | emu | 11:30 |
| Wizzup | sry | 11:30 |
| uvos | is there a way to get what process provides a dbus interface? | 12:04 |
| uvos | ie i want to know what process provides org.freedesktop.ColorManager for instance | 12:04 |
| Wizzup | that's probably some lcms thing, but I am not sure, maybe one of those dbus inspetors can tell you | 12:07 |
| bencoh | I think mdbus2 can help | 12:44 |
| bencoh | but I don't know how much | 12:44 |
| bencoh | and iirc this depends on whether the target process implements dbus introspection(?) | 12:45 |
| uvos | bencoh: so mdbus has the option --show-pids | 12:45 |
| uvos | bencoh: but i cant make it work on any interface | 12:45 |
| uvos | bencoh: pobubly user error | 12:45 |
| bencoh | I vaguely remember jo.erg saying that most of nokia stuffed missed proper introspect implem | 12:47 |
| bencoh | stuff* | 12:47 |
| uvos | well im poking around in xdg stuff | 12:47 |
| uvos | so i suspect that kde/lxqts implementations offer proper introspection | 12:47 |
| uvos | all the other introsepction features wrok | 12:47 |
| parazyd | Wizzup: d4 kernel is ready, managed to build last night | 12:57 |
| parazyd | Wizzup: lmk about pvr mesa and anything I can do | 12:58 |
| Wizzup | parazyd: great, freemangordon might have some new patches later | 12:58 |
| Wizzup | parazyd: regarding mesa, there's just the two patches I shared that are not cleaned up | 12:58 |
| Wizzup | I recall you asked a question about it but I think I forgot to answer | 12:59 |
| parazyd | I think I just asked if you committed it | 12:59 |
| Wizzup | ah, ok, I did not | 13:00 |
| Wizzup | I think there's two things | 13:00 |
| Wizzup | The first thing is the patch to the source itself to make freedreno build | 13:01 |
| Wizzup | and the other stuff is debian/rules + meson "fixes" | 13:01 |
| uvos | freemangordon / Wizzup: you cant create multiple HDStatusMenuItem from one plugin right? | 13:01 |
| 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 | 13:01 |
| Wizzup | uvos: I don't know, I also don't know about the window stack thing you mentioned | 13:02 |
| Wizzup | uvos: I assume not though | 13:02 |
| uvos | :( | 13:02 |
| Wizzup | why? | 13:02 |
| uvos | looks like i cant create a thing that creates a HDStatusMenuItem for eatch xdg StatusNotifierItem | 13:02 |
| uvos | other than directly changing hildons-status-menu | 13:03 |
| Wizzup | wouldn't that potentially be a lot of icons? | 13:03 |
| uvos | Wizzup: not really | 13:03 |
| uvos | its the system tray | 13:03 |
| uvos | not notifications | 13:03 |
| uvos | like the icon networkmanager creates | 13:04 |
| uvos | not like the stuff libnotify creates | 13:04 |
| Wizzup | aha | 13:05 |
| uvos | i think this makes plenty of sense to translate to HDStatusMenuItem | 13:05 |
| uvos | i cant debug a silly mameo-launcher application | 15:07 |
| uvos | so i run gdb maemo-summoner | 15:08 |
| uvos | run /usr/bin/hildon-status-menu.launch | 15:08 |
| uvos | and it ends in "maemo-summoner" received signal SIGILL, Illegal instruction. | 15:08 |
| uvos | bt is just ?? | 15:08 |
| uvos | i have debug symbols for summoner | 15:09 |
| uvos | the application itself works fine without gdb | 15:09 |
| Wizzup | uvos: sigill is openssl | 15:16 |
| Wizzup | just continue | 15:16 |
| Wizzup | this is not summoner related | 15:16 |
| uvos | it segfaults immidatly after | 15:16 |
| Wizzup | also see the wiki debugging page | 15:16 |
| uvos | altho it works fine without gdb | 15:16 |
| uvos | (this is repo hildons-status-menu) | 15:16 |
| uvos | so now hildon-status-menu aborts with a g_assert but it dosent print the message | 16:07 |
| uvos | i can see g_assertion_message in the call stack | 16:07 |
| uvos | but something maemo-summoner or status-menu eats the messages | 16:08 |
| uvos | honestly writing a plugin for status-menu is extreamly frustrating | 16:08 |
| 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? | 17:53 |
| freemangordon | third day in a row I am unable to come up with a sane algo that backs padding to dummy page :) | 17:54 |
| freemangordon | *with a dummy page | 17:54 |
| bencoh | is that so that it can be page-aligned? | 17:54 |
| freemangordon | rephrase please | 17:55 |
| bencoh | freemangordon: are tiles supposed to meet the w*h*bpp = 4096 so that tiles are page aligned? | 18:02 |
| freemangordon | tiles themselves are not page aligned | 18:03 |
| freemangordon | the backing mmory is | 18:03 |
| freemangordon | *memory | 18:03 |
| freemangordon | but I can't understand from the docs what dimensions can a tile have | 18:04 |
| freemangordon | if it is rectangular, then current driver code does very bad things :) | 18:04 |
| zmatt | freemangordon: by "tile" you mean an area backed by a physical page? | 19:00 |
| uvos | freemangordon: any idea how to make hildon-status-menu show any output? g_critical(), assert, printf - anything | 19:14 |
| uvos | its DEBUG_OUTPUT=1 | 19:18 |
| bencoh | uvos: I think it logs to logger/syslog but I might be wrong | 19:29 |
| Wizzup | uvos: maybe add that (DEBUG_OUTPUT=1) to wiki page | 19:31 |
| uvos | bencoh: no it dosent | 19:54 |
| uvos | systray_applet_setup: assertion failed: (HILDON_IS_BUTTON(HILDON_BUTTON(hildon_gtk_button_new(HILDON_SIZE_FINGER_HEIGHT)))) | 19:54 |
| uvos | uhh | 19:54 |
| uvos | Wizzup: yeah | 19:54 |
| uvos | ah hildon_GTK_button | 19:59 |
| uvos | confusing | 19:59 |
| 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. | 20:06 |
| zmatt | no | 20:07 |
| zmatt | a single PAT page is 64x64 pixels * 1 byte/pixel or 64x32 pixels * 2 bytes/pixel or 32x32 pixels * 4 bytes/pixel | 20:08 |
| freemangordon | so, to 'describe' 1024x1x4 area we need several 32x32x4 'slots', correct? | 20:08 |
| 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) | 20:09 |
| zmatt | yes, it'll round up to 1024x32x4 | 20:10 |
| freemangordon | zmatt: which translates to what in practice? that we need 32 32x32x4 'blocks' to describe 1024x1x4 | 20:11 |
| freemangordon | ok, then we have a biger issue | 20:11 |
| freemangordon | *bigger | 20:12 |
| zmatt | TILER virtual memory is reserved in units I just mentioned | 20:12 |
| freemangordon | because the number of pages calculated by kernel for such 1024x1x4 framebuffer is exactly one ;) | 20:12 |
| zmatt | you sure about that? | 20:13 |
| freemangordon | I think so, lemme show you the code | 20:13 |
| zmatt | I'm pretty sure that's not true | 20:13 |
| freemangordon | sec | 20:13 |
| freemangordon | see https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/omapdrm/omap_gem.c#L226 | 20:14 |
| freemangordon | int npages = obj->size >> PAGE_SHIFT; | 20:14 |
| freemangordon | and here https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/omapdrm/omap_gem.c#L597 is where the size is calculated | 20:15 |
| zmatt | obj->size has probably already been rounded up? | 20:15 |
| freemangordon | yes, to page :) | 20:15 |
| freemangordon | because outside of TILER a page is enough to back such framebuffer | 20:15 |
| freemangordon | args->size = PAGE_ALIGN(args->pitch * args->height); | 20:16 |
| zmatt | you're probably missing something since TILER buffer allocation most definitely works fine (or did last time I worked on this) | 20:16 |
| freemangordon | yes, maybe I am missing something | 20:16 |
| freemangordon | but anyway, I wanted a confirmation that 'tile' is 32x32x4 in (for 4bpp framebuffes) | 20:17 |
| freemangordon | hmm, maybe you are right | 20:20 |
| freemangordon | zmatt: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/omapdrm/omap_gem.c#L1236 | 20:21 |
| dreamer | lesson 0) zmatt is always right | 20:21 |
| 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 :) | 20:21 |
| dreamer | :D | 20:22 |
| dreamer | at least you're relaxed about it | 20:22 |
| freemangordon | sure I am | 20:22 |
| freemangordon | it would have been much worse if there is a bug in kernel ;) | 20:22 |
| freemangordon | because stupidity is unfixable, si I have to do nothing about it :D | 20:22 |
| freemangordon | *so | 20:23 |
| zmatt | ah you found it | 20:23 |
| freemangordon | yeah | 20:23 |
| freemangordon | somehow I've missed that when I was looking for where size is calculated | 20:23 |
| freemangordon | now I will be able to finally implement that page aligned buffer padding algo | 20:24 |
| zmatt | freemangordon: had I sent you this link yet? https://pastebin.com/raw/pWWtEiXc it shows how the TILER addressing actually works | 20:24 |
| 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) | 20:26 |
| freemangordon | so my understanding of a 'tile' (128x128 bytes in 4bpp mode) was not matching the input data | 20:27 |
| zmatt | 128x128*4 would be 64KB | 20:28 |
| zmatt | every tile is 4KB since it's backed by a page | 20:28 |
| freemangordon | but now everything will fit tight, expect patch v3 most-probably tomorrow | 20:28 |
| freemangordon | yeah, it is 32x32 | 20:28 |
| freemangordon | typo | 20:28 |
| 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. | 20:30 |
| zmatt | np | 20:31 |
| dreamer | you have reduced zmatt to a rubber ducky | 20:33 |
| freemangordon | dreamer: come on | 20:33 |
| 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 ;) | 20:34 |
| freemangordon | :nod: | 20:34 |
| uvos | meanwhile: | 20:35 |
| uvos | http:/uvos.xyz/maserati/2021-11-18-203429_960x540_scrot.png | 20:35 |
| uvos | http:/uvos.xyz/maserati/screenshots/2021-11-18-203429_960x540_scrot.png | 20:35 |
| Wizzup | needs a second : | 20:35 |
| Wizzup | er second / | 20:36 |
| Wizzup | uvos: ah, so that's a tray icon in status? | 20:36 |
| uvos | yes a StatusNotifierItem | 20:36 |
| uvos | clicking on it causes the first xdg action | 20:36 |
| dreamer | zmatt: <3 | 20:36 |
| uvos | ususaly raises or opens the window | 20:37 |
| uvos | StatusNotifierItems can have a little overlay | 20:39 |
| uvos | thats often used to display a number over the icon | 20:39 |
| uvos | to show avialble messages | 20:40 |
| uvos | havent suportet that yet | 20:40 |
| Wizzup | :) | 20:40 |
| uvos | http:/uvos.xyz/maserati/screenshots/2021-11-18-204044_960x540_scrot.png | 20:41 |
| uvos | trojita dose this | 20:41 |
| uvos | (shown not working :P) | 20:41 |
| dsc_ | nice | 20:42 |
| freemangordon | uvos: wait, I think what you;re implementing is already there | 20:44 |
| freemangordon | unless I miss something | 20:45 |
| freemangordon | you show messages with these yellow stripes | 20:45 |
| freemangordon | and in tasknav the application shows yellow overlay on top | 20:45 |
| zmatt | dreamer: ^_^ | 20:46 |
| zmatt | anyway, time for shopping | 20:46 |
| uvos | freemangordon: this is https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/StatusNotifierItem/ | 20:46 |
| uvos | its something else entirely | 20:46 |
| uvos | the replacement for xembed icons | 20:46 |
| freemangordon | ok | 20:46 |
| freemangordon | maybe I shall get back to TILER :) | 20:46 |
| dreamer | stay in your lane fmg! | 20:50 |
| freemangordon | dreamer: since when I have lane? | 20:50 |
| dreamer | on the freewaygordon | 20:51 |
| dreamer | !badum | 20:51 |
| dreamer | *tshhh* | 20:51 |
| dreamer | ok I'll go do something else now :# | 20:51 |
| lel | IMbackK opened a pull request: https://github.com/maemo-leste/hildon-status-menu/pull/3 (Add support for StatusNotifierItems) | 20:58 |
| uvos | there | 20:58 |
| freemangordon | uvos: adding entries in status menu is not how notifications work in maemo | 21:00 |
| uvos | freemangordon: this isent about notifications | 21:00 |
| uvos | StatusNotifierItems is siltly a misnomer | 21:00 |
| uvos | this is the interface used by stuff like network manager or music players to show a tray icon | 21:00 |
| freemangordon | ah | 21:00 |
| freemangordon | oh, ok | 21:01 |
| freemangordon | yeah, makes sense | 21:01 |
| uvos | generaly its used by any gui deamon | 21:01 |
| uvos | that dosent want to keep a window open | 21:01 |
| freemangordon | ok, I see | 21:01 |
| uvos | but still wants the user to know its there | 21:01 |
| freemangordon | ok, ok :) | 21:01 |
| uvos | to bad the telegram-desktop we have in beowulf is hilariously bad wrt power consumption | 21:30 |
| uvos | it polls at 10ms | 21:30 |
| uvos | all the time | 21:30 |
| uvos | newer t-d just sits in select() | 21:30 |
| Wizzup | I'm surprised it's even in beowulf - is it even open source? | 21:31 |
| uvos | yeah its compleatly foss | 21:31 |
| uvos | longpressing a hildon_button isent a think right? | 23:24 |
| uvos | how dose modest longpress work? | 23:24 |
| uvos | *isent a thing right? | 23:24 |
| uvos | without going through the pain of implementing it yourself ofc | 23:25 |
| parazyd | uvos: Our gtk2 has long press patches IIRC | 23:46 |
| parazyd | tap_and_hold | 23:47 |
| parazyd | hildonize-gtk-widget.diff | 23:47 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!