08:47 jadahl: Vanfanel: i would try to make it a decision that involves the weston_desktop_surface directly, and checks if it's logically fullscreen
08:50 pq: Vanfanel, using a weston_surface or weston_view pointer in weston_seat *would* work with multiple seats. Only the single serial wouldn't.
08:52 jadahl: pq: I think the intention was to grant it without a serial if the xdg_toplevel has the fullscreen state
08:54 pq: Vanfanel, there is no such thing as wl_view.
08:55 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.
08:59 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.
08:59 pq: and it's also not the internal serial already used in the code
09:01 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.
09:03 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.
09:03 pq: now that decisions on confiment actually need concepts that only exist inside the shell plugin, the old design just doesn't work anymore.
09:05 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.
09:06 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?
09:09 pq: Personally I cannot afford to participate in that re-design this year.
09:49 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,
09:49 Vanfanel: right?
09:50 Vanfanel: I mean: faking a click on a view would be doing: view->click_to_activate_serial = surface->compositor->activate_serial, right?
09:52 pq: I guess so. I don't know. I'm just asking if you doing that *setting* on the right view in the shell?
09:53 pq: have you added prints to see how the serials change and what input.c sees?
09:54 Vanfanel: pq: I am going to do that, yes. Good idea.
09:54 pq: :-)
09:55 pq: printing the pointer to the weston_view might help too
11:07 ukiran: Hello swick and pq
11:08 ukiran: this is regarding the color management protocol implementation.. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14/
11:08 ukiran: Could you please help to confirm whether the design is frozen ?
11:10 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. :)
11:11 pq: ukiran, no, it's not frozen.
11:11 pq: ukiran, I have planned changes to do on it, too.
11:12 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.
11:18 ukiran: After i go through the details of the documentation, i have few doubts which needs the clarification
11:19 ukiran: As i know, the compositor is the decision maker of the blending policy in weston
11:20 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 ?
11:21 pq: ukiran, yes.
11:22 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.
11:22 ukiran: In this case what is the blending policy applied in the compositor ?
11:24 pq: ukiran, both source contents are converted into a common blending space, composited, and then converted to the monitor expected space.
11:24 ukiran: Common blending space means XYZ colrospace ?
11:24 pq: no
11:25 pq: the common blending space is something the compositor implementation decides
11:26 pq: Weston is going to use the monitor color space except with optical values instead of electrical values.
11:26 pq: or whatever colorspace the monitor signalling is going to use
11:28 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 ?
11:30 pq: The choice of the blending space will not depend on the input. It depends only on the properties of the output (monitor).
11:31 pq: Anything that comes in gets converted appropriately to the blending space and eventually to the output space.
11:31 ukiran: Would you please elaborate on the properties of the output ? you mean to say chromaticities read as part of the EDID info ?
11:33 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.
11:34 pq: It may also require end-user adjustable settings, given how unreliable and unusable EDID data is.
11:37 ukiran: unreliable EDID means the data without VCGT tag ?
11:38 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.
11:39 pq: or it claims the display support HDR, but fails to provide *any* HDR parameters.
11:41 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.
11:41 pq: VCGT is an ICC file tag, it's not in EDID.
11:41 ukiran: this flag will be part of some profile file ?
11:42 pq: what flag?
11:42 ukiran: sorry VCGT tag
11:43 pq: Yes, VCGT is a tag that may be present inside an ICC profile file.
11:43 ukiran: i think this should be used for the calibration purpose
11:43 pq: Yes, it is calibration. If VCGT exists, it must be used, otherwise the ICC profile is not valid.
11:44 ukiran: yeah.. i get it
11:45 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 ?
11:45 ukiran: app1 buffer is RGB color format and app2 buffer is YCbCr color format..
11:46 JEEB: blending space is whatever compositor chooses, f.ex. the windows compositor uses 16bit floaty scRGB
11:46 pq: ukiran, did you see https://gitlab.freedesktop.org/wayland/weston/-/issues/467#note_864054 ?
11:47 JEEB: output is what the compositor is configured towards with regards to a given screen I.presume
11:47 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
11:48 pq: correct
11:48 JEEB: geez, touch keyboards and typing
11:48 pq: heh
11:48 ukiran: haha
11:49 ukiran: pq, i will go through the referred link
11:50 pq: ukiran, I mean only the one comment it links to, with the diagrams. Not the whole page.
11:51 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.
11:52 ukiran: Electrical signalling meaning OETF ?
11:53 pq: electrical as the 'E' in OETF and EOTF, yes.
11:53 pq: and 'O' for optical
11:53 ukiran: Yes
11:55 ukiran: as per my study, i see that the stps involved conversion between the colorspaces mentioned in the links
11:55 ukiran: https://drafts.csswg.org/css-color/#predefined-to-predefined
11:55 pq: The blending space in Weston is essentially the output color space with the inverse output EOTF applied on top.
11:56 ukiran: Ex: Scenario is to convert the YCbCr Bt.601 color space data into BT.709
11:56 ukiran: Steps involved in doing this operation are
11:56 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.
11:56 ukiran: 2. Conversion from non-linear RGB to Linear RGB. We use transfer function for this i.e.) EOTF-1 (EOTF inverse) function
11:56 ukiran: 3. Conversion from BT.601 RGB to BT.709 RGB primaries
11:56 ukiran: 4. Conversion from Linear RGB representation using target primaries to a non-linear R'G'B' representation i.e.) OETF
11:56 ukiran: Conversion from non-linear R'G'B' to Y'CbCr Color model using matrix multiplication.
11:56 ukiran: This is based on my understanding, i noted it.
11:58 pq: Roughly, almost at least,yeah.
12:00 ukiran: Is Blending to output CS is done through KMS right.. In this case, you are doing it with CRTC or Plane ?
12:01 ukiran: or is this is yet to implement ?
12:01 pq: Currently Weston does it with GL ES 3 shaders, but it is intended to be done in KMS on the CRTC.
12:02 pq: ...when possible.
12:03 ukiran: okay
12:05 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 ?
12:06 pq: The compositor will assume something, usually sRGB colorimetry, if it's YUV then BT.601 matrix coefficients.
12:08 ukiran: the default is SRGB for RGB format and BT.601 for YUV format.
12:08 pq: no
12:09 pq: The default is sRGB.
12:09 ukiran: okay
12:11 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.
12:11 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).
12:11 pq: brighter??
12:12 ukiran: i mean BT.2020 cover more Colorspace than SRGB right..
12:13 ukiran: i mean the user will expect more wider gamut in the case of Bgt.2020
12:13 ukiran: BT.2020*
12:13 pq: More color gamut, yes. Not brighter.
12:13 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.
12:14 pq: On the side, SDR WCG benefits as well by becoming more correct, even though it may be different from what has been before.
12:15 ukiran: okay
12:16 pq: sRGB does not need to be the only assumption, though, when an application does not indicate any colorspace.
12:16 pq: it's really implementation specific
12:16 ukiran: that too the monitor colorimetry values as well
12:17 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.
12:18 pq: But those applications that do care, must start using the color management extensions. Then everyone will get the right result.
12:19 ukiran: exactly.. this is what am typing.
12:19 ukiran: fastest finger first
12:20 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.
12:29 ukiran: if apps are doing the color management, what is the role of compositor here ?
12:30 pq: to composite and present
12:30 ukiran: how do they mark on the wayland surface ?
12:31 ukiran: any colorspace param defined ?
12:31 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.
12:32 ukiran: so compositor dont do any color conversion in this case
12:32 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.
12:33 pq: The compositor will still convert to blending space and then to output space.
12:33 pq: however, if nothing is blended into those client pixels, then the total outcome is a no-op.
12:34 pq: All no-ops and skipping of operations come out of compositor internal pipeline optimizations, and not as something predetermined.
12:37 pq: JEEB, would https://gitlab.freedesktop.org/pq/color-and-hdr/-/merge_requests/20 ring any bells to you?
12:37 ukiran: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14/diffs?commit_id=f118d082a66026c13e54d198f353ab46adcb2a78 --> is this is the image description protocol defines ?
12:38 pq: The wp_image_description_v1 is.
12:39 pq: That patch you linked to is only the ICC factory. There are other factories as well.
12:39 ukiran: sure.. will go over the changes
12:40 pq: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14/diffs?commit_id=154eee12ef0222ba4705adbed9848991764040d6 is the output factory one.
12:40 ukiran: any sample clients implemented this protocol ?
12:41 pq: no, we are still writing the protocol
12:41 ukiran: okay
15:26 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 ?
15:33 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.
15:34 pq: so if you want something else than default, unfortunately you'll have to hack the code, and that might be painful
15:35 lupesio: many thanks pq....
15:36 lupesio: the answer is not good ... I'll try to workaround in some way... many thanks again
15:36 pq: lupesio, https://gitlab.freedesktop.org/wayland/weston/-/issues/165 FWIW
15:52 lupesio: thanks again !