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
kts has joined #wayland
kts has quit []
cool110_ has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
julio7359 has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
manuels has quit [Remote host closed the connection]
manuels has joined #wayland
godvino has joined #wayland
slattann has joined #wayland
mokee has joined #wayland
mokee has quit []
mokee has joined #wayland
mokee has quit []
mokee has joined #wayland
godvino has quit [Quit: WeeChat 3.6]
dcz has joined #wayland
Szadek has quit [Quit: WeeChat 3.8]
tzimmermann has joined #wayland
smurray_ has quit [Read error: Connection reset by peer]
zmike has quit [Read error: Connection reset by peer]
zzag has quit [Read error: Connection reset by peer]
panzeroceania_____ has quit [Read error: Connection reset by peer]
DynamiteDan has quit [Read error: Connection reset by peer]
DynamiteDan has joined #wayland
panzeroceania_____ has joined #wayland
zmike has joined #wayland
smurray_ has joined #wayland
zzag has joined #wayland
julio7359 has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<pq>
emersion, if that's about removing working ABI from a stable library that is evidently also being used in the wild, then how could it be possible? I'm not sure if that's what you're referring to. "Removing" does include "make not work". We can come back to that once we cannot find any user of it anymore, new or *old*. But even it would techincally be a violation of stable ABI rules.
<pq>
JoshuaAshton, from that code block, it is impossible for me to see if you are using column- or row-major layout.
danvet has joined #wayland
<pq>
JoshuaAshton, re: scRGB; That's exactly what I'm talking about. I simply cannot assume that scRGB would never be used for bigger than BT.2020 gamut. Instead, the protocol requires applications to be explicit about the actual gamut, or they get the BT.709 gamut. If you as an application *know* it will never be bigger than BT.2020, you are free to say that via protocol when you know nothing else.
slattann has quit [Ping timeout: 480 seconds]
<pq>
JoshuaAshton, I do not have the luxury of not caring about HLG. Lucky you.
<pq>
JoshuaAshton, can you elaborate those industry opinions about HLG? who and why?
<pq>
JoshuaAshton, was that only game and game engine developers, or also broadcasting companies?
<pq>
or broadcasting tech suppliers or such
<emersion>
pq: a build option off by default is not nearly as dramatic
<pq>
yes, but what would that achieve?
<pq>
it doesn't allow us to drop code, and no distribution would be able to turn it on
<emersion>
BSDs for instance might be able to drop once all compositors in their repo have migrated away
<pq>
ok
<pq>
are there still BSD flavors that do not have working wl_event_loop implementation?
mvlad has joined #wayland
rasterman has joined #wayland
kts has quit [Quit: Konversation terminated!]
gspbirel5684008498790919236 has joined #wayland
gspbirel568400849879091923 has quit [Ping timeout: 480 seconds]
<pq>
Huh. Building libdisplay-info as a Weston meson subproject results in a DSO that exports no symbols. That's not intentional, is it?
<emersion>
that doesn't seem correct
<emersion>
fwiw i've used libdisplay-info as a wlroots/gamescope subproject without issues
<pq>
wonder if some build/link flags from weston leak into display-info that breaks it
<pq>
it worked as a static lib, naturally
<emersion>
if you add_global_arguments(), it would leak indeed
<emersion>
but add_project_arguments() shouldn't
<emersion>
project options might leak
<emersion>
(you can override these per-subproject)
<pq>
I don't see anything odd in the command to link the DSO, and -Wl,--version-script,/home/pq/git/weston/subprojects/display-info/libdisplay-info.map is there too.
<emersion>
pq, -fvisibility=hidden
<emersion>
in add_global_arguments()
<pq>
ooh
<emersion>
weston should really use project args here
<pq>
yes
<pq>
thanks!
<pq>
aml and neatvnc don't hit the problem, because they use visiblity=hidden themselves already
robobub_ has quit []
MrCooper has quit [Remote host closed the connection]
<emersion>
np!
MrCooper has joined #wayland
<emersion>
yea that makes sense
plarke has quit [Remote host closed the connection]
xyene_ is now known as xyene
ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<pq>
and libdisplay-info
<ifreund>
anyone know of real-world clients that unmap and remap their xdg-toplevels?
<ifreund>
just trying to get an idea of what semantics clients expect that to have
<ifreund>
e.g. should I persist compositor-specific window management state or reset it and behave the same as if it were a new toplevel on re-map
<davidre>
ifreund: What do you think of? Clients that delete and create new xdg_toplevels from the same wl_surface?
<ifreund>
davidre: clients that commit an empty buffer to the surface (unmapping it) and then do a new initial configure sequence
<ifreund>
I really don't see why we chose to allow this in the protocol to be quite honest
<ifreund>
but maybe there's a use-case I'm not aware of that justifies the complexity