ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
apritzel has quit [Ping timeout: 245 seconds]
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #armlinux
tchebb has quit [Ping timeout: 252 seconds]
tchebb has joined #armlinux
alpernebbi has quit [Ping timeout: 246 seconds]
alpernebbi has joined #armlinux
vireshk has quit [Ping timeout: 252 seconds]
vireshk has joined #armlinux
iivanov has joined #armlinux
amitk has joined #armlinux
nsaenz has joined #armlinux
amitk has quit [Ping timeout: 245 seconds]
* ukleinek
groans at sparc64 allmodconfig not building on drm-misc-next
<geertu>
javierm: I guess these can be exposed to userspace now
<javierm>
geertu: yes, and I was thinking that may use your fourcc formats instead now that those exist
<javierm>
geertu: btw, I've sent you the fix your suggested. Please review the commit message since I may misunderstood your explanation from yesterday
amitk has quit [Ping timeout: 245 seconds]
jpanisbl has quit [Ping timeout: 245 seconds]
nsaenz has joined #armlinux
amitk has joined #armlinux
<headless>
linusw__: hey! haven't you replied to me by chance?
<geertu>
javierm: Hmm, that looks like a gamma table
<geertu>
The note is interestin: The pulse width value of GS1, GS2, .... , GS15 should not be equal. i.e. 0<GS1<GS2 … <GS15
<geertu>
1. Is that a hardware limitation?
<javierm>
geertu: I don't think that's a HW limitation but rather that if you make it equal, then is not 16-grayscale anymore, in other words you are not using all the 4 bits
<geertu>
2. Are different but not monotonically increasing values supported? That would support a greyscale LUT
<geertu>
We don't have fourcc codes for that yet
<geertu>
javierm: R1 is working fine for the text console. Let's rebase to drm-misc...
<javierm>
geertu: and if you have a default table? Because that's what I'm using in my patch to add support for ssd132x controllers
<javierm>
geertu: "10.1.18 Select Default Linear Gray Scale Table (B9h)"
<javierm>
in that case is R4 right ?
<geertu>
javierm: Yes
apritzel has quit [Ping timeout: 252 seconds]
<javierm>
geertu: cool, I'll do that for now and then we can define a different fourcc code and add support to define different gamma tables
<javierm>
geertu: nice. If you can post that R1 patch I can review it / merge
<javierm>
geertu: do you see any noticeable perf improvement by not doing the xrgb24 -> mono conversion?
<geertu>
javierm: For ssd1327, you can expose the gamma table through drm_mode_crtc_set_gamma_size()/drm_crtc_enable_color_mgmt(), but I believe currently DRM supports 256 entries only.
<geertu>
javierm: Haven't done any benchmarking yet. The display is small and the device has a limited userspace.
<geertu>
And it's slow, regardless
<javierm>
geertu: yeah, was just out of curiosity. Still is the correct thing to do and expose the hardware native format
<javierm>
geertu: IIRC the board that is using that panel is slow as well anyways :)
<geertu>
javierm: it's gonna have more impact on the 1Mpixel ePaper displays.
<geertu>
I could connect it to a faster machine...
<javierm>
geertu: no worries, I was just curious
<javierm>
geertu: re: drm_mode_crtc_set_gamma_size()/drm_crtc_enable_color_mgmt() - as mentioned will just use the default and C4 to allocate the native pixel buffer, then we can add custom gamma table on top
<javierm>
err, R4. I keep getting confused :)
<javierm>
geertu: I already said to you, but it's cool to know that there is another user than myself for that driver ;)
<javierm>
most people seem to be using user-space libraries to drive those panels
headless has quit [Quit: Konversation terminated!]
jpanisbl has joined #armlinux
phh|new is now known as phh
jclsn has joined #armlinux
jclsn has quit [Client Quit]
jclsn has joined #armlinux
salll has joined #armlinux
jpanisbl has quit [Quit: Konversation terminated!]
salll has quit [Remote host closed the connection]
salll has joined #armlinux
<geertu>
javierm: How come 49d7d581ceaf4cf8 ("drm/ssd130x: Don't allocate buffers on each plane update") works for you?
<geertu>
ssd130x_buf_alloc() is called too late, causing a crash
<geertu>
Because you don't have a text console running?
salll has quit [Remote host closed the connection]
<javierm>
geertu: oh, I was pretty sure that tested with a VT too...
<javierm>
geertu: I don't understand how can that be though since the allocation happens in the encoder .atomic_enable and that should be called before any plane update ?
<geertu>
javierm: is your drm driver builtin?
<geertu>
(mine is)
Turingtoast has joined #armlinux
<javierm>
geertu: yes, built-in. Let me try with latest drm-misc build
<javierm>
geertu: hmm, just booting latest drm-misc and console is working correctly for me
<javierm>
geertu: this is with 7dae503584a1 as HEAD
<geertu>
javierm: do you have a logo enabled?
<geertu>
You may need a custom one, as the 80x80 Penguin may be too large
<javierm>
geertu: ah, I don't
<javierm>
geertu: and when bailing out earlier when is NULL, you do see the logo eventually ?
amitk has quit [Ping timeout: 245 seconds]
<geertu>
Actually I do
<geertu>
Probably it's just refreshed later?
<javierm>
I'm still confused why the plane update happens before the encoder enable but I also don't see why we shouldn't check for the buffer so I'm OK with your fix
<geertu>
javierm: Probably data_array should be allocated in probe(), using devm_*?
<geertu>
And buffer when needed first, also using devm_*?
apritzel has joined #armlinux
ajb-linaro has joined #armlinux
<javierm>
geertu: I actually thought about it when writing that patch but didn't want to allocate if the display wasn't used
<geertu>
javierm: data_array is small
<javierm>
geertu: yeah, that's true too
<javierm>
geertu: I'll be OK with that change too, but probably drmm_kzalloc since devm and drm object lifetimes don't play that well together