ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
slattann has joined #wayland
sozuba has joined #wayland
wroathe has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
<pq>
emersion, VQ@ is a listed id in hwdata for Vision Quest
<emersion>
"nice"
<emersion>
well nothing in the spec says that these aren't valid ASCII chars
<pq>
emersion, there is also "inu", "Inovatec S.p.A.", so no caps
naveenk2 has joined #wayland
<emersion>
that one is weird, since you can't hit it at all
<emersion>
is there "INU", all caps?
<pq>
mmm, hah, trie
<pq>
*true
<pq>
nope, no INU
<pq>
I'm writing the colord display id generator, and wondering if I could ever deem a PNP ID to be invalid, not be caught in "my PNP ID database is outdated".
<pq>
also, isupper() uses the current locale...
<pq>
maybe edid-decode that ensure the locale, but libdisplay-info probably not
<pq>
*can ensure
<dottedmag>
K&R C was so much simpler.
<dottedmag>
At least w.r.t. locales, heh
<emersion>
i thought colord was out of the picture for color management?
<emersion>
it would be easy enough to 'A' <= ch && ch <= 'Z'
<pq>
emersion, presumably someone else would like libdisplay-info to provide this, and also weston's deprecated but not yet deleted cms-colord would like it.
<pq>
emersion, right, but we should probably allow '@' too, right?
<vsyrjala>
why do you care beyond the value fitting in the 5 available bits?
jgrulich has quit [Quit: Konversation terminated!]
jgrulich has joined #wayland
flibitijibibo has quit [Quit: Leaving]
<swick>
pq: fwiw I'm trying to kill of colord and hughsie is on board
<swick>
so I wouldn't worry too much about colord
sav10_ has quit []
chipxxx has quit [Ping timeout: 480 seconds]
<pq>
swick, oh? What do you do with scanners, cameras, etc. then?
<pq>
swick, anyway, colord is not a problem. The problem is to figure out whether the "get make/model/serial" strings should be defined suitable as configuration keys or should we have a different API configuration keys.
<pq>
and what encoding those strings are and what characters are allowed in them
<pq>
right now my idea is that "get make/model/serial" are purely for human consumption, and configuration keys should be another API.
<pq>
"for human consumption" will allow us to easily extend those functions to return and prefer data from DisplayID blobs regardless of EDID
<swick>
well the problem is that colord's XRANDR Display Device uses vendor, model, serial as the config key
<pq>
that's not a problem
<pq>
I am writing a separate API to return exactly the colord id
<swick>
ah, yeah that should be fine then
<swick>
btw there is also a localization ext
<pq>
what does that do?
<swick>
have not looked at how it works but when you want "for human consumption" that might become interesting
<pq>
aaha
<pq>
swick, I'm pretty close to pushing updates to my open MRs and one more MR for the colord id API. Might be nice to take a look then.
<pq>
the problem with config key API, especially if it delivers only one string, is that different compositors already use differently constructed strings, and cannot break old configs.
<pq>
colord OTOH had written a spec for the key, so it's an easy target
<emersion>
if colord is being phased out, probably not a good idea to ship an API for it
<pq>
if we don't ship an API for it explicitly, we need to ship an API that offers the equivalent, because old stuff is still used, I presume
<pq>
you could also say that one gets to implement it oneself with the low-level API...
<swick>
yeah we have code for that in mutter rn
<emersion>
i think it depends when you intend to drop that usage
<swick>
re other devices with colord: turns out you can configure printers, scanners and cameras in a lot of ways which change the color characteristics, just like displays
<emersion>
if it's in a few releases vs. if it's in 10 years
<pq>
Ine idea I'm carrying for the high-level API is that compositors would not need to grow new code every time EDID or DisplayID grows a replacement for some old field. Is that unwanted?
<pq>
*One
<swick>
it's not like the API would hurt anyone
<swick>
even if colord will be deprecated
migro has quit []
<pq>
yeah, I think the maintenance cost should be very small. If no-one needs it, it doesn't need new features, and it's completely decoupled from other high-level API, using only low-level API which probably will stay forever.
<pq>
OTOH, dead code it dead.
<pq>
*is
migro has joined #wayland
<pq>
let me update my MRs tomorrow and let's discuss it then
Bran[m] has joined #wayland
sav10 has joined #wayland
lyudess has quit []
Lyude has joined #wayland
audgirka has quit [Remote host closed the connection]
fmuellner_ has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
carbonfiber has joined #wayland
co1umbarius has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
sav10 has quit []
slattann has quit []
rv1sr has joined #wayland
kts has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
naveenk2 has quit []
manuel_ has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
agd5f_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
fmuellner_ has quit [Ping timeout: 480 seconds]
CyprusSocialite has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
flibitijibibo has joined #wayland
jgrulich has quit [Ping timeout: 480 seconds]
gschwind has quit [Quit: Leaving]
MajorBiscuit has joined #wayland
devilhorns has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
MajorBiscuit has quit [Ping timeout: 480 seconds]
mriesch_ has quit []
mriesch has joined #wayland
manuel_ has joined #wayland
kts has joined #wayland
<i509VCB>
Is it typically expected that a compositor could render NV12 and other multi-planar YUV formats if the scan out supports that format or is it typically expected to convert to rgba or some permutation of that?
fmuellner has joined #wayland
<emersion>
mesa has lowering of NV12 in the common code
<daniels>
yeah, depends what you mean by 'render NV12' - many compositors advertise & accept NV12 as an input buffer format from clients, though it's by no means mandatory
<daniels>
if you mean in the other direction, then again that can & does happen - if you're doing screencasting in particular then a popular destination like H.264 is effectively (a worse version of) NV12\
<emersion>
right, "rendering to" and "texturing from" are two different operations
fmuellner has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
<i509VCB>
rendering to meaning I render some content to a YUV12 renderbuffer and scan it out
<i509VCB>
*NV12
<i509VCB>
draw maybe more specifically
<i509VCB>
(I might be mangling terms here)
<emersion>
oh
<emersion>
you need your own shader stuff for this
<i509VCB>
although with Vulkan wouldn't a ycbcr sampler + a framebuffer to the view of the NV12 image work fine and not really need all my own shader stuff? Or did I not read part of the Vulkan spec?
<emersion>
i think i'm not understanding correctly
<emersion>
a vulkan ycbcr sampler can only sample/texture from a YUV buffer right?
<emersion>
what are you trying to do exactly? the above sounds like you're trying to paint an image onto a YUV buffer and then scan it out with KMS
<any1>
I think the question might be whether there is hw that can scan out ycbcr
<any1>
As side note, it would actually be beneficial to be able to have screencopy do the rgb->nv12 conversion because that allows for skipping the extra conversion step to nv12 for vaapi h264 encoding
<tleydxdy>
but that means every compositor would need to have a shader for that right?
<emersion>
dottedmag: ah, i'll fix that
<any1>
tleydxdy: Not really, no. Just the ones who implement the conversion
<tleydxdy>
then the client would still need to have it's own conversion step
<tleydxdy>
in case the compositor doesn't
<any1>
yes, but, those who implement it have get faster/less power hungry screencasting. :)
<any1>
Many of the optimisations that we do only work when the stars align. ;)
<emersion>
i am not convinced this would really help
<tleydxdy>
how much power would it really save?
<any1>
dunno, haven't tested it.
<tleydxdy>
it basically just saves a buffer copy on the gpu right?
<any1>
yes
fmuellner has joined #wayland
<any1>
which doesn't really have much of an impact on a modern laptop or desktop
<tleydxdy>
in that case I think it would be much more useful if vulkan/opengl can just let you copy to yuv buffers like any other
<any1>
However, on a raspberry pi, it makes *a lot* of difference
<tleydxdy>
and it does it's own conversion in the best way
<tleydxdy>
it already converts different rgb formats right?
<i509VCB>
The rpi4 doesn't even support VK_KHR_ycbcr_sampler_conversion I believe, so I'm not sure how you'd be rendering to NV12
<any1>
shaders
<any1>
Eh, well, it's interleaved, so maybe not
<any1>
Err, no, it's multiplanar
<any1>
So, you would need to do one render pass per plane
<tleydxdy>
what happens if I create a image using VK_KHR_sampler_ycbcr_conversion and try to vkCmdCopyImage into it?
Leopold has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
<daniels>
'sampling' is for input through textures, not output through render targets
ybogdano has joined #wayland
<tleydxdy>
so the vkImage created would be read-only?
manuel_ has quit [Ping timeout: 480 seconds]
<daniels>
yeah
<tleydxdy>
sad
kts has quit [Ping timeout: 480 seconds]
fmuellner has joined #wayland
MajorBiscuit has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
luc4 has joined #wayland
carbonfiber has quit [Quit: Connection closed for inactivity]
MajorBiscuit has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #wayland
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
cool110 has quit [Remote host closed the connection]
dcz_ has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
fmuellner has joined #wayland
rv1sr has quit []
fmuellner has quit []
fmuellner has joined #wayland
rv1sr has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
<yshui`>
is adding roles to surfaces always double-buffered? the specification says the subsurface role is buffered, but doesn't seem to specify if others are too.
rv1sr has quit []
danvet has quit [Ping timeout: 480 seconds]
<vyivel>
roles aren't double-buffered
<vyivel>
what the spec says is that the surface becoming the parent's child is double-buffered
ybogdano has quit [Ping timeout: 480 seconds]
<vyivel>
but the role of wl_subsurrace is added immediately