Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #etnaviv
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #etnaviv
lynxeye has quit [Quit: lynxeye]
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #etnaviv
chewitt has quit [*.net *.split]
Chewi has quit [*.net *.split]
Chewi has joined #etnaviv
chewitt has joined #etnaviv
berton has quit [Ping timeout: 248 seconds]
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #etnaviv
adjtm_ has joined #etnaviv
adjtm has quit [Ping timeout: 240 seconds]
cengiz_io has joined #etnaviv
<cengiz_io>
hello there. I'm having an issue with gradient rendering on my imx6 solo. can you share some common things to check to discover if it's really an etnaviv issue or a TFT misconfiguration issue?
<cengiz_io>
for example, kmscube application draws a cube with white/off color lines just on certain color values and whenever the sample cube rotates, those "wrong colored" lines rotate as well
<cengiz_io>
I know I didn't share enough info but don't want to spam this channel until I get some diagnostics first
<cphealy>
If you have concerns that it may be a TFT mis-configuration issue, I would suggest putting a gradient on the screen without using the 3D GPU.
<cphealy>
In the past, I put a pattern generator in barebox (bootloader) which would allow putting up various test patterns including gradients for this very purpose.
<marex>
cengiz_io: try running your application with LIBGL_ALWAYS_SOFTWARE=1 env var set, then it uses software rendering instead of GPU
<cphealy>
The same could be done with a test app in Linux on framebuffer.
<marex>
that way you can rule out the GPU
<cphealy>
What marex is suggesting is also a good way of ruling out the GPU.
<marex>
I dont see why you would need to exchange bootloader to test framebuffer, that makes no sense
<cengiz_io>
btw I'm using kms drm so with my default kernel, fb0 is non existent. at least to me.
<marex>
you can enable fbdev emulation in kernel config
<cphealy>
I'm not suggesting exchanging bootloaders. I'm only pointing out a method used in the past.
<cphealy>
I'm sure the same could be done with u-boot... ;-)
<cengiz_io>
which marex loves
<marex>
cphealy: that's irrelevant
<cphealy>
;-)
<cengiz_io>
hello u-boot champion
<marex>
getting graphics working in the bootloader is too much work
<marex>
just use linux, it is much easier and you dont have to debug two things
<cphealy>
The reason I had this put in the bootloader was to support "fast" automated testing of HW during manufacturing. No need to load a full OS to put a picture on the screen when testing thousands of units.
<cengiz_io>
instructions unclear. my board now runs openbsd
<marex>
with etnaviv ?
<marex>
cphealy: yeah well, then you amortized the investment into debugging the bootloader on the 1000s of units
<cphealy>
Well, someone does once. Once the bootloader has it, it's done and can be used by anyone (the opensource way...) ;-)
<cphealy>
We added color bars, solid colors, and geometry patterns too.
<cphealy>
It helped greatly for the HW folks doing HW bringup and testing.
<marex>
cphealy: great
<cphealy>
Unfortunately, even with the geometry pattern support, it still didn't prevent people from getting the touchscreen masking wrong...
<cphealy>
touchscreen masking - black paint on back of glass around active LCD area
<marex>
cengiz_io: so, are you running etnaviv on openbsd ?
<cengiz_io>
marex: lol no. I wouldn't even dare to boot openbsd with my board. I will try forcing software rendering now. see what happens
<cengiz_io>
let's assume that the banding issue goes away with software rendering. how can I use a newer etnaviv? by switching to a newer version of kernel I guess
<marex>
what do you run now ?
<marex>
also, got a picture of the effect ?
<cengiz_io>
sure.
<cengiz_io>
which image hoster is acceptable here?
<cengiz_io>
(sorry for the messy border around tft. country under 18 day lockdown. had to pack fast)
<marex>
cengiz_io: grayscale is still RGB-scale
<marex>
you can try ruling out separate colors -- use red or green or blue gradient only
<marex>
but the distribution of the bands might indicate something with specific signal in the 24 RGB signals being broken
<cengiz_io>
marex: I generated that image with # modetest -M imx-drm -s 43@34:800x480 -Fgradient
<marex>
or you have the data polarity wrong, so your scanout engine clocks the pixels at falling edge and the display also expects them at falling edge
<cengiz_io>
looks very curious doesn't it
<marex>
in that case, you have setup time violation and the banding might be a result of different capacitance of each line
<marex>
i.e. it almost works for most pixels, but not all
<marex>
maybe just quickly try .bus_format = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE and see what happens
<cengiz_io>
will do that. thanks
<cengiz_io>
btw marex I didn't add any explicit modes for this panel, I have added a timing struct (with min, avg, max values afaik)
<cengiz_io>
so the values are (I assume) evaluated somehow and proper mode is calculated right?
<marex>
so that's better asked in dri-devel, but pretty much yes, the timing struct permits the kernel to negotiate optimal timing between the scanout engine and the panel