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
columbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
<orowith2os>
Ishq you'll have to ask your compositor developers, Wayland doesn't allow arbitrary clients to interact with others.
<orowith2os>
wlroots probably has some way (for all wlroots compositors) to do that, GNOME has some stuff built in I think, and KDE most definitely does
Brainium has joined #wayland
gfxstrand has quit [Ping timeout: 480 seconds]
gilvbp has quit [Quit: Connection closed for inactivity]
carlos_ has quit [Ping timeout: 480 seconds]
gilvbp has joined #wayland
gallo_ has joined #wayland
gallo has quit [Ping timeout: 480 seconds]
<danieldg>
wlroots doesn't have a way for all, that's only in more specific protocols (sway ipc, for example)
<danieldg>
you can get the *focused* window with foreign-toplevel (the taskbar protocol) but that's not hover
Brainium has quit [Quit: Konversation terminated!]
nerdopolis has quit [Ping timeout: 480 seconds]
gilvbp has quit [Quit: Connection closed for inactivity]
gfxstrand has joined #wayland
sima has joined #wayland
gallo_ is now known as gallo
Luxzi has joined #wayland
Luxzi has left #wayland [#wayland]
tzimmermann has joined #wayland
zvarde1988303206779191683 has joined #wayland
zvarde198830320677919168 has quit [Ping timeout: 480 seconds]
zvarde1988303206779191683 is now known as zvarde198830320677919168
<zzag>
Has the meeting date and time been decided?
i509vcb has quit [Quit: Connection closed for inactivity]
rasterman has joined #wayland
ciara has quit [Read error: Connection reset by peer]
ciara has joined #wayland
pochu has joined #wayland
pochu has quit [Ping timeout: 480 seconds]
carlos_ has joined #wayland
epony has joined #wayland
<Ishq>
orowith2os: got it. Thanks. I was afraid of that. I've read about the xdg-foreign protocol which might be interesting though
gallo_ has joined #wayland
gallo has quit [Ping timeout: 480 seconds]
<Ishq>
Seems there is no API to query exported surfaces :(
<jadahl>
Ishq: what is it exactly you want to do?
<emersion>
xdg-foreign is for one specific use-case
<emersion>
parenting toplevels from two different processes
epony has quit [Remote host closed the connection]
<pq>
Ishq, it would help to explain what you want to do from an end user experience point of view, before you decide you need a specific API.
Company has quit [Quit: Leaving]
<Ishq>
I'm trying to update my multitouch gesture recognition app to work on Wayland. One of the features is that it can have per-app gestures. In X11, I would be able to query the "focused" app and use that to figure out what gestures to use. I'm looking for analogous functionality in Wayland
<Ishq>
Technically, the app itself works fine in wayland except for the perapp gesture thing
<emersion>
there is no cross-desktop API for this atm
<emersion>
wlroots and other compositors have a foreign-toplevel protocol
<Ishq>
I guess that's fine...I plan to use sway anyways. I was hoping for something better than parsing get_tree. I'll read the wlroots code to see what they do with foreign surfaces and if there is an API to query them.
Fxzxmic has joined #wayland
cmichael has joined #wayland
fmuellner has joined #wayland
epony has joined #wayland
jelmer has left #wayland [#wayland]
<pq>
I'm slightly curious how that app can work on Wayland at all.
gallo_ is now known as gallo
jmdaemon has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
CME_ has quit [Ping timeout: 480 seconds]
epony has quit [Ping timeout: 480 seconds]
epony has joined #wayland
epony has quit [Remote host closed the connection]
epony has joined #wayland
<immibis>
that sounds like something that should be in the compositor?
<Max1>
daniels / jadahl: I mentioned here last week that in this line: https://gitlab.freedesktop.org/wayland/weston/-/blob/main/desktop-shell/shell.c#L1646, `shsurf` might be NULL in some edge cases (popups are involved, fullscreen xdg-toplevels probably as well). Not sure if there's a fix already underway or if I should file a bug so we can keep track of this?
<daniels>
Max1: yeah, please file a bug - it's definitely NULL in case of popups but I'm not entirely sure what the proper fix is for it
<daniels>
(and my timeslot expired)
<Max1>
Ok, will do, thanks!
<daniels>
np, thank you!
epony has quit [Remote host closed the connection]
<pq>
Eh heh. To my latest understanding of EDID, the "default RGB colorimetry" was the closest thing to having source based color management until SBTM becomes usable. The WCG and HDR modes introduced in between just made things more unknowable by invalidating the old colorimetry and offering nothing in its place.
epony has quit [Remote host closed the connection]
<pq>
I think we are really going to need tools that end users, who happen to care but not enough to buy profiling equipment, can get an estimate of the color gamut limits in BT.2020 mode.
<pq>
assumptions galore, but maybe it might lead to subjectively better picture sometimes
<pq>
I also think we've been using HDR static metadata in infoframes wrong all the time, except video players that just set what the video says.
epony has joined #wayland
ukiran has joined #wayland
ukiran1 has joined #wayland
<ukiran>
hello pq
<ukiran>
need little help in reading the color primaries and other transfer characterstics from the LCMS
<ukiran>
have enabled color-management in the weston server and created a color profile from the icc file..
<ukiran>
now when i want to read the color primaries from the color profile created from icc file, am getting some values..
<ukiran>
but the color primaries read from the color profile and the primaries of the widergamut are not matching.. Is it is expected ?
<ukiran>
reading these cp using lcms lib
<ukiran1>
pq, btw, i have used /usr/share/color/icc/colord/WideGamutRGB.icc as an icc_file
<pq>
ukiran, do not try to disassemble an ICC profile to go back to primaries and white point.
<ukiran>
okay. just wanted to know how a compositor will take a decision on the preferred color space, other color characteristics to create the preferred-image-description
<pq>
I'm not even sure what you are trying to do.
<pq>
A surface's preferred image description could be simply the image description of the output where the surface is synchronized to.
<pq>
Or if a compositor uses a single global blending space, the preferred image description could be derived from that.
<pq>
If you have an ICC profile, then send the ICC profile as-is to the client, and do not send any other parameters at all.
<ukiran>
If the client wants to get the image descrption, then the bunch of events needs to be sent to the client with all the color params right ?
<ukiran>
In this case, do we need send only icc_fd followed by done event ?
<pq>
No. Only those parameters the compositor had.
<pq>
If a compositor has an ICC profile, then it has nothing else.
<pq>
yes
<pq>
Deriving device primaries and white point from an ICC profile is often not even possible.
<ukiran>
Yes.. i have got some but dont know whether they are proper or not
<ukiran>
used some icc-tags to read those..
<pq>
yeah, and the tags may or may not exist, and then you might be throwing something else away that the profile is doing
<ukiran>
if the compositor is not using an ICC profile, then how the compositor will create the preferred-image-description ? is it is based on the color space supported by the monitor ?
<pq>
exactly the same way I explained
<pq>
you need an image description for each output, and you decide to choose one output as the main output for the surface, and use that output's image description as the surface's preferred one.
<pq>
*you can decide to choose
<pq>
Where to get the output image description is a much harder problem. EDID is practically useless.
<pq>
well, theoretically useless, I don't know about practise yet
<pq>
there might be something that libdisplay-info does not parse yet, but lacking that, I guess one has to either guess (pick something from a short list of standards), or measure (needs equipment).
rv1sr has joined #wayland
<ukiran>
could you please point me what libdisplay-info is not parsing yet ?
<ukiran>
i have included libdisplay-info as part of my experiments and able to read the color-space information
<pq>
ukiran, I don't know what libdisplay-info is not parsing yet that would be relevant here.
<pq>
There is nothing useful that I know of for any HDR mode.
<ukiran>
okay
<ukiran>
if we know the colorspace of the monitor,can we hardcode the primaries, tf, other parameters hard coded to create the image description object.
<pq>
sure
peeterm has quit [Read error: Connection reset by peer]
peeterm has joined #wayland
Fxzxmic has quit [Remote host closed the connection]
<ukiran>
pq, based on the protocol, how can we create an image_description based on the icc_profile ? wp_image_description_factory_icc_v1_interface:: Create()
CME has quit [Ping timeout: 480 seconds]
CME has joined #wayland
<pq>
ukiran, you mean how a client can create an ICC-based image description? Yes, with wp_image_description_creator_icc_v1.
<pq>
after checking that it actually is advertised as supported
<pq>
new_icc_creator request gives you a wp_image_description_creator_icc_v1
epony has quit [Remote host closed the connection]
sima has quit [Ping timeout: 480 seconds]
rv1sr has quit []
rasterman has quit [Quit: Gettin' stinky!]
fmuellner has quit [Ping timeout: 480 seconds]
epony has joined #wayland
<Ishq>
pq: it's because it directly hooks into libinput and doesn't rely on wayland, that said, I haven't given it significant mileage under wayland...(https://github.com/DolceTriade/gesturers/tree/master). It's worked great for the last few years, but given how everything was moving to wayland, I figure I'd port it over so I could use it on wayland
<jadahl>
vyivel: hmm, true, part of the removed "meaning" should be morphed into the earlier paragraph
<vyivel>
that sounds like it would require a version bump
<jadahl>
why?
<jadahl>
!151 attempted to deduplicate, but missed part of it
<vyivel>
a compositor which implements the latest xdg-shell.xml has full rights to kill a client which tries to create a grabbing popup on top of a non-grabbing one
<vyivel>
if the client wants to do that, it must be sure the compositor actually supports this case
<jadahl>
!151 didn't change anything, so no it doesn't
Brainium has joined #wayland
<vyivel>
weston and smithay don't seem to allow that fwiw
<vyivel>
"xdg_popup was not created on the topmost popup"
ciara has quit [Read error: Connection reset by peer]