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
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
robobub_ has joined #wayland
Brainium has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
chipxxx has joined #wayland
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
Company has quit [Quit: Leaving]
shankaru has quit [Read error: Connection reset by peer]
shankaru has joined #wayland
dcz_ has joined #wayland
danvet has joined #wayland
UndeadLeech_ has joined #wayland
JPEW_ has joined #wayland
d10n_ has joined #wayland
systwi has quit [resistance.oftc.net weber.oftc.net]
glisse has quit [resistance.oftc.net weber.oftc.net]
bindu has quit [resistance.oftc.net weber.oftc.net]
c7s has quit [resistance.oftc.net weber.oftc.net]
txtsd_ has quit [resistance.oftc.net weber.oftc.net]
WhyNotHugo has quit [resistance.oftc.net weber.oftc.net]
leon-p_ has quit [resistance.oftc.net weber.oftc.net]
dnkl_ has quit [resistance.oftc.net weber.oftc.net]
abcdw_ has quit [resistance.oftc.net weber.oftc.net]
Lyude has quit [resistance.oftc.net weber.oftc.net]
kchibisov has quit [resistance.oftc.net weber.oftc.net]
ifreund has quit [resistance.oftc.net weber.oftc.net]
tommybomb_ has quit [resistance.oftc.net weber.oftc.net]
cpli_ has quit [resistance.oftc.net weber.oftc.net]
d10n has quit [resistance.oftc.net weber.oftc.net]
soreau has quit [resistance.oftc.net weber.oftc.net]
anarsoul has quit [resistance.oftc.net weber.oftc.net]
hays has quit [resistance.oftc.net weber.oftc.net]
AJ_Z0 has quit [resistance.oftc.net weber.oftc.net]
ovf has quit [resistance.oftc.net weber.oftc.net]
bcheng has quit [resistance.oftc.net weber.oftc.net]
gfxstrand has quit [resistance.oftc.net weber.oftc.net]
everfree_ has quit [resistance.oftc.net weber.oftc.net]
Sachiel has quit [resistance.oftc.net weber.oftc.net]
Lightsword has quit [resistance.oftc.net weber.oftc.net]
that_guy_ has quit [resistance.oftc.net weber.oftc.net]
UndeadLeech has quit [resistance.oftc.net weber.oftc.net]
JPEW has quit [resistance.oftc.net weber.oftc.net]
yar has quit [resistance.oftc.net weber.oftc.net]
daniels has quit [resistance.oftc.net weber.oftc.net]
ebassi has quit [resistance.oftc.net weber.oftc.net]
ogromny_ has quit [resistance.oftc.net weber.oftc.net]
jimjams has quit [resistance.oftc.net weber.oftc.net]
yongxiang______ has quit [resistance.oftc.net weber.oftc.net]
lvrp16 has quit [resistance.oftc.net weber.oftc.net]
seanpaul_ has quit [resistance.oftc.net weber.oftc.net]
abdur has quit [resistance.oftc.net weber.oftc.net]
isinyaaa has quit [resistance.oftc.net weber.oftc.net]
JPEW_ is now known as JPEW
glisse has joined #wayland
jimjams has joined #wayland
c7s has joined #wayland
leon-p_ has joined #wayland
bindu has joined #wayland
dnkl_ has joined #wayland
ifreund has joined #wayland
tommybomb_ has joined #wayland
ogromny_ has joined #wayland
abcdw_ has joined #wayland
cpli_ has joined #wayland
soreau has joined #wayland
hays has joined #wayland
anarsoul has joined #wayland
ovf has joined #wayland
AJ_Z0 has joined #wayland
bcheng has joined #wayland
everfree_ has joined #wayland
gfxstrand has joined #wayland
Lightsword has joined #wayland
Sachiel has joined #wayland
that_guy_ has joined #wayland
kchibisov has joined #wayland
systwi has joined #wayland
daniels has joined #wayland
yar has joined #wayland
WhyNotHugo has joined #wayland
yongxiang______ has joined #wayland
Lyude has joined #wayland
txtsd_ has joined #wayland
isinyaaa has joined #wayland
abdur has joined #wayland
seanpaul_ has joined #wayland
lvrp16 has joined #wayland
ebassi has joined #wayland
tzimmermann has joined #wayland
rasterman has joined #wayland
i509vcb has quit [Quit: Connection closed for inactivity]
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
shankaru has quit [Ping timeout: 480 seconds]
mvlad has joined #wayland
ukiran has joined #wayland
<ukiran>
Hello
ukiran1 has joined #wayland
ukiran has quit [Ping timeout: 480 seconds]
ukiran1 has quit [Ping timeout: 480 seconds]
ukiran has joined #wayland
<ukiran>
hello pq
<ukiran>
Looks like i have got fair understanding on the color spaces and the properties related to them
<ukiran>
for creating the image description object there are multiple factory interfaces defined..
<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) ?
<ukiran>
pq, could you please help to clarify
<pq>
ukiran, sorry, what is your question?
<ukiran>
In CM protocol, ImageDescription object is created only by client using global interfaces ?
<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.
<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.
<ukiran>
Compositors created ID will be based on the EDID ?
<pq>
output image description and surface preferred image description are fundamentally created by the compositor
<pq>
they *can* be, yes
<ukiran>
Ouput image description is created based on the EDID only right ?
<pq>
no, it an also created from other settings the end user has made
<pq>
*can
<ukiran>
other settings ?
<pq>
compositor setting, yes
<pq>
EDID is often wrong or misleading
<ukiran>
which interface does the client use to get the compositor created image description ?
<ukiran>
Is it through get_image_Description ?
<ukiran>
am working on color handshaking design between the client and the server..
<pq>
wp_color_management_output_v1.get_image_description and wp_color_management_surface_v1.get_preferred requests
<ukiran>
who will define the compositor settings ?
<pq>
the compositor developers define what settings the end user can change
<pq>
Our accompanying documentation in color-and-hdr will probably make recommendations on what settings would be good to expose.
<ukiran>
how does these recommendations will be exposed ?
<ukiran>
okay.. so far, i thought the Image description object is created based on the EDID supported by the monitor.
<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
<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
<JEEB>
so the compositor defines what it can take in, and then the output is what the compositor has to output
<JEEB>
(or has configured the screen to output)
<JEEB>
you can think of the compositor as the block between applications and the output to GPU
<ukiran>
Yes.. i understand this.
<ukiran>
but the only part which am missing is, compositor definition of color characteristics.
<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.
<pq>
end users are people, clients are application programs
<ukiran>
What kind of content an end user can select ?
<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.
<pq>
ukiran, sorry?
<ukiran>
do you mean to say, a web page with all kinds of color spaces ?
<pq>
what?
<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.
<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
<JEEB>
I hope I'm not explaining the completely incorrect things
<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.
rosefromthedead has joined #wayland
<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.
<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.
<pq>
If compositors start using that to accept only image descriptions that do not need any conversion, many clients would probably not work.
<JEEB>
yea
<pq>
OTOH, if your system is closed and you develop all the possible clients, no problem.
<ukiran>
yes..
<JEEB>
all I just tried to explain that the configured input into compositor might not have anything to do with the compositor output :)
<pq>
what's "configured input"?
<JEEB>
the config from app to compositor
<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
<pq>
ukiran, a compositor would create it's monitor image description before it lights up that monitor. The compositor itself needs it foremost.
<pq>
ukiran, clients should favor using the surface preferred image description instead of the output image description.
<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.
<pq>
ukiran, your diagram is generally correct.
<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 ?
<pq>
ukiran, "the default" is confusing.
<ukiran>
pq, more interested to know monitor image description contents
<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.
<pq>
If you run a monitor in SDR mode, I'd pick a stock sRGB profile unless the end user has configured something else.
<ukiran>
end user configuration is through monitor settings ?
<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.
<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
<pq>
monitor settings or the DE, yes
<pq>
monitor settings of the DE, yes
<ukiran>
pq, DE --> display engine i guess.
<pq>
no, Desktop Environment
<ukiran>
okay
<pq>
whatever fancy GUI your end users will use to configure video modes etc.
ahartmetz has joined #wayland
<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.
<ukiran>
Okay.. does this monitor color profile contains all the encode characteristics of H.273 supported ?
<ukiran>
pq, do you have such settings configured in .ini ? could you please help to share the sample content how do you define them ?
<pq>
ukiran, see 'man weston.ini' and look icc_profile, eotf-mode, color_characteristics
<pq>
*look for
<pq>
and also the color_characteristics section
<pq>
this is incomplete, though
<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
<pq>
It's possible or even probably to need completely new parameters as well.
<pq>
*probable
<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.
<pq>
Then, it would be good to have the target color volume characterization (and dynamic range).
kts has joined #wayland
<ukiran>
am going through the weston.ini for the properties defined..
<pq>
Plus, we have been thinking about viewing environment parameters. These are important especially for dynamic range given in absolute units (cd/m²).
<ukiran>
this will be given as preferred_image_Description to the client ?
<pq>
potentially yes
<ukiran>
these viewing params are basically depending on the room environment right ?
kts has quit []
<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.
<pq>
yes
<ukiran>
okay.. using the video content, client can create the Image_description by reading from the AVCodec (triplet)
<ukiran>
and it attaches this ID on surface and send to the compositor..
<pq>
In other words, what an image description will contain is quite an open question. We will likely be adding things as we experiment.
<ukiran>
does compositor will validate the input surface triplet with its monitor supported triplets ?
<pq>
Not validate, no
<ukiran>
so compositor directly uses the input surface triplet for encode and decode ?
<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
jmdaemon has quit [Ping timeout: 480 seconds]
<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
<ukiran>
in that case, does compositor will take the best possible Bt.2020 and do the necessary conversion ?
<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.
<pq>
and then after composition, the result gets encoded for the video mode the monitor is being driven in.
<ukiran>
yes, right
<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 ?
<ukiran>
even though it has wider color gamut support..
<pq>
correct, if I understood what you mean
<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.
<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 ?
<pq>
all possible combinations are the same time?
<pq>
*at the same time
kts has joined #wayland
<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
Company has joined #wayland
<ukiran>
okay..
<ukiran>
does compositor can create the ID using ICC profiles as well ?
<pq>
yes
<ukiran>
like wise client also ?
<pq>
yes, there is the icc factory interface
<pq>
which is optional for a compositor to implement, btw.
<ukiran>
pq, BRB
<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.
<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.
<pq>
Color characteristics are similar, except getting a physical measurement is much harder to do.
<pq>
you need more than ruler for that
<pq>
The analogue of taking the monitor two meters further away is to change the room lighting or surroundings (viewing environment).
<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.
<pq>
So there are actually three different things to get right:
<pq>
- driving the monitor, as in, what kind of data and metadata is sent to it
<pq>
- knowing how the monitor will turn that data into light
<pq>
- how that light will actually look
<pq>
You can choose the first one, but not the latter two. You can only adapt your driving to what the latter two do.
nerdopolis has joined #wayland
godvino has joined #wayland
cool110_ has joined #wayland
cool110 has quit [Ping timeout: 480 seconds]
crazybyte has quit [Quit: Bye]
crazybyte has joined #wayland
crazybyte has quit []
crazybyte has joined #wayland
dcz has joined #wayland
crazybyte has quit []
crazybyte has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
sb has joined #wayland
sb has quit []
fmuellner has joined #wayland
ukiran has quit [Ping timeout: 480 seconds]
godvino has quit [Quit: WeeChat 3.6]
rv1sr has joined #wayland
that_guy_ has quit [Remote host closed the connection]
<emersion>
Company: this kind of thing was discussed at length
<Company>
excellent, lots of discussions are always good
<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
<Company>
because all of Wayland kinda works like that ;)
<emersion>
that's not how the protocol was designed fwiw
<Company>
which one?
<Company>
the fractional scale one or the core one?
<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
<emersion>
i'm talking about the fractional scale protocol
<emersion>
it doesn't matter for opaque region
<emersion>
the opaque region can be smaller than the actual opaque region, it's just a hint for optimizations
<Company>
except when you're fullscreen
<Company>
and the off by one causes you to not hit the direct scanout optimization
<emersion>
you just set the opaque region to the viewporter dest rect
<Company>
yeah, if your code rounds it that way
<emersion>
that's a client issue then
<Company>
but your code may just do what you said and decide it can be smaller than the actual opaque region
<Company>
totally
<Company>
the client gets to unfuck the protocol
<kchibisov>
Company: fullscreen window is always opaque regardless.
<kchibisov>
just as a side note.
<emersion>
no, the client sgets to behave as excepted
<emersion>
expected*
<emersion>
it's a deliberate trade-off in the protocol
<Company>
fun rounding games for everyone
<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.
<Company>
totally
<emersion>
"doctor it hurts i designed by client badly" well yeah, not sure what we can do about it
<emersion>
just round once, and then use the scaled and unscaled sizes
<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.
<Company>
yeah, I figured that out yesterday when I was given a scaling factor of 329/120
<Company>
because that was fewer pixels off than 330/120
<Company>
with the plus that now pretty much no application pixel boundary matched with a device pixel boundary
<kchibisov>
Are you writing client or compositor?
<Company>
GTK
<kchibisov>
Be aware that some compositors have bugged fractinol scaling impl, like sway.
<Company>
I'm usually using gnome-shell
<Company>
I just started playing with it and the more I looked, the wonkier everything ended up being
<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
<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)
<Company>
but attempting to map to device pixels - literal pixels on the monitor - gets really hard that way
<kchibisov>
I'm not sure from where you've got 1/256th viewporter reference. Viewporter is all logical sizes.
<Company>
kchibisov: it's using wl_fixed, which is 1/256th
<emersion>
viewporter doesn't use wl_fixed
<kchibisov>
^
<Company>
for the source
<kchibisov>
But for fractional scaling you don't set source.
<emersion>
source and dest rects are just ints
<Company>
the source rect is wl_fixed
<emersion>
incorrect
<emersion>
oh, okay
<kchibisov>
emersion: it's actually...
<emersion>
yes, it is wl_fixed. but it doesn't matter
<emersion>
you only use the fractional part if you want to sample in-between two pixels
<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"
<Company>
had a fun argument about aligning subsurfaces on fractionally scaled outputs with some shell devs yesterday
<zamundaaa[m]>
Company: the compositor guarantees that every (toplevel) surface starts on a whole pixel
<Company>
zamundaaa[m]: yeah, but that falls apart for subsurfaces
<Company>
zamundaaa[m]: it also falls apart if the compositor chooses 329/120 as the scale factor
mvlad has quit [Remote host closed the connection]
<Company>
zamundaaa[m]: because users will notice when toplevels can only be moved by multipls of 329 device pixels ;)
<emersion>
kchibisov: is sway still broken though? i thought we fixed everything
<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)
<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.
<emersion>
ah, i see
<kchibisov>
Given that hyprland has the excat same bug, based on the user report I had in alacritty, it's likely a wlroots thing.
Guest9809 has quit [Ping timeout: 480 seconds]
<emersion>
nah, wlroots doesn't handle toplevel position
rosefromthedead has quit []
<kchibisov>
Hm, maybe they were inspired by sway.
<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
<Company>
yeah
<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
<Company>
that would work for subsurfaces, too
<Company>
and then you'd use viewport.set_source() to offset your buffer
<Company>
btw
<Company>
while I'm complaining
<Company>
the preferred_scale notification in gnome-shell arrives too late - at the point it arrives GTK has already commit()ed the first buffer
<Company>
it would be nice if the protocol explained when it expects that event to be sent
jmdaemon has joined #wayland
<Company>
the shell delays it until it know which output the surface will be on, but that requires doing the configuring
<Company>
and GTK wants to draw right after configuring
<Company>
so there's a question about how things shouold be ordered
<kchibisov>
But you sort of know where the client will open on the first configure from the compositor perspective?
<Company>
I expect so
<Company>
I work on GTK though, so no idea
<kchibisov>
So gnome can clearly send you the scale factor along with the first configure.
<Company>
yeah
<Company>
but it would be good if the spec said so
<Company>
"clients can expect the event to arrive before the first configure"
<Company>
it's a somewhat more generic question, because it applies to all properties of surfaces
<Company>
like I'd expect the colorspace stuff to have that problem, too
<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)
<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
<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
<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.
<Company>
yeah, that configure thing sounds good
<Company>
kinda like commit(), just for the server
<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.
<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
<kchibisov>
Yeah, but you should handle client moving between different DPI monitors.
Moprius has joined #wayland
<Company>
sure, it's not visible
<Company>
to the normal observer
andyrtr has joined #wayland
<Company>
but my debugger stopped twice instead of once when starting my app
<Company>
oh, another thing:
<Company>
fractional scale needs a way to communicate fractional scale for outputs
<kchibisov>
Like I can't say much on assets loading, because I do such thing lazy.
Moprius has quit []
<kchibisov>
The scale on wl_output is sort of deprecated though.
<Company>
we do that in a thread so the assets are available when we want to render
<Company>
so we want a scale asap
<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.
<Company>
I don't have a wel_surface yet
<Company>
when I start loading assets
<kchibisov>
Ah, then if you don't have a surface, how do you know which scale factor to load?
<Company>
we currently use the scale of the first output
<Company>
which is right in almost all cases
<kchibisov>
That's wrong though, because what is first is not even defined.
<emersion>
<Company> fractional scale needs a way to communicate fractional scale for outputs
<emersion>
why?
<Company>
it's better than any other option
<Company>
emersion: see backlog
<kchibisov>
emersion: they exlained that they guess based on output.
dcz_ has joined #wayland
<emersion>
ouch
<emersion>
that's not good
<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.
DodoGTA has quit [Quit: DodoGTA]
<Company>
sure
<Company>
that's what we do when the scale turns out to be wrong and we have to reload assets
* kchibisov
would be impressed to see a C gui library without a global state.
<Company>
but the way startup works in GTK is kinda like this:
<Company>
1. create the wl_compositor
DodoGTA has joined #wayland
<Company>
2. create the widget tree
<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
<Company>
3. create wl_surface(s) for the widget tree
<Company>
4. configure the wl_surface(s) with the widget tree's sizing information
<kchibisov>
But you can't use any of the sizing unless you commit the surface and get the configure back?
<kchibisov>
as in all geometry requests on surfaces without buffers will likely be a protocol error.
<Company>
I'm not an expert on what I can and can't doin Wayland
soreau has quit [Ping timeout: 480 seconds]
<Company>
I'm just saying that the current code works in a way that the preferred scale arrives rather late
<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
<kchibisov>
I think it was sort of stated that scale arrives after the configure.
<kchibisov>
At least, that's how I understood Company .
<Company>
jadahl: right, but for that I need to know the size and for that I need to load the whole widget tree
<kchibisov>
And what they really want if compositors send the scale before the first configure.
<kchibisov>
As in "reliable".
<Company>
jadahl: so we're pushing the asset loading further and further back
<Company>
I just want to do some opportunistic loading in a thread
<Company>
and end up being lucky
<jadahl>
Company: you can't possibly have the size until after the configure event
<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
<Company>
yeah
<Company>
that's why I want an opportunistic scale
<Company>
the number that's most likely to make me luicky
<jadahl>
there is no such scale
<kchibisov>
Company: configure, as in *server send you* event.
<kchibisov>
just to ensure we're on the same page.
<Company>
jadahl: on my laptop there is such a scale - and it is a hit 100% of the time
<Company>
because my laptop has exactly 1 output and uses a scale of 2 for everything
<jadahl>
Company: that's not a general solution, just unreliable guess work
<kennylevinsen>
tbf some compositors do know the placement before map occurs and they could send early - they might be the exception though
<jadahl>
what's the point of delaying resource loading 1 ms?
<Company>
it's more than 1ms
<jadahl>
erm, the other way around I mean
<Company>
I mean, GTK has a ::scale property that it needs to initialize somehow, and send change notifications whenever it changes
<Company>
so picking a good initial value is worth it anyway
<Company>
but that can be considered a GTK problem, too
soreau has joined #wayland
<Company>
still, having a good first guess for the scale without needing a wl_surface is something we like
<Company>
and currently, with using output[0].scale, I'd expect we hit that in >90% of the cases
godvino has joined #wayland
<Company>
probably closer to 99%, because people with multiple differently-scaled outputs are probably very rare
<kennylevinsen>
maybe voice this on the issue emersion linked that specifically addresses the topic
<kennylevinsen>
sure, you could also say that you'd get it right 85% of the time by assuming "1"
<kchibisov>
kennylevinsen: they want to assume without any surface created though, not sure that linked issue will help.
<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...
dcz_ has quit [Ping timeout: 480 seconds]
<kennylevinsen>
Well it addresses getting to know it in time for first render
<kchibisov>
Yeah, but they don't want that ¯\_(ツ)_/¯
<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 :)
<Company>
does matter in that our first buffer appears a few frames earlier
<kennylevinsen>
if you have a buffer, you must have rendered and so the issue applies
<Company>
yes
<Company>
but if we're still busy loading assets, the buffer will take a while
<kchibisov>
Yeah, and the wl_surface v6 covers that, so you get your first scaling before you'll draw.
<kchibisov>
The fractional scaling protocol also covers that.
<Company>
I want the first scaling before I create the wl_surface
<kchibisov>
And that's the thing, you can't.
<Company>
I can get pretty close
<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
<Company>
I should actually try figuring out what happens wth some asset-heavy code, ideally stuff that doesn't have the assets in cache
<Company>
to see how big of a problem that is
<daniels>
you can have a surface long before you render
<Company>
example would probably be file managers who load thumbnails
<Company>
daniels: yes and no - we could redesign how we construct our widget tree to create the wl_surface asap
<Company>
daniels: but currently the surface creation step happens rather late
<kchibisov>
I do wonder why are you creating wigdet tree, and then top-level though.
<Company>
but it'd also assume that compositors send buffer scale etc before the first configure
<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.
<Company>
kchibisov: GTK creates the window system resources in a separate realize() step - and that step usually runs after creating the widget tree
<kchibisov>
But I'm have no clue about GTK limitations.
<Company>
no idea why, probably historic
<Company>
I also never considered it a benefit to create the wl_surface earlier
<Company>
(or the XWindow or the HWND)
<kchibisov>
You can't use your graphics API without creating a HWND on windows.
<Company>
correct
<Company>
but I can build my widget tree
<kchibisov>
By use, I mean that you can't do even config loading/matching like you can with GLX/EGL.
<kchibisov>
Or checking what extensions you have, but that's sort of offtopic.
<Company>
uh yes, but we do that by having a dedicated global HWND that does that part
<Company>
we have that on X, too
<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.
<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
<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
<kchibisov>
Company: you can certainly do while !got_configure { sync_roundtrip() } and then continue your init flow.
<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.
<Company>
yeah, but I want to do that in a thread so the main thread can load its widgets
<Company>
because I need both - the widgets to be ready and the wl_surface
rv1sr has quit []
<soreau>
if it's taking that long to get a configure event from the compositor, there's already a pretty big problem
caveman has joined #wayland
cvmn has quit [Ping timeout: 480 seconds]
godvino has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
rosefromthedead has joined #wayland
tjaden has joined #wayland
rosefromthedead has quit [Remote host closed the connection]
rosefromthedead has joined #wayland
mohamexiety has joined #wayland
glennk has quit [Read error: Connection reset by peer]
glennk has joined #wayland
ForeverNoob[m] has joined #wayland
<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.
<ForeverNoob[m]>
(Trying to determine how to reliably test whether the X220T/X230T is multi-touch or not)
rosefromthedead has quit [Remote host closed the connection]
rappet has quit [Remote host closed the connection]
immibis has quit [Remote host closed the connection]
rappet has joined #wayland
immibis has joined #wayland
rappet has quit [Remote host closed the connection]
immibis has quit [Remote host closed the connection]
tjaden has quit [Remote host closed the connection]
rappet has joined #wayland
immibis has joined #wayland
yoslin has quit [Remote host closed the connection]