ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
AJ_Z0 has quit [Read error: Connection reset by peer]
<ofourdan>
DodoGTA: Xwayland is an xserver, it handles x11 fonts like like any other xservers, using font paths "xset fp" - for example, here, 'xlsfonts | wc -l' gives 2188 fonts.
<ofourdan>
(it doesn't use the xorg.conf though, so if you had any font paths set there, you'd have to add them using xset)
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
tzimmermann has joined #wayland
rv1sr has joined #wayland
kts has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
<kode54>
I have significantly more font pollution in my system
<kode54>
that wc -l gives 8010 here
<ofourdan>
well, definitely more than 4 ;-)
<kode54>
fun thing I ran into recently too
<kode54>
I needed an xorg-fonts-misc package
<kode54>
to run hasciicam in GUI mode, that is
<kode54>
turns out that package uses aalib, and I didn't see the optional dependencies of aalib to make its x11 backend display properly
Company has joined #wayland
tlwoerner_ has joined #wayland
tlwoerner has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
mvlad has joined #wayland
kts has joined #wayland
<DodoGTA>
kode54: Even after I install one of those xorg-fonts packages, the font count doesn't change in xfontsel (and probably xlsfonts too)
crazybyte has quit [Read error: Connection reset by peer]
crazybyte has joined #wayland
kts has quit [Ping timeout: 480 seconds]
Net147 has quit [Quit: Quit]
Net147 has joined #wayland
<wlb>
weston Merge request !1399 closed (compositor: fix crash when repaint fails with pending presentation feedback)
<MrCooper>
fontconfig doesn't affect the X protocol font handling, it's more or less a client-side replacement
mupuf has joined #wayland
anarsoul has joined #wayland
anarsoul|2 has quit [Read error: Connection reset by peer]
WhyNotHugo has quit [Remote host closed the connection]
WhyNotHugo has joined #wayland
<kode54>
ah
<kode54>
so I don't know what would cause X to be missing font config
leon-anavi has joined #wayland
kts has joined #wayland
tagr has quit [Remote host closed the connection]
tagr has joined #wayland
glennk has joined #wayland
abeltramo589523 has joined #wayland
abeltramo589523 has quit []
gryffus_ has quit [Read error: Connection reset by peer]
lsd|2 has joined #wayland
gryffus_ has joined #wayland
alarumbe has quit [Remote host closed the connection]
alarumbe has joined #wayland
Brainium has joined #wayland
feaneron has joined #wayland
abeltramo589523 has joined #wayland
<ofourdan>
DodoGTA: are those fonts you installed listed in the font path as used by teh xserver (xset q)?
<ofourdan>
installign the fonts is not enough, the font path need to be knownto the xserver - Some distributions add symlinks in /etc/X11/fontpath.d/ but those might end up being filtered out and ignored.
<wlb>
weston/main: Daniel Stone * view: Move psf_flags from weston_view to weston_paint_node https://gitlab.freedesktop.org/wayland/weston/commit/f5074f261aa8 include/libweston/libweston.h libweston/backend-drm/state-propose.c libweston/compositor.c libweston/libweston-internal.h
<Company>
zamundaaa: there's various GTK branches of the protocol, too - but it's all wip and nobody has actually run a full app => gtk => any compositor => kernel => monitor setup yet
* Company
not commenting on the issue because it doesn't load
nerdopolis has quit [Ping timeout: 480 seconds]
<zamundaaa[m]>
great, added it to the list
<zamundaaa[m]>
And yeah it takes absolute ages to load sometimes
<Company>
I have flaky internet atm
<Company>
that surely contributes
<zamundaaa[m]>
Maybe, but it also takes like 10s just to load the preview of my edited comment
<zamundaaa[m]>
freedesktop gitlab seems to be generally slow today, and the 600 comment MR is always slow on its own
Guest1139 has quit [Remote host closed the connection]
<Company>
I talked about this with mclasen yesterday
cool110 has joined #wayland
<Company>
my plan with GTK is to slowly truck on with adding features, but not sue how much we expose with the September Gnome release
<Company>
and then we switch to linear compositing early after
cool110 is now known as Guest1292
rv1sr has quit []
<Company>
so I'd like to see some common implementations appear in time for F42
<Company>
or 25.04 Ubuntu
<Company>
or whatever people use to time things
<zamundaaa[m]>
I'd like a much faster timeline fwiw
<zamundaaa[m]>
Ideally to have the protocol merged before Plasma 6.2, which releases in October if I have the release schedule correct
jlco has joined #wayland
* Company
has no horse in this race
<Company>
I'll take what is there and work with it, and don't care if it's merged or not
<mclasen>
zamundaaa[m]: it would be really nice to have to the protocols merged
<Company>
the biggest thing I want is implementations I can test against, and even better conformance tests
<Company>
if a merged protocol helps with that, I'm all for it
<zamundaaa[m]>
It should mostly help get a lot of app developers interested in implementing it
<Company>
I have no idea how that's even supposed to work
<zamundaaa[m]>
Because right now that seems to be quite limited, because they expect an API to be there in the system before implementing it, which doesn't work with Wayland
<Company>
like, the apps that want to use it are somewhat limited
<Company>
and a bunch of them wait on toolkits
<zamundaaa[m]>
There aren't many apps that really depend on it, but they're one of the last major complaints about Wayland
lsd|2 has joined #wayland
<Company>
how does that work with Qt?
<Company>
Does Qt have an API in the core, or does the rendering engine ship one? Or does that go in KDE?
<Company>
mostly because in core would mea it's pretty restricted and how the protocol evolves doesnt matter too much for app dev - and if it's outside, the APIs are way more undefined and dependent on the Wayland protocol probably
<Company>
also, do you know of any browsers doing work about this?
<Company>
feaneron: Do you know if webkit-gtk is doing any work on color management integration?
<zamundaaa[m]>
Krita has some custom stuff for color management
<Company>
yeah, I was expecting that - Krita is used in places where people care a lot about that stuff
<zamundaaa[m]>
What Qt has itself for color management is still very limited afaik, I'm not super up to date if there's any efforts to change that
<zamundaaa[m]>
On the browser side, Chromium implements a really old snapshot of the protocol
<zamundaaa[m]>
Getting it to actually make use of it on normal Linux is something I tried but failed badly at
<Company>
hehe
<Company>
what's actually needed is some sort of collaborative environment where people implement in their apps what other people need to test their apps - which is where it's always been fallen apart
<Company>
because the stack is so deep that at least one component is always acting up
<zamundaaa[m]>
For Firefox last I heard there's at least interest in playing HDR videos, but idk if anything has actually happened about it
<Company>
and it's demotivating trying to make something happen in experimental branches of other people's code that one isn't familiar with
<Company>
and then people go do other stuff
<zamundaaa[m]>
Yeah. And you need someone with Wayland, color management and app knowledge to then review the thing if you do write it
<Company>
plus there's at least 3 competing groups with different ideas about how everything should work
<Company>
movie people, games people and oldschool icc profile people
<Company>
it's even kinda the case with the Wayland protocol - where Weston and KWin have an entirely different featureset, and the only thing they both can do is sRGB more or less
<Company>
other question: GTK wants to do linear compositing
<Company>
so that we produce visually identically output on sdr and hdr modes
<Company>
but that means we end up with a linear buffer in the end
<Company>
and then how do we hand that off to Kwin?
<Company>
do you like linear buffers? Will we need to run a transfer function over it?
<zamundaaa[m]>
You can use the linear transfer function with the new luminance requests Sebastian just added
<Company>
how would this look on the kwin side in an ideal world?
<Company>
the apps produce what kind of data and how do you turn that into the final image to send to the hardware
<Company>
?
<Company>
assuming HDR hardware here
<zamundaaa[m]>
It depends
<zamundaaa[m]>
In Plasma 6.1, if direct scanout isn't possible, the color data is converted to a linear version of the output colorspace, and that's written to a shadow buffer
<zamundaaa[m]>
After compositing, another shader pass converts from that to PQ in a 10bpc buffer, and that gets passed to KMS
<Company>
you use 16bit float for the intermediate buffers?
<zamundaaa[m]>
Yes
<Company>
"output colorspace" - is that hardware dependent, or does that essentially mean rec2020 linear?
<zamundaaa[m]>
In git master / 6.2, it does blending in a gamma 2.2 variant of the output colorspace. It either does the same as in 6.1, just with a 10bpc buffer, or it doesn't use a shadow buffer at all
<zamundaaa[m]>
With HDR, that is rec.2020 linear
<Company>
do you do the blending in the gamme colorspace? or do you use GL_SRGB do have gamma buffers but blend in linear?
<Company>
I guess that only works in 8bpc
<zamundaaa[m]>
Blending is in the gamma 2.2 colorspace. There's no GL_SRGB for 10bpc or for EGLImage in general
<Company>
EGLImage has a flag for that I thought?
<Company>
I saw some extension while googling about it
<zamundaaa[m]>
There is an extension, but I thought it wasn't implemented in Mesa
<Company>
that might be
<Company>
for GTK, it's available for the target side, so I'm fine
<Company>
so I can send you linear rec2020 from GTK and you're gonna be reasonably happy
<Company>
as float16
<zamundaaa[m]>
Yes
<Company>
btw: do you have linear srgb supported?
<Company>
it's excellent for testing, that's why I'm asking
<zamundaaa[m]>
I don't think 6.1 supports the linear transfer function
<zamundaaa[m]>
But 6.2 will
<Company>
that's good enough for me
<zamundaaa[m]>
If you want to offload blending in linear space though, that might be problematic. At least not until we switch to Vulkan and/or implement blend shaders in OpenGL
<Company>
the thing I'm worried about there, but those aren't critical atm, are our offloading stuff
<Company>
and if the compositor does scaling
<Company>
but we support fractional scale, so there should be no scaling happening
<Company>
for offloaded videos it might though
<Company>
most apps are opaque, so that's not an issue either
<Company>
and if shadows are blended wrong, I can live with that
<zamundaaa[m]>
With fractional scale v1, supporting it doesn't mean anything for subsurfaces
<Company>
yeah, but I'll either assume subsurfaces work fine or not use them until they do
<Company>
the tricky part is the hole punching part
<Company>
because it doesn't buy us anything if we offload blending to the compositor, if the compositor can't send it on to kms
<zamundaaa[m]>
It depends on the compositor and on the hardware
<zamundaaa[m]>
With current KMS APIs in general though, no
<Company>
somore fun work to do there, too
<zamundaaa[m]>
Lots of fun work has already happened
<zamundaaa[m]>
There's a branch with an API for per plane color pipelines, with support for Intel and AMD GPUs
<zamundaaa[m]>
KWin git master has most of the infrastructure for that in place, with only some minor changes being needed for it to make use of that
<Company>
oh, that's quite a lot closer to reality than I had expected
<zamundaaa[m]>
That reminds me though that I should finish up that stuff and post it on dri-devel. Afaik having real world userspace for the API is the main blocker for getting it into the kernel
<zamundaaa[m]>
The biggest remaining missing piece for offloading at this point is imo overlay and underlay support in compositors
<Company>
that's the same chicken-and-egg game as with the Wayland protocol
<zamundaaa[m]>
Nah, on the compositor side offloading a whole window is also worth it
<zamundaaa[m]>
And the color pipeline stuff is useful for the post blending CRTC properties too
<zamundaaa[m]>
The code to glue the infrastructure to different drm properties in the end is the easy part :D
<Company>
I was more thinking of the apps not starting to use an API that's not in the kernel
<Company>
and the kernel not adding an API that no app isusing
<zamundaaa[m]>
Yeah it's pretty similar in that regard
<Company>
the graphics offloading stuff in GTK was a similar thing - needed GStreamer patches, various gstreamer plugins, GTK, and video players
<Company>
without rmader running from one project to the next and filing issues and MRs, that would not have happened as quickly
<Company>
that said, it's still not really done - the big apps still haven't switched and various smaller drivers/compositors still have issues
gryffus_ has quit [Ping timeout: 480 seconds]
Calandracas has quit [Remote host closed the connection]
Guest1292 has quit [Remote host closed the connection]
gryffus_ has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest1302
kasper93 has joined #wayland
feaneron has joined #wayland
coldfeet has quit [Remote host closed the connection]
<feaneron>
Company: webkit has internal plumbing for color management, but that's disabled on linux
<feaneron>
Company: it's all in the internal, non-gtk part of webkit anyway. we'll need some sort of api somewhere, somehow, to enable it
<Company>
yeah, you're gonna end up with a buffer that's not srgb and then need to tell gtk/wayland about it on gtk/wpe probably
<Company>
which would require looking at the new protocol (for wpe)
bodiccea has quit [Ping timeout: 480 seconds]
cool110 has joined #wayland
cool110 is now known as Guest1306
Guest1302 has quit [Ping timeout: 480 seconds]
<JPEW>
I notices that weston pins the wl_region version to 1, is this for the same reason as wl_callback, just not documented as such?
<emersion>
it shouldn't, it should be tied to wl_compositor version
<kennylevinsen>
JPEW: wl_region is only created from wl_compositor::create_region, so the concern described in wl_callback (more than one factory) does not apply
<kennylevinsen>
JPEW: weston also isn't really "pinning" anything, it's just specifying that it's version 1, which is the only version available
<JPEW>
kennylevinsen: Fair, but if there was some change to wl_region, it would be e.g. version 6?
mclasen has quit [Ping timeout: 480 seconds]
<JPEW>
(6 be being the next wl_compositor version)
<kennylevinsen>
maybe, but given the scope of wl_region I doubt that will happen
<kennylevinsen>
and versioning hypothetical changes isn't a hobby of mine :P
<JPEW>
kennylevinsen: Sure, just checking. Maybe I just missed the documentation that describes how object versioning works, but that particular piece of code is a little confusing