ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<MrCooper>
Dami_Lu: it's possible if the child window uses e.g. xdg_popup
kts has quit [Ping timeout: 480 seconds]
<Dami_Lu>
MrCooper: Thank you, if it is just a widget child window; is there any way to set the position relative to the parent window?
<Dami_Lu>
Or whether it is necessary to supplement the protocol for such scenarios
<MrCooper>
only child windows with special roles such as xdg_popup or wl_subsurface can be positioned relative to their parent
iomari891 has quit [Ping timeout: 480 seconds]
<Dami_Lu>
Yes, got it ; Is it necessary to add corresponding protocols for other child Windows, so that the child window can set the position relative to the parent window
iomari891 has joined #wayland
dottedmag has joined #wayland
kts_ has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
anarsoul has quit [Read error: No route to host]
anarsoul has joined #wayland
privacy has joined #wayland
mvlad has joined #wayland
<pq>
Dami_Lu, the default answer is "no". There would need to be a good justification why, and a good plan for how, given that the client cannot know what the area around the parent window contains or maybe the parent is at the edge of the screen.
<pq>
this is why xdg_popup uses the positioner interface - you cannot simply set a position, it needs to be negotiated, because your idea of a position might go off-screen etc.
<pq>
wl_subsurface does not use positioner, because a sub-surface is not a child window; it's an integral part of the same window as the parent surface.
<Dami_Lu>
pq: Thank you for your reply. Currently, it is a necessary requirement to set the position of the child window in the user scenario. Can we create another issue to track this issue or reopen https://gitlab.freedesktop.org/wayland/wayland/- /issues/183
<emersion>
Dami_Lu: can you elaborate what the "user scenario" is?
<pq>
Dami_Lu, please do not re-open that one.
<Dami_Lu>
pq: I personally think a good plan is necessary :-)
<emersion>
unless the "user scenario" is a new thing that hasn't been brought up before, the answer is unlikely to change, fwiw
<emersion>
not to discourage you -- but we really need more context here
<Dami_Lu>
emersion: Thank you for your reply; I am not sure if there is a problem with my description. In terms of user scenarios, my user feedback is that under x11, his program can set the position of the sub-window, and can also adjust or move the sub-window arbitrarily; but in This is not possible under wayland
<emersion>
the problem is that it's too vague
<emersion>
we would like to know exactly _why_ you think it's necessary to set the position
<emersion>
what is the exact app? what is it used for?
<emersion>
what does the window that needs positioning?
<emersion>
or, are you working on a toolkit kind of thing, and your "user" is a developer?
<emersion>
right, but this is not about a concrete use-case
<pq>
Dami_Lu, we generally do not accept additions to Wayland simply because something was possible on X11, or that the behavior is defined in a toolkit's API.
<pq>
There needs to be a specific use case: what is the original goal of the application's end user, when the application is deciding to place a certain window in a certain position.
<pq>
Migrating an application from X11 to Wayland can include redesigning some parts of the application. It's not just a replacement of an API with another.
<pq>
you think you need to position that window, but what for?
<pq>
Dami_Lu, that is what you would need to explain.
luyn_ has joined #wayland
kts has joined #wayland
luyn has quit [Read error: Connection reset by peer]
<Dami_Lu>
The actual scenario is this: there are two screens, the second screen is used as an extension screen. When the child window is opened it needs to be moved to the second screen for display
<pq>
but not as fullscreen?
<pq>
what is an "extension screen"?
<pq>
is this not a desktop?
<pq>
Who defines which screen is the "extension screen"?
luyn has joined #wayland
<emersion>
is this an embedded use-case?
luyn_ has quit [Ping timeout: 480 seconds]
<Dami_Lu>
The sub-window is not full screen, or the Plasma6 desktop system uses two screens. want to set the sub-window on the second screen.
<Dami_Lu>
It's not an embedded system, it's just a desktop system.
CME has joined #wayland
davidre has joined #wayland
<davidre>
If you as a user want a window to always open on a specific screen you can create a window rule for it
<davidre>
(in the context that this is a plasma system)
iomari892 has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
<Dami_Lu>
Thanks. Not a special screen, just a second screen.
<Dami_Lu>
Regarding creating window rules, can you give me an overview.
<davidre>
right click on titlebar, more actions, configure special window settings
<davidre>
there you can select properties on which to match a window and apply actions
<Dami_Lu>
Is there an API that can be set? If I don’t use kwin, other compositor probably won’t support it either;
<Dami_Lu>
Moreover, if the second screen is set as the main screen and the first screen becomes the secondary screen, the sub-window needs to be displayed on the first screen;
dottedmag has left #wayland [#wayland]
iomari892 has quit [Ping timeout: 480 seconds]
<davidre>
People keep asking but you dont answer
<davidre>
Why does the window need to do that
<davidre>
no its meant for end user configuratin
<davidre>
* no rule its meant
<pq>
Dami_Lu, why does the application know better that the end user or the window system where the child window should be placed? Or is it trying to do it somehow on the end user's behalf? Is it something all the application's users always want?
<pq>
*know better than the end user
<pq>
How does the application know which monitor the window should appear on? Why specifically there?
<pq>
The concept of "main screen" or "primary output" is not universal across desktops, is it?
<pq>
Dami_Lu, I'm asking, because I want to help you to make your case better. This is not going to get resolved in IRC, but I hope convey what you should explain in your filed issue.
mclasen has joined #wayland
dottedmag has joined #wayland
<Dami_Lu>
pq davidre: Thank you very much for your reply. Maybe my statement is not particularly accurate; the real user requirement of the user application is that the sub-window needs to be displayed on the second screen (not the main screen)
<davidre>
But why does it need to do that?
<Dami_Lu>
This is the effect the user wants :-C
<pq>
why does the user want that?
<pq>
so, it is the end user who wants that, and not the application, right?
CME has quit [Ping timeout: 480 seconds]
<pq>
why can't the end user just move the window to where they want it, and have the application remember the layout by using a protocol extension meant for recalling application layouts?
<Dami_Lu>
Yes , The effect my clients want; They think that the child window should also be set in position
<pq>
How do "your clients" know what position to set?=
<pq>
Your clients do not know what else is on screen, and they cannot tell different screens apart, can they? So how could your clients know what position is good?
<pq>
Your clients cannot even address screens by x,y position at all.
CME has joined #wayland
<emersion>
pq, core protocol has x/y sadly
<emersion>
(wlroots always leaves these zero)
<pq>
emersion, I know. But you cannot use it, nor trust it, right?
<emersion>
right
<Dami_Lu>
pq: This app supports x11 and wayland. The end user believes that this effect can be achieved in x11, so this function should also be implemented in wayland. I also understand the reason, but I'm sorry for having such thoughts
<emersion>
Dami_Lu: are you a Qt developer?
<pq>
Dami_Lu, in the beginning, I explained that just because something is possible on X11, is not at all a justification to support the same *mechanism* on Wayland.
<Dami_Lu>
Yes
<Dami_Lu>
pq: Yes, I understand, that's why I asked if there are other ways to move the child window.
<pq>
Dami_Lu, ok, why?
<pq>
Dami_Lu, so you understand the difference between a user and an application? The end user is a person, and application is a program. How does the application know where the window should be put?
<pq>
*do you
<emersion>
it seems like you don't have the information we ask Dami_Lu, so maybe forward the questions we asked to your user
<emersion>
(by that i mean to the person asking you to implement the feature)
<pq>
I do not recall any ways to move a window.
mohit81582263 has quit [Quit: mohit81582263]
mohit81582263 has joined #wayland
<pq>
Fundamentally the inability for applications to move their windows is intentional. There can be use cases where something more is needed, and it has traditionally been solved by placing a window at x,y. However, Wayland does not have such coordinate system, so the *original* problem needs to be solved somehow else.
<Dami_Lu>
Although the mechanism is different from x11 under wayland; Under x11 there is the concept of global coordinates, users think that since applications can sub-set the default window position. But it doesn’t work under wayland; (btw, users don’t know x11 and wayland) ;
<pq>
A big question is how did one come up with the right x,y in the first place. What does it depend on?
<Dami_Lu>
But it is difficult to explain to users the differences in the same application under different protocol frameworks.
fmuellner has joined #wayland
<pq>
That's true. Sorry to push that pain downstream.
<pq>
It is unavoidable that when an API has been designed for X11, very likely it will have parts that just cannot be translated to Wayland. Both the API and the applications using the API need to be partially re-designed. This is expected.
<pq>
The alternative is to stick to X11 via Xwayland.
<Dami_Lu>
All applications have been adapted to wayland, and xwayland will basically not be considered. :-C
<pq>
really?
<pq>
if apps have been adapted, why are they expecting that set window position x,y works?
<Dami_Lu>
Before I posted this question, we have already discussed it and will not consider xwayland.
<Dami_Lu>
I would like to ask again if Wayland will not consider the function of setting the position of the child window relative to the parent window.
<pq>
Dami_Lu, I would say "no" if you cannot give any more justification than you did here.
<Dami_Lu>
ok
<pq>
All I understood so far is: Qt API has a function to set window position by x,y, and we want it to work. That's not enough, IMO.
<pq>
not the *general* desktop
<pq>
it might be fine in special environments
<Dami_Lu>
yes , set_positon
<Dami_Lu>
I have also read the logic in qtwayland in detail.
<pq>
setting window position, and putting a window on a specific monitor are two different goals that have very little common
<Dami_Lu>
x11 is first achieved by setting the position of the sub-window; in wayland, whether it is setting the position of the sub-window or setting it to be displayed on the second screen (non-main screen), we just try to achieve the same effect.
<pq>
Dami_Lu, yes, the effect is important, and the mechanism less so. Wayland goes even further and asks "how does one determine the expected effect?" and continues with "what does the compositor need to know, to be able to choose the correct effect in all reasonable/imaginable situations?"
glennk has quit [Ping timeout: 480 seconds]
<Dami_Lu>
:-)
<pq>
that's why we are such a pain with all the questions about the use cases :-)
<Dami_Lu>
me toooooo
<JEEB>
yeh, so in general just "explain the use case" kind of stuff, so it can be checked how limited in scope it would be etc
neniagh has quit [Remote host closed the connection]
neniagh has joined #wayland
garnacho has quit [Quit: garnacho]
garnacho has joined #wayland
feaneron has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
Dami_Lu has quit [Remote host closed the connection]
luyn has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
MrCooper has joined #wayland
Company has joined #wayland
Brainium has joined #wayland
<Company>
a question that came up in GTK while working on black-single-pixel-backgrounds to ease direct scanout:
<Company>
is sRGB black the same as other colorspace blacks?
<daniels>
pq and someone else were debating the concept of black a week or two ago
<pq>
Company, depends on your definitions of each.
iomari891 has joined #wayland
<emersion>
my mood when dealing with X11 DnD is darker than black
<pq>
emersion, you must be using limited quantization range then.
<Company>
pq: the thing that the compositor accepts as the kms background - that's more or less the definition I'm after
<pq>
Company, are you asking, what color value matches the KMS default-black of CRTC areas not covered with any KMS plane?
<colinmarc>
pq: I got this joke!
<daniels>
emersion: desolée
<Company>
pq: GTK wants to detect the case of a video with black bars, so that it can create 2 surfaces - one with a black pixel and one with the video
<emersion>
aha
<Company>
so that the compositor can use 1 plane only
<Company>
and in a color-managed world, what does that mean for the black pixel?
<pq>
Company, umm... you mean, a video that already contains black bars, GTK would detect those, clip them away, and the replicate them with another wl_surface with a black single-pixel?
<Company>
no
<Company>
a video with a different aspect ratio
<pq>
oh
<Company>
say a 16:9 video on a 21:9 output
<pq>
so my first guess was right?
<Company>
yeah, ultimately it's about the KMS background color
<pq>
right
<Company>
though there's the compositor inbetween
<Company>
and my question was also about how it should work in a perfet world, not how it does work today :)
<pq>
I kind of suspect that the default-black KMS background color is simply (0,0,0), and what that means depends on what "Colorspace" one chooses. Optionally converted to YCbCr equivalent.
<pq>
hmm...
iomari892 has joined #wayland
<mclasen>
Company: I think this is just making things too complicated. black is black, as far as I'm concerned, for the purposes of this optimization
iomari891 has quit [Read error: Connection reset by peer]
<Company>
mclasen: if the compositor doesn't agree, that doesn't help you
<Company>
mclasen: also, do you need to set a colorspace (which one?) on the black pixel?
<pq>
I cannot think of why the simple RGB(0,0,0) would not be it, regardless of color space.
<mclasen>
if I need to do that, I'd rather do without out that optimization
<mclasen>
but it is a good reminder that the single-pixel protocol will need some wording around color representation when those things land
<Company>
yeah, it'd make things trickier, because then the background color would depend on the video's colorspace
<pq>
I can theoretically imagine mapping sRGB black to dark rather zero light on a display that has very dark blacks, but...
<pq>
Company, because you want the video black, which might occasionally appear, to match the borders black?
<emersion>
single-pixel will not need anything special
<emersion>
single-pixel is equivalent to a wl_shm or DMA-BUF 1×1 buffer
<pq>
why not just make borders the darkest black you can / bother, why match video black?
<Company>
it currently is just #000000
<mclasen>
emersion: at the very least, it should tell us how the 32bit range gets mapped to whatever actual color depth we have
<Company>
my question was if that's always gonna get the effect I want
<emersion>
mclasen: nothing special there
<zamundaaa[m]>
Company: I wrote an implementation a few weeks or so back, but it was stalled because QtWaylandScanner made some dumb assumptions about the protocol name or something, so it didn't compile
<pq>
Company, which effect do you want? To match KMS default-black, or to match video content black?
<emersion>
same as DRM_FORMAT_XRGB16161616 getting to DRM_FORMAT_XRGB8888
<zamundaaa[m]>
I think that's since been resolved, so I'll try again
<Company>
pq: to get single-plane direct scanout
<pq>
Company, ok, so you want to match KMS default-black, and not video content black. Ok. Hmm...
* Company
no idea how KMS default-black is defined - does that depend on HDR settings?
<pq>
Company, I would say, use RGB(0, 0, 0), and tag that surface with the output's image description.
<zamundaaa[m]>
Company: oh, now I remember why it didn't compile. It has a temporary variable for a resource called "r", and the protocol has the variable name "r" for the red component
<pq>
Company, it's not defined. That's the point.
<pq>
Company, I suspect KMS drivers just pull out zeros out of a hat as "black", and then it's sent to a sink which will interpret it according to infoframe data.
<Company>
zamundaaa[m]: so I'll assume it's gonna land in kwin and I don't need to add a special case to gtk for compositors not supporting it (which I really don't want)
<pq>
RGB zeros, I mean
<daniels>
Company: fwiw gst uses a (0,0,0,1) spb to letter/pillarbox, so just do that and you'll at least match gst behaviour
<Company>
pq: that was my assumption, too - but that's all existing code that doesn't concern itself with color management
<zamundaaa[m]>
Company: you'll have to special case for a while, because flatpaks are a thing
<pq>
I recommend plain (0,0,0) RGB as well, either untagged, or tagged with the output image description at most.
<zamundaaa[m]>
Probably for a few years at least to be safe
<pq>
Company, I don't think KMS drivers ever will nor should care more than that.
<mclasen>
emersion: so it only uses 16 bits then ?
<Company>
pq: I'm talking to compoisitors though, not KMS
<mclasen>
emersion: just put it in the protocol, so we don't have to guess...
<emersion>
mclasen: you'd convert from 32-bit to 8-bit, the same way one would convert 16-bit to 8-bit
<pq>
Company, I know, but compositors match KMS "definition" when off-loading to KMS.
<emersion>
mceier: no, because that depends on the color encoding and stuff
<emersion>
and has nothing to do with the protocol
<Company>
zamundaaa[m]: I can just not support it for kwin 6.0 and fall back to regular drawing - that's fine with me, people can upgrade their kde if they want optimized rendering
<emersion>
like, one has the same question when converting between wl_shm or DMA-BUF formats
<pq>
mclasen, the full 32-bit range maps to (0.0, 1.0) range, with a divisor of uint32_max
<mclasen>
"just use 32bit values for the primaries, we won't tell you how we use them and we won't tell you what other factors are involved"
<mclasen>
great way to make a protocol :)
<pq>
just like 8-bit full range maps with a divisor of uint8_max
<mclasen>
at least it leaves room for interpretation, so it is future-safe
<emersion>
protocols are not hand-holding explaining basics every time
<emersion>
(mceier: sorry, wrong mention)
<Company>
people are tainted from back in the days where 16bit values were interpreted as 8bit values sometimes instead of mapping the whole space to [0..1]
<pq>
mclasen has a point, the spec should be more clear.
<pq>
I do not appreciate mclasen's snarkyness, though.
<mclasen>
my apologies. colors do that to me
<Company>
it'd be VK_FORMAT_R32G32B32A32_UNORM - if that existed
<pq>
yes, they tend to do that to everyone
<Company>
or the equivalent dmabuf format - which also doesn't exist
<mceier>
emersion: no problem.
<jadahl>
pq: I appreciate your color comedy though
<pq>
:>
<emersion>
describing how to map r/g/b to [0..1] makes sense to me
iomari891 has joined #wayland
<pq>
Company, let's make that untagged RGB(0,0,0) for the black bars. Compositors have more freedom to map untagged content, so it could more easily map to any KMS default-black there might be.
<pq>
emersion, yes, that.
<Company>
pq: that might turn out problematic for GTK, because once we're color-managed, we won't do untagged anymore
<pq>
:-p
<Company>
and we especially won't have a way to set that color
<mclasen>
I don't think thats true? the code I wrote will keep working just the same, and it will keep using #00000
<Company>
Are you sure?
<Company>
you could certainly special case it somehow, but you run into the same issue: What GdkColor do you accept as "untagged kms black"?
<Company>
because you'll have to set that in the css
<Company>
and "#000000" or "black" are sRGB colors
<mclasen>
Company: yes, it will get more complicated to find the black in the node tree, but the black we pass to the compositor has nothing to do with it
iomari891 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
leon-anavi has quit [Quit: Leaving]
<Company>
mclasen: it's ultimately the same question though - somebody has to figure out what is "kms black" - either the compositor does it for us or we send a special "kms black" pixel
<Company>
and then we need to figure out the mapping
mvlad has quit [Remote host closed the connection]
<pq>
Company, I think compositors could also help you by not requiring a too exact match between a single-pixel (0,0,0) buffer and KMS default-black.
<Company>
ultimately, that question came up because we were wondering if we need to create >1 single pixel buffer with different values for different colorspaces
dcompoze has joined #wayland
<Company>
and also if the single-pixel surface colorspace needs to match the video surface's colorspace
<pq>
but if this becomes a real problem, there could be a "black pixel" protocol extension that is explicit about not being too picky about what is black
<zamundaaa[m]>
pq: that depends a lot on what the difference between the values is
<Company>
this is gonna need some best practices, so apps and compositors agree on what they do
<pq>
Company, since your goal is not to match video content black, I don't think the video content image description is important.
<Company>
and then everything's fine
<zamundaaa[m]>
If KMS black is too vaguely defined, arguably a compositor can't safely do direct scanout with buffers that don't exactly fill the whole screen
<zamundaaa[m]>
Because it might look noticeably different vs what it does in compositing
<pq>
ah, the seamless fallback thing
dcompoze has quit []
<Company>
zamundaaa[m]: then somebody needs to define it so that doesn't happen
<zamundaaa[m]>
looks like it, yeah
<mclasen>
or we ask for that kms api to set the color
<Company>
I know there were patches to set the bgcolor in kms
<Company>
but nobody needed them
<pq>
KMS kinda has a definition, more or less, assuming people understand "black" as RGB(0,0,0)
<Company>
do DisplayPort and HDMI require correctly sized buffers?
* Company
no idea about those layers of the stack
<pq>
KMS composition stage gets RGB(0,0,0) as input for default-black, and what happens then is up to userspace to a) set CRTC color props, and b) set connector props.
<zamundaaa[m]>
Company: DisplayPort and HDMI don't deal with buffers
<pq>
Company, DisplayPort and HDMI are streams. Video mode says how many pixels they carry per line and per frame.
<zamundaaa[m]>
They just get a data stream from the scanout hardware, which can do ~whatever
<pq>
display adapters create those streams in real-time from memory or other sources
<Company>
right, so the scnout hardware is the one that adds the black bars iiuc
Arsen has joined #wayland
<zamundaaa[m]>
yes
<Company>
then we can technically define whatever and use it, it's just that so far the term "black" was working well enough for everyone
<pq>
yeah, zeros
dcompoze has joined #wayland
dcompoze has quit []
<zamundaaa[m]>
Does the background color interact with the CRTC color management properties?
<pq>
zamundaaa[m], yes, I think it should.
<zamundaaa[m]>
That's what I think too, but I have the feeling that at least not all drivers implement it that way
<bwidawsk>
Xanazf: is that native wayland, or through xwayland?
swick[m] has joined #wayland
<swick[m]>
Company: fwiw, I think this isn't hard. the monitor interprets 0,0,0 as black in the color space it is in. black of another color space might not map to black in that color space. if you want the black in your content to match the output black, tag the content with the image description of the output.
<swick[m]>
as far as KMS is concerned, black must be 0,0,0 on the cable, so whatever is black in the monitor color space
<Company>
dunno - the thing I want to guard agaisnt is some compositor going "oh in this colorspace the black pixel needs to be 1,1,1 so I need an extra plane" and then direct scanout of the video stops working
<Company>
and the same problem exists on the GTK level, where the application/theme needs to set a color for the black bar
<swick[m]>
I mean, yes, black in some color spaces is different from black in others
<swick[m]>
so an untagged surface gets you ~sRGB blacks which can be brighter than whatever the display can do
<swick[m]>
so this can happen
<swick[m]>
and it makes sense. if you always map any content black to the display black, independent of how much dynamic range there is, then you're messing up the constrast
<Company>
what I want in the end is direct scanout working and there being black bars on the side that people watching the video agree are black bars
ahartmetz has quit [Quit: Konversation terminated!]
<Company>
and the question is how to get there
<swick[m]>
yes, so just tag the surface which uses the single pixel buffer with the output image description
<Company>
oof
<Company>
that's tricky because the black currently comes from CSS
<Company>
and the output image description comes out of GStreamer
<Company>
or more exact: the video file
<swick[m]>
no, the output image description comes from wayland
<swick[m]>
and for the css part, that's what color space annotations are for
<swick[m]>
you'll need them anyway for sRGB, PQ, ...
<Company>
yeah, but the CSS comes from libadwaita, and that comes before Wayland
<swick[m]>
well, you can have an "output image description" color space
<swick[m]>
in css
<Company>
not sure if I can - I mean, I can add an extension to CSS and define a color named "kms-black" or so
<Company>
that's tricky though once you have 2 monitors
<swick[m]>
nah, you only need one more color space option for defining a color: sRGB(0,1,2), PQ(5,6,7), output(10,11,12)
<swick[m]>
oh I see, it depends on the monitor and that can change...
<swick[m]>
that's the complication you see
<Company>
yeah
<Company>
it also makes the rendering depend on the output
<Company>
ie when rendering into a PNG vs a monitor
<swick[m]>
indeed, that's bad
<swick[m]>
the other solution is to use e.g. black with PQ which will probably always be darker than whatever anything can actually do and then hope compositors figure that out :/
<Xanazf>
bwidawsk: native wayland with ozone-platform=wayland flag
<Company>
I want to play back a video, which comes with its own color space, or rather cicp settings
<Company>
then I ask the compositor to please configure the hardware/driver/whatever to use that
<Company>
and then direct scanout starts working?
<swick[m]>
if the hardware can do it, yes, that's the idea
<Company>
is cicp just those 3 enum values?
<Company>
transfer function, code points and matrix?
<swick[m]>
there are more
<swick[m]>
there is a bit for full vs limited, chroma subsampling location, and I think one more thing that I forgot
<Company>
why is that in cicp - that goes into the pixel format description already
<Company>
dangit, people
<Company>
okay, full vs limited is colorspace, but chroma subsampling is pixelformat
<swick[m]>
no, it's not
<swick[m]>
so, the location isn't
<Company>
I would very much say it is
<Company>
there's also the fun stuff with linear vs nearest interpolation between the subsamples
<Company>
and only half the gpus doing linear iirc
<swick[m]>
the pixel format only gives you the subsampling factors, not where to sample from
<Company>
well, you can't convert between pixel formats without that info
<swick[m]>
correct, but that info isn't present in the pixel formats
<Company>
and that's why I'm complaining
<Company>
because really, it should go there
lsd|2 has joined #wayland
<swick[m]>
you also need the matrix for that, and limited vs full range etc
<Company>
if you want to convert from 4:2:0 to 4:4:4 you don't
<swick[m]>
true, but that's one subset
<swick[m]>
pixel formats are just inherently not always convertible between all other pixel formats
<Company>
the fact that dmabufs encode YUV vs RGB as different pixelformats is a bug in dmabufs
<Company>
just like GTK with premultiplied
<swick[m]>
the premult stuff in pixel formats is just insane
<swick[m]>
but I don't see your point
<Company>
my point is about the data types to represent this stuff
<swick[m]>
you also can't convert between two RGB pixel formats if they have different bit depth, or if one has alpha and the other doesn't, ...
<Company>
is pixel format different from color space?
<swick[m]>
yes
<Company>
or are those just 2 properties of the image description
<swick[m]>
I can't follow
<swick[m]>
the pixel format describes where in memory some channels are
<Company>
but that description is useless unless you know what those channels mean
<swick[m]>
correct
<Company>
so the question is if it ever makes sense to pass that format without all the other stuff
<swick[m]>
if you implicitly have "all the other stuff" then sure
<swick[m]>
otherwise, no
<Company>
that's an API design question ofc
<Company>
ie do I have GdkColorState.format or do I have GdkColorState and format as different properties of my Image type
<Company>
currently GTK has a generic conversion routine that converts between formats
<Company>
well, it covnerts to RGBA8 or RGBA32F just so we can upload everything to the GPU
<Company>
but that function will need to take chroma subsampling information
<Company>
the question then becomes if chroma subsampling info should be different from the ColorState, so that we can pass it around there without needing a full ColorState object