09:20 ukiran: Hello
09:29 ukiran: hello pq
09:30 ukiran: Looks like i have got fair understanding on the color spaces and the properties related to them
09:31 ukiran: going through the color management protocol defined https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/54e566100d21f5eacbff2b91e7752bb9b668b4ee/staging/color-management/color-management-v1.xml here
09:31 ukiran: for creating the image description object there are multiple factory interfaces defined..
09:33 ukiran: i want to know that the ID (image description) is created by the client initiation only through ICC (factory_icc_v1), Parameters (factory_parametric_v1) ?
09:38 ukiran: pq, could you please help to clarify
09:44 pq: ukiran, sorry, what is your question?
09:46 ukiran: In CM protocol, ImageDescription object is created only by client using global interfaces ?
09:47 pq: I'm not sure what you are asking - yes, that's how Wayland works, and we do not have any events directly creating image description objects.
09:48 pq: but we do have compositors creating underlying image deescriptions, which clients can then get a hold of as a wp_image_description_v1 object.
09:48 ukiran: Compositors created ID will be based on the EDID ?
09:48 pq: output image description and surface preferred image description are fundamentally created by the compositor
09:48 pq: they *can* be, yes
09:49 ukiran: Ouput image description is created based on the EDID only right ?
09:49 pq: no, it an also created from other settings the end user has made
09:49 pq: *can
09:49 ukiran: other settings ?
09:50 pq: compositor setting, yes
09:50 pq: EDID is often wrong or misleading
09:50 ukiran: which interface does the client use to get the compositor created image description ?
09:50 ukiran: Is it through get_image_Description ?
09:51 ukiran: am working on color handshaking design between the client and the server..
09:51 pq: wp_color_management_output_v1.get_image_description and wp_color_management_surface_v1.get_preferred requests
09:52 ukiran: who will define the compositor settings ?
09:53 pq: the compositor developers define what settings the end user can change
09:56 pq: Our accompanying documentation in color-and-hdr will probably make recommendations on what settings would be good to expose.
09:57 ukiran: how does these recommendations will be exposed ?
09:58 pq: as a web page
09:58 pq: https://gitlab.freedesktop.org/pq/color-and-hdr
10:00 pq: much of the discussions happen at https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues
10:02 ukiran: okay.. so far, i thought the Image description object is created based on the EDID supported by the monitor.
10:03 JEEB: if you f.ex. think of the windows compositor, it just always let you do either sRGB SDR, BT.2020+PQ HDR and scRGB floaty. internally it seems to utilize floaty when it cannot do passthrough, otherwise when input and output match, it does passthrough
10:04 ukiran: Based on the color spaces supported by the monitor, we can create the Image Description object with the Color primraies, tc, and matrix co-efficients
10:04 JEEB: so the compositor defines what it can take in, and then the output is what the compositor has to output
10:04 JEEB: (or has configured the screen to output)
10:05 JEEB: you can think of the compositor as the block between applications and the output to GPU
10:06 ukiran: Yes.. i understand this.
10:06 ukiran: but the only part which am missing is, compositor definition of color characteristics.
10:06 pq: ukiran, the compositor *can* create an image description of the output based on the EDID. There are many cases where it would do so, but it's not the only way. Because EDID can be wrong, end users (not clients) must have a way to override that information somehow in the compositor.
10:06 pq: end users are people, clients are application programs
10:07 ukiran: What kind of content an end user can select ?
10:08 pq: ukiran, I might even go as far as saying that for monitors driven as SDR (not HDR), you don't want to use EDID by default. Assume sRGB instead.
10:08 pq: ukiran, sorry?
10:08 ukiran: do you mean to say, a web page with all kinds of color spaces ?
10:08 pq: what?
10:09 pq: I mean, you were asking about several unrelated things, and I gave you answers to those. Web pages have nothing to do with end users.
10:09 JEEB: ukiran: the idea is that some compositors will only support pass-through and thus they advertise only what their video output is configured to. others will expose some set of configurations which they are able to remap to the output
10:10 JEEB: I hope I'm not explaining the completely incorrect things
10:10 pq: JEEB, yeah, the compositor defines what it can take it is fine, until you want to display a video on a KMS plane without using the GPU for color conversion anywhere.
10:13 pq: JEEB, the Wayland design is not that. The compositor does expose what would be an optimal color format, but we always allow clients to use their own, putting the burden of conversion to the compositors, which if lucky can off-load that to KMS.
10:14 pq: There is a mechanism to gracefully reject a client created image description, but that's primarily for things the compositor simply doesn't implement.
10:15 pq: If compositors start using that to accept only image descriptions that do not need any conversion, many clients would probably not work.
10:16 JEEB: yea
10:16 pq: OTOH, if your system is closed and you develop all the possible clients, no problem.
10:17 ukiran: yes..
10:17 JEEB: all I just tried to explain that the configured input into compositor might not have anything to do with the compositor output :)
10:17 pq: what's "configured input"?
10:17 JEEB: the config from app to compositor
10:17 ukiran: pq, based on my understanding from the color-management protocol proposed, i have created one handshake block diagram.. Here it is https://pasteboard.co/H7JRtFo6PFzq.png
10:17 JEEB: "ohai I am sRGB 8bit"
10:18 pq: we call that "image description"
10:18 pq: config is like compositor settings
10:18 JEEB: yup
10:19 ukiran: pq, could you please take a look at https://pasteboard.co/H7JRtFo6PFzq.png
10:19 ukiran: based on my understanding from https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/54e566100d21f5eacbff2b91e7752bb9b668b4ee/staging/color-management/color-management-v1.xml
10:21 pq: ukiran, a compositor would create it's monitor image description before it lights up that monitor. The compositor itself needs it foremost.
10:21 pq: ukiran, clients should favor using the surface preferred image description instead of the output image description.
10:23 pq: ukiran, if a client is using the color information from a video directly as an image description, then it has no need for the preferred or output image descriptions.
10:25 pq: ukiran, your diagram is generally correct.
10:25 ukiran: pq, first line, " a compositor would create it's monitor image description before it lights up that monitor" --> This means, the compositor will create the default image description ?
10:26 pq: ukiran, "the default" is confusing.
10:27 ukiran: pq, more interested to know monitor image description contents
10:27 pq: when a compositor takes a monitor or other output into use, it necessarily needs a color profile (image description) for it. Otherwise it cannot show even its internal content correctly on it.
10:28 pq: If you run a monitor in SDR mode, I'd pick a stock sRGB profile unless the end user has configured something else.
10:29 ukiran: end user configuration is through monitor settings ?
10:29 pq: If you run a monitor in HDR mode, you probably need to take *something* from EDID, guess other bits, and also take into account the container format on the monitor cable.
10:30 pq: but since EDID can be partly or completely wrong, you also need to allow the end user to fine-tune or replace that information
10:30 pq: monitor settings or the DE, yes
10:30 pq: monitor settings of the DE, yes
10:31 ukiran: pq, DE --> display engine i guess.
10:31 pq: no, Desktop Environment
10:32 ukiran: okay
10:32 pq: whatever fancy GUI your end users will use to configure video modes etc.
10:34 pq: Weston does not have a GUI for anything, but it has the weston.ini file where these settings will be able to be made.
10:34 ukiran: Okay.. does this monitor color profile contains all the encode characteristics of H.273 supported ?
10:34 ukiran: pq, do you have such settings configured in .ini ? could you please help to share the sample content how do you define them ?
10:36 pq: ukiran, see 'man weston.ini' and look icc_profile, eotf-mode, color_characteristics
10:36 pq: *look for
10:37 pq: and also the color_characteristics section
10:37 pq: this is incomplete, though
10:38 pq: it is at least missing the directives to use EDID, and then we likely need to be able to override some parameters while others come from EDID
10:38 pq: It's possible or even probably to need completely new parameters as well.
10:38 pq: *probable
10:43 pq: An image description needs at least a characterization of the container color space and the transfer function. For HDR, the dynamic range needs to be described.
10:43 pq: Then, it would be good to have the target color volume characterization (and dynamic range).
10:44 ukiran: am going through the weston.ini for the properties defined..
10:44 pq: Plus, we have been thinking about viewing environment parameters. These are important especially for dynamic range given in absolute units (cd/m²).
10:45 ukiran: this will be given as preferred_image_Description to the client ?
10:45 pq: potentially yes
10:45 ukiran: these viewing params are basically depending on the room environment right ?
10:46 pq: the surface's preferred image description is whatever the compositor would like the client to use to make the compositor's job most efficient.
10:46 pq: yes
10:47 ukiran: okay.. using the video content, client can create the Image_description by reading from the AVCodec (triplet)
10:47 ukiran: and it attaches this ID on surface and send to the compositor..
10:47 pq: In other words, what an image description will contain is quite an open question. We will likely be adding things as we experiment.
10:47 ukiran: does compositor will validate the input surface triplet with its monitor supported triplets ?
10:48 pq: Not validate, no
10:48 ukiran: so compositor directly uses the input surface triplet for encode and decode ?
10:49 pq: the compositor should inspect both content and output image descriptions and do whatever is necessary to display that content on that output in the best possible way as guided by the rendering intent
10:51 ukiran: Ex: Client Input triplet: CP/TC/MC for BT.709 is bt709/bt709/bt709 (1/1/1) and output image description has BT.2020 support
10:51 ukiran: in that case, does compositor will take the best possible Bt.2020 and do the necessary conversion ?
10:52 pq: Usually that means creating a color processing pipeline that decodes the incoming content, converts it through a profile connection space into the output's blending space and applies any necessary tone and gamut mapping as instructed by the rendering intent.
10:52 pq: and then after composition, the result gets encoded for the video mode the monitor is being driven in.
10:53 ukiran: yes, right
10:56 ukiran: now my question is, in my .ini config file, i have defined the color properties without Bt.2020 CP/TC/MC code points. But my monitor supports it. In this case, the best possible output we did not see on the monitor right ?
10:56 ukiran: even though it has wider color gamut support..
10:58 pq: correct, if I understood what you mean
11:00 pq: that also has two different details to it: the kind of signal or metadata you send to the monitor, and the color properties describing how the monitor displays pixel values.
11:00 ukiran: so IANW (If am not wrong), Can I define all possible combinations of color properties as part of the weston.ini and create image description out of these ?
11:01 pq: all possible combinations are the same time?
11:01 pq: *at the same time
11:02 pq: with Weston, you will be able to pick any combination - but it's a whole different question of does your monitor actually behave like that
11:06 ukiran: okay..
11:06 ukiran: does compositor can create the ID using ICC profiles as well ?
11:07 pq: yes
11:07 ukiran: like wise client also ?
11:08 pq: yes, there is the icc factory interface
11:08 pq: which is optional for a compositor to implement, btw.
11:10 ukiran: pq, BRB
11:11 pq: I could maybe compare the settings problem to setting a DPI value in config. You can set any number you like, and it may change the size of things on screen, and they all "work", but only one particular DPI value will actually be physically true. If you change monitor OSD settings, or switch video mode to a different resolution, the physically correct number will probably change.
11:12 pq: Then, let's say you set the DPI to a physically true value, but your monitor is taken two meters further away. Does it still look right? Probably not, but the value is still physically correct.
11:14 pq: Color characteristics are similar, except getting a physical measurement is much harder to do.
11:14 pq: you need more than ruler for that
11:15 pq: The analogue of taking the monitor two meters further away is to change the room lighting or surroundings (viewing environment).
11:16 pq: Change the viewing environment, and even though the monitor is emitting the exact same light spectrum as before, it may not look good anymore.
11:18 pq: So there are actually three different things to get right:
11:18 pq: - driving the monitor, as in, what kind of data and metadata is sent to it
11:18 pq: - knowing how the monitor will turn that data into light
11:19 pq: - how that light will actually look
11:21 pq: You can choose the first one, but not the latter two. You can only adapt your driving to what the latter two do.
14:35 wlb: weston Merge request !1207 opened by Daniel Stone (daniels) drm: Fix type confusion in writeback_state https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1207 [DRM/KMS backend]
16:57 wlb: weston/main: Loïc Molinari * gl-renderer: Get rid of begin fence sync https://gitlab.freedesktop.org/wayland/weston/commit/7c9c545b4e9a libweston/renderer-gl/ gl-renderer-internal.h gl-renderer.c
16:57 wlb: weston Issue #342 closed \o/ ("Start fence" is nonsense https://gitlab.freedesktop.org/wayland/weston/-/issues/342)
16:57 wlb: weston Merge request !1113 merged \o/ (gl-renderer: Improve GPU profiling accuracy https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1113)
17:44 Company: whoever invented the fractional scale protocol didn't think a lot of things through
17:45 Company: or rather: made a lot of things more obvious that weren't thought through
17:45 Company: fun example I'm running into atm: opaque region
18:02 wlb: weston/main: Daniel Stone * input: Consistently use enums for modifier/axis/state https://gitlab.freedesktop.org/wayland/weston/commit/6f9c27ac077e include/libweston/libweston.h libweston/bindings.c
18:02 wlb: weston Merge request !1205 merged \o/ (input: Consistently use enums for modifier/axis/state https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1205)
18:11 emersion: Company: this kind of thing was discussed at length
18:27 Company: excellent, lots of discussions are always good
18:33 Company: I'm pretty sure that what happened was that people implemented it and it worked well enough so they kept it that way - and then all the discussions were just retroactively making up reaasons for why it'd be a bad idea to break everything now
18:33 Company: because all of Wayland kinda works like that ;)
18:34 emersion: that's not how the protocol was designed fwiw
18:38 Company: which one?
18:38 Company: the fractional scale one or the core one?
18:40 Company: because they kinda both suffer from the same problem of the opaque region not being about the buffer's pixels but about the surface's size
18:44 emersion: i'm talking about the fractional scale protocol
18:44 emersion: it doesn't matter for opaque region
18:45 emersion: the opaque region can be smaller than the actual opaque region, it's just a hint for optimizations
18:45 Company: except when you're fullscreen
18:45 Company: and the off by one causes you to not hit the direct scanout optimization
18:45 emersion: you just set the opaque region to the viewporter dest rect
18:46 Company: yeah, if your code rounds it that way
18:46 emersion: that's a client issue then
18:46 Company: but your code may just do what you said and decide it can be smaller than the actual opaque region
18:46 Company: totally
18:46 Company: the client gets to unfuck the protocol
18:47 kchibisov: Company: fullscreen window is always opaque regardless.
18:47 kchibisov: just as a side note.
18:47 emersion: no, the client sgets to behave as excepted
18:47 emersion: expected*
18:47 emersion: it's a deliberate trade-off in the protocol
18:48 Company: fun rounding games for everyone
18:49 kchibisov: The rounding is stated in the protocol though, just not exact approach. If your client decided not to use what suggest it's on you.
18:49 Company: totally
18:49 emersion: "doctor it hurts i designed by client badly" well yeah, not sure what we can do about it
18:50 emersion: just round once, and then use the scaled and unscaled sizes
18:50 kchibisov: For exact approach there's an issue opened https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/132
18:51 kchibisov: The only obvious issue with fractional scaling, is when output logical size can't be represented with the scale you're using. But it's up to compositor to restrict the scaling factors you can pick.
18:52 Company: yeah, I figured that out yesterday when I was given a scaling factor of 329/120
18:53 Company: because that was fewer pixels off than 330/120
18:53 Company: with the plus that now pretty much no application pixel boundary matched with a device pixel boundary
18:53 kchibisov: Are you writing client or compositor?
18:54 Company: GTK
18:54 kchibisov: Be aware that some compositors have bugged fractinol scaling impl, like sway.
18:54 Company: I'm usually using gnome-shell
18:55 Company: I just started playing with it and the more I looked, the wonkier everything ended up being
18:57 Company: I mean, it's kinda neat that I get a fraction (though why is it in 120th and then uses a wp_viewproteer protocol that uses 1/256th, what's that about?) that I can scale my buffer at
18:58 Company: because it makes it really easy for a client to decide to create an even larger buffer for more accurate rendering (or for testing)
18:59 Company: but attempting to map to device pixels - literal pixels on the monitor - gets really hard that way
18:59 kchibisov: I'm not sure from where you've got 1/256th viewporter reference. Viewporter is all logical sizes.
19:00 Company: kchibisov: it's using wl_fixed, which is 1/256th
19:00 emersion: viewporter doesn't use wl_fixed
19:00 kchibisov: ^
19:00 Company: for the source
19:01 kchibisov: But for fractional scaling you don't set source.
19:01 emersion: source and dest rects are just ints
19:01 Company: the source rect is wl_fixed
19:02 emersion: incorrect
19:02 emersion: oh, okay
19:02 kchibisov: emersion: it's actually...
19:02 emersion: yes, it is wl_fixed. but it doesn't matter
19:02 emersion: you only use the fractional part if you want to sample in-between two pixels
19:03 Company: yes, which you'd need to do if you had to align to subpixels - though the fractional scale protocol doesn't do this and conveniently leaves that part "undefined"
19:05 Company: had a fun argument about aligning subsurfaces on fractionally scaled outputs with some shell devs yesterday
19:05 kchibisov: Company: there's an alternative protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/149
19:06 zamundaaa[m]: Company: the compositor guarantees that every (toplevel) surface starts on a whole pixel
19:07 Company: zamundaaa[m]: yeah, but that falls apart for subsurfaces
19:09 Company: zamundaaa[m]: it also falls apart if the compositor chooses 329/120 as the scale factor
19:10 Company: zamundaaa[m]: because users will notice when toplevels can only be moved by multipls of 329 device pixels ;)
19:11 emersion: kchibisov: is sway still broken though? i thought we fixed everything
19:11 Company: kchibisov: I think I like the current approach better - with the caveat that it needs to be way more explicit about the 3 involved coordinate systems (surface, buffer and device)
19:12 kchibisov: emersion: Well, my issue is still opened ¯\_(ツ)_/¯ https://github.com/swaywm/sway/issues/7463
19:13 kchibisov: We concluded with kennylevinsen that the issue is due to sway/wlroots dynamically changing the rounding based on the window position, so if you move around it gets blurry/not blurry.
19:14 emersion: ah, i see
19:14 kchibisov: Given that hyprland has the excat same bug, based on the user report I had in alacritty, it's likely a wlroots thing.
19:15 emersion: nah, wlroots doesn't handle toplevel position
19:16 kchibisov: Hm, maybe they were inspired by sway.
19:16 zamundaaa[m]: Company: The usual way that users notice the protocol is imperfect is when with some scales there's gaps between the panel and window, because not all window sizes can be communicated
19:16 Company: yeah
19:17 Company: that's where it would be cool if the protocol could say "your surface's (0, 0) is not on a pixel boundary, but offset by 0.5 or 0.333333 or whatever
19:18 Company: that would work for subsurfaces, too
19:18 Company: and then you'd use viewport.set_source() to offset your buffer
19:20 Company: btw
19:20 Company: while I'm complaining
19:21 Company: the preferred_scale notification in gnome-shell arrives too late - at the point it arrives GTK has already commit()ed the first buffer
19:22 Company: it would be nice if the protocol explained when it expects that event to be sent
19:22 Company: the shell delays it until it know which output the surface will be on, but that requires doing the configuring
19:22 Company: and GTK wants to draw right after configuring
19:23 Company: so there's a question about how things shouold be ordered
19:23 kchibisov: But you sort of know where the client will open on the first configure from the compositor perspective?
19:23 Company: I expect so
19:24 Company: I work on GTK though, so no idea
19:24 kchibisov: So gnome can clearly send you the scale factor along with the first configure.
19:24 Company: yeah
19:24 Company: but it would be good if the spec said so
19:25 Company: "clients can expect the event to arrive before the first configure"
19:26 Company: it's a somewhat more generic question, because it applies to all properties of surfaces
19:26 Company: like I'd expect the colorspace stuff to have that problem, too
19:27 Company: enter() events have that problem, too, though GTK doesn't care too much about those (apart from deducing the scale, which is now no longer necessary)
19:27 jadahl: Company: the spec doesn't tie anything into the configure sequence because it kind of waits for wl_surface.configure event to become a thing first
19:27 zamundaaa[m]: See https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/227, which is meant for that purpose
19:27 zamundaaa[m]: Currently, tying stuff in with the first configure event is a bit weird, because it depends on the shell interface instead of only on wl_surface
19:28 kchibisov: Company: I think the reason it's not mentioned is similar with the wl_surface::preferred_buffer_scale new event on a wl_surface v6.
19:29 Company: yeah, that configure thing sounds good
19:29 Company: kinda like commit(), just for the server
19:30 kchibisov: As a windowing library writter scale arrive hasn't bothered me that much, because 1. every request is logical (except buffer damage), so it doesn't matter the scaling. 2. The scale factor will be needed when I want to draw something actually, so if the compositor hasn't bothered to send me scale factor in time, it's up to it.
19:31 Company: kchibisov: GTK loads icon assets based on scale factor, and if the scale changes it has to reconfigure all those assets and reupload them to the GPU and that's a lot of bookkeeping going on
19:32 kchibisov: Yeah, but you should handle client moving between different DPI monitors.
19:32 Company: sure, it's not visible
19:32 Company: to the normal observer
19:33 Company: but my debugger stopped twice instead of once when starting my app
19:33 Company: oh, another thing:
19:34 Company: fractional scale needs a way to communicate fractional scale for outputs
19:34 kchibisov: Like I can't say much on assets loading, because I do such thing lazy.
19:34 kchibisov: The scale on wl_output is sort of deprecated though.
19:34 Company: we do that in a thread so the assets are available when we want to render
19:35 Company: so we want a scale asap
19:36 kchibisov: Like the source of scale is the new wl_surface v6 interface. But again, I'm not the one designing the protocols, I'm just a windowing library writer.
19:36 Company: I don't have a wel_surface yet
19:36 Company: when I start loading assets
19:37 kchibisov: Ah, then if you don't have a surface, how do you know which scale factor to load?
19:37 Company: we currently use the scale of the first output
19:37 Company: which is right in almost all cases
19:37 kchibisov: That's wrong though, because what is first is not even defined.
19:38 emersion: <Company> fractional scale needs a way to communicate fractional scale for outputs
19:38 emersion: why?
19:38 Company: it's better than any other option
19:38 Company: emersion: see backlog
19:38 kchibisov: emersion: they exlained that they guess based on output.
19:38 emersion: ouch
19:38 emersion: that's not good
19:39 kchibisov: I would make an assumption that your assets loader is some sort of singleton per process. You likely can access it later after surface creation.
19:39 Company: sure
19:40 Company: that's what we do when the scale turns out to be wrong and we have to reload assets
19:40 kchibisov:would be impressed to see a C gui library without a global state.
19:40 Company: but the way startup works in GTK is kinda like this:
19:40 Company: 1. create the wl_compositor
19:40 Company: 2. create the widget tree
19:40 zamundaaa[m]: Company: You don't know where the compositor will place the surface. Adding a fractional scale to outputs just makes more people do hacks like that, which is the opposite of what we want
19:40 Company: 3. create wl_surface(s) for the widget tree
19:41 Company: 4. configure the wl_surface(s) with the widget tree's sizing information
19:42 kchibisov: But you can't use any of the sizing unless you commit the surface and get the configure back?
19:42 kchibisov: as in all geometry requests on surfaces without buffers will likely be a protocol error.
19:43 Company: I'm not an expert on what I can and can't doin Wayland
19:43 Company: I'm just saying that the current code works in a way that the preferred scale arrives rather late
19:44 emersion: Company: this is tracked here https://gitlab.freedesktop.org/wayland/wayland/-/issues/133
19:44 jadahl: Company: you should ideally load resources and layout *after* getting the initial configure from the surface so you know the size, whether you're maximized, the scale, etc. any attempt to peek at wl_output is unreliable
19:44 kchibisov: I think it was sort of stated that scale arrives after the configure.
19:45 kchibisov: At least, that's how I understood Company .
19:45 Company: jadahl: right, but for that I need to know the size and for that I need to load the whole widget tree
19:45 kchibisov: And what they really want if compositors send the scale before the first configure.
19:45 kchibisov: As in "reliable".
19:45 Company: jadahl: so we're pushing the asset loading further and further back
19:46 Company: I just want to do some opportunistic loading in a thread
19:46 Company: and end up being lucky
19:47 jadahl: Company: you can't possibly have the size until after the configure event
19:47 Company: I know which assets I need when creating the widget tree, and I need the full widget tree to know the size I should configure the surface with
19:47 Company: yeah
19:47 Company: that's why I want an opportunistic scale
19:47 Company: the number that's most likely to make me luicky
19:47 jadahl: there is no such scale
19:48 kchibisov: Company: configure, as in *server send you* event.
19:48 kchibisov: just to ensure we're on the same page.
19:48 Company: jadahl: on my laptop there is such a scale - and it is a hit 100% of the time
19:48 Company: because my laptop has exactly 1 output and uses a scale of 2 for everything
19:48 jadahl: Company: that's not a general solution, just unreliable guess work
19:49 kennylevinsen: tbf some compositors do know the placement before map occurs and they could send early - they might be the exception though
19:49 jadahl: what's the point of delaying resource loading 1 ms?
19:49 Company: it's more than 1ms
19:49 jadahl: erm, the other way around I mean
19:51 Company: I mean, GTK has a ::scale property that it needs to initialize somehow, and send change notifications whenever it changes
19:51 Company: so picking a good initial value is worth it anyway
19:51 Company: but that can be considered a GTK problem, too
19:53 Company: still, having a good first guess for the scale without needing a wl_surface is something we like
19:53 Company: and currently, with using output[0].scale, I'd expect we hit that in >90% of the cases
19:54 Company: probably closer to 99%, because people with multiple differently-scaled outputs are probably very rare
19:54 kennylevinsen: maybe voice this on the issue emersion linked that specifically addresses the topic
19:54 kennylevinsen: sure, you could also say that you'd get it right 85% of the time by assuming "1"
19:55 kchibisov: kennylevinsen: they want to assume without any surface created though, not sure that linked issue will help.
19:55 kennylevinsen: but that's not really a solution - we want this solved, but want it done in a way that doesn't require making poorly informed guesses...
19:55 kennylevinsen: Well it addresses getting to know it in time for first render
19:56 kchibisov: Yeah, but they don't want that ¯\_(ツ)_/¯
19:57 kennylevinsen: If you don't care about rendering, you have no business knowing with the scale - roll a dice, assume always 0, doesn't matter if it doesn't result in render :)
19:57 Company: does matter in that our first buffer appears a few frames earlier
19:57 kennylevinsen: if you have a buffer, you must have rendered and so the issue applies
19:58 Company: yes
19:58 Company: but if we're still busy loading assets, the buffer will take a while
19:58 kchibisov: Yeah, and the wl_surface v6 covers that, so you get your first scaling before you'll draw.
19:58 kchibisov: The fractional scaling protocol also covers that.
19:58 Company: I want the first scaling before I create the wl_surface
19:59 kchibisov: And that's the thing, you can't.
19:59 Company: I can get pretty close
19:59 kennylevinsen: that doesn't matter, what you need is the scale before you attach and commit a buffer (and therefore also before you prepared that buffer) - and that's what the issue is about
20:01 Company: I should actually try figuring out what happens wth some asset-heavy code, ideally stuff that doesn't have the assets in cache
20:01 Company: to see how big of a problem that is
20:01 daniels: you can have a surface long before you render
20:02 Company: example would probably be file managers who load thumbnails
20:04 Company: daniels: yes and no - we could redesign how we construct our widget tree to create the wl_surface asap
20:04 Company: daniels: but currently the surface creation step happens rather late
20:05 kchibisov: I do wonder why are you creating wigdet tree, and then top-level though.
20:05 Company: but it'd also assume that compositors send buffer scale etc before the first configure
20:05 kchibisov: For me it would be more natural to create top-level and then init the widget tree with it, by moving top-level into it.
20:06 Company: kchibisov: GTK creates the window system resources in a separate realize() step - and that step usually runs after creating the widget tree
20:06 kchibisov: But I'm have no clue about GTK limitations.
20:06 Company: no idea why, probably historic
20:07 Company: I also never considered it a benefit to create the wl_surface earlier
20:07 Company: (or the XWindow or the HWND)
20:08 kchibisov: You can't use your graphics API without creating a HWND on windows.
20:08 Company: correct
20:08 Company: but I can build my widget tree
20:09 kchibisov: By use, I mean that you can't do even config loading/matching like you can with GLX/EGL.
20:09 kchibisov: Or checking what extensions you have, but that's sort of offtopic.
20:09 Company: uh yes, but we do that by having a dedicated global HWND that does that part
20:09 Company: we have that on X, too
20:10 kchibisov: And on Wayland you have to a get a configure from compositor 'to make your window ready for drawing' and get your scale factors along the way.
20:11 kchibisov: With the recent stack of protocols we're having, before you have https://gitlab.freedesktop.org/wayland/wayland/-/issues/133
20:11 kchibisov: you have -> you had*
20:12 Company: right, if we assume the wl_surface tells us everything we want to know before we negotiate a size with it, that would work
20:14 Company: still a fun question there because we'd need to wait for the events to arrive while we're busy initializing the widget tree, but a fun task for the future
20:15 kchibisov: Company: you can certainly do while !got_configure { sync_roundtrip() } and then continue your init flow.
20:16 kchibisov: And once you've got the configure, you have bounds, sizes, states, and so on to properly set styles of the widget tree anyway.
20:16 Company: yeah, but I want to do that in a thread so the main thread can load its widgets
20:16 Company: because I need both - the widgets to be ready and the wl_surface
20:26 soreau: if it's taking that long to get a configure event from the compositor, there's already a pretty big problem
22:30 ForeverNoob[m]: Hello, can Wayland users running on a Thinkpad X220T or X230T with multi-touch please let me know what the output of "xinput list" is? Thanks.
22:30 ForeverNoob[m]: (Trying to determine how to reliably test whether the X220T/X230T is multi-touch or not)