scientes has quit [Ping timeout: 256 seconds]
genii has quit [Remote host closed the connection]
scientes has joined #linux-exynos
scientes has quit [Changing host]
scientes has joined #linux-exynos
mszyprow has joined #linux-exynos
Vasco is now known as Vasco_O
Vasco_O is now known as Vasco
Vasco has quit [Remote host closed the connection]
nighty- has quit [Quit: Disappears in a puff of smoke]
nighty- has joined #linux-exynos
Vasco has joined #linux-exynos
aalm has quit [Ping timeout: 264 seconds]
<memeka> mszyprow: ping
<mszyprow> memeka: pong
<memeka> if i am not mistaken
<memeka> MFC outputs with some padding 1088×1920
<memeka> instead of 1080p
<memeka> might that be the reason?!
<memeka> cause i am sending 1920x1088 ?
<mszyprow> memeka: nope, the page fault issue is on the displayed rgb buffer
<mszyprow> and the device which triggers it is mixer
<mszyprow> 1920x1088 buffers goes to gsc not the mixer
<mszyprow> -goes +go
<memeka> and gsc will output it back
<memeka> and i send it to drm
<mszyprow> yes, but that will be different buffer
<memeka> sure, but the buffer is still 1088
<memeka> and drm can handle 1080
<memeka> e.g. if you play 720p video, it won't show
<memeka> cause buffer is wrong value, and drm does no scaling
<mszyprow> from the log I see that the buffer is 1920x1080 rbg 32bit
<memeka> (so i need to make gsc to scaling too)
<memeka> but i think i remember the gsc log as having 1088
<memeka> let me check
<memeka> it might not be a bug after all :(
<mszyprow> drm imports buffer as 1920x1080x32bit rgb
<mszyprow> hmmm, now I got kernel panic due to oom killer having to process to kill
<mszyprow> it looks that something is leaking memory...
<memeka> mszyprow: yeah GSC converts it to 1080
<memeka> [ 71.981785] video21: VIDIOC_G_FMT: type=vid-out-mplane, width=1920, height=1088, format=NM21
<mszyprow> -converts +crops ;)
<memeka> [ 71.982328] video21: VIDIOC_G_FMT: type=vid-cap-mplane, width=1920, height=1080, format=BGR4
<memeka> yes, crops :)
<memeka> i need to make it scale too :)
<memeka> leaking memory in kernel or userspace?
<memeka> e.g. i might not be releasing buffers correctly when closing mfc/gsc
<memeka> in that version of the code :
<mszyprow> in kernel
genii has joined #linux-exynos
<memeka> actually i think the code used back then
<memeka> didn't release gsc v4l2 buffers at all
<mszyprow> userspace can do anything stupid, but in any case, kernel after finishing the process should release all the allocated resources
<memeka> debugging a kernel other than putting some printk's is something i did not do :(
<memeka> mszyprow: have you noticed the overlay image ... trembles ?
<memeka> not sure it's related or not
<mszyprow> might be related to devfreq activity
<mszyprow> I didn't notice it
<mszyprow> but frankly I didn't look much at the movie/osd
<memeka> whatever is rendered on primary plane
<memeka> si solid
<memeka> whatever is rendered on overlay plane (GRAPH1)
<memeka> ... trembles ... like the lights with unstable power source :)
<memeka> you can change a bit the source to mpv
<memeka> then run ../waf build to compile again
<memeka> and now the video will tremble
<memeka> when it's shown on overlay plane
<memeka> anw, not that important :)
<memeka> unless it's related :P
<memeka> but probably not
<mszyprow> it might be also related to the priority of memory access on axi bus
afaerber has quit [Ping timeout: 240 seconds]
<memeka> mszyprow: it's weird, why would it not crash if h is 2 pixels short?
<mszyprow> memeka: 2 lines
<memeka> sorry yes
<memeka> 2xwidth :)
<memeka> buffer sizes?
<memeka> does DRM not have enough allocated, or is the buffer i'm sending too big?
<mszyprow> memeka: I have no idea yet, but the page fault is because mixer tries to access beyond the end of the provided buffer
<mszyprow> DRM calculates everything properly
<mszyprow> I got some logs, where mixer displays the provided buffers for more than one vblank period and then crashes by accessing a byte after the end of the provided buffer
<mszyprow> I really have no idea why and more important under which conditions this issue happens
<mszyprow> I initially thought that this is related to freeing the buffer immediately after displaying it, but the page fault is always because of the access to a byte after the provided buffer
<memeka> mszyprow: can it be a GScaler bug?
<mszyprow> nope
<mszyprow> it is related only to mixer
<memeka> Gscaler sets wrong bytesperline
<mszyprow> this is ignored by drm
<memeka> maybe it's computing the buffer length wrongly?
<mszyprow> at least in debugs everything looks correct...
<memeka> actually if the data itself from gsc would be wrong, image would have some artifact
<memeka> and it doesn't
<memeka> mszyprow: what happens if i allocate a larger buffer?
<mszyprow> memeka: it might also work
<mszyprow> memeka: but make sure that the larger size is also used in drm prime
<mszyprow> you might try to set gsc destination to 1920x1088 rgb32 and adjust crop/selection
<memeka> drmprime i see ends offset and pitch
<mszyprow> I didn't have time to play with userspace
afaerber has joined #linux-exynos
wwilly has joined #linux-exynos
mszyprow has quit [Ping timeout: 244 seconds]
afaerber has quit [Quit: Leaving]
afaerber has joined #linux-exynos
aalm has joined #linux-exynos
wwilly_ has joined #linux-exynos
wwilly has quit [Ping timeout: 264 seconds]