belcher has quit [Ping timeout: 265 seconds]
belcher has joined #maemo-leste
lightbringer has quit [Ping timeout: 246 seconds]
lightbringer has joined #maemo-leste
lightbringer has joined #maemo-leste
lightbringer has quit [Changing host]
lightbringer has quit [Ping timeout: 264 seconds]
lightbringer has joined #maemo-leste
lightbringer has quit [Changing host]
lightbringer has joined #maemo-leste
zhxt has joined #maemo-leste
joerg has quit [Ping timeout: 265 seconds]
joerg has joined #maemo-leste
joerg has quit [Read error: Connection reset by peer]
zhxt has quit [Ping timeout: 252 seconds]
doc has quit [Quit: Things to do]
joerg has joined #maemo-leste
doc has joined #maemo-leste
pere has quit [Read error: Connection reset by peer]
pere has joined #maemo-leste
BenLand100 has quit [Quit: s/BenLand100//]
BenLand100 has joined #maemo-leste
BenLand100 has quit [Changing host]
BenLand100 has joined #maemo-leste
BenLand100 has quit [Quit: s/BenLand100//]
<Wizzup> freemangordon: nice, opening pdf from email just worked
BenLand100 has joined #maemo-leste
BenLand100 has joined #maemo-leste
BenLand100 has quit [Changing host]
<freemangordon> not on my freshly upgraded d4
<Wizzup> weird
<freemangordon> yeah, but I am not going to dig into that
<freemangordon> my concern is modesetting/glamor
<freemangordon> I think those are FUBAR
<freemangordon> the point is: it seems that PRESENT implementation in modesetting is more or less broken
<freemangordon> maybe I shall pull latest master and see it is is better
<freemangordon> what I see on n900 - for some reason 'older' frames are drawn 'after' newer
<freemangordon> TFP is broken as well
<freemangordon> CMA area is 16 MB - how much more is needed for MS/GLAMOR to work?
<freemangordon> hmm, I have to try some video playback
<freemangordon> but given that performance is 3/4th of that without xorg, I doubt it will look nice
<freemangordon> Wizzup: I built mesa with dri3 enabled, does it make sense to build it with dri2?
<freemangordon> ah, where is uvos, he knows a bit about hat
<freemangordon> *that
<freemangordon> tmlind: does glmark-es2-drm works for you on d4?
<Wizzup> freemangordon: which xorg is this?
<Wizzup> it is possible some of the modeset problems are kms problems
<freemangordon> lemme check
<Wizzup> esp. the frame stuff/trails you mention
<freemangordon> 5e3900904ddc27f3d5580ce3a07929469d82fb5e
<Wizzup> I do not know regarding dri2, probably not
<Wizzup> I would really suggest separating glamor and ms if we can in our evaluation
BenLand100 has quit [Quit: s/BenLand100//]
<Wizzup> modesetting I think we really want to use for the mode setting part
<Wizzup> there is no reason not to
<Wizzup> glamor if potentially a different story
<Wizzup> is*
<Wizzup> freemangordon: cannot check the commit hash atm but iirc tmlind had some fixes for xorg modeset and rotation
<Wizzup> if that is what you mean with present
<freemangordon> hmm, upstream has lots of fixes for glamor/ms
<Wizzup> I use modesetting on my laptop and it does not seem broken
<freemangordon> worths rtying latest master
BenLand100 has joined #maemo-leste
<Wizzup> right
BenLand100 has quit [Changing host]
BenLand100 has joined #maemo-leste
<Wizzup> we also patch our xorg but only with my patch iirc
<Wizzup> (xrexcorcd related)
<freemangordon> since that there is a pile of commits
<freemangordon> so I am going to try latest master
<Wizzup> ok
<freemangordon> hmm, ABI_INPUT has changed, lets hope there will be no issue with that
<freemangordon> ABI_XINPUT_VERSION that is
<freemangordon> only minor is changed though
BenLand100 has quit [Quit: s/BenLand100//]
xmn has quit [Quit: ZZZzzz…]
<Wizzup> I think the xorg server builds some drivers as well no
<Wizzup> so you should just get them
<freemangordon> those are in separate repos
<Wizzup> ok
<freemangordon> but, for video, it is no issue as we use only modesetting
<freemangordon> and input ABI major is still 24, lets see
<freemangordon> Requested 'fixesproto >= 6.0' but version of FixesProto is 5.0
<freemangordon> No package 'libxcvt' found
<freemangordon> Requested 'inputproto >= 2.3.99.1' but version of InputProto is 2.3.2
<freemangordon> :(
BenLand100 has joined #maemo-leste
BenLand100 has quit [Changing host]
BenLand100 has joined #maemo-leste
belcher has quit [Ping timeout: 245 seconds]
<Wizzup> so this is a buster/beowulf+1 thing?
<freemangordon> mhm
<Wizzup> it could also be that master is prepped for some rc
<freemangordon> just installed one package from buster, with no issue
<freemangordon> lets see
<freemangordon> yeah, but we don;t need it with chromeos mesa
<freemangordon> we need x11proto-dev_2021.5-1_all.deb
belcher has joined #maemo-leste
pere has quit [Ping timeout: 264 seconds]
<freemangordon> tmlind: yeah, glmark doesn't work on droid4-pending-pvr-omapdrm-v5.15
<freemangordon> maybe the same "Fix page fault handling..." patch
<freemangordon> ok, upstream xorg is being build, fingers crossed
belcher has quit [Ping timeout: 252 seconds]
<Wizzup> :)
pere has joined #maemo-leste
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 252 seconds]
<freemangordon> glmark2 Score: 21
<freemangordon> trying to start hildon-desktop, xorg segfault
<freemangordon> Thread 1 "Xorg" received signal SIGSEGV, Segmentation fault.
<freemangordon> 0xb55eb612 in ?? () from /root/mesa/sgx/libGLESv2_PVR_MESA.so
<Wizzup> debug symbols?
<freemangordon> no
<freemangordon> this is ion the blob
<freemangordon> *in the
<freemangordon> I am trying some other thing ATM
<freemangordon> yes, with this h-d starts
<freemangordon> not that it works
<freemangordon> but at least good thing is that I can rmmod/modprobe on hang
<freemangordon> ok, TFP seems to work, somehow :)
<freemangordon> seems we need GL_OES_texture_border_clamp or replacement
<freemangordon> otherwise all repaints are fullscreen
<Wizzup> cool @ tfp
* Wizzup is excited
<freemangordon> but, I don;t know how to implement GL_OES_texture_border_clamp replacement
<freemangordon> without that this is useless
<Wizzup> wonder if newer x will work with lima better
<Wizzup> right
inky has quit [Read error: Connection reset by peer]
<freemangordon> trying to play video:
<freemangordon> ERROR: 0:1: Syntax error, GLSL Version 120 not supported
<freemangordon> I think this is a dead-end
<bencoh> oh
<bencoh> what are you playing that video with?
<freemangordon> gst-launch
<bencoh> hmm
<bencoh> is glsl mandatory? that's odd
<bencoh> I bet it's for yuv/rgb conversion
<freemangordon> this is error from Xorg
<freemangordon> modesetting/glamor
<bencoh> ah
<freemangordon> yeah, I would guess the same (yuv/rgb)
<freemangordon> I can try to force gst to do it in SW, but what is th epoint
<bencoh> I'd rather try disabling it in glamor, but yeah
<bencoh> or backport shader to older glsl
<freemangordon> and where it should be done?
<freemangordon> yeah, porting is ok
<bencoh> I mean, glsl shaders have been working for ... years, I doubt they just recently added something that enables yuv/rgb :)
<freemangordon> but doesn;t really make sense, given that PRV2d supports tens of types of surfaces in HW
<bencoh> what do you mean by that?
<freemangordon> it is just that SGX 3D driver functionality is limited to ES2
<freemangordon> I mean that we can try to not use glamor for EXA
<bencoh> yeah
<bencoh> ah, I see
<freemangordon> too many pieces are missing IIUC
<mighty17[m]> <freemangordon> "but, I don;t know how to..." <- Is the bgra extension working?
<freemangordon> yes
<freemangordon> mighty17[m]: sec, I'll pastebin the patch
<freemangordon> mighty17[m]: https://pastebin.com/XiYgriJ1
<mighty17[m]> freemangordon you're a savior
<bencoh> I wonder if this got dropped at some point
<freemangordon> mighty17[m]: this alone is not enough
<freemangordon> at least for modesetting/glamor
<mighty17[m]> Can we try to patch gles instead of glamor?
<freemangordon> you need https://pastebin.com/ciGS2zJt too
<freemangordon> mighty17[m]: patch what exactly?
<freemangordon> uplift SGX driver to ES3.0?
<mighty17[m]> freemangordon: Heh that's impossible
<freemangordon> mhm
<mighty17[m]> freemangordon: Like wrapper around libegl or smth
<mighty17[m]> Else we'll have to patch all apps for support for the missing gles extensions
<freemangordon> bencoh: the point is that SGX driver seems to perform very well for 3D stuff, but glamor is FUBAR on gles2
<bencoh> freemangordon: oh, I see
inky has joined #maemo-leste
<bencoh> well then there is really no point in keeping it
<freemangordon> so, we can use modesetting without glamor but instead RE pvr_drv from old IMG DDKs
<freemangordon> but, I want to hear from uvos on that, I am not really experienced in that shit
<bencoh> wait, you really want to re the pvr driver?
<freemangordon> it is ~50k and I have a version with debug symbols
<freemangordon> a week or so
<bencoh> oh
<bencoh> well
<Wizzup> this also doens't seem too bad: $ wc -l ./src/sgx_exa.c
<Wizzup> 1176 ./src/sgx_exa.c
<freemangordon> what is this?
<Wizzup> xf86-video-pvrsgx driver
<Wizzup> based on fbdeb, but I assume that exa plugin arch didn't change much
<Wizzup> fbdev*
<freemangordon> does it call into libpvr2d?
<Wizzup> maybe it contains the pvr2d stuff, I can't really tell without looking at the .so
<freemangordon> I think it does
<freemangordon> yes, it does
<freemangordon> it includes pvr2d.h
<freemangordon> which I guess comes from SDK/DDK
<freemangordon> actually, if we build that, it should work against the new sdk
<freemangordon> did we try it?
pere has quit [Ping timeout: 264 seconds]
<freemangordon> anyway, going to a walk, ttyl
<mighty17[m]> I'll try to add bgra patch to wayland (wlroots) ig, is that even possible
<Wizzup> freemangordon: we do not want to and cannot use most of xf86-video-pvrsgx
<Wizzup> but the exa part we can use in modesetting
<Wizzup> freemangordon: yeah pvrsgx_drv_la_LDFLAGS = -module -avoid-version -lm -lpvr2d
<Wizzup> freemangordon: most of the stuff in there I don't think we want/need, a lot of it is related to old omapfb and the really weird api with overlays
<bencoh> unused symbols can't hurt though
<Wizzup> the code is a mess
<Wizzup> we're trying to move away so we don't have to touch it again
<bencoh> ah
<Wizzup> I don't think there's much of value there
<Wizzup> apart from the exa over pvr2d stuff
<Wizzup> freemangordon: does 3d work if you disable glamor, or does it require glamor to be loaded for dri3
<freemangordon> I think glamor is required because of dri3
<freemangordon> going to try without glamor
<freemangordon> hmm, it works with out glamor
<bencoh> neat
<freemangordon> but, veeeery slow
<freemangordon> GL_RENDERER: llvmpipe (LLVM 7.0.1, 128 bits)
<freemangordon> :)
<bencoh> huhu
<freemangordon> yes, because of dri3
<freemangordon> but, I think I can compile mese for dri2
<freemangordon> *mesa
inky has quit [Ping timeout: 252 seconds]
<freemangordon> Wizzup: yes, we don't want xf86-video-pvrsgx, that's why I want to RE pvr_drv
<freemangordon> xf86-video-pvrsgx doesn't use 2D engine, iiuc
<freemangordon> this fbdev stuff we will want someday, because of XV stuff
<freemangordon> ofc it will need to be ported to drm
xmn has joined #maemo-leste
Pali has joined #maemo-leste
inky has joined #maemo-leste
doc has quit [Remote host closed the connection]
<Wizzup> freemangordon: what 2d engine is that
l_bratch has quit [Quit: Leaving]
<freemangordon> the one on SGX
<freemangordon> "Advanced and standard 2D operations (that is, vector graphics, BLTs (fixed blitters), ROPs (raster operating processors operations))"
<freemangordon> Wizzup: at least blit is in HW, IIUC
<freemangordon> Wizzup: look at pvr2d.h for type of ROPs it can do
inky has quit [Remote host closed the connection]
<Wizzup> ok, so this is part of the gpu then
<freemangordon> yeah
<freemangordon> and this is the public SDK
<freemangordon> it seems it can do more then that, at least by the looks of pvr_drv
inky has joined #maemo-leste
<Wizzup> ok
<freemangordon> maybe it can do vektor stuff in HW
<freemangordon> *vactor
<freemangordon> aaah
<freemangordon> vector :)
doc has joined #maemo-leste
<Wizzup> I need to go for some time of the eve, but will hopefully finish the droid3 kexecboot tomorrow
pere has joined #maemo-leste
l_bratch has joined #maemo-leste
l_bratch has quit [Quit: Leaving]
belcher has joined #maemo-leste
l_bratch has joined #maemo-leste
LjL has quit [Read error: Connection reset by peer]
LjL has joined #maemo-leste
uvos has joined #maemo-leste
<uvos> hi
<uvos> i am back around
<freemangordon> hi
<uvos> whats the state on pvr-xorg
<freemangordon> bad
<uvos> also any suggestions on what to do about the n900 wrt wayland
<freemangordon> basically nothing works ok
<freemangordon> what do you mean?
<uvos> dose someone have the patched blobs for me to use with a leste image?
<freemangordon> sure
<uvos> or shal i work to get wlan working on debian 11
<freemangordon> I will provide blobs, including mesa
<freemangordon> chromeos mesa that is
<uvos> ok
<freemangordon> BTW, I had x11 working with that
<freemangordon> but we hit various bug in modesetting/glamor
<uvos> yeah i saw that
<freemangordon> *bugs
<freemangordon> ok
<uvos> cool :)
<uvos> so the x11 emulation path in mesa works on pvr
<freemangordon> yeah
<freemangordon> so, now the plan is - I am REing pvr_drv, in hope we will have working EXA
<freemangordon> and then, somehow will implement PRESENT in it
<uvos> ok, taking the exa code from the old fbdev video-pvr driver is not an option?
<uvos> not for present ofc
<freemangordon> Wizzup: doesn;t like it
<freemangordon> me neuther, it doesnt really do any 2d accel
<freemangordon> IIUC
<uvos> Wizzup: can you comment on that?
<uvos> ok
<freemangordon> well, ofc I am not sure there will be any use of pvr_frv
<freemangordon> *pvd_drv
<freemangordon> what the?!?
<freemangordon> PVR_DRV
<freemangordon> but at least we will have a better understanding on what is under the hood
<uvos> ok
<uvos> Wizzup: with kexecboot on d3
<uvos> if bspw is just 2 mb on d3 i dont think its viable to use for kexecboot
<uvos> just put it on cdrom
<uvos> android dosent need that
<uvos> cdrom is pretty big
<uvos> 212mb on xt894
<uvos> hmm
<uvos> having touble compileing a hildon application
<uvos> hildon-gtk.h includes maemo-gtk-compat.h
<uvos> maemo-gtk-compat.h dosent appear to exist on my system
<uvos> at least acording to find
<uvos> oh i need to define MAEMO_GTK
<uvos> can we drop this
<uvos> since maemo-gtk-compat.h appears gohne
<freemangordon> [ 41324.198] (II) pvr: Driver for PowerVR chipsets: PowerVR SGX
<freemangordon> [ 41324.308] (EE) ERROR: Couldn't get PVR Services status
<uvos> freemangordon: context?
<freemangordon> REed driver
<freemangordon> most of it is still stubs though
<uvos> neat
Pali has quit [Ping timeout: 264 seconds]
akossh has joined #maemo-leste
<Wizzup> freemangordon: uvos: hi, I don't think I said I don't like the exa code for xf86-video-pvrsgx, but the fbdev code I don't like
<Wizzup> I cannot comment on whether it actually uses the 2d unit/api/whatever, that requires some more examination at leats from me
<Wizzup> uvos: I was able to load kexecboot in there I think
<Wizzup> it seems to fit at least
<uvos> well even if it dosent use it execpt to blit
<uvos> its still usefullt
<Wizzup> yeah
<uvos> (as we would start with pvr2d just doing blits too)
<Wizzup> uvos: re: d3, I think I am almost there, the only thing that is missing is mmcblk1 not showing up
<uvos> Wizzup: fastboot dosent check sizes if you flash:raw
<Wizzup> uvos: ls -ls seems to indicate it matches
<Wizzup> afaik
<uvos> Wizzup: omap4 has 3 mmc controllers iirc
<uvos> Wizzup: might be on a different one than on d4/bionic
avoidr has quit [Ping timeout: 245 seconds]
avoidr has joined #maemo-leste
<uvos> Wizzup: btw im massively refacotring sphone rn
<uvos> Wizzup: to make it modular
<uvos> dont work on it untill that drops
<Wizzup> uvos: no because it works on 5.11
<Wizzup> it shows up as mmcblk2
<uvos> oh ok
<Wizzup> so I could build 5.11 statically instead, I suppose
<Wizzup> just for the proof of concept
<Wizzup> but there are some traces in 5.14.9, so maybe that is the problem
<uvos> i would kinda prefer a lts kernel for the bootloader
<uvos> so 5.10
<uvos> but yeah fixing 5.14+ is good in any case
<uvos> dose mmc work on d4 on 5.14? i dont think i have checked recently
<uvos> i wouldent notice
<Wizzup> not sure, haven't checked either
<uvos> sec ill boot the sway d4
<Wizzup> right, and I mean internal mmc, but you got that
<uvos> works fine on d4
<uvos> its mmcblk1
<uvos> (5.15-rc2)
<uvos> maybe is broken in 5.14 only
<uvos> had a 5.14 kernel on it too
<uvos> works just the same
<uvos> its d3 specific
<uvos> or there is patch about this that i pulled in via tmlids -pending
<uvos> into my tree
<uvos> tmlind: ^^^
<uvos> Wizzup: your d3 kernel is vanilla mainline right?
<Wizzup> yes
<Wizzup> just the tar from kernel.org
joerg has quit [Read error: Connection reset by peer]
joerg has joined #maemo-leste
uvos has quit [Ping timeout: 252 seconds]
akossh has quit [Quit: Leaving.]