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
fmuellner has quit [Ping timeout: 480 seconds]
darkskyze has joined #wayland
daz has joined #wayland
darkskyze has quit []
columbarius has joined #wayland
d42 has quit [Ping timeout: 480 seconds]
co1umbarius has quit [Ping timeout: 480 seconds]
sav10 has quit []
cool110 has joined #wayland
cool110_ has quit [Remote host closed the connection]
sav10 has joined #wayland
sav10 has quit [Remote host closed the connection]
Leopold_ has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
kts has joined #wayland
kts has quit []
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #wayland
kts has joined #wayland
floof58 has quit [Read error: No route to host]
floof58 has joined #wayland
molinari has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
hardening has joined #wayland
kts has quit [Quit: Leaving]
kts has joined #wayland
molinari has joined #wayland
agd5f has joined #wayland
kts has quit [Quit: Leaving]
agd5f_ has quit [Ping timeout: 480 seconds]
julio7359 has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
rasterman has joined #wayland
pochu has joined #wayland
manuel1985 has joined #wayland
fmuellner has joined #wayland
hardening has quit [Ping timeout: 480 seconds]
<jadahl>
Vanfanel: i would try to make it a decision that involves the weston_desktop_surface directly, and checks if it's logically fullscreen
<pq>
Vanfanel, using a weston_surface or weston_view pointer in weston_seat *would* work with multiple seats. Only the single serial wouldn't.
<jadahl>
pq: I think the intention was to grant it without a serial if the xdg_toplevel has the fullscreen state
<pq>
Vanfanel, there is no such thing as wl_view.
<pq>
Vanfanel, no, input.c code cannot know which view is wich, or if it is "fullscreen". input.c also cannot call into libweston-desktop.
<pq>
jadahl, different serial. This is not the protocol serial, but an internal serial to replace a boolean flag that can be forgotten to be unset.
<pq>
and it's also not the internal serial already used in the code
<pq>
Vanfanel, because input.c *must not* know about concepts like desktop-surface or fullscreen, you have to invent the concept of "can be pointer-confined" which will be driven by the shell plugin which actually know what "active", "fullscreen", or "desktop" mean.
<pq>
I believe the existing code is taking a shortcut, and may not even allow the shell plugin to participate in the decision of whether confinement is allowed. That is an architectural flaw.
Leopold has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
<pq>
now that decisions on confiment actually need concepts that only exist inside the shell plugin, the old design just doesn't work anymore.
<pq>
If the hack of faking in the shell plugin that the view was clicked does not work, then the interactions between the shell plugin and libweston core (input.c) needs to be re-designed.
<pq>
btw. I don't recall clearly, but it might be that there is another weston_view created by the shell from the beginning. Are you sure you were manipulating the right view?
Leopold__ has joined #wayland
<pq>
Personally I cannot afford to participate in that re-design this year.
Leopold has quit [Ping timeout: 480 seconds]
dcz has joined #wayland
hardening has joined #wayland
<Vanfanel>
pq: Let's go back to the "view has been clicked" hack then, yes. I am not sure I was manipulating the right view, no. I understand it depends on the serial: the right view is the view with the right "serial". The only *serial* field I see in weston_view is click_to_activate_serial. Faking a click on a view would mean setting it's click_to_activate_serial to the surface->compositor->activate_serial,
<Vanfanel>
right?
<Vanfanel>
I mean: faking a click on a view would be doing: view->click_to_activate_serial = surface->compositor->activate_serial, right?
<pq>
I guess so. I don't know. I'm just asking if you doing that *setting* on the right view in the shell?
<pq>
have you added prints to see how the serials change and what input.c sees?
<Vanfanel>
pq: I am going to do that, yes. Good idea.
<pq>
:-)
<pq>
printing the pointer to the weston_view might help too
floof58 is now known as Guest2868
floof58 has joined #wayland
Guest2868 has quit [Read error: Connection reset by peer]
alarumbe has quit [Remote host closed the connection]
<ukiran>
Could you please help to confirm whether the design is frozen ?
<kennylevinsen>
no open merge requets is "frozen", but a merge request with two years worth of efforts and discussion is unlikely to be redesigned from scratch at random. :)
<pq>
ukiran, no, it's not frozen.
<pq>
ukiran, I have planned changes to do on it, too.
alarumbe has joined #wayland
alarumbe has quit [Remote host closed the connection]
<pq>
ukiran, if you are intending to ship an implementation of it, please rename *every* interface downstream so that they won't conflict with the upstream version once it lands in wayland-protocols.
maxzor has quit [Ping timeout: 480 seconds]
alarumbe has joined #wayland
alarumbe has quit []
<ukiran>
After i go through the details of the documentation, i have few doubts which needs the clarification
<ukiran>
As i know, the compositor is the decision maker of the blending policy in weston
<ukiran>
And it is must that the application should pass the colorspace information to compositor inorder to make use of color management protocol. am i correct ?
<pq>
ukiran, yes.
<ukiran>
What if i have 2 applications. one is sending the buffer with SRGB CS and another with BT2020/AdobeRGB and my monitor is supporting BT2020 CS.
<ukiran>
In this case what is the blending policy applied in the compositor ?
<pq>
ukiran, both source contents are converted into a common blending space, composited, and then converted to the monitor expected space.
<ukiran>
Common blending space means XYZ colrospace ?
<pq>
no
<pq>
the common blending space is something the compositor implementation decides
<pq>
Weston is going to use the monitor color space except with optical values instead of electrical values.
<pq>
or whatever colorspace the monitor signalling is going to use
<ukiran>
you mean to say, based on the input colorspaces, compositor will take the more wide gamut CS and if that supported by the monitor, then the lower CS(SRGB) converted to BT2020 and finally sends the buffers to the display for blending ?
<pq>
The choice of the blending space will not depend on the input. It depends only on the properties of the output (monitor).
<pq>
Anything that comes in gets converted appropriately to the blending space and eventually to the output space.
<ukiran>
Would you please elaborate on the properties of the output ? you mean to say chromaticities read as part of the EDID info ?
<pq>
It's all the colorimetric characteristics we can get: it might be EDID color parameters, it may contain HDR metadata, it might be an ICC profile.
<pq>
It may also require end-user adjustable settings, given how unreliable and unusable EDID data is.
<ukiran>
unreliable EDID means the data without VCGT tag ?
<pq>
No. I mean the EDID says primaries are this, and then they are not. Or that white point is this, but it pratically never is.
<pq>
or it claims the display support HDR, but fails to provide *any* HDR parameters.
<pq>
VCGT tag is irrelevant. It does not describe the monitor at all, it is just an extra set of curves that the end user wants applied for whatever reason.
<pq>
VCGT is an ICC file tag, it's not in EDID.
<ukiran>
this flag will be part of some profile file ?
<pq>
what flag?
<ukiran>
sorry VCGT tag
<pq>
Yes, VCGT is a tag that may be present inside an ICC profile file.
<ukiran>
i think this should be used for the calibration purpose
<pq>
Yes, it is calibration. If VCGT exists, it must be used, otherwise the ICC profile is not valid.
<ukiran>
yeah.. i get it
<ukiran>
for example, Keep the HDR aside, this question is related to the color space conversion. app1-> SRGB, app2->BT2020 and monitor support BT2020.. In this case, what are the blending space and output space ?
<ukiran>
app1 buffer is RGB color format and app2 buffer is YCbCr color format..
<JEEB>
blending space is whatever compositor chooses, f.ex. the windows compositor uses 16bit floaty scRGB
<JEEB>
output is what the compositor is configured towards with regards to a given screen I.presume
<JEEB>
compositors may or may not have fast paths if input and output match exactly.and no adjustme.ts or scaling need to.be done
<pq>
correct
<JEEB>
geez, touch keyboards and typing
<pq>
heh
<ukiran>
haha
<ukiran>
pq, i will go through the referred link
alarumbe has joined #wayland
<pq>
ukiran, I mean only the one comment it links to, with the diagrams. Not the whole page.
<pq>
ukiran, if Weston drives a monitor with BT.2020 electrical signaling, it would use BT.2020 RGB color space in optical half-float encoding for the blending.
<ukiran>
Electrical signalling meaning OETF ?
<pq>
electrical as the 'E' in OETF and EOTF, yes.
<pq>
and 'O' for optical
<ukiran>
Yes
DodoGTA has quit [Quit: DodoGTA]
<ukiran>
as per my study, i see that the stps involved conversion between the colorspaces mentioned in the links
<pq>
The blending space in Weston is essentially the output color space with the inverse output EOTF applied on top.
DodoGTA has joined #wayland
<ukiran>
Ex: Scenario is to convert the YCbCr Bt.601 color space data into BT.709
<ukiran>
Steps involved in doing this operation are
<ukiran>
1. Conversion between color models i.e.) non-linear YCbCr BT.601 data to non-linear Bt.601 RGB. This is calculated using Sparse Matrix Multiplication.
<ukiran>
2. Conversion from non-linear RGB to Linear RGB. We use transfer function for this i.e.) EOTF-1 (EOTF inverse) function
<ukiran>
3. Conversion from BT.601 RGB to BT.709 RGB primaries
<ukiran>
4. Conversion from Linear RGB representation using target primaries to a non-linear R'G'B' representation i.e.) OETF
<ukiran>
Conversion from non-linear R'G'B' to Y'CbCr Color model using matrix multiplication.
<ukiran>
This is based on my understanding, i noted it.
<pq>
Roughly, almost at least,yeah.
<ukiran>
Is Blending to output CS is done through KMS right.. In this case, you are doing it with CRTC or Plane ?
<ukiran>
or is this is yet to implement ?
<pq>
Currently Weston does it with GL ES 3 shaders, but it is intended to be done in KMS on the CRTC.
maxzor has joined #wayland
<pq>
...when possible.
<ukiran>
okay
<ukiran>
What if the case where one client app fills the colospace information and another did not.. How compositor will take the decision in this case during blending ?
<pq>
The compositor will assume something, usually sRGB colorimetry, if it's YUV then BT.601 matrix coefficients.
<ukiran>
the default is SRGB for RGB format and BT.601 for YUV format.
<pq>
no
<pq>
The default is sRGB.
<ukiran>
okay
<ukiran>
Does this alter the user expectation ? because app1 is sending BT.2020 and his monitor supports BT2020 and he expects the output will be more brighter.
<pq>
If the format is YUV, then BT.601 matrix is used to get to RGB, after which it is assumed to be sRGB (because that is how the content has been presented before color management).
<pq>
brighter??
<ukiran>
i mean BT.2020 cover more Colorspace than SRGB right..
<ukiran>
i mean the user will expect more wider gamut in the case of Bgt.2020
<ukiran>
BT.2020*
<pq>
More color gamut, yes. Not brighter.
<pq>
Well, this design is a major change to anything old, because the display server is not a simple pass-through anymore. But to make HDR work, there cannot be pass-through to begin with.
<pq>
On the side, SDR WCG benefits as well by becoming more correct, even though it may be different from what has been before.
<ukiran>
okay
<pq>
sRGB does not need to be the only assumption, though, when an application does not indicate any colorspace.
Leopold__ has quit [Ping timeout: 480 seconds]
<pq>
it's really implementation specific
<ukiran>
that too the monitor colorimetry values as well
Leopold_ has joined #wayland
<pq>
applications and people did not care about colors before, so it doesn't matter too much how such applications are presented now, as long as end users don't complain much.
fgdfgdfgd has quit []
<pq>
But those applications that do care, must start using the color management extensions. Then everyone will get the right result.
<ukiran>
exactly.. this is what am typing.
<ukiran>
fastest finger first
<pq>
It is also possible for applications to do their own color management. They just need to mark their Wayland surface as using the output colorspace.
Szadek has quit [Quit: WeeChat 3.8]
Szadek has joined #wayland
<ukiran>
if apps are doing the color management, what is the role of compositor here ?
<pq>
to composite and present
<ukiran>
how do they mark on the wayland surface ?
<ukiran>
any colorspace param defined ?
<pq>
Note that the application can target only one output at a time for each wl_surface. On that output, the compositor's color mapping should result to no-op, but not if the surface is visible on any other output at the same time.
<ukiran>
so compositor dont do any color conversion in this case
<pq>
The CM&HDR protocol extension allows the client to get the image description object of an output. The client can attach that image description object to its surface.
<pq>
The compositor will still convert to blending space and then to output space.
<pq>
however, if nothing is blended into those client pixels, then the total outcome is a no-op.
<pq>
All no-ops and skipping of operations come out of compositor internal pipeline optimizations, and not as something predetermined.
<ukiran>
any sample clients implemented this protocol ?
<pq>
no, we are still writing the protocol
<ukiran>
okay
maxzor_ has joined #wayland
maxzor__ has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
Vanfanel has quit [Read error: Connection reset by peer]
Vanfanel has joined #wayland
tzimmermann has quit [Quit: Leaving]
maxzor_ has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
Szadek has quit [Ping timeout: 480 seconds]
Szadek has joined #wayland
ukiran has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #wayland
Leopold_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
pounce has quit [Remote host closed the connection]
pounce has joined #wayland
agd5f has joined #wayland
ukiran has joined #wayland
rv1sr has joined #wayland
Company has joined #wayland
ukiran has quit [Ping timeout: 480 seconds]
matteo has joined #wayland
matteo has quit []
lupesio has joined #wayland
<lupesio>
Hi ! I'm searching the way to change the screen position on an extended weston desktop. But in to the weston.ini documentation I didn't find anything about this... is it possible ?
<pq>
lupesio, unfortunately not. I'm sure we have an issue open about how to come up with a scheme on how to arrange outputs in weston.ini, but it hasn't been implemented.
<pq>
so if you want something else than default, unfortunately you'll have to hack the code, and that might be painful
<lupesio>
many thanks pq....
<lupesio>
the answer is not good ... I'll try to workaround in some way... many thanks again