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]
ahartmetz has joined #wayland
ahartmetz has quit [Quit: Konversation terminated!]
crazybyte has quit [Quit: Bye]
Dami-star has quit [Ping timeout: 480 seconds]
Dami-star has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
cool110_ has quit [Remote host closed the connection]
cool110 has joined #wayland
Szadek has joined #wayland
rv1sr has joined #wayland
sima has joined #wayland
Dami-star has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
Dami_Lu has quit [Read error: Connection reset by peer]
Dami_Lu has joined #wayland
cool110_ has joined #wayland
cool110 has quit [Remote host closed the connection]
Oro is now known as orowith2os
dcz_ has joined #wayland
Company has quit [Quit: Leaving]
isomari has joined #wayland
crazybyte has joined #wayland
pounce has quit [Remote host closed the connection]
pounce has joined #wayland
crazybyte has quit [Quit: Bye]
crazybyte has joined #wayland
mvlad has joined #wayland
rasterman has joined #wayland
isomari has quit [Quit: WeeChat 3.8]
isomari has joined #wayland
pochu has quit [Ping timeout: 480 seconds]
isomari has quit [Quit: WeeChat 3.8]
isomari has joined #wayland
systwi has quit [Remote host closed the connection]
pochu has joined #wayland
systwi has joined #wayland
systwi has quit [Remote host closed the connection]
systwi has joined #wayland
junaid has joined #wayland
cmichael has joined #wayland
cmichael has quit [Quit: Leaving]
cmichael has joined #wayland
<kennylevinsen>
jadahl: OT-ish, but the xdp-gnome hangs still do happen on latest releases (1.16 and 44.1) - seems like xdg-gnome fails immediately, but dbus/systemd decides to wait the full service activation timeout
<jadahl>
kennylevinsen: needs 1.16.1, but think that'll happen soon. make sure not to have xdp-kde installed too, it seems to have the same problem
<kennylevinsen>
ah
<kennylevinsen>
I feel that there is still merit to the PR allowing Settings to be configured like the rest
<kennylevinsen>
but the service activation timeout issue is definitely the most annoying issue, so let's see what 1.16.1 can do :)
<davidre>
problem is that gtk requires the gtk settings to have sensible font rendering :/
<kennylevinsen>
does the gtk portal provide that too?
<kennylevinsen>
at least works fine without the gnome portal
<kennylevinsen>
might make sense for the gnome portal to have a Settings only mode like jadahl suggested in the discussion, but there's precedence and preference issues with just using all backends...
<davidre>
yes
<davidre>
with xdg-desk-portal-gtk uninstalled this is how bustle looks on my system
<kennylevinsen>
ah yeah I remember that issue, and crops up in support occasionally
<davidre>
So you probably want to run at least the gtk portal on every system if you expect to run gtk apps
<kennylevinsen>
yeah, I think that makes sense - the tricky part becomes DE-specific things. A good example was auto-darkmode, where you have Darkman, GNOME and possible KDE all providing the same setting controlled differently.
<kennylevinsen>
(and maybe Gtk's font setting fallback just need a small adjustment)
<davidre>
I vaguely remember that xdp would at least ask the one belonging to the session first
<kennylevinsen>
is there a dedicated place for XDP discussions?
<davidre>
I dont know of any except the github :D
<jadahl>
davidre: if it doesn't already, it probably should, at lesat
<jadahl>
kennylevinsen: there is a matrix room
<kennylevinsen>
ah, fair enough
<davidre>
jadahl: I remember from reading the code once, and at least on my system it first asks the kde portal for a Setting
<kennylevinsen>
my matrix home server is resting in bit heaven, and have been a bit detached since that
<pq>
In this Recommendation, when we refer to the luminance of a single color component, we mean NOT the luminance of a single color component. *sigh*
<pq>
FWIW, both HLG and PQ use the same definition at least.
<pq>
well, inside BT.2100
<jadahl>
davidre: that code was changed a bit recently, from "look at UseIn for priority" to "lets see what DE's is asking for"
<davidre>
as I understand kennylevinsen he complains that it was not changed for the settings portal :D
<davidre>
but I would still hope it retains priority
<kennylevinsen>
"complains" is a strong word, I just think that our new, better system is applicable to Settings too :)
<q234rty>
I think the reason is that that commit does not change find_all_portal_implementations so settings will still try to launch x-d-p-gnome and times out
<jadahl>
kennylevinsen: if xdp-gnome and xdp-kde can learn how to enter "settings only mode", and xdp dealing with priority correctly, I suspect it can work with darkman as long as it gets to have a say before anything else
MadcapJake has joined #wayland
junaid has quit [Remote host closed the connection]
nerdopolis has joined #wayland
<kennylevinsen>
jadahl: I guess the question becomes how to handle the priority
<jadahl>
kennylevinsen: prioritize whatever the DE has in its "want this portal" file, and use anything else after ?
ahartmetz has joined #wayland
rv1sr has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
<kennylevinsen>
yeah mean specifyign an ordered list for Settings? Or just a single backend as priority?
<kennylevinsen>
the former is basically my suggestion, except you can also decide not to include a backend
<kennylevinsen>
but if we allowed a value of "gnome;*", wouldn't that be the best of everything?
<jadahl>
kennylevinsen: I mean first "filling out" the settings with whatever comes from the preferred list, and then continuing with all other backends for the rest
<jadahl>
if 'UseIn' is respected, seems the end result is in the screenshot from before
<kennylevinsen>
yeah UseIn wasn't great
<jadahl>
nor the fact that there is no "good" way to start in settings-only mode
<davidre>
Now that there is a list of which impl to use for which settings maybe it could make sense for a way for xdp to forward that info
<davidre>
Tell each impl which interfaces it should support
kts has joined #wayland
kts has quit [Read error: Connection reset by peer]
columbarius has joined #wayland
co1umbarius has quit [Remote host closed the connection]
<q234rty>
jadahl: see the new comment in the issue, turns out it does seem to be related to dbus-daemon vs dbus-broker...
<jadahl>
ah, great..
<jadahl>
either way, adding "settings only" mode and having xdp-{gnome,kde} handle them differently should address it. will add it to the gnome one
<q234rty>
side note: initially I was facing this issue in greetd but not in the session greetd launched
<q234rty>
turns out its because I ran enable and enable --user but not enable --global on dbus-broker
co1umbarius has joined #wayland
columbarius has quit [Read error: Connection reset by peer]
<pq>
ookay, then when an EOTF says that color channel is at C cd/m², it actually means that you take a white of (C, C, C) optical which results in C cd/m², and then zero the other channels. The light that is left is the chosen channel at "nominal C cd/m²" which is always less or much less than an actual C cd/m². That depends on both the RGB emitter white point and the... I forgot the name of the human spectral
<pq>
brightness sensitivity curve.
Company has joined #wayland
cmichael has quit [Quit: Leaving]
cmichael has joined #wayland
<pq>
I guess that's a trick that makes it possible to use the same EOTF for Y/I and per RGB channel, instead of defining a differently scaled EOTF for each.
<pq>
while reading about PQ and HLG, I've also seen comments that the peak cd/m² is only achievable at the device white point, and any other chromaticity is necessarily less. Which I knew, but nice to see confirmation.
co1umbarius has quit [Read error: No route to host]