<clever>
this is a custom shader i wrote, which at least handled alpha values of 0 and 1 within the texture
<clever>
but it is using mults, and should be able to blend as well
<clever>
anholt_: the only unknown left, is how both coordinate and vertex shaders, actually get data in, and emit it back out?, i think the attribute array stuff, lets you feed the xyz/vary of each vertex into the shader? and then it somehow writes shaded vertex data out
rasterman has quit [Quit: Gettin' stinky!]
<anholt_>
attributes are your inputs to your shader. VPM writes are the varyings that come out of the shader. fixed function hardware processes the VPM data produced to actually bin or render.
<clever>
ah, i dont think ive done anything with the VPM yet
<clever>
it almost looks like a matrix math unit, tacked onto the side of the QPU?
<anholt_>
it's basically just a block of ram that gets accessed by both the shaders and the fixed function rasterizer
<clever>
binning took 78 uSec(1123.199951) and rendering took 8249 uSec(118785.593750) @ 14.400000 MHz
<clever>
binning took 23 uSec(4968.000000) and rendering took 732 uSec(158112.000000) @ 216.000000 MHz
<clever>
i also swept the v3d over a range of freqs, and measured how fast it was, and the binning very rapidly bottomed out at ~23 uSec, and stopped getting faster
<clever>
while the rendering did improve with each step, but not by the amount i would expect, there are likely latencies unrelated to the v3d freq
<clever>
doubling the v3d freq, did not halve the rendering time, with 1 polygon
co1umbarius has joined #dri-devel
<anholt_>
v3d is limited by rpi's abysmal memory bandwidth
<clever>
the number in parens, is an estimated clock-cycle count, based on freq and uSec
<clever>
do you happen to know which clock the axi bus is running off of?
<clever>
i can freely control all of the clocks, including the ram clock
columbarius has quit [Ping timeout: 480 seconds]
<alyssa>
ITE: Enough VC4 guts to make me hug my Mali laptop close.
<anholt_>
I would guess it would be more of the sd clock limiting you, but :shrug: not that interested in following this investigation myself.
<clever>
anholt_: so basically, when using a coordinate shader, you put the shaded x/y into certain spots in the VPM, and the binner will do the rest for you?
<anholt_>
I would recommend reading the published spec, which tells you how to format your VPM outputs
<clever>
for the pi4, the v3d is behind its own dedicated mmu, to map the 32bit v3d view, onto the (up to) 16gig of physical space
<clever>
RPF engineers have also stated on the forums, that the pi4 dram controller, is way faster then benchmarking claims
<clever>
but due to NDA, they cant say how fast
<clever>
i'll re-read the VPM chapter in the pdf, and see if it makes any more sense now
<anholt_>
airlied: how does one debug virgl "Illegal command buffer 28836865"?
<clever>
i'm also curious as to what the pi4 changed, but there isnt much need yet, since i havent solved the 2d subsystem
<clever>
no way to get the frames out
<airlied>
anholt_: probably have to gdb the host server and break on vrend_report_context_error and backtrace it
<airlied>
anholt_: could be corruption, or just a bad value being passes
<airlied>
anholt_: it's pretty much the guest gave the host something it can't understand
<airlied>
the large value suggests it's getting a malformed command buffer
<clever>
anholt_: oh yeah, currently, i trigger the renderer thread, from the irq handler for the binner, but i see some scordboard opcodes in the control lists
<clever>
anholt_: can i start both at once, and have the binner tell the renderer when to go?
<clever>
airlied: yep, swapped out my host mesa, glxgears is still perfectly locked to vsync, and now i have v3d and vc4 libs available
<clever>
anholt_: ahhh, i see, when doing vertex shading, a form of MMU will map your VPM access to a pre-reserved region, and you just compute off that, but when doing user shaders, you need to manage it yourself, and tell the hw to keep out
<zmike>
gitlab dead again?
<zmike>
imirkin: I know this is your fault, fix it
<imirkin_>
zmike: i was thinking about submitting a MR
<imirkin_>
that must be it
<zmike>
I knew it
<zmike>
how could you do this to us
<imirkin_>
mea culpa
<zmike>
just put that thought back in your pocket and forget about it
<zmike>
the rest of us need the servers up
<zmike>
it's back up, thanks 👍
pnowack_ has joined #dri-devel
pnowack has quit [Ping timeout: 480 seconds]
<clever>
anholt_: thanks to your explanation, i can more easily understand what the docs are saying now, and the only unknown is what the difference is between Xc and Xs, one appears to be in 3d space, and the other in 2d space
<clever>
i'm guessing something like uniforms is used to feed a transformation matrix into the coordinate/vertex shader, and it will then translate/rotate the raw xyz, and the project it onto a flat xy space, and write it back to the VPM?
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #dri-devel
<clever>
anholt_: do you still remember much about how drivers/irqchip/irq-bcm2835.c worked? i'm getting weird interrupts on 161, and the HW irq numbers just dont go that high
mbrost has joined #dri-devel
mbrost has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
bluebugs has joined #dri-devel
macromorgan is now known as Guest6755
Guest6755 has quit [Read error: Connection reset by peer]
nchery has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
NiksDev has joined #dri-devel
<clever>
nvm, i think i figured it out
<clever>
the bootloader didnt mask all interrupts, it only disabled handling them in the arm core
<clever>
so when linux re-enabled irq's, some where unmasked, and began tripping
sdutt has quit [Remote host closed the connection]
idr has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
mlankhorst has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
itoral has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
agd5f has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
danvet has joined #dri-devel
Hi-Angel has joined #dri-devel
<airlied>
daniels, pq: hey simple-dmabuf-egl weston client, why does it do get handle and then prime handle->fd, I've no idea how that is even working at all
<airlied>
emersion: ^ maybe you know something
<airlied>
from my attempt at deciperhing it, that would get a gem handle from the underlying driver file descriptor, then convert that handle to a file descriptor on the gbm fd
<airlied>
which may not be the same fd
* airlied
isn't sure how it works at all, and is questioning my own sanity/knowledge :-P
* airlied
works out the craziness for iris, lots of dupfd
<airlied>
so thanks for being a rubberduck irc :-P
<HdkR>
dupfd + SCM_RIGHTS to really annoy people?
<airlied>
fight for your SCM_RIGHTS to dupfd
<airlied>
okay so the problem I thought this was, isn't the problem, zink is messier but should work
<HdkR>
I used SCM_RIGHTS directly for the first time a couple of days ago, fresh on the mind. Ancillary buffers are so jank
itoral has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
alanc has quit [Remote host closed the connection]
jessica_24 has quit [Quit: Connection closed for inactivity]
<emersion>
airlied: gbm_bo_get_fd_for_plane was missing for quite some time
<emersion>
however drmPrimeHandleToFD is a bad idea regardless
<emersion>
it'll mess up libdrm's gem handle ref'counting
<airlied>
emersion: ah get_fd_for_plane was added later, explans why the demo code didn't use it, yes didn't seem right to be calling drm function there
<emersion>
in wlroots, when gbm_bo_get_fd_for_plane isn't available, we fallback to gbm_bo_get_fd, but also check that all planes handles are equal
jkrzyszt has joined #dri-devel
<emersion>
we had code similar to simple-dmabuf-egl before, but caused some drivers to freak out
mattrope has quit [Remote host closed the connection]
rgallaispou has joined #dri-devel
mattst88 has quit [Ping timeout: 480 seconds]
hanetzer1 has joined #dri-devel
hanetzer1 has quit [Remote host closed the connection]
hanetzer1 has joined #dri-devel
<danvet>
mlankhorst, btw quite some things in drm-misc-next-fixes
hanetzer has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
tursulin has joined #dri-devel
cef has quit [Remote host closed the connection]
cef has joined #dri-devel
mattst88 has joined #dri-devel
hanetzer1 has quit [Remote host closed the connection]
hanetzer1 has joined #dri-devel
pcercuei has joined #dri-devel
mattst88 has quit [Ping timeout: 480 seconds]
<mlankhorst>
? Should have been small
mattst88 has joined #dri-devel
thellstrom has joined #dri-devel
jhli has quit [Remote host closed the connection]
mattst88 has quit [Ping timeout: 480 seconds]
soreau has quit [Remote host closed the connection]
soreau has joined #dri-devel
<pq>
Company, bilinear filtering tends to make things blurry anyway, so best to avoid as much as possible.
<pq>
mareko, what do you imply with "blending with premultiplied alpha is mathematically an associative operation"?
<pq>
mareko, for some context: if a compositor needs to do color space conversion or even just linearization before blending, then it can't use premul alpha, it has to undo premult first.
ppascher has quit [Ping timeout: 480 seconds]
<MrCooper>
at least there's a fighting chance for that with floats :)
<pq>
also bilinear filtering should be done on light-linear values, but all pixel buffers tend to contain nonlinear (sRGB encoded) values.
<pq>
so there are many reasons to just avoid bilinear filtering as much as possible in a compositor
<emersion>
well you need to de-linearize the pixel values if you want to do any kind of operation on them right?
<emersion>
e.g. blending
mattst88 has joined #dri-devel
<emersion>
so bilinear filtering isn't much of a special case here?
<pq>
emersion, that's true.
<pq>
err, you mean, linearize
<pq>
unless your users are accustomed to non-linear blending and scream at you for making their window shadows look bad
<emersion>
and then go on about how the real world looks bad as well
<emersion>
"but why are physics de-linearizing gamma values when i look through a glass?"
<pq>
I believe GL and others have the sRGB texture formats for the GPU to linearize during sampling so bilinear filtering works correctly, but that's fine until you have non-sRGB non-linear values. Like PQ in HDR.
<emersion>
yeah… and mesa doesn't support sRGB textures for EGLImage
<pq>
oh, boo
<pq>
well, good, because then I don't need sRGB texture code in Weston :-)
<pq>
since I need the generic path in any case
<emersion>
there's an extension that allows you to specify "it's sRGB" when creating an EGLImage, but… the EGL/GL impl needs to implement it for all types of EGLImages
<emersion>
hm, what do you mean by "generic path"?
<emersion>
everything done manually in shaders?
<pq>
the ability to use any encoding curve, not just the sRGB one
<emersion>
ah
<pq>
yeah, manually in shaders
<pq>
that part is already in upstream weston
<emersion>
makes sense, sRGB being only a special case (so the sRGB textures would only be an optimization)
<pq>
exactly
<emersion>
will the color management proto require the compositor to support arbitrary curves?
<pq>
yes, but also the compositor could reject color profiles at will, so maybe not quite
<pq>
reject gracefully, that is
<emersion>
are there other situations where it makes sense to reject color profiles?
<pq>
yeah, ICC spec has a huge amount of freedom and clients could give any wild ICC files that are not for displays at all.
boistordu_ex has joined #dri-devel
<danvet>
mlankhorst, hm yeah not too much, but the fbdev fix from Tetsuo is a security one :-)
<emersion>
i see
<pq>
like, not three channels
<pq>
ISTR they support up to 15 channels
<pq>
there's also several versions of ICC
<pq>
depends on the CM libs you use what you can read
<pq>
so graceful failure is kind of must to have, since it's impossible to spec what kind of ICC files must be supported
<pq>
*infeasible
<pq>
ICC files won't be only way to submit a color profile, there are also parametrised and enumerated interfaces. Not limited to sRGB encoding, of course.
<pq>
so I suppose a compositor could decide to not support client ICC files at all, and just do the parameterised/enumerated interfaces.
<emersion>
cool
<emersion>
hm
<pq>
might be suitable for non-desktop use
<emersion>
is there some kind of "baseline" so that we can always have a fallback?
<emersion>
i guess the hard fallback is default to whatever the compositor does without the color management stuff
<pq>
emersion, fallback in what way? I mean, if a client doesn't set up a color profile, then sRGB is assumed, for backwards compatiblity.
<emersion>
just a bit worried about clients and compositors expecting/supporting entirely different things
<emersion>
since the set of supported features is very big
<emersion>
kind of like atomic commits
boistordu_ex has quit [Remote host closed the connection]
<pq>
I think the parametrised/enumerated interfaces can't be gracefully denied by a compositor implementation.
<emersion>
you can check whether something is supported, but not easily check what other alternatives would be
<emersion>
i see
<pq>
IIRC there is also the escape hatch for client to say "this image is already in the output color space", after which it's up to the client to actually make it so.
<emersion>
in the case where a professional photo editing tool isn't used, would most clients be able to use the parametrised/enumerated interfaces?
<emersion>
e.g. if i'm playing a movie, are the parametrised/enumerated interfaces enough?
<emersion>
hm
<pq>
sure, they're enough for movies and HDR and games and stuff
<emersion>
ok, so the full ICC stuff would only be useful for power users
<pq>
up to the app
<emersion>
well, yeah
<emersion>
i kind of hope clients use the sRGB enumerated thing, instead of manually computing the ramp and sending it as an ICC profile
<pq>
image files can come with embdedded ICC files, btw.
<pq>
like PNG IIRC
<pq>
I dunno about video file formats, but I'd expect them to use some parametrised description instead, since ICCv4 (the currently most used version) doesn't really do HDR.
<tpalli>
I wonder if someone here tested vkAcquireXlibDisplayEXT and display events before? getting some strange issues with drmCrtcQueueSequence failing
<tpalli>
vkAcquireXlibDisplayEXT seems to succeed fine but registering display events fails
<emersion>
i've tested the wayland counterpart a few weeks ago
myth0s has joined #dri-devel
<tpalli>
emersion what did you use for testing?
<emersion>
monado
<tpalli>
I assume you are not referring to mythical sword in Xenoblade Chronicles
<tpalli>
hmm I wonder if there is some simpler framework/test available
myth0s has quit []
<tpalli>
monado does not seem to utilize vkRegisterDisplayEventEXT
<emersion>
there are forks of vkcube iirc
Viciouss has quit [Ping timeout: 480 seconds]
<haagch>
pretty sure keith had a vkcube that used drm lease directly
<haagch>
this hasn't been touched in a long time, but it uses the vulkan extension https://gitlab.com/lubosz/xrgears (it's also what the monado compositor was initially derived from)
<haagch>
someone should probably write a compact canonical test app for both
vivijim has joined #dri-devel
<tpalli>
this has same problem, it does not use EXT_display_control (display events or swapchain counter)
<haagch>
yea but I imagine it is easier to hack into a standalone codebase than into the monado compositor
<tpalli>
right ok
<tpalli>
thanks will see if thing would work out with that
<tpalli>
I agree also on the testing point, I'm working on some tests since I want to refactor things in this area
Company has joined #dri-devel
<haagch>
sounds like a very useful extensions, I wonder why we don't have that in monado already
hansg has joined #dri-devel
shfil has quit [Ping timeout: 480 seconds]
<hansg>
Hi All, After pushing 2 patches to drm-intel-next, I just hit a merge error when rebuilding drm-tip, the error is in merging drm-next and the conflicts are in the amdgpu driver. So I guess this means that I did not cause this and someone else is already working on resolving this ?
<hansg>
While I'm asking for help anyways, I also have this trivial DMI quirk patch pending: https://patchwork.freedesktop.org/patch/452464/ These type of patches are so trivial, that it seems that everyone just overlooks them, so they never get an Ack. If someone can take a quick peek to do a sanity check and ack this, it would be great.
flto_ has joined #dri-devel
flto has quit [Ping timeout: 480 seconds]
flto_ has quit []
flto has joined #dri-devel
<danvet>
hansg, maybe sravn or tagr has some equally simple panel patches to ack trade?
<mareko>
pq: the associative property of the blending operation with premultiplied alpha is a requirement for correct composition and filtering that can be mathematically proved; unpremultiplied alpha lacks that
agd5f has joined #dri-devel
<pq>
mareko, filtering I can easily believe, but for compositing? What blending equation are you thinking of?
sdutt has joined #dri-devel
dviola has quit [Quit: WeeChat 3.2]
<hansg>
sravn, tagr if you do have any patches to trade a review/ack on, I would certainly welcome that
<pq>
mareko, I can't see how the usual OVER operator could be associative, given the background color needs to be multiplied with (1 - foreground_alpha).
<pq>
mareko, re: filtering; how does filtering work with sRGB textures that have an alpha channel? Those cannot have premult alpha, can they?
<pq>
You'd need to store straight alpha, and texture sampling needs to 1. convert to light-linear, 2. multiply by alpha, 3. filter, right?
<imirkin>
by "feature of the year", i mean of course, "feature which should be removed this year"
<imirkin>
ajax: i thought the whole point of srgb was "i want linear blending in a non-linear color space". so doing the conversion on alpha would defeat that...
frieder has quit [Remote host closed the connection]
<ajax>
imirkin: right. the rgb channels are gamma-compressed when stored as unorm8 because that makes them usefully "linear" once they're expanded to float to work on. alpha is already linearized, there's no reason to want to gamma-compress either coverage or opacity.
macromorgan is now known as Guest6796
macromorgan has joined #dri-devel
idr has quit [Ping timeout: 480 seconds]
Guest6796 has quit [Read error: Connection reset by peer]
dviola has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
jessica_24 has joined #dri-devel
Surkow|laptop has quit [Remote host closed the connection]
macromorgan has quit [Ping timeout: 480 seconds]
Surkow|laptop has joined #dri-devel
macromorgan has joined #dri-devel
macromorgan is now known as Guest6801
macromorgan has joined #dri-devel
Guest6801 has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
<Company>
pq, ajax: when you have hw overlays, do they do alpha compositing? And if so, is that premult or not?
jhli has joined #dri-devel
dhwohrom^ has joined #dri-devel
<imirkin>
Company: cursors are meant to be premultiplied i think
<imirkin>
Company: however regular planes .... not sure.
<emersion>
yes and yes
<Company>
so my conclusion from yesterday that for float you want to not use premultip[lied seems to be very wrong
hansg has quit [Quit: Leaving]
macromorgan has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
<Company>
and it might even be the opposite: you want to use premult everywherer
hanetzer1 has quit [Read error: Connection reset by peer]
hanetzer1 has joined #dri-devel
<Company>
and only unpremult if you hit a use case where that's relevant
alatiera has joined #dri-devel
ngcortes has joined #dri-devel
alatiera is now known as Guest6808
<mareko>
pq: when you blend b on top of c, and then a on top of that, i.e. (a o (b o c)), premult alpha enables associativity, so that you can blend a and b into a temporary and then blend that on top of c, i.e. ((a o b) o c)
macromorgan is now known as Guest6810
Guest6810 has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
bluebugs has quit [Read error: Connection reset by peer]
bluebugs has joined #dri-devel
<mareko>
pq: premult alpha results in correct filtering because of the associativity, i.e. it blends neighboring pixels first and then it blends the result on top the destination image
<Company>
how is blending even defined for post-multiplied?
<Company>
transparent red over transparent green - what's the result?
<mareko>
it's just linear interpolation using alpha
<Company>
that would mean it stays transparent green
macromorgan has quit [Read error: Connection reset by peer]
macromorgan_ has joined #dri-devel
<mareko>
it doesn't matter, it can be proven that post-multiplied is not associative, and that's sufficient
<swick>
Company: normal blend mode isn't translucency
<swick>
for normal blend mode the order does not matter because it calculates the converage of the pixel
<swick>
which means you *need* associativity which you do not get with straight alpha
<swick>
I'm not sure if the same is true for tranlucency
<swick>
but what I do know is that in the compositor we must work with straight alpha on any color transforms
dllud has quit [Read error: Connection reset by peer]
dllud has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.2]
<Company>
yeah, the rule of thumb seems to be that you want straight alpha for colors and premult alpha for pixels
<Company>
and with that rule of thumb, it's obvious that color transforms aren't pixel transforms
<Company>
of ourse, there's a huge overlap, so one will run into issues all the time
macromorgan has joined #dri-devel
macromorgan_ has quit [Read error: Connection reset by peer]
<dviola>
1
<dviola>
oops, sorry, the keyboard on this laptop is messed up
Hi-Angel has quit [Remote host closed the connection]
dllud_ has joined #dri-devel
dllud has quit [Read error: Connection reset by peer]
dllud has joined #dri-devel
dllud_ has quit [Read error: Connection reset by peer]
hanetzer1 has quit [Remote host closed the connection]
hanetzer1 has joined #dri-devel
iive has joined #dri-devel
quasselcore has quit [Read error: Connection reset by peer]
quasselcore has joined #dri-devel
quasselcore has quit [Read error: Connection reset by peer]
quasselcore has joined #dri-devel
quasselcore has quit []
bluebugs has quit [Ping timeout: 480 seconds]
ngcortes has quit [Read error: Connection reset by peer]
bluebugs has joined #dri-devel
quasselcore has joined #dri-devel
ngcortes has joined #dri-devel
bluebugs has quit [Ping timeout: 480 seconds]
bluebugs has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
<cengiz_io>
hello there. I hope you're having a good day.
Duke`` has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
<dianders>
Looks like `dim rebuild-tip` is currently broken due to a pre-existing merge conflict. Is that something folks here would be able to help with?
Duke`` has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
pendingchaos_ has joined #dri-devel
pendingchaos has quit [Read error: No route to host]
<airlied>
dianders: oh my fault maybe
* airlied
needs my brain for this, will fix it in an hour
pendingchaos_ is now known as pendingchaos
idr has joined #dri-devel
samueldr has joined #dri-devel
Hi-Angel has joined #dri-devel
macromorgan is now known as Guest6825
macromorgan has joined #dri-devel
Guest6825 has quit [Ping timeout: 480 seconds]
macromorgan is now known as Guest6826
macromorgan has joined #dri-devel
Guest6826 has quit [Ping timeout: 480 seconds]
macromorgan has quit [Quit: Leaving]
macromorgan has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
ngcortes has quit [Ping timeout: 480 seconds]
vivijim has quit [Ping timeout: 480 seconds]
hanetzer1 has quit [Remote host closed the connection]
hanetzer1 has joined #dri-devel
<samueldr>
hi, trying to implement a panel driver for a specific controller, st7789s, based loosely off the existing s7789v panel driver
<samueldr>
and I'm unsure how to get the drm_display_mode .clock value
<samueldr>
(first time getting knee deep in drm stuff)
Bennett has joined #dri-devel
<samueldr>
unsure whether it matters it's being used with sun** (suniv actually) display engine
hanetzer1 has quit [Remote host closed the connection]
hanetzer1 has joined #dri-devel
NiksDev has quit [Ping timeout: 480 seconds]
hanetzer1 has quit [Remote host closed the connection]
<samueldr>
the fact I'm getting `Division by zero in kernel.` with sun4i_tcon_mode_set and sun4i_dclk_round_rate kind of makes me assume something with the clock rate is what is currently making things unhappy
<samueldr>
e.g. no need to look into why I get "vblank wait timed out" if something much earlier is clearly unhappy
hanetzer1 has joined #dri-devel
<samueldr>
or I would say unclearly unhappy; unclear why there's a division by zero
bluebugs has quit [Read error: Connection reset by peer]
cedric has joined #dri-devel
<marex>
samueldr: are these two panels somehow overly different ?
cedric is now known as bluebugs
<marex>
samueldr: the clock is pixel clock of the panel in kHz, no ?
<marex>
yep, htotal * vtotal * 60 Hz gives cca 6 MHz , which is close enough to the pixel clock
<samueldr>
marex (hi) I don't know for sure; one thing to note is that the resolution is set to 240x320 in the V variant, 320x240 AFAIUI in the S variant
<samueldr>
(and I'm not sure whether it matters or not that it's a controller, and not an LCD panel outright?)
<samueldr>
I don't really have any background knowledge with panels and such, so those values you just said are mostly going over my head :)
<samueldr>
is pixel clock a different thing from dot clock?
<samueldr>
(currently looking at the datasheet for instances of clock
dviola has quit [Remote host closed the connection]
<samueldr>
one major difference, I assume, is that the controller is not using SPI here
<samueldr>
though now looking at the frontpage of the datasheet, it's clearly written 240x320 so uh
<marex>
samueldr: maybe V means vertical and S means ... sideways ? :)
<samueldr>
plausible!
<marex>
samueldr: so what is it using if not SPI ?
<samueldr>
of note: not an expert (yet?), and doing it as an enthusiast without any support
<samueldr>
parallel interface; here on f1c100s it's the "LCD" pins used by the display engine, which also multiplex as GPIO
<marex>
samueldr: parallel interface, like the i80 ?
bluebugs has quit [Ping timeout: 480 seconds]
<samueldr>
good question: see "not an expert"; though I can guess "maybe" from the chapter titles "8080- I Series MCU Parallel Interface" and "8080- II Series MCU Parallel Interface""
<marex>
samueldr: are you sure there isn't some i2c connected to the panel through which it is configured ?
<samueldr>
pretty sure; I implemented a "uint16"-banged fbdev driver that works
<marex>
oh
<samueldr>
and for U-Boot too (ugly and needs to be reworked, probably once I better understand those tcon and DEBE things
<samueldr>
right now things are hanging on *something* causing a division by zero when using that clock value,,, at least until the next stumbling block
italove has quit []
padovan4 has quit []
leandrohrb27 has quit []
fahien2 has quit []
tomeu has quit [Quit: Ping timeout (120 seconds)]
shadeslayer has quit [Quit: Ping timeout (120 seconds)]
<marex>
samueldr: doesn't the kernel generate a backtrace at that point ?
<samueldr>
yes
<samueldr>
it could be a missing configuration in the suniv dts for the display engine; I've forward ported patches by icenowy
<marex>
and does it help ? can you share it ?
<marex>
samueldr: ah, I _think_ that is icecream95 here (I might be wrong)