ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
co1umbarius has joined #wayland
floof58 is now known as Guest987
floof58 has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Guest987 has quit [Ping timeout: 480 seconds]
Serus has quit [Quit: brb]
<daniels>
JoshuaAshton: a compositor that signals a frame callback for frame n+1 before frame n has retired is terminally broken
luna_ has quit [Remote host closed the connection]
ahartmetz has joined #wayland
yixie has joined #wayland
<MrCooper>
emersion: my interpretation of frame event semantics results from the compositor sending them when picking the surface buffer for its output frame, which seems quite natural and simple
tzimmermann has joined #wayland
rasterman has joined #wayland
pochu has joined #wayland
dcz_ has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
Company has joined #wayland
Leopold_ has joined #wayland
<pq>
emersion, TFs in Weston: depends on the API. On the protocol facing side, probably const struct weston_tf *. In the weston_color_transform API, there are already enums with unioned parameters for what a renderer needs to implement. So yes, there will be enums at some point, but not exactly what the protocol has.
occivink has joined #wayland
dcz has joined #wayland
<emersion>
dcz: do you have time to move forward the virtual-keyboard proto? if not, i can try
<dcz>
emersion: not really. I have no objection against you taking it
<emersion>
also let me know if at some point you have time for the IME/OSK stuff :)
<emersion>
ack!
manuel1985 has joined #wayland
<dcz>
emersion: not from the Purism or personal side, but I am ready to pick it up if someone wants to hire me
<pq>
emersion, the semantics of wl_surface.frame callback done is that a new commit is guaranteed to not override the commit of the callback. Unfortunately we were not that good at writing spec language all those years ago. Whether it should be used to implement a FIFO is a whole another question, since it does not ask the done event to be sent ASAP.
<emersion>
pq, if a client renders in a loop, and i want to make it render at full speed, i need to send frame callbacks as soon as the client commits
<vbt>
emersion: would the ext-virtual-keyboard protocol that you proposed would work for game controllers(/gamepads/xinput devices) ?
<emersion>
no
<pq>
emersion, re: TFs in Weston; there is also the LittleCMS layer in between, and LCMS already has some curve types defined which we use, and then add those that it misses. Vitaly may even propose to upstream them once they are solid.
<emersion>
wayland doesn't do gamepad input
<heftig>
> <@ahmadranirilidg:matrix.org> Hello, I'm trying some examples of qt wayland compositior (from qtwayland5-examples package). It's launchable both from TTY or nested. I notice that if I launch the compositor from TTY, my keyboard input become double, like if I type "l", the output become "ll". It doesn't happen when I launch it as nested... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/vLyVoScLguzATLAuwfXBeGqs>)
<vbt>
emersion: so, games directly read gamepad events from device fd?
<emersion>
yes
<vbt>
so, consider this hypothetical situation. remote desktop client wants to support gamepads. so, instead of using any protocols, should it needs to directly read from /dev/js* ?
<emersion>
i have no idea how this would work
<kennylevinsen>
DodoGTA: sure, just takes a subsurface per bar. Just don't try to do advanced drawing that way with hundreds or thousands of elements :P
<pq>
emersion, re: client render at full speed; Well, technically yes, but if you break the no-override guarantee, you violate protocol intention. But, you can say that your presentation is a no-op on a headless compositor, so you don't break the guarantee. Whatever. *shrug*
<emersion>
it not headless
mvlad has joined #wayland
<emersion>
i just want the freshest frame
<pq>
there is no protocol to ask for the freshest frame
<emersion>
i just want the client to render at full speed and pick the freshest frame when i do scanout*
<heftig>
vbt: a raw hid protocol would be nice
<pq>
emersion, sure, but there is no protocol to tell the client to do the equivalent of eglSwapinterval=0.
<emersion>
i am not following
<emersion>
i'm talking about core wayland only
<pq>
there is no way to tell a client to do what you want - there is only a mechanism that you might abuse by violating the intent of the protocol to practically achieve what you want.
<pq>
yes, core
<emersion>
i disagree
<pq>
too bad
<pq>
that's the problem with the low-level mechanics, they can always be abused for something they were not meant for
<zubzub>
is there a way to deduce if a fourcc code has an alpha channel or do I have to manually map all of them?
<emersion>
i don't believe it's an abuse
<pq>
zubzub, make an exhaustive map.
<emersion>
there's nothing wrong with saying "please render your next frame" right when the client submits a frame
<zubzub>
pq: ok :')
<pq>
Fine. We disagree. I'm also not going to file a bug against your compositor if you do that, but I will keep my opinion on this for now.
<emersion>
we do this in gamescope right now
* zubzub
wonders of some ai chatbot can do it for him
<vbt>
heftig: but, is the protocol really necessary for that? as per emersion , wayland doesn't handle that.
manuel1985 has quit [Ping timeout: 480 seconds]
<kennylevinsen>
heftig: maybe something abstracted slightly further away, but yeah would be nice if it could be routed through
<heftig>
it could, but resolving fights between applications reading or configuring gamepads, or securing gamepad access doesn't seem like a pressing problem
<vbt>
heftig: one of the solution would be "wayland must handle those devices"
<kennylevinsen>
especially with the gaming usecase largely served through Xwayland for now anyway
<kennylevinsen>
Would be more useful when wine Wayland is completed so gamescope and proton could utilize it
<vbt>
kennylevinsen: Xwayland is running on Wayland only, right? it would use the devices in the same way other Wayland clients would.
<kennylevinsen>
Yeah but then you need an equivalent X extension to forward it to
<kennylevinsen>
IIRC, games like that access the device directly right now...
<kennylevinsen>
hmm what would it take to get "close trivial misguided issues" rights
<emersion>
zzag, blocked by CI, or blocked by something else?
<emersion>
zzag, you are only Reporter in w-p
<emersion>
maybe we forgot to upgrade you?
<emersion>
zzag, invited you
<emersion>
here's a list of people who've made contributions in the past in wayland and wayland-protocols, but are no longer active: @bryce, @rdp.effort, @gfxstrand, @krh, @sardemff7
<zzag>
emersion: thanks!
<emersion>
(maybe rdp.effort and sardemff7 are still active in weston? they could be added to that project if needed)
<pq>
How to contact them... maybe open an issue somewhere and cc them there?
fmuellner has quit [Remote host closed the connection]
<emersion>
okay, ask them to reply if they want to keep their role, and give them 1 month to speak up?
<pq>
sure
Leopold__ has joined #wayland
fmuellner has joined #wayland
<SardemFF7>
not sure I’d consider myself “active” but definitely available for pings, whatever role that may be :-D
<Company>
emersion: I see you've never had the pleasure of using imlib ;)
<emersion>
aha, no, didn't know about this one
<swick[m]>
so, can I also get the reporter role?
<emersion>
sure, where?
<emersion>
org?
<emersion>
hm, i remember this discussion
<emersion>
it was about CI, and i'm not a fan hanbding off roles just for the sake of CI
<pq>
if you want the color-management factory re-design back to traditional, I'd like to do that before the name abbreviating I think.
<emersion>
better just patch projects to use detached pipelines so that anyone can have a working CI
<pq>
and the enums after both of those, if wanted
<swick[m]>
emersion: the projects inherit from the org, right? so sure, org would work for me
<swick[m]>
I mean, it's not just CI
<pq>
swick[m], seems we should rebase your color branch to main, that would bring in detached CI pipelines.
<swick[m]>
pq: I honestly just don't care about the factory design. if you don't want it anymore, go ahead and remove it, otherwise, keep it.
<swick[m]>
but sure, the order makes sense
<pq>
I'm torn. It works only half-way.
<pq>
To make it work in full, wp_image_description_v1 should have an event delivering the name string of the interface that can be used to inspect it, and clients need to create an extension object from it using that (global) interface in order to get the describing events.
<pq>
perhaps version in addition to name
<pq>
then we should have no need to ever extend wp_image_description_v1, so we can leave it like wl_buffer is and not bother with the versioning factory requests.
<pq>
or, just drop the idea of multiple factory globals, and have a fully traditional monolithic design.
<emersion>
can't factories create an interface with a wp_image_description_v1 event?
<pq>
what do you mean exactly?
<pq>
an event with new_id and without an XML-defined interface?
<emersion>
icc_profile_manager provides a request to create an icc_img_desc, which has ICC-specific events and requests
<emersion>
icc_img_desc has an event with a new_id, sent once when created, carrying the img_desc
<pq>
the problem case is asking a wl_surface for its preferred image description, which could then be from any factory
<emersion>
querying img_desc data only makes sense for this case right?
<pq>
it should somehow emit factory-specific data in events
<pq>
yes
<emersion>
so you could have surface_img_desc which carries the img_desc
<emersion>
in a new_id event
<emersion>
and also provides ways to query the image description data
<pq>
can you separate the factory-specific requests in separate interfaces like that? or do you end up with the current wp_image_description_v1 with events covering all factories?
<pq>
I mean, one interface for ICC stuff, another interface for parametric stuff, since they are mutually exclusive
<emersion>
the goal is indeed to split the requests/events based on the actual type
<emersion>
each kind of img_desc gets its own interface
<pq>
how do you achieve that?
<emersion>
i'm not sure i understand your question
<pq>
If I ask a wl_surface for preferred image description, I get a generic object. How do I get a type-specific object instead, when I don't know before-hand which type it is going to be?
<emersion>
if you ask a wl_surface for preferred image description, you get a surface_img_desc, not the generic object
<emersion>
then the surface_img_desc gives you the generic object as an event carrying a new_id with an img_desc object
<pq>
but surface_img_desc is not specific to ICC factory and not specific to parametric factory. How do I get either ICC or parametric object?
<pq>
A compositor internally chooses whether it uses ICC or parametric description for the preferred, how can a client get that object with a specific ICC or parametric interface?
<emersion>
eh
<emersion>
flag and two requests?
<pq>
That won't work if someone wants to add a third type with a new global factory. (This is the independent extendability.)
<pq>
the flag could be replaced with an interface name string, and the request be in the global factory interface instead...
<pq>
I'm getting the feeling that this is over-engineering extendability.
<emersion>
this would work, they'd just add their own request to get an img desc from a wl_surface
<emersion>
yeah, i think this is a bit tad complicated too
<pq>
right
mvlad has quit [Remote host closed the connection]
<emersion>
do we need the img_desc to be both feedback and input?
<emersion>
hm i guess so
<pq>
yeah, I want to be able to attach the same object I get as "wl_surface preferred" as the surface's image description.
<emersion>
yea
<pq>
it's not strictly necessary, but...
mvlad has joined #wayland
<pq>
the alternative is to trust that the compositor is efficient in de-duplicating internal image descriptions
<emersion>
an ICC ping-pong would be weird
<pq>
oh yeah, totally
<pq>
that's the point
dcz_ has joined #wayland
<pq>
I suppose the conclusion is that I'll blow up the whole factory design once more, and go back to the simplest, traditional, monolithic design.
<pq>
and add equivalent advertisements as currently is done via globals ads
<pq>
or maybe even fold it into the "features" enum
<pq>
PQ EOTF is funny. If you deal in YCbCr, the Y goes through the TF, so your max encoded luminance is 10k cd/m². But if you deal in RGB, the TF applies per-channel, so your max is 3 x 10k = 30k cd/m²???
<pq>
there must be some subtlety here...
<vsyrjala>
it's specified also for YCbCr? that seems unusual
<pq>
the YCbCr is the part that makes sense
<pq>
I'm looking at BT.2100-2
<pq>
Note 4b might explain it, if I can understand it.
<swick[m]>
eh, I think the luminance is still defined as weighted sum of RGB
<swick[m]>
attaching luminance to the TF was a mistake
<pq>
so... if only one of encoded R, G or B is non-zero and that encoded value is v, then PQ EOTF will give the luminance of the code RGB=(v, v, v)
rv1sr has joined #wayland
<swick[m]>
ah...
<swick[m]>
well, that makes sense, doesn't it? always the luminance of the achromatic color
<pq>
the only thing I can get from that is red cd/m² is different from green cd/m² is different from blue cd/m²
<pq>
so there are three different units, all called cd/m²
<pq>
then again, cd/m² is only defined for a green laser, so
<pq>
I mean cd is
<pq>
suddenly computing the overall luminance of a pixel as EOTF(max(R, G, B)) makes some perverse sense
<pq>
but it's all a fallacy, because the nits aren't "real"
Paul33 has joined #wayland
<pq>
the answer has different units depend on which channel is highest
<emersion>
(i think i've already said this before but: you client is sending non-UTF-8, pq, i see � instead of ²)
<pq>
oh, right
<pq>
and I see your ^2 just fine, and the question mark in a blob
<emersion>
(it's possible your bouncer is configured to use a non-UTF-8 encoding as well)
<pq>
I'm not using a bouncer, but I very likely have some odd irssi config from a couple decades ago.
<emersion>
maybe check your term_charset, recode_fallback, recode_out_default_charset
manuel1985 has quit [Quit: Leaving]
<pq>
recode_out_default_charset was definitely stuck in the 90s
<jadahl>
hmm, I see pqs ^2, but maybe irssi is very forgiving
<pq>
how's cd/m² ?
<jadahl>
works here
<emersion>
works, thanks!
<pq>
cool, thanks. Now to save the config too...
<emersion>
yeah, older clients will try to detect the charset -- but my clients are strict and only understand UTF-8