12:29 javierm: tzimmermann, mripard: I've started reviewing this series https://lore.kernel.org/dri-devel/20261019213726.4145532-1-devarsht@ti.com/T/#t but there are patches that are exposing custom device-specific KMS properties...
12:41 javierm: anyway, commented on the list but just FYI in case you want to chime in
12:50 vsyrjala: unexport the property create functions? bunch of old non-standard props would need to be grandfathered in though
12:55 pq: gosh, an actual proper use of DRM_FORMAT_R1? "red ink on white" :-D
12:55 pq: buuut...
12:58 pq: I didn't get how R1 could do 3 colors.
13:02 pinchartl: pq: classical application of the tri-state boolean: https://thedailywtf.com/articles/What_Is_Truth_0x3f_
13:04 javierm: pq: yeah, I think they should use C1 instead of R1
13:04 javierm: because AFAIU the driver is using this "3-color mode" property to decide to use black or red on white
13:05 javierm: *either black or red
13:13 javierm: in fact, by doig C1 + palette, they could just use the standard GAMMA_LUT KMS property, for user-space to decide to which color to map the C1 value
13:15 javierm: instead of trying to add this driver-specific color_mode property
13:25 pq: yes, although I was more wondering exactly what pinchartl referred to: how does one get three different states from one bit? :-)
13:26 pq: IOW, C2 would seem like the proper format.
13:27 javierm: pq: indeed, specially since it seems that mutually exclusive red-on-white or black-on-white was a restriction of the driver, not the device
13:28 pq: The GAMMA_LUT palette (which does not exist with colorops I believe) would be in the wrong direction, would it not? It would be from palette to RGB, when this hardware needs anything to palette instead.
13:28 javierm: yeah, I think you are correct
13:28 pq: It's like the panel should expose an immutable palette for a C2 format.
13:31 pq: The palette would also be a connector property? But the whole thing is awkward because KMS (with or without colorops) kind of assumes that everything between the FB and the connector happens in RGB.
13:34 pq: we end up with something like: FB in C2 format -> expand to RGB -> plane color pipeline -> blending -> CRTC color pipeline -> quantize down to C2 with the fixed palette -> panel
13:36 pq: I would be surprised if the display controller there implemented anything but C2 pass-through, but that should be fine: expose exactly one KMS plane and only identity/no-op color pipelines.
13:37 pq: It's just that conceptually it would need to be modelled like that RGB path.
13:37 pq: and there would need to something to say that the FB palette must equal the connector's palette.
13:45 javierm: pq: yes, that's why the ssd130x driver always exposes an XR24 format and only converts to R1 (for the monochrome panels) or R8 (for 8-bit greyscale panels) update the actual device memory that requires the native format
13:46 javierm: although in that case is easier because the devices only support a single channel, they are whatever-on-whatever but the color is fixed at the HW level
13:46 pq: aye
15:16 lumag_: mripard, narmstrong, While cross-checking decode/display of the compressed images, one thing came to my mind. Is there any plan on how to specify chroma location for decimated formats? Should we assume left chroma location or top-left?
15:24 CounterPillow: mripard and lumag_: so, some parts of HDMI VRR transitions are in essence a state machine clocked by frame presentations and affect HDMI infoframes. I was hoping I could handle this in the connector atomic_check, but nope: if userspace commits another frame without changing user-facing connector state the connector atomic_check is skipped. That means I can't set a certain flag in the EMP infoframe to indicate a VRR rate is constant after
15:24 CounterPillow: the transition to said constant rate is complete, because the constant-ness means the atomic_check is never re-run. Any preferences in how to solve this?
15:24 CounterPillow: daniels suggested one solution could be that userspace's atomic commit just goes through the whole multi-frame transition. The other solution I can think of is some new atomic_tick callback that gets called for each component and each commit. The last solution I could imagine is that for this case, atomic_check on the connector is run regardless
15:27 lumag_: CosmicPenguin: do you need to run it per commit or per vblank?
15:28 CounterPillow: Per vblank, from what I can tell
15:29 CounterPillow: which does mean doing it during atomic commit might not be the right thing at all
15:29 CounterPillow: at the same time this needs to mutate the encoders registers to write the new infoframes, and also use the atomic state to generate the VTEM EMP, so that's fun
15:29 lumag_: Does hardware assist you with the Infoframes? Otherwise it might become too fragile
15:33 CounterPillow: Judging by the hardware having registers to set the order in which frames are transmitted, I hazard a guess that it times the packets, so we just need to set the state right
15:33 CounterPillow: but the packets themselves are packed by us and written to a bank of registers
15:34 lumag_: From what you have described, a separate drm_hdmi_vblank() helper might be a good idea.
15:35 lumag_: Then the driver can call it from the vblank handler.
15:35 lumag_: The only question is about HDMI bridges
15:36 CounterPillow: the hardware in question (RK3588) uses a bridge connector fwiw
15:36 CounterPillow: thanks for the hint, I was not at all thinking about the vsync being the clock here rather than the atomic commits
18:08 alyssa: why does imul_32x16 take two 32-bit sources? x_x
18:16 glehmann: probably because it's from the ancient times
18:18 alyssa: fun
18:19 alyssa: SPV_INTEL_shader_integer_functions2 defines it as such. charming.
18:30 glehmann: we can always downcast in vtn/glsl if it helps you
18:31 glehmann: but not sure how well elk and brw deal with16bit integers
18:54 alyssa: glehmann: I'm defining some new jay nir opcodes anyways, I can add them to the bucket but also lol