<freemangordon>
and for sure we need libpvr_dri_support.so in binary package
<freemangordon>
links are clear
<Wizzup>
> 10:54 < freemangordon> and for sure we need libpvr_dri_support.so in binary package
<freemangordon>
yes, because pvr_dri dload()'s it
<Wizzup>
I was going to include it anyway per your instructions to include *.so*1.17*
<Wizzup>
oh right
<Wizzup>
I see now, symlink wise
<freemangordon>
mhm
<Wizzup>
shall I just do all then
<Wizzup>
I think it makes more sense than special casing
<freemangordon>
yes, better do
<Wizzup>
ok
<freemangordon>
yeah
<freemangordon>
also, make sure that every binary package you build provides sgx-ddk-um and sgx-ddk-um-1.17.4948957 (for example)
<freemangordon>
so that -dev package deps to sgx-ddk-um-1.17.4948957 and (maybe) omap-video deps to sgx-ddk-um to be satisfied nop matter the device package installed
pere has quit [Ping timeout: 256 seconds]
<Wizzup>
ok, I'll try
<Wizzup>
both src/pvr/hwdefs/ and src/pvr/include4/ - do you want them in /usr/include/sgx/ or something?
Pali has joined #maemo-leste
inky_ has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
<freemangordon>
hmm, seems 2d blit is faster
System_Error has joined #maemo-leste
<freemangordon>
Wizzup: not sure, see how is kernel tree
<freemangordon>
we better follow it
<Wizzup>
kernel tree?
<freemangordon>
TBH, this -dev package shall come from the kernel build
_inky has joined #maemo-leste
<freemangordon>
yes, headers kome from PVR kernel driver
<tmlind>
freemangordon: so do you want me to apply omap3 prm patch and your posted omapdrm and sgx patches into droid4-pending-pvr-omapdrm-v5.15?
<freemangordon>
yes
<tmlind>
ok
<freemangordon>
thanks
<freemangordon>
it seems omapdrm will need more patches, for example it refuses to export dma (not cma) allocated memory
<freemangordon>
IOW-if a buffer is not contiguous or tiled, omapdrm will not export it
<freemangordon>
I don't see the reason for that, it will be perfectly valid do construct scatterlist and provide it to the importer
<freemangordon>
if importer can handle non-contiguous memory is out of scope of omapdrm, no?
<tmlind>
yeah i guess
<tmlind>
so two sgx fixes and one omapdrm fix for now?
<freemangordon>
yeah
<freemangordon>
and I am yet to touch VRFB :D
<freemangordon>
tmlind: I think I found a way to allocate TILER buffers through GBM
<tmlind>
ok, will apply, then we can update again later based on comments etc
<tmlind>
oh cool
<freemangordon>
it will need omapdrm patch ofc
<freemangordon>
gbm has 3 flags to set a BO format:
<freemangordon>
GBM_BO_USE_LINEAR, GBM_BO_USE_RENDERING and GBM_BO_USE_SCANOUT
<freemangordon>
so, my idea is - if GBM_BO_USE_LINEAR is not provided, allocate TILER buffer
<freemangordon>
desription of this flag is : "Buffer is linear, i.e. not tiled."
<freemangordon>
so, if it is not set, allocate tiled buffer
<freemangordon>
does that make sense to you?
<freemangordon>
or on the opposite
Twig has quit [Ping timeout: 260 seconds]
<tmlind>
yeah ok, not that i know much about it at all, but sounds like at least worth trying that :)
Twig has joined #maemo-leste
<bencoh>
freemangordon: in your opnion who is supposed to set the LINEAR flag then?
Twig has quit [Ping timeout: 265 seconds]
branon has quit [Remote host closed the connection]
branon has joined #maemo-leste
<tmlind>
freemangordon: pushed out updated droid4-pending-pvr-omapdrm-v5.15 to github with stable v5.15.2 merged in
uvos has joined #maemo-leste
<uvos>
dreamer: system sounds should be slient on the silent profile
<uvos>
(and works for me)
<uvos>
also i did not change anything about this, they where always part of the profile and not related to gconf
<uvos>
if it dosent work, please changing the volume of the sounds in settings->profile->general
<uvos>
maybe your silent profile is broken some how
<uvos>
please share your profile.ini if this works but silent dose not
<uvos>
Wizzup: dont forget to binary patch the blobs for old libc
<dsc_>
uvos: Re: QML performance; you previously said something like "opengl copies the whole buffer each time" <-- is this a software/driver issue or just how QML works, thus it will never perform well on older hardware?
<uvos>
driver issue
<dsc_>
gotcha
<uvos>
but not sure if qml will ever be fast on n900
<uvos>
its pretty resource intensive either way
<uvos>
maybe try it
<bencoh>
qt4/qml on n900 (fremantle) wasn't exactly fast, but it was bearable for most apps
<uvos>
yeah but he is writing the conversations ui
<bencoh>
(except that it kept the device awake way more that it should)
<uvos>
this will probubly allways be in ram
<uvos>
so not sure if its a good idea
<uvos>
needs profileing first
pere has joined #maemo-leste
<bencoh>
in that case, I'd rather not use qml, yeah
<dsc_>
QtWidgets would be most performant but am time limited atm
<bencoh>
(unless for stuff limited to UI only)
<uvos>
rather than dissmissing it out of hand i think checking it out make sense
<uvos>
performance wise
<uvos>
qt5 should be a bit better than 4
<uvos>
if the qt company is to be belived
<uvos>
perf wise
<dsc_>
yeah some QML performance changes between the minor versions too
<dsc_>
we're on 5.11
<dsc_>
thats somewhat recent
<dsc_>
anyway, for now this is just a MVP
<bencoh>
well, if they fixed the idling (or lack of) issues, then it might be worth a try yeah
<bencoh>
(and/or if it doesn't impact our usecase)
<uvos>
yeah def check for if it idles well
<uvos>
if not thats k.o.
<dsc_>
ill keep business logic on the C++ side so switching out the renderer is not a huge undertaking :P
<bencoh>
:)
<bencoh>
if you really follow MVP I guess one could always replace the QML parts with 'native' qt bit by bit once it works anyway, assuming we feel the need to
<dsc_>
MVC you mean? Yeah something like that. Not going to claim I am an expert in C++/Qt, more of an UI person, but yeah switching to QtWidgets wont be as painful
<dsc_>
ive been on projects where most business logic is in QML
<dsc_>
so you can never drop it for something else unless you rewrite everything
<bencoh>
yeah I've seen such apps
elastic_dog has quit [Quit: elastic_dog]
elastic_dog has joined #maemo-leste
<dreamer>
uvos: hmm. I'll have to try that indeed
<dreamer>
uvos: made a new profile with all sounds turned off -> still hear the woosh
<dreamer>
no wait, it keeps switching back to General
<dreamer>
yeah ok, if I turn everything off in General profile it's silent
<dreamer>
the problem is that it doesn't save the profile change. it just resets back to General
<uvos>
how are you changing profiles?
<dreamer>
`Settings > Profiles`
<dreamer>
select one. done?
<uvos>
dreamer: that dosent change prfiles
<uvos>
your just selecting one to edit
<dreamer>
then how?
<uvos>
click the battery item
<uvos>
*icon
<uvos>
in the status bar
<uvos>
and change it in hildon-status-menu
<dreamer>
oh derp
<uvos>
or open the power menu
<dreamer>
I haven't been on maemo for too long -_-
<uvos>
and click silent there
<uvos>
profilesx is a bit wierd yeha
<uvos>
but thats works as intended
<dreamer>
yeah, sorry
<dreamer>
what is "power menu"?
<dreamer>
bbl, food
<uvos>
the one where you switch off the deive
<uvos>
*device
<uvos>
also has a "silent" that changes the profile
<dreamer>
ah yes
<dreamer>
ok, check. gotta re-learn old habbits (or rather: I set my maemo profile once ~decade ago and never changed it. I hate all forms of notification sounds and vibrations)
<sicelo>
or you can do it via dbus if you don't mind the long string (setting silent ... unless things work differently now)
LjL has quit [Quit: Scappò via con la paura di arrugginire. Il giornale di ieri lo dà morto arrugginito. I becchini ne raccolgono spesso fra la gente che si lascia piovere addosso.]
n900 has joined #maemo-leste
elastic_dog has quit [Ping timeout: 264 seconds]
inky_ has joined #maemo-leste
pere has quit [Ping timeout: 245 seconds]
<sicelo>
freemangordon: there's a Lucas Fryzek in the openpvrsgx ml. i wonder if he also would have some insight for anything you still need :-)
elastic_dog has joined #maemo-leste
<Wizzup>
uvos: freemangordon says we do not need bin patching with mesa
<uvos>
parazyd: Wizzup: in what pacakge are the maemo icons?
<uvos>
im particularly looking for the sms/phone icon
<Wizzup>
themes?
<uvos>
to use with sphone outside of maemo
<uvos>
oh ok
<Wizzup>
try dpkg -S filepath
<uvos>
i dont know the filepath either :P
<uvos>
Wizzup: are you sure i had to patch some for use with chromeos mesa
<Wizzup>
he told me irl just now
<uvos>
ok
<Wizzup>
we'll see I guess
<uvos>
wierd
<uvos>
https://github.com/IMbackK/pvr-omap4 these are the exact blobs i use, you can diff arm-linux-gnueabihf-untainted and arm-linux-gnueabihf to see what i had to patch
<uvos>
there are deff. some glibc symbol version tags in there that are newer than ours
<uvos>
so no idea how that should work
<Wizzup>
do you use the zeus ranch?
<Wizzup>
branch*
<uvos>
its ti-img-sgx/zeus/1.17.494857 @ 551665bf9c321bc3e7721416e6ebbc9f65c18155
<uvos>
*ti-img-sgx/zeus/1.17.4948957
<uvos>
actually those 2 branches share a head
<Wizzup>
we use a different one I think
<Wizzup>
fmg does at least
<uvos>
ok
<uvos>
that explains it
<Wizzup>
fmg told me to use 1.17.4948957-next
<uvos>
that dident exist last time i fetched
<uvos>
looks like
<uvos>
we asked someone to rebuild agains older glibc some time ago
<uvos>
maybe they finaly did :P
<Wizzup>
hehe
<freemangordon>
no, they didn;t
elastic_dog has quit [Ping timeout: 264 seconds]
<freemangordon>
it is just that blobs that depend on newer glibc are replaced by the ones we have in MESA