08:45 pq: danvet, vsyrjala, what if you have a display with blue pixels? And nother with green pixels, and third where you have only blue and white, but no black? I think all those exist as some small embedded panels. None of them is gray scale or even black & white. Should supported KMS pixel formats reflect what colors there are?
08:46 pq: a very *very* hypothetical question
08:47 pq: perhaps as C8 with an immutable colormap
10:10 pinchartl: pq: userspace may need to know the colour of the pixels, but I think it's mostly an informative property, similar to the panel model or physical size, not something that necessarily needs to be reported through the 4CC
13:49 pinchartl: sravn: stop working on a Sunday ! :-)
13:58 sravn: pinchartl: You all need something to do on monday when you are all forced to work from home
13:58 pinchartl: sravn: that's the thing, I secretely hope that people will be forced to stop working, so I can catch up :-)
13:59 sravn: mripard: "dt-bindings: spi: support non-spi bindings as SPI slaves" - I have fixed your mail for a v2, but my ISP think it is spam so I cannot reply. Some may claim my ISP is right..
13:59 pinchartl: I've asked for years for the world to stop for a few months to let me catch up on my backlog
13:59 pinchartl: and finally it seemed that my wish would come true
13:59 pinchartl: but noooooo, everybody has to work from home instead :-)
14:00 pinchartl: sravn: I'm fairly busy these days, do you think someone else could review the panel patches ?
14:01 sravn: pinchartl: I would appreciate feedback "drm: drop data-mapping property from panel-dpi" - this is three trivial patches. The rest can be left for others
14:02 pinchartl: thanks
14:20 malice: Is it possible to run my monitor in non-vrr mode with dp?
14:26 emersion: yes, this should be the default
14:27 emersion: only xf86-video-amdgpu and sway support vrr as far as i know
14:27 emersion: in sway, you need to enable it in the config file for now
14:27 emersion: in xf86-video-amdgpu, it's only turned on when there's a fullscreen app which is not in a special hacky blacklist
14:27 malice: modeset lags tho
14:28 malice: emersion: I tried Option "VariableRefresh" "off" in xorg conf, my monitor still thinks it's in freesync mode
14:28 emersion: are you using xf86-video-amdgpu?
14:28 malice: Yeah
14:29 emersion: i don't know X11, sorry
14:29 malice: It has some overdrive features I want to try just for testing, but if it is running in vrr mode, it disables them from being used
14:29 malice: Vrr doesn't seem to actually work, but the monitor is still in that mode
14:30 malice: emersion: How do you make sway not have awful unusable input lag and mouse accel?
14:30 malice: It's so bad it's not even about "can't play competitively" at that point
14:30 malice: Legit can't even click links in web browser because my mouse just massively overshoots because accel and input lag
14:30 emersion: well, we don't have that issue in sway
14:31 malice: I did some things, and they made it better, but it just doesn't fully go away
14:31 malice: Feels disgusting compared to X :(
14:31 emersion: do you mean you've tried in sway and you get bad mouse accel?
14:32 malice: Yes
14:32 emersion: interesting
14:32 malice: I tried setting accel profile to flat, and that helps, but it really doesn't fix it, it's still quite disgusting
14:32 emersion: not sure what could cause this
14:32 malice: I legit can't even click on links in a web browser easily because of how bad it is
14:32 malice: emersion: Well, it's better than it used to be
14:33 emersion: since we don't do any framerate change limitations, you should get flickering instead of bad lag
14:33 malice: My mouse used to be legit stuck to the sides of the screen because of how bad it was
14:33 emersion: so if i had to guess i'd say it would be either a bad screen or an amdgpu kernel bug
14:33 malice: Works fine on xorg :(
14:33 emersion: it's disabled on xorg
14:34 malice: Don't think those are vrr related issues tho, just why sway is unusable
14:34 emersion: well, might be unrelated to vrr indeed
14:34 malice: emersion: Well, my screen is running at a high refresh rate on sway
14:35 emersion: if you have a sway bug, please report it on the issue tracker, with your config and debug logs
14:35 emersion: sometimes mesa decides to pick llvmpipe instead of using the GPU, which can cause huge delays when rendering
14:36 malice: emersion: Well, the mouse accel, is it a sway bug or libinput bug or?
14:36 malice: Eh
14:36 malice: emersion: I think things ran at a decent fps, not 100% sure tho
14:36 emersion: have you tried weston?
14:36 emersion: if you can reproduce on weston, it's probably not a sway/weston bug
14:47 malice: Hmm
14:48 malice: emersion: Well, monitor doesn't really unlock the vrr-locked options on sway either, at least not by default
14:49 emersion: by default sway doesn't enable VRR
14:49 malice: Hmm
14:49 emersion: you need to enable it in your config file
14:49 emersion: you can check with `swaymsg -t get_outputs` ("Adaptive sync" line)
14:49 malice: I mean, for some reason, the monitor thinks it has vrr enabled
14:50 emersion: well, monitor bug :)
14:50 malice: Maybe :D
14:50 malice: They used to be unlocked tho, long time ago, before linux got vrr support
14:50 malice: But I don't remember when they got locked
14:50 emersion: maybe it just means that VRR is enabled on the monitor side, ie. allows the GPU to send VRR content
14:50 emersion: but not that VRR is active
14:51 emersion: dunno
14:51 emersion: could be an amdgpu bug too, i guess
14:51 emersion: hard to tell
14:52 malice: Yeah, I have no clue where to look or what to blame with this :P
14:53 emersion: i'd open an amdgpu bug "screen says VRR is active even when it's not"
14:53 emersion: then see what the kernel devs say
14:55 malice: Xonotic with sdl video backend set to wayland doesn't even open a window, but x backend indeed gives a high fps, so, probably not llvmpipe?
14:56 malice: Mouse accel seems to be actually less an issue in-game than on desktop, hmm
14:56 malice: But that's probably off-topic here
17:03 linkmauve: Cool, wanna come over with Corona-chan?
17:03 linkmauve: Err, sorry.
17:23 FurretUber: There is something that happens when using zswap with Intel HD Graphics: where under relatively light swapping (around 200 MB) and when running a graphically intensive application, the system freezes, requiring to forcefully shutdown the computer
17:24 FurretUber: As Intel HD Graphics uses shared memory, is it incompatible with zswap?
17:33 imirkin: zswap just compresses swap, right? if so it shouldn't directly affect the GPU's ability to read RAM
17:34 karolherbst: imirkin: it's compressed RAM
17:34 karolherbst: essentially in memory swap
17:34 karolherbst: but yeah
17:35 karolherbst: if a swapped out page is accesed it should trigger a page fault and uncompress it again
17:37 FurretUber: This is a freeze scenario I'm seeing only with zswap enabled. Other computer functionalities seem to continue working normally, as I could SSH to it and even close the memory hogging applications, but i915 never recovered
17:38 FurretUber: I think I only have a dmesg for an older version now :(
20:03 danvet: pq, pinchartl could also do a read-only CTM I guess and R8/10 or whatever you have
20:03 danvet: I guess if some userspace wants to know about these special panels we'll figure it out
20:04 danvet: I guess some distinction between C8 and R8 would also be good under this model
20:04 danvet: since they're kinda the same
20:04 danvet: but I guess we could clarify that C8 is discrete, and the gamma ramp is a lookup table
20:04 danvet: whereas R8 is continuous, and the gamma ramp represents a (possibly interpolated) continuous function