<freemangordon>
mighty17[m]: I investigated a bit about GL_IMG_read_format/GL_EXT_read_format_bgra and came to the conclusion that it will be incorrect if driver reports GL_EXT_read_format_bgra if it only supports GL_IMG_read_format. The reason is that if GL_EXT_read_format_bgra is supported, one can pass UNSIGNED_SHORT_1_5_5_5_REV_EXT to glReadPixels, but this is unsupported by GL_IMG_read_format.
<freemangordon>
so, it is the application that shall be fixed to support GL_IMG_read_format
<freemangordon>
assuming it does not require UNSIGNED_SHORT_1_5_5_5_REV_EXT
<freemangordon>
Wizzup: do we have an issue about ofono problems on d4?
<mighty17[m]>
ohk thats interesting, i did assume they were interchangable, but `UNSIGNED_SHORT_1_5_5_5_REV_EXT` does make sense
<mighty17[m]>
in this case, if something calls for `GL_EXT_read_format_bgra` we'd check if it wants `UNSIGNED_SHORT_1_5_5_5_REV_EXT`, if not we can pass it on to `GL_IMG_read_format`
<mighty17[m]>
this can be done in mesa, but does feel a bit hacky?
<mighty17[m]>
basically `GL_IMG_read_format` would be a subset of `GL_EXT_read_format_bgra` right?
Twig has quit [Ping timeout: 256 seconds]
<mighty17[m]>
freemangordon do you know why the shader crashes here, i've not been able to successfully replicate it multiple times tho https://paste.debian.net/1251407/
<uvos__>
but its not compleat (there are way more issues)
<Wizzup>
freemangordon: yes, like uvos__ linked, I think many of the issues are the same, what we maybe need a good way to compare kernel serial interaction with what ofono actually sees
<Wizzup>
I think we can make the kernel modules fully verbose
<Wizzup>
n_gsm.debug as 0xff iirc
<uvos__>
also maybe diff bionic and d4 behavior more
<uvos__>
as bionic works better
<uvos__>
wich btw
<uvos__>
bionics modem fw was not updated as often
<uvos__>
maybe some older d4 firmware works better
<uvos__>
so far motorla never prevented installing old images on d4
<uvos__>
so you can likely just flash one
<Wizzup>
let's hope it's not a firmare issue
<uvos__>
well it works in android so it cant be an insrumoutable firmware isssue
<uvos__>
still some older version might work better
<Wizzup>
what makes you conclude that? (older versions work better)
<uvos__>
thay are closer to bionic
<uvos__>
(bionics wasent updated as often)
<uvos__>
(version wise)
<Wizzup>
aha
crab has quit [Quit: WeeChat 3.6]
crab has joined #maemo-leste
<freemangordon>
mighty17[m]: yes (subset)
<freemangordon>
no idea about the shader
<freemangordon>
uvos__: thanks
n900 has joined #maemo-leste
<freemangordon>
uvos__: in the meanwhile I fixed h-d portrait tasknav bug
<freemangordon>
please test notify fixes when you have chance
<mighty17[m]>
freemangordon: so i'd think its better to have a hack in mesa rather than patching each application that calls for it? for example for now wlroots seems to need it, so i'd need to patch wlroots everytime thye do some major changes, rather than that why not mesa?
<freemangordon>
what you are going to do if application requires UNSIGNED_SHORT_1_5_5_5_REV_EXT?
<uvos__>
crash, mesa allready has sutch flags that alow you to make it lie about capabilities
<uvos__>
like the ogl version override
<uvos__>
he could just add one
<mighty17[m]>
<freemangordon> "what you are going to do if..." <- That point we say we don't support it :P
<mighty17[m]>
Or just crash :P, but there's no way to know whether an application requires it or not right?
<freemangordon>
mighty17[m]: as uvos__ said, use MESA_EXTENSION_OVERRIDE onstead of hacking mesa
<freemangordon>
*instead
<mighty17[m]>
For that we'll still need to add GL_IMG_* to mesa tho
<uvos__>
sure and thats fine
<uvos__>
you can half implement it
<uvos__>
and then hide it behind an extension overide
<uvos__>
thats how ogl >3 works on r600 < 5050
<freemangordon>
mighty17[m]: sorry, WTYM?
<freemangordon>
why add GL_IMG_* to mesa? it is already there
<uvos>
hmm i still cant get it to display the image
<freemangordon>
yep, notify-send "test" "<img src=\"/home/user/2022-07-27-162354_960x540_scrot.png\" alt=\"screenshot\"/>" works as well
<uvos>
it displays the text
<freemangordon>
sure, this is not supported :)
<uvos>
ah
<uvos>
ok
<freemangordon>
bbl
Livio has joined #maemo-leste
Livio has joined #maemo-leste
<freemangordon>
uvos: so, are there any other non-compliances in notify server?
<uvos>
freemangordon: i dont think so, gues supporting urgency levels and the behavior around critical is not implemented.
<uvos>
besides that there are of course several wildly used optional features missing
<uvos>
(actions being the most widely used)
<freemangordon>
that's true, we lack support for some features
<freemangordon>
but lets what we have to be compliant, at least
<freemangordon>
so, I am going to merge and release
<uvos>
i think except the bhavior around ciricital its compliant
<freemangordon>
ok
<uvos>
im also not sure org.freedesktop.Notifications.GetCapabilities is correct
<freemangordon>
why so?
<uvos>
we support icon-static and persistence no?
<uvos>
it returns just 'body', 'body-markup', 'icon-static'
<uvos>
nvm icon-static i missed it
<freemangordon>
we dont; support persistence
<uvos>
"The server supports persistence of notifications. Notifications will be retained until they are acknowledged or removed by the user or recalled by the sender. The presence of this capability allows clients to depend on the server to ensure a notification is seen and eliminate the need for the client to display a reminding function (such as a status icon) of its own. "
<uvos>
that seams how it behaves
<freemangordon>
no
<uvos>
not sure what it means
<uvos>
if not
<freemangordon>
you explained it yesterday
<freemangordon>
other servers retain a queue
<uvos>
i dont think thats nesscary
<uvos>
reading that
<uvos>
keeping the "window" in tasknav is sufficant no?
<uvos>
per spec
<freemangordon>
it is not kept forever
<uvos>
ah really?
<uvos>
how long is it kept?
<freemangordon>
yes, unless you specify a timeout of zero
<freemangordon>
for 'timeout' period
<uvos>
right ok, but then just overrding timeout to 0 if persistance is set
<uvos>
in the code seams like a easy peasy way to support this feature
<uvos>
but ok
<freemangordon>
yes, it is, but thats a hack
<uvos>
anyhow ok
<freemangordon>
as IIUC this is not what specs require
<freemangordon>
we shall support "transient" hint as well
<uvos>
i dont think spec imples a que
<freemangordon>
if we say we support persistence
<uvos>
even thoug i think it suggests one to exist
<uvos>
*though
<freemangordon>
but this is >= 1.2
<freemangordon>
the version that is
<uvos>
yeah
<uvos>
supporting sound would be really usefull btw
<uvos>
(just an asside)
<uvos>
rn the app has to play a sound itself which is not as nice
<uvos>
but yeah you can push it
mardy has quit [Quit: WeeChat 2.8]
Livio has quit [Quit: Lost terminal]
uvos has quit [Ping timeout: 252 seconds]
<norayr>
this battery stuff should be documented.
<norayr>
i don't understand it well, otherwise would try to add info from recent chats to the wiki.